L3VPN-overdragelse: private ruter, en standardrute eller en fuld tabel?

Din forbindelse er oppe, VRF’en er konfigureret, og udbyderen stiller et kort spørgsmål, der afgør resten af designet: hvad skal kundekanten modtage? Tre svar er almindelige, og ingen af dem følger af, at der findes en labelstak. Det er servicebeslutninger om, hvor trafikken forlader filialen.

At gennemgå overdragelsen i rækkefølge er den billigste måde at få det rigtigt. Du starter med, hvad der sker med trafik, der ikke matcher noget, skriver derefter de private præfikser og deres fejlopførsel ned, og taler først derefter om, hvor stor et feed du er villig til at bære.

Begynd med trafikken, som ingen havde planlagt

Stil ét spørgsmål, før nogen præfikseliste dukker op: når en pakke ikke matcher nogen privat rute, hvor skal den så hen? En filial med sin egen internetforbindelse holder normalt en lokal standardrute, så almindelig webtrafik forlader gennem den lokale firewall og rører aldrig udbyderen. I det design bærer VPN’en kun de fjerne private lokaliteter, og de mere specifikke præfikser foretager valget.

En filial, der skal bruge en central udgang, er det modsatte tilfælde. Der peger standardruten ind i tjenesten, og udbyderen eller det centrale site ejer videresendelse, returrouting og eventuel oversættelse. At sige "standard til VPN’en" uden den ejer giver en filial, der opløser navne og ikke når noget.

De to designs adskiller sig i, hvordan en routingfejl ser ud, og derfor er gætteri dyrt. Med en lokal standardrute sender en tabt privat rute den trafik til internettet, hvor firewallen dropper den eller, værre, noget du ikke havde tænkt på svarer. Med en central standardrute fjerner samme tab internetadgangen helt, og sagen kommer ind som "hele filialen er nede". Ingen af fejlene er forkerte i sig selv, men kun én af dem passer til den service, du solgte, og en BGP-konfiguration alene fortæller dig ikke, hvilken du byggede.

Skriv de private præfikser ned sammen med deres fejlscenarie

List de præfikser, som filialen skal nå, og noter, hvilke der er summariseret. Et aggregat, der er én bit for bredt, trækker ukendte destinationer ind i VPN’en, hvilket kun er i orden, hvis den fjerne side faktisk ejer og videresender dem.

Beskriv derefter den tilsigtede opførsel, når den private service fejler. En fastholdt discard-rute holder trafik væk fra en uautoriseret vej og giver et rent, forventet udfald. En flydende standardrute kan bevare tilgængeligheden ved at skifte til en backup-vej, men kun hvis backup-vejen har tilladelse til at bære den trafik.

Hold tilgængelighed og tilladt tilbagefald som to adskilte krav i overdragelsesdokumentet. Teams, der slår dem sammen, ender med at diskutere, om filialen burde være fejlet, i stedet for at kontrollere, om den aftalte politik blev implementeret.

Kontrollér, hvad CE’en faktisk installerede

Konfigurationshensigt og videresendelsestilstand afviger ofte nok til, at verifikation hører i overdragelsen og ikke i hændelsesgennemgangen. På en IOS-XE-kundekant besvarer de tre kommandoer nedenfor tre forskellige spørgsmål: hvad der blev tilbudt, hvad der blev accepteret, og hvad der faktisk bruges.

show ip bgp vpnv4 vrf BRANCH neighbors 192.0.2.1 received-routes
show ip bgp vpnv4 vrf BRANCH
show ip route vrf BRANCH 0.0.0.0

Kør alle tre på overdragelsesdagen i stedet for en måned senere, mens nogen stadig husker, hvad der blev aftalt. Det første output afhænger af soft-reconfiguration inbound eller en gemt ruteopdatering; uden et af dem kan CE’en ikke vise dig, hvad den afviste. Det andet viser accepterede og bedste ruter efter politik. Det tredje fortæller dig, hvor standardruten faktisk går hen, og det er den enkelt mest nyttige linje i hele overdragelsen.

Kør de samme kontroller på en anden CE, hvis lokaliteten er dobbeltforbundet. Asymmetrisk accept mellem to kanter er en almindelig årsag til "det virker fra den ene server og ikke den anden", og det er usynligt i en konfigurationsforskel, der ser symmetrisk ud.

Kvalificér et større feed i stedet for at forudsætte det

Nogle gange har kunden reelt brug for internetruteinformation inde i VRF’en, til policy routing eller til en central udgang, der styrer efter præfiks. Det er et krav, der skal erklæres, afgrænses og prissættes, ikke en skjult standardrute. Det kommer med hukommelse til RIB og FIB, CPU til opdateringer, vedligeholdelse af filtre og en ejer af den resulterende tabel.

Kapacitetsargumenter går galt i begge retninger. En fuld tabel er ikke forbudt inde i en VRF, og den er heller ikke gratis. På samme måde kan du ikke udlede dagens pris af et gammelt ruteantal, og en mindre labeltildeling fjerner ikke omkostningen ved at gemme ruter.

BGP/MPLS IP VPN-specifikationen drøfter flere internetadgangsordninger ved siden af selve VPN-tjenesten og erklærer ikke en fuld tabel eller en standardrute obligatorisk for hver kunde, og det er det afsnit, der er værd at pege på, når en påstand om "standardpraksis" dukker op: RFC 4364.

Afslut overdragelsen ved at registrere det annoncerede sæt, det modtagne sæt og det valgte sæt ved siden af den aftalte udgangspolitik, og ved at teste én privat destination, én tilsigtet offentlig destination og ét rutetabsscenarie. En underskrevet registrering af de tre tests afgør flere diskussioner end nogen udtalelse om, hvad de fleste netværk gør.