Alta disponibilidade para redes de acesso a assinantes
Este tópico é uma visão geral de alto nível de alta disponibilidade para redes de acesso DHCP, L2TP e PPP.
ISSU unificado para alta disponibilidade em redes de acesso a assinantes
Uma atualização unificada de software em serviço (ISSU unificada) permite que você atualize entre duas versões diferentes do Junos OS sem interrupções no plano de controle e com o mínimo de interrupção do tráfego. Os roteadores preservam as sessões ativas de assinantes 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 a PPPoE estático e dinâmico, o ISSU unificado oferece o seguinte suporte:
Conexões PPPoE terminadas e não tuneladas configuradas com interfaces lógicas PPP estáticas ou dinâmicas e interfaces estáticas ou dinâmicas subjacentes
Serviços para assinantes em interfaces PPP de link único
Preservação de estatísticas para interfaces de contabilidade, filtro e CoS em interfaces MPC/MIC
Nota:O ISSU unificado para o modelo de acesso PPPoE de gerenciamento de assinantes não oferece suporte a interfaces de pacote multilink de protocolo ponto a ponto (MLPPP). As interfaces de pacote MLPPP exigem o uso de um PIC de serviços adaptativos ou PIC de multisserviços para fornecer serviços para assinantes PPP. Esses PICs não oferecem suporte a ISSU unificada.
Para acesso ao DHCP, o ISSU unificado oferece o seguinte suporte:
Servidor local DHCPv4, transmissão DHCPv4, servidor local DHCPv6, transmissão DHCPv6 e proxy de transmissão DHCP
Preservação das 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 tanto ao LAC quanto ao LNS. Quando uma atualização é iniciada, o LAC conclui quaisquer negociações L2TP que estejam em andamento, mas rejeita qualquer nova negociação até que a atualização seja concluída. Nenhum novo túnel ou sessões são estabelecidos durante a atualização. Os logotipos dos assinantes são registrados durante a atualização e são concluídos após a conclusão da atualização.
Consulte o Getting Started with Unified In-Service Software Upgrade para uma descrição das plataformas e módulos suportados, declarações de CLI e procedimentos que você usa para configurar e iniciar o ISSU unificado. Você pode usar a bandeira de emissão com a traceoptions
declaraçã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 ISSU unificado.
Verificação e monitoramento do gerenciamento de assinantes Estado ISSU unificado
Propósito
Exibir o estado do ISSU unificado para recursos de gerenciamento de assinantes.
Ação
O primeiro exemplo indica que a quiescing de plano de controle como parte do ISSU unificado não está em andamento (por exemplo, o ISSU unificado não foi iniciado, já foi concluído ou a fila de plano de controle não começou). O segundo exemplo mostra que o ISSU unificado está em andamento e que um daemon de gerenciamento de assinantes participantes requer 198 segundos para quiescer 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
Switchover gracioso do mecanismo de roteamento para redes de acesso aos assinantes
O recurso gracioso de switchover do Mecanismo de Roteamento (GRES) 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 de interface e 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 nível de [edit chassis redundancy]
hierarquia.
DHCP
Para os roteadores da Série MX, o servidor local DHCP estendido e os aplicativos de agente de retransmissão DHCP mantêm o estado de leasings ativos de clientes DHCP no banco de dados da 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 dos leasings ativos de clientes DHCP é 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 gracioso de switchover do mecanismo de roteamento para o aplicativo DHCP estendido quando o roteador está configurado para oferecer suporte ao switchover gracioso do Mecanismo de Roteamento.
Para obter mais informações sobre o uso do switchover gracioso do Mecanismo de Roteamento, veja Entenda a comutação 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 se o roteador falhar do mecanismo de roteamento ativo (RE) para o RE de espera, o L2TP GRES garante que o seguinte ocorra:
O LAC e o LNS recuperam destinos, túneis e sessões que já estavam estabelecidas no momento da falha ou reiniciamento.
O LAC e o LNS respondem a solicitações de keepalive de túnel recebidas durante a transferência para túneis estabelecidos, mas não geram nenhum keepalive até que a transferência 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 de desconexão no momento da falha ou reiniciação. Para sessões e túneis que estavam surgindo na época, o LAC e o LNS enviam uma notificação de desconexão para o peer.
O LAC e o LNS reiniciam os temporizantes para o período de tempo integral 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 um compromisso de CLI ou FPC, reinicie ou trava, 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
Minimize a perda de tráfego devido à remoção de rota obsoleta após uma transição graciosa do mecanismo de roteamento
Durante um gracioso switchover do Mecanismo de Roteamento (GRES), rotas de acesso e rotas internas de acesso para gerenciamento de assinantes DHCP e PPP podem ficar obsoletas. Após o GRES, o roteador remove tais rotas obsoletas da tabela de encaminhamento. Algum tráfego é perdido se as rotas obsoletas forem removidas antes que as rotas sejam reinstaladas.
Em redes de assinantes com protocolos graciosos de reinício e roteamento, como BGP e OSPF configurados, o roteador elimina quaisquer rotas de acesso obsoletas e rotas internas de acesso assim que a graciosa operação de reinicialização é concluída, o que pode ocorrer logo após a conclusão do gracioso switchover do Mecanismo de Roteamento.
Em redes de assinantes com roteamento ativo (NSR) sem parar e protocolos de roteamento como BGP e OSPF configurados, o processo de protocolo de roteamento (rpd) elimina imediatamente as rotas de acesso obsoletas e as rotas internas de acesso que correspondem às rotas de assinantes.
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 não é configurado em 180 segundos (3 minutos). O roteador mantém as rotas obsoletas durante o período, o que é longo o suficiente para o processo de cliente DHCP (jdhcpd), processo de cliente PPP (jpppd) ou processo de protocolo de roteamento (rpd) para reinstalar as rotas de acesso e 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 assinantes disponíveis para assinantes DHCP e assinantes de PPP.
Para configurar o roteador para atrasar a remoção (flushing) de rotas de acesso e rotas internas de acesso após uma troca graciosa do mecanismo de roteamento: