MPLS-filialruting: hva CE lærer, og av hvem

En vert på én filial åpner en forbindelse til en server på en annen, og begge stedene ligger bak samme administrerte MPLS VPN på lag 3. Verten kjenner bare sin egen standard gateway og ingenting annet, noe som er riktig. Det viktige er at den lokale kundekanten overleverer pakken til sin leverandørkant, og at VPN-rutingstilstanden hos leverandøren leverer den til filialen som eier destinasjonsprefikset.

Å følge én pakke gjennom ruten er den raskeste måten å se hvilken del som er kundens ansvar og hvilken del som hører til tjenesten.

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

Hvor jobben til hvert hopp slutter

CE-A trenger en rute til det fjerne LAN-et som peker på sin lokale leverandørtilkobling, ikke på WAN-adressen til den fjerne filialen. Deretter bærer leverandøren pakken gjennom sin egen kjerne ved hjelp av VPN-rutingstilstanden, og CE-B leverer den på destinasjons-LAN-et. På ingen tidspunkt trenger en vert å forstå etiketter, VRF-er eller internettlinjen til den andre siden.

Feilen som stadig dukker opp i saker, er å konfigurere WAN-adressen til filial B som neste hopp på filial A. Begge filialene har kjøpt samme tjeneste, så det føles som om de burde være naboer. Det er de ikke: et neste hopp må være nåbart gjennom rutedesignet du faktisk har, og den fjerne CE-en ligger vanligvis mange hopp unna bak utstyr du ikke administrerer. En statisk rute bygget på den forutsetningen vises som aktiv og løses ikke opp til noe, noe som er verre enn en manglende rute, fordi den ser riktig ut i tabellen.

RFC 4364 skiller utvekslingen mellom kunde- og leverandørkant fra leverandørens distribusjon av VPN-ruter, og det er nøyaktig den grensen denne veiledningen handler om. Kundens jobb er å fortelle kanten sin hva den kan levere og godta den nåbarheten tjenesten tilbyr tilbake.

Hva overleveringen må bli enige om

Velg mekanismen sammen med leverandøren i stedet for utenom dem. Statiske ruter, BGP eller en rutingprotokollavtale mellom CE og PE er alle legitime, og OSPF har en definert MPLS VPN-modell for en slik overlevering. Ingen av dem er grunn til å bygge et OSPF-naboskap mellom to fjerne kundekanter gjennom en uspesifisert leverandørkjerne, for det er et design leverandøren ikke har godtatt og ikke kan støtte.

Før et nytt LAN settes i drift, skriv ned fire ting: prefikset, den lokale videre ruten på CE-en, annonseringen leverandøren vil godta, og rutene leverandøren vil returnere. Legg til all filtrering, prefiksgrenser eller begrensninger mellom steder som kontrakten pålegger. Et sunt naboskap er en kanal for å utveksle informasjon, og det er ikke bevis for at et bestemt prefiks ble godtatt; sesjonen kan være oppe mens det nye subnettet ditt sitter i et filter.

Følg deretter svaret. Filial B trenger en rute tilbake til kilde-LAN-et, og verten på mottakersiden trenger sin egen gateway og sine egne tjenestetillatelser. En rute som dukker opp på CE-A etablerer halve reisen, og halve reisen er grunnen til at én retning av en ping-test ser sunn ut mens applikasjonen fortsatt feiler.

Kontroller begge overleveringene før godkjenning

Samle rutingstilstanden på begge kundekanter, bekreft med leverandøren at de tiltenkte LAN-prefiksene ble godtatt i VPN-et, og test deretter én tillatt applikasjon i hver retning. Rutetabeller alene beviser ikke at applikasjonen virker, og en applikasjonstest alene forteller deg ikke hvilket kontrollplan som feilet når den ikke virker.

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 de tre utdataene sammen. Det første sier hva kanten tror, det andre sier hva den har lært og fra hvilken peer, og det tredje sier hva den faktisk vil videresende. Uenighet mellom dem er vanligvis et politikk- eller rekursjonsproblem snarere enn en manglende annonsering, og det er verdt å løse før leverandøren bes undersøke. Ta de tre utdataene med til samtalen med operatøren, for de svarer på de fleste spørsmålene en støtteingeniør ellers ville stilt deg.

Vet hva tjenesten ikke leverer

Dette er rutet tilgang på lag 3. Det er ikke en krets på lag 2 som utvider kringkasting mellom kontorer, så oppdagelsesprotokoller, kringkastingsavhengige applikasjoner og antakelser om delt segment reiser ikke med. Utskrift, navneblaing og alt som avhenger av et lokalt segment trenger sitt eget design.

VPN-atskillelse er heller ikke kryptering. Etikettkommutering holder kunder atskilt inne i leverandørens nettverk, og det gjør ikke nyttelasten konfidensiell hvis kontrakten krever konfidensialitet. Der det betyr noe, må applikasjonen eller et overlegg levere det.

Til slutt bør du holde tjenestemodellen skrevet ned ved siden av rutedesignet til stedet. Den neste ingeniøren som legger til et subnett, bør kunne lese hvilke prefikser som annonseres, hvem som godtar dem, og hva den forventede returveien er: BGP/MPLS IP VPN-spesifikasjonen er referansen for modellen bak alt dette.