Inhalt

Einführung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Konventionen

Grundlegende ML-Architektur

Grundlegende Testtopologie

Fallstudien zur Fehlereinfügung

Allgemeine Informationen

Anwenderberichte

Fehlerbehebung und Fehlerisolierung

Allgemeine Informationen

Anwenderberichte

Anhang: Grundlegende Informationen zur Testkonfiguration und zu Befehlen

7603a

7603b

0,225 ML

.252ML12

Zugehörige Informationen

Einführung

In diesem Dokument wird eine einfache Testtopologie verwendet, um die Fehlerbehebung von Multi-Layer (ML)-Karten auf Cisco ONS 15454 zu beschreiben. Der Anhang enthält einige grundlegende Konfigurationsbefehle und detaillierte Topologieinformationen.

Der Test verwendet einen empirischen Ansatz, um die Netzwerkfehler zu verstehen, die mit ML-Karten verbunden sind. Der Test fügt bekannte Fehler oder Konfigurationen ein, um erwartete Ergebnisse zu erfassen und zu analysieren. Die Fault Isolation Case Studies präsentieren diese Ergebnisse.

Das Dokument folgt den typischen Methoden zur Fehlerbehebung. Das Dokument stellt ein Symptom dar und behandelt die relevanten Schritte zur Fehlerisolierung sowie allgemeine Fehlerbehebungsverfahren.

Voraussetzungen

Anforderungen

Cisco empfiehlt, dass Sie über Kenntnisse in folgenden Bereichen verfügen:

- Cisco ONS 15454

- Cisco ONS Ethernet-Karten der Serie 15454 ML

- Cisco IOS

- Bridging und IP-Routing

Verwendete Komponenten

Die Informationen in diesem Dokument basierend auf folgenden Software- und Hardware-Versionen:

- Cisco Router 7603 mit Cisco IOS® Softwareversion 12.1(13)E13

- Cisco ONS 15454 mit Cisco ONS Version 4.1.3

- ML (gebündelt als Teil der ONS 4.1.3-Version), die die Cisco IOS-Softwareversion 12.1(19)EO1 ausführt

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netz Live ist, überprüfen Sie, ob Sie die mögliche Auswirkung jedes möglichen Befehls verstehen.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps von Cisco zu Konventionen).

Grundlegende ML-Architektur

Die Karten der Cisco ML-Serie für die ONS 15454-Plattform bieten 10/100/1000 Mbit/s Ethernet-Konnektivität über SONET/SDH auf Layer 2 und Layer 3. Jede ML-Karte im Chassis führt ein unabhängiges IOS-Image aus. Durch die Erstellung eines Cross-Connect-Circuits in Cisco Transport Controller (CTC) zwischen ML-Ports werden virtuelle Back-End Packet over SONET (POS)-Ports erstellt. In Softwareversionen ab Version 4.6 wird immer ein POS-Port erstellt. Die Ports werden jedoch nur dann aktiviert, wenn im CTC eine Kreuzung der Schaltkreise erfolgt.

Die ML1000-2-Karte verfügt über zwei POS-Ports (0 und 1). Jeder Port verfügt über eine bis zu synchrone (STS)-24c-Bandbreite und insgesamt über STS-48c pro Karte. Jeder POS-Port unterstützt Subschnittstellen, um VLAN-Trunking zu ermöglichen. Die physische Zuordnung eines POS-Ports zu einem optischen Port erfolgt während der Phase der Schaltkreiserstellung und kann sich während des Wechsels der optischen Reichweite ändern. Daher sind zwei POS-Ports an zwei Enden des Schaltkreises Peers, deren Konfigurationen müssen übereinstimmen.

Die Zuordnung zwischen einem Ethernet-Port und einem POS-Port hängt von der Topologieanforderung ab. Die Layer-2-Switching-Topologie verknüpft diese beiden Port-Typen mit derselben Bridge-Gruppen-Nummer. Die Layer-3-Topologie leitet Pakete zwischen diesen Schnittstellen weiter.

Grundlegende Testtopologie

Abbildung 1 stellt die Testtopologie dar:

Abbildung 1: Testtopologie

So richten Sie die Testtopologie ein:

1. Verbinden Sie zwei Cisco 7603-Router über Gigabit Ethernet mit ONS-Knoten, und stellen Sie sicher, dass beide Ports der beiden Router im gleichen IP-Subnetz sind. Hier verfügt jeder ONS-Knoten in Steckplatz 12 über eine ML1000-2-Karte.

2. Konfigurieren Sie eine Bridge-Gruppe 100 für Gig0 und POS0 auf beiden ONS-Knoten.

Hinweis: In diesem Test müssen Sie POS1 nicht verwenden.

Der Stromkreis zwischen den beiden ML-POS0-Ports ist STS-12c.

3. Deaktivieren Sie IP-Routing auf ML-Karten.

4. Bereitstellung des OC12 1+1-Schutzes zwischen den beiden ONS-Knoten. Die entsprechenden Informationen finden Sie in Abbildung 1.

Hinweis: Auf beiden ONS-Knoten wird Cisco ONS Version 4.1.3 ausgeführt.

Fallstudien zur Fehlereinfügung

In diesem Abschnitt werden die Ergebnisse verschiedener bekannter Fehler und einiger gängiger Operationen untersucht. Jede Fallstudie beschreibt den Vorgang und die Ergebnisse zu ML und ONS.

Allgemeine Informationen

Einige relevante Befehle zur Behebung von Problemen mit ML IOS

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

Stellen Sie sicher, dass Sie einen korrekten Zeitstempel für die Puffer-Protokollierung verwenden, und überprüfen Sie, ob die Timing Communication and Control (TCC) mit dem richtigen Datum und der richtigen Uhrzeit eingestellt ist. Im Folgenden finden Sie eine Beispielkonfigurationsausgabe für ML:

service timestamps debug uptime

service timestamps log datetime msec localtime

logging buffered 4096 debugging

Diese Alarme lösen automatisch eine Änderung des POS-Verbindungsstatus aus:

PAIS

PLOP

PTIM

PUNEQ

PRDI

PPLM

PPDI

BER_SF_B3

Hinweis: Die ONS 15454-Plattform verwendet zwei Formate zum Melden von Alarmen. Beispielsweise wird PAIS in IOS (ML) und AIS-P in CTC angezeigt. PAIS und AIS-P stellen den gleichen Alarmtyp dar.

Allgemeine Verifizierungen im CTC

Alarms

Conditions

History

Circuit

Inventory

Port PM counters

Diagnostics file

Audit trail

- Auf ML-Karte:

- Wartungs-/Leistungs-EtherPorts: auf Fehler überprüfen.

- POS-Ports für Wartung/Leistung: auf Fehler überprüfen.

- Auf der Arbeitskarte OC12:

- Aktivieren Sie IPPM auf Provisioning/SONET STS.

- Leistung: auf Fehler überprüfen.

Anwenderberichte

In diesem Abschnitt werden verschiedene mögliche Fehlerpunkte beschrieben und erläutert, wie Sie die richtigen Informationen zur Problembehebung erfassen.

Ethernet-Trennung

Dieser Alarm wird auf 0,225 angezeigt, wenn Sie das Ethernetkabel ziehen:

.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

Hinweis: Wenn Sie die ML-GigE-Schnittstelle erzwingen, bemerkt ML nicht, dass die Verbindung inaktiv ist.

Derselbe Alarm wird im CTC von .225 (siehe Abbildung 2) angezeigt.

Abbildung 2: Alarm im CTC

Der Verlust des Cisco Discovery Protocol (CDP)-Nachbarn des 7603a bestätigt das Problem.

Hinweis: Der Status von GigE 0 beeinflusst die POS 0-Schnittstelle nicht (die Schnittstelle ist immer noch aktiv/aktiv).

OC12 Protection Switch

OC12 Protection Switch verursacht keine Alarme oder Fehler.

Beide OC12 Out of Service (OOS)

Wenn beide OC12-Ports am .252-Knoten zu OOS wechseln, meldet .225 AIS-P, was dazu führt, dass die POS 0-Schnittstelle ausfällt und zu TPTFAIL führt.

.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

XC-seitiger Switch

Dieser Protokolleintrag wird in der ML des Knotens angezeigt, in dem XC geswitcht ist. Beachten Sie, dass XCON B Steckplatz 10 XC ist.

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

TCC Side Switch

Abbildung 3 zeigt den registrierten Alarm.

Abbildung 3: Alarm für den TCC Side Switch

Hinweis: Wenn Sie CTC oder Reverse Telnet verwenden, um eine Verbindung zur ML-Karte herzustellen, verlieren Sie die Verbindung zur ML-Karte.

Nach einigen Minuten muss der Alarm gelöscht werden. Diese Protokolleinträge werden in ML angezeigt:

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.

In dieser Ausgabe wird auch der aktuell aktive TCC angezeigt. Steckplatz 11 TCC ist TCC B, Steckplatz 7 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

Entfernen und Erstellen von Schaltkreisen

Durch das Entfernen der Cross-Connect-Schaltung werden folgende Protokolleinträge erstellt:

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.

Die Portkonfiguration wird geändert, während Sie sie in ML anzeigen.

.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

Durch die Erstellung eines STS3c-Circuits werden die Port-Informationen zu ML aktualisiert. Die Leitungsgröße wird auch in der Ausgabe des POS 0-Controllers angezeigt.

.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

Diese Protokolleinträge werden angezeigt:

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

Die Anwendung eines Anlagenschleifs auf den aktiven OC12-Port am .225 bewirkt, dass der .225 ML-Alarm TPTFAIL meldet. Dieser Alarm wird auch in den ML-Alarmlisten angezeigt.

Hinweis: Wenn Sie Loopbacks auf einem aktiven Pfad aktivieren, geht Datenverkehr verloren.

.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

Hinweis: Wenn Sie statt des 1+1 OC-12 wie in diesem Test den ausfallsicheren Paketring (RPR) verwenden, müssen Sie die POS-Schnittstellen herunterfahren, bevor Sie Loopbacks aktivieren. Ein solcher Loopback auf RPR verursacht Datenverluste, da der Schutzpfad den Datenverkehr nicht umleitet.

Änderung von Datum und Uhrzeit

Der Eintrag im Protokoll wird durch falsche Datums- und Uhrzeiteinstellungen auf dem TCC erstellt:

2d23h: %CARDWARE-5-CLOCK_ERR: cannot set time-of-day,

(invalid IOS time set on TCC)

Wenn Sie Datum und Uhrzeit ändern, wird dieser Eintrag im ML-Protokoll angezeigt.

2d23h: %CARDWARE-5-CLOCK_INFO: system clock, timezone,

and summertime configured

Die IOS-Systemuhr wird automatisch aktualisiert, basierend auf der Uhr von TCC. Sie können diese Aktualisierung mit dem Befehl show clock überprüfen.

Hinweis: Sie können den Befehl Dienstzeitstempel verwenden, um Debug- und Protokollzeitstempel für die Verwendung der neuen Uhreninformationen zu konfigurieren.

Herunterfahren einer POS-Schnittstelle

Wenn die POS 0-Schnittstelle bei 225 ML heruntergefahren wird, treten einige Alarme und Bedingungen auf (siehe Abbildung 4).

Abbildung 4: Warnmeldungen und Bedingungen, die beim Herunterfahren der POS 0-Schnittstelle auftreten

AIS-P tritt für beide OC12-Ports an .252 auf. Dann tritt TPTFAIL für ML auf .252 auf. Auf dem Rückgabepfad meldet .225 Path Payload Defect Indication (PPDI, auch PDI-P genannt) für beide OC-12-Ports und RFI-P für den funktionierenden OC-12-Port.

Bei 0,225 ML werden folgende Alarme angezeigt:

.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

Diese Protokolleinträge werden auch in .225 angezeigt:

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

Bei .252 treten diese Alarme auf:

.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

Ebenso weisen Logeinträge auf 252 darauf hin, dass das POS 0-Ausfall-Ereignis PAIS ist. Dies entspricht den von dem Ausschuss gemeldeten Alarmen oder Bedingungen.

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

Diese Tatsache können Sie mit dieser Ausgabe bestätigen:

.252ML12#show contro pos 0 | inc Active

Active Alarms : PAIS

Active Defects: PAIS

Wenn Sie die POS 0-Schnittstelle aufrufen, werden diese Protokolleinträge in .252 ML angezeigt:

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

Dies sind die Protokolleinträge in .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

Der Datenverkehr kehrt jetzt zum Normalzustand zurück.

POS CRC-Nichtübereinstimmung

Wenn CRC auf beiden POS-Ports desselben Stromkreises nicht übereinstimmt (z. B. eine Seite 16 Bit, die andere Seite 32 Bit), treten weder bei TCC noch bei ML Alarme auf. Beide POS-Ports sind weiterhin aktiv, der Datenverkehr fließt jedoch nicht. Hier einige Symptome:

1. Beide POS-Schnittstelleneingangsfehler-Zähler erhöhen sich aufgrund von CRC um 100 %. In diesem Fall ändert CRC auf 16 Bit bei 0,225 ML, während 0,252 ML immer noch die Standard-32-Bit-CRC hat. Die POS0-Schnittstelle in .252 ML zeigt eine ähnliche Eingabe und CRC-Fehleranzahl an.

.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

2. CRC-Fehlerzählungsinkrement für POS-Controller-Eingabe.

.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

3. Der CDP-Nachbar im gesamten optischen Pfad verwirft. Obwohl POS0 aktiv ist und CDP funktioniert, wird der Nachbar über POS0 nicht angezeigt.

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

POS-Scrambling-Diskrepanz

Mit der PPP-Kapselung können Sie SPE-Scrambling aktivieren (standardmäßig ist SPE-Scrambling deaktiviert). In diesem Beispiel wurde die Option 0,225ML POS0 aktiviert, während die Standardeinstellung für 0,252ML POS0 festgelegt ist.

.225ML12#show int pos 0 | in Scramble

Scramble enabled

Eine Nichtübereinstimmung der Verwürfelungen ändert den C2-Wert. Wenn Sie Scrambling aktivieren, verwenden POS-Schnittstellen den C2-Wert 0x16. Wenn Sie das Scrambling deaktivieren, verwenden POS-Schnittstellen den C2-Wert 0xCF. Wenn Sie das Scrambling für den .252 POS 0-Port aktivieren, ergibt sich folgendes Ergebnis (die .225 POS 0-Konfiguration ändert sich nicht):

.252ML12#show contr pos 0 | in C2

C2 (tx / rx)           : 0x16 / 0xCF

Auf dem Knoten 0,252 tritt PLM-P gegen den aktiven OC12-Port im CTC und dann den POS0-Port auf. Dadurch wird der POS0-Port deaktiviert, was den TPTFAIL-Alarm auslöst.

.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

Auf dem Knoten 0,225 tritt PDI-P für beide OC12-Ports im CTC auf. Dieser Alarm ist das Ergebnis von POS0 down in .252. Der gleiche Alarm (PPDI in IOS genannt) tritt auch für POS0 auf, da die Schnittstelle den C2-Wert 0xFC erhält (weitere Informationen hierzu folgen weiter unten im Dokument).

.225ML12#show control pos 0 | inc C2

C2 (tx / rx)           : 0xCF / 0xFC

Durch den PPDI-Alarm wird die POS0-Schnittstelle deaktiviert. Die POS0-Schnittstelle nach unten löst dann TPTFAIL aus.

.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

POS C2 Byte-Änderung

Der C2-Standardwert ist 0x01 für die LEX-Kapselung (die Standardkapselung für POS) und 0xCF für die PPP-/HDLC-Kapselung. Wenn Sie diesen Wert inkonsistent auf einen anderen Wert ändern, können PLM-P- und TPTFAIL-Alarme auftreten, die sich auf den Service auswirken. Beide POS-Ports auf demselben Stromkreis können den gleichen C2-Wert verwenden. Die Ausnahme ist 0xFC. Ein Wert von 0xFC weist auf einen Pfad Payload-Defekt hin. Selbst wenn also die C2-Werte übereinstimmen (0xFC/0xFC), findet PDI-P statt.

Sie können den POS C2-Wert mit dem folgenden Befehl ändern:

pos c2 flag <value in decimal>

Sie können die tatsächlichen C2-Werte wie hier gezeigt darstellen (sie sind im hexadezimalen Format):

.225ML12#show contro pos 0 | inc C2

C2 (tx / rx)           : 0x16 / 0x16

In diesem Fall stimmen beide C2-Werte überein. Daher wird kein Alarm ausgelöst.

Schaltkreiszustand in OOS ändern

Wenn Sie den OC-12-Schaltkreis in das OOS ändern, können unmittelbar bei TCC oder bei ML keine Alarme auftreten. Der Schaltungszustand zeigt das OOS im Schaltungsfenster des CTC an. Protokolleinträge werden in ML eingefügt:

.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.

Die POS-Ports können in den Status Nach oben/Nach unten geändert werden. Als Ergebnis tritt an beiden Enden ein TPTFAIL-Alarm auf. Der Datenverkehr fließt nicht, wie Sie erwarten können.

Blockierter PDI-P-Alarm

Manchmal wird ein Alarm festgeklemmt und wird nicht automatisch gelöscht, auch nach dem Zustand, der den Alarm ausgelöst hat. Ein PPDI (oder PDI-P)-Beispiel wird hier angezeigt:

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

Wenn ein früherer Schaltungszustand in das OOS wechselt, meldet der POS-Code 225 PPDI, selbst wenn der Schaltkreis in den In-Service (IS)-Zustand zurückkehrt. Die POS0-Schnittstelle bleibt also inaktiv. Der CTC meldet außerdem PDI-P auf einem Knoten 225. Die PM-Zähler der OC12-Schnittstellen in .225 zeigen keine Fehler an und geben an, dass der OC-12-Pfad sauber ist.

In dieser Ausgabe wird PPDI als "festgeklemmt" gemeldet:

.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

Beim Rückruf aus früheren Teilen dieses Dokuments wird durch den C2-Wert 0xFC der PPDI vom POS gemeldet.

Hinweis: Wenn der .252-Knoten frei von Alarmen und Fehlern ist und die entsprechenden C2-Werte 0xCF/0xCF für POS0 aufweisen, müssen Sie ein festgeklemmtes Alarmproblem berücksichtigen. Wenn Sie die POS0-Schnittstelle auf dem Knoten 225 zurücksetzen, wird der Alarm gelöscht, der auch den im CTC gemeldeten PDI-P enthält. Diese Anomalie wird in einer späteren Version behoben.

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

Nun stimmen die C2-Werte überein, und der Knoten ist alarmierungsfrei.

.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

Hinweis: Manchmal können auch ein oder mehrere Alarme auf optischen Karten feststecken. Sie müssen den aktiven TCC zurücksetzen, um diese fixierten Alarme zu löschen. Infolgedessen wird der Standby-TCC aktiviert, und der Betrieb ist unterbrechungsfrei (d. h. ohne Beeinträchtigung des Datenverkehrs). Sie können jedoch den Verwaltungsdatenverkehr (z. B. CTC-Sitzung) für einige Minuten verlieren.

Nichtübereinstimmung der Anzahl der Bridge-Gruppen

Bei diesem Test wird auf beiden ONS ML-Karten dieselbe 100-Bridge-Gruppe verwendet. Die Bridge-Gruppen müssen jedoch nicht identisch sein, solange sich POS 0 und GigE 0 im gleichen ML oder in derselben Bridge-Gruppe befinden. Eine Änderung in Bridge-Group 101 in .252 ML hat beispielsweise keine Auswirkungen auf den Datenverkehr.

.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

Teilliste ausstehender ML-Fehler

Im Folgenden finden Sie eine unvollständige Liste von Fehlern, die sich auf die Konfiguration in diesem Dokument beziehen:

Hinweis: Diese Bugs werden als Teil der Versionshinweise auf cisco.com dokumentiert.

DDTS-ID

Status

Version gefunden

Behoben

************************************

CSCeb56287

V

4.1

4.6

Wenn Sie den Zustand eines Stromkreises der ML-Serie von In-Service (IS) bis Out-of-Service (OOS) und dann zurück zu IS bereitstellen, wird der Datenverkehr nicht wiederhergestellt. Um dieses Problem zu vermeiden, legen Sie vor dem Ändern des Status von IS den POS-Port auf Herunterfahren der CLI fest. Nachdem Sie den Status von OOS auf IS zurückgesetzt haben, stellen Sie den POS-Port auf no shutdown ein.

CSCeb24757

V

4.1

4.6

Wenn Sie eine Übertragungsfaser an einem ML1000-Port trennen, wird die Verbindung nur vom benachbarten Port unterbrochen. Im Idealfall müssen beide Ports feststellen, dass die Verbindung ausgefallen ist, sodass die Protokolle der oberen Schicht den Datenverkehr an einen anderen Port weiterleiten können. Um diese Situation zu umgehen, führen Sie ein Herunterfahren und kein Herunterfahren des Ports durch, an dem die Übertragungsfaser getrennt oder fehlerhaft ist.

CSCdy31775

V

4

4.6

Die Anzahl der verworfenen Pakete umfasst keine Pakete, die aufgrund einer Überlastung der Ausgabeliste verworfen werden. Dieses Problem tritt unter einer der folgenden Bedingungen auf:

- Datenverkehr auf Karten der ML-Serie zwischen Ethernet- und SONET-Ports mit konfigurierter Überbelegung der verfügbaren Leitungsbandbreite, was zu Überlastungen in der Ausgangswarteschlange führt.

- Datenverkehr von SONET zu Ethernet mit Überbelegung der verfügbaren Ethernet-Bandbreite.

CSCdz49700

C

4

-

Die Karten der ML-Serie leiten DTP-Pakete (Dynamic Trunking Protocol) immer zwischen angeschlossenen Geräten weiter. Wenn DTP auf angeschlossenen Geräten aktiviert ist (dies kann die Standardeinstellung sein), kann DTP Parameter aushandeln, z. B. ISL, die von den Karten der ML-Serie nicht unterstützt werden. Die Karte der ML-Serie zählt alle Pakete auf einer Verbindung, die zur Verwendung von ISL als Multicast-Pakete ausgehandelt werden, und STP- und CDP-Pakete werden zwischen verbundenen Geräten gequetscht, die ISL verwenden, ohne verarbeitet zu werden. Um dieses Problem zu vermeiden, deaktivieren Sie DTP und ISL auf angeschlossenen Geräten. Diese Funktion ist wie vorgesehen.

CSCdz68649

C

4

-

Unter bestimmten Bedingungen kann der Flusssteuerungsstatus anzeigen, dass die Flusskontrolle funktioniert, wenn die Flusssteuerung nicht funktioniert. Die Datenflusskontrolle auf den Karten der ML-Serie funktioniert nur, wenn Sie eine Überwachung auf Portebene konfigurieren. Bei einer Überwachung auf Portebene handelt es sich um eine Standardrichtlinie und nur um eine Klasse einer Eingaberichtlinienzuordnung. Die Datenflusssteuerung funktioniert auch nur, um die Quellrate auf die konfigurierte Rückwurfrate des Policers zu beschränken. Die Datenflusskontrolle verhindert keine Paketverwerfen aufgrund von Überlastungen in der Ausgabewarteschlange. Wenn Sie also keine Überwachung auf Portebene haben oder eine Überlastung der Ausgabewarteschlange auftritt, funktioniert die Richtlinienvergabe nicht. Die Richtlinienvergabe kann unter diesen Bedingungen jedoch immer noch fälschlicherweise als aktiviert erscheinen. Um dieses Problem zu vermeiden, konfigurieren Sie eine Richtlinie auf Portebene, und verhindern Sie eine Überlastung der Ausgabewarteschlange.

CSCdz69700

C

4

-

Wenn Sie eine Befehlssequenz für Shutdown/no Shutdown an einem ML1000-Port ausgeben, werden die Zähler gelöscht. Dies ist ein normaler Teil des Startprozesses, und diese Funktion wird nicht geändert.

CSCea11742

V

4

4.6

Wenn Sie einen Stromkreis zwischen zwei ML-POS-Ports als OOS bereitstellen, kann einer der Ports TPTFAIL fälschlicherweise melden. Dieses Problem tritt sowohl bei ML100T-12- als auch bei ML1000-2-Karten auf. Wenn dieses Problem auftritt, öffnen Sie ein Konsolenfenster zu jeder ML-Karte, und konfigurieren Sie den POS-Port so, dass er heruntergefahren wird.

CSCea20962

V

4

5

Wenn Sie OOS auf ML-Drop-Ports im Provisioning-Fenster anwenden, wird keine Warnung angezeigt.

CSCdy47284

C

4

-

ML-100 FastEthernet-MTU wird nicht erzwungen. Frames, die größer als 9050 Byte sind, können jedoch verworfen werden und Rx- und Tx-Fehler verursachen.

Statuscodes:

- V - Verifiziert (die Korrektur wird im Labor überprüft)

- C - Geschlossen (es wird wegen verschiedener Gründe keine Fehlerbehebung geben)

- Version gefunden: die Softwareversion, über die der Fehler erstmals gemeldet wurde

- Version behoben: die Software-Version, in der der Fehler behoben wurde

Fehlerbehebung und Fehlerisolierung

Mit den bisher vorliegenden Informationen sollen in diesem Abschnitt Fehlerisolierungsfälle erstellt werden. Basierend auf den vom System gemeldeten Symptomen enthält dieser Abschnitt schrittweise Tipps zur Fehlerbehebung. Diese Fallstudien beziehen sich auf einige häufige Symptome im Zusammenhang mit der ML-Karte auf ONS 15454.

In der Regel müssen Sie zur Problembehebung die folgenden Schritte ausführen:

- Sammeln Sie allgemeine Informationen und Fehlersymptome.

- Analysieren Sie die Informationen.

- Identifizieren Sie das Problem.

- Identifizieren Sie das Problem.

- Beheben Sie das Problem.

Einige dieser Schritte werden mehrmals durchlaufen.

Allgemeine Informationen

Grundlegende Informationserfassung

Sammeln Sie Informationen, bevor Sie die ML-Karte aufgrund eines Fehlers neu laden oder zurücksetzen. Ein manuelles Neuladen verwirft potenziell wertvolle Informationen. Alle Zähler werden manuell neu geladen, und alle im Speicher gespeicherten Protokolle gehen verloren. Cisco empfiehlt, den Befehl show tech-support und alle anderen Befehle zur Datenerfassung auszuführen, um Protokollinformationen wiederherzustellen, bevor Sie Fehlerbehebungsbefehle für den Router ausgeben. Wenn Sie die ML-Karte neu starten oder zurücksetzen, können Sie den Konsolen-/Telnet-Zugriff sowie die relevanten Informationen verlieren.

Konsolenprotokolle, die zum Ereignis führen, können ein Bild davon liefern, was zum Fehler oder Absturz geführt hat. Wenn ein Fehler auftritt, müssen Sie versuchen, alle Meldungen zu speichern, die an der Konsole oder im Puffer protokolliert wurden. Diese letzten Konsolenmeldungen könnten sich als entscheidend für die Erkennung des Problems erweisen. Je nach Art des Problems werden nicht alle Nachrichten auf den SYSLOG-Server geschrieben.

Verwenden Sie den Befehl show tech-support, um eine Vielzahl von Daten zu erfassen. Dieser Befehl ist häufig das beste Tool, um den Status des Routers nach dem Fehler zu einem bestimmten Zeitpunkt abzurufen.

Hier ist eine grundlegende Liste der Befehle, die der Befehl show tech-support ausführt. Welche Daten erfasst werden, hängt von der IOS-Version, der Hardware und den ausgewählten Optionen ab.

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

Zusätzlich zu diesen Befehlen erfassen Sie weitere Befehlsausgaben, die für die ML-Karte von besonderer Bedeutung sind, wie in den vorherigen Abschnitten dieses Dokuments beschrieben. Beispiel: Protokoll anzeigen, Alarm anzeigen usw. Vom CTC erfassen und exportieren Sie relevante Informationen, wie zuvor beschrieben, z. B. Alarme, Bedingungen, Schaltkreise, Bestände und Leistungsindikatoren.

Nützliche IOS-Tools zur Fehlerbehebung

Nachdem Sie die erforderlichen Informationen gesammelt haben, müssen Sie die Informationen auf Fehler entschlüsseln. Diese Aufgabe kann mit der Ausgabe eines show-tech-Befehls schwierig sein. Dies sind Tools, die die Ausgabe des Befehls show-tech und viele andere Befehle entschlüsseln können.

- Output Interpreter Tool (nur registrierte Kunden): Fügen Sie die Ausgabe des Befehls show tech-support in dieses Tool ein. Dieses Tool bietet eine schnelle Zusammenfassung aller gefundenen Probleme. Dies ist ein hervorragendes Tool, das eine schnelle Zusammenfassung der einfacheren Probleme bietet, mit denen Sie konfrontiert werden. Dieses Tool interpretiert eine Vielzahl von Eingaben. Zum Durchsuchen können Sie das Dropdown-Feld "Technologie" verwenden. Das Tool ist jedoch nicht perfekt und muss ausgewertet werden, um die Informationen zu validieren.

- Befehlssuche-Tool: Wählen Sie eine der folgenden Referenzhandbücher aus, um nach einem Befehl und der Syntax zu suchen:

- IOS-Befehlsreferenz

- IOS-Konfigurationsleitfaden

- Catalyst Befehlsreferenz

- PIX-Firewall-Befehlsreferenz

- Fehlermeldung Decoder: Mit diesem Tool können Sie Fehlermeldungen für die Cisco IOS Software, Catalyst Switches Software und die Cisco Secure PIX Firewall Software recherchieren und beheben. Fügen Sie die Fehlermeldungen aus den Protokolldateien ein, und aktivieren Sie das Kontrollkästchen Vorschlagsrelevante Dokumente in den Ergebnissen.

- Bug-Toolkit: Suchen Sie nach Ergebnissen, die auf einer oder mehreren der folgenden Optionen basieren:

- IOS-Version

- Features oder Komponenten.

- Schlüsselwörter.

- Bug Severity (Fehlerschweregrad) (Sie können einen bestimmten Schweregrad auswählen oder einen Bereich angeben).

- TAC-Fallsammlung: Mit Lösungen, die TAC-Techniker bereitstellen, können Sie häufige Probleme in Bezug auf Hardware, Konfiguration und Leistung interaktiv diagnostizieren.

Hinweis: Einige Tools sind für die ML-Karte nicht zu 100% kompatibel.

Anwenderberichte

In diesem Abschnitt werden einige der gängigen Fehlerzustände und mögliche Schritte beschrieben, mit denen Sie die Bedingungen isolieren können. Detaillierte Informationen zu Warnmeldungen finden Sie im Cisco ONS 15454 Troubleshooting Guide, Releases 4.1.x und 4.5.

CARLOSS-Alarm auf einem ML-Ethernet-Port gemeldet

Major (MJ) und Service-Affecting (SA), ein Carrier Loss-Alarm auf der Ethernet-Karte der ML-Serie (Datenverkehr), ist das Datenäquivalent des "LOS (OC-N)"-Alarms. Der Ethernet-Port hat die Verbindung verloren und empfängt kein gültiges Signal.

Ein CARLOSS-Alarm tritt auf, wenn der Ethernet-Port von der IOS-CLI als no shutdown-Port konfiguriert wurde und eine der folgenden Bedingungen ebenfalls erfüllt ist:

- Das Kabel ist nicht richtig mit dem nahe oder weit entfernten Anschluss verbunden.

- Automatische Aushandlung schlägt fehl.

- Die Geschwindigkeit (nur für 10/100-Ports) ist falsch eingestellt.

Wie in diesem Test zwischen der Knoten-ML-Karte 7603b und .252 gezeigt, deaktivieren Sie die automatische Aushandlung, um die Ports zu aktivieren.

Für POS gemeldeter TPTFAIL-Alarm

Dies ist ein wichtiger Alarm (MJ), der den Service beeinträchtigt (SA). Der Alarm "TPT Layer Failure" weist auf eine Unterbrechung der End-to-End-POS-Verbindungsintegritätsfunktion der POS-Karten der ML-Serie hin. TPTFAIL weist auf einen Zustand am anderen Ende oder eine falsche Konfiguration des POS-Ports hin.

Der TPTFAIL-Alarm weist auf ein Problem am SONET-Pfad, am Remote-POS-Port oder auf eine Fehlkonfiguration des POS-Ports hin, die verhindert, dass der vollständige End-to-End-POS-Pfad funktioniert.

Wenn SONET-Pfadalarme, z. B. "AIS-P", "LOP-P", "PDI-P" oder "UNEQ-P", auf dem vom POS-Port verwendeten Schaltkreis vorhanden sind, kann der betroffene Port einen TPTFAIL-Alarm melden.

Wenn der POS-Port der Gegenstelle der ML-Serie administrativ deaktiviert ist, fügt der Port eine "AIS-P"-Bedingung ein, die der Nahtendport erkennt. Der Nahbereichsport kann in diesem Fall TPTFAIL melden. Der POS-Port am anderen Ende berichtet über PRDI und PPDI. Sie können alle Alarme mit dem Befehl show ons alarm anzeigen. Wenn der POS-Port auf IOS-CLI-Ebene falsch konfiguriert ist, führt die Fehlkonfiguration zum Ausfall des Ports und meldet TPTFAIL.

Gehen Sie wie folgt vor, um den TPTFAIL-Alarm (ML-Serie) zu löschen:

1. Wenn keine SONET-Alarme für den POS-Port-Circuit auftreten, überprüfen Sie, ob Sie beide POS-Ports ordnungsgemäß konfiguriert haben.

2. Wenn nur der Alarm "PLM-P" für den POS-Port-Circuit auftritt, überprüfen Sie, ob Sie beide POS-Ports ordnungsgemäß konfiguriert haben.

3. Wenn nur der "PDI-P"-Zustand auf dem POS-Port-Circuit auftritt und der Circuit durch eine Karte der G-Serie terminiert wird, prüfen Sie, ob ein Alarm "CARLOSS (G-Series Ethernet)" auf die Karte der G-Serie auftritt. Wenn ja, schließen Sie das Verfahren zum Löschen des CARLOSS-Alarms (G-Serie Ethernet) aus.

4. Wenn der Alarm "AIS-P", der Alarm "LOP-P" oder der Alarm "UNEQ-P" vorhanden ist, führen Sie eine Fehlerbehebung für den SONET-Pfad (den Pfad zwischen den beiden POS-Schnittstellen über denselben Stromkreis) durch, um diese Alarme zu löschen.

Gigabit-Ethernet-Schnittstelle bleibt hängen

Siehe CARLOSS-Alarm, der an einem ML-Ethernet-Port gemeldet wird.

POS-Schnittstelle meldet CRC-Fehler

Dieses Problem ist in der Regel auf eine CRC-Diskrepanz bei POS-Konfigurationen zurückzuführen.

POS-Berichte - PPDI

PDI-P ist ein Satz anwendungsspezifischer Codes, die in dem vom ONS-Knoten generierten STS-Pfad-Overhead (POH) enthalten sind. Der Alarm zeigt Downstream-Geräten an, dass ein Fehler in einer oder mehreren direkt zugeordneten Payloads in diesem synchronen STS-Payload-Umschlag vorliegt.

Ein PDI-P-Zustand am Port einer OC-N-Karte, die einen Kartenkreis der ML-Serie unterstützt, kann aus der End-to-End-Ethernet-Verbindungsintegritätsfunktion der Karte der ML-Serie resultieren. Wenn das Problem auf die Link-Integrität zurückzuführen ist, wird auch der Alarm "TPTFAIL (G-Series Ethernet)" (TPTFAIL (G-Series Ethernet)) oder ein Alarm ausgegeben, der bei einem oder beiden POS-Ports gemeldet wird, um die Leitung zu beenden. Wenn TPTFAIL an einem oder beiden POS-Ports auftritt, beheben Sie den Alarm, der TPTFAIL beiliegt, um den PDI-P-Zustand zu löschen. Der PDI-P-Alarm kann auch ein Symptom eines festgeklemmten Alarms sein.

Das folgende Beispiel zeigt Alarme, die aufgrund von POS0 administrativ auf 225 auftreten:

0,225 POS 0 (geschlossen)

0,252 POS 0

PPDI, PRDI

PAIS, TPTFAIL

In diesem Beispiel gibt PAIS an, dass das Problem am Stammpunkt des Knotens .225 liegt. Wenn Sie PAIS löschen, sind auch TPTFAIL, PPDI und PRDI klar.

POS-Berichte PRDI

PRDI zeigt an, dass das Problem am anderen Ende liegt. Dieses Problem kann auftreten, weil der Gegenstelle den AIS-Alarm empfängt. Weitere Informationen finden Sie unter POS Reports PPDI.

POS-Berichte PAIS

Die AIS-Pfadbedingung bedeutet, dass dieser Knoten AIS im eingehenden Pfad erkennt.

Im Allgemeinen ist jedes AIS ein spezielles SONET-Signal, das dem Empfängerknoten mitteilt, dass der Senderknoten kein gültiges Signal zum Senden bereitstellt. AIS ist kein Fehler. Der Empfängerknoten löst die Fehlerbedingung AIS auf jeder Eingabe aus, bei der der Knoten das Signal AIS anstatt eines echten Signals erkennt. In den meisten Fällen löst ein Upstream-Knoten einen Alarm aus, um auf einen Signalfehler hinzuweisen. Alle Downstream-Knoten lösen nur einen bestimmten Typ von AIS aus. Diese Bedingung wird gelöscht, wenn Sie das Problem auf dem Upstream-Knoten beheben.

POS-Berichte PPLM

Dieses Problem ist kritisch (CR) und servicebeeinträchtigend (SA)

Ein Alarm zur Pfaderkennung für Payload-Label-Übereinstimmung auf einem Knoten zeigt an, dass das eingehende Signal nicht mit dem lokal bereitgestellten Label übereinstimmt. Die Bedingung ist auf einen ungültigen C2-Bytewert im SONET-Pfad-Overhead zurückzuführen. Durch Scrambling und Kapselung können die C2-Werte geändert werden.

POS-Schnittstelle bleibt hängen

Eine Vielzahl von Alarmen kann die POS-Schnittstelle zum Erliegen bringen. Standardmäßig führen diese Alarme dazu, dass die POS-Verbindung ausfällt: PAIS, PLOP, PTIM, PUNEQ, PRDI, PPLM, PPDI, BER_SF_B3. Um die Liste zu ändern, verwenden Sie den Schnittstellenbefehl POS-Triggerdefekte. Wenn die POS-Schnittstelle aktiv oder inaktiv ist, wird die Ursache protokolliert (Protokoll anzeigen). Sie können alle aktiven Alarme oder Defekte mit dem Befehl show ons alarm abrufen. Beheben Sie die Ursache für die Aktivierung der POS-Schnittstelle. Wenn die POS-Schnittstelle ausfällt, wird ein TPTFAIL-Alarm ausgelöst.

Wenn Sie eine Verbindung zu POS-Schnittstellen anderer Anbieter herstellen, stellen Sie sicher, dass diese Elemente auf beiden Seiten übereinstimmen:

1. Komplikationen

2. C2-Wert

3. CRC

POS-Schnittstelle meldet Eingabefehler.

Eingabefehler, die sich an einer POS-Schnittstelle anhäufen (Anzeige von POS- und CTC-PM-Zählern), weisen darauf hin, dass die eingehenden Pakete fehlerhaft sind. Eine Vielzahl von Ursachen kann zu Eingabefehlerpaketen führen.

Fehlerbehebung bei vorhandenen Alarmen

Wenn CRC-Fehler zusammen mit Eingabefehlern auftreten, können CRC-Fehler die Ursache für Eingabefehler sein. Fehlerbehebung bei CRC-Konfigurationen

Überprüfen der POS-Schnittstellenkonfigurationen

Fehlerbehebung bei den Pfadkomponenten zwischen den beiden POS-Ports Wenn Eingabefehler ohne entsprechende Erhöhung in anderen Komponentenfehlern inkrementiert werden, sollten Sie ein Hardwareproblem in Betracht ziehen. Führen Sie vor dem Hardware-Ersatz die folgenden Schritte auf beiden Seiten des Schaltkreises aus (jeweils einzeln), um festzustellen, ob das Problem weiterhin besteht:

- TCC-Side-Switch

- XC-Side-Switch

- Schutz-Switch an den SONET-Ports, falls Schutz vorhanden

- Softreset für ML-Karten

- ML-Karte wieder einsetzen

Der CDP-Nachbarn wird nicht angezeigt.

Überprüfen Sie, ob Sie CDP auf beiden Schnittstellen aktiviert haben.

Fehlerbehebung bei vorhandenen Alarmen und Schnittstellenfehlern

Kein End-to-End-Datenverkehrsfluss

Überprüfen Sie die Konfigurationen auf den beiden Endgeräten.

Fehlerbehebung bei vorhandenen Alarmen und Fehlern

Anhang: Grundlegende Informationen zur Testkonfiguration und zu Befehlen

In diesem Abschnitt werden die grundlegenden Konfigurationsinformationen für alle in diesem Test verwendeten Geräte erfasst, die als Grundlage für die Fehlerbehebung verwendet werden.

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

0,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

Zugehörige Informationen

- Technischer Support und Dokumentation für Cisco Systeme