Alta disponibilidade para redes de acesso de assinantes
Este tópico é uma visão geral de alto nível da alta disponibilidade para redes de acesso DHCP, L2TP e PPP.
ISSU unificado para alta disponibilidade em redes de acesso de assinantes
Uma atualização unificada de software em serviço (ISSU unificado) permite que você atualize entre duas versões diferentes do Junos OS sem interrupção no plano de controle e com interrupção mínima do tráfego. Os roteadores preservam as sessões de assinante ativas e os serviços de sessão em toda a atualização, para que continuem após a conclusão da atualização.
O recurso ISSU unificado oferece suporte aos modelos de acesso PPPoE, DHCP e L2TP para gerenciamento de assinantes. O suporte ISSU unificado para os modelos de acesso DHCP e L2TP foi adicionado no Junos OS Release 14.1.
Para acesso PPPoE estático e dinâmico, o ISSU unificado suporta o seguinte:
Conexões PPPoE terminadas e sem túnel configuradas com interfaces lógicas PPP estáticas ou dinâmicas e interfaces subjacentes estáticas ou dinâmicas
Serviços de assinante em interfaces PPP de link único
Preservação de estatísticas para contabilidade, filtro e CoS em interfaces MPC/MIC
Observação:O ISSU unificado para o modelo de acesso PPPoE de gerenciamento de assinantes não oferece suporte a interfaces de pacote MLPPP (Multilink Point-to-Point Protocol). As interfaces de pacote MLPPP exigem o uso de um PIC de serviços adaptativos ou PIC de multisserviços para fornecer serviços de assinante PPP. Esses PICs não são compatíveis com ISSU unificado.
Para acesso DHCP, o ISSU unificado suporta o seguinte:
Servidor local DHCPv4, retransmissão DHCPv4, servidor local DHCPv6, retransmissão DHCPv6 e proxy de transmissão DHCP
Preservação de estatísticas de contabilidade, filtro e classe de serviço (CoS) para assinantes DHCP em interfaces MPC/MIC em roteadores da Série MX
Para acesso L2TP, o ISSU unificado oferece suporte ao LAC e ao LNS. Quando uma atualização é iniciada, o LAC conclui todas as negociações L2TP que estão em andamento, mas rejeita todas as novas negociações até que a atualização seja concluída. Nenhum novo túnel ou sessão é estabelecido durante a atualização. Os logouts do assinante são registrados durante a atualização e são concluídos após a conclusão da atualização.
Consulte Introdução ao Upgrade de Software em Serviço Unificado para obter uma descrição das plataformas e módulos suportados, instruções CLI e procedimentos que você usa para configurar e iniciar o ISSU unificado. Você pode usar o sinalizador issu com a traceoptions instrução para rastrear eventos ISSU unificados de gerenciamento de assinantes. Você também pode usar o show system subscriber-management summary comando para exibir informações sobre o estado unificado do ISSU.
Verificando e monitorando o gerenciamento de assinantes Estado ISSU unificado
Finalidade
Exiba o estado do ISSU unificado para recursos de gerenciamento de assinantes.
Ação
O primeiro exemplo indica que o plano de controle desativado como parte do ISSU unificado não está em andamento (por exemplo, o ISSU unificado não foi iniciado, já foi concluído ou o enfileiramento do plano de controle não foi iniciado). O segundo exemplo mostra que o ISSU unificado está em andamento e que um daemon de gerenciamento de assinantes participantes requer 198 segundos para desativar o plano de controle.
user@host> show system subscriber-management summary
General:
Graceful Restart Enabled
Mastership Master
Database Available
Chassisd ISSU State IDLE
ISSU State IDLE
ISSU Wait 0
user@host> show system subscriber-management summary
General:
Graceful Restart Enabled
Mastership Master
Database Available
Chassisd ISSU State DAEMON_ISSU_PREPARE
ISSU State PREPARE
ISSU Wait 198
Comutação de Mecanismo de Roteamento Graceful para Redes de Acesso de Assinantes
O recurso de comutação de Mecanismo de Roteamento (GRES) gracioso no Junos OS 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 da interface e do kernel. O tráfego não é interrompido. No entanto, o GRES não preserva o plano de controle.
Para habilitar o suporte GRES em roteadores da Série MX, inclua a graceful-switchover declaração no [edit chassis redundancy] nível de hierarquia.
DHCP
Para roteadores da Série MX, o servidor local DHCP estendido e os aplicativos de agente de transmissão DHCP mantêm o estado de concessões de cliente DHCP ativas no banco de dados de sessão. O aplicativo DHCP estendido pode recuperar esse estado se o processo DHCP falhar ou for reiniciado manualmente, evitando assim a perda de clientes DHCP ativos em qualquer uma dessas circunstâncias. No entanto, o estado das concessões de cliente DHCP ativas é perdido se ocorrer uma falha de energia ou se o kernel parar de operar (por exemplo, quando o roteador é recarregado) em um único Mecanismo de Roteamento.
Você não pode desabilitar o suporte de switchover gracioso do Mecanismo de Roteamento para o aplicativo DHCP estendido quando o roteador está configurado para suportar o switchover gracioso do Mecanismo de Roteamento.
Para obter mais informações sobre como usar o switchover gracioso do Mecanismo de Roteamento, consulte Entendendo o Switchover do Mecanismo de Roteamento Gracioso.
L2TP
O GRES é suportado em roteadores da Série MX, atuando como L2TP, LAC ou LNS. Caso o L2TP (jl2tpd, o processo de borda universal L2TP) seja reiniciado ou que o roteador faça failover do mecanismo de roteamento ativo (RE) para o RE em standby, o L2TP GRES garante que ocorra o seguinte:
O LAC e o LNS recuperam destinos, túneis e sessões que já estavam estabelecidos no momento da falha ou reinicialização.
O LAC e o LNS respondem às solicitações de keepalive de túnel recebidas durante a comutação para túneis estabelecidos, mas não geram keepalives até que a comutação seja concluída.
O LAC e o LNS excluem todos os túneis e sessões que não estão no estado Estabelecido.
O LAC e o LNS rejeitam solicitações para criar novos túneis e sessões.
O LAC e o LNS enviam outra notificação de desconexão ao peer para sessões e túneis que já estão no estado Desconectando no momento da falha ou reinicialização. Para sessões e túneis que estavam surgindo naquele momento, o LAC e o LNS enviam uma notificação de desconexão ao peer.
O LAC e o LNS reiniciam temporizadores para o período de tempo limite completo para destinos, túneis e sessões L2TP recuperados.
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 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:
set interface si-x/y/z disable commit
Ou:
request chassis fpc restart
Minimize a perda de tráfego devido à remoção de rota obsoleta após uma comutação de Mecanismo de Roteamento graciosa
Durante uma comutação graciosa do Mecanismo de Roteamento (GRES), as rotas de acesso e as rotas internas de acesso para gerenciamento de assinantes DHCP e PPP podem se tornar obsoletas. Após o GRES, o roteador remove todas essas rotas obsoletas da tabela de encaminhamento. Parte do tráfego será perdido se as rotas obsoletas forem removidas antes que as rotas sejam reinstaladas.
Em redes de assinantes com reinicialização graciosa e protocolos de roteamento, como BGP e OSPF configurados, o roteador limpa todas as rotas de acesso obsoletas restantes e as rotas internas de acesso assim que a operação de reinicialização graciosa é concluída, o que pode ocorrer logo após a conclusão da comutação graciosa do Mecanismo de Roteamento.
Em redes de assinantes com roteamento ativo sem interrupções (NSR) e protocolos de roteamento como BGP e OSPF configurados, o processo de protocolo de roteamento (rpd) limpa imediatamente as rotas de acesso obsoletas e as rotas internas de acesso que correspondem às rotas de assinante.
Você pode reduzir o risco dessa perda de tráfego configurando o roteador para atrasar a remoção de rotas obsoletas após um GRES. O período de atraso é de 180 segundos (3 minutos) não configuráveis. O roteador retém as rotas obsoletas durante o período, que é longo o suficiente para que o processo de cliente DHCP (jdhcpd), o processo de cliente PPP (jpppd) ou o processo de protocolo de roteamento (rpd) reinstale as rotas de acesso e as rotas internas de acesso antes que o roteador remova as rotas obsoletas da tabela de encaminhamento. O risco de perda de tráfego é minimizado porque o roteador sempre tem rotas de assinante disponíveis para assinantes DHCP e assinantes PPP.
Para configurar o roteador para atrasar a remoção (liberação) de rotas de acesso e rotas internas de acesso após uma comutação graciosa do Mecanismo de Roteamento:
Tabela de histórico de alterações
A compatibilidade com recursos é determinada pela plataforma e versão utilizada. Use o Explorador de recursos para determinar se um recurso é compatível com sua plataforma.