Table des matières

Introduction

Conditions préalables

Exigences

Composants utilisés

Informations générales

Dépannage

Installation des modules réseau

Vérification du câble et des deux côtés de la connexion

Vérification de la compatibilité SFP et SFP+

Identifier les volets des ports

Interface Commandes Show

Vérification de l’état du câble avec le réflecteur de domaine temporel (TDR)

Lignes directrices du RDT

Surveillance optique numérique (DOM)

Comment activer DOM

Messages Syslog de surveillance optique numérique

Optique Cisco et correction d'erreurs sans voie de retour (FEC)

Commandes de débogage

Informations connexes

Introduction

Ce document décrit comment identifier, collecter des journaux utiles et dépanner les problèmes qui peuvent se produire avec les Port Flaps sur les commutateurs Catalyst 9000.

Contribution de Leonardo Pena Davila

Conditions préalables

Exigences

There are no specific requirements for this document.

Composants utilisés

Les informations contenues dans ce document sont basées sur tous les commutateurs de la gamme Catalyst 9000.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Informations générales

Un port flap, généralement appelé « link flap », est une situation dans laquelle une interface physique du commutateur est continuellement active et inactive. La cause la plus fréquente est généralement liée à un câble défectueux, non pris en charge ou non standard, à un câble SFP (Small Form-Factor Pluggable) ou à d'autres problèmes de synchronisation de liaison. La cause des volets de liaison peut être intermittente ou permanente.

Puisque les battements de liens tendent à être une interférence physique, ce document explique les étapes pour diagnostiquer, collecter des journaux utiles et dépanner les problèmes qui peuvent se produire avec les battements de ports sur les commutateurs Catalyst 9000.

Dépannage

Vous pouvez vérifier plusieurs points. Si vous disposez d'un accès physique au commutateur pour vous assurer que les modules de réseau, les câbles et les modules SFP sont correctement installés :

Installation des modules réseau

Le tableau ci-dessous décrit les meilleures pratiques d'installation d'un module de réseau dans un commutateur de la gamme Catalyst 9000 :

Plateforme

URL

Commutateurs de la gamme Catalyst 9200

Guide d'installation matérielle des commutateurs Catalyst 9200

Commutateurs de la gamme Catalyst 9300

Guide d'installation matérielle des commutateurs Catalyst 9300

Commutateurs de la gamme Catalyst 9400

Guide d'installation matérielle des commutateurs Catalyst 9400

Commutateurs de la gamme Catalyst 9500

Guide d'installation matérielle des commutateurs Catalyst 9500

Commutateurs de la gamme Catalyst 9600

Guide d'installation matérielle des commutateurs Catalyst 9600

Vérification du câble et des deux côtés de la connexion

Ces tableaux décrivent certains des problèmes de câble susceptibles d’entraîner des défauts de liaison.

Motif

Action de récupération

Câble défectueux

Permutez le câble suspect avec un câble fiable connu. Recherchez les broches cassées ou perdues sur les connecteurs

Pertes de connexion

Vérifiez les pertes de connexion. Parfois, un câble semble être correctement positionné, mais ne l'est pas. Débranchez le câble et réinsérez-le

Panneaux de connexions

Supprimez les connexions défectueuses du panneau de connexions. Si possible, dérivez le panneau de connexions pour l'exclure

SFP incorrect ou incorrect (spécifique à la fibre)

Remplacez le module SFP suspect par un module SFP en bon état. Vérifier la prise en charge matérielle et logicielle de ce type de module SFP

Port ou port de module incorrect

Déplacez le câble vers un port fiable connu pour dépanner un port ou un module suspect

Périphérique de point de terminaison incorrect ou ancien

Remplacez le téléphone, le haut-parleur, un autre terminal par un périphérique en bon état ou un périphérique plus récent

Mode veille du périphérique

Il s'agit d'un « rabat attendu ». Vérifiez l'horodatage du rabat de port pour déterminer s'il se produit rapidement ou de façon intermittente et si un réglage de veille en est la cause

Vérification de la compatibilité SFP et SFP+

Le portefeuille Cisco des interfaces enfichables à chaud offre un riche éventail de produits en termes de vitesses, protocoles, portées et médias de transmission supportés.

Vous pouvez utiliser n'importe quelle combinaison de modules SFP ou SFP + émetteurs-récepteurs prise en charge par vos commutateurs de la gamme Catalyst 9000. Les seules restrictions sont que chaque port doit correspondre aux spécifications de longueur d'onde à l'autre extrémité du câble et que le câble ne doit pas dépasser la longueur de câble stipulée pour des communications fiables.

Utilisez uniquement des modules émetteurs-récepteurs SFP Cisco sur votre périphérique Cisco. Chaque module émetteur-récepteur SFP ou SFP+ prend en charge la fonctionnalité Cisco Quality Identification (ID) qui permet à un commutateur ou routeur Cisco d'identifier et de valider que le module émetteur-récepteur est certifié et testé par Cisco.

Conseil : reportez-vous à ce lien afin de vérifier la matrice de compatibilité Cisco Optics-to-Device

Identifier les volets des ports

Utilisezshow loggingpour identifier un événement de battement de lien. Cet exemple montre un message partiel du journal système du commutateur pour un événement de battement de liaison avec l'interface 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

Conseil : si vous analysez les journaux de messages système, vous devez faire attention à l'horodatage du port flap, car il vous permet de comparer des événements simultanés sur ce port spécifique et de valider si oui ou non la survenue du lien flap est attendue (Par exemple : le réglage de la veille ou autre cause « normale » pas nécessairement un problème).

Interface Commandes Show

La commande show interface vous donne beaucoup d'informations qui vous aident à identifier un problème possible de couche 1 qui provoque un événement d'instabilité de liaison :

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

Ce tableau répertorie certains des compteurs de la commande show interface :

Compteur

Problèmes et causes courantes qui augmentent les compteurs d'erreurs

CRC

Un nombre élevé de CRC est généralement le résultat de collisions, mais peut également indiquer un problème physique (câblage, SFP, interface incorrecte ou carte réseau) ou une non-correspondance de mode duplex.

Erreurs d'entrée

Cela inclut les valeurs des compteurs runts, giants, no buffer, CRC, frame, overrun et ignored. D'autres erreurs d'entrée peuvent également entraîner une augmentation du nombre d'erreurs d'entrée.

output errors

Ce problème est dû à la faible taille de la file d'attente de sortie ou en cas de surabonnement.

Total des pertes en sortie

Les pertes de sortie sont généralement le résultat d'une sursouscription d'interface causée par un transfert de plusieurs à un ou d'un transfert de 10 Gbits/s à 1 Gbits/s. Les tampons d'interface constituent une ressource limitée et ne peuvent absorber une rafale que jusqu'à un point après lequel les paquets commencent à être abandonnés. Les tampons peuvent être réglés pour donner un certain coussin, mais il ne peut pas garantir un scénario de chute de sortie nulle.

Abandons de protocole inconnus

Les abandons de protocoles inconnus sont normalement abandonnés parce que l'interface où ces paquets sont reçus n'est pas configurée pour ce type de protocole, ou il peut s'agir de tout protocole que le commutateur ne reconnaît pas. Par exemple, si deux commutateurs sont connectés et que vous désactivez le protocole CDP sur une interface de commutateur, cela entraîne des abandons de protocole inconnus sur cette interface. Les paquets CDP ne sont plus reconnus et ils sont abandonnés.

La commande history permet à une interface de maintenir l'historique d'utilisation dans un format graphique similaire à l'historique du CPU. Cet historique peut être conservé en bits par seconde (bps) ou en paquets par seconde (pps), comme vous pouvez le voir dans cet exemple :

Switch(config-if)#history ?

bps Maintain history in bits/second

pps Maintain history in packets/second

En plus du débit, l'utilisateur peut surveiller divers compteurs d'interface :

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

Comme pour l'historique du processeur, il existe des graphiques pour les 60 dernières secondes, les 60 dernières minutes et les 72 dernières heures. Des graphiques distincts sont maintenus pour les histogrammes d'entrée et de sortie :

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)

Utilisez la commande show controllers ethernet-controller{interface{numéro-interface}}  pour afficher les statistiques des compteurs de trafic par interface (transmission et réception) et des compteurs d'erreurs lues à partir du matériel. Utilisez le mot clé phy pour afficher les registres internes de l'interface ou le mot clé port-info pour afficher des informations sur le port ASIC.

Voici un exemple de sortie de la commande show controllers ethernet-controller pour une interface spécifique :

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

Conseil : vous pouvez également utiliser la commande show interfaces {interface{interface-number}} controller pour afficher les statistiques de transmission et de réception par interface lues à partir du matériel.

Utilisez la commande show platform pm interface-flaps{interface{numéro-interface}}  pour afficher le nombre de fois qu’une interface est tombée en panne :

Ceci est un exemple de sortie de la commande show platform pm interface-flaps{interface{numéro-interface}}pour une interface spécifique :

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

Utiliser la commande show idprom{interface{numéro-interface}}  sans mots-clés pour afficher les informations IDPROM de l'interface spécifique. Utilisez avec le mot clé detail pour afficher des informations IDPROM hexadécimales détaillées.

Voici un exemple de sortie de la commande show idprom{interface{numéro-interface}} pour une interface spécifique. Les valeurs de seuil High et Low Warning|Alarm indiquées dans la sortie de cette commande sont les paramètres d'émetteur-récepteur optique opérationnels normaux. Ces valeurs peuvent être vérifiées à partir de la feuille de données pour l'optique spécifique. Reportez-vous à la fiche technique Cisco Optics

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

Conseil :Assurez-vous que la version matérielle et logicielle du périphérique est compatible avec la matrice de compatibilité SFP/SFP+ installée Cisco Optics-to-Device

Ce tableau répertorie les différentes commandes qui peuvent être utilisées pour résoudre les problèmes de liaison :

Commande

Objectif

show interfaces counters errors

Affiche les compteurs d’erreurs d’interface

show interfaces capabilities

Affiche les fonctionnalités de l’interface spécifique

show interface transceivers (spécifique fibre/SFP)

Affiche des informations sur les émetteurs-récepteurs optiques pour lesquels la surveillance optique numérique (DOM) est activée

show interface link

Affiche les informations de niveau liaison

show interface {interface{interface-number}} platform

Affiche les informations de plate-forme interface

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

Affiche des informations de port supplémentaires

show controllers ethernet-controller {interface{interface-number}} link status detail

Affiche l'état du lien

show errdisable flap-values

Affiche le nombre de volets autorisés avant l'état errdisable.

clear counters

Utilisez cette commande pour mettre à zéro les compteurs de trafic et d'erreurs afin de voir si le problème n'est que temporaire ou si les compteurs continuent à augmenter.

clear controllers ethernet-controller

Utilisez cette commande pour effacer les compteurs matériels de transmission et de réception.

Vérification de l’état du câble avec le réflecteur de domaine temporel (TDR)

La fonction de réflectomètre temporel (TDR) vous permet de déterminer si un câble est OUVERT ou COURT lorsqu'il est défectueux. Avec TDR, vous pouvez vérifier l'état des câbles en cuivre pour les ports des commutateurs Catalyst 9000. Le TDR détecte un défaut de câble avec un signal envoyé via le câble et lit le signal réfléchi. Tout ou partie du signal peut être réfléchi en raison de défauts dans le câble

Utilisez le test cable-diagnostics tdr {interface{interface-number} }pour démarrer le test TDR, puis utilisez la commande show cable-diagnostics tdr{interface-number}.

Conseil : reportez-vous à la vérification de l'état et de la connectivité des ports pour plus de détails

L’exemple montre un résultat de test TDR pour l’interface 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

Conseil : sur les commutateurs de la gamme Catalyst 9300, seuls ces types de défaut de câble sont détectés : OUVERT, COURT et NON-CORRESPONDANCE D'IMPÉDANCE. L'état Normal s'affiche si le câble est correctement raccordé et ceci est fait à titre d'exemple.

Lignes directrices du RDT

Les présentes lignes directrices s'appliquent à l'utilisation de TDR :

- Ne modifiez pas la configuration du port pendant l’exécution du test TDR.

- Si vous connectez un port lors d'un test TDR à un port compatible Auto-MDIX, le résultat TDR peut être non valide.

- Si vous connectez un port lors d'un test TDR à un port 100BASE-T tel que celui du périphérique, les paires inutilisées (4-5 et 7-8) sont signalées comme défectueuses car l'extrémité distante ne met pas fin à ces paires.

- En raison des caractéristiques du câble, vous devez exécuter le test TDR plusieurs fois pour obtenir des résultats précis.

- Ne modifiez pas l'état du port (par exemple, retirez le câble à l'extrémité proche ou éloignée) car les résultats peuvent être inexacts.

- TDR fonctionne mieux si le câble de test est déconnecté du port distant. Sinon, il peut être difficile pour vous d'interpréter correctement les résultats.

- Le TDR fonctionne sur quatre fils. Selon les conditions du câble, l'état peut indiquer qu'une paire est OUVERTE ou COURTE, tandis que toutes les autres paires de fils sont considérées comme défectueuses. Cette opération est acceptable car vous pouvez déclarer un câble défectueux à condition qu'une paire de fils soit OUVERTE ou COURTE.

- L’objectif du TDR est de déterminer le fonctionnement d’un câble plutôt que de localiser un câble défectueux.

- Lorsque TDR détecte un câble défectueux, vous pouvez toujours utiliser un outil de diagnostic de câble hors ligne pour mieux diagnostiquer le problème.

- Les résultats TDR peuvent différer d'une série à l'autre sur différents modèles de commutateurs de la gamme Catalyst 9300 en raison de la différence de résolution des implémentations TDR. Dans ce cas, vous devez vous reporter à un outil de diagnostic de câble hors ligne.

Surveillance optique numérique (DOM)

La surveillance optique numérique (DOM, Digital Optical Monitoring) est une norme à l'échelle de l'industrie, destinée à définir une interface numérique permettant d'accéder à des paramètres en temps réel tels que :

- Température

- Tension d'alimentation émetteur-récepteur

- Courant de polarisation laser

- Puissance Tx optique

- Puissance optique Rx

Comment activer DOM

Le tableau répertorie les commandes que vous pouvez utiliser pour activer/désactiver le mode DOM pour tous les types d'émetteurs-récepteurs du système :

Étapes

Commande ou action

Objectif

Étape 1

activer

Exemple :

switch>enable

Active le mode d’exécution physique

Saisissez votre mot de passe si vous y êtes invité

Étape 2

configurer le terminal

Exemple :

switch#configure terminal

Passe en mode de configuration globale

Étape 3

type d'émetteur-récepteur all

Exemple :

switch(config)#transceiver tapez all

Passe en mode de configuration Type d'émetteur-récepteur

Étape 4

surveillance

Exemple :

switch(config)#monitoring

Permet de surveiller tous les émetteurs-récepteurs optiques.

Utilisez la commande show interfaces {interface{interface-number}} transceiver detail pour afficher les informations de l'émetteur-récepteur :

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

Conseil : pour déterminer si un émetteur-récepteur optique fonctionne aux niveaux de signal appropriés, reportez-vous à la fiche technique Cisco Optics

Messages Syslog de surveillance optique numérique

Cette section décrit les messages syslog de violation de seuil les plus pertinents :

Niveaux de température des optiques SFP

- Explication : ces messages de journal sont générés lorsque la température est basse ou dépasse les valeurs de fonctionnement optique normales :

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

Niveaux de tension des modules optiques SFP

- Explication : ce message de journal est généré lorsque la tension est faible ou dépasse les valeurs de fonctionnement optique normales :

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

Niveaux d'éclairage des optiques SFP

- Explication : ce message de journal est généré lorsque la puissance lumineuse est faible ou dépasse les valeurs de fonctionnement optique :

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

Conseil : pour plus d'informations sur DOM, consultez Surveillance optique numérique

Optique Cisco et correction d'erreurs sans voie de retour (FEC)

FEC est une technique utilisée pour détecter et corriger un certain nombre d’erreurs dans un flux de bits et pour ajouter des bits redondants et du code de vérification des erreurs au bloc de messages avant la transmission. En tant que fabricant de modules, Cisco veille à ce que nos émetteurs-récepteurs soient conformes aux spécifications. Lorsque l'émetteur-récepteur optique est utilisé sur une plate-forme hôte Cisco, le FEC est activé par défaut en fonction du type de module optique détecté par le logiciel hôte (voir ce tableau téléchargeable). Dans la grande majorité des cas, l'implémentation FEC est dictée par la norme de l'industrie que le type optique prend en charge.

Pour certaines spécifications personnalisées, les implémentations FEC varient. Référez-vous à Comprendre FEC et sa mise en oeuvre dans le document Optiques Cisco pour des informations détaillées.

L'exemple montre comment configurer FEC et certaines des options disponibles :

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

Remarque : les deux côtés d'une liaison doivent avoir le même FEC encoding algorithme activé pour que la liaison s'active.

Commandes de débogage

Ce tableau répertorie les différentes commandes qui peuvent être utilisées pour déboguer les Port Flaps

Attention : utilisez les commandes debug avec précaution. Sachez que de nombreuses commandes debug ont un impact sur le réseau actif et qu’il est recommandé de les utiliser dans un environnement de travaux pratiques uniquement lorsque le problème est reproduit.                                                        ;

Commande

Objectif

debug pm

Débogage de Port Manager

debug pm port

Événements liés aux ports

debug platform pm

Informations de débogage du gestionnaire de ports de la plate-forme NGWC

debug platform pm l2-control

NGWC L2 Control Infra debug

debug platform pm link-status

Événements de détection de liaison d'interface

debug platform pm pm-vectors

Fonctions vectorielles de Port Manager

debug condition interface <nom interface>

Activer sélectivement les débogages pour une interface spécifique

debug interface state

Transitions des états

Ceci est un exemple de sortie d'exemple partiel de la commande ddéboguer commandes répertoriées dans le tableau :

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

Informations connexes

Matrice de compatibilité Cisco Optics-to-Device

Fiche technique des modules SFP Cisco pour applications Gigabit Ethernet

25 GE et 100 GE - Livre blanc sur la protection des investissements pour des débits plus élevés dans les entreprises

Fiche technique de la solution Cisco CWDM SFP

Soutenir l'innovation : comment le TAC de Cisco transforme la documentation et simplifie le libre-service

Technical Support & Documentation - Cisco Systems

ID de débogage Cisco

Description

ID de bogue Cisco CSCvu13029

Volets de liaison intermittents sur les commutateurs mGig Cat9300 vers les terminaux compatibles mGig

ID de bogue Cisco CSCvt50788

Les problèmes d'interopérabilité mGig du Cat9400 avec d'autres périphériques mGig entraînent des battements de liaison

ID de bogue Cisco CSCvu92432

CAT9400 : volets d'interface Mgig avec points d'accès Mgig

ID de bogue Cisco CSCve65787

Prise en charge de l'autoneg pour xcvr Cu 100G/40G/25G