Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Entendendo o switchover de roteamento gracioso

Entendendo o switchover gracioso do mecanismo de roteamento

Este tópico contém as seguintes seções:

Conceitos graciosos de switchover de mecanismos de roteamento

O recurso gracioso de switchover do Mecanismo de Roteamento (GRES) no Junos OS e no Junos OS Evolved permite que um dispositivo com mecanismos de roteamento redundantes continue encaminhando pacotes mesmo que um mecanismo de roteamento falhe. O GRES preserva as informações de interface e kernel, e o tráfego não é interrompido. No entanto, o GRES não preserva o plano de controle.

Em plataformas de PTX10004, PTX10008 e PTX10016 que executam o Junos OS Evolved, o GRES é habilitado por padrão e não pode ser desativado.

Nota:

Em roteadores da Série T, roteadores TX Matrix e roteadores TX Matrix Plus, o plano de controle é preservado no caso de GRES com roteamento ativo ininterrupto (NSR), e quase 75% da taxa de linha de tráfego por Mecanismo de encaminhamento de pacotes permanece ininterrupta durante o GRES.

Os dispositivos vizinhos detectam que o dispositivo experimentou uma reinicialização e reagem ao evento de maneira prescrita pelas especificações do protocolo de roteamento individual.

Para preservar o roteamento durante uma troca, o GRES deve ser combinado com:

  • Extensões de protocolo de reinicialização graciosas

  • Roteamento ativo sem parar (NSR)

Todas as atualizações do mecanismo de roteamento primário são replicadas no mecanismo de roteamento de backup assim que ocorrem.

Nota:

Devido aos seus requisitos de sincronização e lógica, o desempenho do NSR/GRES é limitado pelo mecanismo de roteamento mais lento do sistema.

Switches de função primária para o mecanismo de roteamento de backup se:

  • O kernel principal do mecanismo de roteamento para de operar.

  • O mecanismo de roteamento primário experimenta uma falha de hardware.

  • O administrador inicia um switchover manual.

Nota:

Para restaurar ou preservar rapidamente as informações de estado do protocolo de roteamento durante uma transferência, o GRES deve ser combinado com o reinício gracioso ou o roteamento ativo ininterrupto, respectivamente. Para obter mais informações sobre a reinicialização graciosa, consulte Graciosa Restart Concepts. Para obter mais informações sobre o roteamento ativo sem parar, veja Conceitos de roteamento ativo sem parar.

Se o mecanismo de roteamento de backup não receber um keepalive do mecanismo de roteamento primário após 2 segundos (4 segundos em roteadores M20), ele determina que o mecanismo de roteamento primário falhou; e assume o papel principal.

O mecanismo de encaminhamento de pacotes:

  • Desconecta-se perfeitamente do antigo mecanismo de roteamento primário

  • Reconecta-se com o novo mecanismo de roteamento primário

  • Não reinicializa

  • Não interrompe o tráfego

O novo mecanismo de roteamento primário e o mecanismo de encaminhamento de pacotes ficam sincronizados. Se o novo mecanismo de roteamento primário detectar que o estado do Mecanismo de encaminhamento de pacotes não está atualizado, ele reencala mensagens de atualização de estado.

Observe os seguintes comportamentos, recomendações ou requisitos gres:

  • A partir do Junos OS Release 12.2, se adjacências entre o dispositivo de reiniciamento e os dispositivos "helper" de peer vizinhos forem liberadas, as extensões de protocolo de reinicialização graciosas não poderão notificar os dispositivos de "helper" dos pares sobre a reinicialização iminente. A reinicialização graciosa pode então parar e causar interrupções no tráfego.

    Para garantir que essas adjacências sejam mantidas, altere os hold-time protocolos IS-IS do padrão de 27 segundos para um valor superior a 40 segundos.

  • Os eventos sucessivos de comutação do mecanismo de roteamento devem ter um mínimo de 240 segundos (4 minutos) de diferença após ambos os mecanismos de roteamento terem sido montados.

    Se o dispositivo exibir uma mensagem de aviso semelhante a:

    em seguida, não tente uma mudança de switch. Se você optar por prosseguir com a transferência de switches, o dispositivo reinicia apenas os Mecanismos de encaminhamento de pacotes que não estavam prontos para switchover gracioso. Nenhum dos FPCs deve reiniciar espontaneamente. Recomendamos que você aguarde até que o aviso não apareça mais e depois prossiga com a transferência.

  • A partir do Junos OS Release 14.2, quando você executa GRES em roteadores da Série MX, você deve executar o comando de clear synchronous-ethernet wait-to-restore modo operacional no novo mecanismo de roteamento primário para limpar o temporização de espera para restaurar nele. Isso porque o comando do clear synchronous-ethernet wait-to-restore modo operacional libera o temporização de espera para restaurar apenas no Mecanismo de Roteamento local.

  • Em uma matriz de roteamento com roteador TX Matrix Plus com SIBs 3D, para sucessivas switches de mecanismo de roteamento, os eventos devem ter um mínimo de 900 segundos (15 minutos) de diferença após ambos os mecanismos de roteamento surgirem.

    Você deve realizar GRES em apenas um chassi de placa de linha (LCC) (de um roteador TX Matrix com SIBs 3D) de cada vez para evitar problemas de sincronização.

  • Não recomendamos:

    • Fazendo uma operação de confirmação no mecanismo de roteamento de backup quando o GRES estiver habilitado no dispositivo.

    • Habilitando o GRES no mecanismo de roteamento de backup em qualquer cenário.

  • Quando você habilita o roteamento sem parar com GRES em switches na linha QFX10000 que possuem mecanismos de roteamento redundantes, recomendamos fortemente que você configure a nsr-phantom-holdtime seconds declaração no nível hierárquico [edit routing-options] . Isso ajuda a evitar a perda de tráfego durante uma transição.

    Se você configurar essa declaração, os endereços IP fantasmas permanecerão no kernel durante a transferência até o intervalo de espera especificado expirar. Após o término do intervalo, o dispositivo adiciona as rotas correspondentes às tabelas de roteamento apropriadas. Em um ambiente Ethernet VPN (EVPN)-VXLAN, recomendamos que você especifique um valor de tempo de espera de 300 segundos (5 minutos).

    Essa opção não se aplica a switches QFX10002, que não têm mecanismos de roteamento redundantes e não oferecem suporte ao GRES.

A Figura 1 mostra a arquitetura de sistema do switchover gracioso do Mecanismo de Roteamento e o processo que uma plataforma de roteamento segue para se preparar para uma mudança de switch.

Figura 1: Preparação para um switchover gracioso do mecanismo de roteamento Preparing for a Graceful Routing Engine Switchover
Nota:

Verifique a prontidão do GRES executando ambos:

  • O request chassis routing-engine master switch check comando do mecanismo de roteamento primário

  • O show system switchover comando do mecanismo de roteamento de backup

O processo de preparação de switchover para GRES é o seguinte:

  1. O mecanismo de roteamento primário começa.

  2. Os processos da plataforma de roteamento (como o processo do chassi [chassi]) começam.

  3. O mecanismo de encaminhamento de pacotes começa e se conecta ao mecanismo de roteamento primário.

  4. Todas as informações de estado são atualizadas no sistema.

  5. O mecanismo de roteamento de backup começa.

  6. O sistema determina se o GRES foi habilitado.

  7. O processo de sincronização do kernel (ksyncd) sincroniza o mecanismo de roteamento de backup com o mecanismo de roteamento primário.

  8. Após o ksyncd concluir a sincronização, todas as informações de estado e a tabela de encaminhamento são atualizadas.

A Figura 2 mostra os efeitos de uma transição na plataforma de roteamento (ou comutação).

Figura 2: Processo gracioso de switchover do mecanismo de roteamento Graceful Routing Engine Switchover Process

Um processo de switchover compreende as seguintes etapas:

  1. Quando as atualizações do mecanismo de roteamento primário são perdidas, o sistema muda graciosamente para o mecanismo de roteamento de backup.

  2. O mecanismo de encaminhamento de pacotes se conecta ao mecanismo de roteamento de backup, que se torna o novo principal.

  3. Processos de plataforma de roteamento que não fazem parte do GRES (como o processo de protocolo de roteamento rpd) reiniciam.

  4. As informações de estado aprendidas com o ponto de transferência são atualizadas no sistema.

  5. Se configuradas, as extensões de protocolo de reinicialização graciosas coletam e restauram informações de roteamento de dispositivos de helper de peer helper vizinhos.

Nota:

Para roteadores da Série MX que usam gerenciamento aprimorado de assinantes, o novo mecanismo de roteamento de backup (o antigo mecanismo de roteamento primário) será reiniciado quando um switchover gracioso do Mecanismo de Roteamento for executado. Essa reinicialização a frio ressincroniza o estado do mecanismo de roteamento de backup com o do novo mecanismo de roteamento primário, evitando discrepâncias no estado que podem ter ocorrido durante a transferência.

Nota:

Durante o GRES na Série T e roteadores M320 durante o GRES, as placas de interface de switch (SIBs) são retiradas offline e reiniciadas uma a uma. Isso é feito para fornecer o Switch Processor Mezanino Board (SPMB) que gerencia o SIB tempo suficiente para preencher informações de estado para seu SIB associado. No entanto, em um chassi totalmente preenchido onde todos os FPCs estão enviando tráfego a uma taxa de linha completa, pode haver perda momentânea de pacotes durante a transição.

Nota:

Quando o GRES está configurado e o restart chassis-control comando é executado em um roteador TX Matrix Plus com SIBs 3D, você não pode determinar qual mecanismo de roteamento se torna o principal. Isso porque o processo de chassi reinicia com a execução do restart chassis-control comando. O processo do chassi é responsável por manter e manter a função primária e, quando é reiniciado, o novo chassi é processado com base na carga do dispositivo. Como resultado, qualquer um dos mecanismos de roteamento é feito o principal.

Efeitos da mudança de mecanismo de roteamento

A Tabela 1 descreve os efeitos de uma mudança de mecanismo de roteamento quando diferentes recursos são habilitados:

  • Sem recursos de alta disponibilidade

  • Switchover gracioso do mecanismo de roteamento

  • Reinicialização graciosa

  • Roteamento ativo sem parar

Tabela 1: Efeitos da mudança de mecanismo de roteamento

Recurso

Benefícios

Considerações

Mecanismos de roteamento duplos apenas (sem recursos habilitados)

  • Quando a transição para o novo mecanismo de roteamento primário estiver concluída, a convergência de roteamento ocorre e o tráfego é retomado.

  • Todas as interfaces físicas são retiradas offline.

  • Reinicie os mecanismos de encaminhamento de pacotes.

  • O mecanismo de roteamento de backup reinicia o processo de protocolo de roteamento (rpd).

  • Todos os hardwares e interfaces são descobertos pelo novo mecanismo de roteamento primário.

  • A mudança leva vários minutos.

  • Todas as adjacências do dispositivo estão cientes das mudanças físicas (alarmes de interface) e roteamento (topologia).

GRES habilitado

  • Durante a transferência, as informações de interface e kernel são preservadas.

  • A mudança é mais rápida porque os mecanismos de encaminhamento de pacotes não são reiniciados.

  • O novo mecanismo de roteamento primário reinicia o processo de protocolo de roteamento (rpd).

  • Todos os hardwares e interfaces são adquiridos por um processo semelhante a uma reinicialização calorosa.

  • Todas as adjacências estão cientes da mudança de estado do dispositivo.

GRES e NSR habilitados

  • O tráfego não é interrompido durante a transição.

  • As informações de interface e kernel estão preservadas.

  • Os protocolos sem suporte devem ser atualizados usando os mecanismos normais de recuperação inerentes a cada protocolo.

GRES e reinicialização graciosa habilitada

  • O tráfego não é interrompido durante a transição.

  • As informações de interface e kernel estão preservadas.

  • Extensões de protocolo de reinicialização graciosas coletam e restauram rapidamente as informações de roteamento dos dispositivos vizinhos.

  • Os vizinhos são obrigados a dar suporte à reinicialização graciosa, e é necessário um intervalo de espera.

  • O processo de protocolo de roteamento (rpd) é reiniciado.

  • Para certos protocolos, uma mudança significativa na rede pode fazer com que a reinicialização graciosa pare.

  • Começando com o Junos OS Release 12.2, se adjacências entre o dispositivo de reiniciamento e os dispositivos "helper" de peer vizinhos acabarem, a reinicialização graciosa pode parar e causar interrupções no tráfego.

Switchover gracioso do mecanismo de roteamento em interfaces de serviços agregados

Se um switchover gracioso do Mecanismo de Roteamento (GRES) for acionado por um comando de modo operacional, o dispositivo não preservará o estado das interfaces de serviços agregadas (ASIs). Por exemplo:

No entanto, se o GRES for acionado por um compromisso de CLI ou FPC, reinicie ou trava, o mecanismo de roteamento de backup atualiza o estado ASI. Por exemplo:

Ou:

Requisitos graciosos do sistema de switchover do mecanismo de roteamento

A transição graciosa do mecanismo de roteamento é suportada em todas as plataformas de roteamento (ou comutação) que contêm mecanismos de roteamento duplos. Todos os mecanismos de roteamento configurados para switchover gracioso do mecanismo de roteamento devem executar a mesma versão do Junos OS. O suporte de hardware e software para switchover gracioso do Mecanismo de Roteamento é descrito nas seguintes seções:

Suporte gracioso à plataforma de switchover de mecanismos de roteamento

Para habilitar a transferência graciosa do mecanismo de roteamento, seu sistema deve atender a esses requisitos mínimos:

  • Roteadores M20 e M40e — Junos OS Release 5.7 ou posterior

  • Roteador M10i — Junos OS Release 6.1 ou posterior

  • Roteador M320 — Junos OS Release 6.2 ou posterior

  • Roteador T320, roteador T640 e roteador TX Matrix — Junos OS Release 7.0 ou posterior

  • Roteador M120 — Junos OS Release 8.2 ou posterior

  • Roteador MX960 — Junos OS Release 8.3 ou posterior

  • Roteador MX480 — Versão Junos OS 8.4 ou posterior (8.4R2 recomendado)

  • Roteador MX240 — Junos OS Release 9.0 ou posterior

  • PTX5000 roteador — Junos OS Release 12.1X48 ou posterior

  • Roteador autônomo T1600 — Junos OS Release 8.5 ou posterior

  • Roteador T4000 autônomo — Junos OS Release 12.1R2 ou posterior

  • Roteador TX Matrix Plus — Junos OS Release 9.6 ou posterior

  • Roteador TX Matrix Plus com SIBs 3D — Junos Release 13.1 ou posterior

  • Switches da Série EX com mecanismos de roteamento duplos ou em um Virtual Chassis — Junos OS Versão 9.2 ou posterior para switches da Série EX

  • Switches da Série QFX em um Virtual Chassis — Junos OS Versão 13.2 ou posterior para a Série QFX

  • Switches da Série EX ou série QFX em uma malha virtual de chassi — Junos OS Versão 13.2X51-D20 ou posterior para os switches série EX e Série QFX

Para obter mais informações sobre o suporte ao switchover gracioso do Mecanismo de Roteamento, veja as seções a seguir.

Suporte gracioso ao recurso de switchover do mecanismo de roteamento

A comutação graciosa do mecanismo de roteamento oferece suporte à maioria dos recursos do Junos OS no lançamento 5.7 e posterior. Recursos específicos do Junos OS exigem versões específicas do Junos OS. Veja a tabela 2.

Tabela 2: Suporte gracioso ao switchover do mecanismo de roteamento

Aplicativo

Versão do Junos OS

Interfaces de ethernet agregadas com o Link Aggregation Control Protocol (LACP) e interfaces SONET agregadas

6.2

Circuitos virtuais do modo de transferência assíncronos (ATM) (VCs)

6.2

Sistemas lógicos

Nota:

No Junos OS Release 9.3 e posterior, o recurso do roteador lógico é renomeado para sistema lógico.

6.3

Multicast

6.4 (7.0 para roteador TX Matrix)

Protocolo de ponto a ponto multilink (MLPPP) e retransmissão de quadros multilink (MLFR)

7.0

Comutação de proteção automática (APS) — A interface ativa atual (seja o trabalho designado ou a interface de proteção designada) permanece a interface ativa durante a transição do mecanismo de roteamento.

7.4

LSPs MPLS MPLS de comutação de rótulos multiprotocol de ponto a multiponto (apenas trânsito)

7.4

Protocolo de transporte em tempo real comprimido (CRTP)

7.6

Serviço de LAN privada virtual (VPLS)

8.2

Operação, administração e gerenciamento de ethernet (OAM), conforme definido pelo IEEE 802.3ah

8.5

Agente de retransmissão DHCP estendido

8.5

OAM de ethernet conforme definido pelo IEEE 802.1ag

9.0

Processo de protocolo de controle de gateway de pacote (PGCP) em multisserviços 500 PICs em roteadores T640.

9.0

Acesso ao assinante

9.4

Configuração redundante pseudowire de VPLS baseada em VPLS e circuito de camada 2

9.6

As seguintes restrições se aplicam ao suporte gracioso do recurso de switchover do Mecanismo de Roteamento:

  • Quando a comutação graciosa do Mecanismo de Roteamento e as interfaces Ethernet agregadas são configuradas no mesmo sistema, as interfaces Ethernet agregadas não devem ser configuradas para lacp de votação rápida. Quando a votação rápida é configurada, as pesquisas de LACP saem na extremidade remota durante a mudança de função primária do Mecanismo de Roteamento. Quando o tempo de votação do LACP é desativado, o link e a interface agregados são desativados. A mudança de função primária do Mecanismo de Roteamento é rápida o suficiente para que a votação padrão e lenta do LACP não seja demorada durante o procedimento. No entanto, observe que essa restrição não se aplica aos roteadores da Série MX que estão executando o Junos OS Release 9.4 ou posteriores e que tenham o gerenciamento de pacotes periódicos distribuído (PPM) habilitado — que é a configuração padrão — neles. Nesses casos, você pode configurar o switchover gracioso do Mecanismo de Roteamento e ter interfaces Ethernet agregadas configuradas para uma votação rápida de LACP no mesmo dispositivo.

    Nota:

    As sessões de MACSec serão abasadas após o switchover gracioso do mecanismo de roteamento.

    A partir do Junos OS Release 13.2, quando ocorre uma troca graciosa do Mecanismo de Roteamento, o estado vrRP não muda. O VRRP é suportado pelo switchover gracioso do Mecanismo de Roteamento apenas no caso de a delegação de PPM ser habilitada (qual é o padrão).

Suporte gracioso ao switchover de mecanismo de roteamento DPC

A comutação graciosa do mecanismo de roteamento oferece suporte a todos os Concentradores de portas densas (DPCs) nas plataformas de roteamento universal 5G da Série MX que executam a versão apropriada do Junos OS, conforme mostrado no suporte gracioso da plataforma de switchover do mecanismo de roteamento. Para obter mais informações sobre DPCs, consulte o Guia de DPC da Série MX.

Switchover gracioso do mecanismo de roteamento e acesso ao assinante

Atualmente, o switchover gracioso do mecanismo de roteamento oferece suporte à maioria dos recursos diretamente associados ao DHCP dinâmico e ao acesso dinâmico ao assinante PPPoE. O switchover gracioso do Mecanismo de Roteamento também oferece suporte à atualização unificada de software em serviço (ISSU) para o modelo de acesso DHCP e ao modelo de acesso PPPoE usado pelo acesso ao assinante.

Nota:

Quando o switchover gracioso do mecanismo de roteamento é habilitado para o gerenciamento de assinantes, todos os mecanismos de roteamento no roteador devem ter a mesma quantidade de DRAM para operação estável.

Suporte gracioso ao switchover do mecanismo de roteamento PIC

O switchover gracioso do mecanismo de roteamento é suportado na maioria dos PICs, com exceção dos PICs de serviços listados nesta seção. O PIC deve estar em uma plataforma de roteamento suportada que executa a versão apropriada do Junos OS. Para obter informações sobre tipos de FPC, compatibilidade FPC/PIC e a versão inicial do Junos OS em que um FPC suportava um PIC específico, consulte o guia PIC para sua plataforma de roteador.

As seguintes restrições se aplicam ao suporte gracioso de switchover do Mecanismo de Roteamento para PICs de serviços:

  • Você pode incluir a graceful-switchover declaração no nível de [edit chassis redundancy] hierarquia em um roteador com serviços adaptativos, multisserviços e PICs de serviços de túnel configurados nele e comprometer com sucesso a configuração. No entanto, todos os serviços nesses PICs — exceto os pacotes de serviços de Camada 2 e aplicativos de provedores de extensão e SDK em PICs de multisserviços — são redefinidos durante uma transferência.

  • O switchover gracioso do mecanismo de roteamento não é suportado em nenhum PICs de serviços de monitoramento ou PICs de serviços multilink. Se você incluir a graceful-switchover declaração no nível de [edit chassis redundancy] hierarquia em um roteador com qualquer um desses tipos pic configurados nele e emitir o commit comando, o commit falha.

  • O switchover gracioso do mecanismo de roteamento não é suportado em 400 PICs multisserviços configurados para aplicativos de serviços de monitoramento. Se você incluir a graceful-switchover declaração, o compromisso falha.

Nota:

Quando um PIC sem suporte está on-line, você não pode habilitar o switchover gracioso do Mecanismo de Roteamento. Se o switchover gracioso do Mecanismo de Roteamento já estiver habilitado, um PIC sem suporte não pode ficar on-line.

Tabela de histórico de mudanças

O suporte de recursos é determinado pela plataforma e versão que você está usando. Use o Feature Explorer para determinar se um recurso é suportado em sua plataforma.

Lançamento
Descrição
14.2
A partir do Junos OS Release 14.2, quando você executa GRES em dispositivos da Série MX, você deve executar o comando de clear synchronous-ethernet wait-to-restore modo operacional no novo mecanismo de roteamento primário para limpar o temporização de espera para restaurar nele.
13.2
A partir do Junos OS Release 13.2, quando ocorre uma troca graciosa do Mecanismo de Roteamento, o estado vrRP não muda.
12.2
A partir do Junos OS Release 12.2, se adjacências entre o dispositivo de reiniciamento e os dispositivos "helper" de peer vizinhos forem liberadas, as extensões de protocolo de reinicialização graciosas não poderão notificar os dispositivos de "helper" dos pares sobre a reinicialização iminente.
12.2
Começando com o Junos OS Release 12.2, se adjacências entre o dispositivo de reiniciamento e os dispositivos "helper" de peer vizinhos acabarem, a reinicialização graciosa pode parar e causar interrupções no tráfego.