As falhas do trajeto de dados da tela do pontapé do 9000 Series ASR pesquisam defeitos o guia
Índice
Introdução
Este documento descreve os mensagens de falha do trajeto de dados da tela do pontapé considerados durante a operação do 9000 Series do roteador dos serviços da agregação de Cisco (ASR). 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 é pretendido para qualquer um que quer compreender o Mensagem de Erro, e as ações que devem ser tomadas se o problema é considerado.
Pré-requisitos
Requisitos
Cisco recomenda que você tem um conhecimento de nível elevado destes assuntos:
- Placas de linha ASR 9000
- Placas de fábrica
- Processadores de rotas
- Arquitetura do chassi
Contudo, este documento não exige leitores ser familiares com os detalhes do hardware. A informações de fundo necessária é fornecida antes que o Mensagem de Erro esteja explicado. Este documento descreve o erro em ambo o Trident e placas de linha Tufão-baseadas. Veja tipos da placa de linha do 9000 Series ASR para uma explicação daqueles termos.
Componentes Utilizados
Este documento não se restringe a versões de software e hardware específicas.
As informações neste documento foram criadas a partir de dispositivos em um ambiente de laboratório específico. Todos os dispositivos utilizados neste documento foram iniciados com uma configuração (padrão) inicial. Se a sua rede estiver ativa, certifique-se de que entende o impacto potencial de qualquer comando.
Como usar este documento
Considere estas sugestões sobre como usar este documento a fim recolher detalhes essenciais e como um guia de referência no processo da pesquisa de defeitos:
- Quando não há nenhuma urgência à causa de raiz um a falha do trajeto de dados da tela do pontapé, leia todas as seções deste documento. Este documento constrói o fundo necessário necessário a fim isolar um componente defeituoso quando tal erro ocorre.
- Use a seção FAQ se você tem uma pergunta específica na mente para que uma resposta rápida está precisada. Se a pergunta não é incluída na seção FAQ, a seguir verificação se o documento principal endereça a pergunta.
- Use todas as seções do analisam falhas sobre a fim isolar o problema a um componente defeituoso quando um roteador experimenta uma falha ou a fim verificar se é um problema conhecido.
Informações de Apoio
Um pacote pode atravessar ou dois saltos ou três saltos através do Switch Fabric baseado na placa de linha datilografam. As placas de linha da geração do tufão adicionam um elemento extra do Switch Fabric, quando as placas de linha Trident-baseadas comutarem todo o tráfego com a tela no cartão do processador de rotas somente. Estes diagramas mostram elementos da tela para both of these tipos da placa de linha, assim como Conectividade da tela ao cartão do processador de rotas:
Trajeto do pacote de diagnósticos da tela do pontapé
O aplicativo diagnóstico que é executado no cartão CPU do processador de rotas injeta os pacotes de diagnósticos destinados a cada processador de rede (NP) periodicamente. O pacote de diagnósticos é loop dentro do NP, e reinjected para o cartão CPU do processador de rotas que originado o pacote. Este exame médico completo periódico de cada NP com um pacote original pelo NP pelo aplicativo diagnóstico no cartão do processador de rotas fornece um alerta para todos os erros funcionais no trajeto de dados durante a operação de roteador. É essencial notar que o aplicativo diagnóstico no processador da rota ativa e no processador de rotas à espera injeta um pacote pelo NP periodicamente e mantém a pelo sucesso ou o contagem de falha NP. Quando um ponto inicial de pacotes de diagnósticos deixados cair é alcançado, o aplicativo levanta uma falha.
Vista conceptual do trajeto diagnóstico
Antes que o documento descreva o trajeto diagnóstico em Trident e em placas de linha Tufão-baseadas, esta seção fornece um esboço geral do trajeto diagnóstico da tela dos cartões ativos e à espera do processador de rotas para o NP na placa de linha.
Caminho de pacote de informação entre a placa de processador da rota ativa e a placa de linha
Os pacotes de diagnósticos injetados do processador da rota ativa na tela para o NP são tratados como pacotes do unicast pelo Switch Fabric. Com pacotes do unicast, o Switch Fabric escolhe o link de saída baseado na carga de tráfego atual do link, que ajuda a sujeitar pacotes de diagnósticos à carga de tráfego no roteador. Quando há uns links de saída múltiplos para o NP, o Switch Fabric ASIC escolhe um link que seja atualmente carregados o mais menos.
Este diagrama descreve o trajeto do pacote de diagnósticos originado do processador da rota ativa.
Caminho de pacote de informação entre o cartão à espera do processador de rotas e a placa de linha
Os pacotes de diagnósticos injetados do processador de rotas à espera na tela para o NP são tratados como pacotes de transmissão múltipla pelo Switch Fabric. Embora seja um pacote de transmissão múltipla, não há nenhuma replicação dentro da tela. Cada pacote de diagnósticos originado do processador de rotas à espera ainda alcança somente um NP de cada vez. O pacote de resposta do NP para o processador de rotas é igualmente um pacote de transmissão múltipla sobre a tela sem a replicação. Daqui, o aplicativo diagnóstico no processador de rotas à espera recebe um único pacote de resposta dos NP, um pacote de cada vez. O aplicativo do diagnóstico segue cada NP no sistema, porque injeta um pacote pelo NP, e espera respostas de cada NP, um pacote de cada vez. Com um pacote de transmissão múltipla, o Switch Fabric escolhe o link de saída baseado em um valor de campo no cabeçalho de pacote de informação, que ajuda a injetar pacotes de diagnósticos sobre cada tela para ligar entre o cartão do processador de rotas e a placa de linha. O processador de rotas do apoio segue a saúde NP sobre cada link da tela que conecta entre o cartão do processador de rotas e o entalhe da placa de linha.
O diagrama precedente descreve o trajeto do pacote de diagnósticos originado do processador de rotas à espera. Observe que, ao contrário da caixa do processador da rota ativa, todos os links que conectam a placa de linha ao XBAR no processador de rotas são exercitados. Os pacotes de resposta do NP tomam o mesmo link da tela que foi usado pelo pacote no processador de rotas ao sentido da placa de linha. Este teste assegura-se de que todos os links que conectam o processador de rotas à espera à placa de linha estejam monitorados continuamente.
Trajeto do pacote de diagnósticos da tela do pontapé na placa de linha Trident-baseada
Este diagrama descreve os pacotes de diagnósticos originado do processador de rotas destinados a um NP que seja loop para o processador de rotas. É importante notar os links do trajeto de dados e os ASIC que são comuns a todos os NP, assim como os links e os componentes que são específicos a um subconjunto dos NP. Por exemplo, a ponte ASIC 0 (B0) é comum a NP0 e a NP1, quando FIA0 for comum a todos os NP. Na extremidade do processador de rotas, todos os links, o trajeto de dados ASIC, e o Field Programmable Gate Array (FPGA) são comuns a todas as placas de linha, e daqui a todos os NP em um chassi.
Trajeto do pacote de diagnósticos da tela do pontapé na placa de linha Tufão-baseada
Este diagrama descreve os pacotes de diagnósticos originado do cartão do processador de rotas destinados a um NP que seja loop para o processador de rotas. É importante notar os links do trajeto de dados e os ASIC que são comuns a todos os NP assim como links e componentes que são específicos a um subconjunto dos NP. Por exemplo, FIA0 é comum a NP0 e a NP1. Na extremidade do cartão do processador de rotas, todos os links, o trajeto de dados ASIC, e os FGPA são comuns a todas as placas de linha, e daqui a todos os NP em um chassi.
As próximas seções tentam descrever o caminho de pacote de informação a cada NP. Isto é necessário a fim compreender o Mensagem de Erro do trajeto de dados da tela do pontapé, e a fim encontrar igualmente o ponto da falha.
Relatório do alarme diagnóstico e da falha da tela do pontapé
A falha obter respostas de um NP em um 9000-based Router ASR conduz a um alarme. A decisão para levantar um alarme pelo aplicativo do diagnóstico on-line que executa no processador de rotas ocorre quando há três falhas consecutivas. O aplicativo diagnóstico mantém um indicador da falha de três pacotes para cada NP. O processador da rota ativa e o processador de rotas à espera diagnosticam independentemente e paralelamente. O processador da rota ativa, o processador de rotas à espera, ou ambos os cartões do processador de rotas puderam relatar o erro. O lugar da falha e a perda de pacotes determinam que processador de rotas relata o alarme.
A frequência do padrão do pacote de diagnósticos para cada NP é um pacote por 60 segundos ou um pelo minuto.
Está aqui o formato do 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 alcançar NP 1, 2,3, 4, 5, 6, e 7 na placa de linha 0/7/cpu0 do processador de rotas 0/rsp0/cpu0.
Da lista de testes do diagnóstico on-line, você pode ver os atributos do teste de loopback da tela do pontapé 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 do teste de PuntFabricDataPath é um pacote cada minuto, e o ponto inicial da falha é três, que implica que a perda de três pacotes consecutivos não está tolerada e conduz a um alarme. Os atributos do teste mostrados são valores padrão. A fim mudar padrões, inscreva o intervalo do monitor diagnóstico e os comandos threshold do monitor diagnóstico no modo de configuração da administração.
Trajeto Trident-baseado do pacote de diagnósticos da placa de linha
Falha de diagnóstico NP0
Trajeto diagnóstico da tela
Este diagrama descreve o caminho de pacote de informação entre o processador de rotas CPU e a placa de linha NP0. O link que conecta o B0 e o NP0 é o único específico do link a NP0. Todos os outros links caem no trajeto comum.
Faça a anotação do caminho de pacote de informação do processador de rotas para NP0. Embora haja quatro links a se usar para os pacotes destinados para NP0 do processador de rotas, o primeiro link entre o processador de rotas e o entalhe da placa de linha é usado para o pacote do processador de rotas para a placa de linha. O pacote retornado de NP0 pode ser enviado para trás ao processador da rota ativa sobre alguns dos dois trajetos do link da tela entre o entalhe da placa de linha e o processador da rota ativa. A escolha de que um dos dois links a se usar depende da carga de link naquele tempo. O pacote de resposta de NP0 para o processador de rotas à espera usa ambos os links, mas um link de cada vez. A escolha do link é baseada no campo de cabeçalho que o aplicativo diagnóstico povoa.
Análise da falha de diagnóstico NP0
Única encenação da falha
Se um alarme de falha do trajeto de dados da tela do pontapé do gerente da falha da plataforma única (PFM) com somente o NP0 no mensagem de falha é detectado, a falha está somente no trajeto da tela que conecta o processador de rotas e a placa de linha NP0. Esta é uma única falha. Se a falha é detectada a mais de um NP, refira a seção múltipla da encenação da falha.
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)
Como ilustrado no diagrama precedente do trajeto de dados, a falha tem que estar em uns ou vários destes lugar:
- Ligue que conecta NP0 e B0
- Filas B0 internas dirigidas para NP0
- NP0 interno
Encenação múltipla da falha
Falhas múltiplas NP
Quando outras falhas estão observadas em NP0 ou a falha PUNT_FABRIC_DATA_PATH_FAILED está relatada igualmente por outros NP na mesma placa de linha, a seguir o isolamento de falha está feito correlacionando todas as falhas. Por exemplo, se a falha PUNT_FABRIC_DATA_PATH_FAILED e a falha LC_NP_LOOPBACK_FAILED ocorrem em NP0, a seguir o NP parou de processar pacotes. Refira a seção do trajeto de diagnóstico de loopback NP a fim compreender a falha do laço de retorno. Esta podia ser uma indicação adiantada de uma falha crítica dentro de NP0. Contudo, se somente uma das duas falhas ocorre, a seguir a falha é localizada ao trajeto de dados da tela do pontapé ou na placa de linha CPU ao trajeto NP.
Se mais de um NP em uma placa de linha tem uma falha do trajeto de dados da tela do pontapé, a seguir você deve andar acima do trajeto da árvore dos links da tela a fim isolar um componente defeituoso. Por exemplo, se NP0 e NP1 têm uma falha, a seguir a falha tem que estar no B0 ou o link que conecta o B0 e o FIA0. É menos provável que NP0 e NP1 encontram um erro interno crítico ao mesmo tempo. Embora seja menos provável, é possível para que NP0 e NP1 encontre uma falha do erro crítico devido ao processamento incorreto de um tipo particular do pacote ou de um pacote ruim.
Ambos os cartões do processador de rotas relatam uma falha
Se o processador de rotas ativo e à espera carda o relatório uma falha a uns ou vários NP em uma placa de linha, a seguir verifique todos os links e componentes da terra comum no trajeto de dados entre os NP afetados e ambos os cartões do processador de rotas.
Falha de diagnóstico NP1
Este diagrama descreve o caminho de pacote de informação entre o cartão CPU do processador de rotas e a placa de linha NP1. O link que conecta a ponte ASIC 0 (B0) e o NP1 é o único específico do link a NP1. Todos os outros links caem no trajeto comum.
Faça a anotação do caminho de pacote de informação do cartão do processador de rotas para NP1. Embora haja quatro links a se usar para os pacotes destinados para NP0 do processador de rotas, o primeiro link entre o processador de rotas e o entalhe da placa de linha é usado para o pacote do processador de rotas para a placa de linha. O pacote retornado de NP1 pode ser enviado para trás ao processador da rota ativa sobre alguns dos dois trajetos do link da tela entre o entalhe da placa de linha e o processador da rota ativa. A escolha de que um dos dois links a se usar depende da carga de link naquele tempo. O pacote de resposta de NP1 para o processador de rotas à espera usa ambos os links, mas um link de cada vez. A escolha do link é baseada no campo de cabeçalho que o aplicativo diagnóstico povoa.
Trajeto diagnóstico da tela
Análise da falha de diagnóstico NP1
Refira a seção da análise da falha de diagnóstico NP0, mas aplique o mesmo raciocínio para NP1 (em vez de NP0).
Falha de diagnóstico NP2
Este diagrama descreve o caminho de pacote de informação entre o cartão CPU do processador de rotas e a placa de linha NP2. O link que conecta o B1 e o NP2 é o único específico do link a NP2. Todos os outros links caem no trajeto comum.
Faça a anotação do caminho de pacote de informação do cartão do processador de rotas para NP2. Embora haja quatro links a se usar para os pacotes destinados para NP2 do processador de rotas, o primeiro link entre o processador de rotas e o entalhe da placa de linha é usado para o pacote do processador de rotas para a placa de linha. O pacote retornado de NP2 pode ser enviado para trás ao processador da rota ativa sobre alguns dos dois trajetos do link da tela entre o entalhe da placa de linha e o processador da rota ativa. A escolha de que um dos dois links a se usar depende da carga de link naquele tempo. O pacote de resposta de NP2 para o processador de rotas à espera usa ambos os links, mas um link de cada vez. A escolha do link é baseada no campo de cabeçalho que o aplicativo diagnóstico povoa.
Trajeto diagnóstico da tela
Análise da falha de diagnóstico NP2
Refira a seção da análise da falha de diagnóstico NP0, mas aplique o mesmo raciocínio para NP2 (em vez de NP0).
Falha de diagnóstico NP3
Este diagrama descreve o caminho de pacote de informação entre o cartão CPU do processador de rotas e a placa de linha NP3. O link que conecta a ponte ASIC 1 (B1) e o NP3 é o único específico do link a NP3. Todos os outros links caem no trajeto comum.
Faça a anotação do caminho de pacote de informação do cartão do processador de rotas para NP3. Embora haja quatro links a se usar para os pacotes destinados para NP3 do processador de rotas, o primeiro link entre o processador de rotas e o entalhe da placa de linha é usado para o pacote do processador de rotas para a placa de linha. O pacote retornado de NP3 pode ser enviado para trás ao processador da rota ativa sobre alguns dos dois trajetos do link da tela entre o entalhe da placa de linha e o processador da rota ativa. A escolha de que um dos dois links a se usar depende da carga de link naquele tempo. O pacote de resposta de NP3 para o processador de rotas à espera usa ambos os links, mas um link de cada vez. A escolha do link é baseada no campo de cabeçalho que o aplicativo diagnóstico povoa.
Trajeto diagnóstico da tela
Análise da falha de diagnóstico NP3
Refira a seção da análise da falha de diagnóstico NP0, mas aplique o mesmo raciocínio para NP3 (em vez de NP0).
Trajeto Tufão-baseado do pacote de diagnósticos da placa de linha
Esta seção fornece dois exemplos a fim estabelecer o fundo para pacotes do pontapé da tela com placas de linha Tufão-baseadas. O primeiro exemplo usa NP1, e o segundo exemplo usa NP3. A descrição e a análise podem ser estendidas a outros NP em toda a placa de linha Tufão-baseada.
Falha de diagnóstico do tufão NP1
O diagrama seguinte descreve o caminho de pacote de informação entre o cartão CPU do processador de rotas e a placa de linha NP1. O link que conecta FIA0 e NP1 é o único específico do link ao trajeto NP1. Todos os outros links entre o entalhe da placa de linha e o slot da placa do processador de rotas caem no trajeto comum. Os links que conectam a tela XBAR ASIC na placa de linha aos FIA na placa de linha são específicos a um subconjunto dos NP. Por exemplo, os links entre FIA0 e a tela local XBAR ASIC na placa de linha são usados para o tráfego a NP1.
Faça a anotação do caminho de pacote de informação do cartão do processador de rotas para NP1. Embora haja oito links a se usar para os pacotes destinados para NP1 do cartão do processador de rotas, um caminho único entre o cartão do processador de rotas e o entalhe da placa de linha é usado. O pacote retornado de NP1 pode ser enviado para trás ao cartão do processador de rotas sobre oito trajetos do link da tela entre o entalhe da placa de linha e o processador de rotas. Cada um destes oito links está exercitado um numa altura em que o pacote de diagnósticos é destinado de volta ao cartão CPU do processador de rotas.
Trajeto diagnóstico da tela
Falha de diagnóstico do tufão NP3
Este diagrama descreve o caminho de pacote de informação entre o cartão CPU do processador de rotas e a placa de linha NP3. O link que conecta FIA1 e NP3 é o único específico do link ao trajeto NP3. Todos os outros links entre o entalhe da placa de linha e o slot da placa do processador de rotas caem no trajeto comum. Os links que conectam a tela XBAR ASIC na placa de linha aos FIA na placa de linha são específicos a um subconjunto dos NP. Por exemplo, os links entre FIA1 e a tela local XBAR ASIC na placa de linha são usados para o tráfego a NP3.
Faça a anotação do caminho de pacote de informação do cartão do processador de rotas para NP3. Embora haja oito links a se usar para os pacotes destinados para NP3 do cartão do processador de rotas, um caminho único entre o cartão do processador de rotas e o entalhe da placa de linha é usado. O pacote retornado de NP1 pode ser enviado para trás ao cartão do processador de rotas sobre oito trajetos do link da tela entre o entalhe da placa de linha e o processador de rotas. Cada um destes oito links está exercitado um numa altura em que o pacote de diagnósticos é destinado de volta ao cartão CPU do processador de rotas.
Trajeto diagnóstico da tela
Analise falhas
Esta seção categoriza falhas em casos duros e transientes, e alista as etapas usadas a fim identificar se uma falha é uma falha dura ou transiente. Uma vez que o tipo da falha é determinado, o documento especifica os comandos que podem ser executados no roteador a fim compreender a falha e os que ações corretiva são precisadas.
Falha transiente
Se uma mensagem do grupo PFM é seguida pela mensagem clara PFM, a seguir uma falha ocorreu, e o roteador corrigiu a falha própria. As falhas transientes podem ocorrer devido às condições ambientais e às falhas recuperáveis nos componentes de hardware. Às vezes pode ser difícil associar falhas transientes a todo o evento particular.
Um exemplo de uma falha transiente da tela é alistado 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ções corretiva transientes da falha
A aproximação sugerida para erros transitórios é monitora somente para uma ocorrência mais adicional de tais erros. Se uma falha transiente ocorre mais de uma vez, a seguir trate a falha transiente como uma falha do equipamento, e use as recomendações e as etapas a fim analisar tais falhas descritas na próxima seção.
Falha do equipamento
Se uma mensagem do grupo PFM não é seguida por uma mensagem clara PFM, a seguir uma falha ocorreu e o roteador não corrigiu a falha própria pela falha que segura o código, ou a natureza do defeito de hardware não é recuperável. As falhas do equipamento podem ocorrer devido às condições ambientais e às falhas unrecoverable nos componentes de hardware. A aproximação sugerida para falhas do equipamento é usar as diretrizes mencionadas na seção das falhas do equipamento da análise.
Um exemplo da falha dura da tela é alistado aqui para maior clareza. Para este mensagem de exemplo, não há uma mensagem clara correspondente PFM.
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)
Ações corretiva da falha do equipamento
Sob uma encenação da falha do equipamento, recolha todos os comandos mencionados nos dados para recolher antes que seção da criação do pedido do serviço, e para abrir um pedido do serviço. Em casos urgentes, depois que você recolhe toda a saída do comando de Troubleshooting, inicie um cartão do processador de rotas ou um reload da placa de linha baseado no isolamento de falha. Depois que o reload, se o erro não está recuperado, inicia uma autorização de material do retorno (RMA).
Analise falhas transientes
Termine estas etapas a fim analisar falhas transientes.
- Incorpore o registro da mostra | comando inc “PUNT_FABRIC_DATA_PATH” a fim descobrir se o erro ocorreu uma vez ou épocas múltiplas.
- Inscreva o comando all do lugar do pfm da mostra a fim determinar o status atual (AJUSTE ou CANCELE). É o erro proeminente ou cancelado? Se o status de erro muda entre o GRUPO e o ESPAÇO LIVRE, a seguir umas ou várias falhas dentro do trajeto de dados da tela ocorrem e estão retificadas repetidamente pelo software ou pelo hardware.
- Provision armadilhas de Protocolo de Gerenciamento de Rede Simples (SNMP) ou execute um script que recolhe a saída do comando all do lugar do pfm da mostra, e procure-o pela série de erro periodicamente a fim monitorar a ocorrência futura da falha (quando o último estado do erro é CLARO, e nenhuma falha nova ocorre).
Comandos usar-se
Incorpore estes comandos a fim analisar falhas transientes:
- show logging | inc “PUNT_FABRIC_DATA_PATH”
- mostre o lugar todo do pfm
Analise falhas do equipamento
Se você vê o trajeto de dados da tela liga em uma placa de linha como uma árvore (onde os detalhes são descritos na seção de informações de fundo), a seguir você deve pressupor - baseado no ponto da falha - se uns ou vários NP são inacessíveis. Quando as falhas múltiplas ocorrem em NP múltiplos, a seguir use os comandos alistados nesta seção a fim analisar falhas.
Comandos usar-se
Incorpore estes comandos a fim analisar falhas do equipamento:
- show logging | inc “PUNT_FABRIC_DATA_PATH”
A saída pôde conter uns ou vários NP (exemplo: NP2, NP3). - mostre o <lc> do lugar do status do link FIA da tela do controlador
Desde que NP2 e NP3 (na seção da falha de diagnóstico do tufão NP3) recebem e enviam com um único FIA, é razoável pressupor que a falha está em um FIA associado no trajeto. - mostre o lugar <0 e 1> <LC ou RSP> do exemplo do status do link da barra transversal da tela do controlador
Se todos os NP na placa de linha não são alcançáveis para o aplicativo diagnóstico, a seguir é razoável pressupor que os links que conectam o entalhe da placa de linha ao cartão do processador de rotas puderam ter uma falha em alguns dos ASIC que enviam o tráfego entre o cartão do processador de rotas e a placa de linha.
mostre a exemplo do status do link da barra transversal da tela do controlador 0 <lc> do lugar
mostre a exemplo do status do link da barra transversal da tela do controlador 0 lugar 0/rsp0/cpu0
mostre a exemplo do status do link da barra transversal da tela do controlador 1 lugar 0/rsp0/cpu0
mostre a exemplo do status do link da barra transversal da tela do controlador 0 lugar 0/rsp1/cpu0
mostre a exemplo do status do link da barra transversal da tela do controlador 1 lugar 0/rsp1/cpu0 - mostre o lugar 0/rsp*/cpu0 do status do link FIA da tela do controlador
mostre o lugar 0/rsp0/cpu0 do status do link FIA da tela do controlador
mostre o lugar 0/rsp1/cpu0 do status do link FIA da tela do controlador - mostre o lugar 0/rsp*/cpu0 do status de sincronização da ponte FIA da tela do controlador
mostre o lugar 0/rsp0/cpu0 do status de sincronização da ponte FIA da tela do controlador
mostre o lugar 0/rsp1/cpu0 do status de sincronização da ponte FIA da tela do controlador
mostre o terminal da tela da tecnologia
Falhas passadas
Historicamente, 99 por cento das falhas são recuperáveis, e na maioria dos casos a ação de recuperação software-iniciada fixa as falhas. Contudo, muito em casos raros, os erros irrecuperáveis são considerados que podem somente ser fixados com o RMA dos cartões.
As próximas seções identificam algumas falhas passadas encontradas a fim servir como a orientação se os erros similares são observados.
Erro transitório devido à sobreassinatura NP
Indicador destas mensagens se o erro é 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)
As falhas transientes podem ser mais duras de confirmar. Um método para determinar se um NP é atualmente oversubscribed ou foi oversubscribed no passado é verificar um determinado tipo da gota dentro do NP e para ver se há quedas traseiras no FIA. As gotas dianteiras do acesso direto de memória do ingresso (IFDMA) dentro do NP ocorrem quando o NP é oversubscribed e não pode prosseguir com tráfego de entrada. As quedas traseiras FIA ocorrem quando uma saída NP afirma o controle de fluxo (pede a placa de linha do ingresso para enviar menos tráfego). Sob a encenação do controle de fluxo, o ingresso FIA 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
A falha do equipamento devido ao NP jejua restauração
Quando PUNT_FABRIC_DATA_PATH_FAILED ocorre, e se a falha é devido à restauração rápida NP, a seguir registra similar ao que é alistado aqui aparece para uma placa de linha Tufão-baseada. O mecanismo do monitoramento de funcionamento está disponível em placas de linha Tufão-baseadas, mas não em placas de linha Trident-baseadas.
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 Trident-baseadas, este log é considerado com uma restauraçã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
Falhas entre os processadores de rotas RSP440 e as placas de linha do tufão
Cisco fixou uma edição onde raramente os links da tela entre o Route Switch Processor (RSP) 440 e placas de linha Tufão-baseadas através do backplane fossem treinados novamente. Os links da tela são treinados novamente porque a intensidade de sinal não é ótima. Esta edição esta presente nos Software Release 4.2.1, nos 4.2.2, nos 4.2.3, nos 4.3.0, nos 4.3.1, e nos 4.3.2 baixos do Cisco IOS ®-XR. Uma atualização da manutenção de software (SMU) para cada um destes libera-se é afixada no Cisco Connection Online, e seguida com identificação de bug Cisco CSCuj10837 e identificação de bug Cisco CSCul39674.
Quando esta edição ocorre no roteador, qualqueras um encenações podem ocorrer:
- O link vai para baixo e vem acima. (Transeunte)
- O link vai permanentemente para baixo.
Retreinamento da tela da identificação de bug Cisco CSCuj10837 entre RSP e LC (sentido TX)
A fim confirmar, recolha as saídas do ltrace de LC e de ambos os RSP (<> do lugar do ltrace da barra transversal da tela do controlador da mostra) e verifique se esta saída é considerada em ltraces RSP:
SMU está já 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 sentido do termo TX refere o sentido do ponto de vista da relação da tela da barra transversal RSP para uma relação da barra transversal da tela em uma placa de linha Tufão-baseada.
A identificação de bug Cisco CSCuj10837 é caracterizada pela detecção da placa de linha do tufão de um problema no link RX do RSP e da iniciação de um retreinamento do link. Um ou outro lado (LC ou RSP) pode iniciar o evento do retreinamento. No caso da identificação de bug Cisco CSCuj10837, o LC inicia o retreinamento e pode ser detectado pelo xbar_trigger_link_retrain do init: mensagem nos traços 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 link_retrain do rcvd nas saídas 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.
Retreinamento da tela da identificação de bug Cisco CSCul39674 entre RSP e LC (sentido RX)
A fim confirmar, recolha as saídas do ltrace da placa de linha e de ambos os RSP (<> do lugar do ltrace da barra transversal da tela do controlador da mostra) e verifique se esta saída é considerada em ltraces 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 sentido do termo RX refere o sentido do ponto de vista da relação da tela da barra transversal RSP de uma relação da barra transversal da tela em uma placa de linha Tufão-baseada.
A identificação de bug Cisco CSCul39674 é caracterizada pela detecção do RSP de um problema no link RX da placa de linha do tufão e da iniciação de um retreinamento do link. Um ou outro lado (LC ou RSP) pode iniciar o evento do retreinamento. No caso da identificação de bug Cisco CSCul39674, o RSP inicia o retreinamento e pode ser detectado pelo xbar_trigger_link_retrain do init: mensagem nos traços 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 do link_retrain do rcvd nas saídas de 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.
Diferenças do retreinamento da tela na liberação 4.3.2 e mais atrasado
O trabalho significativo foi feito a fim diminuir o tempo onde toma para treinar novamente um link da tela na liberação 4.3.2 IOS-XR e mais atrasado. O retreinamento da tela agora ocorre em épocas subsecond e é imperceptível aos fluxos de tráfego. Na liberação 4.3.2, esta o mensagem do syslog é considerado somente quando um retreinamento do link da tela ocorreu.
%PLATFORM-FABMGR-5-FABRIC_TRANSIENT_FAULT : Fabric backplane crossbar link
underwent link retraining to recover from a transient error: Physical slot 1
Falha devido ao excesso da construção ASIC FIFO
Cisco fixou uma edição onde a construção ASIC (FIA) pudesse obter a restauração devido a uma condição de excesso unrecoverable do first in first out (FIFO). Isto é endereçado com identificação de bug Cisco CSCul66510. Este problema afeta somente as placas de linha Trident-baseadas e é encontrado somente em casos raros com congestão pesada do caminho de ingresso. Se esta edição é encontrada, este mensagem do syslog está indicado antes que a placa de linha esteja restaurada para recuperar da circunstância.
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
Falha devido ao acúmulo pesado da fila de saída virtual (VOQ) da congestão da tela
Cisco fixou uma edição onde a congestão pesada prolongada pudesse conduzir ao esgotamento de recurso e à perda de tráfego da tela. A perda de tráfego pode mesmo ocorrer em fluxos não relacionados. Este problema é endereçado com identificação de bug Cisco CSCug90300 e resolvido na liberação 4.3.2 IOS-XR e mais atrasado. O reparo é entregado igualmente na liberação 4.2.3 CSMU#3, SMU CSCui33805. Esta edição rara pôde ser encontrada em Trident ou em placas de linha Tufão-baseadas.
Comandos relevant
Você deve recolher estes comandos:
- mostre a tela do tecnologia-apoio
- a FIA da tela do controlador da mostra constrói uma ponte sobre o <=== do lugar <LC> do controlo de fluxo obtém esta saída para todos os LC
- mostre a controladores o lugar <LC> da q-profundidade FIA da tela
Estão aqui algumas saídas de exemplo:
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 circunstâncias nomal, é muito pouco suscetível de ver um VOQ com os pacotes enfileirados acima. Este comando é um instantâneo realtime rápido das filas FIA. É comum para que este comando não mostre nenhuns pacotes enfileirados de todo.
Impacto do tráfego devido aos erros de software Bridge/FPGA em placas de linha Trident-baseadas
Os erros de software são os erros transitórios que fazem com que a máquina de estado seja fora da sincronização. Estes são vistos como a verificação de redundância cíclica (CRC), a sequência de verificação de frame (FCS), ou os pacotes do erro no lado da tela do NP ou no lado do ingresso do FIA.
Estão aqui alguns exemplos de como esta edição pode ser considerada:
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 <==========
Comandos recolher para erros de software Bridge/FPGA em placas de linha Trident-baseadas
Você deve recolher estes comandos:
- mostre a tela do tecnologia-apoio
- mostre o tecnologia-apoio NP
- mostre o <> do lugar stats da ponte FIA da tela do controlador (obtenha diversas vezes)
Recuperação dos erros de software Bridge/FPGA
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
Relatório de teste do diagnóstico on-line
O comando do [test <test-id> detail] do <node> do lugar do resultado de diagnóstico da mostra fornece um sumário de todos os testes do diagnóstico on-line e falhas assim como o selo de última vez quando um teste passou. O Teste-ID para a falha do trajeto de dados da tela do pontapé é dez. Uma lista de todos os testes junto com a frequência dos pacotes de teste pode ser considerada com o comando satisfeito diagnóstico do <node> do lugar da mostra.
A saída do resultado de teste do trajeto de dados da tela do pontapé será similar a este exemplo de saída:
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
Realces da recuperação automática
Como descrito na identificação de bug Cisco CSCuc04493, há agora uma maneira de mandar o roteador automaticamente fechar todas as portas que são associadas com os erros PUNT_FABRIC_DATA_PATH.
O primeiro método é seguido através da identificação de bug Cisco CSCuc04493. Para a versão 4.2.3, isto é incluído na identificação de bug Cisco CSCui33805. Nesta versão, é ajustado para fechar automaticamente todas as portas que são associadas com os NP que são afetados.
Está aqui um exemplo que mostre como os Syslog 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
O controlador indicará que a razão para a relação que está para baixo é devido a DATA_PATH_DOWN. Aqui está um exemplo:
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
Nas versões 4.3.1 e mais recente, este comportamento deve ser permitido. Há um comando config novo admin que seja usado a fim realizar este. Porque o comportamento padrão é já não fechar as portas, este deve manualmente ser configurado.
RP/0/RSP1/CPU0:ASR9010-A(admin-config)#fault-manager datapath port ?
shutdown Enable auto shutdown
toggle Enable auto toggle port status
A identificação de bug Cisco CSCui15435 endereça os erros de software que são considerados nas placas de linha Trident-baseadas, como descritos aqui. Isto usa um método de detecção diferente do que o método diagnóstico usual que é descrito na identificação de bug Cisco CSCuc04493.
Este erro igualmente introduziu um comando CLI novo da configuração admin:
(admin-config)#fabric fia soft-error-monitor <1|2> location <specific>
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 fechadas, permite que a redundância de rede tome sobre e evite um desaparecimento do tráfego. A fim recuperar, a placa de linha deve ser recarregada.
Perguntas mais frequentes (FAQ)
Q.O cartão preliminar ou à espera do processador de rotas envia o Keepalives ou os pacotes de diagnóstico on-line a cada NP no sistema?
R. Sim. Ambos os cartões do processador de rotas enviam pacotes de diagnóstico on-line a cada NP.
P.. É o trajeto o mesmos quando o cartão um do processador de rotas (RSP1) é ativo?
R. O trajeto diagnóstico é o mesmo para RSP0 ou RSP1. O trajeto é dependente do estado do RSP. Refira a seção do trajeto do pacote de diagnósticos da tela do pontapé deste documento para mais detalhes.
P.. Como frequentemente os RSP enviam pacotes de diagnósticos, e quantos pacotes de diagnósticos devem ser faltados antes que um alarme esteja provocado?
R. Cada RSP envia independentemente um pacote de diagnósticos a cada NP uma vez pelo minuto. Um ou outro RSP pode provocar um alarme se três pacotes de diagnósticos não aknowledged.
P.. Como você determina se um NP é ou foi oversubscribed?
R. Uma maneira de verificar se um NP é atualmente oversubscribed ou foi oversubscribed no passado é verificar um determinado tipo da gota dentro do NP e para ver se há quedas traseiras no FIA. As gotas dianteiras do acesso direto de memória do ingresso (IFDMA) dentro do NP ocorrem quando o NP é oversubscribed e não pode prosseguir com tráfego de entrada. As quedas traseiras FIA ocorrem quando uma saída NP afirma o controle de fluxo (pede a placa de linha do ingresso para enviar menos tráfego). Sob a encenação do controle de fluxo, o ingresso FIA tem quedas traseiras.
P.. Como você determina se um NP sofre uma falha que o exija ser restaurada?
R. Tipicamente, uma falha NP é cancelada por uma restauração rápida. A razão para uma restauração rápida é indicada nos logs.
P.. Que indica se um NP tem uma falha do hardware NON-recuperável?
R. Você vê uma falha do trajeto de dados da tela do pontapé para esse NP assim como uma falha do teste de loopback NP. O mensagem de falha do teste de loopback NP é discutido na seção do apêndice deste documento.
P.. Um pacote de diagnósticos que seja originado de um cartão do processador de rotas virá para trás ao mesmo?
R. Desde que os pacotes de diagnósticos são originado de ambos os cartões do processador de rotas e são seguidos na pela base do cartão do processador de rotas, um pacote de diagnósticos originado de um cartão do processador de rotas é loop ao mesmo cartão do processador de rotas pelo NP.
P.. A identificação de bug Cisco CSCuj10837 SMU fornece um reparo para o evento do retreinamento do link da tela. É isto a causa e a solução para muitas falhas do trajeto de dados da tela do pontapé?
R. Sim, exigir-se-á para carregar o SMU de substituição para a identificação de bug Cisco CSCul39674 a fim evitar eventos do retreinamento do link da tela.
Q. Quanto tempo recolhe a ordem para treinar novamente os links da tela uma vez que a decisão a fazer assim é feita?
R. A decisão a treinar novamente é feita assim que uma falha do link for detectada. Antes da liberação 4.3.2, o retreinamento poderia tomar diversos segundos. Após a liberação 4.3.2, o tempo do retreinamento significativamente foi melhorado e toma menos do que um segundo.
P.. Em que ponto é o retreinamento da decisão um link da tela fez?
A. Assim que a falha do link for detectada, a decisão a treinar novamente está feita pelo direcionador da construção ASIC.
P.. É somente entre o FIA em uma placa de processador da rota ativa e a tela que você usa o primeiro link, e então em seguida que é menos link carregado quando houver uns links múltiplos disponíveis?
A. Correto. O primeiro link que conecta ao primeiro exemplo XBAR no processador da rota ativa é usado a fim injetar o tráfego na tela. O pacote de resposta do NP pode alcançar de volta à placa de processador da rota ativa em alguns de todos os links que conectam ao cartão do processador de rotas. A escolha do link depende da carga de link.
P.. Durante o retreinamento, todos os pacotes que são enviados sobre esse link da tela são perdidos?
R. Sim, mas com os realces na liberação 4.3.2 e mais atrasado, o retreinamento é virtualmente undetectible. Contudo, no código inicial, poderia tomar diversos segundos para treinar novamente, que conduziram aos pacotes perdidos para esse tempo de frame.
P.. Como frequentemente você espera ver uma tela XBAR ligar o evento do retreinamento depois que você promove a uma liberação ou a um SMU com o reparo para a identificação de bug Cisco CSCuj10837?
R. Mesmo com o reparo para a identificação de bug Cisco CSCuj10837 é ainda possível ver a tela ligar os retreinamentos devido à identificação de bug Cisco CSCul39674. Mas uma vez que um cliente tem o reparo para a identificação de bug Cisco CSCul39674, a instrucção do link da tela nos links do backplane da tela entre o RSP440 e as placas de linha Tufão-baseadas deve nunca ocorrer. Se faz, a seguir para levantar um pedido do serviço com o centro de assistência técnica da Cisco (TAC) a fim pesquisar defeitos o problema.
P.. O Bug da Cisco ID CSCuj10837 e CSCul39674 afeta o RP no ASR 9922 com placas de linha Tufão-baseadas?
R. Sim
P.. O Bug da Cisco ID CSCuj10837 e CSCul39674 afeta o Roteadores do ASR-9001 e ASR-9001-S?
R. Não
P.. Se você encontra a falha de um entalhe que não exista com esta mensagem, "PLATFORM-DIAGS-3-PUNT_FABRIC_DATA_PATH_FAILED: O ponto inicial do pontapé/tela/trajeto de dados Test(0x2000004)|failure Set|online_diag_rsp[237686]|System é 3, (entalhe, NP) falhado: (8, 0)," em um chassi 10-slot, que o entalhe tenha a edição?
R. Em umas liberações mais velhas, você deve esclarecer o exame e os mapeamentos lógicos como mostrado aqui. Neste exemplo, o entalhe 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
Dados a recolher antes da criação do pedido do serviço
Estão aqui os comandos mínimos que você deve recolher antes que toda a ação esteja tomada:
- Show logging
- Mostre o lugar todo do pfm
- detalhe do teste 8 do lugar 0/rsp0/cpu0 do resultado do diagn da mostra admin
- detalhe do teste 8 do lugar 0/rsp1/cpu0 do resultado do diagn da mostra admin
- detalhe do teste 9 do lugar 0/rsp0/cpu0 do resultado do diagn da mostra admin
- detalhe do teste 9 do lugar 0/rsp1/cpu0 do resultado do diagn da mostra admin
- detalhe do teste 10 do lugar 0/rsp0/cpu0 do resultado do diagn da mostra admin
- detalhe do teste 10 do lugar 0/rsp1/cpu0 do resultado do diagn da mostra admin
- detalhe do teste 11 do lugar 0/rsp0/cpu0 do resultado do diagn da mostra admin
- detalhe do teste 11 do lugar 0/rsp1/cpu0 do resultado do diagn da mostra admin
- mostre o <lc> do lugar do status do link FIA da tela do controlador
- mostre o rsp> do <both do lugar do status do link FIA da tela do controlador
- mostre o rsp> do <both do lugar do status de sincronização da ponte FIA da tela do controlador
- mostre a exemplo do status do link da barra transversal da tela do controlador 0 <lc> do lugar
- mostre a exemplo do status do link da barra transversal da tela do controlador 0 rsp> do <both do lugar
- mostre a exemplo do status do link da barra transversal da tela do controlador 1 rsp> do <both do lugar
- mostre o rsp> do <both do lugar da barra transversal do ltrace da tela do controlador
- mostre o lc> <affected lugar da barra transversal do ltrace da tela do controlador
- mostre o <fault do lugar da tela da tecnologia que mostra o <path do arquivo do lc> ao file>
- mostre o <path do arquivo do rsp> do <both do lugar da tela da tecnologia ao file>
Comandos diagnostic úteis
Está aqui uma lista de comandos que são úteis para propósitos de diagnóstico:
- mostre ajustes diagnósticos do ondemand
- mostre o lugar satisfeito diagnóstico < lugar >
- mostre o lugar < lugar > do resultado de diagnóstico [teste {identificação|id_list|tudo}] [detail]
- mostre o estado diagnóstico
- teste diagnóstico < do lugar > do lugar do começo admin {identificação|id_list|suite de teste}
- lugar de parada diagnóstico < lugar > admin
- iterações diagnósticas < iteração-contagem > do ondemand admin
- ação-em-falha diagnóstica do ondemand admin {continue o contagem de falha|parada}
- teste < do lugar > do lugar do monitor diagnóstico do [no] admin-config# {identificação | [disable] do teste-nome}
- teste < do lugar > do lugar do intervalo do monitor diagnóstico do [no] admin-config# {identificação | hora do dia do teste-nome}: minuto: second.millisec
- teste < do lugar > do lugar do ponto inicial do monitor diagnóstico do [no] admin-config# {identificação | contagem de falha do teste-nome}
Conclusão
Do Software Cisco IOS XR libere o tempo de frame 4.3.4, a maioria emite relacionado às falhas do trajeto de dados da tela do pontapé são endereçados. Para o Roteadores afetado pelo Bug da Cisco ID CSCuj10837 e CSCul39674, carregue o SMU de substituição para CSCul39674 a fim evitar eventos do retreinamento do link da tela.
A equipe da plataforma instalou a falha avançada que segura de modo que o roteador recuperasse nos subseconds se e quando toda a falha recuperável do trajeto de dados ocorre. Contudo, este documento é recomendado a fim compreender este problema, mesmo se nenhuma tal falha é observada.
Apêndice
Trajeto de diagnóstico de loopback NP
O aplicativo diagnóstico que executa na placa de linha CPU segue a saúde de cada NP com verificações periódicas do estado de trabalho do NP. Um pacote é injetado da placa de linha CPU destinado ao NP local, que o NP deve loop-back e retornar à placa de linha CPU. Toda a perda em tais pacotes periódicos é embandeirada com um mensagem de registro da plataforma. Está aqui um exemplo de tal 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
Este mensagem de registro significa este teste não é recebido o pacote do laço de retorno de NP3. A máscara da falha do link é 0x8 (mordido 3 é ajustado), que indica uma falha entre a placa de linha CPU para o entalhe 7 e NP3 no entalhe 7.
A fim obter mais detalhes, recolha a saída destes comandos:
- detalhe do teste 9 do lugar 0/<x>/cpu0 do resultado de diagnóstico da mostra admin
- mostre a controladores o lugar 0/<x>/cpu0 do contador NP<0-3> NP
Comandos Debug da tela
Os comandos alistados nesta seção aplicam-se a todas as placas de linha Trident-baseadas assim como à placa de linha 100GE Tufão-baseada. A ponte FPGA ASIC não está atual em placas de linha Tufão-baseadas (à exceção das placas de linha Tufão-baseadas 100GE). Assim, os comandos bridge FIA da tela do controlador da mostra não se aplicam às placas de linha Tufão-baseadas, à exceção das versões 100GE.
Esta representação pictórico ajuda a traçar cada comando show ao lugar no trajeto de dados. Use estes comandos show a fim isolar quedas de pacote de informação e falhas.
FeedbackDeixe-nos ajudar
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)