De tunnel staat, de route is weg: twee VPN-storingen scheiden

Eén host wordt onbereikbaar terwijl de tunnelinterface zich nog steeds als opgezet meldt, en de twee waarnemingen zijn niet in tegenspraak. Iets verwijderde het pad dat het verkeer gebruikte: een buur trok zijn prefix terug, een gevolgde statische route werd verwijderd, of een andere route werd verkozen. De beveiligingsassociatie kan in alle drie de gevallen volledig gezond blijven. De gebeurtenissen scheiden betekent vragen welke laag eerst veranderde, niet of de VPN is mislukt.

Drie fasen die op één gebeurtenis lijken

Een routeringsbeslissing heeft drie fasen. Het prefix wordt ontvangen, als beste geselecteerd en in de doorstuurtabel geïnstalleerd. Elke fase kan op zichzelf mislukken, en de storing ziet er vanuit de applicatie identiek uit. Een prefix dat is geleerd maar de selectie verloor, is niet te onderscheiden van een dat nooit aankwam wanneer het enige bewijs dat je bekijkt de doorstuurtabel is.

Daarom is de eerste vraag welke fase brak, niet welk protocol schuldig is. Het antwoord bepaalt wie de storing bezit en welk gereedschap de volgende controle gebruikt.

Lees eerst de geïnstalleerde route

Vraag de kernel waar het verkeer naar de falende bestemming werkelijk heen gaat. ip route get drukt de volgende hop, de interface en het bronadres af dat de kernel zou gebruiken, en het antwoordt voor één bestemming in plaats van voor de hele tabel. Als het antwoord de tunnel noemt, gelooft de doorstuurtabel nog dat het pad bestaat en zit het probleem erboven.

ip route get 10.20.5.10
ip route show 10.20.0.0/16

Een antwoord «unreachable» betekent dat er helemaal geen geïnstalleerde route is, wat wijst op een intrekking of een ontbrekende installatie. Een antwoord dat een fysieke interface noemt, betekent dat het verkeer de tunnel verliet zonder dat iemand dat besloot, en de volgende controle is de voorkeur die won. Een antwoord dat de tunnel noemt terwijl pakketten nog steeds verdwijnen, wijst verderop in het pad, op filtering of op de andere kant.

Kijk dan naar het eigen beeld van het protocol

Een routeringsdaemon houdt meer dan één tabel bij, en de interessante vergelijking is tussen die tabellen. Voor BGP zijn de toestand van de nabuursessie, de ontvangen aankondiging en de geïnstalleerde route drie afzonderlijke bewijzen. Een prefix kan in de ontvangen tabel staan en de kernel nooit bereiken omdat een route met een kortere administratieve afstand wint. Controleer alle drie voordat je concludeert dat de andere kant stopte met aankondigen.

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

Het overzicht vertelt of de sessie is opgezet, de weergave per prefix vertelt of het prefix is geaccepteerd, en de kernelopzoeking vertelt of het is geïnstalleerd. Ze in die volgorde lezen voorkomt dat een flikkerende sessie voor een intrekking wordt aangezien, en een intrekking voor een beleidsafwijzing.

Wanneer de klokken het oneens zijn

Zet het tunnellog, het routeringslog en de eerste applicatiestoring op één tijdlijn met hun echte tijdzones. Als het verlies van de buur eerst komt, heeft de tunnel de route meegesleurd. Als de intrekking eerst komt, veranderde de routering en reageerde de tunnel daarna. Dat zijn verschillende incidenten met verschillende eigenaren, en de volgorde is de hele bevinding.

Eén minuut klokafwijking is genoeg om die conclusie om te keren, dus bevestig de tijdzone en de offset voordat je de volgorde vertrouwt. Apparaten die in lokale tijd zonder offset loggen, zijn de gebruikelijke bron van een zelfverzekerde maar verkeerde tijdlijn.

Herstel zonder lus

Na een intrekking kunnen twee paden in aanmerking komen: het pad dat het protocol selecteert en het pad dat je met de hand vastzet. Alleen het eerste is een beslissing die het netwerk voor je blijft nemen, daarom is een handmatige route een lapmiddel en geen herstelplan. Een alternatieve aankondiging behoudt ook geen firewall- of NAT-status voor een sessie die al is opgezet, dus nieuwe stromen kunnen werken terwijl de oorspronkelijke kapot blijft. Bevestig welke back-up actief moet worden en of de externe locatie een retourpad daardoorheen accepteert.

Installeer geen permanente statische overschrijving voordat je begrijpt waarom de intrekking gebeurde. Die snelkoppeling kan verkeer aan een mislukt pad vastzetten of stilzwijgend een bewust routeringsbeleid omzeilen, en begraaft de oorspronkelijke oorzaak onder een nieuwe configuratie. Test de applicatie opnieuw zodra de route is hersteld, en bevestig dat het gekozen prefix een werkend datapad heeft en niet alleen een vermelding in een tabel.