Inhalt

Einleitung

Voraussetzungen

Anforderungen

Verwendete Komponenten

Hintergrundinformationen

Problem: Erhöhung des Eingangsabfalls

Controller fällt aus

Unbekannte mittlere Zielzugriffskontrolladresse (DMAC) oder dot1q VLAN

Pakete aufgrund von unbekanntem Upper-Level-Protokoll verworfen

NP Drops für ASR 9000

Netio

Einleitung

In diesem Dokument wird beschrieben, wie Sie Eingabefehler an der Schnittstelle von XR-Routern beheben.

Voraussetzungen

Anforderungen

Es gibt keine spezifischen Anforderungen für dieses Dokument.

Verwendete Komponenten

Dieser Artikel behandelt Router der Serie ASR 9000, Router der Serie CRS und Router der Serie GSR 12000.

Die Informationen in diesem Dokument beziehen sich auf Geräte in einer speziell eingerichteten Testumgebung. Alle Geräte, die in diesem Dokument benutzt wurden, begannen mit einer gelöschten (Nichterfüllungs) Konfiguration. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die möglichen Auswirkungen aller Befehle verstehen.

Hintergrundinformationen

Input-Drops in IOS XR haben eine völlig andere Bedeutung als Input-Drops in IOS. Es kann Sie verwirren, wenn es IOS zu IOS XR migriert und beginnt, seine Eingabefehler in der Show-Schnittstelle zu sehen.

In IOS ist die Eingabe aufgrund der vollen Schnittstellen-Eingabewarteschlange verloren gegangen. Dies bedeutet, dass zu viele Pakete für das Prozess-Switching an die CPU gesendet wurden und diese nicht schnell genug verarbeiten konnte. Die Eingabewarteschlange wird aufgebaut, bis sie voll ist und einige Verwerfungen auftreten.

In IOS XR gibt es keine strikte Definition eines Eingabedopfens. Es liegt also im Grunde an den Entwicklern einer Komponente, zu entscheiden, ob sie den Eingangs-Zähler erhöhen wollen, wenn sie sich entscheiden, ein Paket zu verwerfen. Das Entscheidende ist, dass der Router irgendwann im Code beschließt, das Paket zu verwerfen, was bedeutet, dass es wahrscheinlich ist, dass der Router das Paket nicht weiterleiten sollte, und der Router sich bewusst dafür entscheidet, es zu verwerfen. Daher hat dies nichts mit Überlastung zu tun, wie dies bei IOS der Fall ist. Es handelt sich jedoch eher um ein Paket, das vom Router empfangen wurde und nicht weitergeleitet werden sollte. Daher hat der Router entschieden, es zu verwerfen, und es ist sehr wahrscheinlich kein Grund, alarmiert zu werden. Obwohl, Sie können nicht sagen, ob es etwas zu befürchten oder nicht, bis Sie vollständig verstanden haben, die Art von Paketen, die inkrementieren die Eingabe Drop-Zähler und das ist nicht so einfach, leider.

Beispiele:

- Ein XR-Router ist mit einem Switch verbunden, der einige Bridge-Protokoll-Dateneinheiten (BPDUs) und UDLD-Pakete sendet. Auf dem XR-Router ist weder Spanning-Tree noch UDLD für seine Layer-3-Schnittstellen konfiguriert. Daher werden diese Frames einfach verworfen, und der Zähler für verworfene Eingaben in der Show-Schnittstelle wird erhöht. In diesem Fall gibt es nichts zu befürchten, da es genau das Richtige ist, diese Frames zu löschen, da die Funktionen nicht konfiguriert sind.

- Ein ASR 9000 verfügt über einen Cisco Express Forwarding (CEF)-Eintrag, der aufgrund eines Fehlers falsch programmiert wurde, sodass er nicht auf eine gültige Adjacency zeigt. In diesem Fall erkennt der Netzwerkprozessor der ASR 9000 Line Card (LC), dass der Router eine Lastinformation übersieht und einen Network Processor (NP)-Zähler erhöht, der zum Interface Input Drop Counter hochgeladen wird.

Wenn die Eingabefehler gemeldet werden, besteht das Problem darin, herauszufinden, ob es sich um legitime Einbrüche wie in Beispiel 1 oder die Folge eines Problems wie in Beispiel 2 handelt.

Problem: Erhöhung des Eingangsabfalls

In diesem Dokument werden die Gründe für die inkrementierten Eingabefehler aufgelistet und es wird geprüft, ob dies der Grund ist:

Controller fällt aus

Runts, Frame Check Sequence (FCS), Abbrüche, FIFO-Überläufe (First Input First Output), Giganten Packet Over SDH/SONET (POS)-Drops.

RP/0/RP0/CPU0:equinox#show controllers poS 0/2/0/0 framer statistics

POS Driver Internal Cooked Stats Values for port 0

===================================================

Rx Statistics                   Tx Statistics

-------------                   -------------

Total Bytes:    71346296        Total Bytes:    67718333

Good Bytes:     71346296        Good Bytes:     67718333

Good Packets:   105385          Good Packets:   67281

Aborts:         0               Aborts:         0

FCS Errors:     0               Min-len errors: 0

Runts:          0               Max-len errors: 0

FIFO Overflows: 0               FIFO Underruns: 0

Giants:         0

Drops:          0

RP/0/RP0/CPU0:equinox#

Überprüfen Sie für eine Ethernet-Schnittstelle Folgendes:

Controller anzeigen GigabitEthernet 0/0/0/18-Statistiken

Prüfen Sie, ob es einen Zähler in den Controller-Statistiken gibt, der mit der gleichen Rate inkrementiert wie der Eingabe-Zähler in der Show-Schnittstelle. Einige dieser Fehlerindikatoren müssen sich auch in der Anzeigeschnittstelle befinden.

Unbekannte mittlere Zielzugriffskontrolladresse (DMAC) oder dot1q VLAN

Pakete mit einer Ziel-MAC-Adresse, die nicht die der Schnittstelle ist, oder mit einem Virtual Local Area Network (VLAN) ohne Übereinstimmung mit einer Subschnittstelle. Diese können auftreten, wenn in einer L2-Domäne unbekannte Unicast-MAC-Adressen überflutet werden, sodass der mit dieser L2-Domäne verbundene XR-Router Frames mit einer Ziel-MAC-Adresse empfängt, die keiner seiner Controller ist. Es ist auch möglich, wenn ein IOS-Router Ethernet-Keepalives über seine spezielle Schnittstelle sendet, sodass diese Keepalives die Eingangsverluste auf dem XR-Router inkrementieren, da sie nicht über die MAC-Zieladresse des XR-Routers verfügen. Oder wenn die Schnittstelle mit einem anderen Gerät verbunden ist, für das mehr dot1q-VLANs/Subschnittstellen wie auf dem XR-Router konfiguriert sind, sodass der XR-Router Frames mit einem unbekannten dot1q-Tag empfängt.

Auf einem festen CRS-PLIM (Physical Layer Interface Modules) finden Sie solche Drops in:

RP/0/RP0/CPU0:pixies-uk#sh contr plim asic statistics interface tenGigE 0/1/0/3 location 0/1/CPU0

Wed Aug 22 16:07:47.854 CEST

Node: 0/1/CPU0

TenGigE0/1/0/3 Drop

-------------------------------------------------------------------------------

RxFiFO Drop       : 0                   PAR Tail Drop     : 0

PAR Err Drop      : 0                   Invalid MAC Drop  : 86

TxFIFO Drop       : 0                   Invalid VLAN Drop : 11

Oder im Tenigge- oder Giga-Controller-Status:

RP/0/RP0/CPU0:pixies-uk#sh contr ten 0/1/0/3 stats

Wed Aug 22 16:22:42.059 CEST

Statistics for interface TenGigE0/1/0/3 (cached values):

Ingress:

Input drop overrun          = 0

Input drop abort            = 0

Input drop invalid VLAN     = 11

Input drop invalid DMAC     = 0

Input drop invalid encap    = 0

Input drop other            = 86

Hinweis: Fehler CSCub74803 vorhanden, Input Drop sonstiges wird inkrementiert anstelle von Input Drop ungültigen DMAC mindestens auf dem 8-Port tenigi festen PLIM des CRS.

Bei Shared Port Adapters (SPAs) (CRS, XR 12000) würden die Pakete mit ungültiger MAC von der SPA l2-tcam verworfen, sodass Sie diese Verwerfungen in Show Controllern TenGigE a/b/c/d alle finden können:

Input drop other            = 107

l2-tcam Invalid DA Drops: 107

Auf einem ASR 9000 werden der Eingangsabwurf ungültige DMAC und der Eingangsabwurf andere Zähler in den Controller-Statistiken nicht inkrementiert. Die Erkennung dieser Tropfen auf dem ASR 9000 besteht also darin, den NP zu finden, der die Schnittstelle mit den Eingangs-Tropfen handhabt:

RP/0/RSP0/CPU0:obama#sh int gig 0/0/0/30 | i "input drops"

Wed Aug 22 16:55:52.374 CEST

1155 packets input, 156256 bytes, 1000 total input drops

RP/0/RSP0/CPU0:obama#sh contr np ports all location 0/0/CPU0

Wed Aug 22 16:56:01.385 CEST

Node: 0/0/CPU0:

----------------------------------------------------------------

NP Bridge Fia                       Ports

-- ------ --- ---------------------------------------------------

0  0      0   GigabitEthernet0/0/0/30 - GigabitEthernet0/0/0/39

1  0      0   GigabitEthernet0/0/0/20 - GigabitEthernet0/0/0/29

2  1      0   GigabitEthernet0/0/0/10 - GigabitEthernet0/0/0/19

3  1      0   GigabitEthernet0/0/0/0 - GigabitEthernet0/0/0/9

RP/0/RSP0/CPU0:obama#

Sie können also sehen, dass die Schnittstelle gig 0/0/0/30 vom NP 0 auf 0/0/CPU0 behandelt wird.

Überprüfen wir die NP-Zähler von NP0 auf 0/0/CPU0:

RP/0/RSP0/CPU0:obama#sh contr np counters np0 location 0/0/CPU0

Wed Aug 22 16:56:19.883 CEST

Node: 0/0/CPU0:

----------------------------------------------------------------

Show global stats counters for NP0, revision v3

Read 26 non-zero NP counters:

Offset  Counter                                         FrameValue   Rate (pps)

-------------------------------------------------------------------------------

22  PARSE_ENET_RECEIVE_CNT                                  1465           0

23  PARSE_FABRIC_RECEIVE_CNT                                2793           0

24  PARSE_LOOPBACK_RECEIVE_CNT                              2800           0

28  MODIFY_FABRIC_TRANSMIT_CNT                                80           0

29  MODIFY_ENET_TRANSMIT_CNT                                1792           0

32  RESOLVE_INGRESS_DROP_CNT                                1000           0

35  MODIFY_EGRESS_DROP_CNT                                  1400           0

36  MODIFY_MCAST_FLD_LOOPBACK_CNT                           1400           0

38  PARSE_INGRESS_PUNT_CNT                                   465           0

39  PARSE_EGRESS_PUNT_CNT                                    155           0

45  MODIFY_RPF_FAIL_DROP_CNT                                1400           0

53  PARSE_LC_INJECT_TO_FAB_CNT                                80           0

54  PARSE_LC_INJECT_TO_PORT_CNT                              864           0

57  PARSE_FAB_INJECT_UNKN_CNT                                155           0

67  RESOLVE_INGRESS_L3_PUNT_CNT                              465           0

69  RESOLVE_INGRESS_L2_PUNT_CNT                              464           0

70  RESOLVE_EGRESS_L3_PUNT_CNT                              1400           0

93  CDP                                                      464           0

95  ARP                                                        1           0

109  DIAGS                                                    154           0

221  PUNT_STATISTICS                                         9142           1

223  PUNT_DIAGS_RSP_ACT                                       155           0

225  PUNT_DIAGS_RSP_STBY                                      155           0

227  NETIO_RP_TO_LC_CPU_PUNT                                  155           0

373  L3_NOT_MYMAC                                            1000           0

565  INJECT_EGR_PARSE_PRRT_PIT                                928           0

RP/0/RSP0/CPU0:obama#

L3_NOT_MYMAC im NP-Zähler bedeutet also, dass der Router einen Frame an einer Layer-3-Schnittstelle mit einer Ziel-MAC-Adresse empfangen hat, die keine der Schnittstellen ist. Der Router verwirft die Nachricht wie erwartet, und dies wird als Eingabe in der Show-Schnittstelle verworfen.

Auf dem ASR 9000 für Pakete, die mit einem dot1q-VLAN empfangen werden, das nicht auf einer Subschnittstelle des ASR 9000 konfiguriert ist, wird der unbekannte 802.1Q-Zähler in show controllers gigabitEthernet 0/0/0/30 stats nicht inkrementiert. Die Vorgehensweise ist dieselbe wie oben für die unbekannte DMAC: Identifizieren Sie, welcher NP die Schnittstellen behandelt, und überprüfen Sie dann diese NP-Zähler. Sie sehen, dass der NP-Zähler UIDB_TCAM_MISS_AGG_DROP in diesem Fall inkrementiert.

Pakete aufgrund von unbekanntem Upper-Level-Protokoll verworfen

Diese lässt sich auf einfache Weise erkennen, da es einen Zähler für diese Drops gibt, der eine Zeile unter den Input-Drops in der show-Schnittstelle liegt:

RP/0/RSP0/CPU0:obama#sh int gig 0/0/0/18

Wed Aug 22 17:14:35.232 CEST

GigabitEthernet0/0/0/18 is up, line protocol is up

5 minute input rate 4000 bits/sec, 0 packets/sec

5 minute output rate 5000 bits/sec, 0 packets/sec

7375 packets input, 6565506 bytes, 1481 total input drops

1481 drops for unrecognized upper-level protocol

Hier können Sie sehen, dass alle Eingabefehler auf ein unbekanntes Protokoll der oberen Ebene zurückzuführen sind.

Dies bedeutet, dass Pakete mit einem Ethernet-Protokoll empfangen wurden, das für den Router nicht von Interesse ist. Das bedeutet, dass eine Funktion auf dem Nachbarn (oder auf einem Host, der mit der Layer-2-Domäne verbunden ist, die mit dieser Schnittstelle verbunden ist) konfiguriert ist, sodass sie uns Frames mit einem Protokoll sendet, das auf dem XR-Router nicht konfiguriert ist.

Beispiele: BPDUs, Intermediate System to Intermediate System (ISIS), Connection Less Network Protocol (CLNP), IPv6, UDLD, Cisco Discovery Protocol (CDP), VLAN Trunking Protocol (VTP), Dynamic Trunking Protocol (DTP), Link Layer Discovery Protocol (LLDP) usw..

Wenn diese Funktionen nicht für die XR-Schnittstelle konfiguriert sind, werden sie wie erwartet von der XR-Box verworfen. Um herauszufinden, welche Art von Frames diesen Zähler inkrementiert, müssen Sie vergleichen, welche Funktionen auf dem XR-Router aktiviert sind, mit den Funktionen, die auf dem Nachbarn aktiviert sind (es kann ein Router oder ein Switch sein), oder die Funktionen, die auf allen Geräten aktiviert sind, die mit den Layer-2-Domänen verbunden sind, die mit dieser Schnittstelle verbunden sind (viel weniger einfach). Wenn der XR-Router mit einem Switch verbunden ist, können Sie an diesem Switch eine Spanning der Pakete testen, die er an den XR-Router an der Schnittstelle mit Eingangsverlusten sendet. Siehe:

ASR9000/XR : Verwirft aufgrund eines unerkannten Protokollfehlers der oberen Ebene

NP Drops für ASR 9000

Zähler für Datenverlust im Netzwerkprozess (Network Process, NP) des ASR 9000 werden als Eingabe-Datenverlust gemeldet, wenn sie auf ein an einer Schnittstelle empfangenes und verworfenes Paket angewendet werden. Dies ist bei Verwerfen der Packet Switch Engine (PSE) auf dem CRS und dem XR 12000 nicht der Fall: Sie werden nicht als Verwerfen der Eingabe gezählt.

Wenn Sie also Eingabe-Drops auf einem ASR 9000 haben und diese nicht mit einem dieser Gründe übereinstimmen, dann würden Sie einen Controller np-Ports alle Position 0/<x>/CPU0 anzeigen, um den NP zu finden, der die Schnittstelle mit Eingabe-Drops behandelt, und dann seine NP-Zähler mit show contr np counters np<y> Position 0/<x>/CPU0 überprüfen .

Sie können die Ausgabe über die Pipeline so weiterleiten, dass nur DROP-Zähler mit einem Befehl wie sh contr np counters np<y> location 0/<x>/CPU0 beibehalten werden. | i DROP, aber dies kann gefährlich sein, da ein Drop-Zähler manchmal nicht DROP in seinem Namen hat. Sie haben ein gutes Beispiel für L3_NOT_MYMAC gesehen. Also vielleicht Pfeife für DROP|DISCARD|NOT|EXCD.

Sie können die Schnittstellenzähler und die NP-Zähler mit clear controller np counters np<y> location 0/<x>/CPU0 ungefähr zur gleichen Zeit löschen, um herauszufinden, welcher NP-Zähler mit der gleichen Rate inkrementiert wie die Eingabe fällt.

Sie erhalten beispielsweise IPV4_PLU_DROP_PKT in den NP-Zählern, was bedeutet, dass der CEF/PLU-Eintrag besagt, dass das Paket verworfen werden muss. Sie verfügen nicht über eine Standardroute und haben nicht erreichbare Routen deaktiviert. Daher stimmen Pakete nicht mit einer spezifischeren Route überein, wenn sie auf den Standard-CEF-Handler treffen, bei dem es sich um einen Drop-Eintrag handelt.

Wenn Sie einen Zähler im NP finden, der erklären kann, dass die Eingabe fällt, während sie mit der gleichen Rate inkrementiert werden, aber der Zähler für den NP-Fall ist nicht sehr selbsterklärend, können Sie auf dieser Seite navigieren, um zu versuchen, zu verstehen, was der Zähler bedeutet:

ASR9000/XR: Fehlerbehebung bei Paketverlusten und Erkennung von NP-Zählern für Paketverluste

Hinweis: Xanders Seite auf Support-Foren enthält die Gründe für das Verwerfen der ersten Generation von Linecards (Trident) und es gibt neue Zählernamen für die neue Generation (Typhoon) Linecards... aber basierend auf dem Namen, müssen Sie in der Lage sein, einen ähnlichen Zählernamen wie auf Trident zu finden.

Netio

Sie können eine show netio idb <int> erfassen und erhalten die Zähler für den Schnittstelleneingang und den Netio-Knoten-Abbruch:

RP/0/RP0/CPU0:ipc-lsp690-r-ca-01#show netio idb gigabitEthernet 0/2/0/1

GigabitEthernet0/2/0/1 (handle: 0x01280040, nodeid:0x21) netio idb:

---------------------------------

name:                    GigabitEthernet0_2_0_1

interface handle:        0x01280040

interface global index:  3

physical media type:     30

dchain ptr:              <0x482e0700>

echain ptr:              <0x482e1024>

fchain ptr:              <0x482e13ec>

driver cookie:           <0x4829fc6c>

driver func:             <0x4829f040>

number of subinterfaces: 4096

subblock array size:     7

DSNCNF:                  0x00000000

interface stats info:

IN  unknown proto pkts:  0

IN  unknown proto bytes: 0

IN  multicast pkts:      0

OUT multicast pkts:      0

IN  broadcast pkts:      0

OUT broadcast pkts:      0

IN  drop pkts:           0 <=========== cleared when added to input drop counter !!!

OUT drop pkts:           0

IN  errors pkts:         0

OUT errors pkts:         0

Chains

--------------------

Base decap chain:

ether                <30>  <0xfd018cd8, 0x482c736c>  <       0,        0>

Protocol chains:

---------------

<Protocol number> (name)  Stats

Type  Chain_node       <caps num>  <function, context> <drop pkts, drop bytes>

<snip>

<13> (mpls)   Stats IN: 204 pkts, 23256 bytes; OUT: 0 pkts, 0 bytes

Encap:

mpls                 <25>  <0xfcc7ddbc, 0x00000000>  <       0,        0>

ether                <30>  <0xfd0189b4, 0x482c736c>  <       0,        0>

l2_adj_rewrite       <86>  <0xfcaa997c, 0x4831a2e8>  <       0,        0>

pcn_output           <54>  <0xfd0561f0, 0x48319f04>  <       0,        0>

q_fq                 <43>  <0xfd05f4b8, 0x48320fec>  <       0,        0>

txm_nopull           <60>  <0xfcadba38, 0x4824c0fc>  <       0,        0>

Decap:

pcn_input            <55>  <0xfd0561f0, 0x4830ba8c>  <       0,        0>

q_fq_input           <96>  <0xfd05f330, 0x48312c7c>  <       0,        0>

mpls                 <25>  <0xfcc7b2b8, 0x00000000>  <     152,    17328>

Fixup:

l2_adj_rewrite       <86>  <0xfcaa945c, 0x00000000>  <       0,        0>

pcn_output           <54>  <0xfd0561f0, 0x48319f04>  <       0,        0>

q_fq                 <43>  <0xfd05f4b8, 0x48320fec>  <       0,        0>

txm_nopull           <60>  <0xfcadba38, 0x4824c0fc>  <       0,        0>

Die Drops im MPLS-Knoten (Multi-Protocol Label Switching) können z. B. darauf zurückzuführen sein, dass die MPLS-Lebensdauer (Time To Live, TTL) abgelaufen ist (im Falle einer Schleife oder wenn der Kunde eine Traceroute durchführt) oder dass eine Fragmentierung erforderlich ist und beispielsweise ein DF-Bit (Do Not Fragment, Fragmentierung) gesetzt ist. Sie können debug mpls packet drop und debug mpls error mit dem Speicherort der Schnittstelle ausführen, um herauszufinden, welche Art von Paket diesen Zähler inkrementiert.

Multicast-Pakete mit Zeitlimit. Wenn Sie in Drop Pkts netio IN sehen, aber unten keinen Netio-Knoten mit einigen Drops, die die IN Drop Pkts erklären könnten, dann könnte dies mcast punted Packets sein, und Sie können deb mfib netio drop aktivieren, um herauszufinden, welche Art von Paketen