Fehlerbehebung bei Port-Flaps auf Catalyst Switches der Serie 9000
Inhalt
Problem
In diesem Dokument wird die Fehlerbehebung bei einer oder mehreren Switch-Schnittstellen beschrieben, die wiederholt den Status zwischen aktiv und inaktiv ändern (Port-Flaps oder Link-Flaps), wodurch es zu einer unterbrochenen Verbindung kommt.
Umwelt
Cisco Catalyst Switches der Serie 9000 mit Kupfer- oder Glasfaser-Uplinks/-Downlinks. Das Problem kann an Access-Ports, Uplinks und (sofern vorhanden) austauschbaren Netzwerkmodul-Ports auftreten. Der physische Pfad kann Patchfelder, Endgeräte und optische Transceiver umfassen.
- Medienanwendbarkeit: TDR gilt nur für Kupferschnittstellen. DOM gilt nur für unterstützte optische Transceiver.
- Schnittstellentypen: Standalone-Ports mit fester Konfiguration und Modulports werden abgedeckt. verwenden Sie den gleichen Workflow für beide.
- Unterstützte optische Verbindungen: Verwenden Sie nur optische Kabel, die für die Plattform- und Softwareversion unterstützt werden.
Ursache
Häufige Ursachen sind fehlerhafte oder nicht unterstützte Verkabelung, nicht unterstützte oder fehlerhafte SFP- (Small Form-Factor Pluggable) oder SFP+-Transceiver, Duplex- oder Verhandlungs-Diskrepanzen, Stromsparverhalten von Endgeräten und andere Fehler auf physischer Ebene.
Auflösung
Befolgen Sie den Workflow zur Fehlerbehebung in diesem Artikel, um die Flapping-Protokolle zu bestätigen, physische Verbindungen und optische Verbindungen zu validieren, die Schnittstellenzähler zu überprüfen und ggf. DOM-Prüfungen für den ausschließlichen Kupfer- oder Glasfaser-TDR durchzuführen.
Voraussetzungen
Anforderungen
Es gibt keine spezifischen Anforderungen für dieses Dokument.
Verwendete Komponenten
Die Informationen in diesem Dokument basieren auf Cisco Catalyst Switches der Serie 9000.
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 Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle kennen.
Hintergrundinformationen
Eine Port-Klappe, auch als Link-Klappe bezeichnet, tritt auf, wenn eine physische Schnittstelle am Switch wiederholt aktiv ist und abfällt. Häufige Ursachen sind schlechte, nicht unterstützte oder nicht standardmäßige Verkabelung, nicht unterstützte SFP-Transceiver (Small Form-Factor Pluggable) und andere Probleme bei der Synchronisierung der Verbindungen. Der Zustand kann intermittierend oder permanent sein.
Da Link-Flaps tendenziell ein physisches Problem darstellen, wird in diesem Dokument beschrieben, wie das Problem diagnostiziert, nützliche Protokolle gesammelt und Fehler bei Port-Flaps auf Cisco Catalyst Switches der Serie 9000 behoben werden.
Fehlerbehebung-Workflow
Verwenden Sie diesen Workflow, um die häufigsten Ursachen für Port-Flaps zu identifizieren. Beginnen Sie mit Schritt 1, und fahren Sie in der richtigen Reihenfolge fort. Führen Sie optionale Schritte nur dann aus, wenn Linktyp und Symptome übereinstimmen.
- Bestätigen Sie die Klappe in Protokollen. Verwenden Sie die Show-Protokollierung, um wiederholte Up-/Down-Ereignisse zu bestätigen und Zeitstempel aufzuzeichnen.
- Überprüfen Sie die physische Verbindung und die optischen Verbindungen. Prüfen der Verkabelung, der Patchfelder und der unterstützten Transceiver Setzen Sie die Komponente wieder ein, oder tauschen Sie sie durch zweifelsfrei funktionierende Komponenten aus.
- Überprüfen Sie die Schnittstellenzähler und die Hardware-Statistiken. Verwenden Sie show interfaces (Schnittstellen anzeigen) und Controller Counter (Controller-Zähler), um Layer-1-Fehler (CRC, Symbolfehler, FCS-Fehler) zu identifizieren.
- Führen Sie TDR aus (nur Kupferverbindungen). Verwenden Sie TDR, um OPEN/SHORT-Bedingungen und eine ungefähre Fehlerentfernung zu erkennen.
- Aktivieren Sie DOM (nur Glasfaserverbindungen). Überprüfen der optischen Leistung, Temperatur und Spannung anhand der Grenzwerte des Datenblatts
- Überprüfen Sie die FEC (nur unterstützte optische Verbindungen). Bestätigen Sie ggf. die Einstellungen für die Weiterleitungsfehlerkorrektur und die Kompatibilität.
- Verwenden Sie nur dann debug-Befehle, wenn das Problem weiterhin besteht. Sammeln Sie die zielgerichtete Debug-Ausgabe während eines Wiedergabefensters, und deaktivieren Sie sie unmittelbar nach der Erfassung.
Jeder Abschnitt enthält einen kurzen Hinweis, der angibt, wann er zu verwenden ist.
Verwenden Sie diesen Abschnitt, wenn physischer Zugriff verfügbar ist. Überprüfen Sie, ob die Netzwerkmodule, Kabel und SFP- oder SFP+-Transceiver ordnungsgemäß installiert sind, bevor Sie die Zähler überprüfen oder zusätzliche Diagnosen durchführen.
Referenz zur Installation des Netzwerkmoduls
Verwenden Sie diese Referenz, wenn ein Wechselnetzwerkmodul vorhanden ist. In der Tabelle werden die Best Practices für die Installation eines Netzwerkmoduls auf einem Cisco Catalyst Switch der Serie 9000 beschrieben:
| Plattform |
URL |
| Catalyst Switches der Serie 9200 |
Hardware-Installationsanleitung für Catalyst Switches der Serie 9200 |
| Catalyst Switches der Serie 9300 |
Hardware-Installationsanleitung für Catalyst Switches der Serie 9300 |
| Catalyst Switches der Serie 9400 |
Hardware-Installationsanleitung für Catalyst Switches der Serie 9400 |
| Catalyst Switches der Serie 9500 |
Hardware-Installationsanleitung für Catalyst Switches der Serie 9500 |
| Catalyst Switches der Serie 9600 |
Hardware-Installationsanleitung für Catalyst Switches der Serie 9600 |
Prüfen Sie das Kabel und beide Seiten der Verbindung.
Verwenden Sie diesen Abschnitt, nachdem die Klappe in den Protokollen bestätigt wurde. Diese Tabellen beschreiben häufige kabelbezogene Ursachen von Verbindungsklappen und die empfohlenen Wiederherstellungsaktionen.
| Ursache |
Wiederherstellungsaktion |
| Fehlerhaftes Kabel |
Ersetzen Sie das verdächtige Kabel durch ein zweifelsfrei funktionierendes Kabel. Suchen Sie nach abgebrochenen oder fehlenden Stiften an den Anschlüssen. |
| Lose Verbindung |
Schließen Sie das Kabel wieder an. Entfernen Sie den Steckverbinder, und setzen Sie ihn wieder ein, um sicherzustellen, dass er vollständig eingesetzt ist. |
| Patchpanel |
Vermeiden Sie fehlerhafte Patchpanel-Anschlüsse. Umgehen Sie das Patchpanel, wenn möglich, um es auszuschließen. |
| Schlechter oder falscher SFP (glasfaserspezifisch) |
Ersetzen Sie den verdächtigen SFP durch einen zweifelsfrei funktionierenden SFP. Überprüfen Sie den Hardware- und Software-Support für diesen SFP-Typ. |
| Fehlerhafter Port oder Modulport |
Schließen Sie das Kabel an einen zweifelsfrei funktionierenden Anschluss an, um einen fehlerhaften Anschluss oder ein fehlerhaftes Modul zu beheben. |
| Ungültiges oder altes Endgerät |
Tauschen Sie das Telefon, den Lautsprecher oder ein anderes Endgerät durch ein zweifelsfrei funktionierendes oder ein neueres Gerät aus. |
| Geräte-Energiesparmodus |
Dies kann eine erwartete Klappe sein. Überprüfen Sie den Zeitstempel der Port-Klappe. Vergleichen Sie es mit anderen gleichzeitigen Ereignissen. Stellen Sie dann fest, ob eine Ruhephase die Ursache ist. |
Überprüfung der SFP- und SFP+-Kompatibilität
Verwenden Sie diesen Abschnitt, wenn die Flapping-Verbindung einen Glasfaser-Transceiver verwendet. Das Cisco Portfolio an Hot-Plug-fähigen Schnittstellen bietet eine große Auswahl an Übertragungsgeschwindigkeiten, Protokollen, Reichweiten und unterstützten Übertragungsmedien.
Verwenden Sie eine beliebige Kombination von SFP- oder SFP+-Transceivermodulen, die vom Cisco Catalyst Switch der Serie 9000 unterstützt wird. Jeder Port muss den Wellenlängenspezifikationen am anderen Ende des Kabels entsprechen. Das Kabel darf die unterstützte Kabellänge für eine zuverlässige Kommunikation nicht überschreiten.
Verwenden Sie auf dem Cisco Gerät nur Cisco SFP-Transceiver-Module. Jedes SFP- oder SFP+-Transceiver-Modul unterstützt die Cisco Quality Identification (ID)-Funktion. Mit dieser Funktion können Cisco Switches oder Router feststellen und validieren, ob das Transceiver-Modul von Cisco zertifiziert und getestet wurde.
Identifizieren von Port-Flaps
Voraussetzungen: Privilegierter EXEC-Zugriff (z. B. enable) und Zugriff auf den Systemprotokollpuffer des Geräts oder Remote-Syslog.
Erwartetes Ergebnis: Wiederholte Up-/Down-Meldungen für dieselbe Schnittstelle innerhalb eines kurzen Zeitfensters bestätigen einen Flapping-Zustand.
Verwenden Sie zunächst diesen Abschnitt, um zu bestätigen, dass eine Klappe auftritt. Führen Sie den show logging | include changed Befehl aus, um ein Link-Flap-Ereignis zu identifizieren. Dieses Beispiel zeigt teilweise Protokollmeldungen des Switch-Systems für ein Link-Flapping-Ereignis an der Schnittstelle TenGigabitEthernet1/0/40:
Switch#show logging | include changed
August 17 21:06:08.431 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/0/40, changed state to down
August 17 21:06:39.058 UTC: %LINK-3-UPDOWN: Interface TenGigabitEthernet1/0/40, changed state to down
August 17 21:06:41.968 UTC: %LINK-3-UPDOWN: Interface TenGigabitEthernet1/0/40, changed state to up
August 17 21:06:42.969 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/0/40, changed state to up
August 17 21:07:20.041 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/0/40, changed state to down
August 17 21:07:21.041 UTC: %LINK-3-UPDOWN: Interface TenGigabitEthernet1/0/40, changed state to down
August 17 21:07:36.534 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/0/40, changed state to up
August 17 21:08:06.598 UTC: %LINK-3-UPDOWN: Interface TenGigabitEthernet1/0/40, changed state to up
August 17 21:08:07.628 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/0/40, changed state to down
August 17 21:08:08.628 UTC: %LINK-3-UPDOWN: Interface TenGigabitEthernet1/0/40, changed state to down
August 17 21:08:10.943 UTC: %LINK-3-UPDOWN: Interface TenGigabitEthernet1/0/40, changed state to up
August 17 21:08:11.944 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/0/40, changed state to up
- Identifizieren Sie den Zeitstempel für jeden Übergang nach oben/unten.
- Vergleichen Sie den Zeitstempel mit anderen Ereignissen auf derselben Schnittstelle (z. B. Stromsparverhalten von Endpunkten).
- Stellen Sie fest, ob die Klappe erwartet wird oder auf ein Problem auf der physischen Ebene hinweist.
Befehle zum Anzeigen von Schnittstellen
Verwendungszweck: Nach wiederholtem Auf/Ab werden Ereignisse bestätigt und der physische Pfad validiert.
Command: show interfaces und show controllers Ethernet-Controller-Schnittstelle für die betroffene Schnittstelle.
Erwartetes Ergebnis: Fehlerzähler (CRC, Symbolfehler, FCS) bleiben stabil oder steigen unter normalen Bedingungen langsam an.
Nächste Aktion bei Anomalien: Tauschen Sie das Kabel/die optische Komponente aus, wechseln Sie zu einem zweifelsfrei funktionierenden Port, und überprüfen Sie die Zähler erneut. fahren Sie mit TDR (Kupfer) bzw. DOM (Faser) fort.
Verwenden Sie diesen Abschnitt, nachdem die Klappe bestätigt und der physische Pfad überprüft wurde. Der Befehl show interfaces liefert Informationen zur Identifizierung eines möglichen Layer-1-Problems, das ein Link-Flap-Ereignis verursacht:
Switch#show interfaces tenGigabitEthernet 1/0/40
TenGigabitEthernet1/0/40 is up, line protocol is up (connected)
Hardware is Ten Gigabit Ethernet, address is 00a5.bf9c.29a8 (bia 00a5.bf9c.29a8)
MTU 1500 bytes, BW 10000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive not set
Full-duplex, 10Gb/s, link type is auto, media type is SFP-10GBase-SR <-- SFP plugged into the port
input flow-control is on, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:03, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 0/2000/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
670 packets input, 78317 bytes, 0 no buffer
Received 540 broadcasts (540 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 540 multicast, 0 pause input
0 input packets with dribble condition detected
1766 packets output, 146082 bytes, 0 underruns
0 Output 0 broadcasts (0 multicasts)
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out
In der Tabelle werden einige der Leistungsindikatoren aus dem Befehl show interfaces aufgeführt:
| Zähler |
Probleme und häufige Ursachen, die die Fehlerzähler erhöhen |
| CRC |
Eine hohe Anzahl von CRC-Fehlern (Cyclic Redundancy Check) ist in der Regel das Ergebnis von Kollisionen. Es kann auch auf ein physisches Problem hinweisen, wie z. B. Verkabelung, SFP, fehlerhafte Schnittstellen oder Netzwerkkarten. Sie kann auch auf eine Duplexungleichheit hinweisen. |
| Input errors |
In diese Kategorie gehören Runts, Giants, No Buffer, CRC, Frame, Overrun sowie Ignored. Andere Eingabefehler können ebenfalls die Anzahl der Eingabefehler erhöhen. |
| output errors |
Ausgabefehler können zunehmen, wenn die Größe der Ausgabewarteschlange zu gering ist oder die Schnittstelle überbelegt ist. |
| Gesamtleistung sinkt |
Ausgabekürzungen sind in der Regel das Ergebnis einer Schnittstellenüberbelegung, die durch n-zu-eins-Datenverkehrsmuster oder einen Transfer von 10 Gbit/s zu 1 Gbit/s verursacht wird. Schnittstellenpuffer sind eine begrenzte Ressource und können nur punktuelle Spitzen absorbieren. Danach werden die Pakete verworfen. Puffer können so eingestellt werden, dass sie ein gewisses Polster bereitstellen, aber sie können keine Nullausgabe garantieren. |
| Unbekanntes Protokoll wird gelöscht |
Unbekannte Protokollverluste treten auf, wenn die empfangende Schnittstelle nicht für dieses Protokoll konfiguriert ist oder der Switch das Protokoll nicht erkennt. Wenn beispielsweise zwei Switches verbunden sind und das Cisco Discovery Protocol (CDP) an einer Switch-Schnittstelle deaktiviert ist, treten unbekannte Protokollverluste an dieser Schnittstelle auf. Die CDP-Pakete werden nicht mehr erkannt, und der Switch verwirft sie. |
Mit dem Befehl history kann eine Schnittstelle den Nutzungsverlauf in einem grafischen Format ähnlich dem CPU-Verlauf verwalten. Der Verlauf kann entweder als Bit pro Sekunde (Bit/s) oder als Pakete pro Sekunde (pps) verwaltet werden, wie in diesem Beispiel gezeigt:
Switch(config-if)#history ?
bps Maintain history in bits/second
pps Maintain history in packets/second
Zusammen mit der Rate können verschiedene Schnittstellenzähler überwacht werden:
Switch(config-if)#history [bps|pps] ?
all Include all counters
babbles Include ethernet output babbles - Babbl
crcs Include CRCs - CRCs
deferred Include ethernet output deferred - Defer
dribbles Include dribbles - Dribl
excessive-collisions Include ethernet excessive output collisions -
ExCol
flushes Include flushes - Flush
frame-errors Include frame errors - FrErr
giants Include giants - Giant
ignored Include ignored - Ignor
input-broadcasts Include input broadcasts - iBcst
input-drops Include input drops - iDrop
input-errors Include input errors - iErr
interface-resets Include interface resets - IRset
late-collisions Include ethernet late output collisions - LtCol
lost-carrier Include ethernet output lost carrier - LstCr
multi-collisions Include ethernet multiple output collisions -
MlCol
multicast Include ethernet input multicast - MlCst
no-carrier Include ethernet output no-carrier - NoCarr
output-broadcasts Include output broadcasts - oBcst
output-buffer-failures Include output buffer failures - oBufF
output-buffers-swapped-out Include output buffers swapped out - oBSwO
output-drops Include output drops - oDrop
output-errors Include output errors - oErr
output-no-buffer Include output no buffer - oNoBf
overruns Include overruns - OvrRn
pause-input Include ethernet input pause - PsIn
pause-output Include ethernet output pause - PsOut
runts Include runts - Runts
single-collisions Include ethernet single output collisions - SnCol
throttles Include throttles - Thrtl
underruns Include underruns - UndRn
unknown-protocol-drops Include unknown protocol drops - Unkno
watchdog Include ethernet output watchdog - Wtchdg
<cr> <cr>
SW_1(config-if)#
Wie beim CPU-Verlauf sind Diagramme für die letzten 60 Sekunden, die letzten 60 Minuten und die letzten 72 Stunden verfügbar. Für Eingabe- und Ausgabehistogramme werden separate Diagramme beibehalten:
Switch#show interfaces gigabitEthernet 1/0/2 history ?
60min Display 60 minute histograms only
60sec Display 60 second histograms only
72hour Display 72 hour histograms only
all Display all three histogram intervals
both Display both input and output histograms
input Display input histograms only
output Display output histograms only
| Output modifiers
<cr> <cr>
------ Sample output ---------
Switch#show interfaces tenGigabitEthernet 1/0/9 history 60sec
10
9
8
7
6
5
4
3
2
1
0....5....1....1....2....2....3....3....4....4....5....5....6
0 5 0 5 0 5 0 5 0 5 0
TenGigabitEthernet1/0/9 input rate(mbits/sec) (last 60 seconds)
10
9
8
7
6
5
4
3
2
1
0....5....1....1....2....2....3....3....4....4....5....5....6
0 5 0 5 0 5 0 5 0 5 0
TenGigabitEthernet1/0/9 output rate(mbits/sec) (last 60 seconds)
Verwenden Sie den Befehl show controllers ethernet-controller interface {interface{interface-number}}, um Schnittstellenspezifische Datenverkehrszähler (Senden und Empfangen) und Fehlerstatistiken anzuzeigen, die von der Hardware gelesen werden. Verwenden Sie das Schlüsselwort phy, um die internen Schnittstellenregister anzuzeigen. Verwenden Sie das Schlüsselwort port-info, um Informationen über den anwendungsspezifischen integrierten Schaltkreis (ASIC) des Ports anzuzeigen.
Dies ist ein Beispiel für die Ausgabe des Ethernet-Controllers show controllers für eine bestimmte Schnittstelle:
Switch#show controllers ethernet-controller tenGigabitEthernet 2/0/1
Transmit TenGigabitEthernet2/0/1 Receive
61572 Total bytes 282909 Total bytes
0 Unicast frames 600 Unicast frames
0 Unicast bytes 38400 Unicast bytes
308 Multicast frames 3163 Multicast frames
61572 Multicast bytes 244509 Multicast bytes
0 Broadcast frames 0 Broadcast frames
0 Broadcast bytes 0 Broadcast bytes
0 System FCS error frames 0 IpgViolation frames
0 MacUnderrun frames 0 MacOverrun frames
0 Pause frames 0 Pause frames
0 Cos 0 Pause frames 0 Cos 0 Pause frames
0 Cos 1 Pause frames 0 Cos 1 Pause frames
0 Cos 2 Pause frames 0 Cos 2 Pause frames
0 Cos 3 Pause frames 0 Cos 3 Pause frames
0 Cos 4 Pause frames 0 Cos 4 Pause frames
0 Cos 5 Pause frames 0 Cos 5 Pause frames
0 Cos 6 Pause frames 0 Cos 6 Pause frames
0 Cos 7 Pause frames 0 Cos 7 Pause frames
0 Oam frames 0 OamProcessed frames
0 Oam frames 0 OamDropped frames
193 Minimum size frames 3646 Minimum size frames
0 65 to 127 byte frames 1 65 to 127 byte frames
0 128 to 255 byte frames 0 128 to 255 byte frames
115 256 to 511 byte frames 116 256 to 511 byte frames
0 512 to 1023 byte frames 0 512 to 1023 byte frames
0 1024 to 1518 byte frames 0 1024 to 1518 byte frames
0 1519 to 2047 byte frames 0 1519 to 2047 byte frames
0 2048 to 4095 byte frames 0 2048 to 4095 byte frames
0 4096 to 8191 byte frames 0 4096 to 8191 byte frames
0 8192 to 16383 byte frames 0 8192 to 16383 byte frames
0 16384 to 32767 byte frame 0 16384 to 32767 byte frame
0 > 32768 byte frames 0 > 32768 byte frames
0 Late collision frames 0 SymbolErr frames <-- Usually indicates Layer 1 issues. Large amounts of symbol errors can indicate a bad device, cable, or hardware.
0 Excess Defer frames 0 Collision fragments <-- If this counter increments, this is an indication that the ports are configured at half-duplex.
0 Good (1 coll) frames 0 ValidUnderSize frames
0 Good (>1 coll) frames 0 InvalidOverSize frames
0 Deferred frames 0 ValidOverSize frames
0 Gold frames dropped 0 FcsErr frames <-- Are the result of collisions at half-duplex, a duplex mismatch, bad hardware (NIC, cable, or port)
0 Gold frames truncated
0 Gold frames successful
0 1 collision frames
0 2 collision frames
0 3 collision frames
0 4 collision frames
0 5 collision frames
0 6 collision frames
0 7 collision frames
0 8 collision frames
0 9 collision frames
0 10 collision frames
0 11 collision frames
0 12 collision frames
0 13 collision frames
0 14 collision frames
0 15 collision frames
0 Excess collision frames
LAST UPDATE 22622 msecs AGO
Verwenden Sie den Befehl show platform pm interface-flaps {interface{interface-number}}, um anzuzeigen, wie oft eine Schnittstelle ausfällt:
Dies ist ein Beispiel für die Ausgabe von show platform pm interface-flaps {interface{interface-number}} für eine bestimmte Schnittstelle:
Switch#show platform pm interface-flaps tenGigabitEthernet 2/0/1 Field AdminFields OperFields =============================================================== Access Mode Static Static Access Vlan Id 1 0 Voice Vlan Id 4096 0 VLAN Unassigned 0 ExAccess Vlan Id 32767 Native Vlan Id 1 Port Mode dynamic access Encapsulation 802.1Q Native disl auto Media unknown DTP Nonegotiate 0 0 Port Protected 0 0 Unknown Unicast Blocked 0 0 Unknown Multicast Blocked 0 0 Vepa Enabled 0 0 App interface 0 0 Span Destination 0 Duplex auto full Default Duplex auto Speed auto 1000 Auto Speed Capable 1 1 No Negotiate 0 0 No Negotiate Capable 1024 1024 Flow Control Receive ON ON Flow Control Send Off Off Jumbo 0 0 saved_holdqueue_out 0 saved_input_defqcount 2000 Jumbo Size 1500 Forwarding Vlans : none Current Pruned Vlans : none Previous Pruned Vlans : none Sw LinkNeg State : LinkStateUp No.of LinkDownEvents : 12 <-- Number of times the interface flapped XgxsResetOnLinkDown(10GE): Time Stamp Last Link Flapped(U) : Aug 19 14:58:00.154 <-- Last time the interface flapped LastLinkDownDuration(sec) 192 <-- Time in seconds the interface stayed down during the last flap event LastLinkUpDuration(sec): 2277 <-- Time in seconds the interface stayed up before the last flap event
Verwenden Sie diesen Abschnitt für Glasfaserverbindungen, wenn die optische Integrität überprüft werden muss. Verwenden Sie den Befehl show idprom interface {interface-number}, um die IDPROM-Informationen für den in der angegebenen Schnittstelle installierten Transceiver anzuzeigen. Verwenden Sie das Stichwort detail, um detaillierte hexadezimale IDPROM-Felder anzuzeigen.
Dieses Beispiel zeigt die Ausgabe des Befehls show idprom {interface{interface-number}} für eine bestimmte Schnittstelle. Die in diesem Befehl aufgeführten Schwellenwerte für hohe und niedrige Warnungen|Alarm sind die normalen Parameter des optischen Transceivers. Diese Werte können im Datenblatt für die jeweilige Optik überprüft werden. Weitere Informationen finden Sie in der Dokumentation zu den optischen Transceivermodulen von Cisco.
Switch#show idprom interface Twe1/0/1
IDPROM for transceiver TwentyFiveGigE1/0/1 :
Description = SFP or SFP+ optics (type 3)
Transceiver Type: = GE CWDM 1550 (107)
Product Identifier (PID) = CWDM-SFP-1550 <--
Vendor Revision = A
Serial Number (SN) = SERIALNUMBER
Vendor Name = CISCO-FINISAR
Vendor OUI (IEEE company ID) = 00.90.65 (36965)
Common Language Equipment Identifier (CLEI) code = CNTRV14FAB
Cisco part number = 10-1879-03
Device State = Enabled.
Date code (yy/mm/dd) = 14/12/22
Connector type = LC.
Encoding = 8B10B (1)
Nominal bitrate = OTU-1 (2700 Mbits/s)
Minimum bit rate as % of nominal bit rate = not specified
Maximum bit rate as % of nominal bit rate = not specified
The transceiver type is 107
Link reach for 9u fiber (km) = LR-2(80km) (80)
LR-3(80km) (80)
ZX(80km) (80)
Link reach for 9u fiber (m) = IR-2(40km) (255)
LR-1(40km) (255)
LR-2(80km) (255)
LR-3(80km) (255)
DX(40KM) (255)
HX(40km) (255)
ZX(80km) (255)
VX(100km) (255)
Link reach for 50u fiber (m) = SR(2km) (0)
IR-1(15km) (0)
IR-2(40km) (0)
LR-1(40km) (0)
LR-2(80km) (0)
LR-3(80km) (0)
DX(40KM) (0)
HX(40km) (0)
ZX(80km) (0)
VX(100km) (0)
1xFC, 2xFC-SM(10km) (0)
ESCON-SM(20km) (0)
Link reach for 62.5u fiber (m) = SR(2km) (0)
IR-1(15km) (0)
IR-2(40km) (0)
LR-1(40km) (0)
LR-2(80km) (0)
LR-3(80km) (0)
DX(40KM) (0)
HX(40km) (0)
ZX(80km) (0)
VX(100km) (0)
1xFC, 2xFC-SM(10km) (0)
ESCON-SM(20km) (0)
Nominal laser wavelength = 1550 nm.
DWDM wavelength fraction = 1550.0 nm.
Supported options = Tx disable
Tx fault signal
Loss of signal (standard implementation)
Supported enhanced options = Alarms for monitored parameters
Diagnostic monitoring = Digital diagnostics supported
Diagnostics are externally calibrated
Rx power measured is "Average power"
Transceiver temperature operating range = -5 C to 75 C (commercial)
Minimum operating temperature = 0 C
Maximum operating temperature = 70 C
High temperature alarm threshold = +90.000 C
High temperature warning threshold = +85.000 C
Low temperature warning threshold = +0.000 C
Low temperature alarm threshold = -4.000 C
High voltage alarm threshold = 3600.0 mVolts
High voltage warning threshold = 3500.0 mVolts
Low voltage warning threshold = 3100.0 mVolts
Low voltage alarm threshold = 3000.0 mVolts
High laser bias current alarm threshold = 84.000 mAmps
High laser bias current warning threshold = 70.000 mAmps
Low laser bias current warning threshold = 4.000 mAmps
Low laser bias current alarm threshold = 2.000 mAmps
High transmit power alarm threshold = 7.4 dBm
High transmit power warning threshold = 4.0 dBm
Low transmit power warning threshold = -1.7 dBm
Low transmit power alarm threshold = -8.2 dBm
High receive power alarm threshold = -3.0 dBm
Low receive power alarm threshold = -33.0 dBm
High receive power warning threshold = -7.0 dBm
Low receive power warning threshold = -28.2 dBm
External Calibration: bias current slope = 1.000
External Calibration: bias current offset = 0
In dieser Tabelle sind die Befehle aufgelistet, die zur Fehlerbehebung bei Verbindungs-Flaps verwendet werden können. Empfohlene Verwendungsreihenfolge: show logging, show interfaces, show controllers Ethernet-controller, show platform pm interface-flaps und ggf. weitere faser- oder kupferspezifische Befehle.
| Command |
Zweck |
| Schnittstellenindikatorfehler anzeigen |
Zeigt die Zähler für Schnittstellenfehler an. |
| Anzeigen von Schnittstellenfunktionen |
Zeigt die Funktionen der jeweiligen Schnittstelle an. |
| Show Interface Transceiver (glasfaser- oder SFP-spezifisch) |
Zeigt Informationen zu den optischen Transceivern an, auf denen Digital Optical Monitoring (DOM) aktiviert ist. |
| Schnittstellenverbindung anzeigen |
Zeigt Informationen auf Verknüpfungsebene an. |
| show interface {interface{interface-number}}-Plattform |
Zeigt Informationen zur Schnittstellenplattform an. |
| show controllers Ethernet-controller {interface{interface-number}} port-info |
Zeigt zusätzliche Anschlussinformationen an. |
| Zeigt Controller-Ethernet-Controller {interface{interface-number}} Verbindungsstatusdetails an. |
Zeigt den Linkstatus an. |
| Fehlerhafte Klappenwerte anzeigen |
Zeigt die Anzahl der Flaps an, die vor dem errdisable-Status auftreten dürfen. |
| clear counters |
Verwenden Sie diesen Befehl, um die Zähler für Datenverkehr und Fehler auf Null zu setzen, damit Sie sehen können, ob das Problem nur ein vorübergehendes Problem ist oder ob die Zähler weiter inkrementiert werden. |
| Clear Controller Ethernet-Controller |
Mit diesem Befehl können Sie die Hardware-Zähler für Senden und Empfangen löschen. |
Überprüfen des Kabelstatus mit Time Domain Reflector (TDR)
Mit dem Time Domain Reflectometer (TDR) können Sie feststellen, ob ein Kabel im Fehlerfall OFFEN oder KURZ ist. Mit TDR können Sie den Status der Kupferkabel für die Ports der Catalyst Switches der Serie 9000 überprüfen. TDR erkennt einen Kabelfehler mit einem Signal, das durch das Kabel gesendet wird, und liest das Signal, das zurückreflektiert wird. Das Signal kann aufgrund von Defekten im Kabel ganz oder teilweise zurückreflektiert werden
Verwenden Sie den Test cable-diagnostics tdr {interface{interface-number}}, um den TDR-Test zu starten, und verwenden Sie dann den Befehl show cable-diagnostics tdr {interfaceinterface-number}.
Das Beispiel zeigt ein TDR-Testergebnis für die Schnittstelle Tw2/0/10:
Switch#show cable-diagnostics tdr interface tw2/0/10
TDR test last run on: November 05 02:28:43
Interface Speed Local pair Pair length Remote pair Pair status
--------- ----- ---------- ------------------ ----------- --------------------
Tw2/0/10 1000M Pair A 1 +/- 5 meters Pair A Impedance Mismatch
Pair B 1 +/- 5 meters Pair B Impedance Mismatch
Pair C 1 +/- 5 meters Pair C Open
Pair D 3 +/- 5 meters Pair D Open
TDR-Richtlinien
Diese Richtlinien gelten für den Einsatz von TDR:
- Ändern Sie die Portkonfiguration nicht, während der TDR-Test ausgeführt wird.
- Wenn Sie einen Port während eines TDR-Tests mit einem aktivierten Auto-MDIX-Port verbinden, kann das TDR-Ergebnis ungültig sein.
- Wenn Sie einen Port während eines TDR-Tests mit einem 100BASE-T-Port wie dem am Gerät verbinden, werden die nicht verwendeten Paare (4-5 und 7-8) als fehlerhaft gemeldet, da das Remote-Ende diese Paare nicht terminiert.
- Aufgrund der Eigenschaften der Kabel müssen Sie den TDR-Test mehrmals durchführen, um genaue Ergebnisse zu erhalten.
- Ändern Sie den Portstatus nicht (entfernen Sie z. B. das Kabel am nahen oder fernen Ende), da die Ergebnisse falsch sein können.
- TDR funktioniert am besten, wenn das Testkabel vom Remote-Port getrennt wird. Andernfalls kann es für Sie schwierig sein, die Ergebnisse richtig zu interpretieren.
- TDR arbeitet über vier Leitungen. Je nach Kabelbedingungen kann der Status anzeigen, dass ein Paar OFFEN oder KURZ ist, während alle anderen Drahtpaare als fehlerhaft angezeigt werden. Dieser Vorgang ist akzeptabel, da Sie ein Kabel als fehlerhaft deklarieren können, vorausgesetzt, ein Drahtpaar ist entweder OFFEN oder KURZ.
- Ziel des TDR ist es, die Funktionsfähigkeit eines Kabels zu ermitteln, anstatt ein fehlerhaftes Kabel zu lokalisieren.
- Wenn TDR ein fehlerhaftes Kabel ermittelt, können Sie das Problem dennoch mithilfe eines Offline-Kabeldiagnosetools besser diagnostizieren.
- Die TDR-Ergebnisse können bei verschiedenen Switch-Modellen der Catalyst Switches der Serie 9300 aufgrund der unterschiedlichen Auflösung bei TDR-Implementierungen unterschiedlich ausfallen. In diesem Fall müssen Sie sich an ein Tool zur Offline-Kabeldiagnose wenden.
Digital Optic Monitoring (DOM)
Digital Optical Monitoring (DOM) ist ein branchenweiter Standard, der eine digitale Schnittstelle für den Zugriff auf Echtzeitparameter wie die folgenden definiert:
- Temperatur
- Versorgungsspannung des Transceivers
- Laser-Biasstrom
- Optische Sendeleistung
- Optische Rx-Leistung
DOM aktivieren
In der Tabelle sind die Befehle aufgeführt, die Sie zum Ein-/Ausschalten von DOM für alle Transceiver im System verwenden können:
| Schritte |
Befehl oder Aktion |
Zweck |
| Schritt 1 |
enable Beispiel: Switch > Aktivieren |
Aktiviert den physischen EXEC-Modus. Geben Sie Ihr Kennwort ein, wenn Sie dazu aufgefordert werden. |
| Schritt 2 |
configure terminal Beispiel: switch#configure-Terminal |
Wechselt in den globalen Konfigurationsmodus. |
| Schritt 3 |
Transceiver-Typ all Beispiel: switch(config)#transceiver Alles eingeben |
Wechselt in den Konfigurationsmodus für den Transceiver-Typ. |
| Schritt 4 |
überwachung Beispiel: switch(config)#monitoring |
Ermöglicht die Überwachung aller optischen Transceiver. |
Verwenden Sie den Befehl show interfaces {interface{interface-number}} transceiver detail, um Transceiver-Informationen anzuzeigen:
Switch#show interfaces hundredGigE 1/0/25 transceiver detail
ITU Channel not available (Wavelength not available),
Transceiver is internally calibrated.
mA: milliamperes, dBm: decibels (milliwatts), NA or N/A: not applicable.
++ : high alarm, + : high warning, - : low warning, -- : low alarm.
A2D readouts (if they differ), are reported in parentheses.
The threshold values are calibrated.
High Alarm High Warn Low Warn Low Alarm
Temperature Threshold Threshold Threshold Threshold
Port (Celsius) (Celsius) (Celsius) (Celsius) (Celsius)
--------- ----------------- ---------- --------- --------- ---------
Hu1/0/25 28.8 75.0 70.0 0.0 -5.0
High Alarm High Warn Low Warn Low Alarm
Voltage Threshold Threshold Threshold Threshold
Port (Volts) (Volts) (Volts) (Volts) (Volts)
--------- ----------------- ---------- --------- --------- ---------
Hu1/0/25 3.28 3.63 3.46 3.13 2.97
High Alarm High Warn Low Warn Low Alarm
Current Threshold Threshold Threshold Threshold
Port Lane (milliamperes) (mA) (mA) (mA) (mA)
--------- ---- --------------- ---------- --------- --------- ---------
Hu1/0/25 N/A 6.2 10.0 8.5 3.0 2.6
Optical High Alarm High Warn Low Warn Low Alarm
Transmit Power Threshold Threshold Threshold Threshold
Port Lane (dBm) (dBm) (dBm) (dBm) (dBm)
--------- ---- --------------- ---------- --------- --------- ---------
Hu1/0/25 N/A -2.2 1.7 -1.3 -7.3 -11.3
Optical High Alarm High Warn Low Warn Low Alarm
Receive Power Threshold Threshold Threshold Threshold
Port Lane (dBm) (dBm) (dBm) (dBm) (dBm)
--------- ---- --------------- ---------- --------- --------- ---------
Hu1/0/25 N/A -16.7 2.0 -1.0 -9.9 -13.9
Syslog-Meldungen für die digitale optische Überwachung
In diesem Abschnitt werden die relevantesten Syslog-Meldungen zu Schwellenwertverletzungen beschrieben:
Temperaturniveaus der optischen SFP-Verbindungen
- Erläuterung: Diese Protokollmeldungen werden generiert, wenn die Temperatur niedrig ist oder die normalen Betriebswerte der optischen Verbindung überschreitet:
%SFF8472-3-THRESHOLD_VIOLATION: Te7/3: Temperature high alarm; Operating value: 88.7 C, Threshold value: 74.0 C.
%SFF8472-3-THRESHOLD_VIOLATION: Fo1/1/1: Temperature low alarm; Operating value: 0.0 C, Threshold value: 35.0 C.
Spannungsniveaus der optischen SFP-Verbindungen
- Erläuterung: Diese Protokollmeldungen werden generiert, wenn die Spannung niedrig ist oder die normalen Betriebswerte der optischen Verbindung überschreitet:
%SFF8472-3-THRESHOLD_VIOLATION: Gi1/1/3: Voltage high warning; Operating value: 3.50 V, Threshold value: 3.50 V.
%SFF8472-5-THRESHOLD_VIOLATION: Gi1/1: Voltage low alarm; Operating value: 2.70 V, Threshold value: 2.97 V.
Lichtpegel der optischen SFP-Verbindungen
- Erläuterung: Diese Protokollmeldungen werden generiert, wenn die Lichtleistung niedrig ist oder die Betriebswerte der Optik überschreitet:
%SFF8472-3-THRESHOLD_VIOLATION: Gi1/0/1: Rx power high warning; Operating value: -2.7 dBm, Threshold value: -3.0 dBm.
%SFF8472-5-THRESHOLD_VIOLATION: Te1/1: Rx power low warning; Operating value: -13.8 dBm, Threshold value: -9.9 dBm.
Cisco Optics und Forward Error Correction (FEC)
FEC ist eine Technik, mit der eine bestimmte Anzahl von Fehlern in einem Bitstrom erkannt und korrigiert wird. Vor der Übertragung werden redundante Bits und ein Fehlerprüfungscode an den Nachrichtenblock angehängt. Als Modulhersteller achtet Cisco darauf, unsere Transceiver so zu gestalten, dass sie den Spezifikationen entsprechen. Wenn der optische Transceiver in einer Cisco Host-Plattform betrieben wird, wird die FEC standardmäßig aktiviert, basierend auf dem von der Host-Software erkannten optischen Modultyp (siehe diese herunterladbare Tabelle). In den allermeisten Fällen wird die FEC-Implementierung durch den Branchenstandard diktiert, den der optische Typ unterstützt.
Die FEC-Implementierungen unterscheiden sich in Bezug auf bestimmte benutzerdefinierte Spezifikationen. Weitere Informationen finden Sie im Dokument Understanding FEC and its Implementation in Cisco Optics.
Das Beispiel zeigt, wie FEC konfiguriert wird und einige der verfügbaren Optionen:
switch(config-if)#fec? auto Enable FEC Auto-Neg cl108 Enable clause108 with 25G cl74 Enable clause74 with 25G off Turn FEC off
Use the show interface command to verify FEC configuration:
TwentyFiveGigE1/0/13 is up, line protocol is up (connected)
Hardware is Twenty Five Gigabit Ethernet, address is 3473.2d93.bc8d (bia 3473.2d93.bc8d)
MTU 9170 bytes, BW 25000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 25Gb/s, link type is force-up, media type is SFP-25GBase-SR
Fec is auto < -- The configured setting for FEC is displayed here
input flow-control is on, output flow-control is off
ARP type: ARPA, ARP Timeout 04:00:00
--snip--
Debug-Befehle
In dieser Tabelle sind die verschiedenen Befehle aufgeführt, die zum Debuggen von Port-Flaps verwendet werden können.
| Command | Zweck |
| debug pm | Port Manager-Debugging |
| debug pm-Port | Port-bezogene Ereignisse |
| Debug-Plattform pm | NGWC-Plattform - Port-Manager - Debuginformationen |
| debug plattform pm l2-control | NGWC L2 Control Infra-Debugging |
| debug plattform pm link-status | Erkennung von Schnittstellen |
| debug plattform pm-vektoren | Port-Manager-Vektorfunktionen |
| debug condition interface <Schnittstellenname> | Aktivieren Sie Debug-Funktionen für bestimmte Schnittstellen |
| Debug-Schnittstellenstatus | Zustandsübergänge |
Dies ist ein Beispiel für eine teilweise Ausgabe der in der Tabelle aufgeführten debug-Befehle:
SW_2#sh debugging
PM (platform):
L2 Control Infra debugging is on <-- debug platform pm l2-control
PM Link Status debugging is on <-- debug platform pm link-status
PM Vectors debugging is on <-- debug platform pm pm-vectors
Packet Infra debugs:
Ip Address Port
------------------------------------------------------|----------
Port Manager:
Port events debugging is on <-- debug pm port
Condition 1: interface Te1/0/2 (1 flags triggered)
Flags: Te1/0/2
------ Sample output ---------
*Aug 25 20:01:05.791: link up/down event : link-down on Te1/0/2
*Aug 25 20:01:05.791: pm_port 1/2: during state access, got event 5(link_down) <-- Link down event (day/time)
*Aug 25 20:01:05.791: @@@ pm_port 1/2: access -> pagp
*Aug 25 20:01:05.792: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:05.792: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:05.792: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:05.792: IOS-FMAN-PM-DEBUG-PM-VECTORS: Vp Disable: pd=0x7F1E797914B0 dpidx=10 Te1/0/2
*Aug 25 20:01:05.792: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:05.792: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:05.792: Maintains count of VP per Interface:delete, pm_vp_counter[0]: 14, pm_vp_counter[1]: 14
*Aug 25 20:01:05.792: *** port_modechange: 1/2 mode_none(10)
*Aug 25 20:01:05.792: @@@ pm_port 1/2: pagp -> dtp
*Aug 25 20:01:05.792: stop flap timer : Te1/0/2 pagp
*Aug 25 20:01:05.792: *** port_bndl_stop: 1/2 : inform yes
*Aug 25 20:01:05.792: @@@ pm_port 1/2: dtp -> present
*Aug 25 20:01:05.792: *** port_dtp_stop: 1/2
*Aug 25 20:01:05.792: stop flap timer : Te1/0/2 pagp
*Aug 25 20:01:05.792: stop flap timer : Te1/0/2 dtp
*Aug 25 20:01:05.792: stop flap timer : Te1/0/2 unknown
*Aug 25 20:01:05.792: *** port_linkchange: reason_link_change(3): link_down(0)1/2 <-- State link change
*Aug 25 20:01:05.792: pm_port 1/2: idle during state present
*Aug 25 20:01:05.792: @@@ pm_port 1/2: present -> link_down <-- State of the link
*Aug 25 20:01:06.791: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/0/2, changed state to down
*Aug 25 20:01:07.792: %LINK-3-UPDOWN: Interface TenGigabitEthernet1/0/2, changed state to down
*Aug 25 20:01:11.098: IOS-FMAN-PM-DEBUG-LINK-STATUS: Received LINKCHANGE in xcvr message, if_id 10 (TenGigabitEthernet1/0/2)
*Aug 25 20:01:11.098: IOS-FMAN-PM-DEBUG-LINK-STATUS: if_id 0xA, if_name Te1/0/2, link up <-- Link became up
*Aug 25 20:01:11.098: link up/down event: link-up on Te1/0/2
*Aug 25 20:01:11.098: pm_port 1/2: during state link_down, got event 4(link_up)
*Aug 25 20:01:11.098: @@@ pm_port 1/2: link_down -> link_up
*Aug 25 20:01:11.098: flap count for link type : Te1/0/2 Linkcnt = 0
*Aug 25 20:01:11.099: pm_port 1/2: idle during state link_up
*Aug 25 20:01:11.099: @@@ pm_port 1/2: link_up -> link_authentication
*Aug 25 20:01:11.099: pm_port 1/2: during state link_authentication, got event 8(authen_disable)
*Aug 25 20:01:11.099: @@@ pm_port 1/2: link_authentication -> link_ready
*Aug 25 20:01:11.099: *** port_linkchange: reason_link_change(3): link_up(1)1/2
*Aug 25 20:01:11.099: pm_port 1/2: idle during state link_ready
*Aug 25 20:01:11.099: @@@ pm_port 1/2: link_ready -> dtp
*Aug 25 20:01:11.099: IOS-FMAN-PM-DEBUG-PM-VECTORS: Set pm vp mode attributes for Te1/0/2 vlan 1
*Aug 25 20:01:11.099: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.099: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.099: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.099: pm_port 1/2: during state dtp, got event 13(dtp_complete)
*Aug 25 20:01:11.099: @@@ pm_port 1/2: dtp -> dtp
*Aug 25 20:01:11.099: IOS-FMAN-PM-DEBUG-PM-VECTORS: Set pm vp mode attributes for Te1/0/2 vlan 1
*Aug 25 20:01:11.099: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.099: DTP flapping: flap count for dtp type: Te1/0/2 Dtpcnt = 0
*Aug 25 20:01:11.099: pm_port 1/2: during state dtp, got event 110(dtp_done)
*Aug 25 20:01:11.099: @@@ pm_port 1/2: dtp -> pre_pagp_may_suspend
*Aug 25 20:01:11.099: pm_port 1/2: idle during state pre_pagp_may_suspend
*Aug 25 20:01:11.099: @@@ pm_port 1/2: pre_pagp_may_suspend -> pagp_may_suspend
*Aug 25 20:01:11.099: pm_port 1/2: during state pagp_may_suspend, got event 33(pagp_continue)
*Aug 25 20:01:11.099: @@@ pm_port 1/2: pagp_may_suspend -> start_pagp
*Aug 25 20:01:11.099: pm_port 1/2: idle during state start_pagp
*Aug 25 20:01:11.099: @@@ pm_port 1/2: start_pagp -> pagp
*Aug 25 20:01:11.100: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.100: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.100: IOS-FMAN-PM-DEBUG-PM-VECTORS: Set pm vp mode attributes for Te1/0/2 vlan 1
*Aug 25 20:01:11.100: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.100: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.100: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.100: *** port_bndl_start: 1/2
*Aug 25 20:01:11.100: stop flap timer : Te1/0/2 pagp
*Aug 25 20:01:11.100: pm_port 1/2: during state pagp, got event 34(dont_bundle)
*Aug 25 20:01:11.100: @@@ pm_port 1/2: pagp -> pre_post_pagp
*Aug 25 20:01:11.100: pm_port 1/2: idle during state pre_post_pagp
*Aug 25 20:01:11.100: @@@ pm_port 1/2: pre_post_pagp -> post_pagp
*Aug 25 20:01:11.100: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.100: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.100: pm_port 1/2: during state post_pagp, got event 14(dtp_access)
*Aug 25 20:01:11.100: @@@ pm_port 1/2: post_pagp -> access
*Aug 25 20:01:11.100: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.100: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.100: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.100: IOS-FMAN-PM-DEBUG-PM-VECTORS: Set pm vp mode attributes for Te1/0/2 vlan 1
*Aug 25 20:01:11.100: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.100: Maintains count of VP per Interface:add, pm_vp_counter[0]: 15, pm_vp_counter[1]: 15
*Aug 25 20:01:11.100: IOS-FMAN-PM-DEBUG-PM-VECTORS: vlan vp enable for port(Te1/0/2) and vlan:1
*Aug 25 20:01:11.101: IOS-FMAN-PM-DEBUG-PM-VECTORS: VP ENABLE: vp_pvlan_port_mode:access for Te1/0/2
*Aug 25 20:01:11.101: IOS-FMAN-PM-DEBUG-PM-VECTORS: VP Enable: vp_pvlan_native_vlanId:1 for Te1/0/2
*Aug 25 20:01:11.101: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.101: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.101: *** port_modechange: 1/2 mode_access(1)
*Aug 25 20:01:11.101: IOS-FMAN-PM-DEBUG-PM-VECTORS: The operational mode of Te1/0/2 in set all vlans is 1
*Aug 25 20:01:11.101: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:11.101: IOS-FMAN-PM-DEBUG-PM-VECTORS: vp_pvlan port_mode:access vlan:1 for Te1/0/2
*Aug 25 20:01:11.101: IOS-FMAN-PM-DEBUG-PM-VECTORS: vp_pvlan port_mode:access native_vlan:1 for Te1/0/2
*Aug 25 20:01:11.102: IOS-FMAN-PM-DEBUG-PM-VECTORS: Success sending PM tdl message
*Aug 25 20:01:13.098: %LINK-3-UPDOWN: Interface TenGigabitEthernet1/0/2, changed state to up
*Aug 25 20:01:14.098: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/0/2, changed state to up
Zugehörige Cisco Bugs
| Cisco Bug-ID |
Beschreibung |
| Cisco Bug-ID CSCvu13029 |
Intermittierende Link-Flaps auf mGig Cat9300-Switches auf mGig-fähige Endgeräte. |
| Cisco Bug-ID CSCvt50788 |
Probleme mit der Cat9400-mGig-Interoperabilität mit anderen mGig-Geräten führen zu Verbindungs-Flaps. |
| Cisco Bug-ID CSCvu92432 |
CAT9400: Interface-Flaps mit Mgig-APs verbinden. |
| Cisco Bug-ID CSCve65787 |
Autoneg-Unterstützung für 100 G/40 G/25 G Cu xcvr. |
Zugehörige Informationen
- Kompatibilitätsmatrix für optische Verbindungen zu Geräten von Cisco
- Cisco SFP-Module für Gigabit Ethernet-Anwendungen - Datenblatt
- Whitepaper: 25GE und 100GE - Mehr Geschwindigkeit für Unternehmen mit Investitionsschutz
- Datenblatt zur Cisco CWDM SFP-Lösung
- Förderung von Innovation: Transformation der Dokumentation und Vereinfachung des Self-Service mit Cisco TAC
- Technischer Support und Downloads von Cisco
Revisionsverlauf
| Überarbeitung | Veröffentlichungsdatum | Kommentare |
|---|---|---|
3.0 |
09-Sep-2026
|
Rezertifizierung - Aktualisierte Ausgabe, SEO, maschinelle Übersetzung, Stilanforderungen und Formatierung. |
2.0 |
13-Mar-2024
|
Rezertifizierung |
1.0 |
04-Nov-2022
|
Erstveröffentlichung |
FeedbackCisco kontaktieren
- Eine Supportanfrage öffnen
- (Erfordert einen Cisco Servicevertrag)