BGP-økt oppe, kundens vei brutt: MPLS over DMVPN

Peerforbindelsen har vært oppe i uker, antall prefikser ser riktig ut, og likevel tar én kundes trafikk fortsatt den lange veien eller kommer aldri frem. To forskjellige ting vurderes av samme indikator. En BGP-økt rapporterer at to peers kan utveksle meldinger over en TCP-forbindelse; den sier ingenting om hvorvidt overlayet kan bære en merket pakke for nettopp den kunden.

Dette gapet er lettest å se i et MPLS-over-DMVPN-design, der hub-veien og den direkte spoke-veien kan oppføre seg ulikt av grunner som ikke har noe med peering å gjøre.

Hva økten faktisk beviser

BGP kjører over TCP, så hver peer trenger en rute til den andre endepunktadressen før noe annet kan skje. Velger du en loopback som det endepunktet, har du laget et krav om nåbarhet, ikke en garanti for videresending. Økten kan deretter bli stående over et grensesnitt som kundens trafikk aldri ville bruke.

Noter fire fakta i begge ender før du trekker konklusjoner: øktens kildeadresse, dens destinasjonsadresse, rutekonteksten den ligger i, og hvilket grensesnitt kjernen eller ruteren ville velge for det paret. Disse faktaene beskriver kontrollplanet. Kundepakker legger til en VRF, en etikettstabel og en overlay-mapping på toppen.

Fire mekanismer, ikke én

Ciscos dokumentasjon for MPLS over DMVPN skiller delene klart. MP-BGP fordeler kundens overlay-etiketter mellom leverandørens kantutstyr. MPLS bruker disse etikettene til å velge videresendingskontekst for en pakke. NHRP mapper en overlay-adresse til transportendepunktet en dynamisk tunnel trenger. IPsec beskytter peer-veien der det gjelder.

Hvilken som helst av de fire kan være riktig mens en annen er feil, og kombinasjonen er det som bærer trafikk. En ruteutveksling kan fullføres mens etikettbindingen for én VRF mangler, mens NHRP-mappingen peker på en utdatert transportadresse, eller mens tunnelen finnes men ingen policy tillater den indre pakken. Ingen av disse tilstandene får økten til å falle.

Sammenlign hub-veien med snarveien, én variabel om gangen

Lås kildeverten, destinasjonsverten og VRF-en, og følg deretter samme strøm to ganger. På hub-veien noterer du neste hopp, tjenesteetiketten som identifiserer den eksterne kundekonteksten, og overlay-til-transport-mappingen som brukes. På den tiltenkte direkte veien noterer du de samme tre tingene. Forskjellen mellom de to listene er feilen, eller fraværet av den.

Hold strømmen konstant under sammenligningen. Å endre kildeverten, VRF-en eller destinasjonen mellom observasjoner gir to ubeslektede historier, og det er den vanligste måten denne øvelsen går galt.

Hold loopback-tester i sin egen avdeling

En ping med kilde i en router-loopback er en nyttig test, og den prøver et annet tilfelle enn en strøm fra en vert. Kildeadressen tilhører ruteren, rutekonteksten kan være global i stedet for en VRF, og svarveien kan avvike fra den et kundeprefiks ville tatt. Så loopbacken som svarer, og applikasjonen som virker over snarveien, er separate resultater, og bare det andre beskriver kunden.

Test begge, og merk dem deretter hver for seg i notatene dine. Når de er uenige, har du lært noe konkret om hvor designet avviker, og det er mer enn ett grønt kryss noen gang vil fortelle deg.

Versjons- og defektpåstander trenger egne bevis

Feltrapporter anbefaler av og til å endre en vertsmaske eller en BGP-kildeadresse, og slike rapporter er bare verdt å lese sammen med defekten de ble skrevet om og versjonene den rammet. En omvei fra én versjon er ikke en påstand om at hvert /32-prefiks er uten støtte i arkitekturen.

Bruk dokumentasjon som passer til DMVPN-fasen, plattformen og versjonen din, og husk at ett kapittel kan dekke flere oppsett, inkludert FlexVPN. Et eksempel fra ett oppsett overføres ikke stille til et annet. Velg øktendepunkter for kontrollplansdesignet du faktisk trenger, og verifiser deretter kundens videresendingsvei separat, fordi å skrive om hver loopback-maske ikke erstatter å finne ut hvilken oppgave som feilet.