Cisco 7604 + RSP720 3CXL + WS-X6704-10GE erhöht die Fehlerzähler am Port, es tritt jedoch kein Verlust über den Port auf


10

Cisco 7604 + RSP720 3CXL + WS-X6704-10GE erhöht die Fehlerzähler am Port, aber es gibt keinen Verlust durch den 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

Der Router wird zur Kündigung von Kunden und Kanallimits für diese mit der Verwendung von Policing verwendet.

AKTUALISIEREN:

#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

Ich verwende einen Adapter "XENPACK to SFP +" und "Direct Attach Cable SFP + to SFP +" - dies erschwert die Diagnose.

Wo finde ich die Ursache für Wachstumszähler?


1
Überprüfen Sie die Fasersignalstärke, reinigen Sie die Glasfaseranschlüsse (auch an Patchfeldern) und ersetzen Sie die Optik.
Mike Pennington

Ich verwende das Direktanschlusskabel "SFP + zu SFP +" mit dem Adapter "XFP zu SFP +". Vielleicht muss etwas aus dem Haufen ersetzt werden.
Allan Sundry

Entschuldigung, ich verwende einen Adapter "XENPACK to SFP +" und "Direct Attach Cable SFP + to SFP +"
Allan Sundry

@AllanSundry Entschuldigt!
Jwbensley

Antworten:


4

Sie sehen CRC- und Framing-Fehler sowie allgemeine Eingabefehler. Wenn dies beim Einrichten des Ports passiert ist, kann dies daran liegen, dass immer noch an der Glasfaser herumgespielt wird.

Wenn dies die meiste Zeit während des normalen Betriebs geschieht, weist dies auf ein schwaches Lichtniveau oder einen anderen Fehler mit der Faser (n) oder der Optik hin.

Sie können die Lichtverhältnisse mit überprüfen

show interfaces transceiver 

Beachten Sie, dass dies möglicherweise zu falschen Messwerten für die Optik von Drittanbietern führt. Sie müssten dann das Strombudget / die Leistungsgrenzen der Optik nachschlagen, um festzustellen, ob Sie mit den Spezifikationen in Reichweite sind.

Versuchen Sie, wie von Mike vorgeschlagen, alle Faseranschlüsse zu reinigen. Wenn dies nicht hilft, ersetzen Sie die Optik.

Im Moment sind die Fehler zu klein, um bemerkt zu werden, aber das kann sich sehr schnell ändern. Repariere es jetzt besser, als um 3 Uhr morgens geweckt zu werden, weil plötzlich mehr Verluste in der Leitung sind.

Auch für Schnittstellen- (Fehler-) Zähler lohnt es sich manchmal, den Cisco-Ausgabeinterpreter zu verwenden, um zu analysieren, was Sie sehen:

https://www.cisco.com/pcgi-bin/Support/OutputInterpreter/home.pl

Nehmen Sie die Analyse mit einem Körnchen Salz, manchmal verpassen sie den Punkt, aber es kann helfen, einen schnellen Überblick darüber zu bekommen, was falsch ist.

UPDATE :

Bei Verwendung eines XENPAK / SFP + -Adapters und von DAC-Kabeln kann das Problem bei beiden liegen. Versuchen Sie, die Adapter und / oder Kabel auszutauschen. Da der DAC keine Optik enthält (es ist Kupfer), zeigt der interface transceiverBefehl nichts Nützliches an.

Auch die Kabellänge und mögliche elektromagnetische Störungen können Probleme mit dem DAC verursachen. Wenn alles fehlschlägt, versuchen Sie, auf Optik und optische Verkabelung umzuschalten, und prüfen Sie, ob dies hilfreich ist.


"Der Output Interpreter steht nur registrierten Cisco.com-Benutzern mit einem Cisco-Servicevertrag zur Verfügung." Kannst du mir den Artikel im as pdf geben?
Allan Sundry

Allan, das .plCGI, mit dem Sebastian verlinkt hat, hat keine PDF-Kopie. Dies ist ein Tool, mit dem Sie die Ausgabe des Befehls show einfügen und Empfehlungen für mögliche Abhilfemaßnahmen erhalten können.
Mike Pennington

Leider habe ich keinen Zugriff auf diese Seite. Die Verwendung eines Adapters "XENPACK to SFP +" und "Direct Attach Cable SFP + to SFP +" führt zu einem leeren Ergebnis des Befehls "sh int te3 / 4 transceiver detail" (dem ersten Beitrag hinzugefügt).
Allan Sundry

Okay, ich habe meine Antwort aktualisiert.
Sebastian Wiesinger

Nach dem Ersetzen des DAC durch die optische Verbindung sind die Fehlerzähler nicht mehr gewachsen - in acht Stunden etwa 2 Eingabefehler.
Allan Sundry

9

Es gibt Verluste, Sie sehen die Auswirkungen einfach nicht. Das Display zeigt nur 155706 Eingabefehler von 46982598919 Paketen in den letzten drei Tagen und vier Stunden an. Dies ist ein Paketverlust von 0,0003%, weshalb es beim Testen so schwierig ist, aus erster Hand zu sehen.

Wenn Sie keine betrieblichen Auswirkungen feststellen, besteht die Wahrscheinlichkeit, dass dies ignoriert werden kann. Ein derart geringer Paketverlust hat in einem Standard-IP-Netzwerk einen vernachlässigbaren Effekt, und die Protokolle der oberen Schicht passen sich entsprechend an.

Wenn Sie die Quelle aufspüren möchten, ist dies schwierig. Wie Mike betonte, besteht der erste Schritt darin, die Signalstärke zu überprüfen (Schnittstelle xxxx Transceiver anzeigen; dies erfordert Module mit DOM-Fähigkeit) und zu versuchen, die Abschlusspunkte Ihrer Patchkabel zu reinigen. Wenn dies nicht funktioniert, ersetzen Sie die Patchkabel. Ersetzen Sie als letzten Strohhalm die eigentlichen optischen Module.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.