Dépannage des pertes d'entrée dans Cisco IOS XR

Introduction

Ce document décrit comment dépanner les pertes d'entrée sur l'interface sur les routeurs XR.

Conditions préalables

Exigences

Aucune exigence spécifique n'est associée à ce document.

Composants utilisés

Cet article couvre les routeurs de la gamme ASR 9000, les routeurs de la gamme CRS et les routeurs de la gamme GSR 12000.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Informations générales

Les suppressions d'entrée dans Cisco IOS XR ont une signification complètement différente de celle des suppressions d'entrée dans Cisco IOS. Il peut vous embrouiller lorsqu'il migre Cisco IOS vers Cisco IOS XR et commence à voir ses compteurs d'abandon d'entrée dans la commande show interface.

Dans Cisco IOS, une perte d'entrée est due à la file d'attente d'entrée de l'interface qui se remplit. Cela signifie que trop de paquets ont été envoyés au processeur pour la commutation de processus et qu'il n'a pas pu les traiter assez rapidement. La file d'attente d'entrée est créée jusqu'à ce qu'elle soit pleine et qu'il y ait quelques abandons.

Dans Cisco IOS XR, il n'y a pas de définition stricte d'une suppression d'entrée. C'est donc essentiellement aux développeurs d'un composant de décider s'ils veulent incrémenter le compteur d'abandon d'entrée lorsqu'ils décident d'abandonner un paquet. L'essentiel ici est qu'à un moment donné dans le code, le routeur décide de supprimer le paquet, ce qui signifie qu'il est probable que le routeur n'était pas censé transférer ce paquet, et le routeur a décidé consciemment de le supprimer. Par conséquent, ceci n'est pas lié à l'encombrement comme dans Cisco IOS. Cependant, il s'agit plutôt d'un paquet qui a été reçu par le routeur et qui n'était pas censé être transmis, de sorte que le routeur a décidé de l'abandonner et il est très probable qu'il ne soit pas une raison d'être alarmé. Bien que, vous ne pouvez pas dire si c'est quelque chose de inquiétant ou non jusqu'à ce que vous ayez complètement compris le type de paquets qui incrémentent le compteur d'abandon d'entrée, et ce n'est pas si simple.

Exemples:

• Un routeur XR est connecté à un commutateur qui envoie des paquets BPDU (Bridge Protocol Data Unit) et UDLD. Le routeur XR n'a pas de Spanning Tree ni UDLD configuré sur ses interfaces de couche 3. Il abandonne donc simplement ces trames et incrémente le compteur d'abandons d'entrée dans show interface. Dans ce cas, il n'y a pas de quoi s'inquiéter car il est préférable de supprimer ces trames car les fonctionnalités ne sont pas configurées.
  
  
• Un ASR 9000 a une entrée CEF (Cisco Express Forwarding) programmée à tort en raison d'un bogue de sorte qu'il ne pointe pas vers une contiguïté valide. Dans ce cas, le processeur réseau de la carte de ligne (LC) du routeur ASR 9000 réalise que le routeur manque une information de charge et incrémente un compteur d'abandon de processeur réseau (NP) qui est chargé sur le compteur d'abandon d'entrée d'interface.

Lorsque les pertes en entrée sont signalées, le problème est de déterminer s'il s'agit de pertes légitimes comme dans l'exemple 1, ou de la conséquence d'un problème comme dans l'exemple 2.

Problème : Incrément dans la perte d'entrée

Ce document énumère les raisons des abandons d'entrée qui sont incrémentés et comment vérifier si c'est cette raison :

Abandons du contrôleur

Runts, FCS (Frame Check Sequence), aborts, débordements FIFO (First Input First Output), abandons POS (Packet Over SDH/SONET).

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#

Pour une interface Ethernet (gige, tengige...), vérifiez les points suivants :

show controllers gigabitEthernet 0/0/0/18 stats

Voyez s'il y a un compteur dans l'état du contrôleur qui s'incrémente à la même vitesse que le compteur d'abandon d'entrée dans show interface. Certains de ces compteurs d'erreurs doivent également être dans show interface.

Adresse de contrôle d'accès au support de destination inconnue (DMAC) ou VLAN dot1q

Paquets avec une adresse MAC de destination, pas celle de l'interface, ou avec un réseau local virtuel (VLAN) sans correspondance avec une sous-interface. Ces problèmes peuvent se produire lorsqu'un domaine L2 contient des adresses MAC de monodiffusion inconnues, de sorte que le routeur XR connecté à ce domaine L2 reçoit des trames avec une adresse MAC de destination qui n'est pas l'un de ses contrôleurs. Il est également possible qu’un routeur Cisco IOS envoie des messages de veille Ethernet sur son interface Gigabit, de sorte que ces messages incrémentent les abandons d’entrée sur le routeur XR, car ils ne possèdent pas l’adresse MAC de destination du routeur XR. En outre, lorsque l'interface est connectée à un autre périphérique qui a plus de VLAN/sous-interfaces dot1q configurés comme sur le routeur XR de sorte que le routeur XR reçoive des trames avec une étiquette dot1q inconnue.

Sur un module d'interface de couche physique (PLIM) fixe CRS, vous pouvez trouver de telles chutes dans :

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           

Ou dans l'état du contrôleur tengige ou gige :

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

Remarque : l'ID de bogue Cisco CSCub74803 existe. Input drop other est incrémenté au lieu de Input drop invalid DMAC au moins sur le PLIM fixe tengige à 8 ports du CRS.

Pour les adaptateurs de ports partagés (SPA) (CRS, XR 12000), les paquets avec un MAC non valide seraient abandonnés par la caméra SPA l2-tcam. Vous pouvez donc trouver ces abandons dans show controllers TenGigE a/b/c/d all :

    Input drop other            = 107

   l2-tcam Invalid DA Drops: 107

Sur un ASR 9000, les compteurs Input Drop Invalid DMAC et Input Drop Other dans les états du contrôleur ne sont pas incrémentés. Pour reconnaître ces branchements sur l'ASR 9000, il faut donc trouver le processeur réseau qui gère l'interface avec les branchements d'entrée :

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#

Vous pouvez voir que l'interface gig 0/0/0/30 est gérée par le NP 0 sur 0/0/CPU0.
Vérifions les compteurs NP de NP0 sur 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#

Ainsi, L3_NOT_MYMAC dans le compteur NP signifie que le routeur a reçu une trame sur une interface de couche 3 avec une adresse MAC de destination qui n'est pas l'une des interfaces. Le routeur l’abandonne comme prévu, et ceci est signalé comme des abandons d’entrée dans show interface.

Sur l'ASR 9000 pour les paquets reçus avec un VLAN dot1q non configuré sur une sous-interface de l'ASR 9000, le compteur 802.1Q inconnu de perte d'entrée n'est pas incrémenté dans les états show controllers gigabitEthernet 0/0/0/30. La procédure est la même que ci-dessus pour le DMAC inconnu : identifiez quel NP gère les interfaces, puis vérifiez ce compteur NP. Vous voyez que le compteur NP UIDB_TCAM_MISS_AGG_DROP s'incrémente dans ce cas.

Paquets abandonnés en raison d'un protocole de niveau supérieur non reconnu

Cette ligne est facile à détecter car il y a un compteur pour ces abandons une ligne en dessous des abandons d'entrée dans show interface :

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

Vous pouvez voir ici que toutes les suppressions d'entrée étaient dues à un protocole de niveau supérieur non reconnu.

Cela signifie que les paquets ont été reçus avec un protocole Ethernet auquel le routeur ne s’intéresse pas. Cela signifie qu'une fonctionnalité est configurée sur le voisin (ou sur un hôte connecté au domaine de couche 2 connecté à cette interface) afin qu'il vous envoie des trames avec un protocole non configuré sur le routeur XR.

Exemples : BPDU, 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) etc....

Lorsque ces fonctionnalités ne sont pas configurées sur l'interface XR, la boîte XR les supprime comme prévu. Pour savoir quel type de trames incrémente ce compteur, vous pouvez avoir à comparer les fonctionnalités activées sur le routeur XR avec celles activées sur le voisin (il peut s’agir d’un routeur ou d’un commutateur), ou les fonctionnalités activées sur tous les périphériques connectés aux domaines de couche 2 connectés à cette interface (beaucoup moins facile). Si le routeur XR est connecté à un commutateur, vous pouvez essayer une étendue sur ce commutateur des paquets qu'il envoie au routeur XR sur l'interface avec des abandons d'entrée. 
ASR9000/XR : abandons pour erreur de protocole de niveau supérieur non reconnue

Abandons NP sur l'ASR 9000

Les compteurs de pertes dans le processus réseau (NP) de l'ASR 9000 sont signalés comme des pertes d'entrée lorsqu'ils s'appliquent à un paquet reçu sur une interface et abandonné. Cela ne se produit pas pour les abandons Packet Switch Engine (PSE) sur le CRS et le XR 12000. Ils ne sont pas comptés comme des pertes en entrée.

Si vous avez des pertes d'entrée sur un ASR 9000 et qu'elles ne correspondent pas à l'une de ces raisons, alors vous feriez un show controllers np ports all location 0/<x>/CPU0 pour trouver le NP qui gère l'interface avec des pertes d'entrée, puis vérifieriez ses compteurs NP avec show contr np counters np<y> location 0/<x>/CPU0.

Vous pouvez diriger le résultat pour garder uniquement les compteurs DROP avec une commande comme sh contr np counters np<y> location 0/<x>/CPU0 | i DROP, mais cela peut être dangereux, car parfois un compteur d'abandon n'a pas DROP dans son nom. Vous avez vu un bon exemple avec L3_NOT_MYMAC. Peut-être un tuyau pour DROP|DISCARD|NOT|EXCD.

Vous pouvez effacer les compteurs d'interface et les compteurs NP avec le contrôleur clear np counters np<y> location 0/<x>/CPU0 à peu près au même moment pour savoir quel compteur NP s'incrémente à la même vitesse que les pertes d'entrée.

Par exemple, vous obtenez IPV4_PLU_DROP_PKT dans les compteurs NP, ce qui signifie que l'entrée CEF/PLU indique que le paquet doit être abandonné. Vous n'avez pas de route par défaut et les inaccessibles sont désactivés, de sorte que les paquets ne correspondant pas à une route plus spécifique, où le fait d'atteindre le gestionnaire CEF par défaut, est une entrée d'abandon.

Si vous trouvez un compteur d'abandon dans le NP qui peut expliquer les abandons d'entrée lorsqu'ils s'incrémentent au même rythme, mais que le compteur d'abandon NP n'est pas très explicite, vous pouvez naviguer sur cette page pour essayer de comprendre ce que le compteur signifie :
ASR9000/XR : dépannage des abandons de paquets et compréhension des compteurs d'abandon NP

Note : La page de Xander sur les forums de support contient les raisons d'abandon de la première génération de cartes de ligne (Trident), et il y a de nouveaux noms de compteur pour la nouvelle génération de cartes de ligne (Typhoon). En fonction du nom, vous devez pouvoir trouver un nom de compteur similaire à celui du Trident.

Netio

Vous pouvez collecter un show netio idb <int> et cela vous donne les compteurs de perte d'entrée d'interface et de perte de noeud de réseau :

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>

Les pertes dans le noeud MPLS (Multi-Protocol Label Switching) ici peuvent être dues à l'expiration de la durée de vie MPLS (TTL) (en cas de boucle ou lorsque le client effectue une commande traceroute), ou à la fragmentation requise et au bit Ne pas fragmenter (DF) défini par exemple. Vous pouvez exécuter debug mpls packet drop et debug mpls error avec l'emplacement de l'interface pour essayer de comprendre quel type de paquet incrémente ce compteur.

Paquets de multidiffusion pontés. Quand vous voyez des paquets de suppression netio IN mais aucun noeud netio ci-dessous avec quelques gouttes qui pourraient expliquer les paquets de suppression IN, alors cela peut être des paquets pointés mcast, et vous pouvez activer deb mfib netio drop pour comprendre quel type de paquets