Necesita VPNv4 MPLS no núcleo? Non necesariamente
BGP VPNv4 negocia un contexto de distribución de rutas, non unha ruta de reenvío. Separe a importación, a resolución do seguinte salto e a encapsulación que pode executar.
Activar a familia de enderezos VPNv4 entre dous routers só crea un contexto de distribución de rutas e nada máis. Non instala unha ruta de reenvío nin indica que encapsulación levará un paquete de cliente ata o punto final remoto. Unha vez separados eses dous feitos, a pregunta «necesita isto MPLS no núcleo» convértese nunha cuestión máis estreita e respondible sobre o plano de datos que admite a plataforma.
Que negocia realmente a familia de enderezos
BGP multiprotocolo transporta a información de alcanzabilidade da capa de rede VPNv4 baixo AFI 1 e SAFI 128, e cada entrada emparexa un distinguidor de ruta cun prefixo e cunha etiqueta. A sesión negocia que ambos os interlocutores poden codificar e descodificar esa información. O que non negocia é un plano de datos. Todo o que segue este parágrafo refírese ao reenvío, e nada diso queda resolvido polo establecemento da sesión.
Así que unha sesión correcta é proba de capacidade do plano de control, non do reenvío. Un router pode manter miles de entradas VPNv4 e aínda así descartar cada paquete de cliente, e por iso as dúas clases de fallo se confunden desde o principio.
Fíxese na etiqueta do NLRI. É unha etiqueta de servizo, ligada a un prefixo dentro dunha VRF, e ten un papel de reenvío cando o paquete chega ao punto final de saída. Se algún dispositivo de tránsito a le é unha decisión de deseño aparte.
Recepción, importación e reenvío son tres pasos
Recibir unha ruta, ter permiso para usala e poder reenviar con ela realízanos partes distintas do equipo. BGP almacena o que oe; a política de importación e a coincidencia de obxectivo de ruta deciden que VRF pode considerala; despois o plano de reenvío debe resolver o seguinte salto anunciado en algo que realmente poida pór nun cable.
| Step in the chain | What has to be true | How it fails quietly |
|---|---|---|
| NLRI exchange | Both speakers negotiate the VPNv4 capability | Session stays up while the family is never activated |
| Import eligibility | A route target on the received route matches the VRF import policy | The route exists in the table but never enters the VRF |
| Next-hop resolution | The advertised next hop resolves to a usable tunnel or label path | Best path is selected, then marked unreachable or unusable |
| Encapsulation | The egress endpoint can decapsulate what the ingress produced | Packets arrive and are discarded for a format mismatch |
É nese paso intermedio onde viven os fallos máis sorprendentes. Unha ruta pode estar presente na táboa BGP, válida e mesmo ser a mellor, mentres a táboa de rutas da VRF queda baleira porque ningún obxectivo de ruta coincidiu coa lista de importación. Nada rexistra un erro de protocolo, porque non se produciu ningún erro de protocolo.
O último paso é onde se nota o soporte da plataforma. Un seguinte salto alcanzable na capa subxacente non se resolve automaticamente como transporte de servizo VPN, e o equipo pode esixir un tipo de túnel concreto, unha operación de etiqueta concreta ou ambas as cousas. Ler o estado de resolución é máis informativo que ler o reconto de rutas.
Un núcleo IP pode transportar unha pila que nunca conmuta
A distinción que merece conservarse é entre «o núcleo non executa MPLS» e «non existe ningunha etiqueta no servizo». Son afirmacións distintas, e só a primeira fala de dispositivos de tránsito. RFC 4023 define o transporte de MPLS por túneles IP ou GRE, e ese é o mecanismo que fai posible a segunda afirmación nun núcleo totalmente IP.
customer packet + service label
encapsulated in GRE, addressed to the egress tunnel endpoint
forwarded by ordinary IP routers on the outer header
decapsulated at the endpoint, label still meaningfulOs routers de tránsito reenvían polo destino IP exterior e non necesitan nin os prefixos de cliente nin a conmutación de etiquetas nativa. No extremo afastado retírase o túnel exterior e a etiqueta de servizo retoma o seu traballo. O núcleo moveu unha carga opaca, que é exactamente para o que serve unha rede IP.
O que este deseño non lle dá é unha garantía universal. Non é proba de que cada router resolva cada seguinte salto VPNv4 por calquera interface GRE, nin é motivo para borrar unha configuración MPLS nativa que funciona. É un contraexemplo á afirmación universal, e a pregunta práctica segue a ser local á plataforma. Anote esa pregunta como unha limitación da plataforma e non como unha regra do protocolo.
Percorra a cadea no equipo ata que se rompa
Comece pola ruta recibida e detéñase no primeiro paso que falle, porque os pasos posteriores non se poden diagnosticar mentres un anterior está roto. Catro comandos cobren boa parte diso nunha implementación típica.
show bgp vpnv4 unicast all summary
show bgp vrf CUSTOMER_A ip route 198.51.100.0/24
show ip route vrf CUSTOMER_A 198.51.100.0
show mpls forwarding-table vrf CUSTOMER_ALéaos como unha secuencia e non como catro comprobacións independentes. O primeiro confirma que a familia está activa e que o veciño intercambia rutas; o segundo mostra se o prefixo chegou cun seguinte salto utilizábel; o terceiro demostra a elixibilidade para a importación; o cuarto mostra se o plano de reenvío lle ligou unha etiqueta ou un túnel.
Despois probe o camiño da carga de traballo en ambas as direccións, cunha MTU que sobreviva á encapsulación. GRE engade bytes de cabeceira, e un camiño que supera sondas pequenas pode fallar en paquetes de tamaño completo só nunha dirección, o que parece un fallo de aplicación e non de transporte.
Dúas notas operativas pechan o círculo. GRE é encapsulación, non confidencialidade, así que unha rede de tránsito non fiable necesita unha disposición de seguridade admitida por riba e non unha suposición. E anote que encapsulación admite realmente a plataforma antes da revisión de deseño, porque esa única resposta decide se un núcleo só IP é unha opción válida ou un plan que non pode reenviar.