BGP lærte præfikset, men trafikken springer stadig tunnelen over

Branchgatewayen viser cloudpræfikset i sin BGP-tabel, sessionen til udbyderen er etableret, og alligevel forlader en brugers anmodning til det præfiks den forkerte grænseflade. Intet er i stykker på den måde, overvågningen antyder, fordi “BGP lærte det” er et udsagn om kontrolplanet. Mellem den tabel og pakken er der fire adskilte overgange, og flowet stopper ved præcis én af dem. Gå gennem gateene i rækkefølge, og stop ved den første, der fejler.

Første gate: hvad naboen faktisk sendte

Start med præfikset som modtaget, ikke som opsummeret. Slå det præcise netværk og den præcise maske op i BGP-tabellen, og noter næste hop, AS-stien og eventuelle communities, som en importpolitik kan matche. En opsummeret rute i et dashboard kan skjule, at det konkrete præfiks aldrig blev accepteret.

Importpolitik er det sædvanlige sted, hvor en rute forsvinder uden fejl. En præfiksliste, et communityfilter eller et indgående rutekort kan droppe opdateringen, mens sessionen forbliver oppe og sund, og derfor beviser et grønt nabols så lidt. Fraværet af en loglinje betyder ikke fraværet af en beslutning. Det betyder normalt, at beslutningen blev taget lydløst, præcis som konfigureret.

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 outputtet i den rækkefølge. De to første fortæller, om informationen nåede frem, og hvad peeren siger, den sendte; de to sidste fortæller, om noget nåede routing- og forwardingtabellerne. Et præfiks, der findes i den første kommando og mangler i den tredje, er et valg- eller installationsproblem, ikke et forbindelsesproblem.

Anden gate: valg, derefter installation

BGP vælger en bedste sti, og den valgte sti installeres ikke automatisk. Næste hop skal kunne opløses, og en anden rutekilde kan allerede eje præfikset med en bedre administrativ afstand. En statisk rute tilbage fra migreringen vinder nemt over en gyldig BGP-sti og sender trafikken et andet sted hen.

RFC 4271 holder tre ideer adskilt: hvad en peer sendte, hvad denne speaker valgte som bedst, og hvad den vil annoncere videre. Det er begrebsmæssige roller snarere end tre fysiske databaser, en leverandør skal blotlægge, men netop adskillelsen gør “det er i BGP” til et ufuldstændigt svar.

Kontroller også, hvilken routingkontekst du læser. En rute installeret i en VRF, som brugerens grænseflade ikke tilhører, er usynlig for den brugers pakker, og tabellen ser korrekt ud hele tiden.

Tredje gate: det opslag, der gælder for dette flow

Stop nu med at spørge om ruten, og begynd at spørge om pakken. Noter brugerens kildeaddresse, destination, protokol, port og indgående grænseflade, fordi hver af dem kan vælge en anden politik. Se derefter på det opslag, der gælder for den kombination, i stedet for den generelle 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'

Et mere specifikt præfiks er den mest almindelige overraskelse her, og en policyrute er den anden. Begge tilsidesætter det aggregate, du kiggede på, og ingen af dem er synlige i en opsummering af BGP-tabellen.

En ping fra gatewayen selv er ikke bevis om en brugersession. Anden kildeaddresse, anden politiksti og ofte et andet resultat. Test med den samme kilde, som applikationen bruger, eller accepter, at testen besvarer et andet spørgsmål.

Fjerde gate: den fjerne halvdel af stien

Hvis det lokale opslag faktisk vælger tunnelen, skal pakken stadig accepteres af beskyttelsespolitikken, tillades af forwardingreglen og besvares af noget i den anden ende. En crypto-ACL, der ikke omfatter adresseparret, dropper trafikken, mens tunnelen rapporterer sig selv oppe, hvilket giver en timeout, der ikke kan skelnes fra en routingfejl.

Returvejen betyder lige så meget som den udgående. Cloud-siden skal vide, hvordan den når branchkilden, enten via en rute eller via en oversættelse, du bevidst har konfigureret. Asymmetriske returveje er almindelige i design, der kun er testet fra én retning.

Korrelér en frisk autoriseret forbindelse med tre observationer: den lokale politik, der matchede, de tunneltællere, der flyttede sig, og modtagelsen på den fjerne side, hvor det er synligt. Hvis tællerne ikke flytter sig, kom pakken aldrig ind i tunnelen, uanset hvad rutetabellen siger. Hvis de flytter sig, og intet ankommer, dropper eller fejlrouter den fjerne side den. De to udfald fører til helt forskellige teams.

Navngiv den overgang, der fejlede

Skriv resultatet som en af fem tilstande: ikke modtaget, ikke accepteret af politik, ikke valgt, ikke installeret eller ikke matchet af dette flow. Tilføj en sjette for det tilfælde, hvor den lokale sti er korrekt, og den fjerne ende ikke kan svare. Den sætning er leverancen, og den er langt mere nyttig end et skærmbillede af en etableret nabo.

Behold også en negativ test i acceptplanen: en destination, der ikke må krydse tunnelen, verificeret efter ændringen. En tjekliste, der kun beviser den glade vej, fanger ikke den brede politikregel, nogen tilføjer ved næste vedligeholdelsesvindue.