BGP lærte prefikset, men trafikken går framleis utanom tunnelen

Gatewayen på filialen viser skyprefikset i BGP-tabellen, sesjonen mot leverandøren er oppe, og likevel går førespurnaden frå ein brukar til prefikset ut gjennom feil grensesnitt. Ingenting er øydelagt slik overvakinga antyder, fordi “BGP lærte det” er ein påstand om kontrollplanet. Mellom tabellen og pakken er det fire separate overgangar, og flyten stoppar ved nøyaktig éin av dei. Gå gjennom portane i rekkjefølgje og stopp ved den første som sviktar.

Første port: kva naboen faktisk sende

Start med prefikset slik det vart motteke, ikkje slik det er oppsummert. Slå opp det nøyaktige nettet og maska i BGP-tabellen og noter neste hopp, AS-stien og eventuelle community verdiar som ein importpolicy kan matche. Ei oppsummert rute i eit dashbord kan skjule at det konkrete prefikset aldri vart akseptert.

Importpolicy er den vanlege staden der ei rute forsvinn utan feil. Ei prefiksliste, eit communityfilter eller eit innkomande rutekart kan forkaste oppdateringa medan sesjonen blir ståande oppe og sunn, og difor beviser eit grønt nabolys så lite. Fråvær av ei logglinje tyder ikkje fråvær av ei avgjerd. Det tyder vanlegvis at avgjerda vart teken 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 rekkjefølgja. Dei to første kommandoane seier om informasjonen kom fram og kva peeren hevdar han sende; dei to siste seier om noko nådde ruting- og videresendingstabellane. Eit prefiks som finst i den første kommandoen og manglar i den tredje, er eit val- eller installasjonsproblem, ikkje eit tilkoplingsproblem.

Andre port: val, deretter installasjon

BGP vel den beste stien, og den valde stien blir ikkje installert automatisk. Neste hopp må løysast opp, og ei anna rutekjelde kan alt eige prefikset med betre administrativ avstand. Ei statisk rute som vart att etter migreringa, vinn lett over ein gyldig BGP-sti og sender trafikken ein annan stad.

RFC 4271 held tre idear frå kvarandre: kva ein peer sende, kva denne talaren valde som best, og kva han vil annonsere vidare. Dette er omgreplege roller, ikkje tre fysiske databasar ein leverandør må eksponere, men nettopp denne delinga gjer “det er i BGP” til eit ufullstendig svar.

Sjekk òg kva rutingkontekst du les. Ei rute installert i ein VRF som grensesnittet til brukaren ikkje høyrer til, er usynleg for pakkane til den brukaren, og tabellen ser riktig ut heile tida.

Tredje port: oppslaget som gjeld for denne flyten

Slutt no å spørje om ruta og byrje å spørje om pakken. Noter kjeldeadressa til brukaren, destinasjonen, protokollen, porten og inngangsgrensesnittet, fordi kvar av dei kan velje ein annan policy. Sjå deretter på oppslaget som gjeld for den kombinasjonen, i staden 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'

Eit meir spesifikt prefiks er den vanlegaste overraskinga her, og ei policyrute er den andre. Begge overstyrer aggregatet du såg på, og ingen av dei er synlege i ei oppsummering av BGP-tabellen.

Ein ping frå gatewayen sjølv er ikkje bevis om ein brukarsesjon. Anna kjeldeadresse, annan policysti og ofte eit anna resultat. Test med same kjelde som applikasjonen brukar, eller godta at testen svarar på eit anna spørsmål.

Fjerde port: den fjerne halvdelen av stien

Viss det lokale oppslaget faktisk vel tunnelen, må pakken framleis aksepterast av beskyttelsespolicyn, tillatast av videresendingsregelen og svarast av noko på den andre sida. Ein krypto-ACL som ikkje omfattar adresseparet, slepp trafikken medan tunnelen rapporterer seg sjølv som oppe, noko som gir ein tidsavbrot som ikkje kan skiljast frå ein rutingfeil.

Returvegen tel like mykje som den utgåande. Skysida må vite korleis ho når filialkjelda, anten via ei rute eller via ei omsetjing du med vilje har konfigurert. Asymmetriske returvegar er vanlege i design som berre er testa frå éin retning.

Korreler ei fersk autorisert tilkopling mot tre observasjonar: den lokale policyn som trefte, tunnelteljarane som flytta seg, og mottaket på den fjerne sida der det er synleg. Flyttar teljarane seg ikkje, kom pakken aldri inn i tunnelen, uansett kva rutetabellen seier. Flyttar dei seg og ingenting kjem fram, slepp eller feilruter den fjerne sida han. Desse to utfalla fører til heilt ulike team.

Namngi overgangen som svikta

Skriv resultatet som éin av fem tilstandar: ikkje motteke, ikkje akseptert av policy, ikkje vald, ikkje installert eller ikkje treft av denne flyten. Legg til ein sjette for tilfellet der den lokale stien er riktig og den fjerne enden ikkje kan svare. Den setninga er leveransen, og ho er langt meir nyttig enn eit skjermbilde av ein etablert nabo.

Hald òg ein negativ test i akseptplanen: ein destinasjon som ikkje skal krysse tunnelen, verifisert etter endringa. Ei sjekkliste som berre beviser den glade vegen, fangar ikkje den breie policyregelen nokon legg til i neste vedlikehalsvindauge.