Asignar un puerto de acceso sin etiqueta al VNI EVPN correcto

Un host Ethernet corriente envía tramas sin etiqueta, y la malla EVPN aun así tiene que transportarlas en el servicio de inquilino correcto. El puerto de acceso clasifica la trama en un segmento local, el VTEP asigna ese segmento a un VNI, y el punto de conexión remoto presenta la trama tal como su host la espera. El VLAN y el VNI identifican partes distintas de esa ruta y no necesitan compartir un número. Siga el runbook siguiente en orden, porque un error en cualquier paso produce el mismo síntoma: un host que transmite y no recibe nada.

Seguir una trama a través de la malla

Para un servicio sencillo basado en VLAN, una ruta ilustrativa es así:

Host A: untagged frame
  to access port: local VLAN 110
  to VTEP A: L2VNI 50110
  to VTEP B: corresponding local service
  to access port: untagged frame to Host B

Los números de VLAN y VNI son ejemplos, no una regla. El VLAN local es una clasificación de entrada que existe en un solo conmutador; el L2VNI es el identificador de servicio de overlay que ambos VTEP entienden. La especificación de overlay RFC 8365 mantiene el identificador de servicio separado de cómo se conecta un host, y nombra tres formas: basada en VLAN, agrupada y consciente del VLAN.

Configurar la clasificación de entrada

El host tiene dirección y no alcanza nada, mientras el propio puerto aparece. Decida en qué modo de conexión está realmente el puerto —un puerto de acceso que transporta tramas sin etiqueta o un trunk con un VLAN nativo— y configure ese de forma explícita. Una trama sin etiqueta sigue saliendo del puerto dentro de un segmento local con nombre, y ese segmento es una decisión y no un efecto secundario de la plataforma. Abra la configuración en ejecución del puerto y lea la clasificación que tiene de verdad en lugar de confiar en un valor por defecto del fabricante que usted nunca definió.

En un conmutador típico la secuencia es un cambio de modo y una asignación de VLAN de acceso, seguidos de una comprobación de que el puerto está realmente up y en ese estado. Si el puerto es un trunk, el VLAN nativo se encarga de las tramas sin etiqueta, y esa es otra configuración con otros modos de fallo. Anote tanto el modo como el VLAN antes de continuar.

show running-config interface Ethernet1/1
show interface Ethernet1/1 switchport
show vlan brief

Configurar el VTEP y la correspondencia de VNI

El VTEP añade la encapsulación VXLAN y el VNI. El host no genera esa cabecera y no necesita saber que el servicio existe.

Asigne el VLAN local al L2VNI con la forma de comando que admite la plataforma y mantenga esa correspondencia coherente en ambos extremos del servicio. Un L2VNI de inquilino y el L3VNI usado para el enrutamiento entre subredes son objetos distintos, y mezclar sus números rompe el enrutamiento sin tocar la ruta L2; y recuerde que una ruta de underlay funcional hacia el VTEP remoto pertenece a otra capa más del montaje.

Si la correspondencia es errónea, la trama entra igualmente en la malla y simplemente aterriza en el servicio equivocado. Por eso la comprobación es una comprobación de servicio y no una comprobación de enlace.

Configurar la presentación de salida

En el extremo lejano el servicio recibido tiene que volver a convertirse en lo que el host espera: Ethernet desnudo en un puerto de acceso, una etiqueta concreta en un trunk que usted controla, y un tratamiento de la etiqueta interna que coincida con el modelo de servicio elegido. Revise la lista de VLAN permitidas en el trunk antes de culpar al overlay, porque una etiqueta que el trunk de salida no permite se descarta después de que el overlay ya haya hecho su trabajo. Confirme que el host remoto espera la presentación que recibe y no la que su diagrama supuso.

Que una etiqueta interna sobreviva es una propiedad del modelo de servicio que eligió, así que ningún artículo puede prometer en general que se elimine o se conserve. Un diseño que supone un comportamiento y una plataforma que implementa el otro pasarán una prueba de enlace y fallarán en la aplicación.

Lea juntos el aprendizaje MAC local, la ruta de servicio EVPN y la correspondencia del punto de conexión remoto, y active el descubrimiento de vecinos que necesita la aplicación en lugar de solo un ping. Una dirección MAC aprendida en otro dominio de puente puede ser perfectamente válida allí y aun así apuntar al servicio equivocado.

Verificar con un solo par de hosts

Levante un par de hosts y demuestre la ruta completa antes de añadir un segundo par. Después lea el estado en ambos VTEP y confirme que el mismo identificador de servicio aparece en los dos extremos.

show mac address-table vlan 110
show bgp l2vpn evpn
show nve peers

Para cada extremo anote cuatro valores: la presentación del puerto, el segmento local, el L2VNI y la presentación inversa en la salida. Ese registro permite al siguiente ingeniero ver por qué el host tiene una conexión simple sin etiqueta mientras la malla transporta un servicio de inquilino. Si un cambio falla, devuelva el puerto a su VLAN anterior y vuelva a probar el mismo par, para que la reversión sea un estado conocido y no una suposición.