Routa nepřejde do stavu linkdown/dead

Routa nepřejde do stavu linkdown/dead
« kdy: 07. 11. 2024, 11:55:01 »
Mám na linuxu staticky definované routy. Jednu síť (třeba 77.0.0.0/8) mám via 192.168.1.50 přes pobočný PC, sám tento počítač je součástí 192.168.1.3/24.

je to propojeno switchem. Pokud vypnu switch nebo kabel z toho pobočného 50 a zkusím ho (...1.3) pingnout samozřejmě dostanu ICMP host unreachable.  a do této sítě se samozřejmě nedostanu (v případě default ani na internet)

Proč ale se toto nepropíše  (automaticky, klidně po nějakém zpoždění kvůli arp třeba) do ip route show na routeru?
Očekávám, že routy označené (vypsané, ne nastavené) s příznakem dead, deadlink, linkdown, linkinpark, deadcat, down (existuje opravdu vše, pátral jsem po rozdílu mezi nimi, linkdown je když manuálně vypnu interface) se nepoužijí a v tom případě použije routa s nižší metrikou. To je možné důležité, protože na tu síť se jde dostat i jinou routou, třeba i default routou.

Je nějaký mechanismus u statického routingu, že když mám 77/8 nebo default  via 192.168.0.50  a ten "via host" bude unreachable, že taková routa se prohlásí za dead nebo down a automaticky se přeskočí, aniž by se musela mazat z route tabulky? na multihop route jsem  se ptal a nedostal doporučení na tento účel. Myslel jsem, že v tomhle je linux chytrý, že pokud je nexthop unreachable, (a ping hlásí na tohoto hosta host unreachable), že takový routa bude očerněna.
Jenže ip route  vypisuje vše jako kdyby se nic nedělo


a existuje utilita ip sla?  Je něco z utilit ip *, co mi může pomoc v tomhle?
chová se default route v něčem jinak ?
« Poslední změna: 07. 11. 2024, 11:59:04 od mikesznovu »


jjrsk

  • *****
  • 603
    • Zobrazit profil
Re:Routa nepřejde do stavu linkdown/dead
« Odpověď #1 kdy: 07. 11. 2024, 12:16:59 »
A jak bys asi tak cekal, ze router zjisti, ze routa je nedostupna?

On to nema jak zjistit, na to potrebujes dynamicky routing.

Re:Routa nepřejde do stavu linkdown/dead
« Odpověď #2 kdy: 07. 11. 2024, 12:52:43 »
Jestli bez náčrtku správně chápu tazatele, jde mu o to, že linux se snaží používat next-hop, figurující v kernelové routovací tabulce, přestože minimálně v ARP tabulce nemá pro tento next-hop ARP záznam (protože mít nemůže, protože někde L2 cestou zvadla konektivita). Já dodám, že se to tak chová zřejmě by default i v případě, že padnul dokonce L2 link na daném rozhraní, kde je "locally connected subnet" obsahující next hop. To sledování linku se tuším dá nějak ošetřit... každopádně za mě: dal bych na oba stroje Quaggu/frrouting, jakožto známku punku BGP s krátkým keepalive, a ať se hoši dohodnou...

timers bgp 4 17

BGP je sice nominálně exterior routing protocol, ale má tu příjemnou vlastnost, že nepotřebuje vidět pád linku, aby zareagoval - očuchá si konektivitu na své úrovni těmi keepalive zprávami. Na rozdíl od spousty IGP.

jjrsk

  • *****
  • 603
    • Zobrazit profil
Re:Routa nepřejde do stavu linkdown/dead
« Odpověď #3 kdy: 07. 11. 2024, 17:40:47 »
Prave na pady linek je mnohem lepsi ospf protoze reaguje mnohem rychlejs nez bgp. Ve velkym netu se to nepouziva proto, ze to ma tu vlastnost, ze to potrebuje znat stav vsech linek.

A ano, ten stroj jakoze "vi" ze link je down, ale staticka routa = do nejake tabulky je napsano ze patety se maji posilat nekam. Tecka. On se neumi rozhodnout, ze je znicehoz nic ma posilat jinam.

Ostatne routovaci demoni nedelaji nic jinyho nez ze na zakladne nejakych vnejsich informaci do te tabulky zasahuji. A v principu se to co tazatel chce da realizovat scriptem v cronu ... jen to bude "fungovat" presne podle toho.

Re:Routa nepřejde do stavu linkdown/dead
« Odpověď #4 kdy: 07. 11. 2024, 21:58:24 »
OSPF reaguje okamžitě v případě, že samotnému routeru padne link na fyzickém portu. V tom případě je OSPF naprosto skvělé.
Pokud jsou ale mezi dvěma routery např. dva switche, a padne spoj mezi těmi switchi, tak oběma těm routerům fyzický link zůstane nahoře. A OSPF dlouho dál tvrdošíjně routuje pakety tou mrtvou cestou.

Třeba "bonding driver" v linuxu má option zvanou "miimon", pomocí které ho lze nakonfigurovat, aby si hlídal link state a pro své potřeby se jím řídil - což může dělat pomocí MII ioctl(), ethtool ioctl(), nebo voláním netif_carrier_ok() což je default. (Funkce netif_carrier_ok() žije v kernelu, což není problém, protože bonding driver žije tamtéž.) Ale bonding driver si podle toho řídí jenom svoje vlastní failovery, routovací tabulku/rozhodování to podle všeho neovlivňuje.

Zkusil jsem se zběžně podívat pod kapotu, která oblast ve zdrojácích kernelu se routingu konkrétně týká. Teda spíš jsem se rozhlédl po webu, jestli o tom někdo nesepsal hezké povídání pro lenocha jako jsem já :-)
Tady je docela dobrý začátek, je tam zmíněno pár relevantních funkcí, zejm. fib_lookup() resp. fib_table_lookup().
Odtud vede odkaz na moc pěkný webík, kde jsou hezky v kostce popsány stromové struktury, ve kterých je v kernelu udržována routovací tabulka (FIB, Forwarding Information Base).
Na tomto webíku je zmínka o objektu struct fib_info což vypadá jako jeden záznam v routovací tabulce.
Ten se dále odkazuje na struct fib_nh (= Next Hop) a jeho prostřednictvím na struct fib_nh_common - který už obsahuje pointer na struct net_device, kde by se asi dalo doptat na okamžitý stav rozhraní (zda je "running").

Zarazil jsem se zhruba ve chvíli, kdy bych měl začít zkoumat vnitřnosti funkce fib_table_lookup(). To by bylo vážně na delší ponor. Dovolím si shrnout dojmy:

Routovací tabulka je v kernelu uskladněna v pokročilé stromové struktuře, která je vtipně interně komprimována dvěma způsoby: "path-compressed" a "level-compressed". Zmíněná datová struktura a vyhledávací funkce jsou optimalizovány na rychlost vyhledávání (procházení stromem). Zmíněný webík z roku 2017 tvrdí, že tehdejší plná routovací tabulka vytvoří strom o maximální hloubce 6 nebo 7 uzlů a (maximální? mediánová?) latence procházení je asi 50 ns, na vcelku běžném Haswell CPU.
V datových strukturách jsem si při letmém čenichání nevšiml nějaké informace o "stavu next-hopu", podle které by bylo možno "routovací záznamy náležející zhaslému rozhraní" při prohledávání ignorovat / přeskakovat nebo tak něco. Teoreticky by se dalo, doskákat několik dalších pointer indirections a zkontrolovat to přímo na síťovém rozhraní (struct net_device). Nebo by "něco" muselo cyklicky procházet FIB strom a cinkat jednotlivé záznamy (fib_info), které mají zrovna down příslušný next_hop interface. Není mi bez dalšího dumání jasné, nakolik by zaplevelení FIB takovými "potlačenými" záznamy zkomplikovalo vyhledávání živého next_hopu (procházení stromem). Ale v zásadě: vzhledem k důrazu na co nejefektivnější vyhledávání v tabulce (stromě) mi dává smysl, že se toto prostě nedělá. Ne per packet. Beru to jako zralé návrhové rozhodnutí. Znamenalo by to latenci navíc, a zátěž CPU.

Ještě by se dalo uvažovat, že v kernelu bude FIB "dvouúrovňová": horní "managementová" úroveň by držela všechny záznamy, a byla by nějak cyklicky "zrcadlena" do spodní "provozní" FIB tabulky, ze které by byly vyplety "potlačené" routovací záznamy. Hm. I tady zcela chápu, že se správcům nechtělo udržovat takovou složitost přímo v kernelu, když totéž a mnoho dalšího snadno zařídí dedicated routing daemon žijící v user space. Prostě "keep it simple". Čím víc o tom přemejšlím, tím víc maintainery chápu.

OT: Cestou jsem narazil na zajímavou stránku Interactive Linux Kernel Map - která mi připadá zábavná, přestože konkrétně výše zmíněnou oblast cudně zamlčuje :-) Tzn. ten hezký barevný pavouk nebude zdaleka úplný...


Re:Routa nepřejde do stavu linkdown/dead
« Odpověď #5 kdy: 08. 11. 2024, 07:57:10 »
OSPF reaguje okamžitě v případě, že samotnému routeru padne link na fyzickém portu. V tom případě je OSPF naprosto skvělé.
Pokud jsou ale mezi dvěma routery např. dva switche, a padne spoj mezi těmi switchi, tak oběma těm routerům fyzický link zůstane nahoře. A OSPF dlouho dál tvrdošíjně routuje pakety tou mrtvou cestou.

Toto není pravda a doporučuji si to nastudovat. OSPF stojí na výměně informací přes libovolně rozsáhlou L2 pomocí multicastu a routovací tabulku hosta mění při výpadku nebo ustanovení sousedství mezi routery a né při změně linku na síťovce. Standardně se sousedství kontroluje každých 10 s, ale běžně se používají i 2 s.

jjrsk

  • *****
  • 603
    • Zobrazit profil
Re:Routa nepřejde do stavu linkdown/dead
« Odpověď #6 kdy: 08. 11. 2024, 08:15:50 »
Ve skutecnosti to je jeste trochu jinak, on totiz kazfy clen toho ospf gridu posle aktivne informaci kdyz se neco zmeni, takze ne az za nastaveny interval. Tudiz se vsechny dosazitelne nody prakticky obratem dozvi, ze doslo k nejake zmene, coz mimochodem nemusi byt jen vypadek, muze jit treba i o vyssi zatizeni dotcene linky a tudiz zmenu jeji ceny.

A protoze sem par let par desitek nodu provozoval, tak vim ze to funguje vazne instatne. Zadny tvrdosijny posilani dat do mrtveho spoje se nedeje.

Muze to mit za nejakych okolnosti ten neduh, ze routovani velmi rychle flapuje. Videl sem i v desitkach zmen za sekundu.


Re:Routa nepřejde do stavu linkdown/dead
« Odpověď #7 kdy: 08. 11. 2024, 09:09:52 »
Musím přiznat, že moje zkušenosti jsou sporadické v průběhu mnoha let.

Vím jak se to chovalo na přelomu století napříč republikou na Ciscu (dial-up access pole). Tam byla výborná ta vlastnost, že se připojil klient, dostal adresu nebo klidně celý blok, tzn. na access routeru se objevil route, a vmžiku o něm věděla celá páteř. A bylo jedno, kde po republice se klient připojil, prostě tam ten svůj route koupil a síť se o tom okamžitě dozvěděla. Díky tomu nebylo potřeba si adresní příděl (LIR) napříč republikou nějak hierarchicky binárně parcelovat. Ale jak už jsem psal - když někde tiše zmizela konektivita, trvalo delší dobu, než si toho routery všimly a zafungovala topologická redundance OSPF. Podrobnosti neznám, ani jsem to tehdy neměl ve správě, koukal jsem na to zvenčí jako elév. Netuším co na tom tehdy bylo ke konfiguraci a jak to konkrétně bylo nakonfigurované - ale lidi co se o to starali věděli co dělají.

Pak jsem v nějakém rozestupu asi dvakrát zkoušel OSPF nad VPN tunýlkama. OpenVPN + Zebra/Quagga. Redundantní trasy, hrozně jednoduchá topologie, kapacity všude dostatek. No a když jsem tomu naschvál "trhal nožičky", tak OSPF se chovalo dle mého očekávání: pokud nepadl lokální link, tak si ničeho nevšímalo. K topologické rekonvergenci nedošlo a data netekla. BGP reagovalo tak rychle, jaký jsem nastavil keepalive.

Měl jsem za to, že tohle chování OSPF je projevem jeho "link state" přirozenosti. Ale taky to může znamenat, že jsem/byl jenom lama :-) A pokud se chytím toho, co psal @FactChecker, že to jede multicastem... vemte si, jak to dopadne, když tenhle rychlý multicastem šířený update někomu ze "sousedů" nedorazí. Třeba kvůli takové blbosti, že byla vytížená linka = nemusí být zrovna "tiše padlá".  Jasně na Ethernetu v redundantní LAN se tohle třeba neděje, ale na WAN trasách to kdysi bejval docela denní chleba. Netvrdím, že na páteři je takový stav zdravý, a že byl v našem případě trvalý a nikdo to neřešil...

Každopádně jsem se teď rychlým googlem dočetl, že OSPF skutečně neposílá dokola kompletní routovací tabulku, ale "OSPF refreshes Link State Advertisements every 30 minutes" na základě nějaké konečné životnosti... což je zhruba ten horizont reakce co si matně vybavuju. Když si to dám dohromady s existencí hello timeru a dead timeru (které řeší viditelnost sousedů), tak mi z toho jako blbá situace vychází následující:
- podle hello timeru a dead timeru se sousedi vidí
- pokud se v takové situaci sem tam ztratí "bleskový update" (oznámení nějaké topologické změny) tak to může znamenat nekonvergenci (půl hodiny výpadek)

Což je jiný scénář, než jsem prve naznačoval :->

Re:Routa nepřejde do stavu linkdown/dead
« Odpověď #8 kdy: 08. 11. 2024, 09:29:55 »
Koukám Cisco default je hello 10, dead 40. Pravděpodobně jsem prostě nebyl tak trpělivý :-) a vyvodil ukvapený závěr.

M_D

  • ****
  • 348
    • Zobrazit profil
    • E-mail
Re:Routa nepřejde do stavu linkdown/dead
« Odpověď #9 kdy: 08. 11. 2024, 10:29:02 »
K tazateli - ano, routovací tabulka v kernelu si sama nesleduje stav a nevyhazuje mrtvé routy. To musí dělat něco nad tím, takže pokud chci používat statické routy, tak ten skript v crontabu je cesta. A fakticky používá podobnou strategii řada routerů, kdy se používají jen statikcé routy a k nim se nastaví nějaký "tracking object" a dle jeho stavu se routa zne/platňuje, což obvykle je nějaký arp check, icmp ping, link up/down, BFD nebo logická operace nad tím.

U OSPF je 10/40 s default hodnoty. Pokud 40 sec neslyším protistranu, tak je linka prohlášena za kaput a změna topologie. Data se posílají při změně (plus refreshe dat po celkem dlouhých intervalech). Obvykle je i to hlídání toho port down eventu, takže na tvrdé odpadnutí se reaguje hned.

Jinak pro rychlou detekci, že linka je opravdu kaput, tak na to tu máme dneska BFD protokol (RFC5880 a dál) a celá řada routerů ho podporuje. To je na rekaci na mikro/milisekundové bázi, kde se testuje buď next hop (obvykle pro RIP/OSPF/L2 trunk/...) nebo i multihop (např pro BGP, VPLS, ...). Myšlenka je, že mám jeden mechanismus detekce výpadku linky a na jeho stav reaguje X protokolů nad tím, bez nutnosti ty protokoly nutit nějak urychlovat své vlastní pomalé "dead, hold, ..." timeouty. Dneska i na L2 na to umí reagovat propoje mezi switchi v trunkách atd...

Re:Routa nepřejde do stavu linkdown/dead
« Odpověď #10 kdy: 08. 11. 2024, 10:42:43 »
Koukám Cisco default je hello 10, dead 40. Pravděpodobně jsem prostě nebyl tak trpělivý :-) a vyvodil ukvapený závěr.

Pro OSPF existuje rozšíření BFD [RFC 5881] které stahuje čas detekce mrtvé linky na cca 1s (pingy po 0.2 sec, po 5 bez odpovedi dochází k přepočtu). RouterOS/Mikrotiku to má od verze 6.44

M_D

  • ****
  • 348
    • Zobrazit profil
    • E-mail
Re:Routa nepřejde do stavu linkdown/dead
« Odpověď #11 kdy: 08. 11. 2024, 11:58:31 »
neregistrovany: BFD není rozšíření OSPF, je to dost samostatný framwork, kdy použití s OSPF je jedna z aplikací. Tady je pár oslavných slajdů v PDF, co vše je s tím zamýšleno řešit: https://web.archive.org/web/20051104185353/https://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-eof-bfd.pdf

Re:Routa nepřejde do stavu linkdown/dead
« Odpověď #12 kdy: 08. 11. 2024, 12:11:22 »
Na ciscu bych použil udld, neni odpověď, shodím interfejs, ospf si toho všimne hned ... ?

M_D

  • ****
  • 348
    • Zobrazit profil
    • E-mail
Re:Routa nepřejde do stavu linkdown/dead
« Odpověď #13 kdy: 08. 11. 2024, 15:09:49 »
mensina: Ano, UDLD je na Cisco bednách možnost. Sice má trochu jiný účel, ale na bod-bod lince má efekt podobný tomu obecnějšímu BFD.

Re:Routa nepřejde do stavu linkdown/dead
« Odpověď #14 kdy: 08. 11. 2024, 15:38:04 »
neregistrovany: BFD není rozšíření OSPF, je to dost samostatný framwork, kdy použití s OSPF je jedna z aplikací.

Máte pravdu, blbě jsem to napsal