Tunneln står kvar, rutten är borta: skilja två VPN-fel åt

En värd blir onåbar medan tunnelgränssnittet fortfarande rapporterar att det är upprättat, och de två observationerna motsäger inte varandra. Något tog bort den väg trafiken använde: en granne drog tillbaka sitt prefix, en övervakad statisk rutt togs bort, eller en annan rutt blev att föredra. Säkerhetsassociationen kan förbli helt frisk i alla tre fallen. Att skilja händelserna åt innebär att fråga vilket lager som ändrades först, inte om VPN:en misslyckades.

Tre steg som ser ut som en enda händelse

Ett routingbeslut har tre steg. Prefixet tas emot, väljs som det bästa och installeras i vidarebefordringstabellen. Varje steg kan misslyckas på egen hand, och felet ser identiskt ut från applikationssidan. Ett prefix som lärdes in men förlorade urvalet går inte att skilja från ett som aldrig kom fram när det enda beviset du tittar på är vidarebefordringstabellen.

Därför är den första frågan vilket steg som brast, inte vilket protokoll som har skulden. Svaret avgör vem som äger incidenten och vilket verktyg nästa kontroll använder.

Läs den installerade rutten först

Fråga kärnan vart trafiken till den felande destinationen faktiskt tar vägen. ip route get skriver ut nästa hopp, gränssnittet och källadressen som kärnan skulle använda, och den svarar för en destination i stället för hela tabellen. Om svaret namnger tunneln tror vidarebefordringstabellen fortfarande att vägen finns och problemet ligger ovanför.

ip route get 10.20.5.10
ip route show 10.20.0.0/16

Ett svar «unreachable» betyder att det inte finns någon installerad rutt alls, vilket pekar på en tillbakadragning eller en saknad installation. Ett svar som namnger ett fysiskt gränssnitt betyder att trafiken lämnade tunneln utan att någon beslutade det, och nästa kontroll är den preferens som vann. Ett svar som namnger tunneln medan paketen fortfarande försvinner pekar längre ned på vägen, på filtrering eller på andra sidan.

Titta sedan på protokollets egen bild

En routingdaemon håller mer än en tabell, och den intressanta jämförelsen är mellan dem. För BGP är grannsessionens tillstånd, den mottagna annonsen och den installerade rutten tre separata bevis. Ett prefix kan sitta i den mottagna tabellen och aldrig nå kärnan eftersom en rutt med kortare administrativt avstånd vinner. Kontrollera alla tre innan du drar slutsatsen att andra sidan slutade annonsera.

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

Sammanfattningen säger om sessionen är upprättad, vyn per prefix säger om prefixet accepterades, och kärnsökningen säger om det installerades. Att läsa dem i den ordningen hindrar att en fladdrande session förväxlas med en tillbakadragning, och en tillbakadragning med en avvisning på grund av policy.

När klockorna inte stämmer

Sätt tunnel-loggen, routing-loggen och det första applikationsfelet på en enda tidslinje med deras verkliga tidszoner. Om grannförlusten kommer först drog tunneln ner rutten med sig. Om tillbakadragningen kommer först ändrades routingen och tunneln reagerade efteråt. Det är olika incidenter med olika ägare, och ordningen är hela fyndet.

En minut av klockavvikelse räcker för att vända den slutsatsen, så bekräfta tidszonen och förskjutningen innan du litar på sekvensen. Enheter som loggar i lokal tid utan förskjutning är den vanliga källan till en självsäker men felaktig tidslinje.

Återställning utan loop

Efter en tillbakadragning kan två vägar vara kvalificerade: den protokollet väljer och den du fäster för hand. Bara den första är ett beslut som nätverket fortsätter att fatta för dig, och därför är en manuell rutt en nödlösning snarare än en återställningsplan. En alternativ annons bevarar inte heller brandväggens eller NAT:s tillstånd för en session som redan är upprättad, så nya flöden kan fungera medan det ursprungliga förblir trasigt. Bekräfta vilken reserv som ska bli aktiv och om den avlägsna platsen kommer att acceptera en returväg genom den.

Installera inte en permanent statisk överskuggning innan du förstår varför tillbakadragningen skedde. Den genvägen kan fästa trafiken på en misslyckad väg eller tyst kringgå en avsiktlig routingpolicy, och den begraver den ursprungliga orsaken under en ny konfiguration. Testa applikationen igen när rutten är återställd, och bekräfta att det valda prefixet har en fungerande dataväg och inte bara en post i en tabell.