Hogyan különböztessük meg az útválasztási hurkot az útvonal-rebegéstől VPN-helyeken
Az útválasztási hurok és a rebegő útvonal ugyanazt a szakaszos veszteséget okozza. Három ellenőrzés az átjárókon megkülönbözteti őket, mielőtt bármit megváltoztatna.
Két helyszín, egy alagút és egy távoli előtag, amely egy ideig válaszol, aztán elhallgat. A reflex az, hogy útválasztási huroknak nevezzük, és néha pontosan az. De a hurok és a rebegő útvonal ugyanazt a panaszt kelti, és ellentétes javítást igényel: az egyik egy soha le nem záruló továbbítási döntés, a másik egy előtag, amely folyton elhagyja a táblát. Három megfigyelés választja szét őket, és mindhármat begyűjtheti az átjáró parancssorából, mielőtt szűrőhöz nyúlna vagy újraindítana egy alagutat.
A hurok ugrásról ugrásra dől el. Az A helyszín B-t választja következő ugrásként a célhoz, a B az A-t választja ugyanahhoz a célhoz, és a csomag két oda-vissza után lejár a TTL-en. A rebegést viszont az útválasztási protokoll dönti el: az előtag visszavonásra, újratelepítésre vagy alternatív következő ugrásra cserélődik, így egyes csomagoknak egyáltalán nincs útvonaluk, míg mások teljesen jó útvonalat követnek.
A három ellenőrzés, amely eldönti a kérdést
Az első döntéshez nem kell csomagrögzítés. Az előtag állapotára van szüksége mindkét végén, az egyes oldalak által választott következő ugrásra, és egy ugrásszámra, amely vagy ismétlődik, vagy nem. Ha az előtag ugyanazzal a következő ugrással telepítve marad, miközben a forgalom meghibásodik, a hurok a továbbítási útvonalban él. Ha az előtag eltűnik és visszatér, a hiba a továbbítás felett van, és a javítás az útválasztási protokollhoz tartozik, nem egy statikus útvonalhoz.
| 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 |
Egy figyelmeztetés a kezdés előtt. Ha ezt azon az alagúton keresztül olvassa, amelyik hurkol, a munkamenete abban a pillanatban meghal, amikor megváltoztatja az útvonalat. Nyisson konzolt vagy olyan felügyeleti útvonalat, amely nem függ az előtagtól, amelyet javítani készül.
Első ellenőrzés: stabil-e az előtag, vagy kavarog
Kérdezze meg a kerneltől, mit telepített, ne azt, amit a konfigurációs fájl ígér. Linux átjárón a ip route get 10.20.30.40 ugyanazt a keresést futtatja, mint a továbbítási útvonal, a házirend-táblákkal együtt, míg a ip route show 10.20.30.0/24 magát a bejegyzést mutatja. A ip monitor route minden változást a bekövetkezés pillanatában közvetít, ami a leggyorsabb módja annak, hogy egy előtag érkezését és távozását lássa.
FRR-t vagy BIRD-öt futtató routeren nem a továbbítási tábla az érdekes. A show ip bgp 10.20.30.0/24 visszaadja a kiválasztott útvonalat és annak futási idejét; a néhány percenként visszaálló futási idő olyan rebegés, amelyet megnevezhet, nem hurok. A show ip bgp summary a szomszédok állapotát és az előtagszámokat mutatja, így egy folyton eleső partner leveszi a hibát a továbbítási útvonalról.
Írja le a választ, mielőtt bármit megváltoztat. Tíz percig stabil, miközben a pingek meghiúsultak, és tíz perc alatt négyszer eltűnt, különböző következő lépésekhez vezet. A második eset irrelevánssá tesz minden statikus útvonalról szóló elméletet.
Második ellenőrzés: visszamutat-e a következő ugrás az érkezési alagútba
A hurokhoz két átjáró egyetértése kell. A csomagot fogadó helyszínen nézze meg azt az útvonalat, amelyet a csomag a kilépéshez használni fog: ip route get 10.20.30.40 from 10.10.5.20 a valódi forrás címmel, mert egy házirend-szabály másként válaszolhat, mint a fő tábla. Ezután ismételje meg a keresést azon a helyszínen, amely elküldte. Ha mindkét oldal a másikat választja következő ugrásként ugyanahhoz az előtaghoz, a hurok bizonyított, és egyetlen rögzítés sem tesz hozzá semmit.
Az ok szinte mindig egy hirdetmény, amelynek nem kellett volna átlépnie az alagutat. Az alagútba újraosztott alapértelmezett útvonal, a távoli helyszín saját alhálózatát lefedő összevonás, vagy az óvatosságból a partnerre mutató statikus útvonal mind ugyanazt a kölcsönös következő ugrást hozza létre. Az alagút teljesen felépülhet, és mégis körben viheti a forgalmat; a strongSwan továbbítási megjegyzései leírják ennek a követelménynek az útválasztási oldalát.
A WireGuard saját megjegyzést érdemel, mert nincs hirdetmény, amelyet hibáztathatnánk. A wg show felsorolja az egyes partnerek AllowedIPs-bejegyzéseit, és a kernel csak akkor fogad el egy célt egy partnerhez, ha az ebbe a tartományba esik. A hurok ott egy átfedő AllowedIPs-tartomány vagy az interfészen át visszamutató statikus útvonal, tehát a javítás csak ezen a két helyen él.
Harmadik ellenőrzés: az ugrásszámot olvassa, ne a csillagokat
A traceroute -n -I 10.20.30.40 és a mtr -n -r -c 20 10.20.30.40 is mutatja az útvonalat, és az ICMP-mód gyakran túléli azt a szűrést, amely megeszi az UDP-szondákat. A hurok úgy néz ki, mint ugyanazon két átjárócím rövid, ismétlődő sorozata, a TTL minden alkalommal emelkedik. A kiesés úgy néz ki, mint csillagok az utolsó válaszoló átjáró után, és egyetlen csendes ugrás semmire sem bizonyíték.
Amikor az útvonal kétértelmű, olvassa le a TTL-t a vezetéken. A tcpdump -ni any -vv icmp mindkét átjárón megmutatja az egyes csomagok TTL-jét és minden időtúllépési válasz forráscímét. Ha egy csomag alacsonyabb TTL-lel érkezik a távoli helyszínre, mint amennyi ugrás az útvonalban lehet, valami olyan ugrásokat ad hozzá, amelyeket a traceroute nem mutat meg, és ez akkor történik, amikor az egyik helyszín tűzfala a másik nevében válaszol a szondákra.
Javítsa az előtag tulajdonosát, majd ellenőrizze mindkét irányt
Döntse el, melyik helyszín hozza létre a célt, és mely tranzitútvonalak engedélyezettek, majd változtassa meg a hirdetményt vagy a statikus útvonalat annál a tulajdonosnál. A fogadó helyszín javítása csábító és általában helytelen: elrejti a hurkot egy előtag számára, és a rossz hirdetményt a következő számára hagyja a helyén. Az útvonalcímkék, a terjesztési listák és a split-horizon szabályok azért léteznek, hogy ezt a forrásnál állítsák meg, és olcsóbbak, mint egy szűrő, amely egyetlen előtagra illeszkedik.
A változtatás után külön ellenőrizze az oda- és a visszairányt, mert a hurok helyére fekete lyuk kerülhet anélkül, hogy a tünet láthatóan javulna. Futtassa a ip route get mindkét végéről, küldjön forgalmat olyan gazdagépről, amely nem az átjáró, és hagyja a ip monitor route legalább egy tartási időzítőig futni, hogy a rebegést ne nézzék javításnak.
Mielőtt bármit megváltoztat, erősítse meg ezt az öt pontot: az előtag stabil vagy kavarog, a következő ugrás mindkét végén alagútra mutat, az ugrásszám ismétlődik-e vagy sem, egyetlen helyszín birtokolja az előtagot, és van olyan felügyeleti útvonala, amely túléli a változtatást. Ha az ötből bármelyik ismeretlen, a másik négy találgatás.