Inhalt

Einleitung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Hintergrundinformationen

Fehlerbehebung

Installation der Netzwerkmodule

Prüfen Sie das Kabel und beide Seiten der Verbindung.

Überprüfung der SFP- und SFP+-Kompatibilität

Identifizieren von Port-Flaps

Schnittstelle Befehle anzeigen

Überprüfen des Kabelstatus mit Time Domain Reflector (TDR)

TDR-Richtlinien

Digital Optic Monitoring (DOM)

DOM aktivieren

Syslog-Meldungen für die digitale optische Überwachung

Cisco Optics und Forward Error Correction (FEC)

Debug-Befehle

Zugehörige Informationen

Einleitung

In diesem Dokument wird beschrieben, wie Sie nützliche Protokolle identifizieren und sammeln und Probleme beheben, die bei Port-Flaps auf Catalyst Switches der Serie 9000 auftreten können.

Mit Beiträgen von Leonardo Pena Davila

Voraussetzungen

Anforderungen

Es gibt keine spezifischen Anforderungen für dieses Dokument.

Verwendete Komponenten

Die Informationen in diesem Dokument basieren auf allen 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 verstehen.

Hintergrundinformationen

Eine Port-Klappe (auch als Link-Klappe bezeichnet) ist eine Situation, in der eine physische Schnittstelle am Switch kontinuierlich an- und abgeschaltet wird. Die häufigste Ursache ist in der Regel ein defektes, nicht unterstütztes oder nicht standardmäßiges Kabel oder SFP (Small Form-Factor Pluggable) oder andere Probleme bei der Synchronisierung von Links. Die Ursache für die Verbindungsklappen kann intermittierend oder permanent sein.

Da Link-Flaps tendenziell eine physische Interferenz darstellen, werden in diesem Dokument die Schritte zur Diagnose, Erfassung nützlicher Protokolle und zur Fehlerbehebung erläutert, die bei Port-Flaps auf Catalyst 9000-Switches auftreten können.

Fehlerbehebung

Sie können eine Reihe von Optionen überprüfen, um sicherzustellen, dass die Netzwerkmodule, Kabel und SFP ordnungsgemäß installiert sind, wenn Sie physischen Zugriff auf den Switch haben:

Installation der Netzwerkmodule

Die Tabelle beschreibt die Best Practices für die Installation eines Netzwerkmoduls in einem Catalyst Switch der Serie 9000:

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

Catalyst Switches der Serie 9600 - Hardware-Installationshandbuch

Prüfen Sie das Kabel und beide Seiten der Verbindung.

Diese Tabellen beschreiben einige der möglichen Kabelprobleme, die zu Verbindungsklappen führen können.

Ursache

Wiederherstellungsaktion

Fehlerhaftes Kabel

Ersetzen Sie das verdächtige Kabel durch ein funktionsfähiges Kabel. Suchen Sie nach abgebrochenen oder verlorenen Pins an Anschlüssen.

Lose Verbindungen

Suchen Sie nach losen Verbindungen. Manchmal scheint ein Kabel richtig zu sitzen, ist es aber nicht. Ziehen Sie das Kabel ab und stecken Sie es wieder ein

Patchpanel

Vermeiden Sie fehlerhafte Patchpanel-Verbindungen. Umgehen Sie das Patchpanel, wenn möglich, um es auszuschließen

Schlechter oder falscher SFP (glasfaserspezifisch)

Tauschen Sie einen verdächtigen SFP durch einen zweifelsfrei funktionierenden SFP aus. Überprüfen Sie den Hardware- und Software-Support für diesen SFP-Typ.

Fehlerhafter Port oder Modulport

Schließen Sie das Kabel an einen bekanntermaßen funktionsfähigen Port an, um Fehler an einem verdächtigen Port oder Modul zu beheben

Ungültiges oder altes Endgerät

Tauschen Sie das Telefon, den Lautsprecher oder ein anderes Endgerät durch ein zweifelsfrei funktionierendes Gerät oder ein neueres Gerät aus.

Geräte-Energiesparmodus

Dies ist eine "erwartete Klappe". Achten Sie auf den Zeitstempel der Port-Klappe, um festzustellen, ob sie schnell oder zeitweilig erfolgt und ob eine Ruheeinstellung die Ursache ist.

Überprüfung der SFP- und SFP+-Kompatibilität

Das Cisco Portfolio an Hot Plug-fähigen Schnittstellen bietet eine große Auswahl an Übertragungsgeschwindigkeiten, Protokollen, erreichbaren und unterstützten Übertragungsmedien.

Sie können eine beliebige Kombination von SFP- oder SFP+-Transceivermodulen verwenden, die von Ihrem Catalyst Switch der Serie 9000 unterstützt wird. Die einzigen Einschränkungen bestehen darin, dass jeder Port den Wellenlängenspezifikationen am anderen Ende des Kabels entsprechen muss und dass das Kabel die festgelegte Kabellänge für eine zuverlässige Kommunikation nicht überschreiten darf.

Verwenden Sie auf Ihrem Cisco Gerät nur Cisco SFP-Transceiver-Module. Jedes SFP- oder SFP+-Transceiver-Modul unterstützt die Cisco Quality Identification (ID)-Funktion, mit der ein Cisco Switch oder Router feststellen und validieren kann, ob das Transceiver-Modul von Cisco zertifiziert und getestet wurde.

Tipp: Überprüfen Sie mithilfe dieses Links die Kompatibilitätsmatrix für optische Verbindungen von Cisco mit Geräten

Identifizieren von Port-Flaps

Verwenden Sieshow loggingum ein Link-Flap-Ereignis zu identifizieren. Dieses Beispiel zeigt eine teilweise Protokollmeldung des Switch-Systems für ein Link-Flap-Ereignis mit der Schnittstelle TenGigabitEthernet1/0/40:

Switch#show logging | include changed

Aug 17 21:06:08.431 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/0/40, changed state to down

Aug 17 21:06:39.058 UTC: %LINK-3-UPDOWN: Interface TenGigabitEthernet1/0/40, changed state to down

Aug 17 21:06:41.968 UTC: %LINK-3-UPDOWN: Interface TenGigabitEthernet1/0/40, changed state to up

Aug 17 21:06:42.969 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/0/40, changed state to up

Aug 17 21:07:20.041 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/0/40, changed state to down

Aug 17 21:07:21.041 UTC: %LINK-3-UPDOWN: Interface TenGigabitEthernet1/0/40, changed state to down

Aug 17 21:07:36.534 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/0/40, changed state to up

Aug 17 21:08:06.598 UTC: %LINK-3-UPDOWN: Interface TenGigabitEthernet1/0/40, changed state to up

Aug 17 21:08:07.628 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/0/40, changed state to down

Aug 17 21:08:08.628 UTC: %LINK-3-UPDOWN: Interface TenGigabitEthernet1/0/40, changed state to down

Aug 17 21:08:10.943 UTC: %LINK-3-UPDOWN: Interface TenGigabitEthernet1/0/40, changed state to up

Aug 17 21:08:11.944 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/0/40, changed state to up

Tipp: Wenn Sie die System-Nachrichtenprotokolle analysieren, müssen Sie den Zeitstempel der Port-Klappe beachten, da Sie so gleichzeitige Ereignisse an diesem bestimmten Port vergleichen und überprüfen können, ob die Link-Klappe auftritt (z. B.: Ruhezustand oder andere "normale" Ursachen sind nicht unbedingt ein Problem).

Schnittstelle Befehle anzeigen

Der Befehl show interface bietet Ihnen zahlreiche Informationen, mit denen Sie ein mögliches Layer-1-Problem identifizieren können, 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 dieser Tabelle sind einige der Leistungsindikatoren des Befehls show interface aufgeführt:

Zähler

Probleme und häufige Ursachen, die die Fehlerzähler erhöhen

CRC

Eine hohe Anzahl von CRCs ist in der Regel das Ergebnis von Kollisionen, kann aber auch auf ein physisches Problem (z. B. Verkabelung, SFP, fehlerhafte Schnittstelle oder NIC) oder eine Duplexunstimmigkeit hinweisen.

Input errors

In diese Kategorie gehören Runts, Giants, No Buffer, CRC, Frame, Overrun sowie Ignored. Andere Eingabefehler können auch dazu führen, dass die Anzahl der Eingabefehler erhöht wird.

output errors

Dieses Problem ist auf die geringe Größe der Ausgabewarteschlange oder auf Überbelegung zurückzuführen.

Gesamtleistung sinkt

Ausgabelücken sind in der Regel das Ergebnis einer Überbelegung der Schnittstelle, die durch Übertragungen von n zu 1 oder von 10 Gbit/s zu 1 Gbit/s verursacht wird. Schnittstellenpuffer stellen eine begrenzte Ressource dar und können nur Spitzen bis zu einem Punkt absorbieren, nach dem Pakete verworfen werden. Puffer können so eingestellt werden, dass ein gewisser Puffer entsteht. Sie können jedoch kein Szenario garantieren, bei dem die Ausgabe auf Null zurückgeht.

Unbekanntes Protokoll wird gelöscht

Unbekannte Protokoll-Drops werden normalerweise verworfen, da die Schnittstelle, an der diese Pakete empfangen werden, nicht für diesen Protokolltyp konfiguriert ist. Es kann sich auch um ein beliebiges Protokoll handeln, das der Switch nicht erkennt. Wenn beispielsweise zwei Switches angeschlossen sind und Sie CDP an einer Switch-Schnittstelle deaktivieren, führt dies zu unbekannten Protokollverlusten an dieser Schnittstelle. Die CDP-Pakete werden nicht mehr erkannt und verworfen.

Mit dem Befehl history kann eine Schnittstelle den Nutzungsverlauf in einem grafischen Format ähnlich dem CPU-Verlauf verwalten. Dieser Verlauf kann entweder als Bit pro Sekunde (Bit pro Sekunde) oder als Pakete pro Sekunde (Pakete pro Sekunde (pps)) beibehalten 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 kann der Benutzer verschiedene Schnittstellenzähler überwachen:

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 gibt es auch hier Diagramme für die letzten 60 Sekunden, 60 Minuten und 72 Stunden. Für Eingabe- und Ausgabehistogramme werden separate Diagramme beibehalten:

Switch#sh 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

------ 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 Ethernet-Controller anzeigen.{interface{interface-number}}  um Schnittstellenspezifische (Senden und Empfangen) Zähler für Datenverkehr und Fehlerzähler anzuzeigen, die von der Hardware gelesen werden. Verwenden Sie das phy-Schlüsselwort, um die internen Schnittstellenregister anzuzeigen, oder das port-info-Schlüsselwort, um Informationen über den Port-ASIC 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

Tipp: Sie können auch den Controller-Befehl show interfaces {interface{interface-number} verwenden, um die von der Hardware gelesenen Transmit- und Receive-Statistiken pro Schnittstelle anzuzeigen.

Verwenden Sie die show platform pm interface-flaps{interface{interface-number}}  um anzuzeigen, wie oft eine Schnittstelle ausgefallen ist:

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 show idprom{interface{interface-number}}  ohne Schlüsselwörter, um die IDPROM-Informationen für die spezifische Schnittstelle anzuzeigen. Mit dem detail-Schlüsselwort können Sie detaillierte hexadezimale IDPROM-Informationen anzeigen.

Dies ist ein Beispiel für die Ausgabe von show idprom{interface{interface-number}} für eine bestimmte Schnittstelle. Die in diesem Befehl angegebenen Schwellenwerte für hohe und niedrige Warnung|Alarm sind die normalen Parameter des optischen Transceivers. Diese Werte können aus dem Datenblatt für die jeweilige Optik überprüft werden. Weitere Informationen finden Sie im Datenblatt zu optischen Verbindungen 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)                        = XXXXXXXXXX   <-- Cisco Serial Number

Vendor Name                               = CISCO-FINISAR

Vendor OUI (IEEE company ID)              = 00.90.65 (36965)

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

Tipp: Stellen Sie sicher, dass die Hardware- und Softwareversion des Geräts mit der Cisco SFP/SFP+-Kompatibilitätsmatrix für die optische Datenübertragung (Optics-to-Device) kompatibel ist.

In dieser Tabelle sind die verschiedenen Befehle aufgeführt, die zur Fehlerbehebung von Link-Flaps verwendet werden können:

Command

Zweck

Schnittstellenindikatorfehler anzeigen

Zeigt die Schnittstellenfehlerindikatoren an.

Anzeigen von Schnittstellenfunktionen

Zeigt die Funktionen der jeweiligen Schnittstelle an.

Show Interface Transceiver (glasfaser-/SFP-spezifisch)

Zeigt Informationen zu optischen Transceivern an, für die Digital Optical Monitoring (DOM) aktiviert ist.

Schnittstellenverbindung anzeigen

Zeigt Informationen zu Verknüpfungsebenen an

show interface {interface{interface-number}}-Plattform

Zeigt Schnittstellenplattforminformationen an

show controllers Ethernet-controller {interface{interface-number}} port-info

Zeigt zusätzliche Port-Informationen 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 GEÖFFNET oder KURZ ist, wenn ein Fehler auftritt. 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}.

Tipp: Weitere Informationen finden Sie unter Überprüfen des Portstatus und der Verbindungen.

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

Tipp: Bei Catalyst Switches der Serie 9300 werden nur die folgenden Kabelfehlertypen erkannt: OPEN, SHORT und IMPEDANCE MISMATCH. Der Status Normal wird angezeigt, wenn das Kabel ordnungsgemäß angeschlossen ist. Dies dient zur Veranschaulichung.

TDR-Richtlinien

Diese Richtlinien gelten für die Verwendung 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

aktivieren

Beispiel:

switch>enable

Aktiviert den physischen EXEC-Modus

Geben Sie auf Aufforderung Ihr Kennwort ein.

Schritt 2

Konfigurationsterminal

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

Tipp: Ob ein optischer Transceiver mit den entsprechenden Signalpegeln betrieben wird, entnehmen Sie bitte dem Datenblatt zu Cisco Optics.

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 übersteigt:

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

Tipp: Weitere Informationen zum DOM finden Sie unter Digital Optical Monitoring

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 Fehlerüberprüfungscode an den Nachrichtenblock angehängt. Als Modulhersteller achtet Cisco darauf, dass unsere Transceiver die technischen Spezifikationen erfüllen. Wenn der optische Transceiver in einer Cisco Host-Plattform betrieben wird, wird die FEC standardmäßig aktiviert. Dies hängt von dem optischen Modultyp ab, den die Host-Software erkennt (siehe diese herunterladbare Tabelle). In den allermeisten Fällen wird die FEC-Implementierung durch den Branchenstandard diktiert, den der optische Typ unterstützt.

Bei bestimmten benutzerdefinierten Spezifikationen unterscheiden sich die FEC-Implementierungen. Ausführliche 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--

Hinweis: Beide Seiten einer Verbindung müssen die gleiche FEC haben. encoding -Algorithmus aktiviert, damit die Verbindung aktiv wird.

Debug-Befehle

In dieser Tabelle sind die verschiedenen Befehle aufgeführt, die zum Debuggen von Port-Flaps verwendet werden können.

Vorsicht: Verwenden Sie die Debug-Befehle mit Vorsicht. Bitte beachten Sie, dass viele Debug-Befehle Auswirkungen auf das Live-Netzwerk haben und nur empfohlen werden, sie in einer Laborumgebung zu verwenden, wenn das Problem reproduziert wird.                                                        ;

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 Beispielausgabe des dbetteln Befehle in der Tabelle:

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

Innovation im Support: So optimiert das Cisco TAC die Dokumentation und vereinfacht den Self-Service

Technischer Support und Dokumentation für Cisco Systeme

Cisco Bug-ID

Beschreibung

Cisco Bug-ID CSCvu13029

Unterbrechungsfreie Link-Flaps von mGig Cat9300-Switches auf mGig-fähige Endgeräte

Cisco Bug-ID CSCvt50788

Cat9400-mGig-Interoperabilitätsprobleme mit anderen mGig-Geräten verursachen Verbindungs-Flaps

Cisco Bug-ID CSCvu92432

CAT9400: Schnittstellenflaps mit Zuordnungs-APs

Cisco Bug-ID CSCve65787

Autoneg-Unterstützung für 100 G/40 G/25 G Cu XCR