De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.
Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.
Dit document beschrijft foutmeldingen van het point fabric-gegevenspad die worden gezien tijdens een werking van Cisco Aggregation Services Router (ASR) 9000 Series.
Het bericht wordt in deze bestandsindeling weergegeven:
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)
Dit document is bedoeld voor iedereen die de foutmelding wil begrijpen en de acties die moeten worden ondernomen als het probleem wordt gezien.
Cisco raadt u aan een uitgebreide kennis van deze onderwerpen te hebben:
Dit document vereist echter niet dat lezers bekend zijn met de hardwaregegevens. De nodige achtergrondinformatie wordt verstrekt voordat de foutmelding wordt verklaard. Dit document beschrijft de fout op zowel Trident- als op Typhoon gebaseerde lijnkaarten. Zie ASR 9000 Series lijnkaarttypen begrijpen voor een toelichting op deze termen.
Dit document is niet beperkt tot specifieke software- en hardware-versies.
De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.
Overweeg de volgende suggesties over het gebruik van dit document om belangrijke details te verkrijgen en als naslaggids bij het proces van probleemoplossing:
Een pakket kan of twee hop of drie hop door de switch oversteken die op het type lijnkaart wordt gebaseerd. Typhoon generatie lijnkaarten voegen een extra switch fabric element toe, terwijl Trident-gebaseerde lijnkaarten alle verkeer switches met de stof op de route processor kaart alleen. Deze diagrammen tonen fabric-elementen voor beide lijnkaarttypes, evenals fabric-connectiviteit met de routeprocessorkaart:
De diagnostische toepassing die wordt uitgevoerd op de routeprocessorkaart CPU injecteert diagnostische pakketten die periodiek aan elke netwerkprocessor (NP) worden toegewezen. Het kenmerkende pakket wordt van een lus voorzien binnen NP, en opnieuw naar de kaart CPU van de routeprocessor die het pakket afkomstig was geïnjecteerd. Deze periodieke gezondheidscontrole van elk NP met een uniek pakket per NP door de diagnostische toepassing op de routeprocessorkaart geeft een waarschuwing voor functionele fouten op het gegevenspad tijdens routerwerking. Het is essentieel om op te merken dat de diagnostische toepassing op zowel de actieve routeprocessor als de standby routeprocessor periodiek één pakket per NP injecteert en per NP succes- of storingsgetal handhaaft. Wanneer een drempelwaarde wordt bereikt voor gevallen diagnostische pakketten, doet de toepassing een fout ontstaan.
Voordat het document het diagnosepad op Trident- en Typhoon-lijnkaarten beschrijft, wordt in deze sectie een algemeen overzicht gegeven van het weefseldiagnosepad van zowel de actieve als de stand-by routeprocessorkaarten naar de NP op de lijnkaart.
Diagnostische pakketten die door de actieve routeprocessor in het weefsel in de richting van het NP worden geïnjecteerd, worden door het weefsel van de switch als unicastpakketten behandeld. Met unicastpakketten kiest de routerstructuur de uitgaande link op basis van de huidige verkeerslading van de switch, die helpt om diagnostische pakketten te onderwerpen aan de verkeerslading op de router. Wanneer er meerdere uitgaande links naar het NP zijn, kiest de switch Fabriek ASIC een link die momenteel de minst geladen is.
Dit diagram toont het diagnostische pakketpad dat afkomstig is van de actieve routeprocessor.
Opmerking: De eerste link die de Fabric Interface ASIC (FIA) op de lijnkaart verbindt met de Crossbar (XBAR) op de routeprocessorkaart wordt steeds gekozen voor pakketten die bestemd zijn voor de NP. De pakketten van de reactie van NP worden onderworpen aan een verbinding-lading distributiealgoritme (als de lijnkaart op Typhoon-Gebaseerd is). Dit betekent dat het reactiepakket van NP naar de actieve routeprocessor een van de fabric links kan kiezen die lijnkaarten verbinden met de routeprocessorkaart op basis van de fabric link load.
Diagnostische pakketten die vanuit de stand-by routeprocessor in het weefsel worden geïnjecteerd naar het NP worden door het weefsel van de switch als multicastpakketten behandeld. Hoewel het een multicastpakket is, is er geen replicatie binnen de stof. Elk diagnostisch pakket dat afkomstig is van de stand-by routeprocessor bereikt nog steeds slechts één NP per keer. Het reactiepakket van NP naar de routeprocessor is ook een multicast pakket over de stof zonder replicatie. Daarom ontvangt de diagnostische toepassing op de stand-by routeprocessor één pakket van de NP's, één pakket per keer. De diagnostische toepassing volgt elke NP in het systeem, omdat het één pakket per NP injecteert, en verwacht reacties van elk NP, één pakket tegelijk. Met een multicast pakket, kiest de switch stof de uitgaande verbinding die op een gebiedswaarde in de pakketheader wordt gebaseerd, die helpt om kenmerkende pakketten over elke stoffenverbinding tussen de routeprocessorkaart en de lijnkaart te injecteren. De stand-by routeprocessor volgt de NP-status via elke fabric link die verbindt tussen de routeprocessorkaart en de lijnkaartsleuf.
Het vorige diagram toont het diagnostische pakketpad dat afkomstig is van de stand-by routeprocessor. Merk op dat, in tegenstelling tot de actieve routeprocessorcase, alle links die de lijnkaart verbinden met de XBAR op de routeprocessor worden uitgeoefend. De reactiepakketten van NP nemen de zelfde fabric link die door het pakket in de routeprocessor aan de lijnkaartrichting werd gebruikt. Deze test zorgt ervoor dat alle links die de stand-by routeprocessor verbinden met de lijnkaart continu worden bewaakt.
Dit diagram toont de van de routeprocessor afkomstige diagnostische pakketten die aan NP worden bestemd die terug naar de routeprocessor wordt teruggelicht. Het is belangrijk om te letten op de datapad links en ASIC's die gemeenschappelijk zijn voor alle NP's, evenals links en componenten die specifiek zijn voor een deelgroep van NP's. Zo is bijvoorbeeld de Bridge ASIC 0 (B0) gemeenschappelijk voor NP0 en NP1, terwijl FIA0 gemeenschappelijk is voor alle NP's. Op het routeprocessoruiteinde zijn alle links, data path ASIC's en de Field-Programmable Gate Array (FPGA) gemeenschappelijk voor alle lijnkaarten, en dus voor alle NP's in een chassis.
Dit diagram toont van de routeprocessorkaart uitgaande diagnostische pakketten die aan een NP worden bestemd die terug naar de routeprocessor wordt teruggevoerd. Het is belangrijk om te letten op de datapad links en ASIC's die gemeenschappelijk zijn voor alle NP's, evenals links en componenten die specifiek zijn voor een deelgroep van NP's. FIA0 is bijvoorbeeld gemeenschappelijk voor NP0 en NP1. Op het routeprocessorkaartuiteinde, zijn alle links, datapadazen en de FGPA gemeenschappelijk voor alle lijnkaarten en dus voor alle NP's in een chassis.
Op Tomahawk lijnkaarten is er een 1:1-verbinding tussen de FIA en de NP.
Op Lightspeed en LightspeedPlus lijnkaarten is de FIA geïntegreerd in de NP chip.
In de volgende secties wordt getracht het pakketpad naar elk NP weer te geven. Dit is nodig om de foutmelding van het pad van de puntfabric-gegevens te begrijpen, en ook om het foutpunt te vinden.
Het uitblijven van reacties van een NP in een op ASR 9000 gebaseerde router resulteert in een alarm. De beslissing om een alarm te slaan door de online diagnostische applicatie die wordt uitgevoerd op de routeprocessor, vindt plaats wanneer er drie opeenvolgende storingen zijn. De diagnostische toepassing zorgt voor een venster voor drie pakketfouten voor elke NP. De actieve routeprocessor en de stand-by routeprocessor diagnosticeren onafhankelijk en parallel. De actieve routeprocessor, de stand-by routeprocessor of beide routeprocessorkaarten konden de fout melden. De plaats van de fout en pakketverlies bepalen welke routeprocessor het alarm meldt.
De standaardfrequentie van het diagnostische pakket naar elk NP is één pakket per 60 seconden of één per minuut.
Hier is het alarmberichtformaat:
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)
Het bericht toont een mislukking om NP 1, 2, 3, 4, 5, 6, en 7 op lijnkaart 0/7/cpu0 van routeprocessor 0/rsp0/cpu0 te bereiken.
In de lijst van online diagnostische tests kunt u de kenmerken van de punt fabric loopback test zien met deze opdracht:
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)#
De output toont de PuntFabricDataPath testfrequentie is één pakket elke minuut, en de mislukkingsdrempel is drie, wat impliceert dat het verlies van drie opeenvolgende pakketten niet wordt getolereerd en in een alarm resulteert. De getoonde testkenmerken zijn standaardwaarden. Als u de standaardwaarden wilt wijzigen, voert u de diagnostic monitor interval
en diagnostic monitor threshold
opdrachten in de modus voor de beheerconfiguratie.
Fabric-diagnostisch pad
Dit diagram toont het pakketpad tussen de routeprocessor CPU en de lijnkaart NP0. De link tussen B0 en NP0 is de enige link specifiek voor NP0. Alle andere links vallen in het gemeenschappelijke pad.
Noteer het pakketpad van de routeprocessor naar NP0. Hoewel er vier links te gebruiken zijn voor pakketten die bestemd zijn voor NP0 vanuit de routeprocessor, wordt de eerste link tussen de routeprocessor en de lijnkaartsleuf gebruikt voor het pakket van de routeprocessor naar de lijnkaart. Het teruggekeerde pakket van NP0 kan naar de actieve routeprocessor worden teruggestuurd over om het even welk van de twee stoffen verbindingswegen tussen de lijnkaartgroef en de actieve routeprocessor. De keuze van welke van de twee te gebruiken koppelingen afhangt van de koppelingsbelasting op dat moment. Het reactiepakket van NP0 naar de stand-by routeprocessor gebruikt beide links, maar één link tegelijk. De keuze van de link is gebaseerd op het headerveld dat de diagnostische toepassing bevolkt.
Enkelvoudig foutenscenario
Als een enkele Platform Fault Manager (PFM) signaleert dat het pad van de fabric data fout is met alleen NP0 in het foutbericht, dan is de fout alleen op het pad van de stof dat de routeprocessor en de lijnkaart NP0 verbindt. Dit is één enkele fout. Als de fout in meer dan één NP wordt gedetecteerd, raadpleegt u het gedeelte Multiple Fault Scenario.
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)
Opmerking: dit gedeelte van het document is van toepassing op elke lijnkaartsleuf in een chassis, ongeacht het type chassis. Daarom kan dit worden toegepast op alle lijnkaartsleuven.
Zoals geïllustreerd in het vorige gegevenspad-diagram, moet de fout zich op een of meer van deze locaties bevinden:
Multiple Fault Scenario
Meervoudige NP-fouten
Als op NP0 andere fouten worden geobserveerd of als de fout PUNT_FABRIC_DATA_PATH_ERROR ook door andere NP's op dezelfde lijnkaart wordt gemeld, dan wordt de fout geïsoleerd door alle fouten te correleren. Bijvoorbeeld, als zowel de FOUT PUNT_FABRIC_DATA_PATH_MISLUKTE als de fout LC_NP_LOOPBACK_MISLUKTE optreden op NP0, dan heeft NP de verwerking van pakketten gestopt. Raadpleeg het gedeelte NP LoopBack Diagnostic Path om de loopbackfout te begrijpen. Dit zou een vroege indicatie kunnen zijn van een kritieke storing binnen NP0. Als echter slechts een van de twee fouten optreedt, wordt de fout gelokaliseerd naar het gegevenspad van de puntstof of op de lijnkaart CPU naar het NP-pad.
Als meer dan één NP op een lijnkaart een fout in het pad van de puntstof gegevens heeft, dan moet u de boomweg van de verbindingen van de stof omhoog lopen om een defecte component te isoleren. Bijvoorbeeld, als zowel NP0 als NP1 een fout hebben, dan moet de fout in B0 of de verbinding zijn die B0 en FIA0 verbindt. Het is minder waarschijnlijk dat zowel NP0 als NP1 tegelijkertijd een kritische interne fout tegenkomen. Hoewel het minder waarschijnlijk is, is het mogelijk voor NP0 en NP1 om een kritieke foutenfout te ontmoeten toe te schrijven aan de onjuiste verwerking van een bepaald soort pakket of een slecht pakket.
Beide routeprocessorkaarten melden een fout
Als zowel de actieve als stand-by routeprocessorkaarten een fout melden aan een of meer NP's op een lijnkaart, dan controleer alle gemeenschappelijke koppelingen en componenten op het gegevenspad tussen de betrokken NP's en zowel de routeprocessorkaarten.
Dit diagram toont het pakketpad tussen de routeprocessorkaart CPU en de lijnkaart NP1. De link die Bridge SIC 0 (B0) en NP1 verbindt is de enige link die specifiek is voor NP1. Alle andere links vallen in het gemeenschappelijke pad.
Noteer het pakketpad van de routeprocessorkaart naar NP1. Hoewel er vier links te gebruiken zijn voor pakketten die bestemd zijn voor NP0 vanuit de routeprocessor, wordt de eerste link tussen de routeprocessor en de lijnkaartsleuf gebruikt voor het pakket van de routeprocessor naar de lijnkaart. Het teruggekeerde pakket van NP1 kan naar de actieve routeprocessor worden teruggestuurd over om het even welk van de twee stoffen verbindingswegen tussen de lijnkaartgroef en de actieve routeprocessor. De keuze van welke van de twee te gebruiken koppelingen afhangt van de koppelingsbelasting op dat moment. Het reactiepakket van NP1 naar de stand-by routeprocessor gebruikt beide links, maar één link tegelijk. De keuze van de link is gebaseerd op het headerveld dat de diagnostische toepassing bevolkt.
Fabric-diagnostisch pad
Verwijs naar de sectie van de Analyse van de Kenmerkende Mislukking NP0, maar pas de zelfde redenering voor NP1 (in plaats van NP0) toe.
Dit diagram toont het pakketpad tussen de routeprocessorkaart CPU en de lijnkaart NP2. De koppeling tussen B1 en NP2 is de enige koppeling specifiek voor NP2. Alle andere links vallen in het gemeenschappelijke pad.
Noteer het pakketpad van de routeprocessorkaart naar NP2. Hoewel er vier links te gebruiken zijn voor pakketten die bestemd zijn voor NP2 vanuit de routeprocessor, wordt de eerste link tussen de routeprocessor en de lijnkaartsleuf gebruikt voor het pakket van de routeprocessor naar de lijnkaart. Het teruggekeerde pakket van NP2 kan naar de actieve routeprocessor worden teruggestuurd over om het even welk van de twee stoffen verbindingspaden tussen de lijnkaartsleuf en de actieve routeprocessor. De keuze van welke van de twee te gebruiken koppelingen afhangt van de koppelingsbelasting op dat moment. Het reactiepakket van NP2 naar de stand-by routeprocessor gebruikt beide links, maar één link tegelijk. De keuze van de link is gebaseerd op het headerveld dat de diagnostische toepassing bevolkt.
Fabric-diagnostisch pad
Verwijs naar de sectie van de Analyse van de Kenmerkende Mislukking NP0, maar pas de zelfde redenering voor NP2 (in plaats van NP0) toe.
Dit diagram toont het pakketpad tussen de routeprocessorkaart CPU en de lijnkaart NP3. De koppeling die Bridge ASIC 1 (B1) en NP3 verbindt, is de enige koppeling die specifiek is voor NP3. Alle andere links vallen in het gemeenschappelijke pad.
Noteer het pakketpad van de routeprocessorkaart naar NP3. Hoewel er vier links te gebruiken zijn voor pakketten die bestemd zijn voor NP3 vanuit de routeprocessor, wordt het eerste verband tussen de routeprocessor en de lijnkaartsleuf gebruikt voor het pakket van de routeprocessor naar de lijnkaart. Het teruggekeerde pakket van NP3 kan naar de actieve routeprocessor worden teruggestuurd over om het even welk van de twee stoffen verbindingswegen tussen de lijnkaartgroef en de actieve routeprocessor. De keuze van welke van de twee te gebruiken koppelingen afhangt van de koppelingsbelasting op dat moment. Het reactiepakket van NP3 naar de stand-by routeprocessor gebruikt beide links, maar één link tegelijk. De keuze van de link is gebaseerd op het headerveld dat de diagnostische toepassing bevolkt.
Fabric-diagnostisch pad
Verwijs naar de sectie van de Analyse van de Kenmerkende Mislukking NP0, maar pas de zelfde redenering voor NP3 (in plaats van NP0) toe.
Deze sectie geeft twee voorbeelden om de achtergrond voor fabric punt-pakketten met op tyfoon gebaseerde lijnkaarten vast te stellen. Het eerste voorbeeld gebruikt NP1, en het tweede voorbeeld gebruikt NP3. De beschrijving en analyse kan worden uitgebreid naar andere NP's op elke op Typhoon gebaseerde lijnkaart.
Het volgende diagram toont het pakketpad tussen de routeprocessorkaart CPU en de lijnkaart NP1. De link die FIA0 en NP1 verbindt is de enige link specifiek voor het NP1 pad. Alle andere links tussen de lijnkaartsleuf en de routeprocessorkaartsleuf vallen in het gemeenschappelijke pad. De verbindingen die de stof XBAR ASIC op de lijnkaart met FIAs op de lijnkaart verbinden zijn specifiek voor een ondergroep van NPs. Bijvoorbeeld, beide verbindingen tussen FIA0 en de lokale stof XBAR ASIC op de lijnkaart worden gebruikt voor verkeer naar NP1.
Noteer het pakketpad van de routeprocessorkaart naar NP1. Hoewel er acht links te gebruiken zijn voor pakketten die bestemd zijn voor NP1 vanaf de routeprocessorkaart, wordt één pad tussen de routeprocessorkaart en de lijnkaartsleuf gebruikt. Het teruggekeerde pakket van NP1 kan naar de routeprocessorkaart worden teruggestuurd over acht fabric link paden tussen de lijnkaartsleuf en de routeprocessor. Elk van deze acht verbindingen wordt uitgevoerd één in een tijd wanneer het kenmerkende pakket terug naar de kaart CPU van de routeprocessor bestemd is.
Fabric-diagnostisch pad
Dit diagram toont het pakketpad tussen de routeprocessorkaart CPU en de lijnkaart NP3. De link die FIA1 en NP3 verbindt is de enige link specifiek voor het NP3 pad. Alle andere links tussen de lijnkaartsleuf en de routeprocessorkaartsleuf vallen in het gemeenschappelijke pad. De verbindingen die de stof XBAR ASIC op de lijnkaart met FIAs op de lijnkaart verbinden zijn specifiek voor een ondergroep van NPs. Bijvoorbeeld, beide verbindingen tussen FIA1 en de lokale stof XBAR ASIC op de lijnkaart worden gebruikt voor verkeer naar NP3.
Noteer het pakketpad van de routeprocessorkaart naar NP3. Hoewel er acht links te gebruiken zijn voor pakketten die bestemd zijn voor NP3 vanaf de routeprocessorkaart, wordt één pad tussen de routeprocessorkaart en de lijnkaartsleuf gebruikt. Het teruggekeerde pakket van NP1 kan naar de routeprocessorkaart worden teruggestuurd over acht fabric link paden tussen de lijnkaartsleuf en de routeprocessor. Elk van deze acht verbindingen wordt uitgevoerd één in een tijd wanneer het kenmerkende pakket terug naar de kaart CPU van de routeprocessor bestemd is.
Fabric-diagnostisch pad
Vanwege de 1:1-connectiviteit tussen de FIA en NP is het enige verkeer dat FIA0 doorkruist van/naar NP0.
Aangezien de FIA is geïntegreerd in de NP-chip, is het enige verkeer dat FIA0 doorkruist naar/van NP0.
In dit gedeelte worden fouten gecategoriseerd in harde en tijdelijke gevallen en worden de stappen vermeld die worden gebruikt om te bepalen of een fout een harde of tijdelijke fout is. Zodra het fouttype is bepaald, specificeert het document de opdrachten die op de router kunnen worden uitgevoerd om de fout te begrijpen en welke corrigerende maatregelen nodig zijn.
Als een ingesteld PFM-bericht wordt gevolgd door een duidelijk PFM-bericht, dan is er een fout opgetreden en heeft de router de fout zelf gecorrigeerd. Voorbijgaande fouten kunnen optreden vanwege omgevingsomstandigheden en herstelbare fouten in hardwarecomponenten. Soms kan het moeilijk zijn om tijdelijke fouten te koppelen aan een bepaalde gebeurtenis.
Voor de duidelijkheid wordt hier een voorbeeld van een tijdelijke fabricfout weergegeven:
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)
De voorgestelde benadering voor tijdelijke fouten is om alleen te controleren op het verder voorkomen van dergelijke fouten. Indien een tijdelijke fout zich meer dan één keer voordoet, moet u de tijdelijke fout als een harde fout behandelen en de aanbevelingen en stappen gebruiken om dergelijke fouten te analyseren die in het volgende hoofdstuk worden beschreven.
Als een ingesteld PFM-bericht niet wordt gevolgd door een duidelijk PFM-bericht, is er een fout opgetreden en heeft de router de fout zelf niet gecorrigeerd door de foutverwerkingscode, of kan de aard van de hardwarefout niet worden hersteld. Harde fouten kunnen optreden vanwege omgevingsomstandigheden en niet-herstelbare fouten in hardwarecomponenten. De voorgestelde benadering voor harde fouten is om de richtlijnen te gebruiken die in de sectie Harde fouten analyseren worden vermeld.
Hier wordt een voorbeeld van een defect aan de harde stof voor de duidelijkheid weergegeven. Voor dit voorbeeld is er geen duidelijk PFM-bericht.
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)
In het geval van een harde fout verzamelt u alle opdrachten die in de sectie Gegevens verzamelen voordat u een serviceaanvraag maakt, en opent u een serviceaanvraag. In dringende gevallen, nadat u alle het oplossen van problemen bevel output verzamelt, begin een routeverwerkerkaart of een lijnkaartherladen in werking die op de foutenisolatie wordt gebaseerd. Na het herladen, als de fout niet wordt hersteld, start een Return Material Authorisation (RMA).
Voltooi deze stappen om tijdelijke fouten te analyseren.
show logging | inc “PUNT_FABRIC_DATA_PATH"
bevel om te ontdekken als de fout eens of veelvoud keer voorkwam.show pfm location all
opdracht om de huidige status (SET of CLEAR) te bepalen. Is de fout nog niet opgelost of gewist? Als de foutstatus tussen SET en CLEAR verandert, worden een of meer fouten in het gegevenspad van de stof herhaaldelijk aangetroffen en met behulp van software of hardware gecorrigeerd.show pfm location all
opdrachtoutput, en zoekt periodiek naar de foutstring om het toekomstige optreden van de fout te kunnen bewaken (wanneer de laatste status van de fout DUIDELIJK is en er geen nieuwe fouten optreden).Voer deze opdrachten in om tijdelijke fouten te analyseren:
show logging | inc “PUNT_FABRIC_DATA_PATH”
show pfm location all
Als u de links naar de fabric-datapaden op een lijnkaart ziet als een boom (waar de details worden beschreven in het gedeelte Achtergrondinformatie), moet u - op basis van het foutpunt - afleiden of een of meer NP's ontoegankelijk zijn. Wanneer meerdere fouten optreden op meerdere NP's, gebruikt u de opdrachten die in deze sectie worden vermeld om fouten te analyseren.
Voer deze opdrachten in om harde fouten te analyseren:
show logging | inc “PUNT_FABRIC_DATA_PATH”
show controller fabric fia link-status location
show controller fabric crossbar link-status instance <0 and 1> location
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
Opmerking: Als alle NP's op alle lijnkaarten een fout melden, is de fout waarschijnlijk op de routeprocessorkaart (actieve routeprocessorkaart of stand-by routeprocessorkaart). Raadpleeg de koppeling die de routeprocessorkaart CPU met de FPGA en de routeprocessorkaart FIA verbindt in het gedeelte Achtergrondinformatie.
Historisch gezien is 99 procent van de fouten herstelbaar en in de meeste gevallen worden de fouten verholpen door de door de software geïnitieerde herstelactie. In zeer zeldzame gevallen worden echter onherstelbare fouten waargenomen die alleen kunnen worden opgelost met de RMA van kaarten.
In de volgende paragrafen worden enkele fouten uit het verleden geïdentificeerd die als leidraad kunnen dienen indien soortgelijke fouten worden waargenomen.
Deze berichten worden weergegeven als de fout het gevolg is van NP-overtekening.
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)
Voorbijgaande fouten kunnen moeilijker te bevestigen zijn. Een methode om te bepalen of een NP momenteel overgeabonneerd is of in het verleden overgeabonneerd is, is te controleren op een bepaald soort daling binnen het NP en op staartdruppels in de FIA. Ingress Front Direct Memory Access (IFDMA) daalt in het NP wanneer het NP overgeabonneerd is en het inkomende verkeer niet kan bijhouden. FIA staartdalingen komen voor wanneer een uitgang NP beweert flow control (vraagt de indringingslijnkaart om minder verkeer te verzenden). In het flowcontrolescenario heeft de indringende FIA staartdruppels.
Hierna volgt een voorbeeld:
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 <<<<<
Hierna volgt een voorbeeld:
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
Wanneer PUNT_FABRIC_DATA_PATH_MISLUKTE optreedt, en als de fout te wijten is aan NP snel terugstellen, dan verschijnen logboeken vergelijkbaar met wat hier wordt vermeld voor een op Typhoon gebaseerde lijnkaart. Het gezondheidscontrolemechanisme is beschikbaar op op op tyfoon gebaseerde lijnkaarten, maar niet op op Trident gebaseerde lijnkaarten.
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
Voor op Trident gebaseerde lijnkaarten wordt dit logbestand weergegeven met een snelle reset van een NP:
LC/0/1/CPU0:Mar 29 15:27:43.787 test:
pfm_node_lc[279]: Fast Reset initiated on NP3
Cisco heeft een probleem opgelost waarbij zelden fabric links tussen Route Switch Processor (RSP) 440 en op tyfoon gebaseerde lijnkaarten over de backplane worden getraind. Fabric links worden getraind omdat de signaalsterkte niet optimaal is. Dit probleem is aanwezig in de basissoftwarereleases Cisco IOS® XR 4.2.1, 4.2.2, 4.2.3, 4.3.0, 4.3.1 en 4.3.2. Er wordt een Software Maintenance Update (SMU) voor elk van deze releases geplaatst op Cisco Connection Online en gevolgd met Cisco bug-id CSCuj10837 en Cisco bug-id CSCul39674.
Wanneer deze kwestie op de router voorkomt, kan om het even welk van deze scenario's voorkomen:
Om te bevestigen, verzamel de sporenuitgangen van LC en zowel RSPs (show controller fabric crossbar ltrace location <>
) en controleer of deze uitvoer wordt weergegeven in RSP-lettertypen:
SMU is al beschikbaar
Hierna volgt een voorbeeld:
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.
De term TX-richting verwijst naar de richting vanuit het gezichtspunt van de RSPs dwarsbalk fabric interface naar een fabric dwarsbalk interface op een Typhoon-gebaseerde lijnkaart.
Cisco bug-id CSCuj10837 wordt gekenmerkt door de detectie van een probleem op de RX-link vanaf de RSP en het initiëren van een link-omleiding. Aan beide zijden (LC of RSP) kan de retrain-event worden gestart. In het geval van Cisco bug ID CSCuj10837, start de LC de omleiding en kan worden gedetecteerd door de init xbar_trigger_link_retrain: bericht in de sporen op de 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
Wanneer de LC de retrain start, rapporteert de RSP een rcvd link_retrain in de track output.
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.
Verzamel de overtrek van de lijnkaart en beide RSP’s om dit te bevestigen (show controller fabric crossbar ltrace location <>
) en controleer of deze uitvoer wordt weergegeven in RSP-lettertypen:
Hierna volgt een voorbeeld:
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.
De term RX-richting verwijst naar de richting vanuit het standpunt van de RSPs dwarsbalk fabric interface van een fabric dwarsbalk interface op een Typhoon-gebaseerde lijnkaart.
Cisco bug-id CSCul39674 wordt gekarakteriseerd door de detectie door RSP van een probleem op de RX-link van de tyfoon lijnkaart en de initiatie van een link retrain. Aan beide zijden (LC of RSP) kan de retrain-event worden gestart. In het geval van Cisco bug-ID CSCul39674, start de RSP de omleiding en kan worden gedetecteerd door het init xbar_trigger_link_retrain: bericht in de sporen op de 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
Wanneer de RSP de retrain start, meldt de LC een rcvd link_retrain-gebeurtenis in de track-uitvoer.
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.
Er is veel werk verricht om de tijd te verkorten die nodig is om een fabric link in Cisco IOS XR release 4.3.2 en hoger te trainen. De stof retraint nu in subsecondentijden en is onwaarneembaar voor verkeersstromen. In Cisco IOS XR-release 4.3.2 worden alleen deze syslog-berichten gezien wanneer een hertraining van de fabric link heeft plaatsgevonden.
%PLATFORM-FABMGR-5-FABRIC_TRANSIENT_FAULT : Fabric backplane crossbar link
underwent link retraining to recover from a transient error: Physical slot 1
Cisco heeft een probleem opgelost waarbij de Fabric ASIC (FIA) kan worden hersteld vanwege een niet-herstelbare First In First Out (FIFO) overflow-voorwaarde. Dit wordt geadresseerd met Cisco bug-id CSC66510. Dit probleem heeft alleen betrekking op de op Trident gebaseerde lijnkaarten en wordt alleen in zeldzame gevallen met zware congestie van de ingangsweg aangetroffen. Als dit probleem wordt aangetroffen, wordt dit syslogbericht weergegeven voordat de lijnkaart wordt hersteld om te herstellen van de conditie.
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
Cisco heeft een probleem opgelost waar uitgebreide zware congestie kan leiden tot uitputting van fabricbronnen en verkeersverlies. Het verkeersverlies kan zelfs optreden bij niet-gerelateerde stromen. Dit probleem wordt aangepakt met Cisco bug-id CSC90300 en wordt opgelost in Cisco IOS XR release 4.3.2 en hoger. De fix wordt ook geleverd in Cisco IOS XR release 4.2.3 CSMU#3, Cisco bug-id CSCui3805. Dit zeldzame probleem kan worden aangetroffen op Trident- of Typhoon-gebaseerde lijnkaarten.
Verzamel uitvoer van deze opdrachten:
show tech-support fabric
show controller fabric fia bridge flow-control location
<=== Ontvang deze uitvoer voor alle LC’sshow controllers fabric fia q-depth location
Hier zijn een paar voorbeelden van output:
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#
Onder normale omstandigheden is het zeer onwaarschijnlijk om een VOQ met pakketten in de rij te zien staan. Deze opdracht is een snelle realtime snapshot van de FIA-wachtrijen. Het is gebruikelijk dat deze opdracht geen pakketten in de wachtrij toont.
Zachte fouten zijn niet-permanente fouten die ervoor zorgen dat de toestandsmachine niet goed kan worden gesynchroniseerd. Deze worden gezien als Cyclic Redundancy Check (CRC), Frame Check Sequence (FCS) of foutpakketten aan de fabrickant van het NP of aan de ingangskant van de FIA.
Hier zijn een paar voorbeelden van hoe dit probleem kan worden gezien:
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 <==========
Verzamel uitvoer van deze opdrachten:
show tech-support fabric
show tech-support np
show controller fabric fia bridge stats location <>
(diverse keren ophalen)De terugwinningsmethode is de beïnvloede lijnkaart te herladen.
RP/0/RSP0/CPU0:asr9k-1#hw-module location 0/6/cpu0 reload
Het show diagnostic result location
De opdracht geeft een samenvatting van alle online diagnostische tests en storingen, evenals de laatste tijdstempel wanneer een test succesvol is. De Test-ID voor het punt fabric data path fout is tien. Een lijst van alle tests samen met de frequentie van de testpakketten kan worden gezien met de show diagnostic content location
uit.
De output van het testresultaat van de puntfabric-gegevenspad is gelijk aan deze voorbeelduitvoer:
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
Zoals beschreven in Cisco bug ID CSCuc04493, is er nu een manier om de router automatisch alle poorten die zijn gekoppeld aan de PUNT_FABRIC_DATA_PATH-fouten die zijn gemaakt op Active RP/RSP te laten sluiten.
De eerste methode wordt gevolgd via Cisco bug-id CSC04493. Voor versie 4.2.3 is dit opgenomen in Cisco bug-id CSC3805. In deze versie is ingesteld dat alle poorten die zijn gekoppeld aan de NP's die worden beïnvloed, automatisch worden uitgeschakeld.
Hier is een voorbeeld dat toont hoe de syslogs zouden verschijnen:
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
De controller geeft aan dat de reden waarom de interface niet actief is, ligt aan DATA_PATH_DOWN
. Hierna volgt een voorbeeld:
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
In versies 4.3.1 en hoger moet dit gedrag worden ingeschakeld. Er is een nieuw admin-config commando dat wordt gebruikt om dit te realiseren. Aangezien het standaardgedrag niet langer is om de poorten af te sluiten, moet dit handmatig worden ingesteld.
RP/0/RSP1/CPU0:ASR9010-A(admin-config)#fault-manager datapath port ?
shutdown Enable auto shutdown
toggle Enable auto toggle port status
Op 64-bits Cisco IOS XR is de configuratieopdracht beschikbaar in de XR VM (niet in de Sysadmin VM):
RP/0/RSP0/CPU0:CORE-TOP(config)#fault-manager datapath port ?
shutdown Enable auto shutdown
toggle Enable auto toggle port status
Cisco bug-id CSCui15435 adresseert de zachte fouten die worden gezien op de op Trident gebaseerde lijnkaarten, zoals beschreven in de sectie Traffic Impact Due to Bridge/FPGA Soft Errors on Trident-Based Line Cards. Dit gebruikt een andere detectiemethode dan de gebruikelijke diagnostische methode die wordt beschreven in Cisco bug-id CSC04493.
Deze bug introduceerde ook een nieuwe admin-config CLI opdracht:
(admin-config)#fabric fia soft-error-monitor <1|2> location
1 = shutdown the ports
2 = reload the linecard
Default behavior: no action is taken.
Wanneer deze fout wordt aangetroffen, kan deze syslog worden waargenomen:
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)
Wanneer de betreffende poorten worden uitgeschakeld, kan de netwerkredundantie het overnemen en zwart verkeer voorkomen. Om te herstellen, moet de lijnkaart worden herladen.
Q. Verstuurt de primaire of standby routeprocessorkaart de keepalives of online diagnostische pakketten naar elke NP in het systeem?
A. Ja. Beide routeprocessorkaarten verzenden online diagnostische pakketten naar elke NP.
Q. Is het pad hetzelfde wanneer de routeprocessorkaart één (RSP1) actief is?
A. Het diagnostische pad is hetzelfde voor RSP0 of RSP1. Het pad is afhankelijk van de status van de RSP. Raadpleeg het gedeelte Punt Fabric Diagnostic Packet Path van dit document voor meer informatie.
Q. Hoe vaak verzenden RSPs diagnostische pakketten, en hoeveel diagnostische pakketten moeten worden gemist alvorens een alarm wordt teweeggebracht?
A. Elke RSP stuurt onafhankelijk een diagnostisch pakket naar elk NP eenmaal per minuut. Ofwel RSP kan een alarm activeren als drie diagnostische pakketten niet worden erkend.
Q. Hoe bepaalt u of een NP is of is overschreven?
A. Een manier om te controleren of een NP momenteel overgeabonneerd is of in het verleden overgeabonneerd is, is te controleren op een bepaald soort daling in het NP en op staartdruppels in de FIA. Ingress Front Direct Memory Access (IFDMA) daalt in het NP wanneer het NP overgeabonneerd is en het inkomende verkeer niet kan bijhouden. FIA staartdalingen komen voor wanneer een uitgang NP beweert flow control (vraagt toegang lijnkaart om minder verkeer te verzenden). In het flowcontrolescenario heeft de indringende FIA staartdruppels.
Q. Hoe bepaalt u als een NP een fout lijdt die vereist dat het wordt teruggesteld?
A. Doorgaans wordt een NP-fout gewist door een snelle reset. De reden voor een snelle reset wordt weergegeven in de logbestanden.
V. Is het mogelijk om een NP handmatig te resetten?
A. Ja, vanaf lijnkaart KSH:
run attach 0/[x]/CPU0 #show_np -e [np#] -d fast_reset
Q. Wat toont als een NP een niet-terugvorderbare hardwaremislukking heeft?
A. U ziet zowel een fout in het gegevenspad van het punt voor dat NP als een fout in de NP loopback test. De foutmelding voor de NP-loopback-test wordt in de sectie Bijlage van dit document besproken.
Q. Zal een diagnostiekpakket dat van één kaart van de routeprocessor afkomstig is terugkomen aan zelfde?
A. Aangezien diagnostische pakketten afkomstig zijn van beide routeprocessorkaarten en worden bijgehouden per routeprocessorkaart, wordt een diagnostisch pakket afkomstig van een routeprocessorkaart door het NP teruggekoppeld naar dezelfde routeprocessorkaart.
Q. De Cisco bug-id CSCuj10837 SMU biedt een oplossing voor de fabric link retrain-gebeurtenis. Is dit de oorzaak en oplossing voor vele fouten in het pad van de puntfabric data?
A. Ja, het is vereist om het vervangende SMU voor Cisco bug-id CSCul39674 te laden om omleidingsgebeurtenissen voor de fabric link te voorkomen.
V. Hoe lang duurt het om verbindingen opnieuw te trainen wanneer de beslissing om dit te doen is genomen?
A. Het besluit om te retrainen wordt genomen zodra een koppelingsmislukking wordt ontdekt. Vóór release 4.3.2 kon de omscholing enkele seconden duren. Na release 4.3.2 is de omscholingstijd aanzienlijk verbeterd en duurt dit minder dan een seconde.
Q. Op welk punt wordt het besluit om een stofverbinding om te scholen gemaakt?
A. Zodra de koppelingsfout wordt gedetecteerd, wordt de beslissing om te hertrainen genomen door de ASIC-stuurprogramma van de stof.
Q. Is het alleen tussen de FIA op een actieve routeprocessorkaart en de stof die u de eerste link gebruikt, en daarna is het de minst geladen link wanneer er meerdere links beschikbaar zijn?
A. Correct. De eerste link die verbinding maakt met de eerste XBAR-instantie op de actieve routeprocessor wordt gebruikt om verkeer in de stof te injecteren. Het reactiepakket van NP kan terug naar de actieve kaart van de routeprocessor op om het even welke verbindingen bereiken die met de kaart van de routeprocessor verbinden. De keuze van de link is afhankelijk van de linkbelasting.
Q. Tijdens de omscholing, zijn alle pakketten die over die stoffenverbinding worden verzonden verloren?
A. Ja, maar met de verbeteringen in release 4.3.2 en hoger is de omleiding vrijwel niet te detecteren. In eerdere code kan het echter enkele seconden duren om opnieuw te trainen, wat resulteerde in verloren pakketten voor dat tijdframe.
V. Hoe vaak verwacht u een XBAR fabric link retrain-gebeurtenis te zien nadat u hebt geupgrade naar een release of SMU met de fix voor Cisco bug ID CSCuj10837?
A. Zelfs met de oplossing voor Cisco bug-id CSCuj10837 is het nog steeds mogelijk om herhalingen van de fabric link te zien als gevolg van Cisco bug-id CSCul39674. Maar zodra u de oplossing voor Cisco bug-id CSC39674 hebt, moet de omscholing van de fabric link op de backplane links van de stof tussen RSP440 en op tyfoon gebaseerde lijnkaarten nooit plaatsvinden. Als dat wel het geval is, dient u een serviceverzoek in bij het Cisco Technical Assistance Center (TAC) om het probleem te kunnen oplossen.
V. Hebben Cisco bug-id CSCuj10837 en Cisco bug-id CSCul39674 invloed op de RP op de ASR 9922 met op tyfoon gebaseerde lijnkaarten?
A. Ja
V. Hebben Cisco bug-ID CSCuj10837 en Cisco bug-id CSCul39674 invloed op de ASR-9001- en ASR-9001-S routers?
A. Nee
Q. Als u de mislukking van een groef tegenkomt die niet met dit bericht bestaat, "PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_MISLUKTE: Set|online_diag_rsp[237686]|System Punt/Fabric/data Path Test(0x2000004)|faaldrempel is 3, (groef, NP) ontbrak: (8, 0),"in een chassis met 10 sleuven, welke groef heeft het probleem?
A. In eerdere releases, moet u rekening houden met de fysieke en logische toewijzingen zoals hier getoond. In dit voorbeeld komt sleuf 8 overeen met 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
Dit zijn de minimale opdrachten om uitvoer te verzamelen voordat er enige actie wordt ondernomen:
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
Hier is een lijst van opdrachten die nuttig zijn voor diagnostische doeleinden:
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 >
admin diagnostic ondemand action-on-failure {continue failure-count|stop}
[ no ] diagnostic monitor location < loc > test {id | test-name} [disable]
[ no ] diagnostic monitor interval location < loc > test {id | test-name} day hour:minute:second.millisec
[ no ] diagnostic monitor threshold location < loc > test {id | test-name} failure count
Vanuit het tijdframe van Cisco IOS XR-softwarerelease 4.3.4 worden de meeste problemen met betrekking tot fouten in het gegevenspad van puntverbindingen aangepakt. Voor routers die worden beïnvloed door Cisco bug-id CSCuj10837 en Cisco bug-id CSC39674, laadt u de overkoepelende SMU voor Cisco bug-id CSCul39674 om omleidingsgebeurtenissen voor de fabric te voorkomen.
Het platformteam heeft state-of-the-art foutenbehandeling geïnstalleerd zodat de router zich in subseconden herstelt als en wanneer er een gegevenspad herstelbare fout optreedt. Dit document wordt echter aanbevolen om dit probleem te begrijpen, ook al wordt een dergelijke fout niet waargenomen.
De diagnostische toepassing die op de lijnkaart CPU wordt uitgevoerd volgt de gezondheid van elk NP met periodieke controles van de werkstatus van het NP. Een pakket wordt ingespoten van de lijnkaart CPU bestemd voor het lokale NP, dat het NP zou moeten terugkoppelen en terugkeren naar de lijnkaart CPU. Elk verlies in dergelijke periodieke pakketten wordt gemarkeerd met een platformlogboekbericht. Hier is een voorbeeld van zo'n boodschap:
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
Dit logbericht betekent dat deze test er niet in is geslaagd het loopback-pakket van NP3 te ontvangen. Het masker van de verbindingsmislukking is 0x8 (beetje 3 wordt geplaatst), wat op een mislukking tussen lijnkaart CPU voor groef 7 en NP3 op groef 7 wijst.
Verzamel de uitvoer van deze opdrachten om meer informatie te verkrijgen:
admin show diagnostic result location 0/
/cpu0 test 9 detail
show controllers NP counter NP<0-3> location 0/
/cpu0
De opdrachten die in deze sectie worden vermeld, zijn zowel van toepassing op alle op Trident gebaseerde lijnkaarten als op de op Typhoon gebaseerde 100GE lijnkaart. De Bridge FPGA ASIC is niet aanwezig op op tyfoon gebaseerde lijnkaarten (behalve voor de op 100 GE tyfoon gebaseerde lijnkaarten). De show controller fabric fia bridge
De opdrachten zijn niet van toepassing op op Typhoon gebaseerde lijnkaarten, behalve voor de 100GE versies.
Deze afbeelding representatie helpt om elke show commando in kaart te brengen naar de locatie in het gegevenspad. Gebruik deze showbevelen om pakketdruppels en fouten te isoleren.
Revisie | Publicatiedatum | Opmerkingen |
---|---|---|
2.0 |
26-Jun-2023 |
Werkte de sectie van de Verbeteringen van het Automatische Herstel voor Cisco bug-ID CSCuc04493 bij en werkte de sectie FAQ bij. |
1.0 |
29-Oct-2013 |
Eerste vrijgave |