MPLS-filigrouting: hvad CE lærer, og af hvem

En vært på én filial åbner en forbindelse til en server på en anden, og begge steder ligger bag den samme administrerede MPLS VPN på lag 3. Værten kender kun sin egen standardgateway og intet andet, hvilket er korrekt. Det afgørende er, at den lokale kundekant afleverer pakken til sin udbyderkant, og at udbyderens VPN-routingtilstand leverer den til den filial, der ejer destinationspræfikset.

At følge én pakke gennem ruten er den hurtigste måde at se, hvilken del der er kundens ansvar, og hvilken del der hører til tjenesten.

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

Hvor hvert hop stopper

CE-A har brug for en rute til det fjerne LAN, der peger på dens lokale udbyder-tilslutning, ikke på den fjerne filials WAN-adresse. Så bærer udbyderen pakken gennem sin egen kerne ved hjælp af VPN-routingtilstand, og CE-B leverer den til destinations-LAN'et. På intet tidspunkt skal en vært forstå labels, VRF'er eller den anden sides internetkredsløb.

Den fejl, der hele tiden dukker op i sager, er at konfigurere filial B's WAN-adresse som næste hop på filial A. Begge filialer har købt den samme tjeneste, så det føles, som om de burde være naboer. Det er de ikke: et næste hop skal være nåbart gennem det routingdesign, du faktisk har, og den fjerne CE ligger normalt mange hop væk bag udstyr, du ikke administrerer. En statisk rute bygget på den antagelse vises som aktiv og opløses til intet, hvilket er værre end en manglende rute, fordi den ser korrekt ud i tabellen.

RFC 4364 adskiller udvekslingen mellem kunde- og udbyderkant fra udbyderens distribution af VPN-ruter, og det er præcis den grænse, denne runbook handler om. Kundens opgave er at fortælle sin kant, hvad den kan levere, og at acceptere den nåbarhed, tjenesten tilbyder tilbage.

Hvad overdragelsen skal aftale

Vælg mekanismen sammen med udbyderen i stedet for uden om dem. Statiske ruter, BGP eller en routingprotokol-aftale mellem CE og PE er alle legitime, og OSPF har en defineret MPLS VPN-model til den overdragelse. Ingen af dem er grund til at bygge et OSPF-naboskab mellem to fjerne kundekanter gennem en uspecificeret udbyderkerne, for det er et design, udbyderen ikke har accepteret og ikke kan understøtte.

Før et nyt LAN går i drift, skriv fire ting ned: præfikset, den lokale videre rute på CE'en, den annoncering udbyderen vil acceptere, og de ruter udbyderen vil returnere. Tilføj enhver filtrering, præfiksgrænse eller sted-til-sted-begrænsning, som kontrakten pålægger. Et sundt naboskab er en kanal til at udveksle information, og det er ikke bevis for, at et bestemt præfiks blev accepteret; sessionen kan være oppe, mens dit nye subnet ligger i et filter.

Følg så svaret. Filial B har brug for en rute tilbage til kilde-LAN'et, og værten på modtagersiden har brug for sin egen gateway og sine egne tjenestetilladelser. En rute, der dukker op på CE-A, etablerer en halv rundtur, og en halv rundtur er grunden til, at den ene retning af en ping-test ser sund ud, mens applikationen stadig fejler.

Kontrollér begge overdragelser før godkendelse

Indsaml routingtilstanden på begge kundekanter, bekræft med udbyderen, at de tilsigtede LAN-præfikser blev accepteret i VPN'en, og test derefter én tilladt applikation i hver retning. Rutetabeller alene beviser ikke, at applikationen virker, og en applikationstest alene fortæller dig ikke, hvilket kontrolplan der fejlede, 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

Læs de tre output sammen. Det første siger, hvad kanten tror, det andet siger, hvad den har lært og fra hvilken peer, og det tredje siger, hvad den faktisk vil videresende. Uenighed mellem dem er normalt et politik- eller rekursionsproblem snarere end en manglende annoncering, og det er værd at løse, før udbyderen bedes undersøge sagen. Tag de tre output med til samtalen med carrieren, for de besvarer de fleste af de spørgsmål, en supportingeniør ellers ville stille dig.

Vid, hvad tjenesten ikke leverer

Dette er rutet adgang på lag 3. Det er ikke et kredsløb på lag 2, der strækker broadcast mellem kontorer, så discovery-protokoller, broadcast-afhængige applikationer og antagelser om delt segment følger ikke med. Udskrivning, navnefremvisning og alt, der afhænger af et lokalt segment, har brug for deres eget design.

VPN-adskillelse er heller ikke kryptering. Labelkommutering holder kunder adskilt inde i udbyderens netværk, og det gør ikke nyttelasten fortrolig, hvis kontrakten kræver fortrolighed. Hvor det betyder noget, skal applikationen eller et overlay levere det.

Endelig skal du holde tjenestemodellen skrevet ned ved siden af stedets routingkonfiguration. Den næste ingeniør, der tilføjer et subnet, bør kunne læse, hvilke præfikser der annonceres, hvem der accepterer dem, og hvad den forventede returvej er: BGP/MPLS IP VPN-specifikationen er referencen for modellen bag det hele.