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

10

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?

Allan Sundry
la source
1
vérifier la force du signal des fibres, nettoyer les terminaisons des fibres (y compris au niveau des panneaux de brassage), remplacer l'optique.
Mike Pennington
J'utilise un câble à connexion directe "SFP + à SFP +" avec l'adaptateur "XFP à SFP +". Peut-être que quelque chose du tas doit être remplacé.
Allan Sundry
Excusez-moi, j'utilise un adaptateur "XENPACK to SFP +" et "Direct Attach Cable SFP + to SFP +"
Allan Sundry
@AllanSundry Excusé!
jwbensley

Réponses:

4

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

show interfaces transceiver 

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.

Sebastian Wiesinger
la source
"L'interpréteur de sortie n'est disponible que pour les utilisateurs Cisco.com enregistrés disposant d'un contrat de service Cisco". Pouvez-vous me donner l'article au format pdf?
Allan Sundry
Allan, le .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.
Mike Pennington
Malheureusement, je n'ai pas accès à cette page. L'utilisation d'un adaptateur "XENPACK to SFP +" et "Direct Attach Cable SFP + to SFP +" conduit à un résultat vide de la commande "sh int te3 / 4 transceiver detail" (ajoutée au premier message).
Allan Sundry
D'accord, j'ai mis à jour ma réponse.
Sebastian Wiesinger
Après avoir remplacé le DAC par les compteurs d'erreurs de liaison optique ont cessé de croître - en huit heures environ 2 erreurs d'entrée.
Allan Sundry
9

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.

totallystubby
la source