Lliurament L3VPN: rutes privades, una ruta per defecte o una taula completa?

El vostre circuit funciona, el VRF està configurat i el proveïdor fa una pregunta curta que decideix la resta del disseny: què ha de rebre la vora del client? Tres respostes són habituals i cap no es deriva del fet que existeixi una pila d’etiquetes. Són decisions de servei sobre on surt el trànsit de la sucursal.

Recórrer el lliurament en ordre és la manera més barata d’encertar-ho. Comenceu per què passa amb el trànsit que no coincideix amb res, després anoteu els prefixos privats i el seu comportament en cas de fallada, i només llavors parleu de quina mida de feed esteu disposats a portar.

Comenceu pel trànsit que ningú no havia planificat

Feu una pregunta abans que aparegui cap llista de prefixos: quan un paquet no coincideix amb cap ruta privada, on ha d’anar? Una sucursal amb circuit d’internet propi normalment manté una ruta per defecte local, així que el trànsit web ordinari surt pel tallafoc local i no toca mai el proveïdor. En aquest disseny la VPN només transporta els llocs privats remots, i els prefixos més específics fan la selecció.

Una sucursal pensada per utilitzar una sortida central és el cas oposat. Allà la ruta per defecte apunta cap al servei, i el proveïdor o el lloc central posseeix l’encaminament, el retorn i qualsevol traducció. Dir "per defecte a la VPN" sense aquest propietari produeix una sucursal que resol noms i no arriba enlloc.

Els dos dissenys difereixen en com es veu una fallada d’encaminament, i per això endevinar surt car. Amb una ruta per defecte local, una ruta privada perduda envia aquest trànsit a internet, on el tallafoc el descarta o, pitjor, respon alguna cosa que no volíeu. Amb una ruta per defecte central, la mateixa pèrdua elimina del tot l’accés a internet i el tiquet arriba com "tota la sucursal està caiguda". Cap de les dues fallades no és incorrecta per si mateixa, però només una encaixa amb el servei que heu venut, i una configuració BGP per si sola no us dirà quina heu construït.

Anoteu els prefixos privats amb el seu cas de fallada

Lliste els prefixos que la sucursal ha d’assolir i indiqueu quins estan resumits. Un agregat un bit massa ampli arrossega destinacions desconegudes cap a la VPN, cosa que només és correcta si el costat llunyà realment les posseeix i les encamina.

Després descriviu el comportament previst quan el servei privat falla. Una ruta de descart retinguda manté el trànsit fora d’un camí no autoritzat i produeix una interrupció neta i esperada. Una ruta per defecte flotant pot preservar la disponibilitat passant a un camí de reserva, però només si el camí de reserva està autoritzat a portar aquest trànsit.

Manteniu la disponibilitat i el retorn permès com dos requisits separats al document de lliurament. Els equips que els fusionen acaben discutint si la sucursal hauria d’haver fallat, en lloc de comprovar si la política acordada es va implementar.

Comproveu què ha instal·lat realment el CE

La intenció de la configuració i l’estat d’encaminament divergeixen prou sovint perquè la verificació pertanyi al lliurament i no a la revisió de l’incident. En una vora de client IOS-XE les tres ordres de sota responen tres preguntes diferents: què es va oferir, què es va acceptar i què s’està utilitzant realment.

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

Executeu les tres el dia del lliurament i no un mes després, mentre algú encara recorda què es va acordar. La primera sortida depèn de soft-reconfiguration inbound o d’un refresc de rutes emmagatzemat; sense cap dels dos, el CE no us pot mostrar què va rebutjar. La segona mostra les rutes acceptades i les millors després de la política. La tercera us diu on va realment la ruta per defecte, que és la línia més útil de tot el lliurament.

Executeu les mateixes comprovacions en un segon CE si el lloc té doble connexió. L’acceptació asimètrica entre dues vores és una causa habitual de "funciona des d’un servidor i no des de l’altre", i és invisible en una diferència de configuració que sembla simètrica.

Qualifiqueu un feed més gran en lloc de pressuposar-lo

De vegades el client necessita realment informació de camins d’internet dins del VRF, per a encaminament per política o per a una sortida central que dirigeix per prefix. Això és un requisit que cal declarar, acotar i pressupostar, no una ruta per defecte amagada. Arriba amb memòria per a la RIB i la FIB, CPU per a les actualitzacions, manteniment de filtres i un propietari per a la taula resultant.

Els arguments de capacitat fallen en les dues direccions. Una taula completa no està prohibida dins d’un VRF, i tampoc no és gratuïta. Igualment, no podeu inferir el cost d’avui a partir d’un recompte antic de rutes, i una assignació d’etiquetes més petita no elimina el cost d’emmagatzemar rutes.

L’especificació BGP/MPLS IP VPN discuteix diverses disposicions d’accés a internet al costat del servei VPN mateix, i no declara obligatòria una taula completa ni una ruta per defecte per a cada client, i aquesta és la secció que val la pena assenyalar quan apareix una afirmació sobre la "pràctica estàndard": RFC 4364.

Tanqueu el lliurament registrant el conjunt anunciat, el conjunt rebut i el conjunt seleccionat al costat de la política de sortida acordada, i provant una destinació privada, una destinació pública prevista i un cas de pèrdua de ruta. Un registre signat d’aquestes tres proves resol més discussions que qualsevol afirmació sobre què fan la majoria de xarxes.