Redundância de assinantes M:N no BNG
Visão geral da redundância de assinantes M:N no BNG
A partir do Junos OS Release 19.2R1, você pode configurar a redundância de assinante M:N como um mecanismo para melhorar a resiliência da rede, protegendo os assinantes de uma variedade de falhas de software e hardware. Essa proteção está disponível em uma topologia de rede típica, como a mostrada na Figura 1.
de grupo de assinantes M:N
Uma falha em qualquer um dos locais listados na Tabela 1 pode acionar um BNG primário para fazer failover para um BNG de backup.
Placa de linha de acesso |
Link voltado para o núcleo |
Link de acesso |
Rede de acesso parcial |
Chassi |
Rede de núcleo parcial |
Você pode usar a redundância M:N para proteger os seguintes tipos de assinantes:
Assinantes dinâmicos de DHCPv4 e DHCPv6 em VLANs estáticas 1:1 sobre IPoE; Redundância de VRRP
Assinantes estáticos baseados em VLAN; Redundância de VRRP
Assinantes estáticos baseados em IP demux; Redundância de VRRP
Assinantes DHCPv4 e DHCPv6 em VLANs dinâmicas ou estáticas sobre IP/MPLS; redundância pseudowire (Este suporte é adicionado no Junos OS Release 20.1R1.)
- Benefícios da redundância de assinantes M:N no BNG
- Fundamentos de redundância M:N
- Sessões de assinantes e modo de espera a quente
- Redundância M:N usando o protocolo de redundância de roteador virtual (VRRP)
- Failover VRRP e tempo de reversão
- Redundância M:N Usando redundância Pseudowire
- Assinantes estáticos e redundância M:N
- Convergência e redundância de assinantes M:N
Benefícios da redundância de assinantes M:N no BNG
Fornece uma redundância de assinante leve na camada de aplicativo. Você pode usá-lo para fazer backup de vários grupos de assinantes diferentes em vários chassis BNG diferentes. Cada grupo de assinantes tem um backup no modo de espera ativa.
Vários BNGs atuam como BNG ativo para um ou mais grupos de redundância de assinante e como BNG de backup para outros grupos de redundância de assinante ao mesmo tempo.
A redundância M:N é complementar à redundância do Virtual Chassis da Série MX. A redundância M:N é apropriada para ambientes distribuídos. O Virtual Chassis da Série MX requer um chassi dedicado para redundância. Ele fornece redundância 1:1 e é mais frequentemente usado em implantações centralizadas.
Você pode habilitar ou desabilitar a redundância M:N para assinantes ativos. Se você remover a configuração de redundância, os assinantes que tinham a configuração permanecerão intactos nos BNGs primários e de backup.
Você pode implantar a redundância M:N com uma única interface voltada para o núcleo. Isso significa que vários grupos de redundância de assinantes podem compartilhar uma conectividade de núcleo comum.
Os assinantes de redundância M:N podem coexistir com assinantes sem redundância. Isso significa que você não precisa ter BNGs dedicados à redundância do assinante.
Você pode configurar assinantes de redundância M:N em tempo de execução, mesmo depois que os assinantes estiverem ativos. Isso é útil para atualizações de software, porque você pode migrar assinantes para BNGs de backup e, em seguida, atualizar o software.
Fundamentos de redundância M:N
Para simplificar, a maior parte da explicação da redundância M:N nesta documentação reflete o uso de assinantes DHCP em VLANs estáticas.
A base da redundância M:N é que vários grupos de assinantes (M) em um determinado chassi BNG podem ser apoiados em vários (N) destinos de chassi diferentes. Referimo-nos a esses grupos como grupos de redundância de assinante.
Um grupo de assinantes consiste em todos os assinantes que atendem aos seguintes critérios:
(VLANs estáticas) Os assinantes pertencem a uma VLAN estática específica e usam a mesma interface de acesso lógico, como ge-1/0/10/1. Um dispositivo de acesso, como um switch, DSLAM ou OLT, agrega os assinantes na VLAN comum.
(VLANs dinâmicas) Os assinantes pertencem à mesma VLAN dinâmica e usam a mesma interface de acesso físico, como ge-1/0/0.
(Demux IP estático) Todos os assinantes têm um endereço IP de origem que corresponde à sub-rede configurada.
Quando você configura a redundância para um grupo de assinantes, ele se torna um grupo de redundância de assinantes. Um determinado grupo de redundância de assinante usa apenas um BNG por vez. Chamamos esse BNG de primário. Para cada grupo de redundância de assinante, apenas um dos outros BNGs atua como backup no modo de espera ativa. Quando um dos erros listados na Tabela 1 ocorre para o BNG primário, ele faz failover para o BNG de backup apropriado para o grupo de redundância afetado. Esse BNG de backup agora é o novo BNG principal para esse grupo. Todas as sessões de assinante ativas para esse grupo de redundância de assinante são mantidas em todo o failover para o BNG de backup.
A Figura 2 é um diagrama conceitual que ilustra as relações primárias/de backup M:N. Ele mostra cinco BNGs em uma topologia primária/backup M:N em que cada BNG tem um relacionamento com todos os outros BNG. Se BNG 1 for o principal, você poderá configurar BNG 2, 3, 4 e 5 como BNG de backup para diferentes grupos de redundância de assinante. Se BNG 2 for o primário, você poderá configurar BNG 1, 3, 4 e 5 como BNG de backup e assim por diante.
de grupo de assinantes M:N
Para redundância M:N, é importante entender que você pode configurar:
Apenas um BNG de backup para cada grupo de redundância de assinante.
Um BNG para ser o roteador de backup para mais de um grupo de redundância.
Isso significa que um determinado BNG pode ser simultaneamente o roteador principal para muitos grupos de redundância e o roteador de backup para muitos grupos de redundância diferentes. Quando um BNG primário falha, ele faz failover para o roteador de backup que você configura para cada um de seus grupos de redundância. As sessões de assinante para todos os grupos de redundância no BNG primário são mantidas em todos os BNGs de backup que se tornam novos primários para os grupos.
A Figura 3 mostra uma configuração simples de grupos de assinantes e grupos de redundância de assinantes em três agentes de retransmissão DHCP hospedados em três BNGs. Os BNGs podem estar diretamente conectados uns aos outros ou conectados pelas redes de acesso ou núcleo.
O agente de retransmissão RA1 é configurado para grupos de redundância de assinante, SRG 1 e SRG 2 e grupo de assinantes SG A.
O agente de transmissão RA2 está configurado para SRG 2 e SRG 3.
O agente de transmissão RA3 está configurado para SRG 1, SRG 3 e SG B.
Outra maneira de ver isso é que:
O SRG 1 pode estar ativo ou com backup em RA1 e RA3.
O SRG 2 pode estar ativo ou com backup em RA1 e RA2.
O SRG 3 pode estar ativo ou com backup em RA2 e RA3.
O SG A e o SG B não são copiados.
Agora considere a Figura 4, que mostra a mesma topologia, mas indica qual BNG é primário e qual é backup para cada grupo de redundância. O BNG que hospeda o RA 1 é o BNG primário para SRG 1 e SRG 2.
Se esse BNG falhar, ele fará failover para um BNG de backup diferente para SRG 1 e SRG 2, conforme mostrado na Figura 5.
Para o SRG 1, ele faz failover para o BNG que hospeda o RA 3. O BNG RA 3 torna-se o novo primário para SRG 1.
Para o SRG 2, ele faz failover para o BNG que hospeda o RA 2. O BNG RA 2 torna-se o novo primário para SRG 2.
A falha não afeta o SRG 3.
Sessões de assinantes e modo de espera a quente
Cada BNG de backup está no modo de espera ativa para seu BNG primário correspondente para cada grupo de redundância de assinante no backup. Isso significa que o BNG de backup está pronto para substituir o BNG principal imediatamente e sem interrupção quando ocorrer um failover. Os seguintes comportamentos do BNG principal e de backup permitem que o modo de espera ativa funcione.
As ligações do assinante e o estado do assinante são espelhados de forma síncrona para o BNG de backup, assim como o ARP do BNG primário e as informações de descoberta de vizinhos. Cada assinante é ativado no BNG de backup e seu estado é Ativo. Como os assinantes estão ativos simultaneamente no BNG principal e de backup, o BNG de backup não executa nenhum processamento de assinante durante um evento de failover.
Cada sessão de assinante é tratada como uma sessão contínua antes, durante e depois de um failover. Durante o login inicial do assinante, os BNGs primários e de backup enviam uma mensagem RADIUS Accounting-Start ou uma mensagem OCS CCR-I para o assinante.
Durante o failover, o primário com falha envia uma mensagem de parada de contabilidade ou CCR-T com base no melhor esforço. Por exemplo, ele envia a mensagem se o enlace voltado para o núcleo ainda estiver ativo ou se o chassi ainda estiver em execução. Se o enlace voltado para o núcleo estiver inativo ou todo o chassi estiver inativo, o principal com falha não poderá enviar uma mensagem Accounting-Stop ou CCR-T.
Quando o BNG de backup se torna primário, ele não envia uma mensagem Accounting-Start ou CCR-I porque os assinantes estão ativos no failover. As estatísticas contábeis são incrementadas a partir do novo primário.
Durante o login inicial do assinante, o BNG adiciona rotas de assinante à sua tabela de roteamento e propaga as rotas para a rede principal. Quando o BNG primário falha, ele não exclui rotas de assinantes de sua própria tabela de roteamento e não retira as rotas da rede principal. Após o failover, o primário com falha não adiciona nem propaga nenhuma rota. Como alternativa, você pode configurar as rotas do assinante a serem anunciadas ou retiradas do núcleo com base na função primária BNG para que não haja perda de tráfego como resultado do failover.
A sincronização de estado se aplica somente ao estado do assinante. O estado do serviço não está sincronizado. Dependendo da configuração dos serviços, o BNG pode anexar serviços para os assinantes ativos e de backup. Como alternativa, os serviços podem ser reconectados após o failover no novo BNG ativo.
A redundância de assinante M:N não sincroniza estatísticas contábeis do BNG primário para o BNG de backup. Ele faz uma tentativa de melhor esforço para comunicar informações contábeis a um servidor de contabilidade. Quando ocorre um failover, as estatísticas contábeis começam a ser incrementadas a partir do novo primário e param de incrementar a partir do primário com falha. Dependendo da gravidade da falha, os failovers podem resultar em perda de informações contábeis.
Redundância M:N usando o protocolo de redundância de roteador virtual (VRRP)
Você pode usar o VRRP para fornecer redundância M:N em uma rede. A redundância M:N usa VRRP para fornecer um endereço IP virtual e um endereço MAC compartilhados por dois BNGs em um grupo VRRP (às vezes chamado de instância VRRP). O grupo VRRP corresponde a um único roteador virtual. Você configura o grupo VRRP na respectiva interface de acesso em cada BNG. A interface de acesso é a interface lógica voltada para o assinante que está conectada à rede de acesso.
O endereço IP virtual torna-se o endereço de gateway padrão para os BNGs no grupo. Somente o BNG que atua como principal envia anúncios VRRP ou responde ao tráfego destinado ao endereço do roteador virtual. O BNG anuncia apenas o endereço de gateway virtual e o endereço MAC virtual para hosts de assinantes. Como ambos os roteadores do grupo compartilham o mesmo endereço de gateway virtual, nenhuma interação com os hosts é necessária e o failover do primário para o backup ocorre em alguns segundos.
A solução VRRP para redundância M:N é direcionada para um modelo de acesso de assinante N:1 que usa interfaces lógicas subjacentes estáticas.
Para obter informações detalhadas sobre como o VRRP funciona em geral, consulte Noções básicas sobre VRRP e tópico relacionado no Guia do usuário de alta disponibilidade.
Você configura prioridades diferentes para os dois roteadores em um grupo VRRP para determinar qual roteador o grupo elege para ser o principal:
O roteador com a prioridade mais alta para o grupo é o principal. Quanto maior o número, maior a prioridade. Por exemplo, entre dois membros do grupo com prioridades de 100 e 50, respectivamente, o roteador com prioridade 100 é o principal.
Quando o primário falha, o protocolo elege o roteador de backup como o novo primário. O novo primário assume a propriedade dos endereços IP e MAC virtuais. O failover não tem efeito no tráfego de dados.
-
Quando o primário original volta a ficar online, o protocolo determina que ele tem uma prioridade mais alta do que o primário atual (backup anterior). Em seguida, o primário original retoma a função primária sem afetar o tráfego de dados.
Observação:Ao usar o VRRP para redundância de assinantes M:N, o número de grupos de redundância de assinantes é limitado ao número de sessões VRRP suportadas no dispositivo. Para pilha dupla, esse recurso requer sessões VRRP separadas para IPv4 e IPv6, portanto, o número de grupos de redundância de assinantes é reduzido pela metade.
A Figura 6 mostra uma topologia de exemplo com dois BNGs e a configuração das interfaces correspondentes em cada roteador:
As duas interfaces lógicas estão na mesma VLAN (1).
Os endereços da interface estão na mesma sub-rede (203.0.113.1/24 e 203.0.113.2/24).
Os endereços de interface estão no mesmo grupo VRRP (27) e compartilham o mesmo endereço IP virtual (203.0.113.25).
O BNG com a prioridade mais alta (254) é eleito primário; o BNG com a prioridade mais baixa (200) é o backup.
e de backup
A Figura 7 mostra como a prioridade VRRP configurada determina qual BNG atua como principal ou backup para um grupo de redundância de assinante.
de redundância de assinantes
A topologia inclui três grupos de redundância de assinante (M), SRG 1, SRG 2 e SRG 3 em três BNGs (N). Cada grupo de redundância de assinante corresponde a um grupo VRRP diferente. As setas indicam o roteador principal e o roteador de backup para cada grupo
Para SRG 1, BNG 1 tem a prioridade mais alta, 250. BNG 3 tem uma prioridade mais baixa, 200. Isso significa que o BNG 1 é o principal para SRG 1 e o BNG 3 é o backup, portanto, o BNG 1 faz failover para o BNG 3. Quando o BNG 1 se recupera, ele é reeleito primário para o SRG 1, porque tem uma prioridade maior do que o BNG 3.
Para SRG 2, BNG 1 também tem a prioridade mais alta, 180, e é a primária. BNG 2 tem uma prioridade mais baixa, 150, e é o backup.
Para SRG 3, BNG 2 tem a prioridade mais alta, 100, e é a primária. BNG 3 tem uma prioridade mais baixa, 75, e é o backup.
Failover VRRP e tempo de reversão
Usando a configuração de redundância mostrada na Figura 7, suponha que o BNG 1 faça failover para o BNG 3 para SRG 1, de modo que o BNG 3 seja o novo primário do grupo. A função principal é revertida automaticamente para BNG 1 quando volta a funcionar. Se a conexão entre os dois BNGs for através da rede de acesso (em comparação com um link direto entre os BNGs), os estados do assinante podem não ser sincronizados entre os dois BNGs quando a função primária for revertida. O estado do VRRP é independente da sincronização leasequery ativa do DHCP.
Quando o link de acesso no BNG 1 é restaurado, o leasequery ativo do DHCP restaura a conexão para sincronização do assinante entre os BNGs. O DHCP começa a ressincronizar o estado do assinante e as informações de vinculação do primário atual (BNG 3) para o primário original recuperado (BNG 1).
As estatísticas contábeis podem ser afetadas se a função principal for revertida para BNG 1 antes que a ressincronização seja concluída. Por exemplo, as estatísticas contábeis dos assinantes que fazem login não são adicionadas ao banco de dados até que a ressincronização seja concluída. As mensagens de logout para assinantes que fazem logout não são processadas até que a sincronização termine e os assinantes sejam recuperados no BNG 1.
Você pode mitigar esses efeitos configurando o temporizador de espera VRRP (às vezes chamado de temporizador revertivo) para que a ressincronização seja concluída antes que o primário original retome a função principal. Use a hold-time instrução no nível da [edit interfaces] hierarquia.
Recomendamos que você configure a redundância VRRP no modo não revertivo quando estiver operando em alta escala. Para sistemas que não operam em escala, você pode usar o modo não revertivo ou configurar o temporizador de espera VRRP (às vezes chamado de temporizador revertivo) com valores altos o suficiente para que a ressincronização seja concluída antes que o primário original retome a função principal.
Redundância M:N Usando redundância Pseudowire
A partir do Junos OS Release 20.1R1, você pode usar a redundância pseudowire para oferecer redundância M:N quando a rede de acesso consiste em circuitos de Camada 2 (L2) sobre IP/MPLS. Nesse tipo de rede de acesso, LDP é o protocolo de sinalização que distribui rótulos entre vizinhos do circuito L2. Cada circuito L2 é um túnel pseudowire ponto a ponto entre o nó de acesso (ou dispositivo de borda do cliente) e um BNG. A rede pode incluir uma combinação heterogênea de dispositivos L2 ou L3.
A Figura 8 mostra uma topologia simples em que os nós de acesso agregam tráfego e o enviam pela rede para um agente de retransmissão DHCP no BNG principal. A configuração de redundância pseudowire especifica um pseudowire ativo (para o BNG principal) e um pseudowire de backup (para o BNG de backup).
e de backup
Para circuitos L2, você configura os pseudowires como as interfaces subjacentes (voltadas para o acesso) nos BNGs. Em seguida, você configura as interfaces com conexões L2, como Ethernet, VLANs dinâmicas com detecção automática ou VLANs estáticas. As interfaces pseudowire voltadas para o cliente DHCP são agrupadas e adicionadas a um circuito L2 (o túnel pseudowire. Normalmente, o pacote inclui um conjunto de interfaces VLAN dinâmicas. No entanto, o pacote pode incluir qualquer combinação de interfaces lógicas VLAN únicas, listas de interfaces VLAN e interfaces físicas.
Um circuito L2 é executado entre dois vizinhos L2; nesse caso, entre um nó de acesso e um BNG. Cada vizinho serve como um destino de ponto final para um caminho comutado por rótulos (LSP) MPLS. Você constrói o circuito configurando-o em uma interface em cada vizinho:
No BNG, você especifica o nó de acesso como um vizinho e uma interface pseudowire local no BNG que encerra o circuito L2.
No nó de acesso, você especifica o BNG como um vizinho e uma interface local voltada para os clientes no nó que é a outra extremidade do circuito L2.
No nó BNG e de acesso, você configura um identificador de circuito virtual (VCI) exclusivo que distingue esse circuito L2 de todos os outros circuitos L2 que terminam no dispositivo.
Esse circuito L2 é agora o pseudowire primário para o BNG. Para estabelecer redundância, configure o pseudowire de backup no nó de acesso. Na mesma interface local, você especifica outro BNG como o vizinho de backup e especifica que o pseudowire de backup está no modo de espera ativa.
O modo de espera ativa garante que o vizinho de backup esteja totalmente pronto para assumir o controle como primário se o circuito primário atual falhar. Um LSP para o vizinho de backup já está estabelecido pelo LDP.
O estado da interface pseudowire é UP no BNG primário. O estado da interface pseudowire é o modo de espera remoto (RS) no BNG de backup. (Você pode usar o show l2circuit connections brief comando para exibir o estado do circuito.) Você deve configurar suas políticas de rota para que as rotas de sub-rede para esse grupo de redundância sejam anunciadas apenas no BNG principal. Isso garante que apenas o primário receba tráfego downstream.
O LDP tem um mecanismo de manutenção de atividade para detectar falhas. Uma falha resulta no failover do circuito L2 do pseudowire primário e do BNG primário para o pseudowire de backup e o BNG de backup. Quando detecta uma falha, o LDP comuta o circuito do LSP primário (no pseudowire primário) para o LSP de backup (no pseudowire de backup). O BNG de backup assume a função principal e seu estado faz a transição para Up.
Quando o primário antigo está ativo novamente, as mesmas considerações sobre a sincronização se aplicam à redundância pseudowire que quando o VRRP é o método de redundância.
Recomendamos que você configure a redundância pseudowire no modo não revertivo quando estiver operando em alta escala. Para sistemas que não operam em escala, é possível usar o modo não revertivo ou configurar o revert-time intervalo na interface do nó de acesso com valores altos o suficiente para que a ressincronização seja concluída antes que o primário original retome a função primária.
Assinantes estáticos e redundância M:N
A redundância de assinante M:N oferece suporte a duas categorias de assinantes:
Assinantes que usam o protocolo de cliente DHCP em uma VLAN estática. Esse é o tipo de assinante mais comum para redundância de assinante M:N.
Assinantes em interfaces estáticas que não estão executando um protocolo de cliente. Esse tipo de assinante é típico para pequenas e médias empresas que têm seu próprio endereço IP estático e não usam nada parecido com o DHCP.
Os assinantes estáticos consistem nos seguintes tipos:
Assinantes estáticos baseados em VLAN — Você cria assinantes em cima da interface lógica VLAN. Você configura os atributos VRRP na interface lógica VLAN.
Assinantes estáticos baseados em IP demux — Você cria assinantes em uma interface IP demux em uma interface subjacente. O tráfego para esses assinantes inclui um endereço IP de origem que corresponde à sub-rede configurada para a interface do assinante. Você configura atributos VRRP na interface lógica subjacente.
Ambos os tipos de assinantes estáticos são gerenciados pelo daemon jsscd. Às vezes, eles são chamados de assinantes estáticos JSSCD.
Os snippets de configuração de exemplo a seguir mostram como criar um grupo de assinantes estáticos com duas interfaces configuradas para VRRP em um BNG primário e um BNG de backup. Uma interface é uma interface IP demux e a outra é uma interface VLAN. A configuração mostra como o VRRP é configurado em cada interface.
Configuração BNG primária:
O snippet a seguir configura a interface subjacente para a interface lógica IP demux, ge-1/1/9.11. Ele especifica o ID da VLAN como 11. A sub-rede da interface de acesso é definida como 203.0.113.1/24. A configuração VRRP nesta sub-rede define o grupo (o grupo de redundância do assinante) como 11 e especifica o endereço para o roteador virtual. O roteador virtual consiste nos BNGs primários e de backup para esse grupo de redundância de assinante. A prioridade do VRRP é 230. Quando o primário faz failover para o backup, a assunção da função primária pelo backup é atrasada em 30 segundos.
[edit] interfaces { ge-1/1/9 { unit 11 { demux-source inet; vlan-id 11; family inet { address 203.0.113.1/24 { vrrp-group 11 { virtual-address 203.0.113.25; priority 230; preempt { hold-time 30; } } } } } } }O trecho a seguir configura a interface lógica da VLAN, ge-1/1/9.20. Ele especifica o ID da VLAN como 20. A sub-rede da interface de acesso é definida como 192.0.2.1/24. A configuração VRRP nessa sub-rede define o grupo (o grupo de redundância do assinante) como 20 e especifica o endereço para o roteador virtual. O roteador virtual consiste nos BNGs primários e de backup para esse grupo de redundância de assinante. A prioridade do VRRP é 230. Quando o primário faz failover para o backup, a assunção da função primária pelo backup é atrasada em 30 segundos.
[edit] interfaces { ge-1/1/9 { unit 20 { vlan-id 20 ; family inet { address 192.0.2.1/24 { vrrp-group 20 { virtual-address 192.0.2.25; priority 230; preempt { hold-time 30; } } } } } } }O snippet a seguir configura a interface lógica de IP demux, demux0.1, sobre a interface subjacente, ge-1/1/9.11. Ele também configura a interface de loopback e permite que o endereço local para a interface de demux de IP seja derivado da interface de loopback.
[edit] interfaces { demux0 { unit 1 { demux-options { underlying-interface ge-1/1/9.11; } family inet { unnumbered-address lo0.0; } } } lo0 { unit 0 { family inet { address 192.168.10.32/32; } } } }O snippet a seguir configura um grupo de assinantes estáticos, static-ifl, que inclui a interface de assinante estático de IP demux (demux0.1) e a interface de assinante estático de VLAN (ge-1/1/9.20). Ele associa um perfil de acesso ao grupo, define a senha e um prefixo para o nome de usuário.
[edit system services] static-subscribers { group static-ifl { access-profile { staticauth; } authentication { password "$ABC123$ABC123"; ## SECRET-DATA username-include { user-prefix test-static; } } interface ge-1/1/9.20; interface demux0.1; } }O snippet a seguir configura um perfil de acesso para o grupo de assinantes estáticos.
[edit access] profile staticauth { authentication-order none; }
Configuração BNG de backup:
Neste exemplo, alguns detalhes de configuração são diferentes e outros devem ser os mesmos.
As interfaces de acesso são diferentes. Como alternativa, você pode configurar as interfaces de acesso para serem as mesmas no primário e no backup.
A prioridade do VRRP é definida como 200 para ambas as interfaces. Esse valor torna este o BNG de backup, porque é menor que a prioridade no outro BNG (230).
Os endereços da interface são diferentes. O endereço virtual é o mesmo para ambos, como deve ser, para que ambos os BNGs estejam no mesmo roteador virtual.
As interfaces de acesso estão na mesma sub-rede.
O snippet a seguir configura a interface subjacente para a interface lógica IP demux, ge-3/0/1.11. Ele especifica o ID da VLAN como 11. A sub-rede da interface de acesso é definida como 203.0.113.2/24. A configuração VRRP nesta sub-rede define o grupo (o grupo de redundância do assinante) como 11 e especifica o endereço para o roteador virtual. O roteador virtual consiste nos BNGs primários e de backup para esse grupo de redundância de assinante. A prioridade do VRRP é 200. Quando o primário faz failover para o backup, a assunção da função primária pelo backup é atrasada em 30 segundos.
[edit] interfaces { ge-3/0/1 { unit 11 { demux-source inet; vlan-id 11; family inet { address 203.0.113.2/24 { vrrp-group 11 { virtual-address 203.0.113.25; priority 200; preempt { hold-time 30; } } } } } } }O trecho a seguir configura a interface lógica da VLAN, ge-3/0/1.20. Ele especifica o ID da VLAN como 20. A sub-rede da interface de acesso é definida como 192.0.2.2/24. A configuração VRRP nessa sub-rede define o grupo (o grupo de redundância do assinante) como 20 e especifica o endereço para o roteador virtual. O roteador virtual consiste nos BNGs primários e de backup para esse grupo de redundância de assinante. A prioridade do VRRP é 200. Quando o primário faz failover para o backup, a assunção da função primária pelo backup é atrasada em 30 segundos.
[edit] interfaces { ge-3/0/1 { unit 20 { vlan-id 20 ; family inet { address 192.0.2.2/24 { vrrp-group 20 { virtual-address 192.0.2.25; priority 200; preempt { hold-time 30; } } } } } } }O snippet a seguir configura a interface lógica de IP demux, demux0.1, sobre a interface subjacente, ge-3/0/1.11. Ele também configura a interface de loopback e permite que o endereço local para a interface de demux de IP seja derivado da interface de loopback.
[edit] interfaces { demux0 { unit 1 { demux-options { underlying-interface ge-3/0/1.11; } family inet { unnumbered-address lo0.0; } } } lo0 { unit 0 { family inet { address 192.168.10.32/32; } } } }O snippet a seguir configura um grupo de assinantes estáticos, static-ifl, que inclui a interface de assinante estático de IP demux (demux0.1) e a interface de assinante estático de VLAN (ge-3/0/1.20). Ele associa um perfil de acesso ao grupo, define a senha e um prefixo para o nome de usuário.
[edit system services] static-subscribers { group static-ifl { access-profile { staticauth; } authentication { password "$ABC123"; ## SECRET-DATA username-include { user-prefix test-static; } } interface ge-3/0/1.20; interface demux0.1; } }O snippet a seguir configura um perfil de acesso para o grupo de assinantes estáticos.
[edit access] profile staticauth { authentication-order none; }
Convergência e redundância de assinantes M:N
Convergência é o processo no qual os roteadores em uma rede atualizam suas tabelas de roteamento individuais quando as rotas em qualquer roteador são adicionadas, removidas ou não podem mais ser alcançadas devido a uma falha de link. Os protocolos de roteamento nos roteadores anunciam as mudanças de rota em toda a rede. À medida que cada roteador recebe as atualizações, ele recalcula as rotas e cria novas tabelas de roteamento com base nos resultados.
Uma rede é convergida quando todas as tabelas de roteamento concordam com a topologia geral da rede. Por exemplo, isso significa que os roteadores têm um entendimento comum sobre quais links estão ativos ou inativos, e assim por diante. Quanto tempo leva para os roteadores atingirem um estado de convergência é chamado de tempo de convergência. A duração do tempo de convergência depende de vários fatores, como o tamanho e a complexidade da rede e o desempenho dos protocolos de roteamento.
A redundância de assinante M:N oferece suporte à convergência de rota do lado do acesso (upstream) e do lado do núcleo (downstream). Como cada assinante está ativo simultaneamente nos BNGs primários e de backup, a convergência de tráfego pode ser muito rápida. No entanto, a convergência de rotas é o melhor esforço e depende do grau de failover; ou seja, se ocorre uma falha parcial ou total do chassi.
Cabe a você determinar como gerenciar a convergência de tráfego upstream e downstream para sua rede após um failover do BNG principal para o backup.
- Convergência de tráfego upstream (redundância VRRP)
- Convergência de tráfego upstream (redundância pseudowire)
- Convergência de tráfego downstream
Convergência de tráfego upstream (redundância VRRP)
Você pode melhorar a convergência de tráfego upstream usando ARP gratuito para reduzir o tempo necessário para a rede de acesso começar a enviar tráfego para o novo BNG primário após a falha do BNG primário original.
No BNG primário, a interface de acesso ou o módulo de interface fica inativo.
O VRRP elege o BNG reserva como o novo primário.
O novo primário transmite mensagens ARP gratuitas para a rede de acesso. Ele envia as mensagens de sua interface de acesso correspondente à interface de acesso do primário anterior. A mensagem ARP contém o endereço IP virtual VRRP e o endereço MAC virtual que definem o roteador virtual que inclui os dois BNGs.
O switch ou outro dispositivo na rede de acesso reaprende o endereço IP do gateway (o endereço virtual). Quando ele envia tráfego para esse endereço, o novo BNG primário o recebe na interface de acesso.
Convergência de tráfego upstream (redundância pseudowire)
Quando você configura os pseudowires primários e de backup no modo hot-standby no nó de acesso, o LDP estabelece automaticamente LSPs para os BNGs primários e de backup. O protocolo de sinalização LDP inclui um mecanismo de keepalive para detectar falhas no caminho. Nesse caso, a convergência upstream é obtida por um switch de túnel de Camada 2 pseudowire do BNG primário para o BNG de backup.
Você pode configurar temporizadores de keep-alive LDP para detecção mais rápida de falhas. Como alternativa, você pode executar o protocolo BFD para um failover mais rápido. Qualquer um dos métodos a seguir pode causar uma mudança do pseudowire primário para o pseudowire de backup:
Use o
request l2circuit-switchovercomando para acionar manualmente um switch do pseudowire primário para o pseudowire de backup.Você pode configurar a detecção de encaminhamento bidirecional (BFD) para os LSPs LDP. A detecção de vivacidade BFD pode detectar dois tipos diferentes de falhas:
Uma falha de enlace no caminho LSP entre o nó de acesso e o BNG principal. Nesse caso, o BNG ainda está ativo.
Um vizinho inativo falha quando o BNG primário fica inativo.
Para ambos os tipos, você controla a velocidade da detecção e da alternância pela configuração da instrução no
[edit protocols ldp oam]nível dabfd-liveness-detectionhierarquia.
Convergência de tráfego downstream
O tempo necessário para a convergência do tráfego downstream é afetado por vários fatores, incluindo o seguinte:
A publicidade de rotas de assinantes individuais aumenta o número de recálculos de rota que os roteadores de rede principal devem executar.
Detectar quando uma interface de acesso fica inativa e enviar a notificação de mudança de rota apropriada para o núcleo às vezes pode ser difícil ou demorado.
Os protocolos de roteamento no núcleo podem não aprender imediatamente quando um enlace voltado para o núcleo ou todo o chassi falha. Os protocolos de roteamento normalmente dependem de algum tipo de tempo limite para detectar a perda, portanto, sempre há um atraso aguardando o tempo limite expirar.
Recomendamos as seguintes diretrizes:
Certifique-se de que as rotas do assinante sejam agregadas para anúncio no núcleo sempre que possível. A agregação pode ser obtida usando pools de endereços ou anúncio de rota baseado em políticas, conforme descrito abaixo. Reduzir o número de rotas a serem recalculadas nos roteadores de núcleo reduz o tempo de convergência, especialmente à medida que a escala de assinantes aumenta.
Configure as rotas a serem anunciadas de ambos os BNGs com preferências diferentes. Use técnicas de redirecionamento rápido no núcleo.
Evite o balanceamento de carga do tráfego downstream entre os BNGs primários e de backup.
Dois métodos que você pode considerar são o anúncio de rota baseado em políticas e links BNG dedicados.
Anúncio de rota baseado em política (VRRP e redundância de pseudowire) — Essa técnica pode reduzir o tempo de convergência de tráfego downstream porque apenas rotas agregadas são atualizadas na rede principal, em vez de várias rotas de assinantes individuais. Para esse método, você configura o BGP, o OSPF ou qualquer outro protocolo de roteamento para anunciar rotas agregadas em direção ao núcleo somente quando um BNG se torna o principal.
Para redundância VRRP, você configura as políticas BGP para rastrear o endereço IP virtual VRRP. O BGP agrega as rotas do assinante com base no grupo de redundância do assinante correspondente a um grupo VRRP. O BGP anuncia as rotas agregadas para o núcleo quando a função primária do VRRP é assumida pelo BNG.
Para redundância pseudowire, você configura as políticas BGP para rastrear o status da interface pseudowire (Up ou Down). O BGP agrega rotas para o grupo de redundância do assinante. O BGP anuncia as rotas agregadas para o núcleo quando o estado muda para Up, o que significa que o BNG de backup agora é o principal.
Em ambos os casos, se o BNG primário falhar no backup, o BGP no primário com falha retirará as rotas agregadas de assinantes para o núcleo. Quando o BNG de backup se torna o novo primário, ele, por sua vez, anuncia grupos de assinantes agregados no núcleo.
Links dedicados BNG (somente redundância VRRP) — Você pode reduzir o tempo necessário para detectar uma falha no BNG principal conectando os BNGs com um link dedicado. Você configura o VRRP na interface de acesso para rastrear o estado da interface de enlace dedicado. Você também configura o VRRP na interface de enlace dedicado para rastrear o estado da interface de acesso.
Uma falha na interface de acesso no primário faz com que a função primária do VRRP mude no link dedicado. Essa alteração, por sua vez, faz com que a função principal mude imediatamente na interface de acesso no BNG de backup. Esse método é mais rápido do que esperar que o temporizador de saudação do VRRP expire.
Como configurar a redundância de assinantes M:N com sincronização de vinculação VRRP e DHCP
A redundância de assinante M:N com sincronização de vinculação VRRP e DHCP requer que você configure todos os seguintes:
Grupos de assinantes redundantes para especificar os assinantes que fazem parte da operação primária/backup.
VRRP em todos os roteadores redundantes na topologia. VRRP é o protocolo que fornece a capacidade de redundância subjacente para os grupos de assinantes e agentes de transmissão DHCP.
Este tópico descreve apenas as configurações básicas necessárias para a redundância de assinante M:N nos BNGs que hospedam os agentes de retransmissão DHCP de peer. Ele não descreve todos os aspectos do seguinte: gerenciamento global de assinantes, a configuração VRRP que você pode usar em sua rede, agentes de retransmissão DHCP ou leasequery DHCP. Para obter mais informações sobre esses assuntos, consulte o seguinte:
A redundância de assinante M:N requer que os BNGs primários e de backup ofereçam suporte às mesmas versões de protocolo para DHCP e VRRP. Se o suporte ao protocolo for diferente entre os BNGs, você poderá ver efeitos colaterais indesejáveis.
Os assinantes de redundância de pilha dupla têm o requisito de configuração VRRP. Você deve configurar ambas as famílias de endereços na interface de acesso, pois os assinantes de pilha dupla exigem duas sessões, uma para IPv4 e uma para IPv6. Você também deve configurar a mesma prioridade de função primária VRRP para as sessões IPv4 e IPv6 para um determinado grupo de redundância porque eles compartilham a mesma interface lógica.
Configurar redundância de grupo de assinantes
Para configurar a redundância do grupo de assinantes em um BNG:
Configurar o VRRP para suportar redundância M:N
Para configurar o VRRP para oferecer suporte à redundância M:N para um grupo de redundância de assinante em um BNG:
Como configurar a redundância de assinantes M:N com pseudowires e sincronização de ligação DHCP
A redundância de assinante M:N com pseudowires e a sincronização de associação DHCP exigem que você configure grupos de assinantes redundantes para especificar os assinantes que fazem parte da operação primária/backup.
A redundância de assinante M:N com funções pseudowires em uma rede IP/MPLS onde túneis pseudowire de um nó de acesso (como um switch) compõem os circuitos L2 para os BNGs primários e de backup atuando como agentes de transmissão DHCP. Essas configurações estão fora do escopo desta documentação.
Este tópico descreve apenas as configurações básicas necessárias para a redundância de assinante M:N nos BNGs que hospedam os agentes de retransmissão DHCP de peer. Ele não descreve todos os aspectos do seguinte: gerenciamento global de assinantes, agentes de retransmissão DHCP ou leasequery DHCP. Ele não descreve como configurar sua rede IP/MPLS, o nó de acesso que cria os circuitos L2 para os agentes de transmissão DHCP ou os túneis pseudowire. Para obter mais informações sobre esses assuntos, consulte o seguinte:
A redundância de assinante M:N requer que os BNGs primários e de backup ofereçam suporte às mesmas versões de protocolo para DHCP. Se o suporte ao protocolo for diferente entre os BNGs, você poderá ver efeitos colaterais indesejáveis.
Configurar redundância de grupo de assinantes
Para configurar a redundância do grupo de assinantes em um BNG:
Por exemplo, você pode configurar o seguinte em um BNG:
[edit system services subscriber-management redundancy] user@host# set protocol pseudo-wire user@host# set interface ps2.0 local-inet-address 10.80.1.2 user@host# set interface ps2.0 local-inet6-address 2001:db8:: user@host# set interface ps2.0 shared-key pskey-2.0-abc-215 user@host# set interface ps3.0 local-inet-address 10.10.0.1 user@host# set interface ps3.0 local-inet6-address 2001:db8:ff:f8:: user@host# set interface ps3.0 shared-key pskey-3.0-def-43 user@host# set no-advertise-routes-on-backup
Em seguida, configure o seguinte em um BNG de peer. Observe que o ps5.0 neste BNG compartilha a mesma chave que o ps2.0 no outro. Isso significa que ps2.0 e ps5.0 são as interfaces de acesso associadas para redundância pseudowire. Da mesma forma, as interfaces associadas ps3.0 e ps4.0 têm a mesma chave compartilhada entre si.
[edit system services subscriber-management redundancy] user@host# set protocol pseudo-wire user@host# set interface ps4.0 local-inet-address 10.55.3.0 user@host# set interface ps4.0 local-inet6-address 2001:db8:1C:44:: user@host# set interface ps4.0 shared-key pskey-3.0-def-43 user@host# set interface ps5.0 local-inet-address 10.60.20.1 user@host# set interface ps5.0 local-inet6-address 2001:db8:01:10:cd:: user@host# set interface ps5.0 shared-key pskey-2.0-abc-215 user@host# set no-advertise-routes-on-backup
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.