Dépannage des rabats de port sur les commutateurs Catalyst 9000
Table des matières
Problème
Ce document décrit comment dépanner une ou plusieurs interfaces de commutateur qui changent de façon répétée d'état entre up et down (volets de port ou volets de liaison), ce qui entraîne une connectivité intermittente.
Environnement
Commutateurs de la gamme Cisco Catalyst 9000 avec liaisons ascendantes/descendantes cuivre ou fibre. Le problème peut se produire sur les ports d'accès, les liaisons ascendantes et (le cas échéant) les ports de module de réseau amovibles. Le chemin physique peut inclure des tableaux de connexions, des périphériques d'extrémité et des émetteurs-récepteurs optiques.
- Applicabilité des supports : TDR s'applique uniquement aux interfaces cuivre ; DOM s'applique uniquement aux émetteurs-récepteurs optiques pris en charge.
- Types d'interface : Les ports fixes autonomes et les ports de module sont dans le champ d'application ; utilisez le même workflow pour les deux.
- Prise en charge optique : Utilisez uniquement des câbles optiques pris en charge pour la plate-forme et la version logicielle.
Motif
Les causes les plus courantes sont les suivantes : câblage défectueux ou non pris en charge, émetteurs-récepteurs SFP (Small Form-Factor Pluggable) ou SFP+ (Small Form-Factor Pluggable Plus) non pris en charge ou défectueux, non-concordance des modes duplex ou de négociation, comportement d'économie d'énergie des terminaux et autres défaillances de la couche physique.
Résolution
Suivez le workflow de dépannage de cet article pour confirmer le rabat dans les journaux, valider la connectivité physique et les optiques, examiner les compteurs d'interface et exécuter des vérifications TDR ou DOM fibre optique uniquement, le cas échéant.
Conditions préalables
Exigences
Aucune exigence spécifique n'est associée à ce document.
Composants utilisés
Les informations contenues dans ce document sont basées sur les commutateurs de la gamme Cisco 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 battement de port, également appelé battement de liaison, se produit lorsqu’une interface physique du commutateur s’active et s’arrête à plusieurs reprises. Les causes les plus courantes sont un câblage défectueux, non pris en charge ou non standard, des émetteurs-récepteurs SFP (Small Form-Factor Pluggable) non pris en charge et d'autres problèmes de synchronisation des liaisons. La condition peut être intermittente ou permanente.
Étant donné que les défauts de liaison sont généralement un problème physique, ce document décrit comment diagnostiquer le problème, collecter des journaux utiles et dépanner les défauts de port sur les commutateurs de la gamme Cisco Catalyst 9000.
Workflow de dépannage
Utilisez ce flux de travail pour isoler les causes les plus courantes des défaillances de port. Commencez à l'étape 1 et continuez dans l'ordre. Exécutez les étapes facultatives uniquement lorsque le type de lien et les symptômes correspondent.
- Confirmez le rabat dans les journaux. Utilisez la commande show logging pour confirmer les événements up/down répétés et capturer les horodatages.
- Vérifiez la connectivité physique et les optiques. vérification du câblage, des tableaux de connexions et des émetteurs-récepteurs pris en charge ; réinstallez ou remplacez les composants dont le fonctionnement a été vérifié.
- Vérifiez les compteurs d'interface et les statistiques matérielles. Utilisez show interfaces et les compteurs de contrôleur pour identifier les erreurs de couche 1 (CRC, erreurs de symbole, erreurs FCS).
- Exécutez TDR (liaisons cuivre uniquement). Utilisez TDR pour détecter les conditions OPEN/SHORT et la distance approximative de panne.
- Cochez DOM (liaisons fibre optique uniquement). Comparez l'alimentation/la température/la tension optique aux seuils indiqués dans la fiche technique.
- Vérifiez FEC (optiques prises en charge uniquement). Confirmez les paramètres de correction des erreurs de transfert et la compatibilité si applicable.
- N'utilisez les commandes debug que si le problème persiste. Collecter la sortie de débogage ciblée pendant une fenêtre de reproduction et la désactiver immédiatement après la capture.
Chaque section comprend une courte note qui indique quand l'utiliser.
Utilisez cette section lorsque l'accès physique est disponible. Vérifiez que les modules réseau, les câbles et les émetteurs-récepteurs SFP ou SFP+ sont correctement installés avant de vérifier les compteurs ou d'exécuter des diagnostics supplémentaires.
Guide d'installation du module réseau
Utilisez cette référence lorsqu'un module de réseau amovible est présent. Le tableau décrit les meilleures pratiques d'installation d'un module de réseau dans un commutateur de la gamme Cisco Catalyst 9000 :
| Plateforme |
URL |
| Commutateurs Catalyst 9200 |
Guide d'installation matérielle des commutateurs Catalyst 9200 |
| Commutateurs Catalyst 9300 |
Guide d'installation matérielle des commutateurs Catalyst 9300 |
| Commutateurs Catalyst 9400 |
Guide d'installation matérielle des commutateurs Catalyst 9400 |
| Commutateurs Catalyst 9500 |
Guide d'installation matérielle des commutateurs Catalyst 9500 |
| Commutateurs 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
Utilisez cette section une fois que le rabat est confirmé dans les journaux. Ces tableaux décrivent les causes courantes des défaillances de liaison liées aux câbles et les actions de récupération recommandées.
| Motif |
Action de récupération |
| Câble incorrect |
Remplacez le câble suspect par un câble en bon état. Recherchez les broches cassées ou manquantes sur les connecteurs. |
| Connexion lâche |
Reconnectez le câble. Retirez le connecteur et réinsérez-le pour vous assurer qu'il est bien en place. |
| Panneaux de brassage |
Éliminez les connexions défectueuses du tableau de connexions. Si possible, évitez le panneau de brassage pour l’exclure. |
| SFP incorrect ou incorrect (spécifique à la fibre) |
Remplacez le SFP suspect par un SFP dont le fonctionnement a été vérifié. Vérifiez 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 dont le fonctionnement a été vérifié pour dépanner un port ou un module suspect. |
| Périphérique de point d'extrémité incorrect ou ancien |
Remplacez le téléphone, le haut-parleur ou un autre terminal par un périphérique dont le fonctionnement a été vérifié ou un périphérique plus récent. |
| Mode veille du périphérique |
Cela peut être un rabat attendu. Vérifiez l'horodatage du port flap. Comparez-le à d'autres événements simultanés. Déterminez ensuite si un paramètre de veille en est la cause. |
Vérification de la compatibilité SFP et SFP+
Utilisez cette section lorsque la liaison instable utilise un émetteur-récepteur à fibre optique. La gamme d'interfaces enfichables à chaud de Cisco offre un large choix de vitesses, de protocoles, de portées et de supports de transmission pris en charge.
Utilisez toute combinaison de modules émetteurs-récepteurs SFP ou SFP+ prise en charge par le commutateur Cisco Catalyst 9000. Chaque port doit correspondre aux spécifications de longueur d'onde à l'autre extrémité du câble. Le câble ne doit pas dépasser la longueur de câble prise en charge pour assurer une communication fiable.
Utilisez uniquement des modules émetteurs-récepteurs SFP Cisco sur le périphérique Cisco. Chaque module émetteur-récepteur SFP ou SFP+ prend en charge la fonctionnalité Cisco Quality Identification (ID). Cette fonctionnalité permet à un commutateur ou routeur Cisco d'identifier et de valider que le module émetteur-récepteur est certifié et testé par Cisco.
Identifier les rabats de port
Conditions préalables: Accès privilégié en mode EXEC (par exemple, enable) et accès au tampon du journal système du périphérique ou au journal système distant.
Résultat escompté : Les messages up/down répétés pour la même interface dans un court laps de temps confirment une condition de battement.
Utilisez d'abord cette section pour confirmer qu'un rabat se produit. Exécutez la commande show logging | include changed pour identifier un événement d'affolement de lien. Cet exemple montre des messages partiels du journal système du commutateur pour un événement de battement de liaison sur l'interface TenGigabitEthernet1/0/40 :
Switch#show logging | include changed
August 17 21:06:08.431 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/0/40, changed state to down
August 17 21:06:39.058 UTC: %LINK-3-UPDOWN: Interface TenGigabitEthernet1/0/40, changed state to down
August 17 21:06:41.968 UTC: %LINK-3-UPDOWN: Interface TenGigabitEthernet1/0/40, changed state to up
August 17 21:06:42.969 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/0/40, changed state to up
August 17 21:07:20.041 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/0/40, changed state to down
August 17 21:07:21.041 UTC: %LINK-3-UPDOWN: Interface TenGigabitEthernet1/0/40, changed state to down
August 17 21:07:36.534 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/0/40, changed state to up
August 17 21:08:06.598 UTC: %LINK-3-UPDOWN: Interface TenGigabitEthernet1/0/40, changed state to up
August 17 21:08:07.628 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/0/40, changed state to down
August 17 21:08:08.628 UTC: %LINK-3-UPDOWN: Interface TenGigabitEthernet1/0/40, changed state to down
August 17 21:08:10.943 UTC: %LINK-3-UPDOWN: Interface TenGigabitEthernet1/0/40, changed state to up
August 17 21:08:11.944 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface TenGigabitEthernet1/0/40, changed state to up
- Identifiez l'horodatage de chaque transition up/down.
- Comparez l'horodatage à d'autres événements sur la même interface (par exemple, comportement d'économie d'énergie du point d'extrémité).
- Déterminez si le rabat est attendu ou s'il indique un problème de couche physique.
Interface Commandes show
Cas d’utilisation: Une fois les événements up/down répétés confirmés, le chemin physique est validé.
commande : show interfaces et show controllers ethernet-controller interface pour l'interface affectée.
Résultat attendu : Les compteurs d'erreurs (CRC, erreurs de symboles, FCS) restent stables ou augmentent lentement dans des conditions normales.
Action suivante en cas d'anomalie : Remplacez le câble/câble optique, passez à un port dont le fonctionnement a été vérifié et vérifiez à nouveau les compteurs. passez au TDR (cuivre) ou au DOM (fibre), selon le cas.
Utilisez cette section une fois que le rabat est confirmé et que le chemin physique est vérifié. La commande show interfaces fournit des informations qui permettent d'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
Le tableau répertorie certains des compteurs de la commande show interfaces :
| Compteur |
Problèmes et causes courantes qui augmentent les compteurs d’erreurs |
| CRC |
Un nombre élevé d'erreurs de contrôle par redondance cyclique (CRC) est généralement le résultat de collisions. Elle peut également indiquer un problème physique tel que le câblage, un module SFP, une interface défectueuse ou une carte réseau. Il peut également indiquer une non-correspondance de mode duplex. |
| Erreurs en entrée |
Cela inclut les trames incomplètes, les trames géantes, les nombres sans tampon, CRC, les trames, les dépassements et les nombres ignorés. D'autres erreurs d'entrée peuvent également augmenter le nombre d'erreurs d'entrée. |
| Erreurs de sortie |
Les erreurs de sortie peuvent augmenter lorsque la file d'attente de sortie est sous-dimensionnée ou lorsque l'interface est surabonnée. |
| Total des pertes en sortie |
Les pertes de sortie sont généralement le résultat d'une sursouscription d'interface causée par des modèles de trafic plusieurs-à-un ou 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 certain point. Après ce point, les paquets commencent à tomber. Les tampons peuvent être réglés pour fournir un certain amortisseur, mais ils ne peuvent pas garantir zéro chute de sortie. |
| Abandons de protocole inconnus |
Des abandons de protocole inconnus se produisent lorsque l'interface de réception n'est pas configurée pour ce protocole ou lorsque le commutateur ne reconnaît pas le protocole. Par exemple, si deux commutateurs sont connectés et que le protocole CDP (Cisco Discovery Protocol) est désactivé sur une interface de commutateur, des abandons de protocole inconnus se produisent sur cette interface. Les paquets CDP ne sont plus reconnus et le commutateur les abandonne. |
La commande history permet à une interface de gérer l'historique d'utilisation dans un format graphique similaire à l'historique de l'UC. L'historique peut être géré soit en bits par seconde (bps), soit en paquets par seconde (pps), comme indiqué dans cet exemple :
Switch(config-if)#history ?
bps Maintain history in bits/second
pps Maintain history in packets/second
En plus du débit, divers compteurs d'interface peuvent être surveillés :
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, les graphiques sont disponibles 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#show interfaces gigabitEthernet 1/0/2 history ?
60min Display 60 minute histograms only
60sec Display 60 second histograms only
72hour Display 72 hour histograms only
all Display all three histogram intervals
both Display both input and output histograms
input Display input histograms only
output Display output histograms only
| Output modifiers
<cr> <cr>
------ Sample output ---------
Switch#show interfaces tenGigabitEthernet 1/0/9 history 60sec
10
9
8
7
6
5
4
3
2
1
0....5....1....1....2....2....3....3....4....4....5....5....6
0 5 0 5 0 5 0 5 0 5 0
TenGigabitEthernet1/0/9 input rate(mbits/sec) (last 60 seconds)
10
9
8
7
6
5
4
3
2
1
0....5....1....1....2....2....3....3....4....4....5....5....6
0 5 0 5 0 5 0 5 0 5 0
TenGigabitEthernet1/0/9 output rate(mbits/sec) (last 60 seconds)
Utilisez la commande show controllers ethernet-controller interface {interface{interface-number}} pour afficher les compteurs de trafic par interface (transmission et réception) et les statistiques d'erreur lues à partir du matériel. Utilisez le mot clé phy pour afficher les registres internes de l'interface. Utilisez le mot clé port-info pour afficher des informations sur le circuit intégré spécifique à l'application de 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
Utilisez la commande show platform pm interface-flaps {interface{interface-number}} pour afficher le nombre de fois qu'une interface tombe en panne :
Voici un exemple de sortie de la commande show platform pm interface-flaps {interface{interface-number}} 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
Utilisez cette section pour les liaisons par fibre optique lorsque l'intégrité optique doit être vérifiée. Utilisez la commande show idprom interface {interface-number} pour afficher les informations IDPROM de l'émetteur-récepteur installé dans l'interface spécifiée. Utilisez le mot clé detail pour afficher les champs IDPROM hexadécimaux détaillés.
Cet exemple montre la sortie de la commande show idprom {interface{interface-number}} pour une interface spécifique. Les valeurs High et Low Warning|Alarm threshold 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 dans la fiche technique pour l'optique spécifique. Reportez-vous à la documentation des modules émetteurs-récepteurs optiques Cisco.
Switch#show idprom interface Twe1/0/1
IDPROM for transceiver TwentyFiveGigE1/0/1 :
Description = SFP or SFP+ optics (type 3)
Transceiver Type: = GE CWDM 1550 (107)
Product Identifier (PID) = CWDM-SFP-1550 <--
Vendor Revision = A
Serial Number (SN) = SERIALNUMBER
Vendor Name = CISCO-FINISAR
Vendor OUI (IEEE company ID) = 00.90.65 (36965)
Common Language Equipment Identifier (CLEI) code = CNTRV14FAB
Cisco part number = 10-1879-03
Device State = Enabled.
Date code (yy/mm/dd) = 14/12/22
Connector type = LC.
Encoding = 8B10B (1)
Nominal bitrate = OTU-1 (2700 Mbits/s)
Minimum bit rate as % of nominal bit rate = not specified
Maximum bit rate as % of nominal bit rate = not specified
The transceiver type is 107
Link reach for 9u fiber (km) = LR-2(80km) (80)
LR-3(80km) (80)
ZX(80km) (80)
Link reach for 9u fiber (m) = IR-2(40km) (255)
LR-1(40km) (255)
LR-2(80km) (255)
LR-3(80km) (255)
DX(40KM) (255)
HX(40km) (255)
ZX(80km) (255)
VX(100km) (255)
Link reach for 50u fiber (m) = SR(2km) (0)
IR-1(15km) (0)
IR-2(40km) (0)
LR-1(40km) (0)
LR-2(80km) (0)
LR-3(80km) (0)
DX(40KM) (0)
HX(40km) (0)
ZX(80km) (0)
VX(100km) (0)
1xFC, 2xFC-SM(10km) (0)
ESCON-SM(20km) (0)
Link reach for 62.5u fiber (m) = SR(2km) (0)
IR-1(15km) (0)
IR-2(40km) (0)
LR-1(40km) (0)
LR-2(80km) (0)
LR-3(80km) (0)
DX(40KM) (0)
HX(40km) (0)
ZX(80km) (0)
VX(100km) (0)
1xFC, 2xFC-SM(10km) (0)
ESCON-SM(20km) (0)
Nominal laser wavelength = 1550 nm.
DWDM wavelength fraction = 1550.0 nm.
Supported options = Tx disable
Tx fault signal
Loss of signal (standard implementation)
Supported enhanced options = Alarms for monitored parameters
Diagnostic monitoring = Digital diagnostics supported
Diagnostics are externally calibrated
Rx power measured is "Average power"
Transceiver temperature operating range = -5 C to 75 C (commercial)
Minimum operating temperature = 0 C
Maximum operating temperature = 70 C
High temperature alarm threshold = +90.000 C
High temperature warning threshold = +85.000 C
Low temperature warning threshold = +0.000 C
Low temperature alarm threshold = -4.000 C
High voltage alarm threshold = 3600.0 mVolts
High voltage warning threshold = 3500.0 mVolts
Low voltage warning threshold = 3100.0 mVolts
Low voltage alarm threshold = 3000.0 mVolts
High laser bias current alarm threshold = 84.000 mAmps
High laser bias current warning threshold = 70.000 mAmps
Low laser bias current warning threshold = 4.000 mAmps
Low laser bias current alarm threshold = 2.000 mAmps
High transmit power alarm threshold = 7.4 dBm
High transmit power warning threshold = 4.0 dBm
Low transmit power warning threshold = -1.7 dBm
Low transmit power alarm threshold = -8.2 dBm
High receive power alarm threshold = -3.0 dBm
Low receive power alarm threshold = -33.0 dBm
High receive power warning threshold = -7.0 dBm
Low receive power warning threshold = -28.2 dBm
External Calibration: bias current slope = 1.000
External Calibration: bias current offset = 0
Ce tableau répertorie les commandes qui peuvent être utilisées pour résoudre les problèmes d'instabilité des liaisons. Ordre d'utilisation recommandé : show logging, show interfaces, show controllers ethernet-controller, show platform pm interface-flaps, puis des commandes spécifiques à la fibre ou au cuivre, selon le cas.
| 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 à la fibre ou au 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 plateforme d'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 fonctionnalité de réflectomètre du domaine 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 de la gamme 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}.
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
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. Entrez votre mot de passe si le système vous le demande. |
| É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 du 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
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: Ces messages de journal sont générés 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: Ces messages de journal sont générés 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.
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 du FEC est dictée par la norme industrielle prise en charge par le type optique.
Pour certaines spécifications personnalisées, les implémentations FEC varient. Référez-vous à Comprendre FEC et son implémentation dans le document Cisco Optics 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--
Commandes de débogage
Ce tableau répertorie les différentes commandes qui peuvent être utilisées pour déboguer les Port Flaps
| 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 |
Voici un exemple de sortie partiel des commandes debug 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
Bogues Cisco associés
| ID de bogue Cisco |
Description |
| ID de bogue Cisco CSCvu13029 |
Flaps 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 défaillances de liaison. |
| ID de bogue Cisco CSCvu92432 |
CAT9400 : Mgig interface Flaps avec Mgig APs. |
| ID de bogue Cisco CSCve65787 |
Prise en charge de l'autoneg pour 100G/40G/25G Cu xcvr. |
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 Cisco transforme la documentation et simplifie le libre-service
- Assistance technique de Cisco et téléchargements
Historique de révision
| Révision | Date de publication | Commentaires |
|---|---|---|
3.0 |
09-Sep-2026
|
Recertification - Problème mis à jour, SEO, traduction automatique, exigences de style et formatage. |
2.0 |
13-Mar-2024
|
Recertification |
1.0 |
04-Nov-2022
|
Première publication |
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)