Dépannage des rabats de port sur les commutateurs de la gamme Catalyst 9000
Options de téléchargement
-
ePub (99.3 KB)
Consulter à l’aide de différentes applications sur iPhone, iPad, Android ou Windows Phone -
Mobi (Kindle) (103.2 KB)
Consulter sur un appareil Kindle ou à l’aide d’une application Kindle sur plusieurs appareils
Langage exempt de préjugés
Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
À propos de cette traduction
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
Table des matières
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.
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 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
Cet article a été écrit par Leonardo Pena Davila.
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. Vérifiez si des broches sont manquantes ou brisées 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 rabats de port
Utilisez la show loggingcommande pour identifier un événement d’affolement 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 upConseil : 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 Gbit/s à 1 Gbit/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 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
<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-number}} pour afficher les statistiques de compteurs de trafic et d'erreurs par interface (transmission et réception) 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{interface-number}} pour afficher le nombre de fois qu'une interface s'est arrêtée :
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 la commande show idprom{interface{interface-number}} sans mots clés pour afficher les informations IDPROM pour l'interface spécifique. Utilisez avec le mot clé detail pour afficher des informations IDPROM hexadécimales détaillées.
Il s'agit d'un exemple de sortie de la commande show idprom{interface{numéro-interface}} pour une interface spécifique. Les seuils d'alarme High et Low Warning répertoriés dans cette sortie de commande sont les paramètres opérationnels normaux de l'émetteur-récepteur optique. 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 OpenConseil : 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 : l' encoding algorithme FEC doit être activé des deux côtés d'une liaison pour que la liaison soit établie.
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
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 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
Informations connexes
Matrice de compatibilité Cisco Optics-to-Device
Fiche technique des modules SFP Cisco pour applications Gigabit Ethernet
Historique de révision
| Révision | Date de publication | Commentaires |
|---|---|---|
2.0 |
13-Mar-2024 |
Recertification |
1.0 |
04-Nov-2022 |
Première publication |
Contribution d’experts de Cisco
- Leonardo Pena DavilaIngénieur de remontée Cisco
CommentairesContacter Cisco
- Ouvrir un dossier d’assistance
- (Un contrat de service de Cisco est requis)