Un C9300 deja de pasar tráfico y al reaplicar la VLAN avisa de que la crea
Un administrador de red describe un caso sin confirmar: el puerto figuraba como conectado, el LED estaba en ámbar y no cursaba tráfico. Quitar y reaplicar la configuración del puerto lo arregló.
Un administrador de red ha descrito un comportamiento raro en un stack de Cisco Catalyst C9300 con IOS XE: un puerto de acceso aparecía como conectado en show interface status, pero no pasaba ni un paquete. En el equipo físico, el LED estaba en ámbar. La solución fue borrar la configuración del puerto y volver a aplicarla, y al reintroducir la VLAN de acceso el switch soltó un mensaje inesperado: % Access VLAN does not exist. Creating vlan 2. La VLAN 2 existía, y otros puertos seguían cursando tráfico por ella sin problema.
El síntoma y lo que no funcionó
La configuración era mínima: interface GigabitEthernet2/0/2, switchport access vlan 2, switchport mode access y spanning-tree portfast. El show int status daba el puerto como connected, en la VLAN 2, a-full y a-1000 sobre 10/100/1000BaseTX. El plano de control lo daba por bueno. En el sitio, el técnico veía el LED ámbar y ningún tráfico. Un shut/no shut no cambió nada.
Lo que sí funcionó fue quitar la configuración del puerto y volver a ponerla. Al reescribir la sentencia de VLAN de acceso saltó ese aviso de creación de la VLAN 2, y a partir de ahí el puerto levantó y empezó a pasar tráfico.
La hipótesis del autor es que la programación de VLAN a puerto de ese puerto, o de ese miembro del stack, se había desincronizado respecto a la configuración en ejecución, y que reaplicar la VLAN forzó al switch a reprogramarla. No ha encontrado un bug ID que encaje con el caso, y tampoco concreta la versión de IOS XE que llevaba el stack.
Lo que pide a quien lo haya visto
Sus preguntas son dos: si alguien se ha topado con ese mensaje de "no existe, la creo" para una VLAN que está activa en otros puertos, y qué conviene capturar antes de tocar el puerto si vuelve a reproducirse.
Ahí está el valor del hilo, y también su límite. No hay confirmación del fabricante, ni bug ID, ni trazas, ni versión. Es un caso aislado contado por alguien que se lo encontró en producción, con un remedio que funcionó una vez.
Un puerto que miente en show int status es de los fallos que más tiempo cuestan, porque todas las comprobaciones habituales salen bien y el problema está en la programación interna del ASIC. Si aparece el mismo mensaje en un stack, reaplicar la configuración del puerto es un remedio barato. Antes de hacerlo, conviene guardar show vlan, la configuración en ejecución del puerto y el estado del stack: si el fallo resulta ser un bug conocido, esos datos son los que pide el TAC.


