> nota
Un OUI fantasma: por qué el port-channel SAN no levantaba entre el UCS 6536 y el MDS
En esta nota · 7 secciones
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)0xd7
Lé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 switch
20:00:70:a9:83:14:55:d4
└──┬──┘
OUI = 0x70A983
Y en el MDS, buscando si ese OUI existía en su tabla:
show wwn oui | inc 70a983
Vací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-config
El 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.