Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Gerenciamento de erros

Configuração dos níveis de erro e ações do FPC

Começando com o Junos OS Release 13.3 ou Release 14.2 para roteadores M320, você pode usar roteadores MX Series, PTX Series e T Series para configurar os níveis de erro relacionados ao Mecanismo de encaminhamento de pacotes (PFE) em FPCs e as ações a serem executadas quando um limite especificado é atingido. No Junos OS Release 13.2 e anteriores, os erros do mecanismo de encaminhamento de pacotes desativariam o FPC. Quando você usa o comando, os erros do error mecanismo de encaminhamento de pacotes podem ser isolados, o que reduz a necessidade de uma substituição de campo. Usando o error comando, você pode classificar erros de acordo com a gravidade, definir uma ação de recuperação automática para cada gravidade e configurar as ações a serem executadas quando um limite especificado for atingido. Este comando está disponível nas [edit chassis fpc slot-number] hierarquias.[edit chassis]

Para configurar os níveis de erro e as ações do mecanismo de encaminhamento de pacotes para um FPC:

  • (Opcional) Configure o limiar e a ação do nível de erro fatal. Um erro fatal é um erro que resulta em bloqueio de uma quantidade considerável de tráfego entre módulos.

    Se o nível de gravidade do erro for fatal, a ação é realizada quando o número total de erros atinge o valor limite. Depois que o valor limite é cruzado, para cada ocorrência do erro, uma ação é realizada.

  • (Opcional) Configure o limite e a ação de nível de erro principais. Um erro importante é um erro que resulta em perda contínua de tráfego de pacotes, mas não afeta outros módulos.

    Se o nível de gravidade do erro for maior, a ação é realizada quando o número total de erros atinge o valor limite. Depois que o valor limite é cruzado, para cada ocorrência do erro, uma ação é realizada.

  • (Opcional) Configure o limite e a ação do nível de erro menor. Um pequeno erro é um erro que resulta na perda de um único pacote, mas que é totalmente recuperável.

    Se o nível de gravidade for menor, a ação é realizada apenas uma vez quando o número total de erros atinge o valor limite

Começando pelo Junos OS Release 18.1R3, os roteadores da Série MX oferecem suporte à configuração de limiares de erro e ações nos níveis de escopo de erro e categoria de erro. Use o comando set chassis fpc fpc-slot error scope error-scope category category (fatal | major | minor) threshold error-threshold action (alarm | disable-pfe | get-state | offline | log | reset | trap | online-pfe | reset-pfe) para configurar um limite e uma ação para um escopo e categoria de erro específicos no nível do FPC. Você também pode configurar esses recursos no nível do chassi (na [edit chassis] hierarquia). No entanto, o limiar e a ação [edit chassis fpc] configurados na hierarquia substitui a mesma configuração na [edit chassis] hierarquia.

Você pode usar o comando show chassis fpc errors para visualizar as informações de erro no escopo de erro e no nível da categoria.

Para o Junos OS Evolved, você pode usar os seguintes show comandos para visualizar as informações de erro:

  • show system errors count— exibe erros em todo o sistema e sua contagem.

  • show system errors active— exibe erros ativos atuais no sistema.

  • show system errors active fpc <slot number> — exibe erros ativos para o FPC especificado.

  • show system errors fru detail— Exibe um erro detalhado específico da FRU.

  • show system errors fru detail fpc <slot number>— exibe informações sobre erros detectados com base na FRU.

Se você tiver configurado a ação log contra um limite de erro específico, o sistema registra o evento quando a contagem de erros viola o limite definido. As mensagens de syslog de amostra a seguir indicam uma violação do limiar de erro e a ação resultante que está sendo tomada:

As offline, reset, disable-pfe, offline-pfe ações e as reset-pfe ações são mutuamente exclusivas em relação à configuração. O PFE especificado é desativado automaticamente, se offline-pfe ou reset-pfe está configurado.

Nota: Uma ação padrão de alarme de FPC é adicionada para MPC6E. A opção disable-pfe está disponível nas versões Junos 17.4 e posteriores.

A tabela a seguir fornece detalhes sobre as ações de mapeamento de erros do PFE e a resposta do sistema:

Tabela 1: Ação e resposta ao mapeamento de erros do PFE
Resposta à ação
disable-pfe Desativa todas as interfaces PFE, alarmes e logs.
offline Tira o FPC offline, desativa os alarmes e os logs.
reset Tira o FPC offline e reinicia on-line, permite os alarmes e logs.
reset-pfe Desativa o PFE, desativa os alarmes e logs e, em seguida, ativa o PFE, permite que os alarmes e logs.
offline-pfe Desativa o PFE, desativa os alarmes e logs,

Exemplo: Configuração da detecção de erros do FPC e da autorrecuração em roteadores de núcleo da Série T

Este exemplo mostra como configurar a detecção de erros e a auto-cura em um roteador de núcleo da Série T da Juniper Networks com FPC Tipo 5.

Requisitos

Este exemplo usa os seguintes componentes de hardware e software:

  • Roteador de núcleo T4000 da Juniper Networks com FPCs tipo 5.

  • Versão 13.3 ou posterior do Junos OS.

Antes de prosseguir, certifique-se de que as conexões necessárias estejam completas e que as interfaces estejam funcionais.

Visão geral

A detecção de erros e a auto-cura do FPC envolvem a configuração de um conjunto de ações a serem realizadas em cada FPC, quando o número de erros para uma gravidade específica aumenta além de um limiar configurado pelo usuário. A gravidade do erro é categorizada em fatal, maior e menor. As ações de recuperação incluem levantar um alarme, gerar entradas de log, obter o estado atual do FPC, reiniciar o FPC, tirar o FPC offline e redefinir o FPC. Para um FPC específico e gravidade de erro, você pode configurar o limite de erro para qualquer valor dentro dos limites permitidos e mapear o limite para uma ação. Neste exemplo, você definirá esses erros no FPC 0 no roteador de núcleo T4000 da Juniper Networks.

Configuração

Para configurar a detecção de erros e a auto-cura, você precisa definir a gravidade do erro, os valores de limiar correspondentes a cada gravidade de erro e as ações a serem realizadas quando o valor limite for cruzado.

Configuração rápida da CLI

Para configurar rapidamente este exemplo, copie os seguintes comandos, cole-os em um arquivo de texto, remova qualquer quebra de linha, altere os detalhes necessários para combinar com a configuração da sua rede e, em seguida, copie e cole os comandos no CLI no nível de hierarquia [editar interfaces].

Configurando a detecção de erros e a autorrecorreção

Procedimento passo a passo

O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar na CLI, consulte Usando o Editor de CLI no modo de configuração e o Guia do usuário da CLI.

  • Configure o valor limite e a ação associada para erros fatais.

    1. Configure a gravidade do erro como fatal.

      [edit interfaces]

      user@host# set chassis fpc 0 error fatal

    2. Defina o valor limite para erros fatais.

      [edit interfaces]

      user@host# set chassis fpc 0 error fatal threshold 1

    3. Definir a ação associada para erros fatais.

      [edit interfaces]

      user@host# set chassis fpc 0 error fatal threshold 1 action reset

  • Configure o valor limite e a ação associada para grandes erros.

    1. Definir a gravidade do erro para maior.

      [edit interfaces]

      user@host# set chassis fpc 0 error major

    2. Defina o valor limite para erros graves.

      [edit interfaces]

      user@host# set chassis fpc 0 error major threshold 1

    3. Definir a ação associada para grandes erros.

      [edit interfaces]

      user@host# set chassis fpc 0 error major threshold 1 action alarm

  • Configure o valor limite e a ação associada para pequenos erros.

    1. Configure a gravidade do erro em menor.

      [edit interfaces]

      [edit interfaces]

      user@host# set chassis fpc 0 error minor

    2. Defina o valor limite para pequenos erros.

      [edit interfaces]

      user@host# set chassis fpc 0 error minor threshold 10

    3. Definir a ação associada para pequenos erros.

      [edit interfaces]

      user@host# set chassis fpc 0 error minor threshold 10 action log

Resultados

A seguir, o resultado da configuração para o nível de gravidade fatal.

Se você terminar de configurar os dispositivos, entre no commit modo de configuração.

Verificação

Para verificar se a configuração é bem-sucedida e o roteador configurado com a ação correta, use o show chassis fpc errors comando.

Verificação das ações configuradas relacionadas à gravidade fatal de erro do FPC

Propósito

Certifique-se de que o valor limite e a ação associada estejam definidos para erros fatais.

Ação
Significado

A saída de amostra mostra Fatal erro no FPC 0 com 0 erro Occurred (sem ocorrências anteriores), 0 erro Cleared (sem ocorrências anteriores) com Threshold valor definido e Action-Taken definido para 1 RESET.

Gerenciamento de erros de FPC

Nos roteadores da série PTX, você pode desabilitar um erro de FPC ou modificar a gravidade do erro no nível de id de erro. Consulte a auto-cura do FPC para obter detalhes em plataformas PTX que oferecem suporte a esse recurso.

A id de erro, que identifica exclusivamente um erro de FPC, está representada no formato de identificador de recursos uniforme (URI) e é composta por um identificador de módulo e um identificador de erro. Se ocorrer um erro, você pode encontrar a id de erro nas mensagens de log do sistema.

Modificando a gravidade de um erro

Embora você não possa configurar uma nova gravidade de erro, você pode modificar a gravidade existente de um erro. Por exemplo, se você não quiser tratar um erro específico (identificado por uma identificação de erro) como fatal mais, você pode modificar sua gravidade para maior ou menor, conforme necessário.

Nota:

Você não pode modificar a gravidade do erro em um nível de grupo (por exemplo, categoria).

Para modificar a gravidade de um erro, use o seguinte comando:

Veja o exemplo a seguir:

No exemplo acima, você modificou a gravidade do ID “/cpu/0/memory/0/memory-uncorrected-error” de erro no FPC 3 para minor.

Desativação de um erro

Para configurar o sistema para parar de relatar um erro, identifique a id de erro e desabiira-a. Você pode encontrar a id de erro nas mensagens de log do sistema. Para desativar um erro, use o seguinte comando:

Veja o exemplo a seguir:

No exemplo acima, você desabilitou o erro “/cpu/0/memory/0/memory-uncorrected-error” no FPC 3.

Alimentação dos mecanismos de encaminhamento de pacotes

Você pode ativar ou alimentar os mecanismos de encaminhamento de pacotes em um sistema em execução, ou manter um mecanismo de encaminhamento de pacotes desligado quando o FPC estiver on-line. A seguir, alguns cenários em que esse recurso é usado.

  • Quando o ASIC do mecanismo de encaminhamento de pacotes estiver funcionando mal.

  • Para economizar energia caso a implantação não exija a capacidade total do sistema.

Para alimentar um mecanismo de encaminhamento de pacotes, use as seguintes etapas:

Para alimentar um mecanismo de encaminhamento de pacotes, use as seguintes etapas:

Nota:

Você precisa aplicar essa configuração aos mecanismos de encaminhamento de pacotes em um ASIC para poder confirmar a configuração.

Nota:

Em roteadores da série MX com MPC10E-15C-MRATE, você pode desligar ou alimentar apenas o Mecanismo de encaminhamento de pacotes 2. Os mecanismos de encaminhamento de pacotes 0 e 1 não suportam este comando. No MPC10E-15C-MRATE, a operação do Mecanismo de encaminhamento de pacotes 2 exige que os mecanismos de encaminhamento de pacotes 0 e 1 sejam funcionais. Você pode usar o comando show chassis fpc fpc-lot detail para visualizar o status ON/OFF do mecanismo de encaminhamento de pacotes e largura de banda para os mecanismos de encaminhamento de pacotes individuais no MPC10E-15C-MRATE.

Você pode usar o show chassis fpc fpc-slot detail comando para visualizar o status da configuração do mecanismo de encaminhamento de pacotes. Veja um exemplo abaixo:

Configuração de pesquisas de sanidade

Você pode configurar a sanity-poll declaração para um determinado FPC ou FEB ou CFEB para iniciar uma verificação de sanidade periódica para esse FPC ou FEB ou CFEB. A verificação de sanidade periódica inclui verificar se há condições de erro, como "registrar problemas de sanidade", "alta temperatura", "falha de hardware" e assim por diante. Se você não configurar a sanity-poll declaração, a votação sanidade será desabilitada.

Nota:

Atualmente, a verificação de sanidade periódica é realizada apenas no registro de chip de roteamento.

A votação de sanidade verifica periodicamente uma condição de erro em um FPC ou FEB ou CFEB e executa as ações apropriadas em caso de erro.

  • Para configurar a votação de sanidade para um FPC em roteadores da Série T e roteadores M320, inclua a sanity-poll declaração e seus subestações no [edit chassis fpc slot-number] nível de hierarquia:

  • Para configurar a votação de sanidade para um FEB no roteador M120, inclua a sanity-poll declaração e seus subestações no nível hierárquicos [edit chassis feb slot-number] :

  • Para configurar a votação de sanidade para um CFEB em roteadores M7i e M10, inclua a sanity-poll declaração e seus subestações no [edit chassis cfeb slot-number] nível hierárquicos:

Nota:

Em um roteador TX Matrix ou TX Matrix Plus, você pode configurar a sanity-poll declaração no nível de [edit chassis lcc number fpc number] hierarquia.

A sanity-poll declaração compreende os seguintes subestações:

  • A retry-count declaração especifica o número de verificações a serem realizadas após a ocorrência de uma determinada condição de erro. Se houver um erro em todas as verificações periódicas, então a sanidade da votação relata um erro e prossegue para realizar as ações apropriadas (descritas como opções da on-error declaração).

    Por exemplo, se a verificação de sanidade periódica detectar um erro no FPC ou FEB ou CFEB e se você configurar o a 15, a retry count number sondagem de sanidade não informará o erro imediatamente. A votação de Sanity verifica 15 vezes a mesma condição de erro. Se um erro persistir em todos os 15 rechecks, ele relata um erro e toma as ações apropriadas.

    Se você não configurar a retry-count declaração e depois por padrão, a sanity-poll declaração verifica novamente o erro detectado 10 vezes antes de relatar uma condição de erro.

  • Se a sondagem sanidade detectar uma condição de erro, a on-error declaração executará as ações apropriadas para eliminar o erro.

    As ações a seguir são comuns a todos os tipos de condições de erro:

    • Para gerar um alarme de chassi, configure a raise-alarm declaração. O alarme do chassi é exibido no painel frontal do chassi.

    • Para reiniciar o FPC, FEB ou CFEB após a geração de um arquivo principal, configure a power cycle declaração. Esta declaração é útil para erros temporários de software que são eliminados após a reinicialização.

    • Para interromper o FPC, FEB ou CFEB, configure a power off declaração. Essa declaração é útil em caso de falha permanente no hardware.

      CUIDADO:

      A power off declaração interrompe o FPC. Certifique-se de ter caminhos de backup por um FPC ou FEB ou CFEB diferentes para evitar interrupções no serviço.

      Nota:

      As power cycle declarações e power off as declarações são mutuamente exclusivas: você pode configurar a ação power cycle ou a ação power off para um erro.

    • Para acionar o arquivo principal, configure a write-coredump declaração.

Você pode configurar várias ações para um determinado FPC ou FEB ou CFEB. Se você não configurar nenhuma ação, a sanity-poll declaração gera apenas mensagens de log do sistema FPC ou FEB ou CFEB.

Configurando o Junos OS para tornar um concentrador PIC flexível fique offline

Por padrão, um concentrador PIC flexível (FPC) é configurado para reiniciar após uma reinicialização do sistema. Você pode usar o comando de request chassis fpc modo operacional para tirar um FPC offline, mas no Junos OS o FPC tenta reiniciar quando você entra em um commit comando CLI. Para configurar um FPC para ficar offline e evitar que ele reinicie, inclua a power off declaração no nível de [edit chassis fpc slot-number] hierarquia:

Para colocar um FPC on-line configurado para ficar offline e configurá-lo para permanecer on-line, inclua a power on declaração no nível de [edit chassis fpc slot-number] hierarquia:

Configurando um SFM para ficar offline

Por padrão, se você usar o request chassis sfm comando CLI para tirar um módulo de comutação e encaminhamento (SFM), a SFM tenta reiniciar quando você entra em um commit comando CLI. Para evitar uma reinicialização, você pode configurar um SFM para permanecer offline. Esse recurso é útil para situações de reparo.

Para configurar um SFM para permanecer offline, inclua a sfm declaração no nível de [edit chassis] hierarquia:

  • slot number— Número de slot em que o SFM está instalado.

  • power off— Tire o SFM offline e configure-o para permanecer offline.

Por exemplo, a declaração a seguir leva um SFM no slot 3 offline:

Use o show chassis sfm comando CLI para confirmar o status offline:

Para ativar o SFM, exclua a edit chassis sfm declaração e depois comprometa a configuração.

Ressincronizando os números de sequência de FPC com FPCs ativos quando um FPC entra em operação

Nos roteadores M320, T320, T640, T1600, T4000, TX Matrix e TX Matrix Plus, quando você colocar um Concentrador PIC Flexível (FPC) on-line, o número de sequência no FPC pode não ser sincronizado com os outros FPCs ativos no roteador, o que pode resultar na perda de uma pequena quantidade de tráfego inicial.

Para evitar qualquer perda de tráfego, inclua a fpc-resync declaração no nível de [edit chassis] hierarquia. Isso garante que os números de sequência do FPC que é colocado on-line sejam ressincronizados com os outros FPCs ativos no roteador.

Nota:

Para evitar a filtragem de rotas nulas, o fpc-resync comando não terá efeito se um único FPC baseado em LMNR e um ou mais FPCs I-chip existirem no mesmo chassi.

Permitindo que um mecanismo de roteamento reinicialize erros de disco rígido

Quando ocorre um erro de disco rígido, um mecanismo de roteamento pode entrar em um estado em que ele responde a pings e interfaces locais, mas nenhum outro processo está respondendo.

Para se recuperar dessa situação, você pode configurar um único mecanismo de roteamento para reiniciar automaticamente quando ocorre um erro de disco rígido. Para habilitar esse recurso, inclua a on-disk-failure reboot declaração no nível de [edit chassis routing-engine] hierarquia.

Para ambientes de mecanismo de roteamento duplo, você pode configurar um mecanismo de roteamento de backup para assumir automaticamente a função principal, se detectar um erro de disco rígido no mecanismo de roteamento primário. Para habilitar esse recurso, inclua a on-disk-failure declaração no nível de [edit chassis redundancy failover] hierarquia. Para obter informações sobre esta declaração, consulte o Guia de usuário de alta disponibilidade do Junos OS.

Você pode configurar o mecanismo de roteamento para parar (em vez de reiniciar) quando o disco rígido falha no mecanismo de roteamento. Para configurar esse recurso, inclua a disk-failure-action (halt | reboot) declaração no nível de [edit chassis routing-engine on-disk-failure] hierarquia:

Use a opção de parada para configurar o mecanismo de roteamento para parar quando o disco rígido falhar. Use a opção de reinicialização para configurar o mecanismo de roteamento para reiniciar quando o disco rígido falhar.

Tratamento de eventos de saúde térmica usando verificação de integridade térmica e cão de guarda PSM

Você pode usar o recurso de verificação de integridade térmica para configurar uma ação a ser tomada na detecção de um evento de saúde térmica, como vazamento de energia. O recurso de verificação térmica monitora a saída de energia do módulo de fonte de alimentação (PSM) e o consumo de energia FRU e se detecta que a saída de energia PSM excede o consumo de energia fru por um limiar definido pelo usuário, ele assume que há um evento de saúde térmica e toma uma ação com base na configuração do usuário. Você pode configurar ações como o desligamento automático ou alarmes a serem iniciados na detecção de um evento de saúde térmica. Um exemplo da configuração é o seguinte: set chassis thermal-health-check action-onfail auto-shutdown shutdown-timer 10 power-threshold 700. Esta configuração de exemplo permite que o software detecte um evento de integridade térmica se o vazamento de energia exceder 700W, e desativa o sistema 10 segundos após a detecção da falha de integridade térmica.

O recurso de verificação de integridade térmica só funciona se:

  • O roteador tem as unidades de distribuição de energia AC ou DC (PDU) de alta capacidade instaladas em ambos os slots, e cada PDU tem número igual de PSMs. Tanto o PSM ca quanto o PSM dc são suportados.

    Os PSMs e PDUs com suporte estão listados abaixo:

    • PSM AC de alta capacidade (modelo: PSM2-PTX-AC; firmware: 0210 ou posterior; revisão de hardware: 06 ou posterior)

    • PSM 60A DC de alta capacidade (modelo: PSM2-PTX-DC; firmware: 0315 ou posterior; revisão de hardware: 09 ou posterior)

    • PDU de alta capacidade 60A DC (modelo: PDU2-PTX-DC; use a versão de firmware 0404 ou posterior com revisão de hardware 07; use a versão de firmware 0503 ou posterior com a revisão de hardware 08)

    • PDU ac delta de alta capacidade (modelo: PDU2-PTX-AC-D; firmware: 0305 ou posterior; revisão de hardware: 04 ou posterior)

    • PDU AC Wye de alta capacidade (modelo: PDU2-PTX-AC-W; firmware: 0305 ou posterior; revisão de hardware: 03 ou posterior)

    • PDU AC de fase única de alta capacidade (modelo: PDU2-PTX-AC-SP; firmware: 0102 ou posterior; revisão de hardware: 03 ou posterior)

  • Cada PDU tem pelo menos três PSMs on-line, e cada PSM on-line está consumindo acima de 60A atual (no caso de um PSM AC) ou acima de 100A atual (no caso de um PSM DC).

  • Nenhuma das FRUs (RE, SIB e FPC) está no estado "Presente".

No roteador, você também pode configurar o recurso de cão de guarda PSM na hierarquia [editar chassis]. Se um evento de saúde térmica fizer o Junos diminuir, o recurso de cão de guarda PSM o detecta e desativa o roteador. Na configuração do cão de guarda, você pode especificar o tempor de cão de guarda em segundos. Após a duração especificada, o cão de guarda expira. Você também pode especificar a frequência (em minutos) em que o Junos reinicia o contador de cães de guarda. Se o contador de watchdog não for reiniciado por motivos como a falha do Mecanismo de Roteamento, o PSM desativa a potência de saída no temporizador de cão de guarda e, assim, desliga o roteador.

As configurações de exemplo são as seguintes:

  • Use set chassis psm watchdog timeout 600 pat-frequency 2. Esse comando permite o cão de guarda PSM com o temporizador de cão de guarda definido para 600 segundos e o contador está definido para ser reiniciado a cada 2 minutos.
  • Use set chassis thermal-health-check fet-failure-check action-onfail auto-shutdown shutdown-timer 10.. Esse comando permite a verificação da integridade térmica e fecha o sistema, 10 segundos após a detecção de falha no FET.
Nota:

O recurso de cão de guarda do PSM só funciona se todos os PSMs on-line no roteador suportarem esse recurso.

Em resumo, se o software Routing Engine estiver sendo executado quando ocorre um evento térmico, o recurso de verificação da integridade térmica detecta o evento térmico e toma uma ação. No entanto, se o software routing Engine cair em um evento de saúde térmica, é o temporização de cão de guarda PSM que detecta esse problema e derruba o sistema.

Tabela de histórico de lançamentos
Lançamento
Descrição
13.3
Começando com o Junos OS Release 13.3 ou Release 14.2 para roteadores M320, você pode usar roteadores MX Series, PTX Series e T Series para configurar os níveis de erro relacionados ao Mecanismo de encaminhamento de pacotes (PFE) em FPCs e as ações a serem executadas quando um limite especificado é atingido.