AFI y SAFI: lea el par antes del nombre del servicio

Puede ver cómo una sesión sube, cómo aparece una ruta y aun así estar leyendo el servicio equivocado. El par de números al principio de cada anuncio, el identificador de familia de direcciones y el identificador de familia de direcciones posterior, decide qué analizador lee la carga y qué tabla guarda el resultado. Equivoque el par y la política de importación, la coincidencia del objetivo de ruta y la búsqueda del siguiente salto se ejecutan contra una estructura que nadie anunció. El recorrido de abajo empieza en ese par y termina en el resultado del reenvío.

Dos números deciden a qué tabla pertenece la ruta

El par aparece dos veces: dentro de la capacidad multiprotocolo, donde un hablante anuncia una familia, y delante de cada NLRI que esa familia transporta. Eso lo convierte en una propiedad de la ruta y no en un ajuste de la caja de origen. Los fabricantes lo imprimen como un nombre del tipo Address family VPNv4 Unicast, y la redacción cambia entre versiones mientras los números se quedan en su sitio.

Cuatro codificaciones cubren casi todos los casos empresariales: 1 con 128 para VPN-IPv4 etiquetada con MPLS, 2 con 128 para el equivalente IPv6, 25 con 65 para VPLS señalizado con BGP y 25 con 70 para EVPN. El primer error es suponer que todo servicio Layer 2 vive detrás de 25 con 65, lo que oculta EVPN. El segundo es tratar las dos familias IP como una sola familia con una dirección más larga, cuando se negocian por separado y pueden aceptarse en pares distintos. Un tercero aparece cuando se copia una plantilla de una versión que solo conoce una de ellas. Una consulta al registro resuelve los tres más rápido que una conjetura basada en el nombre del servicio.

Trate las cuatro filas como ejemplos del registro IANA, no como el registro mismo. Cuando un número no coincida con nada que reconozca, búsquelo antes de construir una política a su alrededor.

AFI 25 transporta dos formatos NLRI sin relación

Las dos familias Layer 2 se sientan bajo AFI 25, y el parecido termina ahí. El NLRI de VPLS en RFC 4761 section 3.2.2 transporta una longitud, un distinguidor de ruta, un VE ID, un desplazamiento de bloque VE, un tamaño de bloque VE y una base de etiquetas, que juntos nombran un extremo de pseudowire y su etiqueta. EVPN conserva AFI 25 y pasa a SAFI 70, donde la carga es un tipo de ruta: descubrimiento automático de Ethernet, anuncio MAC/IP, multicast inclusivo, segmento Ethernet, prefijo IP. Por eso el mismo desplazamiento de byte significa cosas distintas en las dos familias. Un analizador escrito para una lee la otra sin quejarse y produce tonterías. El par es la única advertencia de que la interpretación es incorrecta.

Un campo que en una familia significa desplazamiento de bloque VE no tiene contrapartida en la otra, y la ruta de anuncio MAC/IP solo existe en EVPN. Citar un atributo como si se aplicara a ambas es como se estropea una revisión de captura.

Cuando alguien le entregue una captura o una tabla de proveedor, pregunte a qué familia pertenece el atributo. Luego confirme que la implementación receptora admite esa familia, no el nombre del servicio de la hoja de datos. Dos plataformas pueden reclamar ambas soporte de VPLS mientras implementan familias de señalización distintas. El par las separa; la etiqueta del producto no.

La familia de direcciones de la propia sesión es una pregunta aparte

VPN-IPv6 se anuncia habitualmente por una sesión cuya conexión TCP va sobre IPv4, y eso es diseño admitido, no un fallo. Por eso leer solo el resumen de la sesión no dice nada sobre qué familias VPN intercambian los pares.

Familia NLRI, familia de transporte y familia de reenvío son tres decisiones independientes. Un enrutador puede hablar IPv4 con su par, aceptar alcance de VPN-IPv6 e instalar una ruta cuyo siguiente salto sea una dirección IPv6 alcanzable por un camino que usted no pretendía. Cada capa necesita su propia confirmación. Los sitios que informan de destinos IPv6 inalcanzables mientras los anuncios parecen correctos suelen haber perdido la resolución del siguiente salto, no la negociación de familias.

Pruebe la familia de direcciones de la sesión por separado, después las familias que transporta y después lo que el núcleo puede reenviar. Mantener las tres separadas evita el diagnóstico erróneo habitual en el que un anuncio correcto se lee como prueba de que IPv6 funciona de extremo a extremo. Solo prueba que un par le dijo a otro algo sobre un prefijo.

Negociado, recibido, importado, instalado

Para una ruta esperada, cuatro estados deben cumplirse en orden, y cada uno es observable. La familia debe estar negociada con ese par, la ruta debe llegar, un objetivo de ruta debe importarla al contexto previsto y el siguiente salto debe resolverse para que la ruta se instale. Saltarse el primer estado hace irrespondibles los otros tres, porque una familia no negociada no produce rutas que inspeccionar. En plataformas de estilo Cisco los resúmenes de familia y las capacidades por par son comandos separados.

show bgp all summary
show bgp vpnv4 unicast all summary
show bgp l2vpn evpn summary
show bgp neighbors <peer-address> | include Address family

La negociación aparece en el intercambio de capacidades impreso por par, y una sesión establecida sin ninguna familia listada no transporta nada de lo que usted pidió. La importación la deciden los objetivos de ruta transportados como comunidades extendidas, así que un par correcto con un objetivo mal escrito deja la tabla vacía. La instalación depende luego de que el siguiente salto se resuelva en el contexto receptor, lo que puede fallar mientras cada anuncio parece perfecto.

Confirme el plano de datos al final, porque una ruta en la tabla es una afirmación, no una entrega. Los mismos cuatro estados se aplican a cada familia; solo cambian los comandos y los nombres de tabla.

Lo que un par de familias nunca demuestra

Leer bien el par le dice cómo interpretar la información de encaminamiento que sigue, y esa es toda la afirmación. No dice nada sobre alcance, nada sobre política y nada sobre la salud del plano de datos. Confundir las dos cosas produce afirmaciones seguras sobre una red que nadie ha verificado. Un desajuste de objetivo de ruta y un siguiente salto roto parecen idénticos solo mirando el par. El par es una instrucción de lectura, nunca un veredicto.

Cuando escale, ponga el par, el objetivo de ruta y el siguiente salto resuelto en la misma nota. El siguiente ingeniero tiene entonces tres cosas independientes que probar en lugar de un nombre de servicio que reinterpretar. Si falta la negociación lo ven de inmediato, un objetivo equivocado deja la importación visiblemente ausente y un siguiente salto sin resolver deja la ruta presente pero inutilizable.