Cisco 7604 + RSP720 3CXL + WS-X6704-10GE augmentant les compteurs d'erreur sur le port, mais il n'y a aucune perte via le port:
#sh interfaces Te3/4
TenGigabitEthernet3/4 is up, line protocol is up (connected)
Hardware is C7600 10Gb 802.3, address is 588d.09b4.8d80 (bia 588d.09b4.8d80)
MTU 1500 bytes, BW 10000000 Kbit/sec, DLY 10 usec,
reliability 255/255, txload 42/255, rxload 42/255
Encapsulation 802.1Q Virtual LAN, Vlan ID 1., loopback not set
Keepalive set (10 sec)
Full-duplex, 10Gb/s
Transport mode LAN (10GBASE-R, 10.3125Gb/s)
input flow-control is off, output flow-control is off
Clock mode is auto
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters 3d03h
Input queue: 0/75/291/291 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 1667291000 bits/sec, 244099 packets/sec
5 minute output rate 1665910000 bits/sec, 243961 packets/sec
L2 Switched: ucast: 4875 pkt, 1667250 bytes - mcast: 0 pkt, 0 bytes
L3 in Switched: ucast: 0 pkt, 0 bytes - mcast: 0 pkt, 0 bytes mcast
L3 out Switched: ucast: 0 pkt, 0 bytes mcast: 0 pkt, 0 bytes
46982598919 packets input, 40800999530943 bytes, 0 no buffer
Received 1748682 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
155706 input errors, 65000 CRC, 11401 frame, 0 overrun, 0 ignored
0 watchdog, 0 multicast, 0 pause input
0 input packets with dribble condition detected
46985469520 packets output, 40792363160570 bytes, 0 underruns
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 routeur est utilisé pour la terminaison des clients et pour leur limiter les canaux avec l'utilisation de la police.
METTRE À JOUR:
#sh int te3/4 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)
--------- ----------------- ---------- --------- --------- ---------
Te3/4 28.2 70.0 60.0 5.0 0.0
High Alarm High Warn Low Warn Low Alarm
Voltage Threshold Threshold Threshold Threshold
Port (Volts) (Volts) (Volts) (Volts) (Volts)
--------- ----------------- ---------- --------- --------- ---------
Te3/4 0.00 N/A N/A N/A N/A
High Alarm High Warn Low Warn Low Alarm
Current Threshold Threshold Threshold Threshold
Port (milliamperes) (mA) (mA) (mA) (mA)
--------- ----------------- ---------- --------- --------- ---------
Te3/4 N/A N/A N/A N/A N/A
Optical High Alarm High Warn Low Warn Low Alarm
Transmit Power Threshold Threshold Threshold Threshold
Port (dBm) (dBm) (dBm) (dBm) (dBm)
--------- ----------------- ---------- --------- --------- ---------
Te3/4 N/A ++ 0.9 0.4 -8.2 -8.1
Optical High Alarm High Warn Low Warn Low Alarm
Receive Power Threshold Threshold Threshold Threshold
Port (dBm) (dBm) (dBm) (dBm) (dBm)
--------- ----------------- ---------- --------- --------- ---------
Te3/4 N/A ++ 0.9 0.4 -14.4 -15.0
J'utilise un adaptateur "XENPACK to SFP +" et "Direct Attach Cable SFP + to SFP +" - cela complique le diagnostic.
Où trouver la cause des compteurs de croissance?
cisco
cisco-ios-15
errors
policing
Allan Sundry
la source
la source
Réponses:
Vous voyez des erreurs CRC et de trame et des erreurs d'entrée générales. Si cela se produisait lors de la configuration du port, cela pourrait être dû au fait que les gens jouent encore avec la fibre.
Si cela se produit pendant le fonctionnement normal la plupart du temps, cela indique un faible niveau de lumière ou une autre erreur avec la ou les fibres ou l'optique.
Vous pouvez vérifier les niveaux d'éclairage avec
Attention, cela pourrait signaler des lectures incorrectes pour les optiques tiers. Vous devrez ensuite rechercher le budget / les limites de puissance de l'optique pour voir si vous êtes dans la plage des spécifications.
Comme l'a suggéré Mike, essayez de nettoyer toutes les terminaisons de fibres. Si cela n'aide pas, essayez de remplacer l'optique.
Pour le moment, les erreurs sont trop petites pour être remarquées mais cela peut changer très rapidement. Mieux vaut le réparer maintenant que d'être réveillé à 3 heures du matin car il y a soudainement plus de pertes sur la ligne.
Aussi pour les compteurs d'interface (erreur), il est parfois rentable d'utiliser l'interpréteur de sortie Cisco pour analyser ce que vous voyez:
https://www.cisco.com/pcgi-bin/Support/OutputInterpreter/home.pl
Prenez l'analyse avec un grain de sel, parfois ils manquent de raison, mais cela peut aider à obtenir un aperçu rapide de ce qui ne va pas.
MISE À JOUR :
Lors de l'utilisation d'un adaptateur XENPAK / SFP + et de câbles DAC, le problème peut être lié à l'un ou l'autre. Essayez de remplacer les adaptateurs et / ou les câbles. Comme le DAC n'a pas d'optique (c'est du cuivre), la
interface transceivercommande ne montrera rien d'utile.De plus, la longueur du câble et d'éventuelles interférences électromagnétiques pourraient causer des problèmes avec le DAC. Si tout échoue, essayez de passer à l'optique et au câblage optique et voyez si cela aide.
la source
.plCGI auquel Sebastian a lié n'a pas de copie PDF; c'est un outil où vous pouvez coller la sortie de la commande show et obtenir des recommandations pour des remèdes potentiels.Il y a une perte, vous ne voyez tout simplement pas l'impact. L'écran n'affiche que 155706 erreurs d'entrée sur 46982598919 paquets au cours des trois jours et quatre heures précédents. Il s'agit d'une perte de paquets de .0003%, c'est pourquoi il est si difficile de voir de première main pendant les tests.
Si vous ne voyez aucun impact opérationnel, il est probable que cela puisse être ignoré en toute sécurité. Un tel faible niveau de perte de paquets a un effet assez négligeable dans un réseau IP standard et les protocoles de couche supérieure s'adapteront en conséquence.
Si vous avez l'intention de retrouver la source, ce sera difficile. Comme Mike l'a souligné, la première étape consistera à vérifier la force du signal (show interface xxxx transceiver; cela nécessite des modules avec capacité DOM) et à essayer de nettoyer les points de terminaison de vos cordons de brassage. Si cela ne fonctionne pas, essayez de remplacer les cordons de brassage. Comme paille finale, remplacez les modules optiques réels.
la source