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

Peering-forbindelsen har stått oppe i ukevis, antallet prefikser ser riktig ut, og likevel tar trafikken fra én kunde fortsatt den lange veien eller kommer aldri frem. To forskjellige ting bedømmes ut fra samme indikator. En BGP-økt melder at to peers kan utveksle meldinger over en TCP-forbindelse; den sier ikke noe om hvorvidt overlayet kan frakte en merket pakke for nettopp denne kunden.

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

Hva økten egentlig beviser

BGP går over TCP, så hver peer trenger en rute til adressen i den andre enden før noe annet kan skje. Velger du en loopback som denne enden, har du laget et krav om tilgjengelighet, ikke en garanti for videresending. Økten kan så bli stående over et grensesnitt som kundetrafikken aldri ville brukt.

Skriv ned fire fakta i begge ender før du konkluderer: øktas kildeadresse, destinasjonsadresse, rutekonteksten den ligger i, og hvilket grensesnitt kjernen eller ruteren ville valgt for paret. Disse faktaene beskriver kontrollplanet. Kundepakker legger en VRF, en etikettstabel og en overlay-mapping oppå.

Fire mekanismer, ikke bare én

Ciscos dokumentasjon om MPLS over DMVPN deler delene tydelig. MP-BGP fordeler kundens overlay-etiketter mellom enhetene ved leverandørens kant. MPLS bruker etikettene til å velge videresendingskontekst for en pakke. NHRP mapper en overlay-adresse til transportendepunktet en dynamisk tunnel trenger. IPsec beskytter peer-veien der det er relevant.

Enhver av de fire kan være riktig mens en annen er gal, og det er kombinasjonen som bærer trafikken. En ruteutveksling kan være fullført mens etikettbindingen for én VRF mangler, mens NHRP-mappingen viser til en foreldet 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 av gangen

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

Hold strømmen uendret gjennom sammenligningen. Å bytte kildevert, VRF eller mål mellom observasjonene gir to historier uten sammenheng, og det er den vanligste måten denne øvelsen går galt.

Hold loopback-tester i egen avdeling

En ping fra en routers loopback er en nyttig test, og den øver på et annet tilfelle enn en strøm fra en vert. Kildeadressen tilhører ruteren, rutekonteksten kan være global istedenfor en VRF, og returveien kan være en annen enn den et kundeprefiks ville tatt. Derfor er loopbacken som svarer og applikasjonen som virker over snarveien, to ulike resultater, og bare det andre beskriver kunden.

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

Påstander om versjon og defekt krever egne bevis

Feltrapporter anbefaler iblant å 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 arkitekturen ikke støtter noe /32-prefiks.

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 i stillhet til et annet. Velg øktendepunkter ut fra kontrollplan-designet du faktisk trenger, og verifiser så kundens videresendingsvei separat, fordi å skrive om hver loopback-maske ikke er noen erstatning for å finne ut hvilken oppgave som feilet.