LTE backup s Cisco routerem

17.02.2022 | Tag Sítě

Způsobů implementace internetového připojení se zálohou je opravdu mnoho. Chtěla bych ukázat konfiguraci jedné z možných variant, kdy se použije jeden router s primární linkou a LTE backupem. V tomto případě tedy router od Cisco.

Pro začátek use case. V určitých případech používáme pro připojení lokality do firemní sítě menší Cisco router s integrovaným LTE modemem. Lokální poskytovatel nám zajistí primární připojení a v případě výpadku tohoto spojení se přejde na LTE backup. Ten zajišťuje datová SIM karta se statickou IP adresou jako doplňkovou službou od operátora. A jelikož jde o přenos přes datovou SIM, není úplně chtěné, aby byl tento spoj aktivní neustále. S tímto nastavením fungujeme už relativně dlouho a máme ozkoušené, že přepad a následná obnova fungují spolehlivě.

Velice podobný princip s LTE backupem pak máme i doma, kde jako router slouží cenově dostupnější Mikrotik. I v tomto případě funguje přepad velice dobře. Teď už však ke konfiguraci výše zmíněného.

Technicky bude mít router dvě rozhraní do internetu - primární připojení a LTE připojení. LTE připojení slouží jako backup a jeho interface bude v běžné situaci vypnutý. Routing bude řešený dvěma statickými routami s rozdílnou hodnotou administrative distance. První default routa bude přes primární rozhraní s AD 1, druhá default routa přes LTE rozhraní s AD 5. Za normálních okolností se tedy provoz bude routovat přes primární rozhraní. Dále bude na routeru vykonfigurovaná kontrola dostupnosti nějakého statického síťového bodu přes primární linku a v případě výpadku se automaticky provede změna routingu a nahození LTE interface.

Obrázek by měl naznačit layout sítě, ale spíše je to jen taková výplň. Hrát si na Visio bez Visia je vcelku těžké :).

Pro monitorování linek se na Cisco prvcích běžně používá ip sla. IP sla dává k dispozici velkou škálu operací pro testování různých atributů spojení, dá se tedy použít i pro složitější testy linky. Nám ale teď jde čistě o dostupnost. Pro ověření funkčnosti linky je nejlepší pravidelně dotazovat nějaký spolehlivý a stabilní bod v síti a kontrolovat odpověď. Tady záleží na každém, jaký bod si zvolí. Může to být router operátora, nebo nějaký veřejný server atd. Já většinou používám Cisco Umbrella DNS a jako alternativu používám DNS Cloudflare.

Napřed tedy vytvoříme operaci ip sla s číslem 1. Typ operace bude icmp-echo, je to prostý ping na nějakou destinaci, kterou jsme si v našem případě zvolili jako kontrolní bod. Jako zdrojové rozhraní pro odchozí ping se zvolí primární přípojka, případně IP adresa toho rozhraní. Není to v základu povinná část příkazu, ale pro náš účel bude potřeba. Frequency 5 říká, že se operace bude provádět po pěti vteřinách, to je však dle volby každého. Tím je základ hotov. Mimo výše zmíněného má ip sla spoustu dalších volitelných atributů, dá se s tím opravdu hrát.

Samotná ip sla operace se nebude provádět bez nějakého plánu. K nastavení plánu poslouží další příkaz, který říká, že operace 1 bude běžet bez ustání s okamžitou platností, protože v našem případě potřebujeme, aby check probíhal pořád. Jinak je možné mít schedule nastavený na určité datum a čas, může mít omezenou platnost a tak dále, opět podle toho, jak je zrovna potřeba.

Tím je tedy vytvořena kontrola dostupnosti pomocí ip sla. Tuto kontrolu je nyní nutné použít v další konfiguraci tak, aby se na jejím základě provedla nějaká akce. Pro automatickou změnu routingu se použije object tracking, kdy se vytvoří track, který se naváže na vytvořené ip sla a přiřadí k primární routě. Track má stav buďto up, nebo down, podle aktuálního ip sla výstupu. Dokud bude hlídaná IP odpovídat, ip sla bude vracet stav OK, track bude mít stav up a primární routa bude platná. Když se situace změní a hlídaná IP přestane být dostupná, track změní svůj stav na down a odebere primární routu z routovací tabulky. V tu chvíli se začne používat druhá routa směrovaná backup rozhraním s vyšší AD. Jakmile bude kontrolní bod opět odpovídat, track se vrátí do stavu up a původní default routa začne znovu platit.

Níže je nastavení tracku s číslem 1 a jeho provázání s dříve vytvořeným ip sla 1:

Delay v tomto případě říká, že se má na změnu stavu počkat 120 vteřin u stavu down (výpadku) a 120 vteřin u stavu up (obnovy). Mělo by to zamezit zbytečnému flappování rout v případě mikro výpadků. Nastavení hodnoty delay je také podle každého uvážení. U 120 vteřin jsou sice reakce na výpadky delší, ale zato se dobře daří vyhýbat zbytečným přepadům při kolísání linky.

Dále k nastavení rout. Jak bylo zmíněno, použijí se dvě s různými AD. K primární routě se přidá dříve vytvořený track 1:

První routa je default routa primární přípojky podmíněná trackem. Dokud bude ip sla check v pořádku, bude platit. Druhá routa přes LTE rozhraní má vyšší AD a nepoužije se, dokud je primární linka v pořádku. Jakmile nastane výpadek a track 1 změní stav na down, primární routa z routovací tabulky zmizí a začne platit druhá routa.

Výše uvedenou konfigurací se tedy zajistí kontrola stavu primární linky a v případě výpadku se upraví routovací tabulka. Nicméně na začátku jsem psala, že LTE rozhraní bude v základu vypnuté a zapínat se bude pouze při výpadku. K tomu poslouží další část konfigurace.

Pro tento případ se použijí dva event manager applety k nahození interface a k vypnutí interface. Oba applety budou vycházet ze stavu stejného tracku, který řídí statické routy. Jinak tyto applety je možné vytvořit v rámci komponenty zvané Embedded Event manager. Pokud vím, neumějí to všechny verze IOS, ale u novějších routerů nebyl problém. EEM umožňuje adminům vytvořit si buďto sety příkazů právě přes applet, nebo si napsat vlastní tcl skript. Tyto pak mohou reagovat na nějakou událost, jako je v našem případě stav tracku. Opět, EEM je mocná komponenta, mimo tento scénář se dá použít na spoustu věcí.

Níže jsou tedy EEM applety reagující na stav tracku 1, přičemž i pro ně platí nastavený delay 120 vteřin. První reaguje na výpadek (tj. na změnu stavu tracku na down) nahozením LTE backup rozhraní a druhý reaguje na recovery jeho opětovným vypnutím. Dále při změně stavu vždy vyčistí ike SA, protože podle mých zkušeností to urychlí obnovení IPsec tunelu, ale to samozřejmě není povinné. Jak je vidět, applet je poskládaný set příkazů přesně tak, jak by příkazy zadával admin sám ručně.

A to je celé. Jak jsem psala, je opravdu spousta konfiguračních možností, jak dosáhnout stejného výsledku. Cesta popsaná výše se mi osvědčila, jednoduše protože funguje dle očekávání.