Para parceiros
The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
A Cisco traduziu este documento com a ajuda de tecnologias de tradução automática e humana para oferecer conteúdo de suporte aos seus usuários no seu próprio idioma, independentemente da localização. Observe que mesmo a melhor tradução automática não será tão precisa quanto as realizadas por um tradutor profissional. A Cisco Systems, Inc. não se responsabiliza pela precisão destas traduções e recomenda que o documento original em inglês (link fornecido) seja sempre consultado.
Este documento descreve as mensagens de falha de caminho de dados punt fabric observadas durante a operação do Cisco Aggregation Services Router (ASR) 9000 Series. A mensagem aparece neste formato:
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)
Este documento destina-se a qualquer pessoa que queira entender a mensagem de erro e as ações que devem ser tomadas se o problema for visto.
A Cisco recomenda que você tenha um conhecimento de alto nível destes tópicos:
No entanto, este documento não exige que os leitores estejam familiarizados com os detalhes do hardware. As informações de fundo necessárias são fornecidas antes que a mensagem de erro seja explicada. Este documento descreve o erro nas placas de linha baseadas em Trident e Typhon. Consulte Tipos de Placa de Linha ASR 9000 Series para obter uma explicação sobre esses termos.
Este documento não se restringe a versões de software e hardware específicas.
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.
Considere estas sugestões sobre como usar este documento para obter detalhes essenciais e como um guia de referência no processo de solução de problemas:
Um pacote pode percorrer dois saltos ou três saltos através da matriz de comutação com base no tipo de placa de linha. As placas de linha de geração de tufão adicionam um elemento extra de matriz de comutação, enquanto as placas de linha baseadas em Trident comutam todo o tráfego com a estrutura apenas na placa de processador de rotas. Esses diagramas mostram elementos de estrutura para ambos os tipos de placas de linha, assim como conectividade de estrutura para a placa de processador de rota:
O aplicativo de diagnóstico executado na CPU da placa do processador de rota injeta pacotes de diagnóstico destinados a cada NP (Network Processor, processador de rede) periodicamente. O pacote de diagnóstico tem loopback dentro do NP e é injetado novamente na CPU da placa do processador de rota que originou o pacote. Essa verificação de integridade periódica de cada NP com um pacote exclusivo por NP pelo aplicativo de diagnóstico na placa do processador de rotas fornece um alerta para quaisquer erros funcionais no caminho de dados durante a operação do roteador. É essencial observar que o aplicativo de diagnóstico no processador de rota ativa e no processador de rota de standby injeta um pacote por NP periodicamente e mantém uma contagem de êxito ou falha por NP. Quando um limite de pacotes de diagnóstico descartados é atingido, o aplicativo gera uma falha.
Antes que o documento descreva o caminho de diagnóstico nas placas de linha baseadas em Trident e Typhon, esta seção fornece um esboço geral do caminho de diagnóstico de estrutura das placas de processador de rota ativa e standby para o NP na placa de linha.
Os pacotes de diagnóstico injetados do processador de rota ativo na estrutura em direção ao NP são tratados como pacotes unicast pela matriz de comutação. Com pacotes unicast, a matriz de comutação escolhe o enlace de saída com base na carga de tráfego atual do enlace, o que ajuda a submeter pacotes de diagnóstico à carga de tráfego no roteador. Quando há vários links de saída para o NP, o ASIC da matriz de comutação escolhe um link que atualmente é o menos carregado.
Este diagrama descreve o caminho do pacote de diagnóstico originado do processador de rota ativo.
Note: O primeiro link que conecta o ASIC de Interface de Estrutura (FIA - Fabric Interface ASIC) na placa de linha à barra cruzada (XBAR - Crossbar) na placa do processador de rota é escolhido o tempo todo para pacotes destinados ao NP. Os pacotes de resposta do NP são submetidos a um algoritmo de distribuição de carga de enlace (se a placa de linha for baseada em tufão). Isso significa que o pacote de resposta do NP para o processador de rota ativo pode escolher qualquer um dos links de estrutura que conectam as placas de linha à placa do processador de rota com base na carga do link de estrutura.
Os pacotes de diagnóstico injetados do processador de rota de standby na estrutura em direção ao NP são tratados como pacotes multicast pela matriz de comutação. Embora seja um pacote multicast, não há replicação dentro da estrutura. Cada pacote de diagnóstico originado do processador de rota de standby ainda alcança apenas um NP por vez. O pacote de resposta do NP para o processador de rota também é um pacote multicast sobre a estrutura sem replicação. Assim, o aplicativo de diagnóstico no processador de rota de standby recebe um único pacote de resposta dos NPs, um pacote por vez. O aplicativo de diagnóstico rastreia cada NP no sistema, pois injeta um pacote por NP, e espera respostas de cada NP, um pacote por vez. Com um pacote multicast, a matriz de comutação escolhe o enlace de saída com base em um valor de campo no cabeçalho do pacote, o que ajuda a injetar pacotes de diagnóstico em cada enlace de estrutura entre a placa do processador de rota e a placa de linha. O processador de rota de standby rastreia a integridade do NP em cada link de estrutura que se conecta entre a placa do processador de rota e o slot da placa de linha.
O diagrama anterior descreve o caminho do pacote de diagnóstico originado do processador de rota de standby. Observe que, ao contrário do caso do processador de rota ativo, todos os links que conectam a placa de linha ao XBAR no processador de rota são exercitados. Os pacotes de resposta do NP levam o mesmo link de estrutura que foi usado pelo pacote no processador de rota para a direção da placa de linha. Esse teste garante que todos os links que conectam o processador de rota de standby à placa de linha sejam monitorados continuamente.
Este diagrama descreve os pacotes de diagnóstico originados pelo processador de rotas destinados a um NP que tem loopback em direção ao processador de rotas. É importante observar os enlaces de caminho de dados e os ASICs que são comuns a todos os NPs, bem como os enlaces e os componentes que são específicos para um subconjunto de NPs. Por exemplo, o Bridge ASIC 0 (B0) é comum a NP0 e NP1, enquanto FIA0 é comum a todos os NPs. Na extremidade do processador de rota, todos os links, ASICs de caminho de dados e FPGA (Field-Programmable Gate Array) são comuns a todas as placas de linha e, portanto, a todos os NPs em um chassi.
Este diagrama descreve os pacotes de diagnóstico originados da placa do processador de rota destinados a um NP que está em loop em direção ao processador de rota. É importante observar os enlaces de caminho de dados e os ASICs que são comuns a todos os NPs, bem como os enlaces e os componentes que são específicos para um subconjunto de NPs. Por exemplo, FIA0 é comum a NP0 e NP1. Na extremidade da placa do processador de rotas, todos os links, ASICs de caminho de dados e FGPA são comuns a todas as placas de linha e, portanto, a todos os NPs em um chassi.
Nas placas de linha Tomahawk há conectividade 1:1 entre o FIA e o NP.
Nas placas de linha Lightspeed e LightspeedPlus, o FIA está integrado no chip NP.
As próximas seções tentam representar o caminho do pacote para cada NP. Isso é necessário para entender a mensagem de erro de caminho de dados da malha punt e também para localizar o ponto de falha.
A falha em obter respostas de um NP em um roteador baseado em ASR 9000 resulta em um alarme. A decisão de disparar um alarme pelo aplicativo de diagnóstico on-line que é executado no processador de rotas ocorre quando há três falhas consecutivas. O aplicativo de diagnóstico mantém uma janela de falha de três pacotes para cada NP. O processador de rota ativa e o processador de rota de standby fazem o diagnóstico independente e em paralelo. O processador de rota ativo, o processador de rota em standby ou ambas as placas do processador de rota podem relatar o erro. O local da falha e a perda de pacotes determinam qual processador de rotas relata o alarme.
A frequência padrão do pacote de diagnóstico para cada NP é um pacote por 60 segundos ou um por minuto.
Aqui está o formato da mensagem de alarme:
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)
A mensagem deve ser lida como uma falha ao acessar NP 1, 2, 3, 4, 5, 6 e 7 na placa de linha 0/7/cpu0 do processador de rota 0/rsp0/cpu0.
Na lista de testes de diagnóstico on-line, você pode ver os atributos do teste de loopback de estrutura punt com este 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)#
A saída mostra que a frequência de teste PuntFabricDataPath é de um pacote a cada minuto, e o limiar de falha é três, o que implica que a perda de três pacotes consecutivos não é tolerada e resulta em um alarme. Os atributos de teste mostrados são valores padrão. Para alterar os padrões, insira os comandos diagnostic monitor interval e diagnostic monitor threshold no modo de configuração de administração.
Caminho de diagnóstico de estrutura
Este diagrama descreve o caminho do pacote entre a CPU do processador de rota e a placa de linha NP0. O link que conecta B0 e NP0 é o único link específico para NP0. Todos os outros links estão no caminho comum.
Anote o caminho do pacote do processador de rota para NP0. Embora existam quatro links para serem usados para pacotes destinados ao NP0 do processador de rota, o primeiro link entre o processador de rota e o slot da placa de linha é usado para o pacote do processador de rota em direção à placa de linha. O pacote devolvido de NP0 pode ser enviado de volta ao processador de rota ativo por qualquer um dos dois caminhos de link de estrutura entre o slot da placa de linha e o processador de rota ativo. A escolha de qual dos dois links usar depende da carga do link no momento. O pacote de resposta de NP0 para o processador de rota de standby usa ambos os links, mas um link por vez. A escolha do link é baseada no campo de cabeçalho que o aplicativo de diagnóstico preenche.
Se um alarme de falha de caminho de dados punt PFM (Platform Fault Manager) único com NP0 na mensagem de falha for detectado, a falha estará somente no caminho de estrutura que conecta o processador de rota e a placa de linha NP0. Isso é uma única falha. Se a falha for detectada em mais de um NP, consulte a seção Cenário de falha múltipla.
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)
Note: Esta seção do documento se aplica a qualquer slot de placa de linha em um chassi, independentemente do tipo de chassi. Portanto, isso pode ser aplicado a todos os slots de placas de linha.
Como ilustrado no diagrama de caminho de dados anterior, a falha deve estar em um ou mais desses locais:
Várias falhas de NP
Quando outras falhas são observadas em NP0 ou a falha PUNT_FABRIC_DATA_PATH_FAILED também é reportada por outros NPs na mesma placa de linha, o isolamento de falhas é feito correlacionando todas as falhas. Por exemplo, se tanto a falha PUNT_FABRIC_DATA_PATH_FAILED quanto a falha LC_NP_LOOPBACK_FAILED ocorrerem em NP0, o NP parou de processar pacotes. Consulte a seção Caminho de Diagnóstico de LoopBack NP para entender a falha de loopback. Isso pode ser uma indicação precoce de uma falha crítica dentro de NP0. No entanto, se apenas uma das duas falhas ocorrer, a falha será localizada no caminho de dados da malha punt ou na CPU da placa de linha para o caminho NP.
Se mais de um NP em uma placa de linha tiver uma falha de caminho de dados de estrutura punt, você deverá percorrer o caminho de árvore dos links de estrutura para isolar um componente defeituoso. Por exemplo, se ambos NP0 e NP1 tiverem uma falha, a falha deve estar em B0 ou no link que conecta B0 e FIA0. É menos provável que tanto NP0 quanto NP1 encontrem um erro interno crítico ao mesmo tempo. Embora seja menos provável, é possível que NP0 e NP1 encontrem uma falha crítica de erro devido ao processamento incorreto de um tipo específico de pacote ou de um pacote inválido.
As duas placas de processador de rota relatam uma falha
Se as placas do processador de rota ativa e de standby relatarem uma falha para um ou mais NPs em uma placa de linha, verifique todos os links e componentes comuns no caminho de dados entre os NPs afetados e ambas as placas do processador de rota.
Este diagrama descreve o caminho do pacote entre a CPU da placa do processador de rota e a placa de linha NP1. O link que conecta o Bridge ASIC 0 (B0) e NP1 é o único link específico do NP1. Todos os outros links estão no caminho comum.
Anote o caminho do pacote da placa do processador de rota para NP1. Embora existam quatro links para serem usados para pacotes destinados ao NP0 do processador de rota, o primeiro link entre o processador de rota e o slot da placa de linha é usado para o pacote do processador de rota em direção à placa de linha. O pacote devolvido do NP1 pode ser enviado de volta ao processador de rota ativo por qualquer um dos dois caminhos de link de estrutura entre o slot da placa de linha e o processador de rota ativo. A escolha de qual dos dois links usar depende da carga do link no momento. O pacote de resposta do NP1 para o processador de rota de standby usa ambos os links, mas um link por vez. A escolha do link é baseada no campo de cabeçalho que o aplicativo de diagnóstico preenche.
Caminho de diagnóstico de estrutura
Consulte a seção NP0 Diagnostic Failure Analysis, mas aplique o mesmo raciocínio para NP1 (em vez de NP0).
Este diagrama descreve o caminho do pacote entre a CPU da placa do processador de rota e a placa de linha NP2. O link que conecta B1 e NP2 é o único link específico para NP2. Todos os outros links estão no caminho comum.
Anote o caminho do pacote da placa do processador de rota para NP2. Embora existam quatro links para serem usados para pacotes destinados ao NP2 do processador de rota, o primeiro link entre o processador de rota e o slot da placa de linha é usado para o pacote do processador de rota em direção à placa de linha. O pacote devolvido do NP2 pode ser enviado de volta ao processador de rota ativo por qualquer um dos dois caminhos de link de estrutura entre o slot da placa de linha e o processador de rota ativo. A escolha de qual dos dois links usar depende da carga do link no momento. O pacote de resposta do NP2 para o processador de rota de standby usa ambos os links, mas um link por vez. A escolha do link é baseada no campo de cabeçalho que o aplicativo de diagnóstico preenche.
Caminho de diagnóstico de estrutura
Consulte a seção NP0 Diagnostic Failure Analysis, mas aplique o mesmo raciocínio para NP2 (em vez de NP0).
Este diagrama descreve o caminho do pacote entre a CPU da placa do processador de rota e a placa de linha NP3. O link que conecta o Bridge ASIC 1 (B1) e NP3 é o único link específico do NP3. Todos os outros links estão no caminho comum.
Anote o caminho do pacote da placa do processador de rota para NP3. Embora existam quatro links para serem usados para pacotes destinados ao NP3 do processador de rota, o primeiro link entre o processador de rota e o slot da placa de linha é usado para o pacote do processador de rota em direção à placa de linha. O pacote devolvido do NP3 pode ser enviado de volta ao processador de rota ativo por qualquer um dos dois caminhos de link de estrutura entre o slot da placa de linha e o processador de rota ativo. A escolha de qual dos dois links usar depende da carga do link no momento. O pacote de resposta de NP3 para o processador de rota de standby usa ambos os links, mas um link por vez. A escolha do link é baseada no campo de cabeçalho que o aplicativo de diagnóstico preenche.
Caminho de diagnóstico de estrutura
Consulte a seção NP0 Diagnostic Failure Analysis, mas aplique o mesmo raciocínio para NP3 (em vez de NP0).
Esta seção fornece dois exemplos para estabelecer o plano de fundo para pacotes punt de estrutura com placas de linha baseadas em tufão. O primeiro exemplo usa NP1 e o segundo exemplo usa NP3. A descrição e a análise podem ser estendidas para outros NPs em qualquer placa de linha baseada em tufão.
O próximo diagrama descreve o caminho do pacote entre a CPU da placa do processador de rota e a placa de linha NP1. O link que conecta o FIA0 e o NP1 é o único link específico para o caminho NP1. Todos os outros links entre o slot da placa de linha e o slot da placa do processador de rota se encaixam no caminho comum. Os links que conectam o ASIC XBAR de estrutura na placa de linha aos FIAs na placa de linha são específicos para um subconjunto de NPs. Por exemplo, ambos os links entre FIA0 e XBAR ASIC de estrutura local na placa de linha são usados para tráfego para NP1.
Anote o caminho do pacote da placa do processador de rota para NP1. Embora existam oito links para serem usados para pacotes destinados ao NP1 da placa do processador de rotas, um único caminho entre a placa do processador de rotas e o slot da placa de linha é usado. O pacote devolvido de NP1 pode ser enviado de volta à placa do processador de rotas por oito caminhos de link de estrutura entre o slot da placa de linha e o processador de rota. Cada um desses oito links é exercido um por vez quando o pacote de diagnóstico é destinado de volta à CPU da placa do processador de roteamento.
Caminho de diagnóstico de estrutura
Este diagrama descreve o caminho do pacote entre a CPU da placa do processador de rota e a placa de linha NP3. O link que conecta o FIA1 e o NP3 é o único link específico para o caminho NP3. Todos os outros links entre o slot da placa de linha e o slot da placa do processador de rota se encaixam no caminho comum. Os links que conectam o ASIC XBAR de estrutura na placa de linha aos FIAs na placa de linha são específicos para um subconjunto de NPs. Por exemplo, ambos os links entre o FIA1 e o XBAR ASIC de estrutura local na placa de linha são usados para tráfego para NP3.
Anote o caminho do pacote da placa do processador de rota para NP3. Embora existam oito links para serem usados para pacotes destinados ao NP3 da placa do processador de rotas, um único caminho entre a placa do processador de rotas e o slot da placa de linha é usado. O pacote devolvido de NP1 pode ser enviado de volta à placa do processador de rotas por oito caminhos de link de estrutura entre o slot da placa de linha e o processador de rota. Cada um desses oito links é exercido um por vez quando o pacote de diagnóstico é destinado de volta à CPU da placa do processador de roteamento.
Caminho de diagnóstico de estrutura
Devido à conectividade 1:1 entre o FIA e o NP, o único tráfego que atravessa o FIA0 é para/do NP0.
Como o FIA está integrado no chip NP, o único tráfego que atravessa o FIA0 é para/do NP0.
Esta seção categoriza falhas em casos duros e transitórios e lista as etapas usadas para identificar se uma falha é uma falha difícil ou transitória. Uma vez determinado o tipo de falha, o documento especifica os comandos que podem ser executados no roteador para entender a falha e quais ações corretivas são necessárias.
Se uma mensagem PFM definida for seguida de uma mensagem PFM clara, uma falha ocorreu e o roteador corrigiu a própria falha. Falhas transitórias podem ocorrer devido a condições ambientais e falhas recuperáveis em componentes de hardware. Às vezes, pode ser difícil associar falhas transitórias a qualquer evento específico.
Um exemplo de uma falha transitória da estrutura é listado aqui para maior clareza:
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)
A abordagem sugerida para os erros transitórios consiste em apenas monitorizar a ocorrência de novos erros. Se uma falha transitória ocorrer mais de uma vez, trate a falha transitória como uma falha difícil e use as recomendações e etapas para analisar essas falhas descritas na próxima seção.
Se uma mensagem PFM definida não for seguida por uma mensagem PFM nítida, uma falha ocorreu e o roteador não corrigiu a falha por si mesmo pelo código de tratamento de falhas, ou a natureza da falha de hardware não é recuperável. Falhas graves podem ocorrer devido a condições ambientais e falhas irrecuperáveis em componentes de hardware. A abordagem sugerida para falhas duras é usar as diretrizes mencionadas na seção Analisar falhas físicas.
Um exemplo de falha de tela dura está listado aqui para esclarecer. Para esta mensagem de exemplo, não há uma mensagem PFM clara correspondente.
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)
Em um cenário de falha difícil, reúna todos os comandos mencionados na seção Dados a serem coletados antes da criação da solicitação de serviço e abra uma solicitação de serviço. Em casos urgentes, depois de coletar toda a saída do comando de solução de problemas, inicie uma placa de processador de rota ou uma recarga de placa de linha com base no isolamento de falha. Após o recarregamento, se o erro não for recuperado, inicie uma RMA (Return Material Authorization, Autorização de devolução de material).
Conclua estes passos para analisar falhas transitórias.
Insira estes comandos para analisar falhas transitórias:
Se você visualizar os links de caminho de dados de estrutura em uma placa de linha como uma árvore (onde os detalhes são descritos na seção Informações de Fundo), então você deve inferir - com base no ponto de falha - se um ou mais NPs estão inacessíveis. Quando várias falhas ocorrerem em vários NPs, use os comandos listados nesta seção para analisar falhas.
Insira estes comandos para analisar falhas físicas:
Note: Se todos os NPs em todas as placas de linha relatarem uma falha, a falha provavelmente está na placa do processador de rota (placa do processador de rota ativo ou placa do processador de rota em standby). Consulte o link que conecta a CPU da placa do processador de rota ao FPGA e a placa do processador de rota FIA na seção Informações de Fundo.
Historicamente, 99% das falhas são recuperáveis e, na maioria dos casos, a ação de recuperação iniciada por software corrige as falhas. No entanto, em casos muito raros, erros irrecuperáveis são observados que só podem ser corrigidos com a RMA das placas.
As próximas seções identificam algumas falhas anteriores encontradas para servir de orientação se erros semelhantes forem observados.
Essas mensagens serão exibidas se o erro for devido à sobreassinatura 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)
Falhas transitórias podem ser mais difíceis de confirmar. Um método para determinar se um NP está atualmente com excesso de assinaturas ou se foi com excesso de assinaturas no passado é verificar se há um certo tipo de queda dentro do NP e para quedas de cauda no FIA. O IFDMA (Access de memória direta frontal de entrada) cai dentro do NP ocorre quando o NP está com excesso de assinaturas e não consegue acompanhar o tráfego de entrada. As quedas traseiras do FIA ocorrem quando um NP de saída garante o controle de fluxo (pede que a placa de linha de entrada envie menos tráfego). Sob o cenário de controle de fluxo, o FIA de ingresso tem quedas traseiras.
Aqui está um exemplo:
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 <<<<<
Aqui está um exemplo:
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
Quando PUNT_FABRIC_DATA_PATH_FAILED ocorre, e se a falha é devida a NP fast reset, os registros semelhantes aos listados aqui aparecem para uma placa de linha baseada em tufão. O mecanismo de monitoramento de integridade está disponível em placas de linha baseadas em tufão, mas não em placas de linha baseadas em 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
Para placas de linha baseadas em Trident, esse registro é visto com uma reinicialização rápida de um NP:
LC/0/1/CPU0:Mar 29 15:27:43.787 test:
pfm_node_lc[279]: Fast Reset initiated on NP3
A Cisco corrigiu um problema em que os links de estrutura raramente entre o Route Switch Processor (RSP) 440 e as placas de linha baseadas em tufão no painel traseiro são treinados novamente. Os links de estrutura são treinados novamente porque a intensidade do sinal não é ideal. Esse problema está presente nas versões básicas do software Cisco IOS®-XR 4.2.1, 4.2.2, 4.2.3, 4.3.0, 4.3.1 e 4.3.2. Uma atualização de manutenção de software (SMU) para cada uma dessas versões é publicada no Cisco Connection Online e rastreada com o bug da Cisco ID CSCuj10837 e o bug da Cisco ID CSCul39674.
Quando esse problema ocorre no roteador, qualquer um destes cenários pode ocorrer:
Para confirmar, colete as saídas de rastreamento do LC e dos RSPs (show controller fabric crossbar ltrace location <>) e verifique se essa saída é vista nos registros de RSP:
O SMU já está disponível
Aqui está um exemplo:
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.
O termo direção TX refere-se à direção do ponto de vista da interface de estrutura de barras cruzadas dos RSPs em direção a uma interface de barra cruzada de estrutura em uma placa de linha baseada em tufão.
A ID de bug da Cisco CSCuj10837 é caracterizada pela detecção de um problema no link RX do RSP pela placa de linha do tufão e pelo início de um retreinamento de link. Qualquer um dos lados (LC ou RSP) pode iniciar o evento de retreinamento. No caso do bug da Cisco ID CSCuj10837, o LC inicia o retreinamento e pode ser detectado pelo init xbar_trigger_link_retrain: nos rastreamentos no 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 o LC inicia o retreinamento, o RSP relata um rcvd link_retrain na saída de rastreamento.
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.
Para confirmar, colete as saídas de rastreamento da placa de linha e dos RSPs (show controller fabric crossbar ltrace location <>) e verifique se essa saída é vista nos registros de RSP:
Aqui está um exemplo:
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.
O termo direção de RX refere-se à direção do ponto de vista da interface de estrutura de barras cruzadas dos RSPs a partir de uma interface de barra cruzada de estrutura em uma placa de linha baseada em tufão.
A ID de bug da Cisco CSCul39674 é caracterizada pela detecção de um problema no link RSP da placa de linha do tufão e pela iniciação de um retreinamento de link. Qualquer um dos lados (LC ou RSP) pode iniciar o evento de retreinamento. No caso do bug da Cisco ID CSCul39674, o RSP inicia o retreinamento e pode ser detectado pelo init xbar_trigger_link_retrain: nos rastreamentos no 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 o RSP inicia o retreinamento, o LC relata um evento rcvd link_retrain na saída do rastreamento.
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.
Foi feito um trabalho significativo para diminuir o tempo necessário para reformar um link de estrutura no IOS-XR versão 4.3.2 e posterior. O treinamento da malha agora ocorre em segundos e é imperceptível aos fluxos de tráfego. Na Versão 4.3.2, somente essas mensagens de syslog são vistas quando ocorre um retreinamento de link de estrutura.
%PLATFORM-FABMGR-5-FABRIC_TRANSIENT_FAULT : Fabric backplane crossbar link
underwent link retraining to recover from a transient error: Physical slot 1
A Cisco corrigiu um problema em que o ASIC de estrutura (FIA) pode ser redefinido devido a uma condição de estouro FIFO (First In First Out, primeiro a entrar) irrecuperável. Este é o endereço com a ID de bug da Cisco CSCul66510. Esse problema afeta apenas as placas de linha baseadas em Trident e só é encontrado em casos raros com congestionamento pesado do caminho de entrada. Se esse problema for encontrado, essa mensagem de syslog será exibida antes que a placa de linha seja redefinida para se recuperar da condição.
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
A Cisco corrigiu um problema em que o congestionamento pesado pode levar à exaustão dos recursos de estrutura e à perda de tráfego. A perda de tráfego pode até ocorrer em fluxos não relacionados. Esse problema é tratado com o bug da Cisco ID CSCug90300 e é resolvido no IOS-XR versão 4.3.2 e posterior. A correção também é fornecida na versão 4.2.3 CSMU#3, SMU CSCui3805 . Esse problema raro pode ser encontrado em placas de linha baseadas em Trident ou Typhon.
Você deve reunir estes comandos:
Aqui estão alguns exemplos de saída:
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#
Sob condições normais, é muito improvável ver um VOQ com pacotes enfileirados. Esse comando é um instantâneo rápido em tempo real das filas FIA. É comum que esse comando não mostre nenhum pacote enfileirado.
Erros suaves são erros não permanentes que fazem com que a máquina de estado não esteja sincronizada. Eles são vistos como Cyclic Redundancy Check (CRC), Frame Check Sequence (FCS) ou pacotes com erros no lado da estrutura do NP ou no lado de entrada do FIA.
Aqui estão alguns exemplos de como esse problema pode ser visto:
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 <==========
Você deve reunir estes comandos:
O método de recuperação é recarregar a placa de linha afetada.
RP/0/RSP0/CPU0:asr9k-1#hw-module location 0/6/cpu0 reload
O comando show diagnostic result location <node> [test <test-id> detail] fornece um resumo de todos os testes e falhas de diagnóstico on-line, bem como o último carimbo de data e hora quando um teste foi aprovado. O Test-ID para a falha do caminho de dados da estrutura punt é dez. Uma lista de todos os testes junto com a frequência dos pacotes de teste pode ser vista com o comando show diagnostic content location <node>.
A saída do resultado do teste de caminho de dados de estrutura punt será semelhante a esta saída de exemplo:
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
Conforme descrito no bug da Cisco ID CSCuc04493, agora há uma maneira de o roteador desligar automaticamente todas as portas associadas aos erros PUNT_FABRIC_DATA_PATH.
O primeiro método é rastreado através da ID de bug da Cisco CSCuc04493. Para a versão 4.2.3, isso está incluído no bug da Cisco ID CSCui33805. Nesta versão, ela é definida para desligar automaticamente todas as portas associadas aos NPs afetados.
Aqui está um exemplo que mostra como os syslogs apareceriam:
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
A controladora indicará que o motivo da interface estar inativa é devido a DATA_PATH_DOWN. Aqui está um exemplo:
RP/0/RSP0/CPU0:ASR9006-E#sh 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
Nas versões 4.3.1 e posteriores, esse comportamento deve ser ativado. Há um novo comando admin config que é usado para fazer isso. Como o comportamento padrão não é mais encerrar as portas, ele deve ser configurado manualmente.
RP/0/RSP1/CPU0:ASR9010-A(admin-config)#fault-manager datapath port ?
shutdown Enable auto shutdown
toggle Enable auto toggle port status
No IOS XR de 64 bits, o comando de configuração está disponível na VM XR (não na VM Sysadmin):
RP/0/RSP0/CPU0:CORE-TOP(config)#fault-manager datapath port ?
shutdown Enable auto shutdown
toggle Enable auto toggle port status
A ID de bug da Cisco CSCui15435 aborda os erros de software observados nas placas de linha baseadas em Trident, conforme descrito aqui. Isso usa um método de detecção diferente do método de diagnóstico comum descrito na ID de bug da Cisco CSCuc04493.
Este bug também introduziu um novo comando CLI de configuração de administrador:
(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 este erro é encontrado, este syslog pode ser observado:
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 as portas afetadas são desligadas, ela permite que a redundância de rede assuma o controle e evite um holing negro de tráfego. Para recuperar, a placa de linha deve ser recarregada.
P. A placa de processador de rota primária ou de standby envia keepalives ou pacotes de diagnóstico on-line para cada NP no sistema?
A. Yes. As duas placas de processador de rota enviam pacotes de diagnóstico on-line para cada NP.
P. O caminho é o mesmo quando a placa de processador de rota um (RSP1) está ativa?
A. O caminho de diagnóstico é o mesmo para RSP0 ou RSP1. O caminho depende do estado do RSP. Consulte a seção Caminho do Pacote de Diagnóstico da Estrutura de Procura deste documento para obter mais detalhes.
P. Com que frequência os RSPs enviam pacotes de diagnóstico e quantos pacotes de diagnóstico devem ser perdidos antes que um alarme seja disparado?
A. Cada RSP envia independentemente um pacote de diagnóstico para cada NP uma vez por minuto. Qualquer RSP pode disparar um alarme se três pacotes de diagnóstico não forem confirmados.
P. Como você determina se um NP está ou foi superinscrito?
A. Uma maneira de verificar se um NP está atualmente com excesso de assinaturas ou se já foi com excesso de assinaturas no passado é verificar se há um certo tipo de queda dentro do NP e para quedas de cauda no FIA. O IFDMA (Access de memória direta frontal de entrada) cai dentro do NP ocorre quando o NP está com excesso de assinaturas e não consegue acompanhar o tráfego de entrada. As quedas traseiras do FIA ocorrem quando um NP de saída garante o controle de fluxo (pede que a placa de linha de entrada envie menos tráfego). Sob o cenário de controle de fluxo, o FIA de ingresso tem quedas traseiras.
P. Como você determina se um NP sofre uma falha que exige que ele seja redefinido?
A. Geralmente, uma falha de NP é eliminada por uma reinicialização rápida. O motivo de uma redefinição rápida é exibido nos registros.
P. O que será exibido se um NP tiver uma falha de hardware não recuperável?
A. Você vê uma falha de caminho de dados de estrutura punt para esse NP, bem como uma falha de teste de loopback NP. A mensagem de falha do teste de loopback NP é discutida na seção Apêndice deste documento.
P. Um pacote de diagnóstico originado de uma placa de processador de rota voltará para a mesma?
A. Como os pacotes de diagnóstico são originados das placas do processador de rota e rastreados em uma base por placa de processador de rota, um pacote de diagnóstico originado de uma placa de processador de rota é redirecionado à mesma placa de processador de rota pelo NP.
P. O bug da Cisco ID CSCuj10837 SMU fornece uma correção para o evento de retreinamento do link de estrutura. Essa é a causa e a solução para muitas falhas de caminho de dados de estrutura punt?
A. Sim, será necessário carregar o SMU substituto para o bug da Cisco ID CSCul39674 para evitar eventos de retreinamento de link de estrutura.
P. Quanto tempo leva para reformar os links de malha depois que a decisão é tomada?
A. A decisão de treinar novamente é tomada assim que uma falha de link é detectada. Antes da versão 4.3.2, o retreinamento pode levar alguns segundos. Após a Versão 4.3.2, o tempo de retreinamento foi significativamente melhorado e leva menos de um segundo.
P. Em que ponto é tomada a decisão de reformar um link de estrutura?
A. Assim que a falha do link é detectada, a decisão de treinar novamente é tomada pelo driver ASIC de estrutura.
P. É somente entre o FIA em uma placa de processador de rota ativa e a estrutura que você usa o primeiro link e, depois disso, é o link menos carregado quando há vários links disponíveis?
A. Correto. O primeiro link que se conecta à primeira instância do XBAR no processador de rota ativo é usado para injetar tráfego na estrutura. O pacote de resposta do NP pode alcançar a placa do processador de rota ativa em qualquer um dos links que se conectam à placa do processador de rota. A escolha do link depende da carga do link.
P. Durante o retreinamento, todos os pacotes enviados por esse link de estrutura são perdidos?
A. Sim, mas com os aprimoramentos na versão 4.3.2 e posterior, o novo treinamento é praticamente indetectável. No entanto, no código anterior, pode levar alguns segundos para ser treinado novamente, o que resultou em pacotes perdidos para esse período.
P. Com que frequência você espera ver um evento de retreinamento de link de estrutura XBAR após atualizar para uma versão ou SMU com a correção para o bug da Cisco ID CSCuj10837?
A. Mesmo com a correção para o bug da Cisco ID CSCuj10837, ainda é possível ver retrusões de link de estrutura devido ao bug da Cisco ID CSCul39674. No entanto, uma vez que o cliente tenha a correção para o bug da Cisco ID CSCul39674, o treinamento do link de estrutura nos links do painel traseiro de estrutura entre o RSP440 e as placas de linha baseadas em tufão nunca deve ocorrer. Se isso acontecer, faça uma solicitação de serviço ao Cisco Technical Assistance Center (TAC) para solucionar o problema.
P. Os IDs de bug da Cisco CSCuj10837 e CSCul39674 afetam o RP no ASR 9922 com placas de linha baseadas em tufão?
A. Yes
P. Os IDs de bug da Cisco CSCuj10837 e CSCul39674 afetam os roteadores ASR-9001 e ASR-9001-S?
A. No
P. Se você encontrar a falha de um slot que não existe com esta mensagem, "PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED: Set|online_diag_rsp[237686]|System Punt/Fabric/data Path Test(0x2000004)|o limiar de falha é 3, (slot, NP) falhou: (8, 0)" em um chassi de 10 slots, que slot tem o problema?
A. Em versões mais antigas, você deve levar em conta os mapeamentos físicos e lógicos como mostrado aqui. Neste exemplo, o slot 8 corresponde 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
Aqui estão os comandos mínimos que você deve coletar antes de qualquer ação ser tomada:
Esta é uma lista de comandos úteis para fins de diagnóstico:
A partir do período de tempo do Cisco IOS-XR Software Release 4.3.4, a maioria dos problemas relacionados a falhas de caminho de dados de estrutura punt são abordados. Para os roteadores afetados pelas IDs de bug da Cisco CSCuj10837 e CSCul39674, carregue o SMU substituto para CSCul39674 para evitar eventos de retreinamento de link de estrutura.
A equipe da plataforma instalou o tratamento de falhas de última geração para que o roteador recupere em subsegundos se e quando ocorrer alguma falha recuperável do caminho de dados. No entanto, este documento é recomendado para entender esse problema, mesmo que nenhuma falha seja observada.
O aplicativo de diagnóstico que é executado na CPU da placa de linha controla a integridade de cada NP com verificações periódicas do status de funcionamento do NP. Um pacote é injetado da CPU da placa de linha destinada ao NP local, que o NP deve fazer loopback e retornar à CPU da placa de linha. Qualquer perda nesses pacotes periódicos é sinalizada com uma mensagem de log da plataforma. Aqui está um exemplo dessa mensagem:
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
Essa mensagem de log significa que esse teste não recebeu o pacote de loopback de NP3. A máscara de falha de link é 0x8 (o bit 3 está definido), que indica uma falha entre a CPU da placa de linha para o slot 7 e NP3 no slot 7.
Para obter mais detalhes, colete a saída destes comandos:
Os comandos listados nesta seção aplicam-se a todas as placas de linha baseadas em Trident, bem como à placa de linha 100GE baseada em Typhon. O Bridge FPGA ASIC não está presente em placas de linha baseadas em tufão (exceto as placas de linha baseadas em tufão 100GE). Assim, os comandos show controller fabric fia bridge não se aplicam às placas de linha baseadas em tufão, exceto às versões 100GE.
Essa representação pictórica ajuda a mapear cada comando show para o local no caminho de dados. Use estes comandos show para isolar quedas de pacotes e falhas.