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

Kretsen din er oppe, VRF-en er konfigurert, og leverandøren stiller eit kort spørsmål som avgjer resten av designet: kva kundekanten skal ta imot? Tre svar er vanlege, og ingen av dei følgjer av at det finst ein etikettstabell. Dei er tenestebeslutningar om kvar trafikken forlèt filialen.

Å gå gjennom overleveringa i rekkjefølgje er den billegaste måten å få dette rett på. Du byrjar med kva som skjer med trafikk som ikkje treff noko, skriv deretter ned dei private prefiksa og feilåtferda deira, og først då snakkar du om kor stor feed du er viljug til å bera.

Byrj med trafikken ingen planla for

Still eitt spørsmål før noka prefiksliste dukkar opp: når ein pakke ikkje treff noka privat rute, kvar skal han gå? Ein filial med eiga internettlinje held vanlegvis ei lokal standardrute, slik at vanleg nettraflikk går ut gjennom den lokale brannmuren og aldri rører leverandøren. I det designet ber VPN-en berre dei eksterne private nettstadene, og dei meir spesifikke prefiksa gjer utvalet.

Ein filial som skal bruke ein sentral utgang er det motsette tilfellet. Der peikar standardruta inn i tenesta, og leverandøren eller den sentrale nettstaden eig vidaresending, returruting og eventuell omsetjing. Å seie "standard til VPN" utan den eigaren gir ein filial som løyser namn og ikkje når noko.

Dei to designa skil seg i korleis ein rutefeil ser ut, og difor er gjetting dyrt. Med ei lokal standardrute sender ei tapt privat rute den trafikken ut på internett, der brannmuren slepp han eller, verre, noko du ikkje meinte svarar. Med ei sentral standardrute fjernar det same tapet internettilgangen heilt, og saka kjem inn som "heile filialen er nede". Ingen av feila er gale i seg sjølv, men berre éin svarar til tenesta du selde, og ein BGP-konfigurasjon åleine fortel deg ikkje kva du bygde.

Skriv ned dei private prefiksa med feiltilfellet deira

List opp prefiksa filialen må nå, og noter kva som er oppsummert. Eit aggregat som er éin bit for breitt dreg ukjende destinasjonar inn i VPN-en, og det er berre greitt om den andre sida faktisk eig dei og vidaresender dei.

Skildre så den tiltenkte åtferda når den private tenesta sviktar. Ei halden forkastingsrute held trafikken unna ein uautorisert veg og gir eit reint, venta avbrot. Ei flytande standardrute kan halde oppe tilgjengelegheita ved å flytte til ein reserveveg, men berre om reservevegen har løyve til å bera den trafikken.

Hald tilgjengelegheit og tillaten reserveveg som to separate krav i overleveringsdokumentet. Team som slår dei saman, endar med å krangle om filialen burde ha feila, i staden for å sjekke om den avtalte policyen vart gjennomført.

Sjekk kva CE faktisk installerte

Konfigurasjonshensikt og vidaresendingstilstand skil seg ofte nok til at verifisering høyrer heime i overleveringa, ikkje i hendingsgjennomgangen. På ein IOS-XE kundekant svarar dei tre kommandoane nedanfor på tre ulike spørsmål: kva som vart tilbode, kva som vart godteke, og kva som faktisk blir brukt.

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øyr alle tre på overleveringsdagen og ikkje ein månad seinare, medan nokon enno hugsar kva som vart avtalt. Den første utdataen avheng av soft-reconfiguration inbound eller ein lagra route refresh; utan eitt av dei kan ikkje CE vise deg kva han avviste. Den andre viser godtekne og beste ruter etter policy. Den tredje fortel kvar standardruta eigentleg går, og det er den eine linja som er mest nyttig i heile overleveringa.

Køyr dei same kontrollane på ein andre CE om nettstaden er dobbeltilkopla. Asymmetrisk aksept mellom to kantar er ein vanleg årsak til "det virkar frå éin server og ikkje frå den andre", og det er usynleg i ein konfigurasjonsdiff som ser symmetrisk ut.

Kvalifiser ein større feed i staden for å føresette han

Nokre gonger treng kunden verkeleg internett-ruteinformasjon inne i VRF-en, for policyruting eller for ein sentral utgang som styrer etter prefiks. Det er eit krav som skal angivast, avgrensast og prisast, ikkje ei skjult standardrute. Det kjem med minne for RIB og FIB, CPU for oppdateringar, filtervedlikehald og ein eigar for tabellen som oppstår.

Kapasitetsargument går gale i begge retningar. Ein full tabell er ikkje forboden inne i ein VRF, og han er ikkje gratis heller. På same måte kan du ikkje utleie dagens kostnad frå eit gammalt ruteantal, og ein mindre etikettildeling fjernar ikkje kostnaden ved å lagre ruter.

Spesifikasjonen BGP/MPLS IP VPN drøftar fleire internettilgangsordningar ved sida av sjølve VPN-tenesta og erklærer ikkje ein full tabell eller ei standardrute som obligatorisk for kvar kunde, og det er det avsnittet det er verdt å peike på når ein påstand om "standard praksis" dukkar opp: RFC 4364.

Avslutt overleveringa ved å registrere settet som blir annonsert, settet som blir motteke og settet som blir valt ved sida av den avtalte utgangspolicyen, og ved å teste éin privat destinasjon, éin tiltenkt offentleg destinasjon og eitt tilfelle av rutetap. Ein signert protokoll frå dei tre testane avgjer fleire diskusjonar enn nokon påstand om kva dei fleste nettverk gjer.