Takto to mám nastavené. A i když vy vypadne default_gw1, tak mi to na 8.8.8.8 stále pingá. Přitom 10.12.10.254 se jeví jako "unreachable".
Protože ve chvíli, kdy se stane adresa brány 10.12.10.254 unreachable, tak se zneplatní daná specifická routa pro 8.8.8.8 a routuje se na základě nečeho jiného, co tomu vyhoví, což je ta defualt routa přes GW2.
Pokud se používá takto routa, aby šla daná IP jen jednou cestou, je třeba přidávat pomocnou blokovací routu, aby k tomuto nedošlo, takže:
/ip route
add check-gateway=ping distance=1 gateway=10.12.10.254 dst-address=8.8.8.8
add distance=5 dst-address=8.8.8.8 type=unreachable
Takto půjde spojení k 8.8.8.8 vžy jen přes tu první linku.
Pak jsem dělal ještě pokusy s ip rules, akorát jsem nějak nepřišel na to, jak nastavit, aby třeba cesta na osmičky byla vždy přes ether1. A ani na wiki jsem nenašel nic pořádnýho, k čemu tohle menu je. Poradíte?
/ip route
add distance=1 gateway=10.12.10.254 routing-mark=ISP1
add distance=5 routing-mark=ISP1 type=unreachable
add distance=1 gateway=10.0.1.138 routing-mark=ISP2
add distance=5 routing-mark=ISP2 type=unreachable
add distance=1 gateway=10.12.10.254 check-gateway=ping
add distance=5 gateway=10.0.1.138 check-gateway=ping
add distance=10 type=blackhole
/ip route rule
add dst-address=10.0.0.0/24 table=main
add dst-address=10.0.1.0/24 table=main
add dst-address=10.12.10.0/24 table=main
add action=lookup-only-in-table dst-address=8.8.8.8/32 table=ISP1
add action=lookup-only-in-table src-address=10.12.10.x/32 table=ISP1
add action=lookup-only-in-table src-address=10.0.1.254/32 table=ISP2
Tohle ti udělá s použitím route rule, aby 8.8.8.8 šlo jen přes ISP1 (čtvrté pravidlo).
Ty první tři pravidla jsou pro lokální segmenty (LAN a přímo připojené WAN segmenty k routeru), aby se vždy routovaly na základě hlavní routovací tabulky a neposílaly alternativně někam do pryč. Pak je nasměrování 8.8.8.8 do výlučně první linky. A poslední dvě řeší, aby spojení přišlá na router přes ISP1 nebo ISP2 se vracela správnou linkou zpět a ne tou druhou.
nicmene neni potreba skript. Staci ti na to tool-netwatch
Velkou nevýhodou netwatch je, že reaguje na první ztracený ping. Je třeba mlátit Mikrotiky po hlavě, aby přibyl parametr, že se má reagovat nepř až na 5-tý ztracený paket pro down událost a up třeba nahodit, až projdou 2 pakety... Také přes netwatch neudělám snadno svázání s tím, že má kontrolovat např 2 IPčka a až výpadek obou je přepnutí.
1) nastavit obě připojení a oddělit to pomocí distance v ip route. Nicméně toto bude mít asi problém v tom, že nehlídám tak úplně konektivitu do internetu, ale jen třeba hlavní bránu primárního poskytovatele. Teoreticky se pak asi může stát, že brána bude dostupná, ale internet nepůjde, protože problém bude až za bránou...
Proto tu existují rekurzivní routy, které se dají k tomuto použít. Kdy si router kontroluje klidně i víc IP adres a až všechny chcípnou, tak se daná routa přestane používat:
/ip route
add dst-address=8.8.8.8 gateway=10.12.10.254 scope=10
add dst-address=8.8.4.4 gateway=10.12.10.254 scope=10
add gateway=8.8.8.8,8.8.4.4 check-gateway=ping
Pokud je 8.8.8.8 nebo 8.8.4.4 dostupné pro ping, tak se routuje default brána přes 10.12.10.254.
2) udělat nějaký skript, který bude hlídat dostupnost ip adresy v netu a podle toho zapínat/vypínat defaultní routu. Asi něco takového a to spouštět třeba každých 30 sekund schedulerem:
...
Pak by to ale asi chtělo kontrolovat více IP adres, kdyby dejme tomu 8.8.8.8 klekla, tak se router upřepíná...
S maximální nechutí je nutno konstatovat, že v Mikrotiku je jediný způsob, jak to uchodit jakž tak, je to naskriptovat (pokud mám 2 nezávislé konektivity a musím na ně NATovat).
Jednak při použití skriptu nemusím natvrdo nutit routu 8.8.8.8, aby šla jen jednou linkou, použije se ve skriptu "ping 8.8.8.8 count=10 routing-table=ISP1" a můžu klidně i testovat pak druhý směr zase pomocí "ping 8.8.8.8 count=10 routing-table=ISP2", pokud mám založený ty alternativní route tabulky, jak je uvedeno výše u toho ip route rule. Potom se ve skriptu snadno ošetří, ať nepřepínám na první ztracený paket. Zde u pingu snad chybí parametr, že nemusí pingat 10x, ale ať se ping ukončí třeba po třech úspěšných odpovědích. Taktéž snadno můžu tím pngem kontrolovat víc IP, kdyby náhodou Google selhal. A hlavně ve skriptu můžu řešit to, že při změně odchozí linky musím vyresetovat connection tracking, respektive naučená NAT překlady, jinak při přepnutí se rozbije řada věcí, co funguje nad UDP a periodicky posílá data (SIP VoIP telefony je krásný příklad), bude je to pak posílat do druhé linky se zdrojovou IP odpovídající první lince, jak má naučeno v connection trackingu. Takže vedle disablování selhané brány, tak při každém přepnutí důmylsněji udělat něco na způsob "/ip firewall connection remove numbers=".
Jakým způsobem řešíte backup spoje vy?
Kde je to myšleno vážněji, že to má doopravdy fungovat, tak mám stejně dvě RB vedle sebe, každé drží jednu odchozí linku a na LAN straně je použito VRRP a dle ne/funkčnosti odchozí linky se přepíná priorita VRRP tak, aby pro věci v LAN byl odchozí RB ten, který má konktivitu.
