Redundância de assinantes M:N no BNG

Benefícios da redundância de assinantes M:N no BNG

• Oferece uma redundância leve de assinantes na camada de aplicativos. 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 hot-standby.

• Vários BNGs atuam como o BNG ativo para um ou mais grupos de redundância de assinantes e como o BNG de backup para outros grupos de redundância de assinantes 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 oferece redundância 1:1 e é mais usado em implantações centralizadas.

• A redundância M:N com a descoberta de topologia de leasing ativo DHCP protege os assinantes de vários pontos únicos de falha de hardware e software diferentes. Isso inclui falhas no acesso (voltados para assinantes) ou links voltados para o núcleo e em um módulo de interface de acesso ou chassi. Ela também protege contra falhas parciais de rede de acesso e de rede central parcial.

• Você pode habilitar ou desabilitar a redundância de M:N para assinantes que estejam ativos. Se você remover a configuração de redundância, os assinantes que tiveram a configuração permanecem intactos nos BNGs primários e de backup.

• Você pode implantar 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 semredundancy. Isso significa que você não precisa ter BNGs dedicados à redundância de assinantes.

• Você pode configurar assinantes de redundância M:N em tempo de execução, mesmo após os assinantes estarem UP. Isso é útil para atualizações de software, porque você pode migrar assinantes para backup de BNGs e, em seguida, atualizar o software.

Fundamentos da redundância M:N

Nota:

Para simplificar, a maior parte da explicação da redundância de 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 (M) grupos de assinantes em um determinado chassi BNG podem ser apoiados em vários (N) destinos diferentes de chassi. Nós nos referimos a esses grupos como grupos de redundância de assinantes.

Um grupo de assinantes é formado por todos os assinantes que atendem aos seguintes critérios:

• (VLANs estáticas) Os assinantes pertencem a um VLAN estático específico e usam a mesma interface de acesso lógica, como ge-1/0/10/1. Um dispositivo de acesso, como um switch, DSLAM ou OLT, agrega os assinantes à VLAN comum.

• (VLANs dinâmicas) Os assinantes pertencem à mesma VLAN dinâmica e usam a mesma interface de acesso físico, como a ge-1/0/0.

• (Ip demux estático) Todos os assinantes têm um endereço IP de origem que corresponde à sub-rede configurada.

Quando você configura redundância para um grupo de assinantes, ela se torna um grupo de redundância de assinantes. Um determinado grupo de redundância de assinantes usa apenas um BNG de cada vez. Chamamos esse BNG de primário. Para cada grupo de redundância de assinantes, apenas um dos outros BNGs atua como um backup no modo hot-standby. Quando um dos erros listados na Tabela 1 ocorre para o BNG primário, ele falha no BNG de backup apropriado para o grupo de redundância afetado. Este BNG de backup é agora o novo BNG primário para esse grupo. Todas as sessões de assinantes ativas para esse grupo de redundância de assinantes 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/backup M:N. Ele mostra cinco BNGs em uma topologia primária/backup M:N em que cada BNG tem uma relação com todos os outros BNG. Se o BNG 1 for o principal, você pode configurar BNG 2, 3, 4 e 5 como o BNG de backup para diferentes grupos de redundância de assinantes. Se o BNG 2 for o principal, você pode configurar BNG 1, 3, 4 e 5 como o BNG de backup, etc.

Para a redundância de M:N, é importante entender que você pode configurar:

• Apenas um BNG de backup para cada grupo de redundância de assinantes.

• 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 falha no roteador de backup que você configura para cada um de seus grupos de redundância. As sessões de assinantes para todos os grupos de redundância no BNG primário são mantidas em todos os BNGs de backup que se tornam novas primárias 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 transmissão DHCP hospedados em três BNGs. Os BNGs podem estar diretamente conectados entre si ou conectados pelas redes de acesso ou núcleo.

• O agente de retransmissão RA1 está configurado para grupos de redundância de assinantes, SRG 1 e SRG 2 e grupo de assinantes SG A.

• O agente de retransmissão RA2 está configurado para SRG 2 e SRG 3.

• O agente de retransmissã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 no RA1 e RA3.

• O SRG 2 pode estar ativo ou com backup no RA1 e RA2.

• O SRG 3 pode estar ativo ou com backup no RA2 e RA3.

• SG A e SG B não têm backup.

Agora considere a Figura 4, que mostra a mesma topologia, mas indica qual BNG é primário e qual é o backup para cada grupo de redundância. O BNG hosting RA 1 é o BNG principal para SRG 1 e SRG 2.

Se este BNG falhar, ele falha em um BNG de backup diferente para SRG 1 e SRG 2, como mostrado na Figura 5.

• Para o SRG 1, ele falha com o BNG hospedando RA 3. O RA 3 BNG torna-se o novo principal para o SRG 1.

• Para o SRG 2, ele falha com o BNG hospedando RA 2. O RA 2 BNG torna-se o novo principal para o SRG 2.

A falha não afeta o SRG 3.

Sessões para assinantes e modo hot standby

Cada BNG de backup está no modo hot-standby para seu BNG primário correspondente para cada grupo de redundância de assinantes no backup. Isso significa que o BNG de backup está pronto para assumir o controle do BNG primário imediatamente e sem interrupções quando ocorre um failover. Os seguintes comportamentos do BNG principal e backup permitem que o modo hot-standby funcione.

• As ligações de assinantes e o estado do assinante são espelhados sincronizadamente para o BNG de backup, assim como as informações primárias de ARP do BNG e descoberta de vizinhos. Cada assinante é criado 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 realiza nenhum processamento de assinantes 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, a primária 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 link voltado para o núcleo ainda estiver funcionando ou se o chassi ainda estiver funcionando. Se o link voltado para o núcleo estiver desativado ou todo o chassi estiver desativado, a rede primária com falha não poderá enviar uma mensagem de parada de contabilidade ou CCR-T.

  Quando o BNG de backup se torna primário, ele não envia uma mensagem de Início de Contabilidade ou CCR-I porque os assinantes estão ativos em todo o failover. As estatísticas contábeis aumentam a partir das novas primárias.

• Durante o login inicial do assinante, o BNG adiciona rotas de assinantes à 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 central. Após o failover, a primária com falha não adiciona nem propaga nenhuma rota. Como alternativa, você pode configurar as rotas de assinante a serem anunciadas ou retiradas do núcleo com base na função primária do BNG para que não haja perda de tráfego como resultado do failover.

Nota:

A sincronização de estado se aplica apenas ao estado do assinante. O estado de serviço não está sincronizado. Dependendo da configuração de seus serviços, o BNG pode anexar serviços para os assinantes tanto em assinantes ativos quanto em backup. Como alternativa, os serviços podem se recolocar após o failover no novo BNG ativo.

Nota:

A redundância de assinantes M:N não sincroniza as estatísticas contábeis do BNG primário ao 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 aumentar a partir do novo primário e param de aumentar das primárias com falha. Dependendo da gravidade da falha, os failovers podem resultar em perda de informações contábeis.

M:N Redundância usando protocolo de redundância de roteador virtual (VRRP)

Você pode usar 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 endereço MAC compartilhado por dois BNGs em um grupo VRRP (às vezes referido como uma 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 assinantes que está conectada à rede de acesso.

O endereço IP virtual torna-se o endereço de gateway padrão para os BNGs do grupo. Apenas o BNG atuando como primário 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 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 poucos segundos.

Nota:

A solução VRRP para redundância de M:N é direcionada para um modelo de acesso ao assinante N:1 que usa interfaces lógicas estáticas subjacentes.

Para obter informações detalhadas sobre como o VRRP funciona em geral, veja Entenda o VRRP e o tópico relacionado no Guia do usuário de alta disponibilidade.

Você configura diferentes prioridades para os dois roteadores em um grupo VRRP para determinar qual roteador o grupo elege ser o principal:

1. O roteador com maior prioridade 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.

2. Quando a primária 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 afeta o tráfego de dados.

3. Quando o primário original volta on-line, o protocolo determina que ele tem uma prioridade maior do que o backup primário atual (backup anterior). A primária original então retoma o papel principal sem efeito no tráfego de dados.

   Nota:

   Ao usar VRRP para redundância de assinantes M:N, o número de grupos de redundância de assinantes se limita ao número de sessões VRRP suportadas no dispositivo. Para dual stack, 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 amostra com dois BNGs e a configuração para as interfaces correspondentes em cada roteador:

• As duas interfaces lógicas estão na mesma VLAN (1).

• Os endereços de 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 maior prioridade (254) é eleito primário; o BNG com a menor prioridade (200) é o 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 assinantes.

A topologia inclui três grupos de redundância de assinantes (M), SRG 1, SRG 2 e SRG 3 em três BNGs (N). Cada grupo de redundância de assinantes corresponde a um grupo VRRP diferente. As setas indicam o roteador principal e o roteador de backup para cada grupo

• Para o SRG 1, o BNG 1 tem a maior prioridade, 250. O BNG 3 tem uma prioridade menor, 200. Isso significa que o BNG 1 é o principal para O SRG 1 e BNG 3 é o backup, de modo que o BNG 1 falha no 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 o SRG 2, o BNG 1 também tem a maior prioridade, a 180, e é a principal. O BNG 2 tem uma prioridade menor, 150, e é o backup.

• Para o SRG 3, o BNG 2 tem a maior prioridade, 100, e é o principal. O BNG 3 tem uma prioridade menor, 75, e é o backup.

Tempo de failover e reversão de VRRP

Usando a configuração de redundância mostrada na Figura 7, suponha que o BNG 1 falha no BNG 3 para SRG 1, de modo que o BNG 3 seja a nova principal para o grupo. A função primária é revertida automaticamente para BNG 1 quando ela é novamente ativa. Se a conexão entre os dois BNGs estiver por toda a rede de acesso (em comparação com uma ligação direta entre os BNGs), os estados assinantes podem não ser sincronizados entre os dois BNGs quando a função primária reverter. O estado VRRP é independente da sincronização ativa de leasingquers DHCP.

Quando o link de acesso no BNG 1 é restaurado, o leasing ativo DHCP restaura a conexão para sincronização de assinantes entre os BNGs. O DHCP começa a ressincronizar o estado do assinante e as informações vinculativas 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 primária reverter para BNG 1 antes que a ressincronização seja concluída. Por exemplo, as estatísticas contábeis para assinantes que fazem login não são adicionadas ao banco de dados até que a ressincronização seja concluída. As mensagens de logotipo para assinantes que fazem login não são processadas até que a sincronização esteja acabada e os assinantes sejam recuperados no BNG 1.

Você pode mitigar esses efeitos configurando o temporizador de espera VRRP (em algum momento chamado de temporizador reversivo) para que a ressincronização seja concluída antes que a primária original retome a função primária. Use a hold-time declaração no nível hierárquico [edit interfaces] .

Melhores práticas:

Recomendamos que você configure a redundância VRRP no modo não reversivo quando estiver operando em alta escala. Para sistemas que não operam em escala, você pode usar o modo não reversivo ou configurar o temporizador de espera VRRP (em algum momento chamado de temporizador reversivo) com valores altos o suficiente para que a ressincronização seja concluída antes que a primária original retome a função primária.

M:N Redundância usando redundância pseudowire

A partir do Junos OS Release 20.1R1, você pode usar redundância pseudowire para fornecer redundância M:N quando a rede de acesso consiste em circuitos de Camada 2 (L2) em IP/MPLS. Nesse tipo de rede de acesso, o LDP é o protocolo de sinalização que distribui rótulos entre vizinhos de 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 mistura heterogênea de dispositivos L2 ou L3.

Nota: Ao usar a redundância pseudowire para redundância de assinantes M:N, o número de grupos de redundância de assinantes é limitado ao número de interfaces de assinantes pseudowire suportadas no dispositivo.

A Figura 8 mostra uma topologia simples em que nós de acesso agregam tráfego e o enviam por toda a rede a um agente de retransmissão DHCP no BNG primário. A configuração de redundância pseudowire especifica um pseudowire ativo (para o BNG primário) e um pseudowire de backup (para o BNG de backup).

Para circuitos L2, você configura os pseudowires como interfaces subjacentes (voltadas para o acesso) nos BNGs. Em seguida, você configura as interfaces com conexões L2, como Ethernet, VLANs dinâmicas de sentido automático ou VLANs estáticas. As interfaces pseudowire voltadas para o cliente DHCP são empacotadas 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, listas de interfaces VLAN e interfaces físicas.

Um circuito L2 é executado entre dois vizinhos L2; neste 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 MPLS (LSP). Você constrói o circuito configurando-o em uma interface em cada vizinho:

• No BNG, você especifica o nó de acesso como vizinho e uma interface pseudowire local no BNG que termina o circuito L2.

• No nó de acesso, você especifica o BNG como um vizinho e uma interface local voltada para clientes no nó que é da outra ponta do circuito L2.

• Tanto no BNG quanto no nó de acesso, você configura um identificador de circuito virtual exclusivo (VCI) que distingue esse circuito L2 entre todos os outros circuitos L2 que terminam no dispositivo.

Esse circuito L2 é agora o pseudowire primário para o BNG. Para estabelecer redundância, você configura o pseudowire de backup no nó de acesso. Na mesma interface local, você especifica outro BNG como vizinho de backup e especifica que o pseudowire de backup está no modo hot-standby.

O modo hot-standby garante que o vizinho de backup esteja totalmente pronto para assumir o cargo principal 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 espera remoto (RS) no BNG de backup. (Você pode usar o show l2circuit connections brief comando para visualizar o estado do circuito.) Você deve configurar suas políticas de rota para que as rotas de sub-rede para este grupo de redundância sejam anunciadas apenas no BNG primário. Isso garante que apenas o principal receba tráfego downstream.

O LDP tem um mecanismo keepalive para detectar falhas. Uma falha resulta em falhas no circuito L2, desde o pseudowire primário e o BNG primário até o pseudowire de backup e o BNG de backup. Quando detecta uma falha, o LDP muda o circuito do LSP primário (no pseudowire primário) para o LSP de backup (no pseudowire de backup). O BNG de backup assume o papel principal e seu estado faz a transição para Up.

Quando o primário antigo estiver funcionando novamente, as mesmas considerações sobre a sincronização aplicam-se à redundância pseudowire como fazem quando o VRRP é o método de redundância.

Melhores práticas:

Recomendamos que você configure a redundância de pseudowire no modo não reversivo quando estiver operando em alta escala. Para sistemas que não operam em escala, você pode usar o modo não reversivo ou configurar o revert-time intervalo na interface de nó de acesso com valores altos o suficiente para que a ressincronização seja concluída antes que a primária original retome a função primária.

DhCP Active Leasequery Topology Discovery e redundância de assinantes M:N

Para assinantes DHCP, o leasing ativo DHCP e a descoberta de topologia permitem que o estado do assinante e as informações vinculativas sejam sincronizadas entre agentes de transmissão DHCP peer para todos os grupos de redundância de assinantes nos pares. Isso permite que os leasings e o tráfego de dados continuem sem interrupções, tanto quando o BNG primário falha no backup quanto quando ele retoma o papel principal.

Embora você configure a redundância primária/backup de nível de interface para pares de BNGs, ela também corresponde de forma aos agentes de retransmissão DHCP hospedados nos BNGs primários e de backup. Você pode pensar no agente de retransmissão DHCP no BNG primário como sendo o principal agente de retransmissão para um grupo de redundância de assinantes. Da mesma forma, você pode pensar no agente de retransmissão DHCP no BNG de backup para um grupo como sendo o agente de retransmissão de backup para o grupo.

Cada agente de retransmissão que você configura com a topologia discovery troca mensagens com seus pares ativos de leasing configurados para determinar o nome das interfaces de acesso em seus pares de agentes de retransmissão que correspondem e se conectam com suas próprias interfaces de acesso locais. As interfaces de acesso são as interfaces usadas pelos grupos de redundância de assinantes.

1. Quando um agente de retransmissão envia uma mensagem de consulta de descoberta de topologia para um peer, essa mensagem inclui opções de DHCP que especificam o nome da interface de acesso (Agent Circuit ID), a sub-rede/máscara para a interface e o ID VLAN para o grupo de redundância. O DHCP também gera um ID de transação aleatória para a troca que é transmitida no cabeçalho do pacote. A ID da transação é exclusiva para essa interface de acesso.

2. O agente de retransmissão por pares receptor usa a sub-rede/máscara e o ID VLAN para determinar se ele tem uma interface de acesso local para esses valores. Se isso acontecer, o peer envia uma resposta de descoberta de topologia por essa interface para a interface de acesso do agente de retransmissão de consulta. A mensagem de resposta inclui a sub-rede/máscara, O ID de VLAN e o ID de transação que recebeu na consulta.

3. O agente de retransmissão de consulta verifica se a ID da transação na resposta corresponde à interface de acesso onde ela recebeu a resposta. O ID da transação na resposta deve corresponder ao que ele enviou ao peer para essa interface de acesso. Se a ID da transação for igual, o agente de retransmissão pode então adicionar uma entrada à sua tabela de tradução para associar as duas interfaces vinculadas.

4. O agente de consulta repete esse processo para cada uma de suas interfaces de acesso locais.

A Figura 9 mostra essa consulta e resposta para dois BNGs quando você usa redundância VRRP. O BNG 1 envia a consulta para sua interface de acesso, ge-10/1/2, para BNG 2 por meio da conexão TCP. O BNG 2 responde pela conexão UDP por meio de sua interface associada, ge-2/3/9.

O BNG 2 envia uma consulta para sua interface de acesso ao BNG 1 por meio da conexão TCP. O BNG 1 responde pela conexão UDP por meio de sua interface associada ge-10/1/2.

A Figura 10 mostra uma consulta e resposta para dois agentes de transmissão DHCP em BNGs quando você usa redundância pseudowire. O R1 envia a consulta para sua interface de acesso, ps2.0, para BNG 2 por meio da conexão TCP. O R2 responde pela mesma conexão TCP. O R2 também envia uma consulta ao R1, para sua interface de acesso, ps5.0. O R1 responde a essa consulta por meio da conexão TCP. A descoberta de topologia para redundância de pseudowire usa uma chave comum compartilhada e configurada estaticamente entre pares BNG como critérios de correspondência. Isso contrasta com a redundância VRRP, onde a correspondência é realizada em sub-rede/máscara e ID VLAN.

Cada agente de peer envia consultas a seus pares para que ele possa construir sua própria tabela de tradução de interfaces de acesso local e remota correspondentes. Dessa forma, todos os agentes de retransmissão que você configura tanto como pares quanto para a descoberta de topologia aprendem o conjunto completo de interfaces de acesso remoto para suas interfaces locais. As tabelas de tradução permitem que os pares sincronizam as informações dos assinantes adequadamente para cada grupo de redundância de assinantes.

Após a descoberta da topologia ser concluída, o leasing ativo realiza a sincronização do assinante. O leasing ativo realiza suas consultas por giaddr (DHCPv4) ou linkaddr (DHCPv6). Esse tipo de consulta garante que o DHCP sincroniza apenas as informações para assinantes em um grupo de redundância para cada interface.

Você não pode configurar esse tipo de consulta; é uma função de configurar a descoberta de topologia. Quando você configura a descoberta de topologia, a presença de id por consulta por retransmissão e giaddr na opção DHCPv4 82 ou linkaddr na DHCPv6 Option 18 é interpretada como uma consulta por giaddr ou uma consulta por linkaddr, respectivamente.

O agente de retransmissão usa a interface de acesso como valor para o campo de endereço IP de gateway (giaddr ou linkaddr) quando envia pacotes para o servidor local em nome de um cliente. O servidor local retorna o giaddr/linkaddr quando ele responde ao agente de retransmissão. O agente de retransmissão então usa esse valor para determinar para onde enviar as informações downstream. O giaddr/linkaddr mostra que o pacote foi enviado para uma interface lógica de acesso específica, de modo que o agente de transmissão encaminha as informações para o cliente DHCP nessa interface.

O que isso significa para a redundância de assinantes é que, usando a consulta giaddr ou linkaddr, o leasing ativo solicita apenas informações para assinantes nessa interface de acesso. Consequentemente, sincroniza apenas as informações de assinante do agente de retransmissão principal para o agente de retransmissão de backup. Este é um conjunto muito menor de assinantes do que se o leasingquery ativo utilizasse o método de consulta por id de transmissão, que devolveria informações para todos os assinantes em todo o chassi.

O resultado desse processo é que cada agente peer instala os assinantes para cada grupo de redundância que lida. Quando o agente principal de BNG/retransmissão falha, o backup já tem as informações necessárias para o assinante manter a sessão sem interrupção.

Descoberta de topologia de exemplo com redundância VRRP

A Figura 11 mostra uma topologia simples em que o leasing ativo com descoberta de topologia é configurado para os pares do agente de retransmissão DHCP em dois BNGs conectados pela rede de acesso. Os endereços peer configurados são 192.0.2.1 e 192.0.2.2. Usaremos esta ilustração para entender como a descoberta de topologia funciona quando você configura VRRP como o protocolo de redundância e como as tabelas de tradução são construídas para cada agente de retransmissão de pares.

1. Após a sincronização do TCP, o peer 192.0.2.1 envia uma consulta de descoberta de topologia ao peer 192.0.2.2 para determinar a interface remota correspondente para sua própria interface local, ge-10/1/2.0. Como esta é uma topologia DHCPv4, a mensagem que ela envia é um DHCPLEASEQUERY. A consulta é enviada pela conexão TCP e inclui as seguintes informações:

   • O endereço e a máscara de sub-rede IP (203.0.113.1/24) da interface de acesso local, transmitidos na DHCPv4 Option 43, subopção 2.

   • O VLAN ID (10) que está configurado na interface de acesso, transmitido na DHCPv4 Option 43, subopção 4.

   • Uma ID de transação temporária ou xid (15), transmitida no cabeçalho do pacote. O DHCP gera um xid aleatório para cada interface de acesso. O xid é único em todo o chassi.

   Também incluído na consulta, mas não mostrado na figura:

   • O identificador do cliente, transmitido na DHCPv4 Option 61.

2. O Peer 192.0.2.2.2 recebe a consulta e corresponde ao endereço de sub-rede, máscara e ID VLAN recebidos a uma de suas interfaces de acesso locais. Neste caso, a combinação é a interface ge-2/3/9.0.

3. O Peer 192.0.2.2 envia uma resposta de volta ao peer 192.0.2.1 sobre a conexão UDP por meio de sua interface de acesso correspondente, ge-2/3/9.0. A resposta é uma mensagem DHCPLEASEACTIVEACTIVE e inclui as seguintes informações:

   • O endereço e a máscara de sub-rede IP (203.0.113.2/24) da interface de acesso local, transmitido na DHCPv4 Option 43, subopção 2.

   • O VLAN ID (10) que está configurado na interface de acesso, transmitido na DHCPv4 Option 43, subopção 4.

   • O nome da interface de correspondência (ge-2/3/9.0), transmitido na Opção 82.

   • A mesma ID de transação temporária que recebeu na consulta, transmitida no cabeçalho de IP.

   As informações a seguir também estão incluídas na resposta, mas não são mostradas na figura:

   • O identificador de clientes, com o mesmo valor que o recebido na consulta, na Opção DHCPv4 61.

   • O identificador de servidor, na DHCPv4 Option 54.

   • O endereço de destino IP no cabeçalho ip. Este é o endereço de sub-rede recebido do peer 192.0.2.1 (203.0.113.1/24).

   • O endereço de origem IP no cabeçalho IP. Este é o endereço de sub-rede (203.0.113.2/24) para este agente de retransmissão para a interface de correspondência (ge-2/3/9,0).

4. O Peer 192.0.2.1 recebe a resposta por meio de sua interface de acesso. Ele confirma que a ID de transação da resposta corresponde à que ela enviou na consulta. O ID da transação e as subopções específicas do fornecedor recebidas na resposta fornecem ao agente de retransmissão as informações de que precisa para mapear as duas interfaces de acesso em sua tabela de tradução.

O Peer 192.0.2.2 realiza as mesmas quatro etapas para que possa atualizar sua própria tabela de tradução. Cada um dos pares associados inicia a descoberta de topologia para todas as suas interfaces de acesso locais. Dessa forma, cada peer constrói uma tabela de tradução completa para todas as suas interfaces.

A Figura 11 mostra a tabela de tradução para cada peer que resulta da troca de mensagens entre cada par de pares:

• O agente de retransmissão do BNG 1 inicia a descoberta de topologia para suas três interfaces de acesso.

• O agente de retransmissão do BNG 2 inicia a descoberta de topologia para suas três interfaces de acesso.

• O agente de retransmissão do BNG 3 inicia a descoberta de topologia para suas duas interfaces de acesso.

Nota:

Como o ID da transação é gerado para apenas uma interface de acesso, a descoberta de topologia é bem sucedida mesmo quando várias interfaces compartilham a mesma sub-rede e ID VLAN.

Por exemplo, suponha que duas interfaces no peer 192.0.2.2 (ge-2/3/9 e ge-11/0/7) correspondam à sub-rede e ao ID VLAN que ela recebeu na consulta.

Este agente de retransmissão envia uma resposta separada de cada uma dessas interfaces para interfaces peer 192.0.2.1 ge-10/1/2.0 e ge-4/2/3.0. O ID da transação não combina com a interface ge-4/2/3.0 porque o peer de consulta (192.0.2.1) gerou o ID para interface ge-10/1/2.0. Consequentemente, a consulta por peer atualiza sua tabela de tradução apenas para interface ge-10/1/2.0.

Para obter informações detalhadas sobre o leasing ativo DHCP, a descoberta de topologia e como ele funciona com a redundância de assinantes M:N, consulte DHCP Active Leasequery e Configurando e usando o DHCP Active Leasequery. A seção Topology Discovery Messages no DHCP Active Leasequery fornece descrições das informações e opções realizadas nas mensagens de consulta e resposta DHCP.

Descoberta de topologia de exemplo com redundância pseudowire

A Figura 12 mostra uma topologia simples em que o leasing ativo com descoberta de topologia é configurado para os pares do agente de retransmissão DHCP em dois BNGs conectados por uma rede de acesso IP/MPLS. Os endereços peer configurados são 198.51.100.1 e 198.51.100,5. Usaremos esta ilustração para entender como a descoberta de topologia funciona quando a rede de acesso usa túneis pseudowire na rede IP/MPLS. A descoberta de topologia para redundância de pseudowire usa uma chave comum compartilhada e configurada estaticamente entre pares BNG como critérios de correspondência. Isso contrasta com a redundância VRRP, onde a correspondência é realizada em sub-rede/máscara e ID VLAN. Este exemplo também descreve como as tabelas de tradução são construídas para cada agente de retransmissão de pares.

Nota:

A topologia mostra apenas uma conexão TCP, porque a redundância pseudowire M:N não usa UDP para descoberta de topologia. Em contraste, a redundância de VRRP M:N usa conexões TCP e UDP.

1. Após a sincronização do TCP, o peer 198.51.100.1 envia uma consulta de descoberta de topologia ao peer 198.51.100.5 para determinar a interface remota correspondente para sua própria interface local, ps2.0. Como esta é uma topologia DHCPv4, a mensagem que ela envia é um DHCPLEASEQUERY. A consulta é enviada pela conexão TCP e inclui as seguintes informações:

   • A chave comum compartilhada (PseudoWireKey-100.1) configurada na interface local, transmitida na DHCPv4 Option 43, subopção 6.

   • Uma ID de transação temporária ou xid (15), transmitida no cabeçalho do pacote. O DHCP gera um xid aleatório para cada interface de acesso. O xid é único em todo o chassi.

   Também incluído na consulta, mas não mostrado na figura:

   • O identificador do cliente, transmitido na DHCPv4 Option 61.

2. O Peer 198.51.100.5 recebe a consulta e corresponde à chave comum compartilhada recebida para uma de suas interfaces de acesso locais. Neste caso, a combinação é interface ps5.0.

3. O Peer 198.51.100.5 envia uma resposta sobre a conexão TCP de volta ao peer 198.51.100.1. A resposta é uma mensagem DHCPLEASEACTIVEACTIVE e inclui as seguintes informações:

   • A chave comum compartilhada (PseudoWireKey-100.1) que ela recebeu na consulta, transmitida na DHCPv4 Option 43, subopção 6.

   • A mesma ID de transação temporária que recebeu na consulta, transmitida no cabeçalho de IP.

   • O nome da interface de correspondência (ps5.0), transmitido na Opção 82.

   As informações a seguir também estão incluídas na resposta, mas não são mostradas na figura:

   • O identificador de clientes, com o mesmo valor que o recebido na consulta, na Opção DHCPv4 61.

   • O identificador de servidor, na DHCPv4 Option 54.

4. O Peer 198.51.100.1 recebe a resposta pela conexão TCP em banda. Ele confirma que a ID de transação da resposta corresponde à que ela enviou na consulta. O ID da transação e as subopções específicas do fornecedor recebidas na resposta fornecem ao agente de retransmissão as informações de que precisa para mapear as duas interfaces de acesso (interface local ps2.0 e interface remota ps5.0) em sua tabela de tradução.

Cada um dos pares associados em uma topologia inicia a descoberta de topologia para cada uma de suas interfaces de acesso locais. Cada peer usa as mesmas quatro etapas descritas acima para construir uma tabela de tradução completa que mapeia suas interfaces locais com interfaces de peer. Neste exemplo de topologia, isso significa:

• O agente de retransmissão DHCP (R1) no BNG 1 inicia a descoberta de topologia para suas duas interfaces de acesso, ps2.0 e ps3.0.

• O agente de retransmissão DHCP (R2) no BNG 2 inicia a descoberta de topologia para suas duas interfaces de acesso, ps4.0 e ps5.0.

Você pode ver a tabela de tradução para cada peer que resulta da troca de mensagens entre o par de pares na Figura 12. A mesma chave comum compartilhada está configurada em ambas as interfaces pseudowire para cada par. Por exemplo, o ps2.0 e o ps5.0 têm a chave PseudoWireKey-100.1. As interfaces ps3.0 e ps4.0 compartilham uma chave diferente (não mostrada na figura).

Agora considere a topologia um pouco mais complexa ,com três pares, mostrada na Figura 13. Três agentes de transmissão DHCP em três BNGs realizam a descoberta de topologia para suas interfaces pseudowire. As tabelas de tradução resultantes são mostradas abaixo de cada agente de retransmissão.

Compare as tabelas de tradução e as linhas de conexão pseudowire coloridas na Figura 13 com os trechos de configuração de chave compartilhada para cada agente de retransmissão na Figura 14.

Você pode ver que a interface ps1.0 no R1 tem a mesma chave compartilhada que a interface ps8.0 na R3. As tabelas de tradução para R1 e R3 mostram que essa relação foi descoberta pelo processo de descoberta de topologia.

Da mesma forma, a interface ps2.0 no R1 e ps5.0 no R2 têm a mesma chave compartilhada. Mais uma vez, a descoberta de topologia determinou essa nave de relação e cada agente atualizou sua tabela de tradução de acordo. As outras linhas nas tabelas de tradução foram povoadas da mesma forma.

Para obter informações detalhadas sobre o leasing ativo DHCP, a descoberta de topologia e como ele funciona com a redundância de assinantes M:N, consulte DHCP Active Leasequery e Configurando e usando o DHCP Active Leasequery. A seção Topology Discovery Messages no DHCP Active Leasequery fornece descrições das informações e opções realizadas nas mensagens de consulta e resposta DHCPv4 e DHCPv6.

Assinantes estáticos e redundância de M:N

A redundância de assinantes M:N oferece suporte a duas categorias de assinantes:

• Assinantes que usam o protocolo de cliente DHCP em uma VLAN estática. Este é o tipo de assinante mais comum para redundância de assinantes M:N.

• Assinantes em interfaces estáticas que não estão executando um protocolo de cliente. Esse tipo de assinante é típico de empresas de pequeno a médio porte que têm seu próprio endereço IP estático e não usam nada como DHCP.

Os assinantes estáticos consistem nos seguintes tipos:

• Assinantes estáticos baseados em VLAN — você cria assinantes além 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 de demux ip 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 do JSSCD.

Os trechos de configuração de amostra a seguir mostram como criar um grupo de assinantes estático com duas interfaces configuradas para VRRP em um BNG primário e um BNG de backup. Uma interface é uma interface de demux IP e a outra é uma interface VLAN. A configuração mostra como o VRRP está configurado em cada interface.

Configuração primária de BNG:

1. O trecho a seguir configura a interface subjacente para a interface lógica de IP demux, ge-1/1/9.11. Ele especifica o ID de VLAN como 11. A sub-rede da interface de acesso está definida para 203.0.113.1/24. A configuração vrrp nesta sub-rede define o grupo (o grupo de redundância de assinantes) para 11 e especifica o endereço para o roteador virtual. O roteador virtual consiste nos BNGs primários e de backup para este grupo de redundância de assinantes. A prioridade do VRRP é o 230. Quando o principal falha no backup, a suposição da função primária pelo backup é adiada em 30 segundos.

2. O trecho a seguir configura a interface lógica VLAN, ge-1/1/9.20. Ele especifica o ID de VLAN como 20. A sub-rede de interface de acesso está definida para 192.0.2.1/24. A configuração vrrp nesta sub-rede define o grupo (o grupo de redundância de assinantes) para 20 e especifica o endereço para o roteador virtual. O roteador virtual consiste nos BNGs primários e de backup para este grupo de redundância de assinantes. A prioridade do VRRP é o 230. Quando o principal falha no backup, a suposição da função primária pelo backup é adiada em 30 segundos.

3. O trecho a seguir configura a interface lógica de ip demux, demux0.1, pela 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 IP seja derivado da interface de loopback.

4. O trecho a seguir configura um grupo de assinantes estático, estático-ifl, que inclui tanto a interface de assinante estático ip demux (demux0.1) quanto 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 do usuário.

5. O trecho a seguir configura um perfil de acesso para o grupo de assinantes estáticos.

Configuração de BNG de backup:

Nota:

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 principal e backup.

• A prioridade do VRRP está definida para 200 para ambas as interfaces. Esse valor faz disso o BNG de backup, porque é menor do 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.

1. O trecho a seguir configura a interface subjacente para a interface lógica ip demux, ge-3/0/1.11. Ele especifica o ID de VLAN como 11. A sub-rede de interface de acesso está definida para 203.0.113.2/24. A configuração vrrp nesta sub-rede define o grupo (o grupo de redundância de assinantes) para 11 e especifica o endereço para o roteador virtual. O roteador virtual consiste nos BNGs primários e de backup para este grupo de redundância de assinantes. A prioridade do VRRP é o 200. Quando o principal falha no backup, a suposição da função primária pelo backup é adiada em 30 segundos.

2. O trecho a seguir configura a interface lógica VLAN, ge-3/0/1,20. Ele especifica o ID de VLAN como 20. A sub-rede da interface de acesso está definida para 192.0.2.2/24. A configuração vrrp nesta sub-rede define o grupo (o grupo de redundância de assinantes) para 20 e especifica o endereço para o roteador virtual. O roteador virtual consiste nos BNGs primários e de backup para este grupo de redundância de assinantes. A prioridade do VRRP é o 200. Quando o principal falha no backup, a suposição da função primária pelo backup é adiada em 30 segundos.

3. O trecho a seguir configura a interface lógica de IP demux, demux0.1, pela 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 IP seja derivado da interface de loopback.

4. O trecho a seguir configura um grupo de assinantes estático, estático-ifl, que inclui tanto a interface de assinante estático ip demux (demux0.1) quanto 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 do usuário.

5. O trecho a seguir configura um perfil de acesso para o grupo de assinantes estáticos.

Convergência e redundância de assinantes M:N

Convergência é o processo em que os roteadores em uma rede atualizam suas tabelas de roteamento individuais quando as rotas em qualquer roteador são adicionadas, removidas ou não mais acessáveis por causa de uma falha no link. Os protocolos de roteamento nos roteadores anunciam as mudanças de rota em toda a rede. Como cada roteador recebe as atualizações, ele recalcula as rotas e depois 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 para cima ou para baixo, 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 assinantes M:N oferece suporte à convergência de rotas do lado de acesso (upstream) e do lado central (downstream). Como cada assinante está ativo simultaneamente nas primárias e nos BNGs de backup, a convergência de tráfego pode ser muito rápida. No entanto, a convergência de rota é o melhor esforço e depende do grau de failover; ou seja, se ocorre uma falha parcial ou completa do chassi.

Cabe a você determinar como gerenciar a convergência de tráfego upstream e downstream para sua rede após um failover desde o BNG primário até 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

Propósito

Determine informações de status e estatísticas para interfaces de acesso, agentes de retransmissão e assinantes que fazem parte de sua topologia para redundância de M:N com a descoberta de topologia de leasing ativo DHCP.

Ação

• Para verificar o estado de redundância VRRP de interfaces de acesso:

• Para verificar se o estado de redundância de uma interface lógica de acesso especificada está Master no agente de retransmissão principal e Backup no agente de retransmissão de backup:

  Essa interface pode ser uma interface de assinante ou a interface VLAN subjacente. Para redundância vrrp, o estado de redundância é o mesmo que o estado VRRP da interface lógica subjacente. Para redundância de pseudowire, o estado de redundância é baseado no estado da interface pseudowire.

• Para verificar se os assinantes de um grupo de redundância estão ativos nos agentes primários e de retransmissão de backup:

  O show subscribers comando tem várias opções; você pode exibir assinantes por endereço IP, nome da interface, ID de VLAN, ID do Circuito do Agente, estado do assinante e assim por diante.

• Verificar se as informações de ligação de transmissão de DHCP são as mesmas para os assinantes em um grupo de redundância nos agentes primários e de retransmissão de backup:

  Você também pode especificar resultados para um endereço IP ou uma interface.

• Para ver uma lista de todos os pares de leasing ativos:

• Para ver a tabela de tradução de descoberta de topologia para um agente de retransmissão por pares, incluindo os IDs de circuito local e remoto (interfaces de acesso), endereço de interface de acesso local, ID de transações (xid) e o estado de descoberta de topologia, redundância e sincronização de assinantes:

• Para ver estatísticas ativas de leasingquery, como o número de vinculações DHCP enviadas ou recebidas para uma interface ou peer.

• Para limpar as estatísticas ativas do leasingquery.