BGP lärde sig prefixet, men trafiken går fortfarande förbi tunneln

Filialens gateway visar molnets prefix i sin BGP-tabell, sessionen mot leverantören är uppe, och ändå lämnar en användares begäran till prefixet via fel gränssnitt. Inget är trasigt på det sätt övervakningen antyder, eftersom “BGP lärde sig det” är ett påstående om kontrollplanet. Mellan tabellen och paketet finns fyra separata övergångar, och flödet stannar vid exakt en av dem. Gå igenom portarna i ordning och stanna vid den första som fallerar.

Första porten: vad grannen faktiskt skickade

Börja med prefixet så som det togs emot, inte sammanfattat. Slå upp det exakta nätet och masken i BGP-tabellen och notera nästa hopp, AS-vägen och eventuella communities som en importpolicy kan matcha. En sammanfattad väg i en instrumentpanel kan dölja att det specifika prefixet aldrig accepterades.

Importpolicy är den vanliga platsen där en väg försvinner utan fel. En prefixlista, ett communityfilter eller en inkommande route map kan släppa uppdateringen medan sessionen förblir uppe och frisk, och därför bevisar ett grönt grannljus så lite. Avsaknaden av en logglinje betyder inte avsaknaden av ett beslut. Det betyder vanligtvis att beslutet fattades tyst, exakt som konfigurerat.

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

Läs utdata i den ordningen. De två första kommandona säger om informationen kom fram och vad peer säger sig ha skickat; de två sista om något nådde routing- och forwardingtabellerna. Ett prefix som finns i det första kommandot och saknas i det tredje är ett urvals- eller installationsproblem, inte ett anslutningsproblem.

Andra porten: urval, sedan installation

BGP väljer bästa vägen, och den valda vägen installeras inte automatiskt. Nästa hopp måste lösas upp, och en annan routekälla kan redan äga prefixet med bättre administrativt avstånd. En statisk väg kvar från migreringen vinner lätt över en giltig BGP-väg och skickar trafiken någon annanstans.

RFC 4271 håller tre idéer åtskilda: vad en peer skickade, vad denna talare valde som bäst och vad den kommer att annonsera vidare. Det är begreppsmässiga roller, inte tre fysiska databaser som en leverantör måste exponera, men just den uppdelningen gör “det finns i BGP” till ett ofullständigt svar.

Kontrollera också vilken routingkontext du läser. En väg installerad i en VRF som användarens gränssnitt inte tillhör är osynlig för den användarens paket, och tabellen ser korrekt ut hela tiden.

Tredje porten: den uppslagning som gäller för detta flöde

Sluta nu fråga om vägen och börja fråga om paketet. Notera användarens källadress, destination, protokoll, port och ingående gränssnitt, eftersom var och en av dem kan välja en annan policy. Titta sedan på den uppslagning som gäller för den kombinationen i stället för den allmänna routingtabellen.

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

Ett mer specifikt prefix är den vanligaste överraskningen här, och en policyväg är den andra. Båda åsidosätter det aggregat du tittade på, och ingen av dem syns i en sammanfattning av BGP-tabellen.

En ping från gatewayen själv är inte bevis om en användarsession. Annan källadress, annan policysökväg och ofta ett annat resultat. Testa med samma källa som applikationen använder, eller acceptera att testet besvarar en annan fråga.

Fjärde porten: den bortre halvan av vägen

Om den lokala uppslagningen faktiskt väljer tunneln måste paketet ändå accepteras av skyddspolicyn, tillåtas av forwardingregeln och besvaras av något på andra sidan. En krypto-ACL som inte omfattar adressparet släpper trafiken medan tunneln rapporterar sig själv som uppe, vilket ger en timeout som inte går att skilja från ett routingfel.

Returvägen betyder lika mycket som den utgående. Molnsidan måste veta hur den når filialkällan, antingen via en väg eller via en översättning du medvetet konfigurerat. Asymmetriska returvägar är vanliga i design som bara testats från ett håll.

Korrelera en färsk auktoriserad anslutning mot tre observationer: policyn lokalt som matchade, tunnelnräknarna som rörde sig och mottagandet på den bortre sidan där det syns. Om räknarna inte rör sig kom paketet aldrig in i tunneln, vad routingtabellen än säger. Om de rör sig och inget anländer släpper eller felroutar den bortre sidan det. Dessa två utfall leder till helt olika team.

Namnge övergången som misslyckades

Skriv resultatet som ett av fem tillstånd: inte mottaget, inte accepterat av policy, inte valt, inte installerat eller inte träffat av detta flöde. Lägg till ett sjätte för fallet där den lokala vägen är korrekt och den bortre änden inte kan svara. Den meningen är leveransen, och den är mycket mer användbar än en skärmbild av en etablerad granne.

Behåll också ett negativt test i acceptansplanen: en destination som inte ska korsa tunneln, verifierad efter ändringen. En checklista som bara bevisar den glada vägen fångar inte den breda policyregel någon lägger till i nästa underhållsfönster.