Hay bugs que se resuelven en cinco minutos y bugs que te comen una mañana entera porque el log apunta para el lado equivocado. Este es del segundo tipo, y lo escribo porque es 100% reproducible: si alguna vez migras de un UCS-FI-6248 o 6300 a la serie 6500 contra un MDS con NX-OS viejo, te va a pasar exactamente lo mismo.
El escenario
Migración de Fabric Interconnects: salían un par de FI viejos y entraban dos UCS-FI-6536 nuevos, conectados contra los MDS 9148 del cliente por F-port-channel-trunk. Todo lo demás del cambio estaba limpio. Los hosts veían storage, el cómputo arriba, los uplinks Ethernet sin drama.
El único problema era el SAN, y era uno raro. Con el F-port-channel-trunk configurado, los puertos FC se iban a errDisable y el port-channel nunca formaba. Y pasaba en los dos fabrics por igual: FI-A contra su MDS y FI-B contra el suyo, el mismo síntoma. Daba lo mismo si los dejaba como miembros del PC o probaba un puerto suelto con trunking: el resultado era el mismo, abajo y en error.
El log que te manda a perseguir fantasmas
En el FI el mensaje era este:
%PORT-5-IF_DOWN_ERROR_DISABLED: %$VSAN ...%$ Interface fc1/30 is down (Error disabled)
pm_process_fport_vf_tagging_capability: port fc1/30 attempting vf tagging on non-cisco switch
pi_fsm_port_attr_change_init: Ifindex (fc1/30)0x101d000, Err disabled event (PI_FSM_EV_PORT_CONFIG_FAILURE)0xd7Léelo de nuevo: “attempting vf tagging on non-cisco switch”. El FI estaba diciendo que el MDS, un switch Cisco de pies a cabeza, no era Cisco. Ahí uno ya sabe que la pista verdadera no es la que parece.
Lo que NO era (pero te tienta)
Antes de llegar al fondo perdí un rato en dos sospechosos típicos:
El fill-pattern. Es la respuesta clásica para los enlaces FC que no negocian, sobre todo a 8G. Toqué switchport fill-pattern IDLE por inercia. No movió la aguja, porque el enlace acá negociaba a 16G y el fill-word no tenía nada que ver.
La velocidad y el cable. También descartados. El óptico marcaba potencia de RX sana y no había errores de CRC ni de sincronismo. Si fuera capa física el síntoma sería otro: no_light, el link flapeando o errores subiendo, no un errDisable seco por fallo de configuración.
El detalle que ordena todo: el puerto tenía luz buena y aun así caía con un PI_FSM_EV_PORT_CONFIG_FAILURE apenas intentaba el trunk. Eso no es capa física, es negociación de protocolo. Y la frase “non-cisco switch” apuntaba justo ahí.
La causa real: un OUI que el MDS no tenía en su base
Cada switch Cisco tiene un Switch WWN, y los primeros tres bytes de ese WWN son el OUI (el identificador de fabricante). El FI 6536 trae un OUI nuevo, 0x70A983, que salió mucho después que el NX-OS que corría el MDS.
El MDS estaba en NX-OS 8.3(2), liberado en diciembre de 2018, más de cuatro años antes de que existiera el primer 6536. Su base de datos de OUIs simplemente no incluía el 0x70A983. Resultado: cuando el FI intentaba formar el F-port-channel-trunk, el MDS miraba el OUI del peer, no lo reconocía, y lo trataba como un switch ajeno. De ahí el “non-cisco switch” y el errDisable.
Lo confirmé en 30 segundos. En el FI:
connect nxos a
show wwn switch20:00:70:a9:83:14:55:d4
└──┬──┘
OUI = 0x70A983Y en el MDS, buscando si ese OUI existía en su tabla:
show wwn oui | inc 70a983Vacío. El MDS no tenía idea de quién era ese fabricante.
El fix
NX-OS deja agregar el OUI a mano en el MDS. La línea decisiva es una sola, wwn oui, pero la apliqué junto con las features del trunk para dejar el port-channel completo y forzar el re-negociado:
config t
wwn oui 0x70a983
!
interface port-channel 1
shutdown
no shutdown
end
!
copy running-config startup-configEl flap del port-channel al final es lo que obliga a renegociar con el OUI ya cargado. Apenas hice no shutdown, el PC levantó y se quedó arriba. Caso cerrado en el fabric B.
El fabric A fue idéntico, y acá va un dato útil: los dos FI del par venían del mismo lote, así que el OUI era el mismo (0x70A983). Cambia solo el identificador único del chasis (14:55:d4 vs 14:e4:44), no el OUI. Aun así, conviene verificar con show wwn switch antes de aplicar, porque si el lote fuera distinto el valor cambia y te ahorras un debug al pedo.
El fix de verdad: subir el NX-OS
Agregar el OUI a mano funciona y es estable, pero es un parche. El arreglo permanente es subir el MDS a una versión que ya traiga el OUI en su base. Cisco empezó a actualizar la tabla de OUIs alrededor de 8.4(2c), y la recomendada para convivir con los FI de quinta generación es NX-OS 9.4(3b). La matriz oficial de compatibilidad de Cisco para FI vs MDS pide mínimo 9.2 para el 6536 y recomienda 9.4. El 8.3(2) ni siquiera figura como interoperable.
Si vas a dejar el wwn oui manual por ahora, déjalo documentado en el MOP, porque un reemplazo futuro de supervisor o un reload con config limpia te lo borra.
Por qué vale la pena anotarlo
Este caso normalmente termina en un TAC de varios días, no porque sea difícil de arreglar, sino porque el log te miente con elegancia. El “non-cisco switch” hace que medio mundo se vaya a revisar zoning, ópticos o fill-word, cuando el problema está tres bytes más arriba.
Si te toca, parte por mirar el OUI del switch nuevo y revisa si el otro extremo lo conoce. Es lo primero, no lo último.
Para el que quiera ir a las fuentes, los IDs que documentan esta familia de problemas son CSCvk63036, CSCwn74098 y CSCuz11494, más la KB de Dell 000291922 y el doc de Cisco TAC 217690.
Agregar un comentario
Debes iniciar sesión para comentar.