Verificación de óptica en un conmutador

Una vez que un módulo está en un puerto, cada NOS tiene un comando para mostrar su identidad y su DDM. Úselo para confirmar que el conmutador ve el módulo como usted espera — y para contrastarlo con lo que leyó CodingBox.

Comandos por NOS

NOS	Comando
Cisco IOS / IOS-XE	`show interfaces <if> transceiver detail`
Cisco NX-OS	`show interface <if> transceiver details`
Juniper Junos	`show interfaces diagnostics optics <if>`
Arista EOS	`show interfaces <if> transceiver detail`
Huawei VRP	`display transceiver interface <if> verbose`
Aruba CX	`show interface <if> transceiver detail`

Qué buscar

Identidad — el nombre del fabricante, el número de parte y el número de serie coinciden con lo previsto.
DDM — la temperatura, la tensión, la polarización y la potencia óptica están dentro de rango (el conmutador lee el mismo diagnóstico SFF-8472 que muestra CodingBox).
Errores — una nota "unsupported transceiver" apunta al bloqueo de fabricante.

Contraste con CodingBox

Compare la salida del conmutador con el resumen de transceptor de la aplicación. Si el conmutador no coincide con lo que CodingBox leyó en el banco, la diferencia está en cómo el conmutador interpreta o filtra el módulo — no en la memoria del módulo.

Comandos específicos de DDM por plataforma, volcados en crudo de ethtool, OID de SNMP y rutas de OpenConfig: Lectura del DDM con herramientas.

Configurar lo que verificó — velocidad, FEC, breakout, anulaciones por NOS: Recetas de configuración de puertos; por qué una plataforma rechazó un módulo: Cómo valida cada NOS un módulo.

Los mismos datos por SNMP y telemetría en streaming — objetos MIB por fabricante, rutas de transceptor de OpenConfig, mensajes de syslog para alertar: Gestión y monitorización; nombres de interfaz usados en estos comandos: Nombres de puertos y LED.

Si encuentra una inexactitud o un error en este material, seleccione el fragmento correspondiente y pulse Ctrl+Enter para .