Entendendo o recomeço gracioso
RESUMO A reinicialização graciosa permite o encaminhamento ininterrupto de pacotes e a supressão temporária de todas as atualizações de protocolo de roteamento durante o processo de reinicialização.
Conceitos de reinício graciosos
Com protocolos de roteamento, qualquer interrupção de serviço exige que um roteador afetado recalcula as adjacências com roteadores vizinhos, restaure as entradas da tabela de roteamento e atualize outras informações específicas do protocolo. Uma reinicialização desprotegida de um roteador pode resultar em atrasos no encaminhamento, flapping de rota, tempos de espera decorrentes da reconvergência do protocolo e até mesmo pacotes perdidos. Alguns benefícios da reinicialização graciosa são o encaminhamento ininterrupto de pacotes e a supressão temporária de todas as atualizações de protocolo de roteamento. A reinicialização graciosa permite que um roteador passe por estados de convergência intermediária que estão ocultos do resto da rede.
Três tipos principais de reinício gracioso estão disponíveis em plataformas de roteamento da Juniper Networks:
Reinicie graciosamente para rotas agregadas e estáticas e para protocolos de roteamento — oferece proteção para rotas agregadas e estáticas e para o Border Gateway Protocol (BGP), End System-to-Intermediate System (ES-IS), Intermediate System-to-Intermediate System (IS-IS), Open Shortest Path First (OSPF), Routing Information Protocol (RIP), RIP de próxima geração (RIPng) e protocolo independente de multicast (PIM) protocolos de roteamento esparsos.
Reiniciamento gracioso para protocolos relacionados ao MPLS — oferece proteção para protocolo de distribuição de rótulos (LDP), protocolo de reserva de recursos (RSVP), cross-connect de circuito (CCC) e cross-connect translacional (TCC). (Sem suporte para switches da Série OCX.)
Reiniciamento gracioso para redes virtuais privadas (VPNs)— oferece proteção para VPNs de Camada 2 e Camada 3.
A reinicialização graciosa funciona de maneira semelhante para protocolos de roteamento e protocolos MPLS e combina componentes desses tipos de protocolo para permitir a reinicialização graciosa em VPNs. Os principais benefícios da reinicialização graciosa são o encaminhamento ininterrupto de pacotes e a supressão temporária de todas as atualizações de protocolo de roteamento. A reinicialização graciosa permite que um roteador passe por estados de convergência intermediária que estão ocultos do resto da rede.
A maioria das implementações de reinicialização mais graciosas definem dois tipos de roteadores — o roteador de reinicialização e o roteador de helper. O roteador de reinicialização requer uma rápida restauração das informações de estado de encaminhamento para que ele possa retomar o encaminhamento do tráfego de rede. O roteador de helper ajuda o roteador de reinicialização nesse processo. As declarações de configuração de reinicialização graciosas normalmente afetam o roteador de reinicialização ou o roteador de helper.
Veja também
Reinício gracioso para rotas agregadas e estáticas
Quando você inclui a graceful-restart
declaração no nível de [edit routing-options]
hierarquia, quaisquer rotas estáticas ou rotas agregadas que tenham sido configuradas estão protegidas. Como nenhum roteador de helper auxilia na reinicialização, essas rotas são retidas na tabela de encaminhamento enquanto o roteador reinicia (em vez de ser descartado ou atualizado).
Veja também
Protocolos graciosos de reinício e roteamento
Esta seção abrange os seguintes tópicos:
BGP
Quando um roteador habilitado para o BGP reinicia graciosamente, ele retém rotas de peer BGP em sua tabela de encaminhamento e as marca como obsoletas. No entanto, ele continua a encaminhar tráfego para outros pares (ou pares receptores) durante a reinicialização. Para restabelecer as sessões, o roteador de reinicialização define o bit "estado de reinicialização" na mensagem BGP OPEN e envia para todos os pares participantes. Os pares receptores respondem ao roteador de reinicialização com mensagens que contêm marcadores de mesa de fim de roteamento. Quando o roteador ou switch de reinicialização recebe todas as respostas dos pares receptores, o roteador de reinicialização realiza a seleção de rotas, a tabela de encaminhamento é atualizada e as rotas previamente marcadas como obsoletas são descartadas. Neste ponto, todas as sessões BGP são restabelecidas e o peer de reinicialização pode receber e processar mensagens BGP como de costume.
Enquanto o roteador de reinicialização faz seu processamento, os pares receptores também retêm temporariamente as informações de roteamento. Quando um peer receptor detecta um reset de transporte de TCP, ele retém as rotas recebidas e marca as rotas como obsoletas. Após o restabelecimento da sessão com o roteador ou switch de reinicialização, as rotas obsoletas são substituídas por informações de rota atualizadas.
IS-IS
Normalmente, os roteadores IS-IS movem as adjacências vizinhas para o estado de baixa quando ocorrem mudanças. No entanto, um roteador habilitado para a reinicialização graciosa do IS-IS envia mensagens hello com o bit Restart Request (RR) definido em uma mensagem de valor de comprimento do tipo (TLV) de reinicialização. Isso indica aos roteadores vizinhos que uma reinicialização graciosa está em andamento e que a adjacência IS-IS está intacto. Os roteadores vizinhos devem interpretar e implementar a sinalização reiniciada. Além de manter a adjacência, os vizinhos enviam PDUs de número de sequência completo (CSNPs) para o roteador de reinicialização e inundam todo o banco de dados.
O roteador reiniciador nunca inunda nenhuma de suas próprias PDUs (LSPs), incluindo LSPs pseudonodos, para vizinhos is-IS enquanto passa por uma reinicialização graciosa. Isso permite que os vizinhos reestabeleçam suas adjacências sem fazer a transição para o estado baixo e permite que o roteador reinicie uma sincronização suave de banco de dados.
OSPF e OSPFv3
Quando um roteador habilitado para o OSPF reinicia graciosamente, ele retém rotas aprendidas antes da reinicialização em sua tabela de encaminhamento. O roteador não permite que novos anúncios de estado de link (LSAs) OSPF atualizem a tabela de roteamento. Este roteador continua a encaminhar tráfego para outros vizinhos OSPF (ou roteadores de helper), e envia apenas um número limitado de LSAs durante o período de reinicialização. Para restabelecer as adjacências de OSPF com vizinhos, o roteador reiniciador deve enviar uma LSA de graça a todos os vizinhos. Em resposta, os roteadores de helper entram no modo helper e enviam um reconhecimento de volta ao roteador de reinicialização. Se não houver alterações de topologia, os roteadores de helper continuarão a anunciar LSAs como se o roteador de reinicialização tivesse se mantido em operação OSPF contínua.
Quando o roteador de reinicialização recebe respostas de todos os roteadores de helper, o roteador reiniciador seleciona rotas, atualiza a tabela de encaminhamento e descarta as rotas antigas. Neste ponto, as adjacências completas de OSPF são restabelecidas e o roteador de reiniciamento recebe e processa LSAs OSPF, como de costume. Quando os roteadores de helper não recebem mais LSAs de graça do roteador de reiniciamento ou da topologia das mudanças na rede, os roteadores de helper também retomam a operação normal.
Para obter mais informações sobre a implementação padrão do modo helper, consulte RFC 3623, Graciosa OSPF Restart.
A partir da versão 11.3, o Junos OS oferece suporte ao modo de helper baseado em sinalização de reinicialização para configurações de reinicialização graciosas do OSPF. Os modos de ajuda, tanto padrão quanto baseados em sinalização de reinicialização, são habilitados por padrão. Na reinicialização das implementações do modo helper baseado em sinalização, o roteador de reinicialização transmite o status de reinicialização para os vizinhos somente após a reinicialização ser concluída. Quando a reinicialização estiver concluída, o roteador de reinicialização envia mensagens de olá aos roteadores de helper com o sinal de reinicialização (RS) definido no cabeçalho do pacote olá. Quando um roteador de helper recebe um pacote olá com o bit RS definido no cabeçalho, o roteador de helper retorna uma mensagem de olá para o roteador reiniciador. A mensagem de olá de resposta do roteador de helper contém a bandeira ResyncState e o temporização ResyncTimeout que permitem que o roteador de reinicialização mantenha o controle dos roteadores de helper que estão sincronizando com ele. Quando todos os helpers completam a sincronização, o roteador de reinicialização sai do modo de reinicialização.
Para obter mais informações sobre a implementação do modo helper de reinicialização graciosa baseada em sinalização, consulte RFC 4811, Ressincronização do banco de dados de estado de enlace fora da banda (LSDB), RFC 4812, sinalização de reinicialização de OSPF e RFC 4813, sinalização local de enlace OSPF.
O modo de helper de reinicialização gracioso baseado em sinalização não é suportado para configurações de OSPFv3.
Modo esparso de PIM
O modo esparso PIM usa um mecanismo chamado identificador de geração para indicar a necessidade de uma reinicialização graciosa. Os identificadores de geração são incluídos por padrão em mensagens de olá do PIM. Um identificador de geração inicial é criado por cada vizinho pim para estabelecer recursos de dispositivo. Quando um dos vizinhos do PIM reinicia, ele envia um identificador de nova geração para seus vizinhos. Todos os vizinhos que suportam a reinicialização graciosa e estão conectados por links ponto a ponto ajudam enviando atualizações multicast para o vizinho reiniciado.
A fase de reinicialização é concluída quando o estado do PIM fica estável ou quando o temporização do intervalo de reinicialização expira. Se os vizinhos não suportarem uma reinicialização graciosa ou se conectarem entre si usando interfaces multiponto, o roteador de reinicialização usa o temporização do intervalo de reinicialização para definir o período de reinicialização.
RIP e RIPng
Quando um roteador habilitado para a reinicialização graciosa do RIP é reiniciado, as rotas que foram configuradas ficam protegidas. Como nenhum roteador de helper auxilia na reinicialização, essas rotas são retidas na tabela de encaminhamento enquanto o roteador reinicia (em vez de ser descartado ou atualizado).
Veja também
Reiniciamento gracioso e protocolos relacionados ao MPLS
Esta seção contém os seguintes tópicos:
LDP
A reinicialização graciosa do LDP permite que um roteador cujo plano de controle LDP esteja passando por uma reinicialização continue a encaminhar o tráfego enquanto recupera seu estado dos roteadores vizinhos. Ele também permite um roteador no qual o modo de helper é habilitado para ajudar um roteador vizinho que está tentando reiniciar o LDP.
Durante a inicialização da sessão, um roteador anuncia sua capacidade de realizar a reinicialização graciosa do LDP ou de tirar proveito de um vizinho realizando o reinício gracioso do LDP enviando o gracioso TLV de reinicialização. Este TLV contém dois campos relevantes para a reinicialização graciosa do LDP: o tempo de reconexão e o tempo de recuperação. Os valores dos tempos de reconexão e recuperação indicam os recursos de reinicialização graciosos suportados pelo roteador.
O tempo de reconexão padrão é configurado no Junos OS como 60 segundos e é configurável pelo usuário. O tempo de reconexão é o tempo que o roteador de ajuda espera pelo roteador de reinicialização para estabelecer uma conexão. Se a conexão não estiver estabelecida dentro do intervalo de reconexão, a reinicialização graciosa da sessão de LDP será terminada. O tempo máximo de reconexão padrão é de 120 segundos e é configurável pelo usuário. O tempo máximo de reconexão é o valor máximo que um roteador de helper aceita de seu vizinho reiniciador.
Quando um roteador descobre que um roteador vizinho está reiniciando, ele espera até o fim do tempo de recuperação antes de tentar se reconectar. O tempo de recuperação é o tempo que um roteador espera que o LDP reinicie graciosamente. O período de recuperação começa quando uma mensagem de inicialização é enviada ou recebida. Esse período de tempo também é tipicamente o tempo que um roteador vizinho mantém suas informações sobre o roteador reiniciador, para que ele possa continuar a encaminhar o tráfego.
Você pode configurar o reinício gracioso do LDP tanto na instância principal para o protocolo LDP quanto para uma instância de roteamento específica. Você pode desabilitar a reinicialização graciosa no nível global para todos os protocolos, no nível de protocolo apenas para LDP e apenas para uma instância de roteamento específica.
RSVP
A reinicialização graciosa do RSVP permite que um roteador que passa por uma reinicialização informe seus vizinhos adjacentes sobre sua condição. O roteador de reinicialização solicita um período de carência do vizinho ou peer, que pode então colaborar com o roteador de reinicialização. O roteador de reinicialização ainda pode encaminhar o tráfego MPLS durante o período de reinicialização; a convergência na rede não é interrompida. A reinicialização não é visível para o resto da rede, e o roteador de reinicialização não é removido da topologia da rede. A reinicialização graciosa do RSVP pode ser habilitada em roteadores de trânsito e roteadores de entrada. Ele está disponível tanto para LSPs ponto a ponto quanto para LSPs de ponto a multiponto.
CCC e TCC
A reinicialização graciosa do CCC e do TCC permite que as conexões de Camada 2 entre roteadores de borda do cliente (CE) reiniciem graciosamente. Essas conexões de Camada 2 estão configuradas com o switch ou lsp-switch
declarações de interface remota. Como essas conexões de CCC e TCC têm uma dependência implícita dos LSPs RSVP, a reinicialização graciosa para CCC e TCC usa os recursos de reinicialização graciosa do RSVP.
A reinicialização graciosa do RSVP deve ser habilitada nos roteadores e roteadores de borda (PE) do provedor (P) para permitir a reinicialização graciosa do CCC e do TCC. Além disso, como o RSVP é usado como protocolo de sinalização para sinalizar informações de rótulos, o roteador vizinho deve usar o modo helper para ajudar com os procedimentos de reinicialização do RSVP.
Veja também
Entender o suporte ao modo helper baseado em sinalização reiniciado para o OSPF Graciosa Restart
A partir da versão 11.4, o Junos OS oferece suporte ao modo de helper baseado em sinalização reiniciado para configurações de reinício graciosas do OSPF.
O modo de helper de reinicialização gracioso baseado em sinalização não é suportado para configurações de OSPFv3.
As versões do Junos OS antes da versão 11.4 e das configurações OSPFv3 oferecem suporte apenas ao modo de helper padrão, conforme definido no RFC 3623. Para obter mais informações sobre a implementação padrão do modo helper, consulte o RFC 3623 e o Guia de configuração de alta disponibilidade do Junos OS.
Ambos os modos de helper padrão e reiniciado baseados em sinalização são habilitados por padrão, independentemente do status de configuração de reinicialização graciosa no dispositivo.
Em implementações de modo helper baseadas em sinalização reiniciadas, o roteador de reinicialização informa o status de reinicialização aos vizinhos somente após a reinicialização ser concluída. Quando a reinicialização estiver concluída, o roteador de reinicialização envia mensagens de olá aos roteadores de helper com o sinal de reinicialização (RS) definido no cabeçalho do pacote olá. Quando um roteador de helper recebe um pacote olá com o bit RS definido no cabeçalho, o roteador de helper retorna uma mensagem de olá para o roteador reiniciador. A mensagem de olá de resposta do roteador de helper contém a bandeira ResyncState e o temporização ResyncTimeout que permitem que o roteador de reinicialização mantenha o controle dos roteadores de helper que estão sincronizando com ele. Quando todos os helpers completam a sincronização, o roteador de reinicialização sai do modo de reinicialização.
Para obter mais informações sobre a implementação do modo helper de reinicialização graciosa baseada em sinalização, consulte RFC 4811, Ressincronização do banco de dados de estado de enlace fora da banda (LSDB), RFC 4812, sinalização de reinício do OSPFe RFC 4813, sinalização local do enlace OSPF.
Veja também
Reiniciamento gracioso e VPNs de Camada 2 e Camada 3
A reinicialização graciosa de VPN usa três tipos de funcionalidade de reinicialização:
A funcionalidade de reinicialização graciosa do BGP é usada em todas as sessões BGP de PE para PE. Isso afeta as sessões que transportam quaisquer dados de sinalização de serviço para informações de alcance da camada de rede (NLRI), por exemplo, uma VPN IPv4 ou VPN de Camada 2 NLRI.
A funcionalidade de reinicialização graciosa de OSPF, IS-IS, LDP ou RSVP é usada em todos os roteadores de núcleo. As rotas adicionadas por esses protocolos são usadas para resolver a NLRI VPN de Camada 2 e Camada 3.
A funcionalidade de reinicialização de protocolo é usada para qualquer protocolo de Camada 3 (RIP, OSPF, LDP e assim por diante) usado entre os roteadores pe e de borda do cliente (CE). Isso não se aplica às VPNs de Camada 2 porque os protocolos de Camada 2 usados entre os roteadores CE e PE não têm recursos graciosos de reinicialização.
Antes que a reinicialização graciosa da VPN possa funcionar corretamente, todos os componentes devem ser reiniciados graciosamente. Em outras palavras, os roteadores devem preservar seus estados de encaminhamento e solicitar aos vizinhos que continuem encaminhando ao roteador em caso de reinício. Se todas as condições estiverem satisfeitas, a reinicialização graciosa de VPN impõe as seguintes regras a um roteador reiniciador:
O roteador deve aguardar para receber todas as informações BGP NLRI de outros roteadores PE antes de anunciar rotas para os roteadores CE.
O roteador deve aguardar que todos os protocolos em todas as instâncias de roteamento convergam (ou preencha o processo de reinicialização) antes que ele envie informações do roteador CE para outros roteadores PE. Em outras palavras, o roteador deve aguardar que todas as informações de instância (sejam derivadas da configuração local ou dos anúncios recebidos de um peer remoto) sejam processadas antes de enviar essas informações para outros roteadores PE.
O roteador deve preservar todo o estado de encaminhamento nas tabelas instância.mpls.0 até que os novos rótulos e rotas de trânsito sejam alocados e anunciados para outros roteadores PE (e roteadores CE em um cenário de operadora de operadoras).
Se alguma condição não for atendida, a reinicialização graciosa da VPN não terá sucesso em fornecer encaminhamento ininterrupto entre roteadores CE em toda a infraestrutura vpn.
Veja também
Reinicialização graciosa em sistemas lógicos
A reinicialização graciosa para um sistema lógico funciona tanto quanto a reinicialização graciosa no roteador principal. A única diferença é a localização da graceful-restart
declaração:
Para um sistema lógico, inclua a
graceful-restart
declaração no nível de[edit logical-systems logical-system-name routing-options]
hierarquia.Para uma instância de roteamento dentro de um sistema lógico, inclua a
graceful-restart
declaração em ambos os[edit logical-systems logical-system-name routing-options]
níveis e[edit logical-systems logical-system-name routing-instances instance-name routing-options]
hierarquia.
Veja também
Requisitos graciosos do sistema de reinicialização
A reinicialização graciosa é suportada em todas as plataformas de roteamento. Para implementar uma reinicialização graciosa para determinados recursos, seu sistema deve atender a esses requisitos mínimos:
Junos OS Release 5.3 ou posterior para rota agregada, BGP, IS-IS, OSPF, RIP, RIPng ou reinicialização graciosa da rota estática.
Junos OS Release 5.5 ou posterior para RSVP em roteadores de borda de provedor de saída (PE).
Junos OS Release 5.5 ou posterior para reinício gracioso do LDP.
Junos OS Versão 5.6 ou posterior para as implementações de VPN de CCC, TCC, Camada 2 ou VPN de Camada 3 de reinício gracioso.
Junos OS Release 6.1 ou posterior para RSVP, reinicie graciosamente em roteadores PE de entrada.
Junos OS Release 6.4 ou posterior para o modo Esparso PIM de reinicialização graciosa do modo Esparso.
Junos OS Release 7.4 ou posterior para reinício gracioso do ES-IS.
Versão do Junos OS 8.5 ou posterior para sessão de BFD (apenas no modo helper) — Se um nó estiver passando por uma reinicialização graciosa e suas sessões de BFD forem distribuídas ao Mecanismo de encaminhamento de pacotes, o nó de peer pode ajudar o peer com a reinicialização graciosa.
Junos OS Release 9.2 ou posterior para BGP para oferecer suporte ao modo helper sem exigir que essa reinicialização graciosa seja configurada.