VPNv4 mellem AS: hvad aftalen om videresendelse af labels kræver

At læse et VPNv4-label på en AS-grænserouter fortæller dig ikke meget, før du ved, hvilken model mellem AS overleveringen implementerer. Labelen er ikke en egenskab ved ruten i sig selv; den registrerer en aftale om indkapsling og levering mellem to routere. Fastslå modellen, før du læser displayet. Ellers fejlretter du en aftale, som ingen har skrevet ned.

Hvilken model grænsen implementerer

VRF-til-VRF-ordningen forbinder matchende VRF'er gennem rutede tilslutninger. Hver side ser den anden som en kundeedge-nabo, og de udveksler almindelige IPv4-ruter, så intet ved den grænse har brug for MPLS.

En anden ordning udveksler labeled VPNv4-ruter mellem grænserouterne selv. Det virker kun med en sammenhængende label-switched sti over forbindelsen og en route-target-distribution plus tillidsmodel, som begge sider accepterer. Mangler en af delene, er modellen ikke i brug, uanset hvad konfigurationen antyder.

Den tredje distribuerer labeled PE-rækkevidde, mens VPN-ruterne rejser mellem endepunkter eller routereflektorer på tværs af AS'er. Hver af de tre efterlader forskelligt arbejde ved grænsen, og at blande kontrolplanet fra én med interface-antagelserne fra en anden er den klassiske fejl. Den uoverensstemmelse viser sig normalt som et label, der ser rigtigt ud på den ene side og forsvinder på den anden.

Læs ét præfiks fra ende til anden

Tag et enkelt autoriseret kundepræfiks og gå det igennem. Se på, hvad der blev annonceret, hvad der ankom, næste hop, labelen og den importpolitik, der tillod det. Se derefter på hvordan routeren opløser videresendelse mod det næste hop, for det er der, en label bliver til en pakke. Springer du den ene halvdel over, beskriver du et kontrolplan, der måske ikke flytter trafik. De to læsninger betyder kun noget sammen.

Tallet er lokalt. Det betyder noget i forhold til den router, der tildelte det, og den sti, der bærer pakker derhen, og derfor kan samme værdi optræde to gange og betyde to forskellige ting. Sammenlign det med, hvad den modtagende side siger, den modtog.

Labelen er lokal, og løftet er det også

Kapacitet kontrolleres i begge ender af forbindelsen, ikke i én. En kommando på dit interface gør intet ved naboens udbyderinterface, og en rute, som BGP har accepteret, forpligter ikke i sig selv naboen til at videresende en labeled pakke.

RFC 4364 begrænser labeled VPNv4-peering til betroede ordninger og advarer mod at acceptere labels, der aldrig blev annonceret til den peer. Det er en sikkerhedserklæring lige så meget som en protokolerklæring. Hold forholdet til den offentlige internetrouting væk fra den private VPN-ruteudveksling. Hvis forbindelsen er almindelig IP, skal du ikke forvente, at nogen label overlever den. Og hvor linket er labeled, skal du bekræfte, at den ydre transportlabel skiftes korrekt ved hvert hop.

En label, der ser rigtig ud på den ene side og forsvinder på den anden, er normalt den uoverensstemmelse, ikke en routeringsfejl.

Hvad der skal skrives ned ved accept

Accept er en pakketest, ikke en tabelgennemgang. Følg en kundepakke ind i den fjerne VRF og følg svaret tilbage, og skriv derefter ned, hvilken model overleveringen implementerer. Tilføj overleveringsansvarlige på begge sider og om grænsen bærer almindelig IP eller labeled trafik.

Den note er det, der lader den næste operatør læse det samme labeldisplay korrekt. Uden den udledes modellen af konfigurationen, og udledte antagelser er måden, hvorpå den samme fejl gentages. RFC 4364's afsnit om mellem-AS er stedet, hvor man afgør, hvilken model der var tilsigtet.