BGP heeft het prefix geleerd, maar verkeer omzeilt de tunnel nog steeds

De branchgateway toont het cloudprefix in zijn BGP-tabel, de sessie met de provider staat, en toch verlaat het verzoek van een gebruiker naar dat prefix de verkeerde interface. Niets is kapot op de manier die de monitoring suggereert, want “BGP heeft het geleerd” is een uitspraak over het besturingsvlak. Tussen die tabel en het pakket zitten vier afzonderlijke overgangen, en de stroom stopt bij precies één ervan. Loop de poorten in volgorde langs en stop bij de eerste die faalt.

Eerste poort: wat de buur echt heeft gestuurd

Begin met het prefix zoals het is ontvangen, niet zoals het is samengevat. Zoek het exacte netwerk en masker op in de BGP-tabel en noteer de next hop, het AS-pad en elke community waar een importbeleid op kan matchen. Een samengevatte route in een dashboard kan verbergen dat het specifieke prefix nooit is geaccepteerd.

Importbeleid is de gebruikelijke plek waar een route zonder fout verdwijnt. Een prefixlijst, een communityfilter of een inkomende routemap kan de update laten vallen terwijl de sessie omhoog en gezond blijft, en daarom bewijst een groen buurlicht zo weinig. Het ontbreken van een logregel betekent niet het ontbreken van een beslissing. Meestal betekent het dat de beslissing stil is genomen, precies zoals geconfigureerd.

show ip bgp 10.60.20.0/24
show ip bgp neighbors 203.0.113.5 advertised-routes
show ip route 10.60.20.0
show ip cef 10.60.20.0

Lees de uitvoer in die volgorde. De eerste twee commando's zeggen of de informatie aankwam en wat de peer zegt dat hij stuurde; de laatste twee of iets de routing- en forwardingtabellen bereikte. Een prefix dat in het eerste commando staat en in het derde ontbreekt, is een selectie- of installatieprobleem, geen connectiviteitsprobleem.

Tweede poort: selectie, dan installatie

BGP kiest een beste pad, en het gekozen pad wordt niet automatisch geïnstalleerd. De next hop moet oplossen, en een andere routebron bezit dat prefix misschien al met een betere administratieve afstand. Een statische route die van de migratie overbleef, wint moeiteloos van een geldig BGP-pad en stuurt het verkeer ergens anders heen.

RFC 4271 houdt drie ideeën gescheiden: wat een peer stuurde, wat deze speaker als beste koos en wat hij verder zal aankondigen. Dat zijn conceptuele rollen, geen drie fysieke databases die een leverancier moet blootleggen, maar juist die scheiding maakt “hetzit in BGP” een onvolledig antwoord.

Controleer ook welke routingcontext u leest. Een route die is geïnstalleerd in een VRF waar de interface van de gebruiker niet bij hoort, is onzichtbaar voor de pakketten van die gebruiker, en de tabel ziet er de hele tijd correct uit.

Derde poort: de opzoeking die voor deze stroom geldt

Stop nu met vragen naar de route en begin naar het pakket te vragen. Noteer het bronadres van de gebruiker, de bestemming, het protocol, de poort en de inkomende interface, want elk daarvan kan een ander beleid selecteren. Kijk daarna naar de opzoeking die voor die combinatie geldt in plaats van de algemene routingtabel.

ip route get 10.60.20.25 from 10.60.10.40
ip rule show
sudo tcpdump -ni tun0 'host 10.60.20.25'

Een specifieker prefix is hier de meest voorkomende verrassing, en een policyroute de tweede. Beide overrulen het aggregat dat u bekeek, en geen van beide is zichtbaar in een samenvatting van de BGP-tabel.

Een ping vanaf de gateway zelf is geen bewijs over de sessie van een gebruiker. Ander bronadres, ander beleidspad en vaak een ander resultaat. Test met dezelfde bron die de applicatie gebruikt, of accepteer dat de test een andere vraag beantwoordt.

Vierde poort: de verre helft van het pad

Als de lokale opzoeking de tunnel inderdaad selecteert, moet het pakket nog door het beschermingsbeleid worden geaccepteerd, door de forwardingregel worden toegestaan en door iets aan de andere kant worden beantwoord. Een crypto-ACL zonder het adrespaar laat het verkeer vallen terwijl de tunnel zichzelf als omhoog rapporteert, wat een time-out oplevert die niet te onderscheiden is van een routingfout.

De terugweg is even belangrijk als de heenweg. De cloudkant moet weten hoe hij de branchbron bereikt, hetzij via een route, hetzij via een vertaling die u bewust hebt geconfigureerd. Asymmetrische terugwegen komen veel voor in ontwerpen die maar vanuit één richting zijn getest.

Correleer een verse geautoriseerde verbinding met drie waarnemingen: het lokale beleid dat matchte, de tunneltellers die bewogen en de ontvangst aan de verre kant waar dat zichtbaar is. Bewegen de tellers niet, dan is het pakket nooit de tunnel binnengegaan, wat de routetabel ook zegt. Bewegen ze wel en komt er niets aan, dan laat de verre kant het vallen of routeert het verkeerd. Die twee uitkomsten leiden naar volledig verschillende teams.

Benoem de overgang die faalde

Schrijf het resultaat als een van vijf toestanden: niet ontvangen, niet geaccepteerd door beleid, niet geselecteerd, niet geïnstalleerd of niet gematcht door deze stroom. Voeg een zesde toe voor het geval waarin het lokale pad correct is en het verre uiteinde niet kan antwoorden. Die zin is het resultaat, en die is veel nuttiger dan een schermafbeelding van een opgezette buur.

Houd ook een negatieve test in het acceptatieplan: een bestemming die de tunnel niet mag passeren, geverifieerd na de wijziging. Een checklist die alleen het gelukkige pad bewijst, vangt de brede beleidsregel niet die iemand in het volgende onderhoudsvenster toevoegt.