El uplink de 100GE de un Huawei CE6800 hacia un Profitap XX-3200G nunca sube con ópticos SR4
Sustituyendo la pareja de agregación existente del cliente por equipos CloudEngine, y el único enlace que se resiste a subir es la alimentación de 100GE hacia su packet broker. Todo lo demás en el switch se puso en marcha sin drama.
- Huawei CloudEngine 6800, puerto de 100GE
- Módulos QSFP28 100GBASE-SR4, referencias Huawei, uno en cada extremo
- Packet broker Profitap XX-3200G en el otro lado
Ambos extremos ven su módulo. El log del switch solo tiene entradas de inserción y extracción de transceptor de cuando estuve reasentando cosas, ninguna alarma en absoluto, y la interfaz simplemente se queda down:
<CE6800> display interface 100GE1/0/1
...
FEC : RS-FECProbado hasta ahora:
- cambié ambos módulos por repuestos y limpié los extremos MPO, sin cambios;
- moví el enlace a otro puerto de 100GE del switch;
- comprobé el lado del broker, detecta su módulo y no reporta nada malo.
Así que los ópticos se reconocen en ambos extremos, nada se queja, y no hay enlace. ¿Qué más tiene que coincidir entre un puerto de 100GE de CloudEngine y un equipo de terceros para que el enlace entrene?
Show original (English)
Also available in: English
العربية
Deutsch
Español
Français
हिन्दी
Bahasa Indonesia
Italiano
日本語
한국어
Nederlands
Polski
Português
Русский
Türkçe
Tiếng Việt
简体中文
Comments 3
Esto es un desajuste de FEC. CloudEngine activa RS-FEC por defecto en puertos de 100GE con ópticos SR4, el broker no tiene ningún ajuste de FEC y por tanto corre sin él, y dos extremos que no coinciden en FEC nunca terminan de entrenar. No hay nada roto, así que no se registra nada, por eso el log solo tiene tus mensajes de inserción y extracción.
Apágalo en el switch, en la vista de interfaz:
undo fec modehace lo mismo. La segunda línea es la que importa. CE usa configuración en dos etapas, y unfec mode nonesin commit se ve perfectamente correcto cuando relees la configuración mientras el puerto sigue exactamente tan down como antes. He visto un caso de cliente alargarse un día extra por esa razón, con todos convencidos de que el FEC ya estaba desactivado.Después del commit,
display interfacedebería mostrar FEC: NONE y el puerto debería entrenar.Si el extremo lejano llegara a tener un ajuste de FEC, la mejor solución es activar RS-FEC ahí y dejar el switch en su valor por defecto, ya que en 100G en realidad quieres la corrección. Entre dos fabricantes distintos, yo fijaría el FEC explícitamente en ambos lados en lugar de confiar en que se negocie.
¿Qué dice el broker sobre FEC de su lado, si dice algo? Tú mismo ya publicaste la mitad interesante: el puerto del switch está corriendo RS-FEC. Huawei es explícito en que ambos extremos de un enlace de 100GE deben usar el mismo modo de FEC, o de lo contrario las interfaces nunca suben, y ese fallo se ve exactamente como el tuyo: ambos módulos sanos, sin alarma, sin log, puerto down.
La mayoría de los packet brokers y taps con los que he trabajado ni siquiera exponen un ajuste de FEC, lo que significa que corren sin él y el switch es el lado que tiene que ceder. Confirma eso primero, y luego cambia una sola cosa.
Vale la pena añadir que el valor por defecto de CloudEngine no es único, depende del módulo. El QSFP28-100G-LR4 y el QSFP28-100G-LR1 corren con FEC apagado según IEEE 802.3, mientras que todos los demás tipos QSFP28 traen el FEC activado por defecto. Así que el consejo de simplemente desactivarlo es incorrecto en un enlace LR4, donde el switch ya está apagado y el desajuste vive en el otro extremo.
Dos reglas más del mismo capítulo que me han pillado:
Así que comprueba qué tienes realmente en la mano con
display transceiver interface 100GE1/0/1 verboseantes de decidir hacia qué lado empujar el FEC, y recuerda el commit en cualquier caso.