Risoluzione dei problemi relativi ai percorsi dei dati di ASR serie 9000 Punt Fabric

Introduzione

Questo documento descrive i messaggi di errore del percorso dati di punt fabric rilevati durante il funzionamento di Cisco Aggregation Services Router (ASR) serie 9000.

Il messaggio viene visualizzato nel formato seguente:

RP/0/RSP0/CPU0:Sep  3 13:49:36.595 UTC: pfm_node_rp[358]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED: Set|online_diag_rsp[241782]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP)
failed: (0/7/CPU0, 1) (0/7/CPU0, 2) (0/7/CPU0, 3) (0/7/CPU0, 4) (0/7/CPU0, 5)
(0/7/CPU0, 6) (0/7/CPU0, 7)

Questo documento è destinato a chiunque desideri comprendere il messaggio di errore e le azioni da eseguire in caso di problemi.

Prerequisiti

Requisiti

Cisco raccomanda una conoscenza di alto livello dei seguenti argomenti:

• Schede di linea ASR 9000
• Schede fabric
• Processori di routing
• Architettura dello chassis

Tuttavia, questo documento non richiede che i lettori abbiano familiarità con i dettagli hardware. Prima di spiegare il messaggio di errore, vengono fornite le informazioni preliminari necessarie. Questo documento descrive l'errore sia sulle schede di linea basate su Trident che su Typhoon. Per una spiegazione dei termini, vedere Descrizione dei tipi di schede di linea ASR serie 9000.

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

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.

Modalità d'uso del documento

Prendere in considerazione i suggerimenti riportati di seguito su come utilizzare questo documento per ottenere informazioni essenziali e come guida di riferimento per la risoluzione dei problemi:

• Quando non vi è urgenza di eseguire il root causa un errore nel percorso dei dati di un'infrastruttura punt, leggere tutte le sezioni di questo documento. In questo documento viene creato lo sfondo necessario per isolare un componente difettoso quando si verifica un errore di questo tipo.
• Utilizzare la sezione FAQ se si ha in mente una domanda specifica per la quale è necessaria una risposta rapida. Se la domanda non è inclusa nella sezione Domande frequenti, verificare che il documento principale risponda alla domanda.
• Utilizzare tutte le sezioni da Analizza errori (Analyze Faults) in modo da isolare il problema in un componente guasto quando si verifica un errore in un router o per controllare se si tratta di un problema noto.

Premesse

Un pacchetto può attraversare due o tre hop nel fabric dello switch in base al tipo di scheda di linea. Le schede di linea per la generazione di tifoni aggiungono un elemento supplementare per la struttura dello switch, mentre le schede di linea basate su Trident spostano tutto il traffico con la struttura solo sulla scheda del processore di routing. Questi diagrammi mostrano gli elementi fabric per entrambi questi tipi di schede di linea, nonché la connettività fabric alla scheda del processore di routing:

Percorso pacchetto diagnostico fabric Punt

L'applicazione di diagnostica in esecuzione sulla CPU della scheda del processore di routing inserisce periodicamente i pacchetti di diagnostica destinati a ogni processore di rete (NP). Il pacchetto diagnostico viene rimandato indietro all'interno dell'NP e reiniettato verso la CPU della scheda del processore di routing da cui proviene il pacchetto. Questo controllo periodico dello stato di ogni NP con un pacchetto univoco per NP da parte dell'applicazione diagnostica sulla scheda del processore di routing fornisce un avviso per eventuali errori funzionali sul percorso dati durante il funzionamento del router. È essenziale notare che l'applicazione diagnostica sia sul processore di routing attivo che su quello in standby immette periodicamente un pacchetto per ogni singolo NP e mantiene un conteggio di operazioni riuscite o non riuscite per singolo NP. Quando viene raggiunta una soglia di pacchetti diagnostici ignorati, l'applicazione genera un errore.

Vista concettuale del percorso di diagnostica

Prima che il documento descriva il percorso diagnostico sulle schede di linea basate su Trident e Typhoon, questa sezione fornisce una descrizione generale del percorso diagnostico della struttura dalle schede del processore di routing attive e in standby verso la scheda di linea NP.

Percorso del pacchetto tra la scheda del processore di routing attiva e la scheda di linea

I pacchetti diagnostici iniettati dal processore di routing attivo nel fabric verso l'NP vengono trattati come pacchetti unicast dal fabric dello switch. Con i pacchetti unicast, il fabric dello switch sceglie il collegamento in uscita in base al carico del traffico corrente del collegamento, che contribuisce a sottoporre i pacchetti diagnostici al carico del traffico sul router. Quando sono presenti più collegamenti in uscita verso l'NP, l'ASIC del fabric dello switch sceglie un collegamento che attualmente è il meno caricato.

In questo diagramma viene illustrato il percorso del pacchetto diagnostico originato dal processore di routing attivo.

Nota: il primo collegamento che connette l'ASIC (Fabric Interface) sulla scheda di linea al Crossbar (XBAR) sulla scheda del processore di routing viene scelto continuamente per i pacchetti destinati all'NP. I pacchetti di risposta dall'NP sono soggetti a un algoritmo di distribuzione del carico di collegamento (se la scheda di linea è basata su Typhoon). Ciò significa che il pacchetto di risposta dalla rete PDN al processore di routing attivo può scegliere uno dei collegamenti di infrastruttura che connettono le schede di linea alla scheda del processore di routing in base al carico del collegamento di infrastruttura.

Percorso del pacchetto tra la scheda del processore del percorso di standby e la scheda di linea

I pacchetti diagnostici iniettati dal processore di routing di standby nel fabric verso l'NP vengono trattati come pacchetti multicast dal fabric dello switch. Sebbene si tratti di un pacchetto multicast, non è presente alcuna replica all'interno della struttura. Ogni pacchetto diagnostico proveniente dal processore di routing di standby raggiunge ancora un NP alla volta. Il pacchetto di risposta dall'indirizzo IPv4 al processore di routing è anche un pacchetto multicast sulla struttura senza replica. Pertanto, l'applicazione diagnostica sul processore di routing in standby riceve un singolo pacchetto di risposta dal pacchetto NPS, un pacchetto alla volta. L'applicazione diagnostica tiene traccia di ogni NP nel sistema, perché inserisce un pacchetto per ogni NP, e si aspetta risposte da ogni NP, un pacchetto alla volta. Con un pacchetto multicast, il fabric dello switch sceglie il collegamento in uscita in base a un valore del campo nell'intestazione del pacchetto, che contribuisce a iniettare pacchetti diagnostici su ogni collegamento del fabric tra la scheda del processore di routing e la scheda di linea. Il processore di routing di standby tiene traccia dello stato NP su ogni collegamento di struttura che si connette tra la scheda del processore di routing e lo slot della scheda di linea.

Il diagramma precedente mostra il percorso del pacchetto diagnostico originato dal processore del percorso di standby. A differenza del caso del processore di routing attivo, tutti i collegamenti che collegano la scheda di linea alla XBAR sul processore di routing vengono eseguiti. I pacchetti di risposta provenienti da NP prendono lo stesso collegamento di fabric utilizzato dal pacchetto nel processore di routing verso la direzione della scheda di linea. Questo test assicura che tutti i collegamenti che connettono il processore del percorso di standby alla scheda di linea siano monitorati continuamente.

Percorso pacchetto diagnostico fabric Punt su scheda di linea basata su Trident

In questo diagramma vengono illustrati i pacchetti diagnostici originati dal processore di routing destinati a un NP di cui viene eseguito il loop verso il processore di routing. È importante notare i collegamenti ai percorsi dati e gli ASIC comuni a tutti gli NP, nonché i collegamenti e i componenti specifici di un sottoinsieme di NP. Ad esempio, il Bridge ASIC 0 (B0) è comune a NP0 e NP1, mentre FIA0 è comune a tutti gli NP. Sul lato del processore di routing, tutti i collegamenti, gli ASIC del percorso dei dati e l'FPGA (Field-Programmable Gate Array) sono comuni a tutte le schede di linea e quindi a tutti gli NP in uno chassis.

Percorso del pacchetto diagnostico della struttura di punt sulla scheda di linea basata su tifone

In questo diagramma vengono illustrati i pacchetti diagnostici originati da scheda del processore di routing destinati a un NP che viene restituito al processore di routing. È importante notare i collegamenti ai percorsi dati e gli ASIC comuni a tutti gli NP, nonché i collegamenti e i componenti specifici di un sottoinsieme di NP. Ad esempio, FIA0 è comune a NP0 e NP1. Sul lato della scheda del processore di routing, tutti i collegamenti, gli ASIC del percorso dei dati e l'FGPA sono comuni a tutte le schede di linea e quindi a tutti gli NP in uno chassis.

Percorso del pacchetto diagnostico di Punt Fabric sulla scheda di linea basata su Tomahawk, Lightspeed e Lightspeed Plus

Sulle schede di linea Tomahawk c'è una connettività 1:1 tra la FIA e la NP.

Sulle schede di linea Lightspeed e Lightspeed Plus la FIA è integrata nel chip NP.

Nelle sezioni seguenti viene illustrato il percorso del pacchetto verso ogni NP. Questa operazione è necessaria per comprendere il messaggio di errore del percorso dei dati della struttura punt e per individuare il punto di errore.

Segnalazione errori e allarmi diagnostici su fabric Punt

L'impossibilità di ricevere risposte da un NP in un router basato su ASR 9000 genera un allarme. La decisione di attivare un allarme da parte dell'applicazione diagnostica online eseguita sul processore di routing si verifica quando si verificano tre errori consecutivi. L'applicazione diagnostica mantiene una finestra di errore di tre pacchetti per ogni NP. Il processore di routing attivo e il processore di routing in standby eseguono la diagnosi in modo indipendente e in parallelo. L'errore potrebbe essere segnalato dal processore di routing attivo, dal processore di routing in standby o da entrambe le schede del processore di routing. La posizione del guasto e la perdita del pacchetto determinano quale processore di routing ha segnalato l'allarme.

La frequenza predefinita del pacchetto di diagnostica verso ogni NP è di un pacchetto ogni 60 secondi o di uno al minuto.

Di seguito è riportato il formato del messaggio di allarme:

RP/0/RSP0/CPU0:Sep  3 13:49:36.595 UTC: pfm_node_rp[358]: 
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED: Set|online_diag_rsp[241782]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP)
failed: (0/7/CPU0, 1) (0/7/CPU0, 2) (0/7/CPU0, 3) (0/7/CPU0, 4) (0/7/CPU0, 5)
(0/7/CPU0, 6) (0/7/CPU0, 7)

Il messaggio mostra un errore nel raggiungere NP 1, 2, 3, 4, 5, 6 e 7 sulla scheda di linea 0/7/cpu0 dal processore di routing 0/rsp0/cpu0.

Dall'elenco dei test di diagnostica online, è possibile visualizzare gli attributi del test di loopback dell'infrastruttura punt con questo comando:

RP/0/RSP0/CPU0:iox(admin)#show diagnostic content location 0/RSP0/CPU0


RP 0/RSP0/CPU0:

  Diagnostics test suite attributes:
    M/C/* - Minimal bootup level test / Complete bootup level test / NA
    B/O/* - Basic ondemand test / not Ondemand test / NA
    P/V/* - Per port test / Per device test / NA
    D/N/* - Disruptive test / Non-disruptive test / NA
      S/* - Only applicable to standby unit / NA
      X/* - Not a health monitoring test / NA
      F/* - Fixed monitoring interval test / NA
      E/* - Always enabled monitoring test / NA
      A/I - Monitoring is active / Monitoring is inactive
                                                         Test Interval   Thre-  
 ID   Test Name                          Attributes     (day hh:mm:ss.ms shold)
  ==== ================================== ============ ================= =====
    1) PuntFPGAScratchRegister ---------- *B*N****A       000 00:01:00.000 1
    2) FIAScratchRegister --------------- *B*N****A       000 00:01:00.000 1
    3) ClkCtrlScratchRegister ----------- *B*N****A       000 00:01:00.000 1
    4) IntCtrlScratchRegister ----------- *B*N****A       000 00:01:00.000 1
    5) CPUCtrlScratchRegister ----------- *B*N****A       000 00:01:00.000 1
    6) FabSwitchIdRegister -------------- *B*N****A       000 00:01:00.000 1
    7) EccSbeTest ----------------------- *B*N****I       000 00:01:00.000 3
    8) SrspStandbyEobcHeartbeat --------- *B*NS***A       000 00:00:05.000 3
    9) SrspActiveEobcHeartbeat ---------- *B*NS***A       000 00:00:05.000 3
   10) FabricLoopback ------------------- MB*N****A       000 00:01:00.000 3
   11) PuntFabricDataPath --------------- *B*N****A       000 00:01:00.000 3
   12) FPDimageVerify ------------------- *B*N****I       001 00:00:00.000 1

RP/0/RSP0/CPU0:ios(admin)#

L'output mostra che la frequenza di test di PuntFabricDataPath è di un pacchetto al minuto e la soglia di errore è di tre, il che implica che la perdita di tre pacchetti consecutivi non è tollerata e genera un allarme. Gli attributi di test mostrati sono valori predefiniti. Per modificare le impostazioni predefinite, immettere il diagnostic monitor interval e diagnostic monitor threshold comandi nella modalità di configurazione amministrazione.

Percorso Pacchetto Diagnostico Scheda Di Linea Basato Su Trident

Errore diagnostico NP0

Percorso diagnostico fabric

Questo diagramma mostra il percorso del pacchetto tra la CPU del processore di routing e la scheda di linea NP0. Il collegamento che collega B0 e NP0 è l'unico collegamento specifico di NP0. Tutti gli altri collegamenti rientrano nel percorso comune.

Prendere nota del percorso del pacchetto dal processore di routing verso NP0. Sebbene esistano quattro collegamenti da utilizzare per i pacchetti destinati a NP0 dal processore di routing, il primo collegamento tra il processore di routing e lo slot della scheda di linea viene utilizzato per il pacchetto dal processore di routing alla scheda di linea. Il pacchetto restituito da NP0 può essere restituito al processore di routing attivo su uno dei due percorsi di collegamento del fabric tra lo slot della scheda di linea e il processore di routing attivo. La scelta di uno dei due collegamenti da utilizzare dipende dal carico del collegamento in quel momento. Il pacchetto di risposta da NP0 al processore di routing in standby utilizza entrambi i collegamenti, ma un collegamento alla volta. La scelta del collegamento si basa sul campo di intestazione che viene popolato dall'applicazione diagnostica.

Analisi degli errori di diagnostica NP0

Scenario di errore singolo

Se viene rilevato un singolo allarme di errore del percorso dati PFM (Platform Fault Manager) con solo NP0 nel messaggio di errore, l'errore si verifica solo sul percorso di struttura che collega il processore di routing e la scheda di linea NP0. Questo è un singolo errore. Se il guasto viene rilevato su più di un NP, fare riferimento alla sezione Scenario di più guasti.

RP/0/RSP0/CPU0:Sep  3 13:49:36.595 UTC: pfm_node_rp[358]: 
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED: Set|online_diag_rsp[241782]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP)
failed: (0/7/CPU0, 0)

Nota: questa sezione del documento si applica a tutti gli slot per schede di linea in uno chassis, indipendentemente dal tipo di chassis. Pertanto, questo può essere applicato a tutti gli slot per schede di linea.

Come illustrato nel precedente diagramma del percorso dei dati, l'errore deve trovarsi in una o più delle seguenti posizioni:

• Collegamento che collega NP0 e B0
• Code interne B0 dirette verso NP0
• Interno NP0

Scenario con più errori

Più errori NP

Quando si osservano altri guasti su NP0 o l'errore PUNT_FABRIC_DATA_PATH_FAILED viene segnalato anche da altri NP sulla stessa scheda di linea, l'isolamento degli errori viene eseguito mettendo in correlazione tutti gli errori. Ad esempio, se l'errore PUNT_FABRIC_DATA_PATH_FAILED e l'errore LC_NP_LOOPBACK_FAILED si verificano entrambi su NP0, NP ha interrotto l'elaborazione dei pacchetti. Per comprendere l'errore di loopback, consultare la sezione Percorso diagnostico di loopback NP. Ciò potrebbe essere una prima indicazione di un guasto critico all'interno di NP0. Tuttavia, se si verifica solo uno dei due guasti, l'errore viene localizzato sul percorso dati della struttura punt o sulla CPU della scheda di linea sul percorso NP.

Se più di un NP su una scheda di linea ha un errore del percorso dati di un'infrastruttura punt, è necessario procedere lungo il percorso della struttura dei collegamenti dell'infrastruttura per isolare un componente difettoso. Ad esempio, se sia NP0 che NP1 hanno un guasto, il guasto deve essere in B0 o nel collegamento che collega B0 e FIA0. È meno probabile che sia NP0 che NP1 incontrino contemporaneamente un errore critico interno. Anche se è meno probabile, NP0 e NP1 possono riscontrare un errore critico dovuto all'elaborazione errata di un particolare tipo di pacchetto o di un pacchetto errato.

Entrambe le schede del processore di routing segnalano un errore

Se entrambe le schede del processore di routing attive e in standby segnalano un guasto a uno o più NP su una scheda di linea, controllare tutti i collegamenti e i componenti comuni nel percorso dati tra gli NP interessati e le schede del processore di routing.

Errore di diagnostica NP1

Questo diagramma mostra il percorso del pacchetto tra la CPU della scheda del processore di routing e la scheda di linea NP1. Il collegamento che collega Bridge ASIC 0 (B0) e NP1 è l'unico collegamento specifico di NP1. Tutti gli altri collegamenti rientrano nel percorso comune.

Prendere nota del percorso della scheda del processore di routing verso NP1. Sebbene esistano quattro collegamenti da utilizzare per i pacchetti destinati a NP0 dal processore di routing, il primo collegamento tra il processore di routing e lo slot della scheda di linea viene utilizzato per il pacchetto dal processore di routing alla scheda di linea. Il pacchetto restituito da NP1 può essere restituito al processore di routing attivo tramite uno dei due percorsi di collegamento di struttura tra lo slot della scheda di linea e il processore di routing attivo. La scelta di uno dei due collegamenti da utilizzare dipende dal carico del collegamento in quel momento. Il pacchetto di risposta da NP1 verso il processore di routing in standby utilizza entrambi i collegamenti, ma un collegamento alla volta. La scelta del collegamento si basa sul campo di intestazione che viene popolato dall'applicazione diagnostica.

Percorso diagnostico fabric

Analisi degli errori di diagnostica NP1

Fare riferimento alla sezione Analisi diagnostica dei guasti NP0, ma applicare lo stesso ragionamento per NP1 (anziché NP0).

Errore di diagnostica NP2

Questo diagramma mostra il percorso del pacchetto tra la CPU della scheda del processore di routing e la scheda di linea NP2. Il collegamento che collega B1 e NP2 è l'unico collegamento specifico di NP2. Tutti gli altri collegamenti rientrano nel percorso comune.

Prendere nota del percorso della scheda del processore di routing verso NP2. Sebbene esistano quattro collegamenti da utilizzare per i pacchetti destinati a NP2 dal processore di routing, il primo collegamento tra il processore di routing e lo slot della scheda di linea viene utilizzato per il pacchetto dal processore di routing alla scheda di linea. Il pacchetto restituito da NP2 può essere restituito al processore di routing attivo tramite uno dei due percorsi di collegamento di struttura tra lo slot della scheda di linea e il processore di routing attivo. La scelta di uno dei due collegamenti da utilizzare dipende dal carico del collegamento in quel momento. Il pacchetto di risposta da NP2 al processore di routing in standby utilizza entrambi i collegamenti, ma un collegamento alla volta. La scelta del collegamento si basa sul campo di intestazione che viene popolato dall'applicazione diagnostica.

Percorso diagnostico fabric

Analisi degli errori di diagnostica NP2

Fare riferimento alla sezione Analisi diagnostica dei guasti NP0, ma applicare lo stesso ragionamento per NP2 (anziché NP0).

Errore di diagnostica NP3

Il diagramma mostra il percorso del pacchetto tra la CPU della scheda del processore di routing e la scheda di linea NP3. Il collegamento che collega Bridge ASIC 1 (B1) e NP3 è l'unico collegamento specifico di NP3. Tutti gli altri collegamenti rientrano nel percorso comune.

Prendere nota del percorso della scheda del processore di routing verso NP3. Sebbene esistano quattro collegamenti da utilizzare per i pacchetti destinati all'NP3 dal processore di routing, il primo collegamento tra il processore di routing e lo slot della scheda di linea viene utilizzato per il pacchetto dal processore di routing alla scheda di linea. Il pacchetto restituito dall'NP3 può essere restituito al processore di routing attivo su uno dei due percorsi di collegamento del fabric tra lo slot della scheda di linea e il processore di routing attivo. La scelta di uno dei due collegamenti da utilizzare dipende dal carico del collegamento in quel momento. Il pacchetto di risposta dall'NP3 al processore di routing in standby utilizza entrambi i collegamenti, ma un collegamento alla volta. La scelta del collegamento si basa sul campo di intestazione che viene popolato dall'applicazione diagnostica.

Percorso diagnostico fabric

Analisi degli errori di diagnostica NP3

Fare riferimento alla sezione Analisi diagnostica dei guasti NP0, ma applicare lo stesso ragionamento per NP3 (anziché NP0).

Percorso pacchetto diagnostico scheda di linea basata sul tifone

In questa sezione vengono forniti due esempi per stabilire lo sfondo per i pacchetti fabric punt con schede di linea basate su Typhoon. Il primo esempio utilizza NP1, mentre il secondo utilizza NP3. La descrizione e l'analisi possono essere estese ad altri NP su qualsiasi scheda di linea basata sul tifone.

Errore diagnostico Typhoon NP1

Il diagramma successivo mostra il percorso del pacchetto tra la CPU della scheda del processore di routing e la scheda di linea NP1. Il collegamento che collega FIA0 e NP1 è l'unico collegamento specifico del percorso NP1. Tutti gli altri collegamenti tra lo slot della scheda di linea e lo slot della scheda del processore di routing rientrano nel percorso comune. I collegamenti che collegano l'ASIC XBAR fabric sulla scheda di linea alle FIA sulla scheda di linea sono specifici di un sottoinsieme di NP. Ad esempio, entrambi i collegamenti tra FIA0 e il fabric locale XBAR ASIC sulla scheda di linea vengono utilizzati per il traffico verso NP1.

Prendere nota del percorso della scheda del processore di routing verso NP1. Sebbene esistano otto collegamenti da utilizzare per i pacchetti destinati a NP1 dalla scheda del processore di routing, viene utilizzato un unico percorso tra la scheda del processore di routing e lo slot della scheda di linea. Il pacchetto restituito da NP1 può essere restituito alla scheda del processore di routing su otto percorsi di collegamento tra lo slot della scheda di linea e il processore di routing. Ognuno di questi otto collegamenti viene eseguito uno alla volta quando il pacchetto diagnostico viene reindirizzato alla CPU della scheda del processore di routing.

Percorso diagnostico fabric

Errore diagnostico di Typhoon NP3

Il diagramma mostra il percorso del pacchetto tra la CPU della scheda del processore di routing e la scheda di linea NP3. Il collegamento che collega FIA1 e NP3 è l'unico specifico del percorso NP3. Tutti gli altri collegamenti tra lo slot della scheda di linea e lo slot della scheda del processore di routing rientrano nel percorso comune. I collegamenti che collegano l'ASIC XBAR fabric sulla scheda di linea alle FIA sulla scheda di linea sono specifici di un sottoinsieme di NP. Ad esempio, entrambi i collegamenti tra FIA1 e il fabric locale XBAR ASIC sulla scheda di linea sono utilizzati per il traffico verso NP3.

Prendere nota del percorso della scheda del processore di routing verso NP3. Sebbene esistano otto collegamenti da utilizzare per i pacchetti destinati all'NP3 dalla scheda del processore di routing, viene utilizzato un unico percorso tra la scheda del processore di routing e lo slot della scheda di linea. Il pacchetto restituito da NP1 può essere restituito alla scheda del processore di routing su otto percorsi di collegamento tra lo slot della scheda di linea e il processore di routing. Ognuno di questi otto collegamenti viene eseguito uno alla volta quando il pacchetto diagnostico viene reindirizzato alla CPU della scheda del processore di routing.

Percorso diagnostico fabric

Percorso Pacchetto Diagnostico Scheda Di Linea Basato Su Tomahawk

A causa della connettività 1:1 tra la FIA e la NP, l'unico traffico che attraversa la FIA0 è verso/da NP0.

Percorso pacchetto diagnostico della scheda di linea basata su Lightspeed e Lightspeed Plus

Poiché la FIA è integrata nel chip NP, l'unico traffico che attraversa FIA0 è diretto/proveniente da NP0.

Errori di analisi

In questa sezione gli errori vengono suddivisi in casi difficili e transitori e vengono elencati i passaggi utilizzati per determinare se si tratta di un errore difficile o transitorio. Una volta determinato il tipo di errore, il documento specifica i comandi che possono essere eseguiti sul router per comprendere la causa del guasto e le azioni correttive da intraprendere.

Errore temporaneo

Se un messaggio PFM impostato è seguito da un messaggio PFM non crittografato, si è verificato un errore e il router ha risolto il problema. I guasti temporanei possono verificarsi a causa di condizioni ambientali e guasti ripristinabili nei componenti hardware. A volte può essere difficile associare guasti temporanei a un evento particolare.

Di seguito è riportato un esempio di guasto temporaneo del fabric per motivi di chiarezza:

RP/0/RSP0/CPU0:Feb  5 05:05:44.051 : pfm_node_rp[354]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Set|online_diag_rsp[237686]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP)
failed: (0/2/CPU0, 0)  

RP/0/RSP0/CPU0:Feb  5 05:05:46.051 : pfm_node_rp[354]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Clear|online_diag_rsp[237686]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP)
failed: (0/2/CPU0, 0) 

Azioni correttive temporanee degli errori

L'approccio suggerito per gli errori temporanei consiste nel monitorare solo l'eventuale presenza di tali errori. Se un guasto temporaneo si verifica più di una volta, trattare l'errore temporaneo come un guasto grave e utilizzare i suggerimenti e le operazioni per analizzare tali guasti descritti nella sezione successiva.

Errore grave

Se un messaggio PFM impostato non è seguito da un messaggio PFM chiaro, si è verificato un errore e il router non ha corretto l'errore stesso mediante il codice di gestione degli errori oppure la natura dell'errore hardware non può essere ripristinata. Gli errori hardware possono verificarsi a causa di condizioni ambientali e di errori irreversibili dei componenti hardware. L'approccio suggerito per i guasti gravi consiste nell'utilizzare le linee guida indicate nella sezione Analisi dei guasti gravi.

Un esempio di errore dell'hard fabric è elencato qui per chiarezza. Per questo messaggio di esempio non esiste un messaggio PFM non crittografato corrispondente.

RP/0/RSP0/CPU0:Feb  5 05:05:44.051 : pfm_node_rp[354]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Set|online_diag_rsp[237686]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP)
failed: (0/2/CPU0, 0)

Azioni correttive per errori gravi

In uno scenario di errore hardware, raccogliere tutti i comandi menzionati nella sezione Dati da raccogliere prima della creazione della richiesta di servizio e aprire una richiesta di servizio. In casi urgenti, dopo aver raccolto tutti i risultati del comando di risoluzione dei problemi, avviare una scheda del processore di routing o un ricaricamento della scheda di linea in base all'isolamento del guasto. Dopo il ricaricamento, se l'errore non viene recuperato, avviare un'autorizzazione restituzione materiale (RMA).

Analisi errori temporanei

Completare questi passaggi per analizzare gli errori temporanei.

1. Immettere il show logging | inc “PUNT_FABRIC_DATA_PATH" per verificare se l'errore si è verificato una o più volte.
   
   
2. Immettere il show pfm location all per determinare lo stato corrente (SET o CLEAR). L'errore è in sospeso o cancellato? Se lo stato dell'errore cambia tra SET e CLEAR, si verificano ripetutamente uno o più errori all'interno del percorso dei dati dell'infrastruttura che vengono corretti dal software o dall'hardware.
   
   
3. Eseguire il provisioning di trap SNMP (Simple Network Management Protocol) o eseguire uno script che raccoglie show pfm location all , e ricerca periodicamente la stringa di errore per monitorare la ricorrenza futura dell'errore (quando l'ultimo stato dell'errore è CLEAR e non si verificano nuovi errori).

Comandi da utilizzare

Immettere questi comandi per analizzare gli errori temporanei:

• show logging | inc “PUNT_FABRIC_DATA_PATH”
• show pfm location all

Analizza errori hardware

Se si visualizzano i collegamenti del percorso dei dati della struttura su una scheda di linea come una struttura (dove i dettagli sono descritti nella sezione Informazioni di base), è necessario dedurre, in base al punto di errore, se uno o più NP sono inaccessibili. Se si verificano più errori su più NP, utilizzare i comandi elencati in questa sezione per analizzare gli errori.

Comandi da utilizzare

Immettere questi comandi per analizzare gli errori hardware:

• show logging | inc “PUNT_FABRIC_DATA_PATH”
  L'output potrebbe contenere uno o più NP (ad esempio: NP2, NP3).
  
  
• show controller fabric fia link-status location
  Dal momento che sia NP2 che NP3 (nella sezione Typhoon NP3 Diagnostic Failure) ricevono e inviano attraverso una singola FIA, è ragionevole dedurre che il guasto è in una FIA associata sul percorso.
  
  
• show controller fabric crossbar link-status instance <0 and 1> location
  Se tutti gli NP sulla scheda di linea non sono raggiungibili per l'applicazione diagnostica, è ragionevole dedurre che i collegamenti che collegano lo slot della scheda di linea alla scheda del processore di routing potrebbero avere un errore su uno degli ASIC che inoltrano il traffico tra la scheda del processore di routing e la scheda di linea.
  
  show controller fabric crossbar link-status instance 0 location
show controller fabric crossbar link-status instance 0 location 0/rsp0/cpu0
show controller fabric crossbar link-status instance 1 location 0/rsp0/cpu0
show controller fabric crossbar link-status instance 0 location 0/rsp1/cpu0
show controller fabric crossbar link-status instance 1 location 0/rsp1/cpu0
  
  
• show controller fabric fia link-status location 0/rsp*/cpu0
show controller fabric fia link-status location 0/rsp0/cpu0
show controller fabric fia link-status location 0/rsp1/cpu0
  
  
• show controller fabric fia bridge sync-status location 0/rsp*/cpu0
show controller fabric fia bridge sync-status location 0/rsp0/cpu0
show controller fabric fia bridge sync-status location 0/rsp1/cpu0
show tech fabric terminal


Nota: se tutti gli NP su tutte le schede di linea segnalano un guasto, il guasto è molto probabile sulla scheda del processore di routing (scheda del processore di routing attiva o scheda del processore di routing in standby). Fare riferimento al collegamento che collega la CPU della scheda del processore di routing alla FPGA e alla scheda del processore di routing FIA nella sezione Informazioni di base.

Errori passati

Storicamente, il 99% degli errori è recuperabile e, nella maggior parte dei casi, l'azione di ripristino avviata dal software corregge gli errori. Tuttavia, in casi molto rari, si osservano errori irreversibili che possono essere risolti solo con l'autorizzazione al reso (RMA) delle schede.

Nelle sezioni seguenti vengono identificati alcuni errori riscontrati in passato per fungere da guida nel caso in cui vengano rilevati errori simili.

Errore temporaneo dovuto a sovrascrittura NP

Questi messaggi vengono visualizzati se l'errore è dovuto a una sottoscrizione eccessiva di NP.

RP/0/RP1/CPU0:Jun 26 13:08:28.669 : pfm_node_rp[349]:
 %PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Set|online_diag_rsp[200823]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP)
failed: (0/10/CPU0, 0)

RP/0/RP1/CPU0:Jun 26 13:09:28.692 : pfm_node_rp[349]:
%PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Clear|online_diag_rsp[200823]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP)
failed: (0/10/CPU0,0)

I guasti temporanei possono essere più difficili da confermare. Un metodo per determinare se un NP è attualmente sovrascritto o è stato sovrascritto in passato è quello di controllare un certo tipo di goccia all'interno dell'NP e per le gocce di coda nella FIA. Le cadute in ingresso dell'IFDMA (Front Direct Memory Access) all'interno del NP si verificano quando il NP è sovrascritto e non è in grado di tenere il passo con il traffico in entrata. Le cadute di coda FIA si verificano quando un NP in uscita asserisce il controllo del flusso (chiede alla scheda di linea in entrata di inviare meno traffico). Nello scenario di controllo del flusso, la FIA in entrata presenta cali di coda.

Di seguito è riportato un esempio:

RP/0/RSP0/CPU0:RP/0/RSP0/CPU0:ASR9006-C#show controllers np counters all
Wed Feb 19 13:10:11.848 EST

Node: 0/1/CPU0:
----------------------------------------------------------------
Show global stats counters for NP0, revision v3

Read 93 non-zero NP counters:
Offset Counter                             FrameValue     Rate (pps)
-----------------------------------------------------------------------
 22 PARSE_ENET_RECEIVE_CNT                 46913080435     118335
 23 PARSE_FABRIC_RECEIVE_CNT               40175773071     5
 24 PARSE_LOOPBACK_RECEIVE_CNT             5198971143966   0
<SNIP>

Show special stats counters for NP0, revision v3

Offset Counter                                CounterValue
----------------------------------------------------------------------------
524032 IFDMA discard stats counters 0         8008746088           0   <<<<<

Di seguito è riportato un esempio:

RP/0/RSP0/CPU0:ASR9006-C#show controllers fabric fia drops ingress location 0/1/cPU0
Wed Feb 19 13:37:27.159 EST

********** FIA-0 **********
Category: in_drop-0
 DDR Rx FIFO-0 0
 DDR Rx FIFO-1 0
 Tail Drop-0 0   <<<<<<<
 Tail Drop-1 0   <<<<<<<
 Tail Drop-2 0   <<<<<<<
 Tail Drop-3 0   <<<<<<<
 Tail Drop DE-0 0
 Tail Drop DE-1 0
 Tail Drop DE-2 0
 Tail Drop DE-3 0
 Hard Drop-0 0
 Hard Drop-1 0
 Hard Drop-2 0
 Hard Drop-3 0
 Hard Drop DE-0 0
 Hard Drop DE-1 0
 Hard Drop DE-2 0
 Hard Drop DE-3 0
 WRED Drop-0 0
 WRED Drop-1 0
 WRED Drop-2 0
 WRED Drop-3 0
 WRED Drop DE-0 0
 WRED Drop DE-1 0
 WRED Drop DE-2 0
 WRED Drop DE-3 0
 Mc No Rep 0

Errore irreversibile dovuto a reimpostazione rapida NP

Quando si verifica PUNT_FABRIC_DATA_PATH_FAILED e l'errore è dovuto a reimpostazione rapida NP, per una scheda di linea basata su tifone vengono visualizzati log simili a quelli elencati. Il meccanismo di monitoraggio dello stato è disponibile sulle schede di linea basate sul tifone, ma non su quelle basate su Trident.

LC/0/2/CPU0:Aug 26 12:09:15.784 CEST: prm_server_ty[303]:
prm_inject_health_mon_pkt : Error injecting health packet for NP0
status = 0x80001702

LC/0/2/CPU0:Aug 26 12:09:18.798 CEST: prm_server_ty[303]:
prm_inject_health_mon_pkt : Error injecting health packet for NP0
status = 0x80001702

LC/0/2/CPU0:Aug 26 12:09:21.812 CEST: prm_server_ty[303]:
prm_inject_health_mon_pkt : Error injecting health packet for NP0
status = 0x80001702

LC/0/2/CPU0:Aug 26 12:09:24.815 CEST:
prm_server_ty[303]: NP-DIAG health monitoring failure on NP0

LC/0/2/CPU0:Aug 26 12:09:24.815 CEST: pfm_node_lc[291]:
%PLATFORM-NP-0-NP_DIAG : Set|prm_server_ty[172112]|
Network Processor Unit(0x1008000)| NP diagnostics warning on NP0.

LC/0/2/CPU0:Aug 26 12:09:40.492 CEST: prm_server_ty[303]:
Starting  fast reset for NP 0 LC/0/2/CPU0:Aug 26 12:09:40.524 CEST:
prm_server_ty[303]: Fast Reset NP0  - successful auto-recovery of NP

Per le schede di linea basate su Trident, questo registro viene visualizzato con un reset rapido di un NP:

LC/0/1/CPU0:Mar 29 15:27:43.787 test:
pfm_node_lc[279]: Fast Reset initiated on NP3

Errori tra i processori di routing RSP440 e le schede di linea Typhon

Cisco ha risolto un problema per cui raramente i collegamenti fabric tra Route Switch Processor (RSP) 440 e le schede di linea basate su tifone sul backplane vengono riformati. I collegamenti fabric vengono riaddestrati perché la potenza del segnale non è ottimale. Questo problema è presente nel software Cisco IOS^® XR base versioni 4.2.1, 4.2.2, 4.2.3, 4.3.0, 4.3.1 e 4.3.2. Un aggiornamento della manutenzione software (SMU) per ciascuna di queste versioni è disponibile su Cisco Connection Online e viene registrato con l'ID bug Cisco CSCuj10837 e l'ID bug Cisco CSCul39674.

Quando il problema si verifica sul router, può verificarsi uno dei seguenti scenari:

1. Il collegamento si interrompe e viene visualizzato. (Transitorio)
2. Il collegamento viene interrotto in modo permanente.

Cisco ID bug CSCuj10837 - Ritiro del fabric tra RSP e LC (direzione TX)

Per confermare, raccogliere gli output di ltrace da LC e da entrambi gli RSP (show controller fabric crossbar ltrace location <>) e verificare se l'output viene visualizzato nelle tracce RSP:

SMU è già disponibile

Di seguito è riportato un esempio:

RP/0/RSP0/CPU0:ios#show controllers fabric ltrace crossbar location 0/rsp0/cpu0 |
in link_retrain
     Oct  1 08:22:58.999 crossbar 0/RSP1/CPU0 t1  detail xbar_fmlc_handle_link_retrain:
     rcvd link_retrain for (1,1,0),(2,1,0),1.

RP/0/RSP0/CPU0:ios#show controllers fabric ltrace crossbar location 0/0/cpu0 |
in link_retrain
     Oct  1 08:22:58.967 crossbar 0/0/CPU0 t1   init xbar_trigger_link_retrain:
     destslot:0 fmlgrp:3 rc:0
     Oct  1 08:22:58.967 crossbar 0/0/CPU0 t1   detail xbar_pfm_alarm_callback:
     xbar_trigger_link_retrain(): (2,0,7) initiated
     Oct  1 08:22:58.969 crossbar 0/0/CPU0 t1   detail xbar_fmlc_handle_link_retrain:
rcvd link_retrain for (2,1,0),(2,2,0),0.

Il termine direzione TX si riferisce alla direzione dal punto di vista dell'interfaccia di fabric crossbar RSP verso un'interfaccia crossbar fabric su una scheda di linea basata su tifone.

L'ID bug Cisco CSCuj10837 è caratterizzato dal rilevamento da parte della scheda della linea del tifone di un problema sul collegamento RX dall'RSP e dall'avvio di una nuova formazione del collegamento. Entrambi i lati (LC o RSP) possono avviare l'evento di ripetizione del training. Nel caso dell'ID bug Cisco CSCuj10837, il dispositivo LC avvia la procedura di ripetizione della chiamata e può essere rilevato dal messaggio init xbar_trigger_link_retrain: nelle tracce del dispositivo LC.

RP/0/RSP0/CPU0:ios#show controllers fabric ltrace crossbar location 0/0/cpu0 |
in link_retrain
     Oct  1 08:22:58.967 crossbar 0/0/CPU0 t1   init xbar_trigger_link_retrain: destslot:
     0 fmlgrp:3 rc:0

Quando il controller di dominio avvia la ripetizione della procedura, l'RSP segnala un rcvd link_retrain nell'output di traccia.

RP/0/RSP0/CPU0:ios#show controllers fabric ltrace crossbar location 0/rsp0/cpu0 |
in link_retrain
     Oct  1 08:22:58.999 crossbar 0/RSP1/CPU0 t1  detail xbar_fmlc_handle_link_retrain:
     rcvd link_retrain for (1,1,0),(2,1,0),1.

Cisco ID bug CSCul39674 - Ritiro del fabric tra RSP e LC (direzione RX)

Per confermare, raccogliere gli output di traccia dalla scheda di linea e da entrambi gli RSP (show controller fabric crossbar ltrace location <>) e verificare se l'output viene visualizzato nelle tracce RSP:

Di seguito è riportato un esempio:

RP/0/RSP0/CPU0:asr9k-2#show controllers fabric ltrace crossbar  location 0/0/cpu0 |
in link_retrain
 Jan  8 17:28:39.215 crossbar 0/0/CPU0 t1     detail xbar_fmlc_handle_link_retrain:
 rcvd link_retrain for (0,1,0),(5,1,1),0.

RP/0/RSP0/CPU0:asr9k-2#show controllers fabric ltrace crossbar  location 0/rsp0/cpu0 |
in link_retrain
 Jan  8 17:28:39.207 crossbar 0/RSP1/CPU0 t1       init xbar_trigger_link_retrain:
 destslot:4 fmlgrp:3 rc:0
 Jan  8 17:28:39.207 crossbar 0/RSP1/CPU0 t1     detail xbar_pfm_alarm_callback:
 xbar_trigger_link_retrain(): (5,1,11) initiated
 Jan  8 17:28:39.256 crossbar 0/RSP1/CPU0 t1     detail xbar_fmlc_handle_link_retrain:
 rcvd link_retrain for (5,1,1),(0,1,0),0. 

Il termine direzione RX si riferisce alla direzione dal punto di vista dell'interfaccia del fabric crossbar RSP da un'interfaccia crossbar del fabric su una scheda di linea basata su tifone.

L'ID bug Cisco CSCul39674 è caratterizzato dal rilevamento da parte dell'RSP di un problema sul collegamento RX dalla scheda della linea del tifone e dall'avvio di una nuova formazione del collegamento. Entrambi i lati (LC o RSP) possono avviare l'evento di ripetizione del training. Nel caso dell'ID bug Cisco CSCul39674, l'RSP avvia la procedura di ripetizione della chiamata e può essere rilevato dal messaggio init xbar_trigger_link_retrain: nelle tracce sull'RSP.

RP/0/RSP0/CPU0:asr9k-2#show controllers fabric ltrace crossbar  location 0/rsp0/cpu0 |
in link_retrain
 Jan  8 17:28:39.207 crossbar 0/RSP1/CPU0 t1 init xbar_trigger_link_retrain: destslot:4 fmlgrp:
 3 rc:0

Quando l'RSP avvia la ripetizione della procedura, la LC segnala un evento link_retrain ricevuto nell'output di traccia.

RP/0/RSP0/CPU0:asr9k-2#show controllers fabric ltrace crossbar  location 0/0/cpu0 |
in link_retrain
 Jan  8 17:28:39.215 crossbar 0/0/CPU0 t1 detail xbar_fmlc_handle_link_retrain:
 rcvd link_retrain for (0,1,0),(5,1,1),0.

Differenze tra Fabric Retrain nella release 4.3.2 e successive

In Cisco IOS XR versione 4.3.2 e successive, è stato eseguito un lavoro significativo per ridurre il tempo necessario per la riformazione di un collegamento alla struttura. Il riadattamento del fabric si verifica ora al secondo ed è impercettibile ai flussi di traffico. In Cisco IOS XR release 4.3.2, solo questi messaggi di syslog vengono visualizzati quando si verifica un nuovo training del collegamento fabric.

%PLATFORM-FABMGR-5-FABRIC_TRANSIENT_FAULT :  Fabric backplane crossbar link
underwent link retraining to recover from a transient error: Physical slot 1

Errore causato dall'overflow FIFO ASIC dell'infrastruttura

Cisco ha risolto un problema in cui l'ASIC (FIA) del fabric potrebbe essere reimpostato a causa di una condizione di overflow FIFO (First In First Out) non recuperabile. La causa è da ricercare nell'ID bug Cisco CSCul66510. Questo problema interessa solo le schede di linea basate su Trident e si verifica solo in rari casi con grave congestione del percorso in entrata. Se si verifica questo problema, viene visualizzato questo messaggio syslog prima di ripristinare la scheda di linea per ripristinare la condizione.

RP/0/RSP0/CPU0:asr9k-2#show log
   LC/0/3/CPU0:Nov 13 03:46:38.860 utc: pfm_node_lc[284]:
   %FABRIC-FIA-0-ASIC_FATAL_FAULT Set|fialc[159814]
                |Fabric Interface(0x1014000)|Fabric interface asic ASIC1 encountered fatal
                fault 0x1b - OC_DF_INT_PROT_ERR_0
   LC/0/3/CPU0:Nov 13 03:46:38.863 utc: pfm_node_lc[284]: 
   %PLATFORM-PFM-0-CARD_RESET_REQ : pfm_dev_sm_perform_recovery_action,
   Card reset requested by: Process ID:159814 (fialc), Fault Sev: 0, Target node:
   0/3/CPU0, CompId: 0x10, Device Handle: 0x1014000, CondID: 2545, Fault Reason:
   Fabric interface asic ASIC1 encountered fatal fault 0x1b - OC_DF_INT_PROT_ERR_0

Errore causato dalla sovraccarica coda di output virtuale (VOQ) generata dalla congestione dell'infrastruttura

Cisco ha risolto un problema di congestione estesa che potrebbe causare l'esaurimento delle risorse del fabric e la perdita di traffico. La perdita di traffico può anche verificarsi su flussi non correlati. Il problema è stato risolto con l'ID bug Cisco CSCug90300 e viene risolto in Cisco IOS XR versione 4.3.2 e successive. La correzione viene anche fornita in Cisco IOS XR versione 4.2.3 CSMU#3, ID bug Cisco CSCui3805. Questo raro problema può essere riscontrato sia sulle schede di linea basate su Trident che su quelle basate su Typhoon.

Comandi pertinenti

Raccogli output da questi comandi:

• show tech-support fabric
• show controller fabric fia bridge flow-control location <=== Ottieni questo output per tutti i LC
• show controllers fabric fia q-depth location

Di seguito sono riportati alcuni output di esempio:

RP/0/RSP0/CPU0:asr9k-1#show controllers fabric fia q-depth location 0/6/CPU0
Sun Dec 29 23:10:56.307 UTC 
********** FIA-0 **********
Category: q_stats_a-0
Voq       ddr            pri            pktcnt   
11        0              2              7
********** FIA-0 **********
Category: q_stats_b-0
Voq       ddr            pri            pktcnt
********** FIA-1 **********
Category: q_stats_a-1
Voq       ddr            pri            pktcnt
11        0              0              2491
11        0              2              5701
********** FIA-1 **********
Category: q_stats_b-1
Voq       ddr            pri            pktcnt
RP/0/RSP0/CPU0:asr9k-1#
RP/0/RSP0/CPU0:asr9k-1#show controllers pm location 0/1/CPU0 | in "switch|if"

Sun Dec 29 23:37:05.621 UTC
Ifname(2): TenGigE0_1_0_2, ifh: 0x2000200 : <==Corresponding interface ten 0/1/0/2
iftype             0x1e
switch_fabric_port 0xb   <==== VQI 11
parent_ifh         0x0
parent_bundle_ifh  0x80009e0
RP/0/RSP0/CPU0:asr9k-1#

In condizioni normali, è molto improbabile vedere un VOQ con pacchetti in coda. Questo comando è un'istantanea rapida in tempo reale delle code FIA. Normalmente questo comando non visualizza alcun pacchetto in coda.

Impatto del traffico dovuto a errori soft Bridge/FPGA su schede di linea basate su Trident

Gli errori soft sono errori non permanenti che causano una mancata sincronizzazione della macchina a stati. Questi sono visti come Cyclic Redundancy Check (CRC), Frame Check Sequence (FCS), o pacchetti errati sul lato fabric dell'NP o sul lato in entrata della FIA.

Di seguito sono riportati alcuni esempi di come si può vedere questo problema:

RP/0/RSP0/CPU0:asr9k-1#show controllers fabric  fia drops ingress location 0/3/CPU0
Fri Dec  6 19:50:42.135 UTC
 ********** FIA-0 **********
Category: in_drop-0
                                DDR Rx FIFO-0                        0
                                DDR Rx FIFO-1                 32609856   <=== Errors

RP/0/RSP0/CPU0:asr9k-1#show controllers fabric  fia errors ingress location 0/3/CPU0
Fri Dec  6 19:50:48.934 UTC

 ********** FIA-0 **********
Category: in_error-0
                                 DDR Rx CRC-0                        0
                                 DDR Rx CRC-1                 32616455  <=== Errors

RP/0/RSP1/CPU0:asr9k-1#show controllers fabric fia bridge stats location 0/0/CPU0
Ingress Drop Stats (MC & UC combined)
**************************************
PriorityPacket               Error            Threshold
       Direction               Drops            Drops
--------------------------------------------------
LP      NP-3 to Fabric     0                   0
HP      NP-3 to Fabric    1750              0
RP/0/RSP1/CPU0:asr9k-1#

RP/0/RSP1/CPU0:asr9k-1#show controllers fabric fia bridge stats location 0/6/CPU0

Sat Jan  4 06:33:41.392 CST
  ********** FIA-0 **********
Category: bridge_in-0
                                  UcH Fr Np-0                 16867506
                                  UcH Fr Np-1                   115685
                                  UcH Fr Np-2                   104891
                                  UcH Fr Np-3                   105103
                                  UcL Fr Np-0               1482833391
                                  UcL Fr Np-1              31852547525
                                  UcL Fr Np-2               3038838776
                                  UcL Fr Np-3              30863851758
                                  McH Fr Np-0                   194999
                                  McH Fr Np-1                   793098
                                  McH Fr Np-2                   345046
                                  McH Fr Np-3                   453957
                                  McL Fr Np-0                 27567869
                                  McL Fr Np-1                 12613863
                                  McL Fr Np-2                   663139
                                  McL Fr Np-3                 21276923
                                 Hp ErrFrNp-0                        0
                                 Hp ErrFrNp-1                        0
                                 Hp ErrFrNp-2                        0
                                 Hp ErrFrNp-3                        0
                                 Lp ErrFrNp-0                        0
                                 Lp ErrFrNp-1                        0
                                 Lp ErrFrNp-2                        0
                                 Lp ErrFrNp-3                        0
                                 Hp ThrFrNp-0                        0
                                 Hp ThrFrNp-1                        0
                                 Hp ThrFrNp-2                        0
                                 Hp ThrFrNp-3                        0
                                 Lp ThrFrNp-0                        0
                                 Lp ThrFrNp-1                        0
                                 Lp ThrFrNp-2                        0
                                 Lp ThrFrNp-3                        0
  ********** FIA-0 **********
Category: bridge_eg-0
                                  UcH to Np-0                   779765
                                  UcH to Np-1                  3744578
                                  UcH to Np-2                   946908
                                  UcH to Np-3                  9764723
                                  UcL to Np-0               1522490680
                                  UcL to Np-1              32717279812
                                  UcL to Np-2               3117563988
                                  UcL to Np-3              29201555584
                                UcH ErrToNp-0                        0
                                UcH ErrToNp-1                        0
                                UcH ErrToNp-2                      129   <==============
                                UcH ErrToNp-3                        0
                                UcL ErrToNp-0                        0
                                UcL ErrToNp-1                        0
                                UcL ErrToNp-2                    90359   <==========

Comandi da raccogliere per gli errori software Bridge/FPGA su schede di linea basate su Trident

Raccogli output da questi comandi:

• show tech-support fabric
• show tech-support np
• show controller fabric fia bridge stats location <> (ottieni più volte)

Ripristino da errori software Bridge/FPGA

Il metodo di ripristino consiste nel ricaricare la scheda di linea interessata.

RP/0/RSP0/CPU0:asr9k-1#hw-module location 0/6/cpu0 reload

Rapporto test di diagnostica online

OSPF (Open Shortest Path First) show diagnostic result location [test detail ] fornisce un riepilogo di tutti i test e gli errori di diagnostica online, nonché l'ultimo indicatore orario quando un test è stato superato. L'ID test per l'errore del percorso dati dell'infrastruttura punt è 10. È possibile visualizzare un elenco di tutti i test con la frequenza dei pacchetti di test show diagnostic content location

L'output del risultato del test del percorso dati della struttura punt è simile all'output di esempio seguente:

RP/0/RSP0/CPU0:ios(admin)#show diagnostic result location 0/rsp0/cpu0  test 10 detail
Current bootup diagnostic level for RP 0/RSP0/CPU0: minimal
  Test results: (. = Pass, F = Fail, U = Untested)

  ___________________________________________________________________________
  10 ) FabricLoopback ------------------> .
          Error code ------------------> 0 (DIAG_SUCCESS)
          Total run count -------------> 357
          Last test execution time ----> Sat Jan 10 18:55:46 2009
          First test failure time -----> n/a
          Last test failure time ------> n/a
          Last test pass time ---------> Sat Jan 10 18:55:46 2009
          Total failure count ---------> 0
          Consecutive failure count ---> 0

Miglioramenti del ripristino automatico

Come descritto nell'ID bug Cisco CSCuc04493, è ora possibile fare in modo che il router chiuda automaticamente tutte le porte associate agli errori PUNT_FABRIC_DATA_PATH generati sull'RP/RSP attivo.

Il primo metodo viene rilevato con l'ID bug Cisco CSCuc04493. Per la versione 4.2.3, è incluso nell'ID bug Cisco CSCui3805. In questa versione, è impostato per la chiusura automatica di tutte le porte associate agli NP interessati.

Di seguito è riportato un esempio che mostra come apparirebbero i syslog:

RP/0/RSP0/CPU0:Jun 10 16:11:26 BKK: pfm_node_rp[359]:
 %PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Set|online_diag_rsp[237686]|System
 Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP) failed:
 (0/1/CPU0, 0) 
LC/0/1/CPU0:Jun 10 16:11:27 BKK: ifmgr[204]: %PKT_INFRA-LINK-3-UPDOWN : Interface
 TenGigE0/1/0/0, changed state to Down 
LC/0/1/CPU0:Jun 10 16:11:27 BKK: ifmgr[204]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line
 protocol on Interface TenGigE0/1/0/0, changed state to Down 
LC/0/1/CPU0:Jun 10 16:11:27 BKK: ifmgr[204]: %PKT_INFRA-LINK-3-UPDOWN : Interface
 TenGigE0/1/0/1, changed state to Down 
LC/0/1/CPU0:Jun 10 16:11:27 BKK: ifmgr[204]: %PKT_INFRA-LINEPROTO-5-UPDOWN : Line
 protocol on Interface TenGigE0/1/0/1, changed state to Down 

Il controller indica che il motivo per cui l'interfaccia è inattiva è DATA_PATH_DOWN. Di seguito è riportato un esempio:

RP/0/RSP0/CPU0:ASR9006-E#show controllers gigabitEthernet 0/0/0/13 internal
Wed Dec 18 02:42:52.221 UTC

Port Number       : 13
Port Type         : GE
Transport mode    : LAN
BIA MAC addr      : 6c9c.ed08.3cbd
Oper. MAC addr    : 6c9c.ed08.3cbd
Egress MAC addr   : 6c9c.ed08.3cbd
Port Available    : true
Status polling is : enabled
Status events are : enabled
I/F Handle        : 0x04000400
Cfg Link Enabled  : tx/rx enabled
H/W Tx Enable     : no
UDLF enabled      : no
SFP PWR DN Reason : 0x00000000
SFP Capability    : 0x00000024
MTU               : 1538
H/W Speed         : 1 Gbps
H/W Duplex        : Full
H/W Loopback Type : None
H/W FlowCtrl type : None
H/W AutoNeg Enable: Off
H/W Link Defects  : (0x00080000) DATA_PATH_DOWN  <<<<<<<<<<<
Link Up           : no
Link Led Status   : Link down -- Red
Input good underflow          : 0
Input ucast underflow         : 0
Output ucast underflow        : 0
Input unknown opcode underflow: 0
Pluggable Present   : yes
Pluggable Type      : 1000BASE-LX
Pluggable Compl.    : (Service Un) - Compliant
Pluggable Type Supp.: (Service Un) - Supported
Pluggable PID Supp. : (Service Un) - Supported
Pluggable Scan Flg: false

Nelle versioni 4.3.1 e successive questo comportamento deve essere attivato. A tale scopo, è possibile usare un nuovo comando admin-config. Poiché per impostazione predefinita le porte non vengono più chiuse, è necessario configurarle manualmente.

RP/0/RSP1/CPU0:ASR9010-A(admin-config)#fault-manager datapath port ?
 shutdown Enable auto shutdown
 toggle Enable auto toggle port status

Su Cisco IOS XR a 64 bit, il comando di configurazione è disponibile nella VM XR (non nella VM Sysadmin):

RP/0/RSP0/CPU0:CORE-TOP(config)#fault-manager datapath port ?
shutdown Enable auto shutdown
toggle Enable auto toggle port status

L'ID bug Cisco CSCui15435 risolve gli errori software rilevati sulle schede di linea basate su Trident, come descritto nella sezione Impatto del traffico causato dagli errori software Bridge/FPGA sulle schede di linea basate su Trident. Questo metodo di rilevamento è diverso dal solito metodo diagnostico descritto nell'ID bug Cisco CSCuc04493.

Questo bug ha inoltre introdotto un nuovo comando admin-config CLI:

 (admin-config)#fabric fia soft-error-monitor <1|2> location 
    
    

1 = shutdown the ports
2 = reload the linecard

Default behavior: no action is taken.

Quando si verifica questo errore, è possibile osservare il syslog seguente:

RP/0/RSP0/CPU0:Apr 30 22:17:11.351 : config[65777]: %MGBL-SYS-5-CONFIG_I : Configured
 from console by root
LC/0/2/CPU0:Apr 30 22:18:52.252 : pfm_node_lc[283]:
 %PLATFORM-BRIDGE-1-SOFT_ERROR_ALERT_1 : Set|fialc[159814]|NPU
 Crossbar Fabric Interface Bridge(0x1024000)|Soft Error Detected on Bridge instance 1
RP/0/RSP0/CPU0:Apr 30 22:21:28.747 : pfm_node_rp[348]:
 %PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Set|online_diag_rsp[237686]|
System Punt/Fabric/data Path Test(0x2000004)|failure threshold is 3, (slot, NP) failed:
 (0/2/CPU0, 2) (0/2/CPU0, 3)
LC/0/2/CPU0:Apr 30 22:21:29.707 : ifmgr[194]: %PKT_INFRA-LINK-3-UPDOWN :
 Interface TenGigE0/2/0/2, changed state to Down
LC/0/2/CPU0:Apr 30 22:21:29.707 : ifmgr[194]: %PKT_INFRA-LINEPROTO-5-UPDOWN :
 Line protocol on Interface TenGigE0/2/0/2, changed state to Down
RP/0/RSP1/CPU0:Apr 30 22:21:35.086 : pfm_node_rp[348]:
 %PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED :
 Set|online_diag_rsp[237646]|System Punt/Fabric/data Path Test(0x2000004)|failure
 threshold is 3, (slot, NP) failed: (0/2/CPU0, 2) (0/2/CPU0, 3)

Quando le porte interessate vengono chiuse, consente alla ridondanza di rete di assumere il controllo ed evitare un black-holing del traffico. Per eseguire il ripristino, è necessario ricaricare la scheda di linea.

Domande frequenti (FAQ)

D. La scheda del processore di routing principale o standby invia pacchetti keepalive o diagnostici online a ogni NP del sistema?

R. Sì. Entrambe le schede del processore di routing inviano pacchetti di diagnostica online a ogni NP.

D. Il percorso è lo stesso quando la scheda del processore di routing 1 (RSP1) è attiva?

R. Il percorso di diagnostica è lo stesso per RSP0 o RSP1. Il percorso dipende dallo stato dell'RSP. Per ulteriori informazioni, consultare la sezione Percorso pacchetto diagnostico fabric Punt di questo documento.

D. Quante volte gli RSP inviano pacchetti di diagnostica e quanti pacchetti di diagnostica devono mancare prima che scatti un allarme?

R. Ogni RSP invia in modo indipendente un pacchetto diagnostico a ogni NP una volta al minuto. In entrambi i casi, l'RSP può attivare un allarme se non vengono riconosciuti tre pacchetti diagnostici.

D. Come è possibile stabilire se una sottoscrizione VPN è o è stata sovrascritta?

R. Un modo per verificare se un NP è attualmente sovrasottoscritto o è stato sovrasottoscritto in passato è quello di controllare un certo tipo di cadute all'interno dell'NP e per le cadute di coda nella FIA. Le cadute in ingresso dell'IFDMA (Front Direct Memory Access) all'interno del NP si verificano quando il NP è sovrascritto e non è in grado di tenere il passo con il traffico in entrata. Le cadute di coda FIA si verificano quando un NP in uscita asserisce il controllo del flusso (chiede alla scheda di linea in entrata di inviare meno traffico). Nello scenario di controllo del flusso, la FIA in entrata presenta cali di coda.

D. Come è possibile stabilire se un computer portatile presenta un errore che richiede la reimpostazione?

R. In genere, un errore NP viene cancellato da un ripristino rapido. Il motivo di un ripristino rapido viene visualizzato nei log.

D. È possibile reimpostare manualmente un NP?

R. Sì, dalla scheda di linea KSH:

run attach 0/[x]/CPU0
#show_np -e [np#] -d fast_reset

D. Cosa viene visualizzato se un problema hardware irreversibile è presente in un NP?

R. Vengono visualizzati sia l'errore del percorso dati della struttura punt per la rete NP sia l'errore del test di loopback NP. Il messaggio di errore del test di loopback NP è trattato nella sezione Appendice di questo documento.

D. Un pacchetto di diagnostica proveniente da una scheda del processore di routing tornerà allo stesso?

R. Poiché i pacchetti diagnostici provengono da entrambe le schede del processore di routing e vengono tracciati per ogni scheda del processore di routing, un pacchetto diagnostico proveniente da una scheda del processore di routing viene rimandato indietro alla stessa scheda del processore di routing dall'NP.

D. L'ID bug Cisco CSCuj10837 SMU fornisce una correzione per l'evento di retraining del collegamento fabric. È questa la causa e la soluzione per molti errori del percorso dati della struttura punt?

R. Sì, è necessario caricare l'SMU sostitutivo per l'ID bug Cisco CSCul39674 al fine di evitare eventi di riaddestramento del collegamento fabric.

D. Quanto tempo occorre per riqualificare i collegamenti fabric una volta presa la decisione di farlo?

R. La decisione di effettuare il nuovo addestramento viene presa non appena viene rilevato un errore del collegamento. Prima della release 4.3.2, il riadattamento potrebbe richiedere alcuni secondi. Dopo la release 4.3.2, il tempo di ricollegamento è stato notevolmente migliorato e richiede meno di un secondo.

D. A che punto è stata presa la decisione di riqualificare un collegamento fabric?

R. Non appena viene rilevato il guasto del collegamento, il driver ASIC dell'infrastruttura decide di eseguire nuovamente la formazione.

D. È solo tra la FIA su una scheda del processore di routing attiva e il fabric che si utilizza il primo collegamento, e poi è il collegamento meno caricato quando ci sono più collegamenti disponibili?

R. Esatto. Il primo collegamento che si connette alla prima istanza XBAR sul processore di routing attivo viene utilizzato per iniettare traffico nella struttura. Il pacchetto di risposta dalla scheda del processore di routing attivo può raggiungere di nuovo la scheda del processore di routing attiva su uno qualsiasi dei collegamenti che si connettono alla scheda del processore di routing. La scelta del collegamento dipende dal carico del collegamento.

D. Durante il riadattamento, tutti i pacchetti inviati su quel collegamento fabric vanno persi?

R. Sì, ma con i miglioramenti apportati alla release 4.3.2 e successive, la ripetizione del treno è praticamente irrilevabile. Tuttavia, nel codice precedente, potrebbero essere necessari diversi secondi per la riprogrammazione, con conseguente perdita di pacchetti per quel periodo di tempo.

D. Con quale frequenza prevedete di vedere un evento di riaddestramento del collegamento al fabric XBAR dopo l'aggiornamento a una release o a una SMU con la correzione per l'ID bug Cisco CSCuj10837?

R. Anche se è stato risolto il problema con l'ID bug Cisco CSCuj10837, è ancora possibile verificare una riorganizzazione dei collegamenti dell'infrastruttura a causa dell'ID bug Cisco CSCul39674. Tuttavia, dopo aver risolto il problema con l'ID bug Cisco CSCul39674, non sarà più necessario effettuare il riaddestramento del collegamento di struttura sul backplane del fabric per collegare le schede di linea RSP440 e quelle basate sul tifone. In caso affermativo, inviare una richiesta di assistenza al Cisco Technical Assistance Center (TAC) per risolvere il problema.

D. L'ID bug Cisco CSCuj10837 e l'ID bug Cisco CSCul39674 influiscono sull'RP nell'ASR 9922 con schede di linea basate sul tifone?

A. Sì

D. L'ID bug Cisco CSCuj10837 e l'ID bug Cisco CSCul39674 influiscono sui router ASR-9001 e ASR-9001-S?

R. No

D. Se si verifica un errore di uno slot che non esiste con questo messaggio, "PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED : Set|online_diag_rsp[237686]|Test perno/fabric/percorso dati del sistema (0x2000004)|soglia errore è 3, (slot, NP) non riuscito: (8, 0)," in uno chassis a 10 slot, quale slot presenta il problema?

R. Nelle release precedenti, è necessario tenere conto delle mappature fisiche e logiche, come mostrato di seguito. In questo esempio, lo slot 8 corrisponde a 0/6/CPU0.

For 9010 (10 slot chassis)
L            P
#0  --- #0
#1  --- #1
#2  --- #2
#3  --- #3
RSP0 --- #4
RSP1 --- #5
#4 --- #6
#5 --- #7
#6 --- #8
#7 --- #9

For 9006 (6 slot chassis)
L               P
RSP0 --- #0
RSP1 --- #1
#0 --- #2
#1 --- #3
#2 --- #4
#3 --- #5

Dati da raccogliere prima della creazione della richiesta di assistenza

Di seguito sono riportati i comandi minimi per la raccolta dell'output prima dell'esecuzione di qualsiasi azione:

• show logging
• show pfm location all
• admin show diagn result loc 0/rsp0/cpu0 test 8 detail
• admin show diagn result loc 0/rsp1/cpu0 test 8 detail
• admin show diagn result loc 0/rsp0/cpu0 test 9 detail
• admin show diagn result loc 0/rsp1/cpu0 test 9 detail
• admin show diagn result loc 0/rsp0/cpu0 test 10 detail
• admin show diagn result loc 0/rsp1/cpu0 test 10 detail
• admin show diagn result loc 0/rsp0/cpu0 test 11 detail
• admin show diagn result loc 0/rsp1/cpu0 test 11 detail
• show controller fabric fia link-status location
• show controller fabric fia link-status location
• show controller fabric fia bridge sync-status location
• show controller fabric crossbar link-status instance 0 location
• show controller fabric crossbar link-status instance 0 location
• show controller fabric crossbar link-status instance 1 location
• show controller fabric ltrace crossbar location
• show controller fabric ltrace crossbar location
• show tech fabric location file
• show tech fabric location file

Comandi diagnostici utili

Di seguito è riportato un elenco di comandi utili per scopi diagnostici:

• show diagnostic ondemand settings
• show diagnostic content location < loc >
• show diagnostic result location < loc > [ test {id|id_list|all} ] [ detail ]
• show diagnostic status
• admin diagnostic start location < loc > test {id|id_list|test-suite}
• admin diagnostic stop location < loc >
• iterazioni ondemand diagnostic admin < conteggio-iterazioni >
• admin diagnostic ondemand action-on-failure {continue failure-count|stop}
• admin-config#[ no ] diagnostic monitor location < loc > test {id | test-name} [disable]
• admin-config# [ no ] diagnostic monitor interval location < loc > test {id | test-name} day hour:minute:second.millisec
• admin-config# [ no ] diagnostic monitor threshold location < loc > test {id | test-name} failure count

Conclusioni

Dall'intervallo di tempo del software Cisco IOS XR versione 4.3.4, vengono risolti la maggior parte dei problemi relativi agli errori del percorso dati della struttura punt. Per i router interessati dall'ID bug Cisco CSCuj10837 e dall'ID bug Cisco CSCul39674, caricare l'SMU sostitutivo per l'ID bug Cisco CSCul39674 in modo da evitare eventi di riaddestramento del collegamento dell'infrastruttura.

Il team della piattaforma ha installato una gestione degli errori all'avanguardia in modo che il router si riprenda in pochi secondi se e quando si verifica un errore ripristinabile del percorso dati. Tuttavia, si consiglia di consultare questo documento per comprendere il problema, anche se non viene rilevato alcun errore di questo tipo.

Appendice

Percorso diagnostico loopback NP

L'applicazione diagnostica che viene eseguita sulla CPU della scheda di linea tiene traccia dello stato di salute di ogni NP con controlli periodici dello stato di funzionamento dell'NP. Un pacchetto viene iniettato dalla CPU della scheda di linea destinata all'NP locale, che dovrebbe ricollegarsi e tornare alla CPU della scheda di linea. Ogni perdita in questi pacchetti periodici è contrassegnata con un messaggio di registro della piattaforma. Di seguito è riportato un esempio di tale messaggio:

LC/0/7/CPU0:Aug 18 19:17:26.924 : pfm_node[182]: 
%PLATFORM-PFM_DIAGS-2-LC_NP_LOOPBACK_FAILED : Set|online_diag_lc[94283]|
Line card NP loopback Test(0x2000006)|link failure mask is 0x8

Questo messaggio di registro indica che il test non è riuscito a ricevere il pacchetto di loopback da NP3. La maschera di errore del collegamento è 0x8 (il bit 3 è impostato), il che indica un errore tra la CPU della scheda di linea per lo slot 7 e NP3 nello slot 7.

Per ottenere ulteriori dettagli, catturare l'output di questi comandi:

• admin show diagnostic result location 0/ /cpu0 test 9 detail
• show controllers NP counter NP<0-3> location 0/ /cpu0

Comandi di debug dell'infrastruttura

I comandi elencati in questa sezione si applicano a tutte le schede di linea basate su Trident e alla scheda di linea 100GE basata su tifone. L'ASIC Bridge FPGA non è presente sulle schede di linea basate sul tifone (ad eccezione delle schede di linea basate sul tifone 100GE). Quindi, la show controller fabric fia bridge i comandi non si applicano alle schede di linea basate su tifone, ad eccezione delle versioni 100GE.

Questa rappresentazione grafica consente di mappare ogni comando show alla posizione nel percorso dati. Utilizzare questi comandi show per isolare le perdite e i guasti dei pacchetti.