Entendendo a comutação de roteamento graciosa

Conceitos de comutação do Mecanismo de Roteamento Gracioso

O recurso de comutação de 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 se um Mecanismo de Roteamento falhar. 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.

Os dispositivos vizinhos detectam que o dispositivo foi reiniciado e reagem ao evento da maneira prescrita pelas especificações individuais do protocolo de roteamento.

Para preservar o roteamento durante um switchover, o GRES deve ser combinado com:

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

• Roteamento ativo sem interrupções (NSR)

Quaisquer atualizações no Mecanismo de Roteamento principal são replicadas para o Mecanismo de Roteamento de backup assim que ocorrem.

Observação:

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

A função primária muda para o Mecanismo de Roteamento de backup se:

• O kernel primário do Mecanismo de Roteamento para de operar.

• O Mecanismo de Roteamento primário apresenta uma falha de hardware.

• O administrador inicia uma comutação manual.

Observação:

Para restaurar rapidamente ou preservar as informações de estado do protocolo de roteamento durante um switchover, o GRES deve ser combinado com uma reinicialização graciosa ou um roteamento ativo sem parar, respectivamente. Para obter mais informações sobre a reinicialização graciosa, consulte Conceitos de reinicialização graciosa. Para obter mais informações sobre o roteamento ativo sem interrupções, consulte Conceitos de roteamento ativo sem interrupções.

Se o Mecanismo de Roteamento de backup não receber um keepalive do Mecanismo de Roteamento principal após 2 segundos, ele determinará que o Mecanismo de Roteamento principal falhou; e assume o papel principal.

O Mecanismo de Encaminhamento de Pacotes:

• Desconecta-se perfeitamente do antigo Mecanismo de Roteamento primário

• Reconecta-se ao novo Mecanismo de Roteamento primário

• Não reinicia

• Não interrompe o tráfego

O novo Mecanismo de Roteamento principal 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 reenviará as mensagens de atualização de estado.

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

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

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

• Os eventos sucessivos de switchover do Mecanismo de Roteamento devem ter no mínimo 240 segundos (4 minutos) de intervalo após a ativação de ambos os mecanismos de roteamento.

  Se o dispositivo exibir uma mensagem de aviso semelhante a:

  então não tente uma transição. Se você optar por prosseguir com a alternância, o dispositivo redefinirá apenas os mecanismos de encaminhamento de pacotes que não estavam prontos para a comutação graciosa. Nenhum dos FPCs deve reiniciar espontaneamente. Recomendamos que você aguarde até que o aviso não apareça mais e, em seguida, prossiga com a alternância.

• Não recomendamos:

  • Fazer uma operação de confirmação no Mecanismo de Roteamento de backup quando o GRES está habilitado no dispositivo.

  • Habilitando o GRES no Mecanismo de Roteamento de backup em qualquer cenário.

A Figura 1 mostra a arquitetura do sistema de comutação graciosa do Mecanismo de Roteamento e o processo que uma plataforma de roteamento segue para se preparar para uma comutação.

Observação:

Verifique a prontidão do GRES executando ambos:

• O request chassis routing-engine master switch check comando do Mecanismo de Roteamento principal

• O show system switchover comando do Mecanismo de Roteamento de Backup

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

1. O Mecanismo de Roteamento primário é iniciado.

2. Os processos da plataforma de roteamento (como o processo de chassi [chassi]) são iniciados.

3. O Mecanismo de Encaminhamento de Pacotes é iniciado e se conecta ao Mecanismo de Roteamento principal.

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

5. O Mecanismo de Roteamento de backup é iniciado.

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 principal.

8. Depois que o ksyncd conclui a sincronização, todas as informações de estado e a tabela de encaminhamento são atualizadas.

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

Um processo de transição compreende as seguintes etapas:

1. Quando os keepalives do Mecanismo de Roteamento principal são perdidos, o sistema muda normalmente 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. Os processos da plataforma de roteamento que não fazem parte do GRES (como o rpd do processo de protocolo de roteamento) são reiniciados.

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

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

Use o Explorador de Recursos para confirmar o suporte à plataforma e à versão para recursos específicos.

Revise a seção Comportamento GRES específico da plataforma para obter notas relacionadas à sua plataforma.

Efeitos de um switchover de Mecanismo de Roteamento

A Tabela 1 descreve os efeitos de uma comutação de Mecanismo de Roteamento quando diferentes recursos são habilitados:

• Sem recursos de alta disponibilidade

• Comutação graciosa do Mecanismo de Roteamento

• Reinicialização graciosa

• Roteamento ativo sem interrupções

Tabela 1: Efeitos de uma comutação de Mecanismo de Roteamento

Característica	Benefícios	Considerações
Somente mecanismos de roteamento duplos (sem recursos habilitados)	Quando a comutação para o novo Mecanismo de Roteamento primário é concluída, a convergência de roteamento ocorre e o tráfego é retomado.	Todas as interfaces físicas são colocadas offline. Os mecanismos de encaminhamento de pacotes são reiniciados. O Mecanismo de Roteamento de backup reinicia o processo de protocolo de roteamento (rpd). Todo o hardware e interfaces são descobertos pelo novo Mecanismo de Roteamento primário. A comutação leva vários minutos. Todas as adjacências do dispositivo estão cientes das alterações físicas (alarmes de interface) e roteamento (topologia).
GRES habilitado	Durante a alternância, as informações da interface e do kernel são preservadas. A comutação é 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). Todo o hardware e interfaces são adquiridos por um processo semelhante a uma reinicialização a quente. Todas as adjacências estão cientes da alteração 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 sã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 habilitados	O tráfego não é interrompido durante a transição. As informações de interface e kernel são preservadas. Extensões de protocolo de reinicialização graciosas coletam e restauram rapidamente informações de roteamento dos dispositivos vizinhos.	Os vizinhos são necessários para dar suporte à reinicialização graciosa e um intervalo de espera é necessário. O processo de protocolo de roteamento (rpd) é reiniciado. Para determinados protocolos, uma alteração significativa na rede pode fazer com que a reinicialização normal seja interrompida. A partir do Junos OS Release 12.2, se as adjacências entre o dispositivo de reinicialização e os dispositivos "helper" peer vizinhos expirarem, a reinicialização graciosa pode parar e causar interrupções no tráfego.

Comutação de Mecanismo de Roteamento Gracioso 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 agregados (ASIs). Por exemplo:

No entanto, se o GRES for acionado por uma confirmação de CLI ou reinicialização ou travamento do FPC, o Mecanismo de Roteamento de backup atualizará o estado do ASI. Por exemplo:

Ou:

Suporte gracioso à plataforma de comutação do Mecanismo de Roteamento

Para habilitar a comutação graciosa do Mecanismo de Roteamento, seu sistema deve atender a estes requisitos mínimos:

• Roteador MX960 — Junos OS versão 8.3 ou posterior

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

• Roteador MX240 — Junos OS versão 9.0 ou posterior

• Roteador PTX5000 — Junos OS versão 12.1X48 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 Virtual Chassis Fabric — Junos OS versão 13.2X51-D20 ou posterior para os switches da Série EX e Série QFX

Para obter mais informações sobre o suporte para comutação graciosa do Mecanismo de Roteamento, consulte as seções a seguir.

Suporte a recursos de comutação de Mecanismo de Roteamento gracioso

O switchover gracioso do Mecanismo de Roteamento oferece suporte à maioria dos recursos do Junos OS na versão 5.7 e posterior. Recursos específicos do Junos OS exigem versões específicas do Junos OS. Consulte a Tabela 2.

Tabela 2: Suporte ao recurso de comutação do Mecanismo de Roteamento gracioso

Aplicação	Versão do Junos OS
Interfaces Ethernet agregadas com Link Aggregation Control Protocol (LACP) e interfaces SONET agregadas	6.2
Circuitos virtuais (VCs) do modo de transferência assíncrona (ATM)	6.2
Sistemas lógicos Observação: No Junos OS versão 9.3 e posterior, o recurso de roteador lógico é renomeado para sistema lógico.	6.3
Multicast	6.4 (7.0 para roteador TX Matrix)
Protocolo multilink ponto a ponto (MLPPP) e Multilink Frame Relay (MLFR)	7.0
Comutação automática de proteção (APS) — A interface ativa atual (a interface de trabalho designada ou a interface de proteção designada) permanece a interface ativa durante uma comutação do Mecanismo de Roteamento.	7.4
Ponto a multiponto Multiprotocol Label Switching LSPs MPLS (somente trânsito)	7.4
Protocolo de transporte em tempo real (CRTP) compactado	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 transmissão DHCP estendido	8.5
Ethernet OAM, conforme definido pela IEEE 802.1ag	9.0
Processo de protocolo PGCP (PGCPD) em multisserviços 500 PICs em roteadores T640.	9.0
Acesso do assinante	9.4
Configuração redundante pseudowire VPLS baseada em circuito de camada 2 e LDP	9.6

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

• Quando o switchover gracioso do Mecanismo de Roteamento e as interfaces Ethernet agregadas são configurados no mesmo sistema, as interfaces Ethernet agregadas não devem ser configuradas para LACP de polling rápido. Quando a sondagem rápida é configurada, as pesquisas LACP atingem o tempo limite na extremidade remota durante a comutação de função primária do Mecanismo de Roteamento. Quando a pesquisa LACP atinge o tempo limite, o link agregado e a interface são desativados. A mudança de função primária do Mecanismo de Roteamento é rápida o suficiente para que a pesquisa LACP padrão e lenta não atinja o tempo limite durante o procedimento.

  Observação:

  As sessões de MACSec serão osciladas após a comutação do Mecanismo de Mecanismo de Roteamento Gracioso.

  A partir do Junos OS Release 13.2, quando ocorre uma comutação graciosa do Mecanismo de Roteamento, o estado do VRRP não muda. O VRRP é suportado pelo switchover gracioso do Mecanismo de Roteamento somente no caso em que a delegação de PPM está habilitada (que é o padrão).

Comutação graciosa do Mecanismo de Roteamento e acesso ao assinante

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

Observação:

Quando a comutação graciosa do Mecanismo de Roteamento é habilitada para gerenciamento de assinantes, todos os mecanismos de roteamento no roteador devem ter a mesma quantidade de DRAM para uma operação estável.

Suporte a PIC de comutação de Mecanismo de Roteamento gracioso

A comutação do Mecanismo de Roteamento gracioso é suportada na maioria dos PICs, exceto para os PICs de serviços listados nesta seção. O PIC deve estar em uma plataforma de roteamento suportada executando a versão apropriada do Junos OS. Para obter informações sobre os tipos de FPC, compatibilidade FPC/PIC e a versão inicial do Junos OS na qual um FPC suportou um PIC específico, consulte o guia PIC para sua plataforma de roteador.

As seguintes restrições se aplicam ao suporte de switchover do Mecanismo de Roteamento gracioso 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 PICs de serviços adaptativos, multisserviços e serviços de túnel configurados nele e confirmar a configuração com êxito. No entanto, todos os serviços nesses PICs — exceto os pacotes de serviços de Camada 2 e o provedor de extensão e aplicativos SDK em PICs multisserviços — são redefinidos durante uma alternância.

• O switchover do Mecanismo de Roteamento gracioso 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 [edit chassis redundancy] nível de hierarquia em um roteador com qualquer um desses tipos de PIC configurados e emitir o commit comando, a confirmação falhará.

• O switchover do Mecanismo de Mecanismo de Roteamento gracioso não é suportado em PICs Multiservices 400 configurados para aplicativos de serviços de monitoramento. Se você incluir a graceful-switchover instrução, a confirmação falhará.

Observação:

Quando um PIC não suportado está on-line, você não pode habilitar a comutação graciosa do Mecanismo de Roteamento. Se a comutação graciosa do Mecanismo de Roteamento já estiver habilitada, um PIC não suportado não poderá ficar online.

Use o Explorador de Recursos para confirmar o suporte à plataforma e à versão para recursos específicos.

Use a tabela a seguir para analisar os comportamentos específicos da plataforma:

Plataforma	Diferença
Série MX	Ao executar o GRES em roteadores da Série MX, você deve executar o clear synchronous-ethernet wait-to-restore comando de modo operacional no novo Mecanismo de Roteamento principal para limpar o temporizador de espera para restauração nele. Isso ocorre porque o clear synchronous-ethernet wait-to-restore comando de modo operacional limpa o temporizador de espera para restaurar apenas no Mecanismo de Roteamento local. Para roteadores da Série MX que usam gerenciamento aprimorado de assinantes, o novo Mecanismo de Roteamento de backup (o antigo Mecanismo de Roteamento principal) será reinicializado 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 principal, evitando discrepâncias de estado que possam ter ocorrido durante a comutação. Os roteadores da Série MX que têm o gerenciamento de pacotes periódicos distribuídos (PPM) habilitados podem configurar uma comutação graciosa do Mecanismo de Roteamento e ter interfaces Ethernet agregadas configuradas para LACP de sondagem rápida no mesmo dispositivo. O switchover do Mecanismo de Roteamento gracioso oferece suporte a todos os Dense Port Concentrators (DPCs) nas Plataformas de roteamento universal 5G da Série MX que executam a versão apropriada do Junos OS, conforme mostrado no Comportamento GRES específico da plataforma.
Série PTX	Em dispositivos PTX10004, PTX10008 e PTX10016 que executam o Junos OS Evolved, o GRES é habilitado por padrão e não pode ser desativado.
Série QFX	Quando você habilita o roteamento sem paradas com GRES em switches na linha QFX10000 que têm mecanismos de roteamento redundantes, é altamente recomendável que você configure a nsr-phantom-holdtime seconds [edit routing-options] declaração no nível de hierarquia. 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 comutação até que o intervalo de tempo de espera especificado expire. 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 aos switches QFX10002, que não têm mecanismos de roteamento redundantes e não oferecem suporte a GRES.
Série ACX	Para roteadores da Série ACX, quando ocorre comutação de alta disponibilidade (HA) com MACsec habilitado, espera-se uma breve interrupção de tráfego na interface. Durante a transição, as sessões ativas são interrompidas e restabelecidas. Como resultado, a interface apresenta um comportamento semelhante a um evento MACsec para baixo/para cima após a alternância.