Mikrotik wifi stationbridge s LTE a NATem

[5nik]

S dovolením se vmáčknu s pár komentáři.

• Řešení dvou WAN je celkem komplexní záležitost, ale u Vás to naštěstí zjednodušuje fakt, že potřebujete řešit pouze odchozí směr.
  Méně sofistikovaně se to dá řešit dvěma výchozími routami, primární bude mít menší distanci než sekundární a na primární routě povolíte Check Gateway. Když se nedopingne na gateway, routa se zneplatní a bude platit sekundární s větší distancí. Toto řešení ale nepostihne výpadek internetu u souseda, zareaguje pouze na výpadek wifi.
  Sofistikovanější řešení je použití funkce Netwatch, kde si zvolíte vůči které (veřejné) adrese budete "živost" konektivity ověřovat, způsob (simple - pouhý ping -> dojde/nedojde, icmp - sofistikovanější s procentuální ztrátovostí atd..) a do Up a Down skriptu narvete jednoduché zakázání / povolené záložní routy, případně změnu její distance. Nesmíte zapomenout svázat testovanou IP s primární konektivitou separátní routou.

Jde to i bez netwatch přes rekurzivní routu

Zajímavý tip. Vyzkouším. Zajímá mne, jak se to bude chovat s dynamickými IP na WANu.

[Reklama]

[M_D]

Pokud v tom máš ROS7, tak korektně funguje stav, že fyzický wlan1 dáš jako to APčko (ap bridge) pro svoje věci a nad něj dáš virtual v režimu station a ten napojíš na toho souseda. Tohle šlape OK. Při opačné kombinaci je třeba použít to disable-running-check=no.
Samozřejmě na jednom rádiu AP i klient není úplně ideální stav, ale co už. :-(
Rekurzivní routa je možnost, jak to řešit. Projdi si toto: https://help.mikrotik.com/docs/pages/viewpage.action?pageId=26476608 a pak i toto https://help.mikrotik.com/docs/display/ROS/Firewall+Marking v části Failover With Firewall Marking. Aby jsi to mohl použít, tak toho DHCP klienta si nastav, že na tom wlan nemá nastavovat default routu, tu si nastavíš ručně dle toho výše.
Nicmémě, není to ideální řešení a rozhodně pro spolehlivý chod je potřeba varianta se skriptováním. Jednak ta rekurzivní routa s ping chckem vypadne při prvním ztracením pingu, což nechceš (jde řešit do určité míry použitím víc těch mezihostů). Horší je, že v reálu ti do toho bude kecat NAT a connection tracking. Potřebuješ, aby v okamžiku přepnutí na zálohu, tak aby se vymazala connection/NAT cache. Bez toho ti budou blbnout dlouhodobé UDP spojení, protože to bude držet pořád starý stav a pokud to UDP neustále bude do toho  posílat čas od času paket, tak je problém. TCP spojení ti vychcípe a naváže se nové, tohle urychlí to udělání dle Failover With Firewall Marking s tím rejectem při změně odchozí linky. Ale neřeší to UDP. Na to pak asi ten netwatch, kde přepneš routu ručně a zároveň u toho dělaš něco jako: /ip/firewall/connection/remove numbers=[find connection-mark="cm_ISP1" and protocol!="tcp"]

[5nik]

Pokud v tom máš ROS7, tak korektně funguje stav, že fyzický wlan1 dáš jako to APčko (ap bridge) pro svoje věci a nad něj dáš virtual v režimu station a ten napojíš na toho souseda. Tohle šlape OK.

A připojí se to i po změně kanálu sousedova AP? Myslím, že tohle jsem zkoušel (ještě v ROS6) a po prvním přeladění se Mikrotik už nepřipojil, protože čekal na původním kanále.

[M_D]

Nepřipojí. To musíš řešit skriptem v každém případě. Pokud není wlan klient up, tak si najít navou frekvenci pomocí něčeho jako:
foreach i in=([/interface wireless scan wlan1 duration=5 as-value]) do={if (($i->"ssid")="SSIDsouseda") do={:put [:pick ($i->"channel") 0 [:find ($i->"channel") "/"]]}}
a pokud je soused živý a frekvence jiná, tak ji změnit. A tohle pouštět přes scheduler a hlídat si, ať to skenování nedělám moc často.
Jde nastavit, aby se ti to samo přeladilo. Klienta dáš na fyzický wlan1, frequency=auto, tohle ti bude vzorně přelaďvat za sousedem do okamžiku, než to soused úplně vypne, pak to začne kontinuálně ladit a to virtuální AP nad wlan1 klientem má smůlu, během ladění se na něj nedá připojit. Proto, pokud potřebuješ tento stav ošetřit, tak je třeba přelaďovat skriptem občas, aby ti to fungovalo zároveň jako APčko a pak je asi lepší mít AP na fyzickém a klienta na virtuálu.
Inu, jednorádiový setup má nějaké limity. :-(