Ako rozlíšiť smerovaciu slučku od trepotania trasy na VPN lokalitách
Smerovacia slučka a trepotajúca sa trasa spôsobujú rovnakú prerušovanú stratu. Tri kontroly na bránach ich rozlíšia skôr, než čokoľvek zmeníte.
Dve lokality, jeden tunel a vzdialený prefix, ktorý chvíľu odpovedá a potom stíchne. Reflex je nazvať to smerovacou slučkou, a niekedy to tak presne je. Ale slučka a trepotajúca sa trasa dávajú rovnakú sťažnosť a potrebujú opačné opravy: jedna je rozhodnutie o preposielaní, ktoré sa nikdy nekončí, druhá je prefix, ktorý stále opúšťa tabuľku. Tri pozorovania ich oddeľujú, a všetky tri môžete zozbierať z príkazového riadka brány, skôr než sa dotknete filtra alebo reštartujete tunel.
Slučka sa rozhoduje skok za skokom. Lokalita A zvolí B ako ďalší skok k cieľu, B zvolí A pre ten istý cieľ, a paket vyprší na TTL po dvoch cestách tam a späť. Trepotanie naopak rozhoduje smerovací protokol: prefix sa stiahne, znova nainštaluje alebo nahradí alternatívnym ďalším skokom, takže niektoré pakety nemajú žiadnu trasu, zatiaľ čo iné idú po úplne dobrej.
Tri kontroly, ktoré otázku vyriešia
Na prvé rozhodnutie nepotrebujete zachytávanie paketov. Potrebujete stav prefixu na oboch koncoch, ďalší skok, ktorý volí každá strana, a počet skokov, ktorý sa buď opakuje, alebo nie. Ak prefix zostáva nainštalovaný s tým istým ďalším skokom, kým prevádzka zlyháva, slučka žije v preposielacej ceste. Ak prefix zmizne a vráti sa, porucha je nad preposielaním a oprava patrí smerovaciemu protokolu, nie statickej trase.
| Observation | Routing loop | Route flapping |
|---|---|---|
| Prefix in the table | Installed, same next hop throughout | Withdrawn and reinstalled, or next hop alternates |
| Hop count | Reaches zero at the same two gateways | Expires only while the prefix is missing |
| Failure shape | Consistent loss for that prefix from every source | Bursts, often after a link or peer event |
| Where the fix belongs | The site that owns the prefix, plus filters on the transit path | Advertisement, hold timers, or the flapping link |
Jedno varovanie pred začiatkom. Ak to čítate cez tunel, ktorý robí slučku, vaša relácia zomrie v okamihu, keď zmeníte trasu. Otvorte konzolu alebo cestu správy, ktorá nezávisí od prefixu, ktorý sa chystáte opraviť.
Kontrola prvá: je prefix stabilný, alebo sa búri
Pýtajte sa jadra, čo nainštalovalo, nie čo sľubuje konfiguračný súbor. Na linuxovej bráne ip route get 10.20.30.40 vykonáva to isté vyhľadanie ako preposielacia cesta, vrátane tabuliek pravidiel, zatiaľ čo ip route show 10.20.30.0/24 zobrazuje samotný záznam. ip monitor route prenáša každú zmenu v okamihu jej vzniku, čo je najrýchlejší spôsob, ako sledovať prefix prichádzať a odchádzať.
Na routeri s FRR alebo BIRD nie je zaujímavá preposielacia tabuľka. show ip bgp 10.20.30.0/24 vracia zvolenú cestu a jej dobu behu; doba behu, ktorá sa resetuje každých pár minút, je trepotanie, ktoré môžete pomenovať, nie slučka. show ip bgp summary zobrazuje stav susedov a počty prefixov, takže sused, ktorý stále padá, sníma vinu z preposielacej cesty.
Zapíšte odpoveď, skôr než čokoľvek zmeníte. Stabilita desať minút, kým pingy zlyhávali, a zmiznutie štyrikrát za desať minút vedú k rôznym ďalším krokom. Druhý prípad robí každú teóriu statickej trasy irelevantnou.
Kontrola druhá: ukazuje ďalší skok späť do tunela príchodu
Slučka potrebuje zhodu dvoch brán. Na lokalite, ktorá paket prijíma, pozrite sa na trasu, ktorú paket použije na odchod: ip route get 10.20.30.40 from 10.10.5.20 so skutočnou zdrojovou adresou, pretože pravidlo politiky môže odpovedať inak ako hlavná tabuľka. Potom zopakujte vyhľadanie na lokalite, ktorá ho odoslala. Ak každá strana volí tú druhú ako ďalší skok pre ten istý prefix, slučka je dokázaná a žiadne zachytenie nič nepridá.
Príčinou je takmer vždy oznámenie, ktoré nemalo prejsť tunelom. Predvolená trasa redistribuovaná do tunela, agregát pokrývajúci vlastnú podsieť vzdialenej lokality alebo statická trasa na partnera pre istotu vytvárajú všetky ten istý vzájomný ďalší skok. Tunel môže byť plne zavedený a napriek tomu viesť prevádzku v kruhu; poznámky k preposielaniu strongSwan opisujú smerovaciu stránku tejto požiadavky.
WireGuard si zaslúži vlastnú poznámku, pretože niet oznámenia, ktoré by nieslo vinu. wg show vypisuje AllowedIPs pre každého partnera, a jadro prijme cieľ pre partnera len vtedy, keď spadá do tohto rozsahu. Slučka je tam prekrývajúci sa rozsah AllowedIPs alebo statická trasa ukazujúca späť cez rozhranie, takže oprava žije na tých dvoch miestach a nikde inde.
Kontrola tretia: čítajte počet skokov, nie hviezdičky
traceroute -n -I 10.20.30.40 aj mtr -n -r -c 20 10.20.30.40 ukazujú cestu a režim ICMP často prežije filtrovanie, ktoré požiera UDP sondy. Slučka vyzerá ako krátka opakujúca sa postupnosť tých istých dvoch adries brán, pričom TTL zakaždým stúpa. Výpadok vyzerá ako hviezdičky za poslednou bránou, ktorá odpovedala, a jeden tichý skok nie je dôkazom ničoho.
Keď je cesta nejednoznačná, čítajte TTL na drôte. tcpdump -ni any -vv icmp na oboch bránach ukazuje TTL každého paketu a zdrojovú adresu každej odpovede o prekročení času. Ak paket dorazí na vzdialenú lokalitu s TTL nižším, než je počet skokov, ktoré cesta môže obsahovať, niečo pridáva skoky, ktoré vám traceroute neukazuje, a to sa stáva, keď firewall jednej lokality odpovedá na sondy v mene druhej.
Opravte vlastníka prefixu a potom overte oba smery
Rozhodnite, ktorá lokalita cieľ vytvára a ktoré tranzitné cesty sú povolené, a potom zmeňte oznámenie alebo statickú trasu u toho vlastníka. Opravovať prijímajúcu lokalitu je lákavé a zvyčajne nesprávne: skryje slučku pre jeden prefix a nechá zlé oznámenie na mieste pre ten ďalší. Značky trás, distribučné zoznamy a pravidlá split-horizon existujú, aby to zastavili pri zdroji, a sú lacnejšie než filter zodpovedajúci jednému prefixu.
Po zmene overte zvlášť cestu tam a späť, pretože slučka môže byť nahradená čiernou dierou bez viditeľného zlepšenia príznaku. Spustite ip route get z oboch koncov, pošlite prevádzku z hostiteľa, ktorý nie je bránou, a nechajte ip monitor route bežať aspoň jeden časovač podržania, aby sa trepotanie nepomýlilo s opravou.
Skôr než čokoľvek zmeníte, potvrďte týchto päť bodov: prefix je stabilný alebo sa búri, ďalší skok na oboch koncoch ukazuje na tunel, počet skokov sa opakuje alebo nie, jedna lokalita vlastní prefix a máte cestu správy, ktorá zmenu prežije. Ak je ktorýkoľvek z piatich neznámy, ostatné štyri sú dohady.