Fehlerbehebung bei Eingabefehlern in Cisco IOS XR

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 kennen.

Hintergrundinformationen

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

In Cisco 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 Cisco IOS XR gibt es keine strikte Definition für einen Input Drop. 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 hierbei ist, dass der Router irgendwann im Code beschließt, das Paket zu verwerfen, was bedeutet, dass es wahrscheinlich ist, dass der Router dieses Paket nicht weiterleiten sollte, und der Router hat bewusst entschieden, es zu verwerfen. Daher ist dies nicht mit Überlastung verbunden, wie dies bei Cisco 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 fallen zu lassen, und es ist sehr wahrscheinlich kein Grund, alarmiert zu werden. Obwohl Sie nicht sagen können, ob es etwas ist, um sich Sorgen zu machen 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.

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 das Richtige ist, diese Frames zu verwerfen, 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 Lastangabe übersieht, und erhöht den Wert eines Network Processor (NP) Drop Counter, der in den 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 Eingabeverfügungen 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, nicht der der Schnittstelle, oder mit einem Virtual Local Area Network (VLAN), dem keine Subschnittstelle entspricht. 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 Cisco IOS-Router Ethernet-Keepalives über seine spezielle Schnittstelle sendet, sodass diese Keepalives die Eingangs-Drops auf dem XR-Router inkrementieren, da sie nicht über die Ziel-MAC-Adresse des XR-Routers verfügen. Wenn die Schnittstelle mit einem anderen Gerät verbunden ist, auf dem mehr dot1q-VLANs/Subschnittstellen wie auf dem XR-Router konfiguriert sind, empfängt der XR-Router Frames mit einem unbekannten dot1q-Tag.

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: Cisco Bug-ID CSCub74803 vorhanden. Der andere Input-Drop wird anstatt des ungültigen Input-Drop-DMACs inkrementiert, zumindest auf dem 8-Port tenigge fixed 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 den Show Controllern TenGigE a/b/c/d alle finden:

    Input drop other            = 107

   l2-tcam Invalid DA Drops: 107

Auf einem ASR 9000 werden die Zähler für ungültige DMAC-Eingaben und für ungültige Eingaben 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 sehen, dass die Schnittstelle gig 0/0/0/30 vom NP 0 auf 0/0/CPU0 verarbeitet wird.
Lassen Sie uns die NP-Zähler von NP0 auf 0/0/CPU0 überprüfen:

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 es wie erwartet, und dies wird als Eingabe-Verwerfung in der Show-Schnittstelle gemeldet.

Auf dem ASR 9000 wird bei Paketen, die mit einem dot1q-VLAN empfangen werden, das nicht auf einer Subschnittstelle des ASR 9000 konfiguriert ist, der Zähler für den unbekannten Eingangsverlust 802.1Q in den Statistiken show controllers gigabitEthernet 0/0/0/30 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 diesen 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 leicht 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 Frames mit einem Protokoll gesendet werden, 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. 
ASR9000/XR : Drops wegen unerkanntem Protokollfehler 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 tritt nicht bei Verwerfen der Packet Switch Engine (PSE) auf dem CRS und dem XR 12000 auf. Sie werden nicht als Input-Drops gezählt.

Wenn Sie also Eingabe-Drops auf einem ASR 9000 haben und diese nicht mit einem dieser Gründe übereinstimmen, würden Sie die np-Ports aller Controller 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> location 0/<x>/CPU0 überprüfen 1.

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 Zähler für Tropfen manchmal kein 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 Pakete deaktiviert, sodass Pakete, die nicht einer spezifischeren Route entsprechen, bei denen das Erreichen des Standard-CEF-Handlers ein Drop-Eintrag ist.

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-Verlustzählern

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 von Linecards (Typhoon). 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) festgelegt 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 netio IN Drop Pkts sehen, aber keinen Netio Node unten mit einigen Drops, die die IN Drop Pkts erklären könnten, dann kann dies mcast punted Packets sein, und Sie können deb mfib netio Drop aktivieren, um herauszufinden, welche Art von Paketen