Guia de solução de problemas de falhas de caminho de dados de malha de montagem ASR 9000 Series
Contents
Introduction
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.
Prerequisites
Requirements
A Cisco recomenda que você tenha um conhecimento de alto nível destes tópicos:
- Placas de linha ASR 9000
- Placas de malha
- Processadores de rota
- Arquitetura do chassi
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.
Componentes Utilizados
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.
Como usar este documento
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:
- Quando não houver urgência para a causa raiz de uma falha de caminho de dados de estrutura punt, leia todas as seções deste documento. Este documento cria o plano de fundo necessário para isolar um componente defeituoso quando esse erro ocorre.
- Use a seção FAQ se você tiver uma pergunta específica em mente para a qual uma resposta rápida é necessária. Se a pergunta não estiver incluída na seção FAQ, verifique se o documento principal aborda a pergunta.
- Use todas as seções de Analyze Faults on para isolar o problema em um componente defeituoso quando um roteador apresenta uma falha ou para verificar se é um problema conhecido.
Informações de Apoio
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:
Caminho do pacote de diagnóstico da estrutura de busca
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.
Visão Conceitual do Caminho de Diagnóstico
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.
Caminho do pacote entre a placa do processador de rota ativa e a 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.
Caminho do pacote entre a placa do processador de rota em standby e a placa de linha
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.
Caminho do pacote de diagnóstico da estrutura de busca na placa de linha baseada em tendências
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.
Caminho do pacote de diagnóstico da estrutura de busca na placa de linha baseada em tufão
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.
Punt Fabric Diagnostic Packet Path na placa de linha baseada em Tomahawk, Lightspeed e LightspeedPlus
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.
Relatório de falha e alarme de diagnóstico da estrutura de busca
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 do Pacote de Diagnóstico da Placa de Linha Baseada em Trident
Falha de diagnóstico NP0
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.
Análise de falha de diagnóstico NP0
Cenário de falha única
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)
Como ilustrado no diagrama de caminho de dados anterior, a falha deve estar em um ou mais desses locais:
- Link que conecta NP0 e B0
- Filas B0 internas direcionadas para NP0
- Interno NP0
Cenário de várias falhas
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.
Falha de diagnóstico NP1
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
Análise de falha de diagnóstico NP1
Consulte a seção NP0 Diagnostic Failure Analysis, mas aplique o mesmo raciocínio para NP1 (em vez de NP0).
Falha de diagnóstico NP2
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
Análise de falha de diagnóstico NP2
Consulte a seção NP0 Diagnostic Failure Analysis, mas aplique o mesmo raciocínio para NP2 (em vez de NP0).
Falha de diagnóstico NP3
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
Análise de falha de diagnóstico NP3
Consulte a seção NP0 Diagnostic Failure Analysis, mas aplique o mesmo raciocínio para NP3 (em vez de NP0).
Caminho do pacote de diagnóstico da placa de linha baseada em tufão
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.
Falha de diagnóstico do tufão NP1
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
Falha de diagnóstico do tufão NP3
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
Caminho do pacote de diagnóstico da placa de linha baseada em Tomahawk
Devido à conectividade 1:1 entre o FIA e o NP, o único tráfego que atravessa o FIA0 é para/do NP0.
Lightspeed- e LightspeedPlus Line Card Diagnostic Packet Path
Como o FIA está integrado no chip NP, o único tráfego que atravessa o FIA0 é para/do NP0.
Analisar falhas
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.
Falha transitória
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ções corretivas de falha transitórias
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.
Falha difícil
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)
Ações Corretivas de Falhas Difíceis
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).
Analisar falhas transitórias
Conclua estes passos para analisar falhas transitórias.
- Digite o comando show logging | inc "PUNT_FABRIC_DATA_PATH" para descobrir se o erro ocorreu uma ou várias vezes.
- Insira o comando show pfm location all para determinar o status atual (SET ou CLEAR). O erro está pendente ou foi apagado? Se o status do erro for alterado entre SET e CLEAR, uma ou mais falhas no caminho de dados da estrutura ocorrerão repetidamente e serão corrigidas por software ou hardware.
- Provisione interceptações SNMP (Simple Network Management Protocol) ou execute um script que coleta a saída do comando show pfm location all, e procure a string de erro periodicamente para monitorar a ocorrência futura da falha (quando o último status do erro for CLEAR e nenhuma falha nova ocorrer).
Comandos a serem usados
Insira estes comandos para analisar falhas transitórias:
- show logging | inc "PUNT_FABRIC_DATA_PATH"
- show pfm location all
Analisar falhas de hardware
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.
Comandos a serem usados
Insira estes comandos para analisar falhas físicas:
- show logging | inc "PUNT_FABRIC_DATA_PATH"
A saída pode conter um ou mais NPs (exemplo: NP2, NP3). - show controller fabric fia link-status location <lc>
Como o NP2 e o NP3 (na seção Falha de Diagnóstico do NP3 do Tufão) recebem e enviam por um único FIA, é razoável inferir que a falha está em um FIA associado no caminho. - show controller fabric crossbar link-status instance <0 and 1> location <LC or RSP>
Se todos os NPs na placa de linha não forem alcançáveis para o aplicativo de diagnóstico, então é razoável inferir que os links que conectam o slot da placa de linha à placa do processador de rota podem ter uma falha em qualquer um dos ASICs que encaminham o tráfego entre a placa do processador de rota e a placa de linha.
show controller fabric crossbar link-status instance 0 location <lc>
show controller fabric crossbar link-status instance 0 location 0/rsp0/cpu0
show controller fabric crossbar link-status instance 1 location 0/rsp0/cpu0
show controller fabric crossbar link-status instance 0 location 0/rsp1/cpu0
show controller fabric crossbar link-status instance 1 location 0/rsp1/cpu0 - show controller fabric fia link-status location 0/rsp*/cpu0
show controller fabric fia link-status location 0/rsp0/cpu0
show controller fabric fia link-status location 0/rsp1/cpu0 - show controller fabric fia bridge sync-status location 0/rsp*/cpu0
show controller fabric fia bridge sync-status location 0/rsp0/cpu0
show controller fabric fia bridge sync-status location 0/rsp1/cpu0
show tech fabric terminal
Falhas anteriores
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.
Erro transitório devido ao excesso de assinatura NP
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
Falha difícil devido a NP Fast Reset
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
Falhas entre os processadores de rota RSP440 e as placas de linha de tufão
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:
- O link cai e sobe. (Transitório)
- O link fica permanentemente inativo.
ID de bug da Cisco CSCuj10837 - Fabric Retrain Between RSP and LC (Direção TX)
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.
ID de bug da Cisco CSCul39674 - Fabric Retrain Between RSP and LC (RX Direction)
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.
Diferenças de treinamento de malha na versão 4.3.2 e posterior
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
Falha devido ao estouro FIFO de ASIC de estrutura
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
Falha devido ao grande aumento da fila de saída virtual (VOQ) do congestionamento de estrutura
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.
Comandos relevantes
Você deve reunir estes comandos:
- show tech-support fabric
- show controller fabric fia bridge flow-control location <LC> <==== Obtenha esta saída para todos os LCs
- show controllers fabric fia q-deep location <LC>
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.
Impacto no tráfego devido a erros de software Bridge/FPGA em placas de linha baseadas em Trident
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 <==========
Comandos para coleta de erros de software de bridge/FPGA em placas de linha baseadas em tendências
Você deve reunir estes comandos:
- show tech-support fabric
- show tech-support np
- show controller fabric fia bridge stats location <> (obtenha várias vezes)
Recuperação de 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 de Diagnóstico Online
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
Aprimoramentos de recuperação automática
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.
Perguntas frequentes (FAQ)
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
Dados a serem coletados antes da criação da solicitação de serviço
Aqui estão os comandos mínimos que você deve coletar antes de qualquer ação ser tomada:
- Show logging
- Show pfm location all
- admin show diagn result loc 0/rsp0/cpu0 test 8 detail
- admin show diagn result loc 0/rsp1/cpu0 test 8 detail
- admin show diagn result loc 0/rsp0/cpu0 test 9 detail
- admin show diagn result loc 0/rsp1/cpu0 test 9 detail
- admin show diagn result loc 0/rsp0/cpu0 test 10 detail
- admin show diagn result loc 0/rsp1/cpu0 test 10 detail
- admin show diagn result loc 0/rsp0/cpu0 test 11 detail
- admin show diagn result loc 0/rsp1/cpu0 test 11 detail
- show controller fabric fia link-status location <lc>
- show controller fabric fia link-status location <both rsp>
- show controller fabric fia bridge sync-status location <both rsp>
- show controller fabric crossbar link-status instance 0 location <lc>
- show controller fabric crossbar link-status instance 0 location <ambos rsp>
- show controller fabric crossbar link-status instance 1 location <ambos rsp>
- show controller fabric ltrace crossbar location <both rsp>
- show controller fabric ltrace crossbar location <affected lc>
- show tech fabric location <falha ao mostrar lc> arquivo <caminho para arquivo>
- show tech fabric location <ambos rsp> arquivo <caminho para arquivo>
Comandos de diagnóstico úteis
Esta é uma lista de comandos úteis para fins de diagnóstico:
- show diagnostic ondemand settings
- show diagnostic content location < loc >
- show diagnostic result location < loc > [ test {id|id_list|all} ] [ detail ]
- show diagnostic status
- admin diagnóstico local inicial < loc > teste {id|id_list|test-suite}
- admin diagnóstico stop location < loc >
- admin diagnósticos sob demanda iterações < contagem de iterações >
- admin diagnóstico sob demanda action-on-failure {continue failure-count|stop}
- admin-config#[ no ] local do monitor de diagnóstico < loc > teste {id | test-name} [disable]
- admin-config# [ no ] local do intervalo do monitor de diagnóstico < loc > teste {id | nome do teste} hora do dia:minuto:segundo.millisec
- admin-config# [ no ] local do limite do monitor de diagnóstico < loc > teste {id | test-name} contagem de falhas
Conclusão
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.
Appendix
Caminho de diagnóstico de loopback NP
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:
- admin show diagnostic result location 0/<x>/cpu0 test 9 detail
- show controllers NP counter NP <0-3> local 0/<x>/cpu0
Comandos de depuração de estrutura
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.
FeedbackContate a Cisco
- Abrir um caso de suporte
- (É necessário um Contrato de Serviço da Cisco)