VPNv4 mellom AS: kva avtalen om videresending av etikettar krev

Å lese ein VPNv4-etikett på ein AS-grenseruter seier deg lite før du veit kva for ein AS-modell overleveringa implementerer. Etiketten er ikkje ein eigenskap ved ruta åleine; han registrerer ein avtale om innkapsling og levering mellom to rutarar. Identifiser modellen før du les visinga. Elles feilsøkjer du ein avtale ingen har skrive ned.

Kva modell grensa implementerer

VRF-til-VRF-oppsettet knyter saman samsvarande VRF-ar via ruta tilknytingar. Kvar side ser den andre som ein kundenær nabo, og dei utvekslar vanlege IPv4-ruter, så ingenting på den grensa treng MPLS.

Eit andre oppsett byter etikettmerkte VPNv4-ruter mellom grenserutarane sjølve. Det verkar berre med ein samanhengande etikettsvitsja sti over samankoplinga og ein route-target-distribusjon pluss ein tillitsmodell som begge sider godtek. Manglar ein av delane, er modellen ikkje i bruk, uansett kva konfigurasjonen antydar.

Det tredje fordeler etikettmerkt PE-tilgjenge medan VPN-rutene reiser mellom endepunkt eller rute-reflektorar over AS-ar. Kvar av dei tre lèt att ulikt arbeid ved grensa, og å blande kontrollplanet til éin med grensesnittføresetnadene til ein annan er den klassiske feilen. Det misforholdet viser seg vanlegvis som ein etikett som ser rett ut på éi side og forsvinn på den andre.

Les eitt prefiks frå ende til ende

Ta eitt autorisert kundeprefiks og gå gjennom det. Sjå på kva som vart annonsert, kva som kom fram, neste hopp, etiketten og importpolicyen som sleppte han inn. Sjå deretter på korleis rutaren løyser videresending mot det neste hoppet, for det er der ein etikett blir ein pakke. Hoppar du over nokon av halvdelane, skildrar du eit kontrollplan som kanskje ikkje flyttar trafikk. Dei to lesingane tyder noko berre saman.

Talet er lokalt. Det tyder noko i høve til rutaren som tildelte det og stien som ber pakkane dit, og difor kan same verdi dukke opp to gonger og tyde to ulike ting. Samanlikn han med det mottakarsida seier ho tok imot.

Etiketten er lokal, og det er lovnaden òg

Kapasiteten vert kontrollert i begge endar av samankoplinga, ikkje i éin. Ein kommando på grensesnittet ditt gjer ingenting med leverandørgrensesnittet til naboen, og ei rute BGP godtok forpliktar ikkje naboen til å videresende ein etikettmerkt pakke.

RFC 4364 avgrensar etikettmerkt VPNv4-peering til betrudde oppsett og åtvarar mot å godta etikettar som aldri vart annonserte til den peeren. Det er ei tryggingsfråsegn like mykje som ei protokollfråsegn. Hald ruteforholdet til det offentlege internettet unna utvekslinga av private VPN-ruter. Er samankoplinga rein IP, ikkje vent at nokon etikett overlever henne. Og der lenkja er etikettmerkt, stadfest at den ytre transportetiketten vert bytt rett ved kvart hopp.

Ein etikett som ser rett ut på éi side og forsvinn på den andre, er vanlegvis det misforholdet, ikkje ein ruteleggingsfeil.

Kva som skal skrivast ned ved aksept

Aksept er ein pakketest, ikkje ein tabellgjennomgang. Følg ein kundepakke inn i den fjerne VRF-en og følg svaret attende, og skriv så ned kva modell overleveringa implementerer. Legg til overleveringsansvarlege på begge sider og om grensa ber rein IP eller etikettmerkt trafikk.

Den notata er det som lèt neste operatør lese same etikettvising rett. Utan henne vert modellen utleia frå konfigurasjonen, og utleia føresetnader er måten same feil vert gjenteken på. RFC 4364-avsnittet om AS-samankopling er staden der det vert avgjort kva modell som var meint.