Resolución de problemas de la tarjeta Cisco ONS 15454 ML
Contenido
Introducción
Este documento utiliza una topología de prueba sencilla para describir cómo resolver problemas de tarjetas de varias capas (ML) en Cisco ONS 15454. La sección Apéndice proporciona algunos comandos de configuración básicos e información detallada sobre la topología.
La prueba utiliza un enfoque empírico para comprender los fallos de red asociados con las tarjetas ML. La prueba inyecta fallas o configuraciones conocidas para capturar y analizar los resultados esperados. Los casos prácticos de aislamiento de fallas presentan estos hallazgos.
El documento sigue las metodologías típicas de solución de problemas. El documento presenta un síntoma y analiza los pasos de aislamiento de fallas relevantes, y también proporciona procedimientos genéricos de troubleshooting.
Prerequisites
Requirements
Cisco recomienda que tenga conocimiento sobre estos temas:
-
Cisco ONS 15454
-
Tarjetas Ethernet ONS de Cisco serie 15454 ML
-
IOS de Cisco
-
Bridging and IP Routing
Componentes Utilizados
La información que contiene este documento se basa en las siguientes versiones de software y hardware.
-
Router 7603 de Cisco que ejecuta la versión 12.1(13)E13 del software del IOS® de Cisco
-
Cisco ONS 15454 que ejecuta Cisco ONS versión 4.1.3
-
ML (incluido como parte de la versión ONS 4.1.3) que ejecuta la versión 12.1(19)EO1 del software del IOS de Cisco
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Convenciones
Arquitectura básica ML
Las tarjetas de la serie ML de Cisco para la plataforma ONS 15454 proporcionan conectividad Ethernet de 10/100/1000 Mbps a través de SONET/SDH en las capas 2 y 3. Cada tarjeta ML del chasis ejecuta una imagen IOS independiente. La creación de un circuito de conexión cruzada en el controlador de transporte de Cisco (CTC) entre puertos ML crea puertos virtuales de backend Packet over SONET (POS). En las versiones de software 4.6 y posteriores, siempre se produce la creación de puertos POS, pero los puertos sólo aparecen cuando se crea un circuito de conexión cruzada en CTC.
La tarjeta ML1000-2 tiene dos puertos POS (0 y 1). Cada puerto tiene un ancho de banda de señal de transporte síncrono (STS)-24c y un total de STS-48c por tarjeta. Cada puerto POS admite subinterfaces para permitir el enlace troncal VLAN. La asignación física de un puerto POS a un puerto óptico ocurre durante la fase de creación del circuito y puede cambiar durante el cambio de tramo óptico. Por lo tanto, dos puertos POS en dos extremos del circuito son peers y sus configuraciones deben coincidir.
El mapping entre un puerto Ethernet y un puerto POS depende del requisito de topología. La topología de switching de Capa 2 vincula estos dos tipos de puertos con el mismo número de grupo de bridges. La topología de Capa 3 enruta paquetes entre estas interfaces.
Topología de prueba básica
La figura 1 representa la topología de prueba:
Figura 1: Topología de prueba 
Para configurar la topología de prueba:
-
Conecte dos routers Cisco 7603 a nodos ONS a través de Gigabit Ethernet y asegúrese de que ambos puertos en los dos routers estén en la misma subred IP. Aquí, cada nodo ONS tiene una tarjeta ML1000-2 en la ranura 12.
-
Configure un bridge-group 100 para Gig0 y POS0 en ambos nodos ONS.
Nota: No es necesario utilizar POS1 en esta prueba.
El circuito entre los dos puertos ML POS0 es STS-12c.
-
Inhabilite el IP Routing en las tarjetas ML.
-
Proveer protección OC12 1+1 entre los dos nodos ONS. Consulte la figura 1 para obtener la información pertinente.
Nota: Ambos nodos ONS ejecutan Cisco ONS Release 4.1.3.
Casos prácticos de inserción de fallos
Esta sección examina los resultados de varios fallos conocidos y algunas operaciones comunes. Cada caso práctico describe la operación y los resultados en ML y ONS.
Información general
Algunos comandos relevantes para resolver problemas en el IOS ML
show ons alarm
show ip interface brief
clear counters
show interface summary
show interface
show controller pos show cdp neighbor show bridge verbose show vlans
show sdm l2-switching forwarding show ons provisioning-agent message ports show running show log show tech-support
Asegúrese de utilizar una marca de hora correcta para el registro del búfer y compruebe si la comunicación y el control de temporización (TCC) se ha establecido con la fecha y hora correctas. A continuación se muestra un ejemplo de resultado de configuración en ML:
service timestamps debug uptime service timestamps log datetime msec localtime logging buffered 4096 debugging
Estas alarmas activan automáticamente el cambio de estado del link POS:
PAIS PLOP PTIM PUNEQ PRDI PPLM PPDI BER_SF_B3
Nota: La plataforma ONS 15454 utiliza dos formatos para informar alarmas. Por ejemplo, PAIS aparece en IOS (ML), mientras que AIS-P aparece en CTC. PAIS y AIS-P representan el mismo tipo de alarma.
Verificaciones comunes en CTC
Alarms Conditions History Circuit Inventory Port PM counters Diagnostics file Audit trail
-
En la tarjeta ML:
-
Puertos Ether de Mantenimiento/Rendimiento: verifique si hay errores.
-
Puertos POS de mantenimiento/rendimiento: verifique si hay errores.
-
-
En la tarjeta de trabajo OC12:
-
Habilite IPPM en Provisioning/SONET STS.
-
Rendimiento: verifique si hay errores.
-
Estudios de casos
En esta sección se describen varios posibles puntos de fallo y se explica cómo capturar la información correcta para la resolución de problemas.
Desconexión Ethernet
Esta alarma aparece en .225 cuando se extrae el cable Ethernet:
.225ML12#show ons alarm Equipment Alarms Active: None Port Alarms POS0 Active: None POS1 Active: None GigabitEthernet0 Active: CARLOSS GigabitEthernet1 Active: None POS0 Active Alarms : None Demoted Alarms: None POS1 Interface not provisioned
Nota: Si fuerza la interfaz ML GigE, ML no se da cuenta de que el link está inactivo.
La misma alarma aparece en el CTC de 0,225 (véase la Figura 2).
Figura 2: Alarma en CTC 
La pérdida del vecino 7603a del protocolo de detección de Cisco (CDP) confirma el problema.
Nota: El estado de GigE 0 no afecta a la interfaz POS 0 (la interfaz sigue en Up/Up).
Switch de protección OC12
El switch de protección OC12 no crea ninguna alarma o error.
Ambos OC12 fuera de servicio (OOS)
Cuando ambos puertos OC12 en el nodo .252 cambian a OOS, .225 informa AIS-P, lo que hace que la interfaz POS 0 se desactive y conduce a TPTFAIL.
.225ML12#show ons alarm Equipment Alarms Active: RUNCFG-SAVENEED Port Alarms POS0 Active: TPTFAIL POS1 Active: None GigabitEthernet0 Active: None GigabitEthernet1 Active: None POS0 Active Alarms : PAIS Demoted Alarms: None POS1 Interface not provisioned
Switch lateral XC
Esta entrada de registro aparece en el ML del nodo que se conmuta XC. Tenga en cuenta que el XCON B es la ranura 10 XC.
May 24 09:55:27.402: %CARDWARE-5-XCON_SWITCH: Switched XCON to B May 24 09:55:27.406: %CARDWARE-6-BTC_DRV: Init BTC, BTC Rev = 2, Backplane = 0, Port = 0
Switch lateral TCC
La figura 3 muestra la alarma registrada.
Figura 3: Alarma del switch lateral TCC 
Nota: Si utiliza CTC o Telnet inverso para conectarse a la tarjeta ML, perderá la conexión a la tarjeta ML.
Después de unos minutos, la alarma debe despejarse. Estas entradas de registro aparecen en ML:
May 24 10:29:09.258: %CARDWARE-5-SOCKET_INFO: closed socket to TCC: changed active TCC May 24 10:29:09.766: %ONS-6-VTY: All Vty lines cleared May 24 10:29:14.762: %CARDWARE-5-SOCKET_INFO: cannot connect socket to TCC: B May 24 10:29:20.270: %CARDWARE-5-SOCKET_INFO: cannot connect socket to TCC: B May 24 10:29:25.770: %CARDWARE-5-SOCKET_INFO: cannot connect socket to TCC: B May 24 10:29:31.270: %CARDWARE-5-SOCKET_INFO: cannot connect socket to TCC: B May 24 10:29:36.370: %CARDWARE-5-SOCKET_INFO: open socket to TCC: B May 24 10:29:41.166: %CARDWARE-6-BTC_DRV: Init BTC, BTC Rev = 2, Backplane = 0, Port = 0.
El TCC activo actual también aparece en este resultado. La ranura 11 TCC es TCC B, mientras que la ranura 7 es TCC A.
.252ML12#show ons equipment-agent status
EQA ---- phySlot: 12, eqptType: EQPT_L2SC, eqptID: 0x2403 ----
curTCC: Tcc B
linkStatus: Full dbReq/Recv: 7 / 7 msgVerToEQM: 2
socketFd: 0 pipeMsgAct: No hdrSizeToEQM: 28
connTries: 0 connTimerFast: No hdrSizeFromEQM: 28
timingProv: No
clock auto 1
Eliminación y creación del circuito
La extracción del circuito de conexión cruzada crea estas entradas de registro:
May 27 17:40:48.459: %VIRTUAL_PA-6-PAREMOVED: POS interface [0] has been removed due to circuit deletion May 27 17:40:48.511: %CARDWARE-6-BTC_DRV: Init BTC, BTC Rev = 2, Backplane = 0, Port = 0.
La configuración del puerto se cambia a medida que lo ve desde ML.
.225ML12#show ons provisioning-agent m ports all ----- Backend Port (00) Data ----- prov: no sts: xx vt: xx type: xxx name: xxxxx ----- Backend Port (01) Data ----- prov: no sts: xx vt: xx type: xxx name: xxxxx
La creación de un circuito STS3c actualiza la información del puerto en ML. El tamaño del circuito también aparece en la salida del controlador POS 0.
.225ML12#show ons provisioning-agent m ports all ----- Backend Port (00) Data ----- prov: yes sts: 00 vt: 255 type: DOS name: ----- STS (00) Term Strip ----- Admin State: IS Direction: TX_RX_EQPT Type: 3 Sf: 1E-4 Sd: 1E-7 C2 tx/exp: 0x01 / 0x01 PathTrace Format: 64Byte Mode: OFF expected: (not valid) send: valid: "\000\000\000\000" ----- VT (255) Term Strip not provisioned ----- ----- STS (00) Xc Strip ----- rate: 3 Admin: IS Src Port/STS: 0x09/0x00 STS Eqpt: 0x01 Dest Port/STS: 0x06/0x00 UPSR STS Cont Dest: 0x00 Prev STS Stich Dest Port/STS: 0xFF/0x00 Next STS Stich Dest Port/STS: 0xFF/0x00 ----- Backend Port (01) Data ----- prov: no sts: xx vt: xx type: xxx name: xxxxx
Aparecen estas entradas de registro:
May 27 17:47:08.711: %VIRTUAL_PA-6-PAPLUGGEDIN: POS interface [0] has been created due to circuit creation May 27 17:47:08.715: %CARDWARE-6-BTC_DRV: Init BTC, BTC Rev = 2, Backplane = 0, Port = 0. May 27 17:47:08.915: %LINK-3-UPDOWN: Interface POS0, changed state to up May 27 17:47:09.927: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS0, changed state to up
Loopbacks
La aplicación de un loop de instalación al puerto OC12 activo en .225 hace que el .225 ML informe la alarma TPTFAIL. Esta alarma también aparece en las listas de alarmas ML.
Nota: Si habilita loopbacks en una trayectoria activa, se produce una pérdida de tráfico.
.225ML12#show ons alarm Equipment Alarms Active: None Port Alarms POS0 Active: TPTFAIL POS1 Active: None GigabitEthernet0 Active: None GigabitEthernet1 Active: None POS0 Active Alarms : PAIS Demoted Alarms: None POS1 Interface not provisioned
Nota: Cuando utiliza un anillo de paquete flexible (RPR) en lugar del OC-12 1+1, como en esta prueba, cierre las interfaces POS antes de habilitar loopbacks. Tal loopback en RPR causa pérdida de tráfico, porque la trayectoria de protección no vuelve a rutear el tráfico.
Cambio de fecha y hora
La configuración de fecha y hora incorrecta en el TCC crea esta entrada en el registro:
2d23h: %CARDWARE-5-CLOCK_ERR: cannot set time-of-day, (invalid IOS time set on TCC)
Cuando cambia la fecha y la hora, esta entrada aparece en el registro ML.
2d23h: %CARDWARE-5-CLOCK_INFO: system clock, timezone, and summertime configured
Una actualización automática ocurre en el reloj del sistema IOS basado en el reloj de TCC. Puede verificar esta actualización a través del comando show clock.
Nota: Puede utilizar el comando service timestamps para configurar los sellos debug y log time para utilizar la nueva información del reloj.
Una interfaz POS cerrada
Cuando se apaga la interfaz POS 0 en .225 ML, se producen algunas alarmas y condiciones (ver Figura 4).
Figura 4: Alarmas y condiciones que ocurren cuando se cierra la interfaz POS 0 
AIS-P se produce para ambos puertos OC12 en .252. Luego se produce TPTFAIL para ML en .252. En la ruta de acceso de retorno, .225 informa Path Payload Defect Indication (PPDI, también llamado PDI-P), tanto para los puertos OC-12 como para RFI-P para el puerto OC-12 en funcionamiento.
En .225 ML, aparecen estas alarmas:
.225ML12#show ons alarm Equipment Alarms Active: RUNCFG-SAVENEED Port Alarms POS0 Active: None POS1 Active: None GigabitEthernet0 Active: None GigabitEthernet1 Active: None POS0 Active Alarms : PRDI PPDI Demoted Alarms: None POS1 Interface not provisioned
Estas entradas de registro también aparecen en .225:
May 24 10:52:01.802: %LINK-5-CHANGED: Interface POS0, changed state to administratively down May 24 10:52:02.801: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS0, changed state to down May 24 10:52:04.021: %SONET-4-ALARM: POS0: PRDI May 24 10:52:04.269: %SONET-4-ALARM: POS0: PPDI
En .252, estas alarmas ocurren:
.252ML12#show ons alarm Equipment Alarms Active: None Port Alarms POS0 Active: TPTFAIL POS1 Active: None GigabitEthernet0 Active: None GigabitEthernet1 Active: None POS0 Active Alarms : PAIS Demoted Alarms: None POS1 Interface not provisioned
De manera similar, las entradas de registros en .252 indican que el motivo del evento POS 0 down es PAIS. Esto es coherente con las alarmas o condiciones que informa el Comité contra el Terrorismo.
May 24 10:51:48.969: %VIRTUAL_PA-6-UPDOWN: POS0 changed to down due to PAIS defect trigger changing state May 24 10:51:49.169: %LINK-3-UPDOWN: Interface POS0, changed state to down May 24 10:51:50.169: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS0, changed state to down May 24 10:51:51.169: %SONET-4-ALARM: POS0: PAIS
Puede confirmar este hecho a través de este resultado:
.252ML12#show contro pos 0 | inc Active Active Alarms : PAIS Active Defects: PAIS
Cuando se activa la interfaz POS 0, estas entradas de registro aparecen en .252 ML:
May 24 11:16:17.509: %VIRTUAL_PA-6-UPDOWN: POS0 changed to up due to PAIS defect trigger changing state May 24 11:16:17.709: %LINK-3-UPDOWN: Interface POS0, changed state to up May 24 11:16:18.709: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS0, changed state to up May 24 11:16:27.309: %SONET-4-ALARM: POS0: PAIS cleared
Estas son las entradas de registro en .225 ML:
May 24 11:16:30.607: %VIRTUAL_PA-6-UPDOWN: POS0 changed to up due to PPDI defect trigger changing state May 24 11:16:30.807: %LINK-3-UPDOWN: Interface POS0, changed state to up May 24 11:16:31.555: %SYS-5-CONFIG_I: Configured from console by vty0 (127.0.0.100) May 24 11:16:31.807: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS0, changed state to up May 24 11:16:40.175: %SONET-4-ALARM: POS0: PRDI cleared May 24 11:16:40.415: %SONET-4-ALARM: POS0: PPDI cleared
Ahora el tráfico vuelve a la normalidad.
Discordancia CRC POS
Cuando el CRC no coincide en ambos puertos POS del mismo circuito (por ejemplo, un lado 16 bits, mientras que el otro lado 32 bits), no se producen alarmas en el TCC ni en el ML. Ambos puertos POS siguen activos, pero el tráfico no fluye. Estos son algunos síntomas:
-
Los dos contadores de error de entrada de la interfaz POS se incrementan con un 100% debido a CRC. En este caso, CRC cambia a 16 bits en .225 ML mientras que .252 ML todavía tiene el CRC predeterminado de 32 bits. La interfaz POS0 en .252 ML muestra un recuento de errores CRC y de entrada similar.
.225ML12#show int pos 0 POS0 is up, line protocol is up Hardware is Packet/Ethernet over Sonet, address is 000f.2475.8c00 (bia 000f.2475.8c00) MTU 1500 bytes, BW 622080 Kbit, DLY 100 usec, reliability 149/255, txload 1/255, rxload 1/255 Encapsulation ONS15454-G1000, crc 16, loopback not set Keepalive set (10 sec) Scramble enabled ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:06:57, output never, output hang never Last clearing of "show interface" counters 00:04:28 Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 0 bits/sec, 0 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 0 packets input, 11190 bytes Received 0 broadcasts (0 IP multicast) 0 runts, 0 giants, 0 throttles 0 parity 138 input errors, 138 CRC, 0 frame, 0 overrun, 0 ignored 0 input packets with dribble condition detected 178 packets output, 15001 bytes, 0 underruns 0 output errors, 0 applique, 0 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions -
Los recuentos de errores CRC de entrada del controlador POS aumentan.
.225ML12#show contro pos 0 | inc input 8841 total input packets, 46840204 post-HDLC bytes 0 input short packets, 46840993 pre-HDLC bytes 0 input long packets , 3893 input runt packets 2165 input CRCerror packets , 0 input drop packets 0 input abort packets 0 input packets dropped by ucode
-
CDP vecino a través de las caídas de trayectoria óptica. Aunque POS0 está activo y CDP funciona, el vecino en POS0 no aparece.
225ML12#show cdp neighbor Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone Device ID Local Intrfce Holdtme Capability Platform Port ID 7603a Gig 0 170 R S I Cat 6000 Gig 1/1 .225ML12#show cdp int | be POS0 POS0 is up, line protocol is up Encapsulation Sending CDP packets every 60 seconds Holdtime is 180 seconds
Discordancia de codificación POS
Con la encapsulación PPP, puede habilitar la codificación SPE (de forma predeterminada, la codificación SPE está desactivada). En este ejemplo, .225ML POS0 tiene activada la codificación mientras que .252ML POS0 tiene la configuración predeterminada.
.225ML12#show int pos 0 | in Scramble Scramble enabled
La discordancia de codificación cambia el valor C2. Si habilita la codificación, las interfaces POS utilizan un valor C2 de 0x16. Si inhabilita la codificación, las interfaces POS utilizan un valor C2 de 0xCF. Cuando habilita la codificación en el puerto .252 POS 0, éste es el resultado (la configuración .225 POS 0 no cambia):
.252ML12#show contr pos 0 | in C2 C2 (tx / rx) : 0x16 / 0xCF
En el nodo .252, PLM-P se produce contra el puerto OC12 activo en CTC y luego el puerto POS0. Esto hace que el puerto POS0 se desactive, lo que provoca la alarma TPTFAIL.
.252ML12#show ons alarm Equipment Alarms Active: RUNCFG-SAVENEED Port Alarms POS0 Active: TPTFAIL POS1 Active: None GigabitEthernet0 Active: None GigabitEthernet1 Active: None POS0 Active Alarms : PPLM Demoted Alarms: None POS1 Interface not provisioned
En el nodo .225, PDI-P se produce para ambos puertos OC12 en CTC. Esta alarma es el resultado de POS0 down en .252. La misma alarma (denominada Indicación de Defecto de Carga de Trayectoria [PPDI] en IOS) se produce para POS0, que es porque la interfaz recibe el valor C2 de 0xFC (más información sobre esto más adelante en el documento).
.225ML12#show control pos 0 | inc C2 C2 (tx / rx) : 0xCF / 0xFC
La alarma PPDI desactiva la interfaz POS0. A continuación, la interfaz POS0 inactiva provoca TPTFAIL.
.225ML12#show ons alarm Equipment Alarms Active: RUNCFG-SAVENEED Port Alarms POS0 Active: TPTFAIL POS1 Active: None GigabitEthernet0 Active: None GigabitEthernet1 Active: None POS0 Active Alarms : PPDI Demoted Alarms: None POS1 Interface not provisioned
Cambio de byte POS C2
El valor C2 predeterminado es 0x01 para la encapsulación LEX (la encapsulación predeterminada para POS) y 0xCF para la encapsulación PPP/HDLC. Si cambia este valor de forma inconsistente a cualquier otro valor, pueden producirse las alarmas PLM-P y TPTFAIL, que afectan al servicio. Ambos puertos POS en el mismo circuito pueden utilizar el mismo valor C2. La excepción es 0xFC. Un valor de 0xFC indica un Defecto de carga útil de trayectoria. Por lo tanto, incluso si los valores C2 coinciden (0xFC/0xFC), se produce PDI-P.
Puede cambiar el valor POS C2 con este comando:
pos c2 flag <value in decimal>
Puede representar los valores reales de C2 como se muestra aquí (están en formatos hexadecimales):
.225ML12#show contro pos 0 | inc C2 C2 (tx / rx) : 0x16 / 0x16
En este caso, ambos valores C2 coinciden. Por lo tanto, no se produce ninguna alarma.
Cambio del estado del circuito a OOS
Cuando cambia el circuito OC-12 a OOS, no pueden producirse alarmas inmediatamente en TCC o en ML. El estado del circuito muestra OOS en la ventana del circuito en CTC. Las entradas de registro se insertan en ML:
.225ML12#show log … May 27 14:22:15.114: %CARDWARE-6-CIRCUIT_STATE: Circuit state on POS 0 change from IS to OOS_AS May 27 14:22:15.114: %CARDWARE-6-BTC_DRV: Init BTC, BTC Rev = 2, Backplane = 0, Port = 0.
Los puertos POS pueden cambiar al estado Up/Down. Como resultado, se produce una alarma TPTFAIL en ambos extremos. El tráfico no fluye, como es de esperar.
Alarma PDI-P atascada
A veces se atasca una alarma y no se borra automáticamente, incluso después de que se borra la condición que provocó la alarma. Aquí se muestra un ejemplo de PPDI (o PDI-P):
May 27 18:41:15.339: %CARDWARE-6-CIRCUIT_STATE: Circuit state on POS 0 change from IS to OOS_AS May 27 18:42:11.871: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS0, changed state to down May 27 19:17:48.507: %SYS-5-CONFIG_I: Configured from console by vty2 (127.0.0.100) May 28 11:57:33.387: %CARDWARE-6-CIRCUIT_STATE: Circuit state on POS 0 change from OOS_AS to IS May 28 11:57:33.391: %CARDWARE-6-BTC_DRV: Init BTC, BTC Rev = 2, Backplane = 0, Port = 0. May 28 11:57:35.879: %VIRTUAL_PA-6-UPDOWN: POS0 changed to down due to PPDI defect trigger changing state May 28 11:57:36.079: %LINK-3-UPDOWN: Interface POS0, changed state to down May 28 11:57:36.279: %SONET-4-ALARM: POS0: PPDI
Cuando un estado de circuito anterior cambia a OOS, .225 POS informa PPDI incluso después de que el circuito regrese al estado In-Service (IS). Así que la interfaz POS0 permanece inactiva. CTC también informa de PDI-P en el nodo .225. Los contadores PM de las interfaces OC12 en .225 no muestran errores e indican que la trayectoria OC-12 está limpia.
Este resultado informa que PPDI está atascado:
.225ML12#show contro pos 0 Interface POS0 Hardware is Packet/Ethernet over Sonet PATH PAIS = 0 PLOP = 0 PRDI = 0 PTIM = 0 PPLM = 0 PUNEQ = 0 PPDI = 0 BER_SF_B3 = 0 BER_SD_B3 = 0 BIP(B3) = 0 REI = 0 NEWPTR = 0 PSE = 0 NSE = 0 Active Alarms : PPDI Demoted Alarms: None Active Defects: PPDI Alarms reportable to CLI: PAIS PRDI PLOP PUNEQ PPLM PTIM PPDI BER_SF_B3 BER_SD_B3 Link state change defects: PAIS PLOP PTIM PUNEQ PRDI PPLM PPDI BER_SF_B3 Link state change time : 200 (msec) DOS FPGA channel number : 0 Starting STS (0 based) : 0 VT ID (if any) (0 based) : 255 Circuit size : STS-3c RDI Mode : 1 bit C2 (tx / rx) : 0xCF / 0xFC Framing : SONET
Recuerde que desde hace tiempo en este documento, el valor C2 0xFC hace que POS informe PPDI.
Nota: Cuando el nodo .252 está libre de alarmas y errores y tiene los valores C2 coincidentes de 0xCF/0xCF para POS0, debe considerar un problema de alarma atascada. Si restablece la interfaz POS0 en el nodo .225, se borra la alarma, que incluye el PDI-P informado en CTC. Esta anomalía se corregirá en una versión posterior.
May 28 14:34:16.967: %LINK-5-CHANGED: Interface POS0, changed state to administratively down May 28 14:34:18.675: %LINK-3-UPDOWN: Interface POS0, changed state to down May 28 14:34:18.939: %VIRTUAL_PA-6-UPDOWN: POS0 changed to up due to PPDI defect trigger changing state May 28 14:34:19.139: %LINK-3-UPDOWN: Interface POS0, changed state to up May 28 14:34:20.127: %SYS-5-CONFIG_I: Configured from console by vty2 (127.0.0.100) May 28 14:34:20.147: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS0, changed state to up May 28 14:34:28.739: %SONET-4-ALARM: POS0: PPDI cleared
Ahora los valores de C2 coinciden y el nodo no tiene alarma.
.225ML12#show control pos 0 Interface POS0 Hardware is Packet/Ethernet over Sonet PATH PAIS = 0 PLOP = 0 PRDI = 1 PTIM = 0 PPLM = 0 PUNEQ = 0 PPDI = 0 BER_SF_B3 = 0 BER_SD_B3 = 0 BIP(B3) = 0 REI = 16 NEWPTR = 0 PSE = 0 NSE = 0 Active Alarms : None Demoted Alarms: None Active Defects: None Alarms reportable to CLI: PAIS PRDI PLOP PUNEQ PPLM PTIM PPDI BER_SF_B3 BER_SD_B3 Link state change defects: PAIS PLOP PTIM PUNEQ PRDI PPLM PPDI BER_SF_B3 Link state change time: 200 (msec) DOS FPGA channel number : 0 Starting STS (0 based) : 0 VT ID (if any) (0 based) : 255 Circuit size : STS-3c RDI Mode : 1 bit C2 (tx / rx) : 0xCF / 0xCF Framing : SONET
Nota: A veces, una o más alarmas también se pueden pegar en tarjetas ópticas. Debe reiniciar el TCC activo para borrar estas alarmas atascadas. En consecuencia, el TCC en espera se activa y la operación es sin impacto (es decir, no hay impacto en el tráfico), aunque puede perder el tráfico de administración (sesión CTC, por ejemplo) durante unos minutos.
Discordancia de número de grupo de puente
Esta prueba utiliza el mismo grupo de 100 puentes en ambas tarjetas ONS ML. Sin embargo, los grupos de puente no tienen que ser iguales, siempre y cuando POS 0 y GigE 0 estén en el mismo ML, o en el mismo grupo de puente. Por ejemplo, un cambio al grupo de puentes 101 en .252 ML no afecta al tráfico.
.252ML12#show bridge ver
Total of 300 station blocks, 298 free
Codes: P - permanent, S - self
Maximum dynamic entries allowed: 1000
Current dynamic entry count: 0
Flood ports
Maximum dynamic entries allowed: 1000
Current dynamic entry count: 2
BG Hash Address Action Interface VC Age RX count TX count
101 02/0 000b.45b0.484a forward Gi0 -
101 BC/0 0009.b7f4.76ca forward POS0
-
Flood ports
GigabitEthernet0
POS0
Una lista parcial de errores ML pendientes
Esta es una lista parcial de errores que se aplican a la configuración en este documento:
Nota: Estos errores se documentan como parte de las notas de la versión en cisco.com.
| ID DDTS | Estado | Versión encontrada | Versión corregida | **********************Notas*********************************************************************************************************************************************************************************************************************************** |
|---|---|---|---|---|
| CSCeb56287 | V | 4,1 | 4.6 | Cuando se aprovisiona el estado de un circuito de la serie ML de In-Service (IS) a Out-of-Service (OOS) y, a continuación, de nuevo a IS, el tráfico de datos no se recupera. Para evitar este problema, antes de cambiar el estado de IS, configure el puerto POS para apagar en la CLI. Después de cambiar el estado nuevamente a IS desde OOS, configure el puerto POS en no shutdown. |
| CSCeb24757 | V | 4,1 | 4.6 | Si desconecta una fibra de transmisión en un puerto ML1000, sólo el puerto adyacente desconecta el link. Lo ideal es que ambos puertos identifiquen que el link se cayó para que los protocolos de capa superior puedan rerutear el tráfico a un puerto diferente. Para solucionar esta situación, ejecute shutdown y no shutdown al puerto que tiene la fibra de transmisión desconectada o defectuosa. |
| CSCdy31775 | V | 4 | 4.6 | No hay recuento de descartes que incluya los paquetes que se descartan debido a la congestión de la cola de salida. Este problema ocurre en cualquiera de estas condiciones:
|
| CSCdz49700 | C | 4 | - | Las tarjetas de la serie ML siempre reenvían paquetes de protocolo de enlace troncal dinámico (DTP) entre dispositivos conectados. Si DTP está habilitado en dispositivos conectados (que puede ser la configuración predeterminada), DTP podría negociar parámetros, por ejemplo, ISL, que las tarjetas serie ML no admiten. La tarjeta de la serie ML cuenta todos los paquetes en un link negociado para utilizar ISL como paquetes multicast, y los paquetes STP y CDP se puentean entre dispositivos conectados que utilizan ISL sin ser procesados. Para evitar este problema, inhabilite DTP e ISL en los dispositivos conectados. Esta funcionalidad está diseñada de la misma manera. |
| CSCdz68649 | C | 4 | - | En ciertas condiciones, el estado del control de flujo puede indicar que el control de flujo funciona, cuando el control de flujo no funciona. El control de flujo en las tarjetas de la serie ML sólo funciona cuando se configura un regulador de nivel de puerto. Un regulador de nivel de puerto es un regulador en la clase predeterminada y única de un policy-map de entrada. El control de flujo también funciona solamente para limitar la velocidad de origen a la velocidad de descarte del regulador configurada. El control de flujo no evita descartes de paquetes debido a la congestión de la cola de salida. Por lo tanto, si no tiene un regulador de nivel de puerto o si se produce una congestión de cola de salida, la regulación no funciona. Sin embargo, la regulación de tráfico todavía puede aparecer erróneamente como habilitada en estas condiciones. Para evitar este problema, configure un regulador de nivel de puerto y evite la congestión de cola de salida. |
| CSCdz69700 | C | 4 | - | Si ejecuta una secuencia de comandos shutdown/no shutdown en un puerto ML1000, los contadores se despejan. Esta es una parte normal del proceso de inicio y esta funcionalidad no cambiará. |
| CSCea11742 | V | 4 | 4.6 | Cuando se aprovisiona un circuito entre dos puertos ML POS como OOS, uno de los puertos puede informar erróneamente de TPTFAIL. Este problema existe para las tarjetas ML100T-12 y ML1000-2. Si ocurre este problema, abra una ventana de consola a cada tarjeta ML y configure el puerto POS para apagar. |
| CSCea20962 | V | 4 | 5 | No aparece ninguna advertencia cuando se aplica OOS a los puertos de caída de ML en la ventana de aprovisionamiento del circuito. |
| CSCdy47284 | C | 4 | - | No se aplica la MTU FastEthernet ML-100. Sin embargo, las tramas mayores de 9050 bytes pueden ser descartadas y causar errores Rx y Tx. |
Códigos de estado:
|
||||
Solución de problemas y aislamiento de errores
Con la información presentada hasta el momento, esta sección tiene como objetivo construir casos de aislamiento de fallas. En base a los síntomas que informa el sistema, esta sección proporciona consejos paso a paso para solucionar el problema. Estos casos prácticos se relacionan con algunos síntomas comunes asociados con la tarjeta ML en el ONS 15454.
Normalmente, debe seguir estos pasos para resolver un problema:
-
Recopile información general y síntomas de falla.
-
Analice la información.
-
Aislamiento del Problema.
-
Identifique el problema.
-
Resuelva el problema.
Algunos de estos pasos se iteran varias veces.
Información general
Recopilación de información básica
Recopile información antes de recargar o reiniciar la tarjeta ML debido a un error. Una recarga manual descarta información potencialmente valiosa. Las recargas manuales restablecen todos los contadores y se pierden los registros almacenados en la memoria. Cisco recomienda que ejecute el comando show tech-support y cualquier otro comando de recolección de datos para recuperar la información de registro antes de ejecutar cualquier comando de resolución de problemas en el router. Si reinicia o reinicia la tarjeta ML, puede perder el acceso a la consola/telnet y también la información relevante.
Los registros de la consola que llevan al evento pueden proporcionar una imagen de lo que provocó el error o la caída. Cuando se produce un error, debe intentar guardar los mensajes registrados en la consola o el búfer. Estos últimos mensajes de consola podrían resultar vitales para descubrir el problema. Según el tipo de problema, no todos los mensajes se escriben en el servidor SYSLOG.
Utilice el comando show tech-support para recopilar una amplia variedad de datos. Este comando es a menudo la mejor herramienta para obtener el estado del router, después del error en un momento dado.
Esta es una lista básica de los comandos que el comando show tech-support ejecuta. La captura varía según la versión del IOS, el hardware y las opciones que seleccione.
show version show running-config show stacks show interfaces show controllers show file systems dir nvram: show flash: all show process memory show process cpu show context show sdm internal all-regions show sdm ip-adjacency all show sdm ip-mcast all show sdm ip-prefix all show sdm l2-switching forwarding show sdm l2-switching interface-macs show sdm qos all show ons alarm defect show ons alarm failure show ons hwp defects show ons hwp reframe show ons hwp tci show ons hwp xcon show ons equipment-agent status show ons provisioning-agent message ports all show ons provisioning-agent message node-element test mda conn dump connections test mda ppe global reg dump 0 test mda ppe global reg dump 1 Mempool statistics show region show buffers
Además de estos comandos, capture otros resultados de comandos que tengan especial relevancia para la tarjeta ML como se describe en las secciones anteriores de este documento. Por ejemplo, show log, show ons alarm y así sucesivamente. Del Comité contra el Terrorismo, captar y exportar la información pertinente descrita anteriormente, por ejemplo, alarmas, condiciones, circuitos, inventario y contadores de partículas.
Algunas herramientas útiles de IOS para resolver problemas
Después de recopilar la información necesaria, debe descifrar la información para detectar errores. Esta tarea puede ser difícil con la salida de un comando show-tech. Estas son herramientas que pueden descifrar el resultado del comando show-tech, y muchos otros comandos.
-
Herramienta Output Interpreter (sólo clientes registrados): Pegue el resultado del comando show tech-support en esta herramienta. Esta herramienta proporciona un resumen rápido de los problemas encontrados. Se trata de una excelente herramienta que proporciona un resumen rápido de los problemas más sencillos con los que se encuentra. Esta herramienta interpreta una variedad de entradas. Puede utilizar el cuadro desplegable del menú Tecnología para examinar. Sin embargo, la herramienta no es perfecta y aún así requiere una interpretación para validar la información.
-
Command Lookup Tool: Seleccione cualquiera de estas guías de referencia para buscar un comando y la sintaxis:
-
Referencia de Comandos IOS
-
Guía de Configuración de IOS
-
Referencia de Comandos Catalyst
-
Referencia de comandos del firewall PIX
-
-
Decodificador de mensajes de error: Esta herramienta le ayuda a investigar y resolver mensajes de error para Cisco IOS Software, Catalyst Switches Software y Cisco Secure PIX Firewall Software. Pegue los mensajes de error de los archivos de registro y asegúrese de marcar la casilla de verificación sugerir documentos relacionados dentro de los resultados.
-
Herramienta para errores de funcionamiento: Busque resultados en función de una o varias de estas opciones:
-
Versión del IOS.
-
Características o componentes.
-
Palabras clave.
-
Gravedad de errores (puede seleccionar una gravedad específica o especificar un intervalo).
-
-
Recopilación de casos TAC: Puede diagnosticar de forma interactiva problemas comunes que implican problemas de hardware, configuración y rendimiento con soluciones que proporcionan los ingenieros del TAC.
Nota: Algunas herramientas no son 100% compatibles con la tarjeta ML.
Estudios de casos
Esta sección describe algunas de las condiciones de falla comunes y los pasos que puede dar para aislar las condiciones. Refiérase a Guía de Troubleshooting de Cisco ONS 15454, Versiones 4.1.x y 4.5 para obtener información detallada de la alarma.
Alarma CARLOSS informada en un puerto Ethernet ML
Major (MJ) y Service-Affecting (SA), una alarma de pérdida de operador en la tarjeta Ethernet (tráfico) serie ML es el equivalente de datos de la alarma "LOS (OC-N)". El puerto Ethernet ha perdido el link y no recibe una señal válida.
Una alarma CARLOSS ocurre cuando el puerto Ethernet se ha configurado desde la CLI del IOS como un puerto sin apagado, y también se cumple una de estas condiciones:
-
El cable no está conectado correctamente al puerto cercano o lejano.
-
La negociación automática falla.
-
La velocidad (sólo para puertos 10/100) está configurada incorrectamente.
Como se ve en esta prueba entre la tarjeta ML de 7603b y .252 nodos, inhabilite la negociación automática para activar los puertos.
Alarma TPTFAIL informada para POS
Se trata de una alarma importante (MJ) y afecta al servicio (SA). La alarma TPT Layer Failure indica una ruptura en la función de integridad de link POS de extremo a extremo de las tarjetas POS de la serie ML. TPTFAIL indica una condición de extremo lejano o configuración incorrecta del puerto POS.
La alarma TPTFAIL indica un problema en la trayectoria SONET, el puerto POS remoto o una configuración incorrecta del puerto POS que impide que funcione la trayectoria POS completa de extremo a extremo.
Si existen alarmas de ruta SONET, por ejemplo, el "AIS-P", el "LOP-P", el "PDI-P" o el "UNEQ-P" en el circuito que utiliza el puerto POS, el puerto afectado puede informar una alarma de TPTFAIL.
Si el puerto POS de la serie ML del extremo lejano está inhabilitado administrativamente, el puerto inserta una condición "AIS-P" que el puerto del extremo cercano detecta. El puerto de extremo cercano puede informar de TPTFAIL en este caso. El puerto POS de extremo lejano informa de PRDI y PPDI. Puede ver todas estas alarmas con el comando show ons alarm. Si el puerto POS está configurado incorrectamente en el nivel de CLI del IOS, la configuración incorrecta hará que el puerto se caiga e informará sobre TPTFAIL.
Complete estos pasos para borrar la alarma TPTFAIL (Serie ML):
-
Si no se produce ninguna alarma SONET contra el circuito de puerto POS, verifique si ha configurado ambos puertos POS correctamente.
-
Si sólo se produce la alarma "PLM-P" contra el circuito del puerto POS, verifique si ha configurado ambos puertos POS correctamente.
-
Si sólo se produce la condición "PDI-P" en el circuito del puerto POS y el circuito se termina con una tarjeta de la serie G, verifique si se produce una alarma "CARLOSS (Ethernet de la serie G)" en la tarjeta de la serie G. Si es así, complete el procedimiento "Clear the CARLOSS (G-Series Ethernet) Alarm" (Borrar la alarma de la serie G).
-
Si la alarma "AIS-P", la alarma "LOP-P" o la alarma "UNEQ-P" están presentes, solucione el problema de la trayectoria SONET (la ruta entre las dos interfaces POS sobre el mismo circuito) para borrar esas alarmas.
La interfaz Gigabit Ethernet permanece inactiva
Consulte Alarma CARLOSS notificada en un puerto Ethernet ML.
Errores CRC en la interfaz POS
Este problema se debe normalmente a la discordancia CRC en las configuraciones POS.
PPDI de informes POS
PDI-P es un conjunto de códigos específicos de la aplicación contenidos en la sobrecarga de trayectoria (POH) de STS que genera el nodo ONS. La alarma indica al equipo descendente que hay un defecto en una o más de las cargas útiles directamente asignadas contenidas en ese sobre de carga útil sincrónica STS
Una condición PDI-P en el puerto de una tarjeta OC-N que soporta un circuito de tarjeta de la serie ML puede ser resultado de la característica de integridad de link Ethernet de extremo a extremo de la tarjeta de la serie ML. Si el problema se debe a la integridad del link, también se produce la alarma "TPTFAIL (G-Series Ethernet)" o la alarma notificada contra uno o ambos puertos POS que terminan el circuito. Si TPTFAIL se produce en uno o ambos puertos POS, solucione el problema de la alarma que acompaña a TPTFAIL para borrar la condición PDI-P. La alarma PDI-P también puede ser un síntoma de una alarma atascada.
Este es un ejemplo de alarmas que ocurren debido a POS0 administrativamente desactivado en .225:
| .225 POS 0 (cerrado) | .252 POS 0 |
|---|---|
| PPDI, PRDI | PAIS, TPTFAIL |
En este ejemplo, PAIS indica que la raíz del problema es el nodo .225. Si borra PAIS, TPTFAIL, PPDI y PRDI también se borrarán.
PRDI de informes POS
La PRDI indica que el problema está en el otro extremo. Este problema puede ocurrir porque el extremo lejano recibe la alarma AIS. Consulte Informes POS PPDI para obtener más información.
POS Reports PAIS
La condición AIS Path significa que este nodo detecta AIS en la trayectoria entrante.
Por lo general, cualquier AIS es una señal SONET especial que indica al nodo receptor que el nodo del remitente no tiene ninguna señal válida disponible para enviar. AIS no es un error. El nodo receptor provoca la condición de falla AIS en cada entrada donde el nodo ve la señal AIS en lugar de una señal real. En la mayoría de los casos cuando ocurre esta condición, un nodo ascendente genera una alarma para indicar una falla de señal; todos los nodos descendentes sólo provocan algún tipo de AIS. Esta condición se borra cuando se resuelve el problema en el nodo ascendente.
POS Reports PPLM
Este problema es crítico (CR) y afecta al servicio (SA)
Una alarma de discordancia de etiqueta de carga útil de trayecto en un nodo indica que la señal entrante no coincide con la etiqueta suministrada localmente. La condición se produce debido a un valor de byte C2 no válido en la tara de trayectoria SONET. La codificación y la encapsulación pueden cambiar los valores C2.
La interfaz POS se detiene
Diversas alarmas pueden hacer caer la interfaz POS. De forma predeterminada, estas alarmas hacen que el link POS se desactive: PAIS, PLOP, PTIM, PUNEQ, PRDI, PPLM, PPDI, BER_SF_B3. Para modificar la lista, utilice el comando de interfaz pos trigger defectos. Cuando la interfaz POS se activa o desactiva, se registra la causa (show log). Puede recuperar todas las alarmas o defectos activos con el comando show ons alarm. Solucione los problemas de la causa para activar la interfaz POS. Cuando la interfaz POS se desactiva, se produce una alarma TPTFAIL.
Cuando se conecta a interfaces POS de otros proveedores, asegúrese de que estos elementos coinciden en ambos extremos:
-
Codificación
-
valor C2
-
CRC
La interfaz POS informa de errores de entrada
Los errores de entrada que se acumulan en una interfaz POS (show interface POS y contadores CTC PM) indican que los paquetes entrantes están mal formados. Diversas causas pueden conducir a paquetes de error de entrada.
Solucione problemas de alarmas si existen.
Si los errores CRC aumentan junto con los errores de entrada, los errores CRC pueden ser la causa de los errores de entrada. Solución de problemas de configuraciones CRC.
Verifique las configuraciones de la interfaz POS.
Solucione los problemas de los componentes de trayectoria entre los dos puertos POS. Si los errores de entrada aumentan sin un incremento correspondiente en cualquier otro error de componente, considere un problema de hardware. Antes de la sustitución del hardware, realice estos pasos en ambos lados del circuito (uno a la vez) para ver si el problema persiste:
-
switch lateral TCC
-
switch lateral XC
-
Switch de protección en los puertos SONET, si existe protección
-
restablecimiento de software de la tarjeta ML
-
Recarga de la tarjeta ML
El Vecino CDP No Aparece
Verifique si ha habilitado CDP en ambas interfaces.
Solucione problemas de alarmas y errores de interfaz si existen.
Sin flujo de tráfico de extremo a extremo
Verifique las configuraciones en los dos dispositivos finales.
Solucione problemas de alarmas y errores si existen.
Apéndice: Información básica de configuración y comando
Esta sección captura la información de configuración básica para todos los dispositivos en esta prueba, que se utiliza como línea de base para resolver problemas.
7603a
7603a#show run
Building configuration...
Current configuration : 3136 bytes
!
version 12.1
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname 7603a
!
!
ip subnet-zero
!
!
!
mls flow ip destination
mls flow ipx destination
spanning-tree extend system-id
!
redundancy
mode rpr-plus
main-cpu
auto-sync running-config
auto-sync standard
!
!
!
interface GigabitEthernet1/1
ip address 10.0.0.1 255.0.0.0
!
router ospf 1
log-adjacency-changes
network 10.0.0.1 0.0.0.0 area 0
!
ip classless
no ip http server
!
!
!
!
line con 0
line vty 0 4
!
end
7603a#show ip int bri
Interface IP-Address OK? Method Status Protocol
Vlan1 unassigned YES unset administratively down down
GigabitEthernet1/1 10.0.0.1 YES manual up up
7603a#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
7603a#show int gigabitEthernet 1/1
GigabitEthernet1/1 is up, line protocol is up (connected)
Hardware is C6k 1000Mb 802.3, address is 0009.b7f4.76ca (bia 0009.b7f4.76ca)
Internet address is 10.0.0.1/8
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex mode, link type is autonegotiation, media type is SX
output flow-control is unsupported, input flow-control is unsupported, 1000Mb/s
Clock mode is auto
input flow-control is off, output flow-control is off
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:01, output 00:00:45, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue :0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
L2 Switched: ucast: 5482 pkt, 516472 bytes - mcast: 1 pkt, 64 bytes
L3 in Switched: ucast: 0 pkt, 0 bytes - mcast: 0 pkt, 0 bytes mcast
L3 out Switched: ucast: 0 pkt, 0 bytes
5145 packets input, 405866 bytes, 0 no buffer
Received 5107 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 input packets with dribble condition detected
332 packets output, 111641 bytes, 0 underruns
0 output errors, 0 collisions, 2 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
7603a#show ip ospf neig
Neighbor ID Pri State Dead Time Address Interface
10.0.0.2 1 FULL/DR 00:00:38 10.0.0.2 GigabitEtherne
t1/1
7603b
7603b#show run
Building configuration...
Current configuration : 1102 bytes
!
version 12.1
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname 7603b
!
enable password cisco
!
ip subnet-zero
!
!
!
mls flow ip destination
mls flow ipx destination
spanning-tree extend system-id
!
redundancy
mode rpr-plus
main-cpu
auto-sync running-config
auto-sync standard
!
!
!
interface GigabitEthernet1/1
ip address 10.0.0.2 255.0.0.0
speed nonegotiate
!
router ospf 1
log-adjacency-changes
network 10.0.0.2 0.0.0.0 area 0
!
ip classless
no ip http server
!
!
!
!
line con 0
line vty 0 4
no login
!
end
Note that if GigE link does not come up, auto-negotiation may not be working.
Auto-negotiation can be turned off to force the link to come up.
Ensure both sides of the link are matching.
7603b#show ip int bri
Interface IP-Address OK? Method Status Protocol
Vlan1 unassigned YES NVRAM administratively down down
GigabitEthernet1/1 10.0.0.2 YES manual up up
7603b#show int gig 1/1
GigabitEthernet1/1 is up, line protocol is up (connected)
Hardware is C6k 1000Mb 802.3, address is 000b.45b0.484a (bia 000b.45b0.484a)
Internet address is 10.0.0.2/8
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex mode, link type is force-up, media type is SX
output flow-control is unsupported, input flow-control is unsupported, 1000Mb/s
Clock mode is auto
input flow-control is off, output flow-control is off
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:01, output 00:00:04, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue :0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
L2 Switched: ucast: 5695 pkt, 534143 bytes - mcast: 3 pkt, 192 bytes
L3 in Switched: ucast: 0 pkt, 0 bytes - mcast: 0 pkt, 0 bytes mcast
L3 out Switched: ucast: 0 pkt, 0 bytes
5319 packets input, 395772 bytes, 0 no buffer
Received 5172 broadcasts, 4 runts, 0 giants, 0 throttles
4 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 input packets with dribble condition detected
413 packets output, 139651 bytes, 0 underruns
0 output errors, 0 collisions, 2 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
7603b#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
Gateway of last resort is not set
C 10.0.0.0/8 is directly connected, GigabitEthernet1/1
7603b#ping 10.0.0.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.0.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms
.225 ML
.225ML12#show run
Building configuration...
Current configuration : 580 bytes
!
version 12.1
no service pad
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname .225ML12
!
logging buffered 4096 debugging
enable password cisco
!
ip subnet-zero
no ip routing
no ip domain-lookup
!
!
bridge 100 protocol ieee
!
!
interface GigabitEthernet0
no ip address
no ip route-cache
bridge-group 100
!
interface GigabitEthernet1
no ip address
no ip route-cache
shutdown
!
interface POS0
no ip address
no ip route-cache
crc 32
bridge-group 100
!
ip classless
no ip http server
!
!
!
!
line con 0
line vty 0 4
exec-timeout 0 0
no login
!
end
.225ML12#show ip int bri
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0 unassigned YES unset up up
GigabitEthernet1 unassigned YES unset administratively down down
POS0 unassigned YES unset up up
.225ML12#show int gig 0
GigabitEthernet0 is up, line protocol is up
Hardware is xpif_port, address is 000f.2475.8c04 (bia 000f.2475.8c04)
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 1000Mb/s, 1000BaseSX, Auto-negotiation
output flow-control is off, input flow-control is on
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:53, output 00:00:01, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
336 packets input, 111810 bytes
Received 1 broadcasts (0 IP multicast)
1 runts, 0 giants, 0 throttles
1 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 244 multicast
0 input packets with dribble condition detected
5369 packets output, 422097 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
.225ML12#show int pos 0
POS0 is up, line protocol is up
Hardware is Packet/Ethernet over Sonet, address is 000f.2475.8c00
(bia 000f.2475.8c00)
MTU 1500 bytes, BW 622080 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ONS15454-G1000, crc 32, loopback not set
Keepalive set (10 sec)
Scramble enabled
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:32, output never, output hang never
Last clearing of "show interface" counters 02:16:40
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
152 packets input, 26266640 bytes
Received 0 broadcasts (0 IP multicast)
0 runts, 0 giants, 0 throttles
0 parity
1 input errors, 1 CRC, 0 frame, 0 overrun, 0 ignored
0 input packets with dribble condition detected
4250 packets output, 351305 bytes, 0 underruns
0 output errors, 0 applique, 0 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions
.225ML12#show ons alarm
Equipment Alarms
Active: None
Port Alarms
POS0 Active: None
POS1 Active: None
GigabitEthernet0 Active: None
GigabitEthernet1 Active: None
POS0
Active Alarms : None
Demoted Alarms: None
POS1
Interface not provisioned
This command shows all the defects that can be reported to CLI and TCC (via CTC).
.225ML12#show ons alarm defect
Equipment Defects
Active: None
Reportable to TCC/CLI: CONTBUS-IO-A CONTBUS-IO-B CTNEQPT-PBWORK
CTNEQPT-PBPROT EQPT RUNCFG-SAVENEED ERROR-CONFIG
Port Defects
POS0
Active: None
Reportable to TCC: CARLOSS TPTFAIL
POS1
Active: None
Reportable to TCC: CARLOSS TPTFAIL
GigabitEthernet0
Active: None
Reportable to TCC: CARLOSS TPTFAIL
GigabitEthernet1
Active: None
Reportable to TCC: CARLOSS TPTFAIL
POS0
Active Defects: None
Alarms reportable to CLI: PAIS PRDI PLOP PUNEQ PPLM PTIM PPDI BER_SF_B3 BER_SD_B3
POS1
Interface not provisioned
This command shows all the active alarms.
.225ML12#show ons alarm failure
Equipment Alarms
Active: None
Port Alarms
POS0 Active: None
POS1 Active: None
GigabitEthernet0 Active: None
GigabitEthernet1 Active: None
POS0
Active Alarms : None
Demoted Alarms: None
POS1
Interface not provisioned
.225ML12#show control pos 0
Interface POS0
Hardware is Packet/Ethernet over Sonet
PATH
PAIS = 0 PLOP = 0 PRDI = 0 PTIM = 0
PPLM = 0 PUNEQ = 0 PPDI = 0
BER_SF_B3 = 0 BER_SD_B3 = 0 BIP(B3) = 0 REI = 0
NEWPTR = 0 PSE = 0 NSE = 0
Active Alarms : None
Demoted Alarms: None
Active Defects: None
Alarms reportable to CLI: PAIS PRDI PLOP PUNEQ PPLM PTIM PPDI BER_SF_B3 BER_SD_B3
Link state change defects: PAIS PLOP PTIM PUNEQ PRDI PPLM PPDI BER_SF_B3
Link state change time : 200 (msec)
DOS FPGA channel number : 0
Starting STS (0 based) : 0
VT ID (if any) (0 based) : 255
Circuit size : STS-12c
RDI Mode : 1 bit
C2 (tx / rx) : 0x01 / 0x01
Framing : SONET
Path Trace
Mode : off
Transmit String :
Expected String :
Received String :
Buffer : Unstable
Remote hostname :
Remote interface:
Remote IP addr :
B3 BER thresholds:
SFBER = 1e-4, SDBER = 1e-7
231 total input packets, 26294392 post-HDLC bytes
0 input short packets, 26294465 pre-HDLC bytes
0 input long packets , 0 input runt packets
1 input CRCerror packets , 0 input drop packets
0 input abort packets
0 input packets dropped by ucode
6392 total output packets, 527660 output pre-HDLC bytes
527812 output post-HDLC bytes
Carrier delay is 200 msec
.225ML12#show cdp nei
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone
Device ID Local Intrfce Holdtme Capability Platform Port ID
.252ML12 POS0 148 T ONS-ML1000POS0
7603a Gig 0 121 R S I Cat 6000 Gig 1/1
The following command shows the detail bridge table. Note that 000b.45b0.484a
is the address of Gig0 on 7603b.
.225ML12#show bridge ver
Total of 300 station blocks, 298 free
Codes: P - permanent, S - self
Maximum dynamic entries allowed: 1000
Current dynamic entry count: 2
BG Hash Address Action Interface VC Age RX count TX count
100 02/0 000b.45b0.484a forward POS0 -
100 BC/0 0009.b7f4.76ca forward Gi0 -
Flood ports
GigabitEthernet0
POS0
This command shows the same type of info as the above.
.225ML12#show sdm l2-switching forwarding bridge-group 100
MAC-Address B-Group l3_int punt_da Out-int SPR-NodeId CAM-ADDR STATE
----------- ------- ------ ------- ------- ---------- -------- -----
0009B7F476CA 100 0 0 Gi0 *** 11 Used
000B45B0484A 100 0 0 PO0 *** 12 Used
.225ML12#show interface summary
*: interface is up
IHQ: pkts in input hold queue IQD: pkts dropped from input queue
OHQ: pkts in output hold queue OQD: pkts dropped from output queue
RXBS: rx rate (bits/sec) RXPS: rx rate (pkts/sec)
TXBS: tx rate (bits/sec) TXPS: tx rate (pkts/sec)
TRTL: throttle count
Interface IHQ IQD OHQ OQD RXBS RXPS TXBS TXPS TRTL
---------------------------------------------------------------------
* GigabitEthernet0 0 0 0 0 0 0 0 0 0
GigabitEthernet1 0 0 0 0 0 0 0 0 0
* POS0 0 0 0 0 0 0 0 0 0
NOTE:No separate counters are maintained for subinterfaces
Hence Details of subinterface are not shown
.225ML12#show ons equipment-agent status
EQA ---- phySlot: 12, eqptType: EQPT_L2SC, eqptID: 0x2403 ----
curTCC: Tcc B
linkStatus: Full dbReq/Recv: 1 / 4 msgVerToEQM: 2
socketFd: 0 pipeMsgAct: No hdrSizeToEQM: 28
connTries: 0 connTimerFast: No hdrSizeFromEQM: 28
timingProv: No
clock auto 1
.225ML12#show ons provisioning-agent message ports all
----- Backend Port (00) Data -----
prov: yes sts: 00 vt: 255 type: DOS name:
----- STS (00) Term Strip -----
Admin State: IS Direction: TX_RX_EQPT
Type: 12 Sf: 1E-4 Sd: 1E-7 C2 tx/exp: 0x01 / 0x01
PathTrace Format: 64Byte Mode: OFF
expected: (not valid)
send: valid: "\000\000\000\000"
----- VT (255) Term Strip not provisioned -----
----- STS (00) Xc Strip -----
rate: 12 Admin: IS
Src Port/STS: 0x09/0x00 STS Eqpt: 0x01
Dest Port/STS: 0x06/0x00 UPSR STS Cont Dest: 0x00
Prev STS Stich Dest Port/STS: 0xFF/0x00
Next STS Stich Dest Port/STS: 0xFF/0x00
----- Backend Port (01) Data -----
prov: no sts: xx vt: xx type: xxx name: xxxxx
The following command retrieves the ONS provisioning information
that is done via CTC.
.225ML12#show ons provisioning-agent message node-element
----- NE Data -----
Node Name: R27-15454c
MAC Addr : 00 10 CF D2 70 92
IP Addr : 10.89.244.225
Sub Net Mask : 255.255.255.192
Dflt Router : 10.89.244.193
Lan IP Addr : 10.89.244.225
Lan Sub Mask : 255.255.255.192
Day Savings : 0x01
Min from UTC : 480
Node ID : 0xFF
Sync Msg Ver : 0x01
Sync Msg Res Delta : -1
Sync Msg Res Quality : 0x06
XConA Eqpt ID : 0x00000201
XConB Eqpt ID : 0x00000201 OSPF Node ID : 0xCFD27092
SDH Mode : SONET
.252ML12
The auto negotiation was turned off on Gig0 (see later).
.252ML12#show run
Building configuration...
Current configuration : 643 bytes
!
version 12.1
no service pad
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname .252ML12
!
logging buffered 4096 debugging
enable password cisco
!
ip subnet-zero
no ip routing
no ip domain-lookup
!
!
bridge 100 protocol ieee
!
!
interface GigabitEthernet0
no ip address
no ip route-cache
no speed
no negotiation auto
bridge-group 100
!
interface GigabitEthernet1
no ip address
no ip route-cache
shutdown
!
interface POS0
no ip address
no ip route-cache
crc 32
bridge-group 100
!
ip classless
no ip http server
!
!
!
!
line con 0
line vty 0 4
exec-timeout 0 0
no login
!
end
.252ML12#show ip int brie
Interface IP-Address OK? Method Status Protocol
GigabitEthernet0 unassigned YES manual up up
GigabitEthernet1 unassigned YES NVRAM administratively down down
POS0 unassigned YES unset up up
The Gig0 interface showed carrier loss until it was forced up by turning off
auto negotiation.
.252ML12#show int gig 0
GigabitEthernet0 is up, line protocol is up
Hardware is xpif_port, address is 000f.2475.8c4c (bia 000f.2475.8c4c)
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 1000Mb/s, 1000BaseSX, Force link-up
output flow-control is off, input flow-control is on
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:06, output 00:00:01, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
391 packets input, 125375 bytes
Received 1 broadcasts (0 IP multicast)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 282 multicast
0 input packets with dribble condition detected
8489 packets output, 637084 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
.252ML12#show int pos 0
POS0 is up, line protocol is up
Hardware is Packet/Ethernet over Sonet, address is 000f.2475.8c48
(bia 000f.2475.8c48)
MTU 1500 bytes, BW 622080 Kbit, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ONS15454-G1000, crc 32, loopback not set
Keepalive set (10 sec)
Scramble enabled
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output never, output hang never
Last clearing of "show interface" counters 03:58:02
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
7396 packets input, 608413 bytes
Received 0 broadcasts (0 IP multicast)
0 runts, 0 giants, 0 throttles
0 parity
1 input errors, 1 CRC, 0 frame, 0 overrun, 0 ignored
0 input packets with dribble condition detected
267 packets output, 96676 bytes, 0 underruns
0 output errors, 0 applique, 0 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
0 carrier transitions
.252ML12#show ons alarm
Equipment Alarms
Active: None
Port Alarms
POS0 Active: None
POS1 Active: None
GigabitEthernet0 Active: None
GigabitEthernet1 Active: None
POS0
Active Alarms : None
Demoted Alarms: None
POS1
Interface not provisioned
.252ML12#show ons alarm defect
Equipment Defects
Active: None
Reportable to TCC/CLI: CONTBUS-IO-A CONTBUS-IO-B CTNEQPT-PBWORK
CTNEQPT-PBPROT EQPT RUNCFG-SAVENEED ERROR-CONFIG
Port Defects
POS0
Active: None
Reportable to TCC: CARLOSS TPTFAIL
POS1
Active: None
Reportable to TCC: CARLOSS TPTFAIL
GigabitEthernet0
Active: None
Reportable to TCC: CARLOSS TPTFAIL
GigabitEthernet1
Active: None
Reportable to TCC: CARLOSS TPTFAIL
POS0
Active Defects: None
Alarms reportable to CLI: PAIS PRDI PLOP PUNEQ PPLM PTIM PPDI BER_SF_B3 BER_SD_B3
POS1
Interface not provisioned
.252ML12#show ons alarm failure
Equipment Alarms
Active: None
Port Alarms
POS0 Active: None
POS1 Active: None
GigabitEthernet0 Active: None
GigabitEthernet1 Active: None
POS0
Active Alarms : None
Demoted Alarms: None
POS1
Interface not provisioned
.252ML12#show contro pos 0
Interface POS0
Hardware is Packet/Ethernet over Sonet
PATH
PAIS = 0 PLOP = 0 PRDI = 0 PTIM = 0
PPLM = 0 PUNEQ = 0 PPDI = 0
BER_SF_B3 = 0 BER_SD_B3 = 0 BIP(B3) = 0 REI = 0
NEWPTR = 0 PSE = 0 NSE = 0
Active Alarms : None
Demoted Alarms: None
Active Defects: None
Alarms reportable to CLI: PAIS PRDI PLOP PUNEQ PPLM PTIM PPDI BER_SF_B3 BER_SD_B3
Link state change defects: PAIS PLOP PTIM PUNEQ PRDI PPLM PPDI BER_SF_B3
Link state change time : 200 (msec)
DOS FPGA channel number : 0
Starting STS (0 based) : 0
VT ID (if any) (0 based) : 255
Circuit size : STS-12c
RDI Mode : 1 bit
C2 (tx / rx) : 0x01 / 0x01
Framing : SONET
Path Trace
Mode : off
Transmit String :
Expected String :
Received String :
Buffer : Unstable
Remote hostname :
Remote interface:
Remote IP addr :
B3 BER thresholds:
SFBER = 1e-4, SDBER = 1e-7
7425 total input packets, 610493 post-HDLC bytes
0 input short packets, 610501 pre-HDLC bytes
0 input long packets , 0 input runt packets
1 input CRCerror packets , 0 input drop packets
0 input abort packets
0 input packets dropped by ucode
268 total output packets, 97061 output pre-HDLC bytes
97061 output post-HDLC bytes
Carrier delay is 200 msec
.252ML12#show cdp neigh
Capability Codes: R - Router, T - Trans Bridge, B - Source Route Bridge
S - Switch, H - Host, I - IGMP, r - Repeater, P - Phone
Device ID Local Intrfce Holdtme Capability Platform Port ID
.225ML12 POS0 168 T ONS-ML1000POS0
7603b Gig 0 158 R S I Cat 6000 Gig 1/1
.252ML12#show bridge verbose
Total of 300 station blocks, 300 free
Codes: P - permanent, S - self
Total of 300 station blocks, 298 free Codes: P - permanent, S – self
Maximum dynamic entries allowed: 1000 Current dynamic entry count: 2
BG Hash Address Action Interface VC Age RX count TX count
100 02/0 000b.45b0.484a forward Gi0 -
100 BC/0 0009.b7f4.76ca forward POS0 -
Flood ports GigabitEthernet0 POS0
.252ML12#show sdm l2-switching forwarding bridge-group 100
MAC-Address B-Group l3_int punt_da Out-int SPR-NodeId CAM-ADDR STATE
----------- ------- ------ ------- ------- ---------- -------- -----
000B45B0484A 100 0 0 Gi0 *** 11 Used
0009B7F476CA 100 0 0 PO0 *** 16 Used
.252ML12#show int summ
*: interface is up
IHQ: pkts in input hold queue IQD: pkts dropped from input queue
OHQ: pkts in output hold queue OQD: pkts dropped from output queue
RXBS: rx rate (bits/sec) RXPS: rx rate (pkts/sec)
TXBS: tx rate (bits/sec) TXPS: tx rate (pkts/sec)
TRTL: throttle count
Interface IHQ IQD OHQ OQD RXBS RXPS TXBS TXPS TRTL
---------------------------------------------------------------------
* GigabitEthernet0 0 0 0 0 0 0 0 0 0
GigabitEthernet1 0 0 0 0 0 0 0 0 0
* POS0 0 0 0 0 0 0 0 0 0
NOTE:No separate counters are maintained for subinterfaces
Hence Details of subinterface are not shown
.252ML12#show ons equipment-agent status
EQA ---- phySlot: 12, eqptType: EQPT_L2SC, eqptID: 0x2403 ----
curTCC: Tcc A
linkStatus: Full dbReq/Recv: 1 / 5 msgVerToEQM: 2
socketFd: 0 pipeMsgAct: No hdrSizeToEQM: 28
connTries: 0 connTimerFast: No hdrSizeFromEQM: 28
timingProv: No
clock auto 1
.252ML12#show ons provisioning-agent message ports all
----- Backend Port (00) Data -----
prov: yes sts: 00 vt: 255 type: DOS name:
----- STS (00) Term Strip -----
Admin State: IS Direction: TX_RX_EQPT
Type: 12 Sf: 1E-4 Sd: 1E-7 C2 tx/exp: 0x01 / 0x01
PathTrace Format: 64Byte Mode: OFF
expected: (not valid)
send: valid: "\000\000\000\000"
----- VT (255) Term Strip not provisioned -----
----- STS (00) Xc Strip -----
rate: 12 Admin: IS
Src Port/STS: 0x09/0x00 STS Eqpt: 0x01
Dest Port/STS: 0x06/0x00 UPSR STS Cont Dest: 0x00
Prev STS Stich Dest Port/STS: 0xFF/0x00
Next STS Stich Dest Port/STS: 0xFF/0x00
----- Backend Port (01) Data -----
prov: no sts: xx vt: xx type: xxx name: xxxxx
.252ML12#show ons provisioning-agent message node-element
----- NE Data -----
Node Name: r26-15454a
MAC Addr : 00 10 CF D2 40 52
IP Addr : 10.89.244.252
Sub Net Mask : 255.255.255.192
Dflt Router : 10.89.244.193
Lan IP Addr : 10.89.244.252
Lan Sub Mask : 255.255.255.192
Day Savings : 0x01
Min from UTC : 480
Node ID : 0xFF
Sync Msg Ver : 0x01
Sync Msg Res Delta : 0
Sync Msg Res Quality : 0x00
XConA Eqpt ID : 0x00000201
XConB Eqpt ID : 0x00000201
OSPF Node ID : 0xCFD24052
SDH Mode : SONET
Información Relacionada
Historial de revisiones
| Revisión | Fecha de publicación | Comentarios |
|---|---|---|
1.0 |
14-Nov-2005 |
Versión inicial |
ComentariosContacte a Cisco
- Abrir un caso de soporte
- (Requiere un Cisco Service Contract)