Entender a comutação graciosa do mecanismo de roteamento
Este tópico contém as seguintes seções:
Conceitos graciosos de comutação 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 roteador 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. O tráfego não é interrompido. No entanto, o GRES não preserva o plano de controle.
Nas plataformas PTX10004, PTX10008 e PTX10016 que executam o Junos OS Evolved, o GRES é habilitado por padrão e não pode ser desativado.
Nos roteadores da Série T, roteadores TX Matrix e roteadores TX Matrix Plus, o plano de controle é preservado em 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 roteadores vizinhos detectam que o roteador experimentou uma reinicialização e reagem ao evento de maneira prescrita pelas especificações individuais do protocolo de roteamento.
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 principal são replicadas no mecanismo de roteamento de backup assim que ocorrem.
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 principal experimenta uma falha de hardware.
O administrador inicia um switchover manual.
Para restaurar ou preservar rapidamente as informações de estado do protocolo de roteamento durante uma troca, o GRES deve ser combinado com o reinicialização gracioso ou o roteamento ativo sem parar, respectivamente. Para obter mais informações sobre o recomeço gracioso, consulte o Gracioso Restart Concepts. Para obter mais informações sobre o roteamento ativo sem parar, consulte 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 nos roteadores M20), 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 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 passam a ser sincronizados. Se o novo mecanismo de roteamento primário detectar que o estado do Mecanismo de Encaminhamento de Pacotes não está atualizado, ele reencaminha as mensagens de atualização do estado.
A partir do Junos OS Release 12.2, se houver adjacências entre o roteador de reinicialização e os roteadores "helper" vizinhos, as extensões de protocolo de reinicialização graciosas não poderão notificar os roteadores "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 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 depois que ambos os mecanismos de roteamento surgirem.
Se o roteador ou switch exibir uma mensagem de aviso semelhante a Standby Routing Engine is not ready for graceful switchover. Packet Forwarding Engines that are not ready for graceful switchover might be reset , não tente a troca. Se você optar por prosseguir com a troca, apenas os mecanismos de encaminhamento de pacotes que não estavam prontos para a troca graciosa são reiniciados. Nenhum dos FPCs deve ser reiniciado espontaneamente. Recomendamos que você aguarde até que o aviso não apareçam mais e, em seguida, prossiga com o switchover.
A partir do Junos OS Release 14.2, quando você executa GRES em roteadores da Série MX, você deve executar o comando do clear synchronous-ethernet wait-to-restore modo operacional no novo mecanismo de roteamento primário para liberar o temporizador de espera para restaurar. Isso ocorre porque o comando do clear synchronous-ethernet wait-to-restore modo operacional libera o temporizador de espera para restaurar apenas no mecanismo de roteamento local.
Em uma matriz de roteamento com roteador TX Matrix Plus com SIBs 3D, para a sucessiva troca de mecanismos 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.
O GRES deve ser realizado em 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 realizar uma operação de compromisso no mecanismo de roteamento de backup quando o GRES estiver habilitado no roteador ou switch.
Não recomendamos habilitar o GRES no mecanismo de roteamento de backup em qualquer cenário.
Nos switches QFX10000, recomendamos fortemente que você configure a nsr-phantom-holdtime seconds declaração no nível da hierarquia quando o [edit routing-options] roteamento sem parar for habilitado com GRES. Isso ajuda a evitar perdas de tráfego. Quando você configura esta declaração, os endereços IP fantasmas permanecem no kernel durante uma troca até que o intervalo de tempo de espera especificado expira. Após a expiração do intervalo, essas rotas são adicionadas à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).
A Figura 1 mostra a arquitetura de sistema do gracioso switchover do Mecanismo de Roteamento e o processo que uma plataforma de roteamento segue para se preparar para uma troca.
Verifique a prontidão do GRES executando ambos:
O
request chassis routing-engine master switch checkcomando do mecanismo de roteamento principalO
show system switchovercomando do mecanismo de roteamento de backup
O processo de preparação de switches para GRES é o seguinte:
O mecanismo de roteamento primário começa.
Os processos da plataforma de roteamento (como o processo do chassi [chassi]) começam.
O mecanismo de encaminhamento de pacotes começa e se conecta ao mecanismo de roteamento principal.
Todas as informações de estado são atualizadas no sistema.
O mecanismo de roteamento de backup começa.
O sistema determina se o GRES foi habilitado.
O processo de sincronização do kernel (ksyncd) sincroniza o mecanismo de roteamento de backup com o mecanismo de roteamento principal.
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).
Um processo de comutação inclui as seguintes etapas:
Quando as atualizações do mecanismo de roteamento principal são perdidas, o sistema muda graciosamente para o mecanismo de roteamento de backup.
O mecanismo de encaminhamento de pacotes se conecta ao mecanismo de roteamento de backup, que se torna o novo principal.
Processos de plataforma de roteamento que não fazem parte do GRES (como o rpd do processo de protocolo de roteamento) são reiniciados.
As informações de estado aprendidas com o ponto de transferência são atualizadas no sistema.
Se configuradas, as extensões de protocolo de reinicialização graciosas coletam e restauram informações de roteamento de roteadores de helper vizinhos.
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 realizado. 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 troca.
Durante o GRES na Série T e M320 roteadores 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 Mezzanine 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.
Quando o GRES é 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 ocorre porque o processo de chassi é reiniciado com a execução do restart chassis-control comando. O processo de chassi é responsável pela manutenção e retenção da função primária e, quando reiniciado, o novo chassi é processado com base na carga do roteador ou do switch. Como resultado, qualquer um dos mecanismos de roteamento é feito o principal.
Efeitos de uma troca de mecanismo de roteamento
A Tabela 1 descreve os efeitos de um switchover do Mecanismo de Roteamento quando diferentes recursos são ativados:
Sem recursos de alta disponibilidade
Switchover gracioso do mecanismo de roteamento
Recomeço gracioso
Roteamento ativo sem parar
Recurso |
Benefícios |
Considerações |
|---|---|---|
Somente mecanismos de roteamento duplo (sem recursos habilitados) |
|
|
Habilitado para GRES |
|
|
HABILITAdo para GRES e NSR |
|
|
GRES e reinicialização graciosa habilitada |
|
|
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 estado das interfaces de serviços agregados (ASIs) não será preservado. Por exemplo:
request interface <switchover | revert> asi-interface
No entanto, se o GRES for acionado por um compromisso de CLI ou reinicialização ou falha do FPC, o mecanismo de roteamento de backup atualiza o estado ASI. Por exemplo:
set interface si-x/y/z disable commit
Ou:
request chassis fpc restart
clear synchronous-ethernet wait-to-restore modo operacional no novo mecanismo de roteamento primário para liberar o temporizador de espera para restaurar.