BGP lærte prefikset, men trafikken går fortsatt utenom tunnelen

Filiatens gateway viser skyprefikset i BGP-tabellen, sesjonen mot leverandøren er oppe, og likevel forlater en brukers forespørsel til prefikset via feil grensesnitt. Ingenting er ødelagt slik overvåkingen antyder, fordi “BGP lærte det” er en påstand om kontrollplanet. Mellom tabellen og pakken er det fire separate overganger, og flyten stopper ved nøyaktig én av dem. Gå gjennom portene i rekkefølge og stopp ved den første som svikter.

Første port: hva naboen faktisk sendte

Start med prefikset slik det ble mottatt, ikke slik det er oppsummert. Slå opp det nøyaktige nettet og masken i BGP-tabellen og noter neste hopp, AS-stien og eventuelle communities som en importpolicy kan matche. En oppsummert rute i et dashbord kan skjule at det konkrete prefikset aldri ble akseptert.

Importpolicy er det vanlige stedet der en rute forsvinner uten feil. En prefiksliste, et communityfilter eller et innkommende rutekart kan forkaste oppdateringen mens sesjonen blir stående oppe og sunn, og derfor beviser et grønt nabolys så lite. Fravær av en logglinje betyr ikke fravær av en beslutning. Det betyr vanligvis at beslutningen ble tatt stille, nøyaktig som konfigurert.

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

Les utdata i den rekkefølgen. De to første kommandoene sier om informasjonen kom frem og hva peeren hevder den sendte; de to siste sier om noe nådde ruting- og videresendingstabellene. Et prefiks som finnes i den første kommandoen og mangler i den tredje, er et valg- eller installasjonsproblem, ikke et tilkoblingsproblem.

Andre port: valg, deretter installasjon

BGP velger beste sti, og den valgte stien installeres ikke automatisk. Neste hopp må løses opp, og en annen rutekilde kan allerede eie prefikset med bedre administrativ avstand. En statisk rute som ble igjen fra migreringen, vinner lett over en gyldig BGP-sti og sender trafikken et annet sted.

RFC 4271 holder tre ideer fra hverandre: hva en peer sendte, hva denne speakeren valgte som best, og hva den vil annonsere videre. Dette er konseptuelle roller, ikke tre fysiske databaser en leverandør må eksponere, men nettopp denne delingen gjør “det er i BGP” til et ufullstendig svar.

Sjekk også hvilken rutingkontekst du leser. En rute installert i en VRF som brukerens grensesnitt ikke tilhører, er usynlig for den brukerens pakker, og tabellen ser riktig ut hele tiden.

Tredje port: oppslaget som gjelder for denne flyten

Slutt nå å spørre om ruten og begynn å spørre om pakken. Noter brukerens kildeadresse, destinasjon, protokoll, port og inngangsgrensesnitt, fordi hver av dem kan velge en annen policy. Se deretter på oppslaget som gjelder for den kombinasjonen, i stedet for den generelle rutingtabellen.

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 mer spesifikt prefiks er den vanligste overraskelsen her, og en policyrute er den andre. Begge overstyrer aggregatet du så på, og ingen av dem er synlige i en oppsummering av BGP-tabellen.

En ping fra gatewayen selv er ikke bevis om en brukersesjon. Annen kildeadresse, annen policysti og ofte et annet resultat. Test med samme kilde som applikasjonen bruker, eller godta at testen besvarer et annet spørsmål.

Fjerde port: den fjerne halvdelen av stien

Hvis det lokale oppslaget faktisk velger tunnelen, må pakken fortsatt aksepteres av beskyttelsespolicyn, tillates av videresendingsregelen og besvares av noe på den andre siden. En krypto-ACL som ikke omfatter adresseparet, slipper trafikken mens tunnelen rapporterer seg selv som oppe, noe som gir en tidsavbrudd som ikke kan skilles fra en rutingfeil.

Returveien betyr like mye som den utgående. Skysiden må vite hvordan den når filialkilden, enten via en rute eller via en oversettelse du bevisst har konfigurert. Asymmetriske returveier er vanlige i design som bare er testet fra én retning.

Korreler en fersk autorisert forbindelse mot tre observasjoner: den lokale policyn som traff, tunneltellerne som flyttet seg, og mottaket på den fjerne siden der det er synlig. Hvis tellerne ikke flytter seg, kom pakken aldri inn i tunnelen, uansett hva rutetabellen sier. Hvis de flytter seg og ingenting kommer frem, slipper eller feilruter den fjerne siden den. Disse to utfallene fører til helt forskjellige team.

Navngi overgangen som sviktet

Skriv resultatet som én av fem tilstander: ikke mottatt, ikke akseptert av policy, ikke valgt, ikke installert eller ikke truffet av denne flyten. Legg til en sjette for tilfellet der den lokale stien er riktig og den fjerne enden ikke kan svare. Den setningen er leveransen, og den er langt mer nyttig enn et skjermbilde av en etablert nabo.

Behold også en negativ test i akseptplanen: en destinasjon som ikke skal krysse tunnelen, verifisert etter endringen. En sjekkliste som bare beviser den glade veien, fanger ikke den brede policyregelen noen legger til i neste vedlikeholdsvindu.