Tunnelen står, ruta er borte: skilje to VPN-feil

Éin vert blir utilgjengeleg medan tunnegrensesnittet framleis rapporterer at det er etablert, og dei to observasjonane er ikkje i konflikt. Noko fjerna vegen trafikken brukte: ein nabo trekte tilbake prefikset sitt, ei overvaka statisk rute vart fjerna, eller ei anna rute vart føretrekt. Tryggingsassosiasjonen kan halde fram med å vere heilt sunn gjennom alle tre. Å skilje hendingane tyder å spørje kva lag som endra seg fyrst, ikkje om VPN-en feila.

Tre trinn som ser ut som éi hending

Ei rutingsavgjerd har tre trinn. Prefikset blir motteke, valt som det beste og installert i vidaresendingstabellen. Kvart trinn kan feile åleine, og feilen ser identisk ut frå applikasjonssida. Eit prefiks som vart lært, men tapte utveljinga, kan ikkje skiljast frå eit som aldri kom fram når det einaste beviset du ser på er vidaresendingstabellen.

Difor er det fyrste spørsmålet kva trinn som braut saman, ikkje kva protokoll som har skulda. Svaret avgjer kven som eig hendinga og kva verktøy neste sjekk brukar.

Les den installerte ruta fyrst

Spør kjernen kvar trafikken til den feilande destinasjonen faktisk går. ip route get skriv ut neste hopp, grensesnittet og kjeldeadressa kjernen ville brukt, og han svarar for éin destinasjon i staden for heile tabellen. Viss svaret nemner tunnelen, trur vidaresendingstabellen framleis at vegen finst, og problemet ligg over han.

ip route get 10.20.5.10
ip route show 10.20.0.0/16

Eit svar «unreachable» tyder at det ikkje finst noka installert rute i det heile, noko som peikar på ein tilbaketrekking eller ein manglande installasjon. Eit svar som nemner eit fysisk grensesnitt, tyder at trafikken forlét tunnelen utan at nokon bestemte det, og neste sjekk er preferansen som vann. Eit svar som nemner tunnelen medan pakkane framleis forsvinn, peikar lenger nede i vegen, på filtrering eller på den andre sida.

Sjå deretter på protokollen sitt eige bilete

Ein rutingsdaemon held meir enn éin tabell, og den interessante samanlikninga er mellom dei. For BGP er tilstanden til nabosessjonen, den mottekne annonseringa og den installerte ruta tre separate bevis. Eit prefiks kan sitje i den mottekne tabellen og aldri nå kjernen fordi ei rute med kortare administrativ avstand vinn. Sjekk alle tre før du konkluderer med at den andre sida slutta å annonsere.

vtysh -c "show bgp summary"
vtysh -c "show bgp ipv4 unicast 10.20.0.0/16"

Samandraget fortel om sesjonen er etablert, visninga per prefiks fortel om prefikset vart godteke, og kjernesøket fortel om det vart installert. Å lese dei i den rekkjefølgja hindrar at ein sesjon som blafrar blir forveksla med ein tilbaketrekking, og ein tilbaketrekking med ei avvising på grunn av policy.

Når klokkene er usamde

Set tunnel-loggen, ruting-loggen og den fyrste applikasjonsfeilen på éi tidslinje ved hjelp av dei verkelege tidssonene deira. Viss nabotapet kjem fyrst, tok tunnelen ruta ned med seg. Viss tilbaketrekkinga kjem fyrst, endra rutinga seg, og tunnelen reagerte etterpå. Det er ulike hendingar med ulike eigarar, og rekkjefølgja er heile funnet.

Eitt minutt med klokkeforskjell er nok til å snu den konklusjonen, så stadfest tidssona og forskyvinga før du stolar på rekkjefølgja. Einingar som loggar i lokal tid utan forskyving er den vanlege kjelda til ei sjølvsikker, men feil tidslinje.

Gjenoppretting utan løkke

To vegar kan vere kvalifiserte etter ein tilbaketrekking: den protokollen vel, og den du festar for hand. Berre den fyrste er ei avgjerd nettverket held fram med å ta for deg, og difor er ei manuell rute ei naudløysing framfor ein gjenopprettingsplan. Ei alternativ annonsering bevarer heller ikkje brannmur- eller NAT-tilstand for ein sesjon som alt er etablert, så nye flytar kan verke medan den opphavlege blir verande broten. Stadfest kva reserve som skal bli aktiv, og om det eksterne staden vil godta ein returveg gjennom han.

Ikkje installer ei permanent statisk overstyring før du forstår kvifor tilbaketrekkinga skjedde. Den snarvegen kan feste trafikken til ein feila veg eller stille omgå ein medviten rutingspolicy, og han grev ned den opphavlege årsaka under ein ny konfigurasjon. Test applikasjonen på nytt når ruta er gjenoppretta, og stadfest at det valde prefikset har ein verkeleg dataveg og ikkje berre ein oppføring i ein tabell.