L3VPN-oorgawe: private roetes, ’n verstekroete of ’n volle voer?

Jou kring is op, die VRF is opgestel, en die verskaffer vra ’n kort vraag wat die res van die ontwerp bepaal: wat moet die kliëntekant ontvang? Drie antwoorde is algemeen, en nie een volg uit die feit dat daar ’n etiketstapel bestaan nie. Dit is diensbesluite oor waar verkeer die tak verlaat.

Om die oorgawe in volgorde te deurloop is die goedkoopste manier om dit reg te kry. Jy begin by wat met verkeer gebeur wat niks pas nie, skryf dan die private prefikse en hul foutgedrag neer, en praat eers daarna oor hoe groot ’n voer jy bereid is om te dra.

Begin by die verkeer waarvoor niemand beplan het nie

Vra een vraag voordat enige prefikslys verskyn: waarheen moet ’n pakket gaan wanneer dit geen private roete pas nie? ’n Tak met sy eie internetkring hou gewoonlik ’n plaaslike verstek, so gewone webverkeer verlaat deur die plaaslike firewall en raak nooit die verskaffer nie. In daardie ontwerp dra die VPN slegs die afgeleë private terreine, en die meer spesifieke prefikse doen die keuse.

’n Tak wat bedoel is om ’n sentrale uitgang te gebruik, is die teenoorgestelde geval. Daar wys die verstek in die diens in, en die verskaffer of sentrale terrein besit die aanstuur, die terugroete en enige vertaling. Om "verstek na die VPN" te sê sonder daardie eienaar lewer ’n tak wat name oplos en niks bereik nie.

Die twee ontwerpe verskil in hoe ’n roetefout lyk, en daarom is raai duur. Met ’n plaaslike verstek stuur ’n verlore private roete daardie verkeer na die internet, waar dit deur die firewall laat val word of, erger, deur iets beantwoord word wat jy nie bedoel het nie. Met ’n sentrale verstek verwyder dieselfde verlies internettoegang heeltemal, en die kaartjie kom aan as "die hele tak is af". Nie een van die foute is op sigself verkeerd nie, maar net een pas by die diens wat jy verkoop het, en ’n BGP-konfigurasie alleen sal jou nie sê watter een jy gebou het nie.

Skryf die private prefikse neer saam met hul foutgeval

Lys die prefikse wat die tak moet bereik en merk watter van hulle saamgevat is. ’n Samevatting wat een bis te breed is, trek onbekende bestemmings in die VPN in, wat net goed is as die ver kant hulle werklik besit en aanstuur.

Beskryf dan die beoogde gedrag wanneer die private diens faal. ’n Behoue verwerpingsroete hou verkeer van ’n ongemagtigde pad af en lewer ’n skoon, verwagte onderbreking. ’n Swewende verstek kan beskikbaarheid behou deur na ’n rugsteunpad te skuif, maar net as die rugsteunpad gemagtig is om daardie verkeer te dra.

Hou beskikbaarheid en toegelate terugval as twee afsonderlike vereistes in die oorgawedokument. Spanne wat hulle saamsmelt, eindig met ’n argument oor of die tak moes gefaal het, in plaas daarvan om te kyk of die ooreengekome beleid geïmplementeer is.

Kyk wat die CE werklik geïnstalleer het

Konfigurasiebedoeling en aansturtoestand wyk dikwels genoeg uiteen dat verifiëring in die oorgawe hoort, nie in die voorvaloorsig nie. Op ’n IOS-XE-kliëntekant beantwoord die drie opdragte hieronder drie verskillende vrae: wat aangebied is, wat aanvaar is en wat werklik gebruik word.

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

Voer al drie op die dag van die oorgawe uit eerder as ’n maand later, terwyl iemand nog onthou wat ooreengekom is. Die eerste uitset hang af van soft-reconfiguration inbound of ’n gestoorde roete-verfrissing; sonder een van die twee kan die CE jou nie wys wat dit verwerp het nie. Die tweede wys aanvaarde en beste paaie ná beleid. Die derde sê vir jou waar die verstek werklik heen gaan, en dit is die enkele nuttigste reël in die hele oorgawe.

Voer dieselfde kontroles op ’n tweede CE uit as die terrein dubbelgehuisves is. Asimmetriese aanvaarding tussen twee kante is ’n algemene oorsaak van "dit werk van een bediener en nie van die ander nie", en dit is onsigbaar in ’n konfigurasieverskil wat simmetries lyk.

Kwalifiseer ’n groter voer in plaas van om een aan te neem

Soms het die kliënt werklik internetpadinligting binne die VRF nodig, vir beleidsroetering of vir ’n sentrale uitgang wat volgens prefiks stuur. Dit is ’n vereiste om te stel, te omlyn en te prys, nie ’n verborge verstek nie. Dit kom met geheue vir die RIB en FIB, rekenkrag vir opdaterings, filteronderhoud en ’n eienaar vir die resulterende tabel.

Kapasiteitsargumente gaan in beide rigtings verkeerd. ’n Volle tabel is nie binne ’n VRF verbode nie, en dit is ook nie verniet nie. Net so kan jy nie vandag se koste uit ’n ou roetetal aflei nie, en ’n kleiner etikettoekenning verwyder nie die koste van die stoor van roetes nie.

Die BGP/MPLS IP VPN-spesifikasie bespreek verskeie internettoegangreëlings naas die VPN-diens self, en dit verklaar nie ’n volle tabel of ’n verstek verpligtend vir elke kliënt nie, en dit is die afdeling om na te wys wanneer ’n bewering oor "standaardpraktyk" opduik: RFC 4364.

Sluit die oorgawe deur die geadverteerde stel, die ontvangde stel en die gekose stel langs die ooreengekome uitgangsbeleid op te teken, en deur een private bestemming, een bedoelde openbare bestemming en een geval van roeteverlies te toets. ’n Getekende rekord van daardie drie toetse besleg meer argumente as enige stelling oor wat die meeste netwerke doen.