Intermitencias de segundos en red VXLAN EVPN tras migrar a OpenShift

Una red VXLAN EVPN basada en Nexus 9000 y Catalyst 9k empezó a presentar pérdidas de conectividad de capa 3 de apenas unos segundos. El síntoma se repite varias veces al día y afecta a todos los sub‑redes dentro del mismo VRF, mientras que la capa 2 sigue operando sin incidentes según Zabbix.

Los componentes involucrados son un par de service leafs (vPC) que albergan las SVI con política de ePBR para redirigir el tráfico inter‑VLAN al firewall Palo Alto (activo/pasivo). El firewall, a su vez, devuelve el tráfico a los service leafs. La ruta estática del firewall apunta al VIP de HSRP del par vPC. Los leafs aprenden la red 172.16.0.0/16 desde un leaf Catalyst que la inyecta mediante L2VNI. La topología física es:

[Fw]---/29---[service leafs pair]---[spines]---[cat9k leaf]

A nivel de recursos, tanto los leafs Nexus como el Catalyst operan con una utilización de CPU del 1‑3 % y el firewall muestra una carga similar. El tráfico total es inferior a 800 Mbps en enlaces de 40 Gbps, por lo que la saturación no explica el comportamiento.

El autor sospecha que la migración reciente a OpenShift, que introdujo contenedores y virtualización, pudo haber alterado la interacción entre la capa 2 VNI y la política de ePBR. No se han realizado cambios de configuración en la red desde hace varios meses, y los dispositivos corren versiones estables: Nexus 10.5.4, Catalyst 17.15.4b y Palo Alto 11.14.0.

Para diagnosticar, se recomienda:

• Verificar los logs de control plane de los Nexus y del Catalyst en los momentos de caída, buscando eventos de BGP, OSPF o EVPN.
• Correlacionar los timestamps con los registros del firewall (session table, HA sync) y con los eventos de OpenShift (pod start/stop, CNI).
• Revisar la tabla de ARP y la tabla de MAC en los leafs para detectar flapping de entradas que pueda desencadenar re‑learning.
• Activar el monitoreo de latencia en los paths inter‑leaf y hacia el firewall, usando herramientas como ping‑continuous o sFlow.
• Considerar la posibilidad de un bug de hardware/firmware que cause interrupciones breves en el dataplane; en caso de confirmarse, abrir un caso con Cisco TAC.

Aunque la causa exacta aún no está clara, el hecho de que la capa 2 se mantenga estable mientras la capa 3 se interrumpe sugiere un problema en la ruta de re‑encaminamiento o en la interacción entre ePBR y la tabla de rutas del firewall. La resolución probablemente requiera una revisión conjunta de la configuración de EVPN, los filtros de política y la integración con la solución de contenedores.

En conclusión, la red sigue siendo funcional, pero estas breves pérdidas pueden impactar aplicaciones sensibles a la latencia. La prioridad es aislar si el origen está en los leafs Nexus, el firewall o la capa de virtualización, y aplicar correcciones de firmware o ajustes de política según corresponda.