Entrega de L3VPN: rutas privadas, unha ruta por defecto ou unha táboa completa?

O seu circuíto está activo, o VRF está configurado e o provedor fai unha pregunta curta que decide o resto do deseño: que debe recibir a bordo do cliente? Tres respostas son habituais e ningunha se deriva de que exista unha pila de etiquetas. Son decisións de servizo sobre onde sae o tráfico da sucursal.

Percorrer a entrega en orde é a forma máis barata de acertar. Comeza polo que ocorre co tráfico que non coincide con nada, logo anota os prefixos privados e o seu comportamento ante fallo, e só entón fala de que tamaño de feed estás disposto a transportar.

Comece polo tráfico que ninguén planificara

Faga unha pregunta antes de que apareza calquera lista de prefixos: cando un paquete non coincide con ningunha ruta privada, onde debe ir? Unha sucursal con circuíto de internet propio adoita manter unha ruta por defecto local, así que o tráfico web ordinario sae polo cortalumes local e nunca toca o provedor. Nese deseño a VPN só transporta os sitios privados remotos, e os prefixos máis específicos fan a selección.

Unha sucursal pensada para usar unha saída central é o caso oposto. Alí a ruta por defecto apunta ao servizo, e o provedor ou o sitio central posúe o reenvío, o retorno e calquera tradución. Dicir "por defecto á VPN" sen ese propietario produce unha sucursal que resolve nomes e non chega a nada.

Os dous deseños difiren en como se ve un fallo de encamiñamento, e por iso adiviñar sae caro. Cunha ruta por defecto local, unha ruta privada perdida envía ese tráfico a internet, onde o cortalumes o descarta ou, peor, responde algo que non pretendía. Cunha ruta por defecto central, a mesma perda elimina por completo o acceso a internet e o ticket chega como "toda a sucursal está caída". Ningún dos dous fallos é incorrecto por si mesmo, pero só un encaixa co servizo que vendeu, e unha configuración BGP por si soa non lle dirá cal construíu.

Anote os prefixos privados co seu caso de fallo

Enumere os prefixos que a sucursal debe alcanzar e indique cales están resumidos. Un agregado un bit demasiado amplo arrastra destinos descoñecidos cara á VPN, o que só é correcto se o lado remoto realmente os posúe e os reenvía.

Despois describa o comportamento previsto cando o servizo privado falla. Unha ruta de descarte retida mantén o tráfico fóra dun camiño non autorizado e produce unha interrupción limpa e esperada. Unha ruta por defecto flotante pode preservar a dispoñibilidade pasando a un camiño de reserva, pero só se o camiño de reserva está autorizado a transportar ese tráfico.

Manteña a dispoñibilidade e o retroceso permitido como dous requisitos separados no documento de entrega. Os equipos que os fusionan acaban discutindo se a sucursal debería ter fallado, en lugar de comprobar se se implementou a política acordada.

Comprobe que instalou realmente o CE

A intención da configuración e o estado de reenvío diverxen con suficiente frecuencia como para que a verificación pertenza á entrega e non á revisión do incidente. Nunha bordo de cliente IOS-XE os tres comandos de abaixo responden tres preguntas distintas: que se ofreceu, que se aceptou e que se está a usar realmente.

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

Execute os tres o día da entrega e non un mes despois, mentres alguén aínda recorda o acordado. A primeira saída depende de soft-reconfiguration inbound ou dunha actualización de rutas almacenada; sen ningunha das dúas, o CE non pode amosarlle que rexeitou. A segunda amosa as rutas aceptadas e as mellores tras a política. A terceira dille onde vai realmente a ruta por defecto, e é a liña máis útil de toda a entrega.

Execute as mesmas comprobacións nun segundo CE se o sitio ten dobre conexión. A aceptación asimétrica entre dous bordos é unha causa habitual de "funciona desde un servidor e desde o outro non", e é invisible nunha diferenza de configuración que parece simétrica.

Cualifique un feed maior en lugar de darlle por suposto

Ás veces o cliente realmente necesita información de rutas de internet dentro do VRF, para encamiñamento por políticas ou para unha saída central que dirixe por prefixo. Iso é un requisito que hai que declarar, acoutar e presupostar, non unha ruta por defecto oculta. Vén con memoria para a RIB e a FIB, CPU para as actualizacións, mantemento de filtros e un propietario da táboa resultante.

Os argumentos de capacidade fallan nas dúas direccións. Unha táboa completa non está prohibida dentro dun VRF, e tampouco é gratuíta. Igualmente, non pode inferir o custo actual dun reconto antigo de rutas, e unha asignación de etiquetas menor non elimina o custo de almacenar rutas.

A especificación BGP/MPLS IP VPN analiza varias disposicións de acceso a internet xunto ao servizo VPN, e non declara obrigatoria unha táboa completa nin unha ruta por defecto para cada cliente, e esa é a sección que merece sinalarse cando aparece unha afirmación sobre a "práctica estándar": RFC 4364.

Pecha a entrega rexistrando o conxunto anunciado, o conxunto recibido e o conxunto seleccionado xunto á política de saída acordada, e probando un destino privado, un destino público previsto e un caso de perda de ruta. Un rexistro asinado desas tres probas resolve máis discusións que calquera afirmación sobre o que fan a maioría das redes.