Resumen

  • Un borrador IETF del 27 de octubre coloca cuatro rutas con el mismo prefijo ante PE1. El router elige la procedente de RD22 para VPN11; el registro BMP entregado al monitor identifica RD11, pero pierde el nombre de RD22. Se conoce el destino de la ruta seleccionada y se pierde su instancia de origen.
  • La revisión 02 propone llevar ese origen también en rutas EVPN tipo 5. El envío del nuevo campo y su lectura son opcionales. El operador tiene que decidir si acepta una supervisión que ve el cruce pero no puede atribuirlo.

El mismo prefijo llama cuatro veces

P1 llega a PE1 desde cuatro instancias VPN en el ejemplo del borrador. PE2 ofrece RD21, RD22 y RD23; PE3 ofrece RD31. Las cuatro rutas comparten un objetivo de importación que permite considerarlas para VPN11. PE1 selecciona la de RD22. Cuando informa al servidor BMP de la ruta presente en la tabla local de VPN11, el mensaje indica P1, un siguiente salto y RD11, la instancia receptora. El monitor no recibe RD22.

El ejemplo no describe una incidencia real. Describe un problema más cotidiano: una organización puede tener una pantalla que muestre una ruta seleccionada y no tener una prueba utilizable de la instancia remota que la suministró. Si RD21 y RD22 ofrecen P1 desde el mismo PE2, el siguiente salto tampoco resuelve el enigma. El informe responde «dónde está P1» y deja sin respuesta «qué frontera cruzó este P1».

El registro del IETF clasifica el texto como Internet-Draft individual. Aún no es un estándar aprobado ni una medición de redes desplegadas. Su fuerza está en identificar una pregunta de gobierno operativo: ¿quién puede dar por completa la vigilancia de transferencias entre instancias si el registro que la sustenta solo conserva el lado receptor?

Una tabla local no es un árbol genealógico

El RFC 9069 añadió a BMP una vista de la Loc-RIB, la tabla de rutas escogidas por el proceso BGP local. Es una ventaja para quien quiere ver la elección del router sin rehacerla a partir de cada anuncio de entrada. Sin embargo, en el encabezado de esa vista la dirección del par se rellena con cero y el distinguidor de ruta identifica la instancia cuya tabla se comunica. En el caso del borrador, RD11 identifica a VPN11. RD22 estaba en los candidatos que vio PE1, pero no en el informe de selección que recibe el servidor BMP.

La pérdida ocurre en la exportación de la observación, no necesariamente en la memoria del router. Esa precisión cambia la solución. Exigir al equipo que «vigile mejor» no sirve si el dato de origen nunca cruzó hacia el colector. El borrador propone un TLV de información de VRF remota que agrega el par AFI/SAFI, un identificador BGP remoto y el distinguidor de ruta remoto. Un registro puede entonces decir RD11 para el receptor y RD22 para la fuente. Dos nombres, dos funciones.

También propone, de manera separada, campos optativos para la etiqueta VPN o el identificador de segmento SRv6 de la ruta remota. Esos datos ayudan a examinar el tratamiento de la ruta. Ninguno reemplaza por sí solo el nombre de la instancia de origen. Quien quiera auditar una regla de importación necesita identificar la ruta seleccionada, la instancia que la recibió y aquella desde la que llegó.

La tentación de simplificar es fuerte. Una política puede permitir cierto objetivo de ruta y una pantalla puede mostrar P1 en la tabla prevista. Pero el control responsable de los cruces entre VRF debe poder detectar cuándo cambia el origen aunque se mantengan el prefijo y el destino. Un registro que omite el origen puede ser técnicamente válido y operacionalmente insuficiente para esa tarea.

EVPN repite la escena con otras puertas

La revisión 01 planteaba el campo para VPN. La revisión 02 añadió un ejemplo de ruta EVPN tipo 5 transferida entre EVI mediante enrutamiento y puente integrados. P1 sale de EVI21 en PE2 y termina en EVI11 en PE1. El informe sin extensión muestra el prefijo en EVI11 y PE2 como siguiente salto; no identifica EVI21. El campo propuesto lleva AFI 25, SAFI 70, el identificador BGP remoto y RD21. Cambia la posibilidad de atribuir un movimiento concreto, sin prometer nada sobre el resultado final del tráfico.

Un borrador distinto sobre estadísticas BMP para EVPN enumera rutas por EVI y contempla recuentos de filtraciones dinámicas entre VRF. Un contador detecta magnitudes. Para explicar cuál de varias EVI proporcionó P1 hace falta un dato por ruta. El número puede avisar; la identidad permite seguir la pista.

La vista Loc-RIB observa una elección BGP. No acredita por sí misma que la ruta se instaló en el plano de reenvío, que pasó un paquete o que cambió un servicio. La nueva información mejora la atribución de la elección. El efecto de red pertenece a otra medición, y mezclar ambos niveles produciría un informe tan vistoso como impreciso.

Dos oportunidades para perder el dato

El emisor BMP que admita la extensión puede añadir el TLV. El colector puede ignorarlo sin romper su compatibilidad con RFC 9069. Los códigos de tipo figuran aún como pendientes de asignación. Un texto publicado y una sesión BMP activa tampoco prueban que el campo salga del router, llegue al almacén, sobreviva a una transformación o aparezca ante el analista.

La sección de seguridad del borrador pide establecer sesiones con dispositivos de monitorización autorizados y confiables. Esa protección atiende a quién recibe el flujo. La decisión de conservar RD22 y usarlo en una regla de alerta sigue dentro de la organización que opera el sistema. Una pantalla verde puede certificar que el colector está conectado mientras el único dato que resolvería una disputa de procedencia se descarta silenciosamente.

Sources