La documentazione per questo prodotto è stata redatta cercando di utilizzare un linguaggio senza pregiudizi. Ai fini di questa documentazione, per linguaggio senza di pregiudizi si intende un linguaggio che non implica discriminazioni basate su età, disabilità, genere, identità razziale, identità etnica, orientamento sessuale, status socioeconomico e intersezionalità. Le eventuali eccezioni possono dipendere dal linguaggio codificato nelle interfacce utente del software del prodotto, dal linguaggio utilizzato nella documentazione RFP o dal linguaggio utilizzato in prodotti di terze parti a cui si fa riferimento. Scopri di più sul modo in cui Cisco utilizza il linguaggio inclusivo.
Cisco ha tradotto questo documento utilizzando una combinazione di tecnologie automatiche e umane per offrire ai nostri utenti in tutto il mondo contenuti di supporto nella propria lingua. Si noti che anche la migliore traduzione automatica non sarà mai accurata come quella fornita da un traduttore professionista. Cisco Systems, Inc. non si assume alcuna responsabilità per l’accuratezza di queste traduzioni e consiglia di consultare sempre il documento originale in inglese (disponibile al link fornito).
In questo documento viene descritto come risolvere i problemi relativi alle perdite di input sull'interfaccia dei router XR.
Nessun requisito specifico previsto per questo documento.
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.
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:
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.
In questo documento vengono elencati i motivi delle riduzioni di input incrementate e viene indicato come verificare se si tratta di questo motivo:
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.
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.
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
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.
È 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
Revisione | Data di pubblicazione | Commenti |
---|---|---|
2.0 |
12-Jul-2023 |
Titolo aggiornato, introduzione, requisiti di branding, traduzione automatica, requisiti di stile, grammatica e formattazione. |
1.0 |
04-Jan-2019 |
Versione iniziale |