VPNv4 mellom AS: hva avtalen om videresending av etiketter krever

Å lese en VPNv4-etikett på en AS-grenseruter sier deg lite før du vet hvilken AS-modell overleveringen implementerer. Etiketten er ikke en egenskap ved ruten alene; den registrerer en avtale om innkapsling og levering mellom to rutere. Identifiser modellen før du leser visningen. Ellers feilsøker du en avtale ingen har skrevet ned.

Hvilken modell grensen implementerer

VRF-til-VRF-oppsettet kobler sammen samsvarende VRF-er via rutede tilkoblinger. Hver side ser den andre som en kundenær nabo, og de utveksler vanlige IPv4-ruter, så ingenting på den grensen trenger MPLS.

Et andre oppsett bytter etikettede VPNv4-ruter mellom grenseruterne selv. Det virker bare med en sammenhengende etikettsvitsjet sti over sammenkoblingen og en route-target-distribusjon pluss en tillitsmodell som begge sider godtar. Mangler én av delene, er modellen ikke i bruk, uansett hva konfigurasjonen antyder.

Det tredje fordeler etikettet PE-tilgjengelighet mens VPN-rutene reiser mellom endepunkter eller rute-reflektorer over AS-er. Hver av de tre etterlater ulikt arbeid ved grensen, og å blande kontrollplanet til én med grensesnittantakelsene til en annen er den klassiske feilen. Det misforholdet viser seg vanligvis som en etikett som ser riktig ut på én side og forsvinner på den andre.

Les ett prefiks fra ende til ende

Ta ett autorisert kundeprefiks og gå gjennom det. Se på hva som ble annonsert, hva som kom fram, neste hopp, etiketten og importpolicyen som slapp den inn. Se deretter på hvordan ruteren løser videresending mot det neste hoppet, for det er der en etikett blir en pakke. Hopper du over noen av halvdelene, beskriver du et kontrollplan som kanskje ikke flytter trafikk. De to lesningene betyr noe bare sammen.

Tallet er lokalt. Det betyr noe i forhold til ruteren som tildelte det og stien som bærer pakkene dit, og derfor kan samme verdi dukke opp to ganger og bety to forskjellige ting. Sammenlign det med det mottakersiden sier den mottok.

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

Kapasiteten kontrolleres i begge ender av sammenkoblingen, ikke i én. En kommando på grensesnittet ditt gjør ingenting med naboens leverandørgrensesnitt, og en rute BGP godtok forplikter ikke naboen til å videresende en etikettet pakke.

RFC 4364 begrenser etikettet VPNv4-peering til betrodde oppsett og advarer mot å godta etiketter som aldri ble annonsert til den peeren. Det er en sikkerhetserklæring like mye som en protokollerklæring. Hold det offentlige internettets ruteforhold unna utvekslingen av private VPN-ruter. Er sammenkoblingen ren IP, ikke forvent at noen etikett overlever den. Og der lenken er etikettet, bekreft at den ytre transportetiketten byttes riktig ved hvert hopp.

En etikett som ser riktig ut på én side og forsvinner på den andre, er vanligvis det misforholdet, ikke en rutingsfeil.

Hva som skal skrives ned ved aksept

Aksept er en pakketest, ikke en tabellgjennomgang. Følg en kundepakke inn i den fjerne VRF-en og følg svaret tilbake, og skriv så ned hvilken modell overleveringen implementerer. Legg til overleveringsansvarlige på begge sider og om grensen bærer ren IP eller etikettet trafikk.

Den noten er det som lar neste operatør lese samme etikettvisning riktig. Uten den blir modellen utledet fra konfigurasjonen, og utledede antakelser er måten samme feil gjentas på. RFC 4364-avsnittet om AS-sammenkobling er stedet der det avgjøres hvilken modell som var ment.