Peerforbindelsen har været oppe i uger, præfiksantallet ser rigtigt ud, og alligevel tager én kundes trafik stadig den lange vej eller ankommer aldrig. To forskellige ting bliver vurderet af samme indikator. En BGP-session rapporterer, at to peers kan udveksle meddelelser over en TCP-forbindelse; den siger intet om, hvorvidt overlayet kan bære en mærket pakke for netop den kunde.

Det hul er lettest at se i et MPLS-over-DMVPN-design, hvor hub-vejen og den direkte spoke-vej kan opføre sig forskelligt af grunde, der intet har med peeringen at gøre.

Hvad sessionen egentlig beviser

BGP kører over TCP, så hver peer skal have en rute til den anden endepunkts adresse, før noget andet kan ske. Vælger du en loopback som det endepunkt, har du skabt et krav om nåbarhed, ikke en garanti for videresendelse. Sessionen kan derefter blive oppe gennem et interface, som kundens trafik aldrig ville bruge.

Noter fire fakta i begge ender, før du drager konklusioner: sessionens kildeadresse, dens destinationsadresse, den routingkontekst den ligger i, og hvilket interface kernen eller routeren ville vælge for det par. De fakta beskriver kontrolplanet. Kundepakker tilføjer en VRF, en etiketstak og en overlay-mapping ovenpå.

Fire mekanismer, ikke én

Ciscos dokumentation for MPLS over DMVPN adskiller delene klart. MP-BGP fordeler kundens overlay-etiketter mellem udbyderens kantudstyr. MPLS bruger de etiketter til at vælge videresendelseskontekst for en pakke. NHRP mapper en overlay-adresse til det transportendepunkt, som en dynamisk tunnel har brug for. IPsec beskytter peer-vejen, hvor det er relevant.

Enhver af de fire kan være rigtig, mens en anden er forkert, og kombinationen er det, der bærer trafik. En ruteudveksling kan fuldføres, mens etikettilknytningen for én VRF mangler, mens NHRP-mappingen peger på en forældet transportadresse, eller mens tunnelen findes, men ingen politik tillader den indre pakke. Ingen af de tilstande får sessionen til at falde.

Sammenlign hub-vejen med genvejen, én variabel ad gangen

Fastlås kildeværten, destinationsværten og VRF'en, og følg derefter den samme strøm to gange. På hub-vejen noterer du næste hop, den serviceetiket der identificerer den fjerne kundekontekst, og den overlay-til-transport-mapping der bruges. På den tilsigtede direkte vej noterer du de samme tre ting. Forskellen mellem de to lister er fejlen, eller fraværet af en.

Hold strømmen konstant under sammenligningen. At ændre kildeværten, VRF'en eller destinationen mellem observationer giver to ubeslægtede historier, og det er den mest almindelige måde, denne øvelse går galt.

Hold loopback-tests i deres eget rum

En ping med kilde i en router-loopback er en nyttig test, og den prøver et andet tilfælde end en strøm fra en vært. Kildeadressen tilhører routeren, dens routingkontekst kan være global i stedet for en VRF, og svaret kan tage en anden vej end den, et kundepræfiks ville tage. Så loopbacken der svarer, og applikationen der virker over genvejen, er separate resultater, og kun det andet beskriver kunden.

Test begge, og mærk dem derefter hver for sig i dine noter. Når de er uenige, har du lært noget konkret om, hvor designet afviger, og det er mere, end et enkelt grønt flueben nogensinde vil fortælle dig.

Versions- og defektpåstande kræver deres eget bevis

Feltrapporter anbefaler af og til at ændre en værtmaske eller en BGP-kildeadresse, og sådanne rapporter er kun værd at læse sammen med den defekt, de blev skrevet om, og de versioner, den ramte. En omvej fra én version er ikke en erklæring om, at hvert /32-præfiks er uden arkitektonisk støtte.

Brug dokumentation, der passer til din DMVPN-fase, platform og version, og husk, at et kapitel kan dække flere arrangementer, herunder FlexVPN. Et eksempel fra ét arrangement overføres ikke lydløst til et andet. Vælg sessionsendepunkter ud fra det kontrolplansdesign, du faktisk har brug for, og verificér derefter kundens videresendelsesvej separat, fordi omskrivning af hver loopback-maske ikke erstatter at finde ud af, hvilken opgave der fejlede.

Relaterede artikler