BGP-økt oppe, kundens veg broten: MPLS over DMVPN

Peerforbindelsen har vore oppe i veker, talet på prefiks ser rett ut, og likevel tek trafikken til ein kunde framleis den lange vegen eller kjem aldri fram. To ulike ting vert vurderte av same indikatoren. Ei BGP-økt rapporterer at to peers kan utveksle meldingar over ein TCP-samband; ho seier ingenting om korvidt overlayet kan bera ein merkt pakke for nettopp den kunden.

Dette gapet er lettast å sjå i eit MPLS-over-DMVPN-design, der hub-vegen og den direkte spoke-vegen kan oppføre seg ulikt av grunnar som ikkje har noko med peeringa å gjera.

Kva økta faktisk beviser

BGP køyrer over TCP, så kvar peer treng ei rute til endepunktadressa på hi sida før noko anna kan skje. Vel du ein loopback som det endepunktet, har du laga eit krav om nåbarheit, ikkje ein garanti for videresending. Økta kan deretter bli ståande over eit grensesnitt som kundetrafikken aldri ville bruke.

Skriv ned fire fakta i båe endar før du dreg konklusjonar: kjeldeadressa til økta, destinasjonsadressa, rutekonteksten ho ligg i, og kva grensesnitt kjernen eller rutaren ville velje for det paret. Desse fakta skildrar kontrollplanet. Kundepakkar legg til ein VRF, ein etikettstabel og ein overlay-mapping på toppen.

Fire mekanismar, ikkje éin

Dokumentasjonen til Cisco for MPLS over DMVPN skil delane klårt. MP-BGP fordeler overlay-etikettane til kunden mellom utstyret i kanten hos leverandøren. MPLS brukar desse etikettane til å velje videresendingskontekst for ein pakke. NHRP kartlegg ei overlay-adresse til transportendepunktet ein dynamisk tunnel treng. IPsec vernar peer-vegen der det gjeld.

Kva som helst av dei fire kan vere rett medan ein annan er feil, og kombinasjonen er det som ber trafikken. Ei ruteutveksling kan fullførast medan etikettbindinga for éin VRF manglar, medan NHRP-mappinga peikar på ei utdatert transportadresse, eller medan tunnelen finst men ingen policy lèt den indre pakken gjennom. Ingen av desse tilstandane får økta til å falle.

Samanlikn hub-vegen med snarvegen, éin variabel om gongen

Lås kjeldeverten, destinasjonsverten og VRF-en, og følg deretter same straumen to gonger. På hub-vegen noterer du neste hopp, tenestetikettsen som identifiserer den eksterne kundekonteksten, og overlay-til-transport-mappinga som vert brukt. På den tenkte direkte vegen noterer du dei same tre tinga. Skilnaden mellom dei to listene er feilen, eller fråværet av han.

Hald straumen konstant under samanlikninga. Å endre kjeldeverten, VRF-en eller destinasjonen mellom observasjonar gjev to uslekta historier, og det er den vanlegaste måten denne øvinga går gale på.

Hald loopback-testar i si eiga avdeling

Ein ping med kjelde i ein router-loopback er ein nyttig test, og han prøver eit anna tilfelle enn ein straum frå ein vert. Kjeldeadressa høyrer til rutaren, rutekonteksten kan vere global i staden for ein VRF, og svarvegen kan avvike frå den ein kundeprefiks ville teke. Så loopbacken som svarar, og applikasjonen som verkar over snarvegen, er separate resultat, og berre det andre skildrar kunden.

Test båe, og merk dei deretter kvar for seg i notata dine. Når dei er usamde, har du lært noko konkret om kvar designet vik av, og det er meir enn eitt grønt kryss nokon gong vil fortelje deg.

Versjons- og defektpåstandar treng eigne prov

Feltrapportar tilrår av og til å endre ei vertsmaske eller ei BGP-kjeldeadresse, og slike rapportar er berre verd å lese saman med defekten dei vart skrivne om og versjonane han råka. Ein omveg frå éin versjon er ikkje ein påstand om at kvart /32-prefiks er utan støtte i arkitekturen.

Bruk dokumentasjon som passar til DMVPN-fasen, plattforma og versjonen din, og hugs at eitt kapittel kan dekkje fleire oppsett, inkludert FlexVPN. Eit døme frå eitt oppsett vert ikkje stille overført til eit anna. Vel øktendepunkt for kontrollplansdesignet du faktisk treng, og verifiser deretter videresendingsvegen til kunden separat, fordi å skrive om kvar loopback-maske ikkje erstattar å finne ut kva oppgåve som feila.