Entender a redundância do mecanismo de roteamento

Visão geral da redundância do mecanismo de roteamento

Os mecanismos de roteamento redundantes são dois mecanismos de roteamento instalados na mesma plataforma de roteamento. Um funciona como o principal, enquanto o outro permanece como um backup caso o mecanismo de roteamento primário falhe. Em plataformas de roteamento com mecanismos de roteamento duplos, a reconvergência da rede ocorre mais rapidamente do que em plataformas de roteamento com um único mecanismo de roteamento.

Quando um mecanismo de roteamento é configurado como primário, ele tem funcionalidade completa. Ele recebe e transmite informações de roteamento, constrói e mantém tabelas de roteamento, se comunica com interfaces e componentes do Mecanismo de Encaminhamento de Pacotes, e tem controle total sobre o chassi. Quando um mecanismo de roteamento está configurado para ser o backup, ele não se comunica com o Mecanismo de Encaminhamento de Pacotes ou componentes do chassi.

Nota:

Em dispositivos que executam o Junos OS Release 8.4 ou posteriores, ambos os mecanismos de roteamento não podem ser configurados como primários ao mesmo tempo. Essa configuração faz com que a verificação de compromisso falhe.

Um failover do mecanismo de roteamento primário para o mecanismo de roteamento de backup ocorre automaticamente quando o mecanismo de roteamento primário experimenta uma falha de hardware ou quando você configura o software para dar suporte a uma mudança na função primária com base em condições específicas. Você também pode alternar manualmente a request chassis routing-engine função primária do Mecanismo de Roteamento emitindo um dos comandos. Neste tópico, o termo failover refere-se a um evento automático, enquanto o switchover refere-se a um evento automático ou manual.

Quando ocorre um failover ou um switchover, o mecanismo de roteamento de backup assume o controle do sistema como o novo mecanismo de roteamento primário.

• Se o switchover gracioso do Mecanismo de Roteamento não estiver configurado, quando o mecanismo de roteamento de backup se tornar primário, ele reinicia o plano do switch e baixa sua própria versão do microkernel para os componentes do Mecanismo de Encaminhamento de Pacotes. O tráfego é interrompido enquanto o mecanismo de encaminhamento de pacotes é reinitializado. Todos os processos de kernel e encaminhamento são reiniciados.

• Se o switchover gracioso do mecanismo de roteamento estiver configurado, as informações de interface e kernel serão preservadas. A troca é 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.

• Se o switchover gracioso do mecanismo de roteamento e o roteamento ativo ininterrupto (NSR) forem configurados, o tráfego não será interrompido durante a transição. As informações de protocolo de interface, kernel e roteamento são preservadas.

• Se o switchover gracioso do mecanismo de roteamento e a reinicialização graciosa forem configurados, o tráfego não será 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 roteadores vizinhos.

Condições que desencadeiam falha no mecanismo de roteamento

Os eventos a seguir podem resultar em uma mudança automática na função primária do Mecanismo de Roteamento, dependendo da sua configuração:

• A plataforma de roteamento experimenta uma falha de hardware. Uma mudança na função primária do Mecanismo de Roteamento ocorre se o mecanismo de roteamento ou o módulo de host associado ou o subsistema forem desligados abruptamente. Você também pode configurar o mecanismo de roteamento de backup para assumir o papel principal se detectar um erro de disco rígido no mecanismo de roteamento primário. Para habilitar esse recurso, inclua a failover on-disk-failure declaração no nível de [edit chassis redundancy] hierarquia.

• A plataforma de roteamento experimenta uma falha de software, como uma falha no kernel ou um bloqueio de CPU. Você deve configurar o mecanismo de roteamento de backup para assumir o papel principal quando detecta uma perda de sinal keepalive. Para habilitar esse método de failover, inclua a failover on-loss-of-keepalives declaração no nível de [edit chassis redundancy] hierarquia.

• A plataforma de roteamento experimenta uma falha de interface em0 no mecanismo de roteamento principal. Você deve configurar o mecanismo de roteamento de backup para assumir o papel principal quando detectar a falha da interface em0. Para habilitar esse método de failover, inclua a on-re-to-fpc-stale declaração no nível de [edit chassis redundancy failover] hierarquia.

• Um processo de software específico falha. Você pode configurar o mecanismo de roteamento de backup para assumir o papel principal quando um ou mais processos especificados falharem pelo menos quatro vezes em 30 segundos. Inclua a failover other-routing-engine declaração no nível da [edit system processes process-name] hierarquia.

Se alguma dessas condições for atendida, uma mensagem será registrada e o mecanismo de roteamento de backup tentar assumir o papel principal. Por padrão, um alarme é gerado quando o mecanismo de roteamento de backup fica ativo. Após o mecanismo de roteamento de backup assumir o papel principal, ele continua a funcionar como primário mesmo após o mecanismo de roteamento primário originalmente configurado ter retomado a operação com sucesso. Você deve restaurá-lo manualmente ao status de backup anterior. (No entanto, se a qualquer momento um dos mecanismos de roteamento não estiver presente, o outro mecanismo de roteamento torna-se primário automaticamente, independentemente de como a redundância é configurada.)

Comportamento de redundância do mecanismo de roteamento padrão

Por padrão, o Junos OS usa o re0 como o mecanismo de roteamento principal e re1 como o mecanismo de roteamento de backup. A menos que seja especificado de outra forma na configuração, o re0 sempre se torna primário quando o mecanismo de roteamento primário em ação é reiniciado.

Nota:

Um único mecanismo de roteamento no chassi sempre se torna o mecanismo de roteamento principal, mesmo que anteriormente fosse o mecanismo de roteamento de backup.

Execute as etapas a seguir para ver como funciona a configuração padrão de redundância do mecanismo de roteamento:

1. Garanta que o re0 seja o mecanismo de roteamento principal.

2. Alterne manualmente o estado da função primária do mecanismo de roteamento, emitindo o request chassis routing-engine master switch comando do mecanismo de roteamento primário. re0 agora é o mecanismo de roteamento de backup e o re1 é o mecanismo de roteamento principal.

   Nota:

   Na próxima reinicialização do mecanismo de roteamento principal, o Junos OS devolve o roteador ao estado padrão porque você não configurou os mecanismos de roteamento para manter esse estado após uma reinicialização.

3. Reinicialize o mecanismo de roteamento primário re1.

   O mecanismo de roteamento ativa e lê a configuração. Como você não especificou na configuração qual mecanismo de roteamento é o principal, o re1 usa a configuração padrão como backup. Agora , tanto re0 quanto re1 estão em um estado de backup. O Junos OS detecta esse conflito e, para evitar um estado não primário, volta para a configuração padrão para re0 direta para se tornar primária.

Redundância de mecanismos de roteamento em um roteador TX Matrix

Em uma matriz de roteamento, todos os mecanismos de roteamento primários no roteador TX Matrix e roteadores T640 conectados devem executar a mesma versão do Junos OS. Da mesma forma, todos os mecanismos de roteamento de backup em uma matriz de roteamento devem executar a mesma versão do Junos OS. Quando você executa a mesma versão do Junos OS em todos os mecanismos de roteamento primários e de backup em uma matriz de roteamento, uma mudança na função primária para qualquer mecanismo de roteamento de backup na matriz de roteamento não causa uma mudança na função primária em nenhum outro chassi na matriz de roteamento.

CUIDADO:

(Matriz de roteamento baseada apenas nos roteadores TX Matrix ou TX Matrix Plus) Dentro da matriz de roteamento, recomendamos que todos os mecanismos de roteamento executem a mesma versão do Junos OS. Se você executar diferentes versões nos Mecanismos de Roteamento e uma mudança na função primária ocorrer em qualquer mecanismo de roteamento de backup na matriz de roteamento baseado no roteador TX Matrix ou no roteador TX Matrix Plus, um ou todos os roteadores podem ficar logicamente desconectados do roteador TX Matrix ou do roteador TX Matrix Plus e causar perda de dados.

Se a mesma versão do Junos OS não estiver em execução em todos os mecanismos de roteamento primários e de backup na matriz de roteamento, as seguintes consequências ocorrem quando a failover on-loss-of-keepalives declaração is incluída no nível de [edit chassis redundancy] hierarquia:

• Quando a failover on-loss-of-keepalives declaração é incluída no nível de [edit chassis redundancy] hierarquia e você ou um subsistema host iniciam uma mudança na função primária para o mecanismo de roteamento de backup no roteador TX Matrix, os mecanismos de roteamento primários nos roteadores T640 detectam uma incompatibilidade de versão de software com o novo mecanismo de roteamento primário no roteador TX Matrix e o papel principal do switch para seus mecanismos de roteamento de backup.

• Quando você muda manualmente a função primária para um mecanismo de roteamento de backup em um roteador T640 usando o request chassis routing-engine master comando, o novo mecanismo de roteamento primário no roteador T640 detecta uma incompatibilidade de versão de software com o mecanismo de roteamento primário no roteador TX Matrix e abre mão do papel principal para o mecanismo de roteamento principal original. (O papel principal do mecanismo de roteamento no roteador TX Matrix não muda neste caso.)

• Quando um subsistema host inicia uma mudança na função primária para um mecanismo de roteamento de backup em um roteador T640 porque o mecanismo de roteamento principal falhou, o roteador T640 é logicamente desconectado do roteador TX Matrix. Para reconectar o roteador T640, inicie uma mudança na função primária para o mecanismo de roteamento de backup no roteador TX Matrix ou substitua o mecanismo de roteamento com falha no roteador T640 e a função principal do switch para ele. O mecanismo de roteamento de substituição deve estar executando a mesma versão de software que o mecanismo de roteamento principal no roteador TX Matrix.

Se a mesma versão do Junos OS não estiver em execução em todos os mecanismos de roteamento primários e de backup na matriz de roteamento, as seguintes consequências ocorrem quando a failover on-loss-of-keepalives declaração is not incluída no nível de [edit chassis redundancy] hierarquia:

• Se você iniciar uma mudança na função primária para o mecanismo de roteamento de backup no roteador TX Matrix, todos os roteadores T640 estão logicamente desconectados do roteador TX Matrix. Para reconectar os roteadores T640, alterne o papel principal de todos os mecanismos de roteamento primários nos roteadores T640 para seus mecanismos de roteamento de backup.

• Se você iniciar uma mudança na função primária para um mecanismo de roteamento de backup em um roteador T640, o roteador T640 é logicamente desconectado do roteador TX Matrix. Para reconectar o roteador T640, alterne o papel principal do novo mecanismo de roteamento primário no roteador T640 de volta ao mecanismo de roteamento primário original.

Redundância do mecanismo de roteamento em um roteador TX Matrix Plus

Em uma matriz de roteamento, todos os mecanismos de roteamento primários do roteador TX Matrix Plus e os LCC conectados devem executar a mesma versão do Junos OS. Da mesma forma, todos os mecanismos de roteamento de backup em uma matriz de roteamento devem executar a mesma versão do Junos OS. Quando você executa a mesma versão do Junos OS em todos os mecanismos de roteamento primários e de backup na matriz de roteamento, uma mudança na função primária para qualquer mecanismo de roteamento de backup na matriz de roteamento não causa uma mudança na função primária em nenhum outro chassi na matriz de roteamento.

CUIDADO:

(Matriz de roteamento baseada apenas nos roteadores TX Matrix ou TX Matrix Plus) Dentro da matriz de roteamento, recomendamos que todos os mecanismos de roteamento executem a mesma versão do Junos OS. Se você executar diferentes versões nos mecanismos de roteamento e uma mudança na função primária ocorrer em qualquer mecanismo de roteamento de backup na matriz de roteamento baseado em um roteador TX Matrix ou um roteador TX Matrix Plus, um ou todos os roteadores podem ficar logicamente desconectados do roteador TX Matrix ou do roteador TX Matrix Plus e causar perda de dados.

Se a mesma versão do Junos OS não estiver em execução em todos os mecanismos de roteamento primários e de backup na matriz de roteamento, os seguintes cenários ocorrem quando a failover on-loss-of-keepalives declaração is incluída no nível de [edit chassis redundancy] hierarquia:

• Quando a failover on-loss-of-keepalives declaração é incluída no nível de [edit chassis redundancy] hierarquia e você ou um subsistema host iniciam uma mudança na função primária para o mecanismo de roteamento de backup no roteador TX Matrix Plus, os mecanismos de roteamento primários no LCC conectado detectam uma incompatibilidade de versão de software com o novo mecanismo de roteamento primário no roteador TX Matrix Plus e o papel principal do switch para seus mecanismos de roteamento de backup.

• Quando você muda manualmente a função primária para um mecanismo de roteamento de backup em uma LCC conectada usando o request chassis routing-engine master comando, o novo mecanismo de roteamento primário no LCC conectado detecta uma incompatibilidade de versão de software com o mecanismo de roteamento primário no roteador TX Matrix Plus e abre mão do papel principal para o mecanismo de roteamento primário original. (O papel principal do mecanismo de roteamento no roteador TX Matrix Plus não muda neste caso.)

• Quando um subsistema host inicia uma mudança na função primária para um mecanismo de roteamento de backup em uma LCC conectada porque o mecanismo de roteamento primário falhou, o LCC conectado é logicamente desconectado do roteador TX Matrix Plus. Para reconectar a LCC conectada, inicie uma mudança na função primária para o mecanismo de roteamento de backup no roteador TX Matrix Plus ou substitua o mecanismo de roteamento com falha no LCC conectado e a função principal do switch. O mecanismo de roteamento de substituição deve estar executando a mesma versão de software que o mecanismo de roteamento principal no roteador TX Matrix Plus.

Se a mesma versão do Junos OS não estiver em execução em todos os mecanismos de roteamento primários e de backup na matriz de roteamento, os seguintes cenários ocorrem quando a failover on-loss-of-keepalives declaração is not incluída no nível de [edit chassis redundancy] hierarquia:

• Se você iniciar uma mudança na função primária para o mecanismo de roteamento de backup no roteador TX Matrix Plus, todos os LCCs conectados estão logicamente desconectados do roteador TX Matrix Plus. Para reencontrar a LCC conectada, alterne o papel principal de todos os mecanismos de roteamento primários na LCC conectada aos mecanismos de roteamento de backup.

• Se você iniciar uma mudança na função primária para um mecanismo de roteamento de backup em uma LCC conectada, o LCC conectado é logicamente desconectado do roteador TX Matrix Plus. Para reconectar a LCC conectada, o papel principal do switch do novo mecanismo de roteamento primário na LCC conectada de volta ao mecanismo de roteamento primário original.

Situações que exigem que você interrompa os mecanismos de roteamento

Antes de desligar a energia para uma plataforma de roteamento que tem dois mecanismos de roteamento ou antes de remover o mecanismo de roteamento principal, primeiro você deve parar o mecanismo de roteamento de backup e, em seguida, parar o mecanismo de roteamento principal. Caso contrário, talvez você precise reinstalar o Junos OS. Você pode usar o request system halt both-routing-engines comando no mecanismo de roteamento principal, que primeiro desliga o mecanismo de roteamento principal e depois desliga o mecanismo de roteamento de backup. Para desligar apenas o mecanismo de roteamento de backup, emita o request system halt comando no mecanismo de roteamento de backup.

Se você parar o mecanismo de roteamento primário e não desligá-lo ou removê-lo, o mecanismo de roteamento de backup permanece inativo, a menos que você o configure para se tornar o principal quando detectar uma perda de sinal keepalive do mecanismo de roteamento principal.

Nota:

Para reiniciar o roteador, você deve fazer login na porta do console (em vez da porta de gerenciamento Ethernet) do mecanismo de roteamento. Quando você faz login na porta do console do mecanismo de roteamento principal, o sistema reinicializa automaticamente. Depois de fazer login na porta do console do mecanismo de roteamento de backup, pressione Enter para reiniciá-lo.

Nota:

Se você atualizou o mecanismo de roteamento de backup, primeiro reinicialize-o e reinicialize o mecanismo de roteamento principal.