Risoluzione dei problemi relativi alle perdite di input in Cisco IOS XR

Introduzione

In questo documento viene descritto come risolvere i problemi relativi alle perdite di input sull'interfaccia dei router XR.

Prerequisiti

Requisiti

Nessun requisito specifico previsto per questo documento.

Componenti usati

Questo articolo riguarda i router ASR serie 9000, i router serie CRS e i router serie GSR 12000.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Premesse

In Cisco IOS XR le perdite di input hanno un significato completamente diverso rispetto alle perdite di input in Cisco IOS. Può confondere l'utente quando esegue la migrazione di Cisco IOS a Cisco IOS XR e inizia a visualizzare i contatori di perdita di input nell'interfaccia show.

In Cisco IOS, una perdita di input è dovuta alla coda di input dell'interfaccia che si riempie. Ciò significa che troppi pacchetti sono stati puntati alla CPU per la commutazione del processo e non è stata in grado di gestirli abbastanza velocemente. La coda di input viene creata fino a quando non si riempie e si verificano alcuni cali.

In Cisco IOS XR, non esiste una definizione rigida di perdita di input. In pratica, spetta agli sviluppatori di un componente decidere se incrementare il contatore di perdita di input quando decidono di rilasciare un pacchetto. Il punto chiave è che a un certo punto del codice, il router decide di scartare il pacchetto, quindi è probabile che non sia stato lui a inoltrarlo, e il router ha deciso consciamente di scartarlo. Pertanto, ciò non è correlato a una congestione come in Cisco IOS. Si tratta tuttavia di un pacchetto che è stato ricevuto dal router e che non doveva essere inoltrato, quindi il router ha deciso di scaricarlo e molto probabilmente non è un motivo per essere allarmati. Tuttavia, non è possibile stabilire se ci si debba preoccupare o meno fino a quando non si è perfettamente consapevoli del tipo di pacchetti che incrementano il contatore di rilascio dell'input, il che non è così semplice.

Esempi:

• Un router XR è collegato a uno switch che invia alcuni pacchetti BDPU (Bridge Protocol Data Unit) e UDLD. Sulle interfacce di layer 3 del router XR non è configurato lo spanning-tree o il protocollo UDLD, quindi i frame vengono scartati e il contatore delle perdite di input viene incrementato nell'interfaccia show. In questo caso, non c'è nulla di cui preoccuparsi, poiché è la cosa giusta da fare per eliminare questi frame perché le funzionalità non sono configurate.
  
  
• Su un ASR 9000 una voce Cisco Express Forwarding (CEF) è stata programmata in modo errato a causa di un bug, quindi non punta a un'adiacenza valida. In questo caso, il processore di rete della scheda di linea ASR 9000 (LC) si rende conto che il router non ha informazioni sul carico e incrementa un contatore di rilascio del processore di rete (NP) che viene caricato nel contatore di rilascio dell'input dell'interfaccia.

Quando vengono segnalate le perdite di input, il problema consiste nel determinare se si tratta di perdite legittime come nell'esempio 1 o della conseguenza di un problema come nell'esempio 2.

Problema: incremento della perdita di input

In questo documento vengono elencati i motivi delle riduzioni di input incrementate e viene indicato come verificare se si tratta di questo motivo:

Cadute del controller

Runt, Frame Check Sequence (FCS), interruzioni, overflow FIFO (First Input First Output), cadute POS (Packet Over SDH/SONET) giganti.

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#

Per un'interfaccia ethernet (gige, tengige...), selezionare una delle opzioni seguenti:

mostra stati controller gigabit Ethernet 0/0/0/18

Verificare se nello stato del controller è presente un contatore che aumenta alla stessa velocità del contatore di perdita di input in show interface. Alcuni di questi contatori di errori devono trovarsi anche nell'interfaccia show.

DMAC (Media Access Control Address) o VLAN dot1q di destinazione sconosciuta

Pacchetti con un indirizzo MAC di destinazione, non quello dell'interfaccia, o con una VLAN (Virtual Local Area Network) non corrispondente a una sottointerfaccia. Queste situazioni possono verificarsi in caso di sovraccarico in un dominio L2 con indirizzi MAC unicast sconosciuti, in modo che il router XR connesso a tale dominio L2 riceva i frame con un indirizzo MAC di destinazione che non è uno dei relativi controller. Inoltre, è possibile quando un router Cisco IOS invia pacchetti keepalive ethernet sulla propria interfaccia gige, in modo che incrementino le perdite di input sul router XR in quanto non dispongono dell'indirizzo MAC di destinazione del router XR. Inoltre, quando l'interfaccia è collegata a un altro dispositivo su cui sono configurate più vlan/sottointerfacce dot1q come sul router XR, in modo che il router XR riceva i frame con un tag dot1q sconosciuto.

Su un modulo PLIM (Physical Layer Interface Module) CRS, è possibile trovare tali cadute 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           

Oppure, nelle statistiche dei controller tengige o 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

Nota: esiste l'ID bug Cisco CSCub74803. Input drop other viene incrementato anziché Input drop non valido DMAC almeno sul PLIM fisso a 8 porte del CRS.

Per gli adattatori porte condivise (SPA) (CRS, XR 12000), i pacchetti con MAC non valido verrebbero scartati dalla SPA l2-tcam, quindi è possibile trovare queste perdite nei show controller TenGigE a/b/c/d all:

    Input drop other            = 107

   l2-tcam Invalid DA Drops: 107

Su un ASR 9000, la perdita di input per DMAC non valido e la perdita di input per altri contatori nello stato del controller non vengono incrementati. Quindi il modo per riconoscere queste gocce sull'ASR 9000 è trovare l'NP che gestisce l'interfaccia con le gocce di input:

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#

Si noti che l'interfaccia gig 0/0/30 è gestita da NP 0 su 0/0/CPU0.
Controllare i contatori NP di NP0 su 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#

Quindi L3_NOT_MYMAC nel contatore NP significa che il router ha ricevuto un frame su un'interfaccia di layer 3 con un indirizzo MAC di destinazione che non è una delle interfacce. Il router lo scarta come previsto, e ciò viene segnalato come un calo di input nell'interfaccia show.

Su ASR 9000, per i pacchetti ricevuti con una VLAN dot1q non configurata su una sottointerfaccia di ASR 9000, il contatore Input drop known 802.1Q non viene incrementato in show controller gigabit Ethernet 0/0/0/30. La procedura per l'indirizzo MAC sconosciuto è la stessa di cui sopra: identificare quale indirizzo NP gestisce le interfacce, quindi controllare questo contatore NP. In questo caso, il contatore NP UIDB_TCAM_MISS_AGG_DROP aumenta.

Pacchetti ignorati a causa di un protocollo di livello superiore non riconosciuto

Questo è facile da rilevare come c'è un contatore per queste cadute una linea sotto l'input cadono in 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

Qui potete vedere che tutte le perdite di input sono dovute a un protocollo di livello superiore non riconosciuto.

Ciò significa che i pacchetti sono stati ricevuti con un protocollo Ethernet al quale il router non è interessato. Ciò significa che una funzionalità è configurata sul router adiacente (o su un host connesso al dominio di livello 2 connesso a quell'interfaccia) in modo che invii i frame con un protocollo non configurato sul router XR.

Esempi: 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) ecc...

Quando queste funzionalità non sono configurate sull'interfaccia XR, la casella XR le elimina come previsto. Per individuare il tipo di frame che incrementano questo contatore, è possibile confrontare le funzionalità attivate sul router XR con quelle attivate sul router adiacente (può trattarsi di un router o di uno switch) oppure le funzionalità attivate su tutti i dispositivi connessi ai domini di layer 2 connessi a quell'interfaccia (molto meno facile). Se il router XR è collegato a uno switch, è possibile provare a eseguire un'estensione su tale switch dei pacchetti che invia al router XR sull'interfaccia con perdite di input. 
ASR9000/XR : Interruzione per errore non riconosciuto del protocollo di livello superiore

Batterie NP drops su ASR 9000

I contatori delle perdite nel processo di rete (NP) di ASR 9000 vengono segnalati come perdite di input quando si applicano a un pacchetto ricevuto su un'interfaccia e scartato. Ciò non accade per le cadute del Packet Switch Engine (PSE) sul CRS e sull'XR 12000. Non vengono conteggiati come perdite di input.

Quindi, se si verificano cali di input su un ASR 9000 e questi non corrispondono a uno dei motivi riportati di seguito, eseguire un'operazione show controller np ports all location 0/<x>/CPU0 per trovare l'NP che gestisce l'interfaccia con cali di input, quindi controllare i relativi contatori NP con show contr np<y> location 0/<x>/CPU0.

È possibile reindirizzare l'output per mantenere solo i contatori DROP con un comando come sh contr np counters np<y> posizione 0/<x>/CPU0 | i DROP, ma questo può essere pericoloso come a volte un contatore di caduta non ha DROP nel suo nome. È stato illustrato un buon esempio con L3_NOT_MYMAC. Quindi forse pipe per DROP|DISCARD|NOT|EXCD.

È possibile cancellare i contatori di interfaccia e i contatori NP con i contatori np del controller np<y> posizione 0/<x>/CPU0 all'incirca nello stesso momento per scoprire quale contatore NP incrementa alla stessa velocità con cui scade l'input.

Ad esempio, si ottiene IPV4_PLU_DROP_PKT nei contatori NP, il che significa che la voce CEF/PLU indica che il pacchetto deve essere scartato. Non si dispone di un percorso predefinito e gli elementi non raggiungibili sono disabilitati, quindi i pacchetti che non corrispondono a un percorso più specifico, dove la richiesta al gestore CEF predefinito, è una ricezione.

Se si trova un contatore nella NP che può spiegare le cadute di input con lo stesso incremento di velocità, ma il contatore NP non è molto esplicativo, è possibile navigare in questa pagina per cercare di capire cosa significa il contatore:
ASR9000/XR: risoluzione dei problemi relativi alle perdite di pacchetti e ai contatori di perdite NP

Nota: la pagina di Xander sui forum di supporto contiene i motivi di rilascio per la prima generazione di linecard (Trident), e ci sono nuovi nomi di contatori per la nuova generazione (Typhoon) linecard. In base al nome, è necessario essere in grado di trovare un nome di contatore simile a quello di Trident.

Netio

È possibile raccogliere un show netio idb <int> per ottenere la perdita di input dell'interfaccia e i contatori di perdita del nodo netio:

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>

Le perdite nel nodo MPLS (Multi-Protocol Label Switching) potrebbero essere dovute alla scadenza del valore TTL (Time To Live) di MPLS (in caso di loop o quando il cliente esegue un traceroute) o alla frammentazione richiesta e al bit DF (Do Not Fragment) impostato, ad esempio. È possibile eseguire il comando debug mpls packet drop e debug mpls error insieme alla posizione dell'interfaccia per cercare di capire quale tipo di pacchetto stia incrementando questo contatore.

Pacchetti multicast con punti. Quando si vedono dei pacchetti di rete in drop ma nessun nodo di rete in basso con alcune gocce che potrebbero spiegare i pacchetti in drop, allora questo può essere mcast pacchetti punted, e si può abilitare deb mfib netio drop per capire che tipo di pacchetti