MPLS-filialruting: kva CE lærer, og av kven

Ein vert på éin filial opnar ei tilkopling til ein tenar på ein annan, og begge stadene ligg bak same administrerte MPLS VPN på lag 3. Verten kjenner berre sin eigen standard gateway og ingenting anna, noko som er rett. Det viktige er at den lokale kundekanten overleverer pakken til sin leverandørkant, og at VPN-rutetilstanden hos leverandøren leverer han til filialen som eig destinasjonsprefikset.

Å følgje éin pakke gjennom ruta er den snøggaste måten å sjå kva del som er kundens ansvar og kva del som høyrer til tenesta.

10.20.0.0/24 → CE-A → PE → provider core → PE → CE-B → 10.30.0.0/24

Kvar arbeidet til kvart hopp sluttar

CE-A treng ei rute til det fjerne LAN-et som peikar på den lokale leverandørtilkoplinga hans, ikkje på WAN-adressa til den fjerne filialen. Deretter ber leverandøren pakken gjennom sin eigen kjerne ved hjelp av VPN-rutetilstanden, og CE-B leverer han på destinasjons-LAN-et. På ingen tidspunkt treng ein vert å forstå etikettar, VRF-ar eller internettlinja til den andre sida.

Feilen som stadig dukkar opp i saker, er å konfigurere WAN-adressa til filial B som neste hopp på filial A. Begge filialane har kjøpt same tenesta, så det kjennest som dei burde vere naboar. Det er dei ikkje: eit neste hopp må vere nåbart gjennom rutedesignet du faktisk har, og den fjerne CE-en ligg vanlegvis mange hopp unna bak utstyr du ikkje administrerer. Ei statisk rute bygd på den føresetnaden viser seg som aktiv og løyser seg ikkje opp til noko, noko som er verre enn ei manglande rute, fordi ho ser rett ut i tabellen.

RFC 4364 skil utvekslinga mellom kunde- og leverandørkant frå leverandøren si distribusjon av VPN-ruter, og det er nett den grensa denne rettleiinga handlar om. Jobben til kunden er å fortelje kanten sin kva han kan levere og godta den nåbarheita tenesta tilbyr tilbake.

Kva overleveringa må bli samde om

Vel mekanismen saman med leverandøren i staden for utanom dei. Statiske ruter, BGP eller ein ruteavtale mellom CE og PE er alle legitime, og OSPF har ein definert MPLS VPN-modell for ei slik overlevering. Ingen av dei er grunn til å byggje eit OSPF-naboskap mellom to fjerne kundekantar gjennom ein uspesifisert leverandørkjerne, for det er eit design leverandøren ikkje har godteke og ikkje kan støtte.

Før eit nytt LAN blir sett i drift, skriv ned fire ting: prefikset, den lokale vidare ruta på CE-en, annonseringa leverandøren vil godta, og rutene leverandøren vil returnere. Legg til all filtrering, prefiksgrenser eller avgrensingar mellom stader som kontrakten pålegg. Eit sunt naboskap er ein kanal for å utveksle informasjon, og det er ikkje bevis for at eit bestemt prefiks vart godteke; sesjonen kan stå oppe medan det nye subnettet ditt sit i eit filter.

Følg deretter svaret. Filial B treng ei rute tilbake til kjelde-LAN-et, og verten på mottakarsida treng sin eigen gateway og sine eigne tenesteløyve. Ei rute som dukkar opp på CE-A etablerer halve reisa, og halve reisa er grunnen til at éin retning av ein ping-test ser sunn ut medan applikasjonen framleis feilar.

Kontroller begge overleveringane før godkjenning

Samle rutetilstanden på begge kundekantar, stadfest med leverandøren at dei tiltenkte LAN-prefiksa vart godtekne i VPN-et, og test deretter éin tillaten applikasjon i kvar retning. Rutetabellar åleine beviser ikkje at applikasjonen verkar, og ein applikasjonstest åleine fortel deg ikkje kva kontrollplan som feila når han ikkje verkar.

show ip route vrf BRANCH 10.30.0.0
show ip bgp vpnv4 vrf BRANCH
show ip cef vrf BRANCH 10.30.0.10

Les dei tre utdataa saman. Det første seier kva kanten trur, det andre seier kva han har lært og frå kven, og det tredje seier kva han faktisk vil videresende. Ueinigheit mellom dei er vanlegvis eit politikk- eller rekursjonsproblem snarare enn ei manglande annonsering, og det er verdt å løyse før leverandøren blir beden om å undersøkje. Ta dei tre utdataa med til samtalen med operatøren, for dei svarar på dei fleste spørsmåla ein støtteingeniør elles ville stilt deg.

Vit kva tenesta ikkje leverer

Dette er rutet tilgang på lag 3. Det er ikkje ein krets på lag 2 som utvidar kringkasting mellom kontor, så oppdagingsprotokollar, kringkastingsavhengige applikasjonar og antakingar om delt segment reiser ikkje med. Utskrift, namneblaing og alt som er avhengig av eit lokalt segment treng sitt eige design.

VPN-atskiljing er heller ikkje kryptering. Etikettkommutering held kundar atskilde inne i nettverket til leverandøren, og det gjer ikkje nyttelasta konfidensiell om kontrakten krev konfidensialitet. Der det betyr noko, må applikasjonen eller eit overlegg levere det.

Til slutt bør du halde tenestemodellen skriven ned attmed rutedesignet til staden. Den neste ingeniøren som legg til eit subnett, bør kunne lese kva prefiks som blir annonserte, kven som godtek dei, og kva den forventa returvegen er: BGP/MPLS IP VPN-spesifikasjonen er referansen for modellen bak alt dette.