L3VPN-overlevering: private ruter, en standardrute eller en full tabell?

Kretsen din er oppe, VRF-en er konfigurert, og leverandøren stiller et kort spørsmål som avgjør resten av designet: hva kundekanten skal motta? Tre svar er vanlige, og ingen av dem følger av at det finnes en etikettstabel. De er tjenestebeslutninger om hvor trafikken forlater filialen.

Å gå gjennom overleveringen i rekkefølge er den billigste måten å få dette riktig på. Du starter med hva som skjer med trafikk som ikke treffer noe, skriver deretter ned de private prefiksene og feiloppførselen deres, og først da snakker du om hvor stor feed du er villig til å bære.

Begynn med trafikken ingen planla for

Still ett spørsmål før noen prefiksliste dukker opp: når en pakke ikke treffer noen privat rute, hvor skal den gå? En filial med egen internettlinje beholder vanligvis en lokal standardrute, slik at vanlig netttrafikk går ut gjennom den lokale brannmuren og aldri berører leverandøren. I det designet bærer VPN-en bare de eksterne private nettstedene, og de mer spesifikke prefiksene gjør utvelgelsen.

En filial som skal bruke en sentral utgang er det motsatte tilfellet. Der peker standardruten inn i tjenesten, og leverandøren eller det sentrale nettstedet eier videresending, returrutting og eventuell oversettelse. Å si "standard til VPN" uten den eieren gir en filial som løser navn og ikke når noe.

De to designene skiller seg i hvordan en rutingsfeil ser ut, og derfor er gjetting dyrt. Med en lokal standardrute sender en tapt privat rute den trafikken ut på internett, der brannmuren slipper den eller, verre, noe du ikke mente svarer. Med en sentral standardrute fjerner det samme tapet internettilgangen helt, og saken kommer inn som "hele filialen er nede". Ingen av feilene er gale i seg selv, men bare én samsvarer med tjenesten du solgte, og en BGP-konfigurasjon alene forteller deg ikke hvilken du bygde.

Skriv ned de private prefiksene med feiltilfellet deres

List opp prefiksene filialen må nå, og noter hvilke som er oppsummert. Et aggregat som er én bit for bredt trekker ukjente destinasjoner inn i VPN-en, og det er bare greit hvis den andre siden faktisk eier dem og videresender dem.

Beskriv så den tiltenkte oppførselen når den private tjenesten svikter. En beholdt forkastningsrute holder trafikken unna en uautorisert vei og gir et rent, forventet avbrudd. En flytende standardrute kan opprettholde tilgjengeligheten ved å flytte til en reservevei, men bare hvis reserveveien har tillatelse til å bære den trafikken.

Hold tilgjengelighet og tillatt reservevei som to separate krav i overleveringsdokumentet. Team som slår dem sammen, ender med å krangle om filialen burde ha feilet, i stedet for å sjekke om den avtalte policyen ble implementert.

Sjekk hva CE faktisk installerte

Konfigurasjonshensikt og videresendingstilstand divergerer ofte nok til at verifisering hører hjemme i overleveringen, ikke i hendelsesgjennomgangen. På en IOS-XE kundekant svarer de tre kommandoene nedenfor på tre ulike spørsmål: hva som ble tilbudt, hva som ble akseptert, og hva som faktisk brukes.

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

Kjør alle tre på overleveringsdagen og ikke en måned senere, mens noen ennå husker hva som ble avtalt. Den første utdataen avhenger av soft-reconfiguration inbound eller en lagret route refresh; uten ett av dem kan ikke CE vise deg hva den avviste. Den andre viser aksepterte og beste ruter etter policy. Den tredje forteller hvor standardruten egentlig går, og det er den enkeltlinjen som er mest nyttig i hele overleveringen.

Kjør de samme kontrollene på en andre CE hvis nettstedet er dobbeltilkoblet. Asymmetrisk aksept mellom to kanter er en vanlig årsak til "det virker fra én server og ikke fra den andre", og det er usynlig i en konfigurasjonsdiff som ser symmetrisk ut.

Kvalifiser en større feed i stedet for å forutsette den

Noen ganger trenger kunden virkelig internett-ruteinformasjon inne i VRF-en, for policyrutting eller for en sentral utgang som styrer etter prefiks. Det er et krav som skal angis, avgrenses og prises, ikke en skjult standardrute. Det kommer med minne for RIB og FIB, CPU for oppdateringer, filtervedlikehold og en eier for tabellen som oppstår.

Kapasitetsargumenter går galt i begge retninger. En full tabell er ikke forbudt inne i en VRF, og den er ikke gratis heller. På samme måte kan du ikke utlede dagens kostnad fra et gammelt ruteantall, og en mindre etikettildeling fjerner ikke kostnaden ved å lagre ruter.

Spesifikasjonen BGP/MPLS IP VPN drøfter flere internettilgangsordninger ved siden av selve VPN-tjenesten og erklærer ikke en full tabell eller en standardrute som obligatorisk for hver kunde, og det er det avsnittet det er verdt å peke på når en påstand om "standard praksis" dukker opp: RFC 4364.

Avslutt overleveringen ved å registrere settet som annonseres, settet som mottas og settet som velges ved siden av den avtalte utgangspolicyen, og ved å teste én privat destinasjon, én tiltenkt offentlig destinasjon og ett tilfelle av rutetap. En signert protokoll fra de tre testene avgjør flere diskusjoner enn noen påstand om hva de fleste nettverk gjør.