Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
NESTA PÁGINA
 

Visão geral das redes de acesso ao assinante PPP

Visão geral de perfis dinâmicos para interfaces de assinantes PPP

O suporte a PPP de gerenciamento de assinantes permite que você crie e anexe perfis dinâmicos para interfaces de assinantes PPP. Quando o assinante PPP faz login, o roteador instancia o perfil dinâmico especificado e depois aplica os atributos definidos no perfil à interface.

Perfis dinâmicos são usados para interfaces PPP estáticas e dinâmicas. Para interfaces PPP estáticas, você usa o CLI para anexar perfis dinâmicos, que especificam opções de PPP. Para interfaces PPP dinâmicas, o perfil dinâmico cria a interface, incluindo as opções de PPP.

Nota:

Interfaces criadas dinamicamente são suportadas apenas em interfaces PPPoE.

Ao contrário do suporte PPP tradicional, o gerenciamento de assinantes não permite a autenticação bidirecional de PPP — a autenticação é realizada apenas pelo roteador, nunca pelo peer remoto. O processo AAA do roteador gerencia a autenticação e a atribuição de endereços para o gerenciamento de assinantes. Quando você configura opções de PPP para um perfil dinâmico, você pode configurar a autenticação do Protocolo de Autenticação de Firewall de Desafios (CHAP) ou protocolo de autenticação de senha (PAP), e pode controlar a ordem em que o roteador negocia os protocolos CHAP e PAP. Além disso, para a autenticação DOCA, você pode modificar o comprimento padrão da mensagem de desafio DACA. Outras opções de PPP, que são comumente usadas ou obrigatórias para uma configuração de interface PPP tradicional, não são suportadas em perfis dinâmicos de gerenciamento de assinantes.

Entenda como o roteador processa solicitações de manutenção rápidas de PPP iniciadas por assinantes

Nos roteadores da Série MX com concentradores modulares de portas/placas de interface modulares (MPCs/MICs), o mecanismo de encaminhamento de pacotes em um MPC/MIC processa e responde aos pacotes de eco-solicitação do Protocolo de Controle de Enlaces (LCP) que o assinante PPP (cliente) inicia e envia para o roteador. Os pacotes LCP Echo-Request e os pacotes LCP Echo-Reply fazem parte do mecanismo de manutenção do PPP que ajuda a determinar se um link está funcionando corretamente.

Anteriormente, os pacotes LCP Echo-Request e pacotes LCP Echo-Reply foram tratados em um roteador da Série MX pelo Mecanismo de Roteamento. O mecanismo pelo qual os pacotes LCP Echo-Request são processados pelo Mecanismo de encaminhamento de pacotes em vez de pelo Mecanismo de Roteamento é chamado de manutenção rápida de PPP.

Benefícios do PPP Fast Keepalives

  • As manutenções rápidas do PPP reduzem o tempo necessário para trocas keepalives, permitindo que o Mecanismo de encaminhamento de pacotes receba pacotes LCP Echo-Request do assinante PPP e responda com pacotes LCP Echo-Reply, sem precisar enviar os pacotes LCP ao Mecanismo de Roteamento para processamento.

  • As manutenções rápidas de PPP oferecem maior largura de banda no roteador para oferecer suporte a um número maior de assinantes com melhor desempenho, aliviando o mecanismo de roteamento de ter que processar os pacotes LCP Echo-Request e Echo-Reply.

  • Os keepalives de PPP usam números mágicos negociados para identificar possíveis loopbacks de tráfego para o roteador ou problemas de rede. Você também pode desabilitar a validação se necessário para evitar o término de sessão de PPP indesejável, por exemplo, quando os pares remotos do PPP usam números arbitrários em vez do número negociado.

Como funciona o processamento rápido e keepalive da PPP

Você não precisa de nenhuma configuração especial em um roteador da Série MX com MPCs/MICs para permitir o processamento de solicitações de PPP rápidas e keepalive no Mecanismo de encaminhamento de pacotes. O recurso é habilitado por padrão e não pode ser desativado.

A sequência a seguir descreve como um roteador da Série MX processa pacotes LCP Echo-Request e pacotes LCP Echo-Reply no Mecanismo de encaminhamento de pacotes no MPC/MIC:

  1. O mecanismo de roteamento notifica o Mecanismo de encaminhamento de pacotes quando a transmissão de solicitações keepalive é habilitada em uma interface lógica PPP. A notificação inclui os números mágicos do servidor e do cliente remoto.

  2. O Mecanismo de encaminhamento de pacotes recebe o pacote LCP Echo-Request iniciado pelo assinante PPP (cliente).

  3. O Mecanismo de encaminhamento de pacotes valida o número mágico de peer no pacote LCP Echo-Request e transmite o pacote LCP Echo-Reply correspondente contendo o número mágico negociado pelo roteador.

  4. Se o Mecanismo de encaminhamento de pacotes detectar uma condição de loop no link, ele envia o pacote de solicitação de Eco LCP ao Mecanismo de Roteamento para processamento adicional.

    O mecanismo de roteamento continua a processar pacotes LCP Echo-Request até que a condição do loop seja liberada.

A transmissão de solicitações keepalive do Mecanismo de encaminhamento de pacotes no roteador não está habilitada no momento.

Exibição de estatísticas para PPP Fast Keepalive

Quando um roteador da Série MX com MPCs/MICs está usando PPP de forma rápida para um link PPP, o Keepalive statistics campo na saída do show interfaces pp0.logical statistics comando operacional não inclui estatísticas para o número de pacotes keepalive recebidos ou enviados, ou o tempo desde que o roteador recebeu ou enviou o último pacote keepalive.

Efeito da mudança na configuração da classe de encaminhamento

Para alterar a atribuição de fila padrão (classe de encaminhamento) para tráfego de saída gerado pelo Mecanismo de Roteamento, você pode incluir a forwarding-class class-name declaração no nível hierárquico [edit class-of-service host-outbound-traffic] .

Para pacotes PPP rápidos (em linha) LCP Echo-Request e LCP Echo-Reply transmitidos entre um roteador da Série MX com MPCs/MICs e um cliente PPP, mudar a configuração da classe de encaminhamento entra em vigor imediatamente para novas sessões de assinantes PPP-over-Ethernet (PPPoE), PPP-over-ATM (PPPoA) e L2TP network server (LNS) criadas após a mudança de configuração, e para PPPoE, PPPoA, e sessões de assinantes LNS estabelecidas antes da mudança de configuração.

Ignorando uma incompatibilidade de número mágico

Quando o Mecanismo de encaminhamento de pacotes valida o número mágico de peer no pacote LCP Echo-Request recebido, ele verifica se o número mágico é inesperado. O número recebido deve corresponder ao número do peer remoto que foi acordado durante a negociação da LCP. O número de peer remoto deve ser diferente do número de peer local; quando são iguais, a expectativa é que exista uma condição de loopback (o tráfego está voltando para o peer local) ou algum outro problema de rede.

Quando a verificação de validação determina que uma incompatibilidade está presente, o que significa que o número de peer remoto recebido é diferente do número negociado, o Mecanismo de encaminhamento de pacotes envia os pacotes Echo-Reply fracassados para o Mecanismo de Roteamento. Se um Echo-Reply com um número mágico válido não for recebido em um determinado intervalo, o PPP considera isso uma falha keepalive e derruba a sessão de PPP.

Alguns equipamentos do cliente podem não negociar seu número mágico local e, em vez disso, inserir um valor arbitrário como o número mágico que ele envia para o roteador nos pacotes keepalive. Esse número é identificado como uma incompatibilidade e a sessão acaba sendo descartada. A partir do Junos OS Release 18.1R1, esse resultado pode ser evitado configurando o roteador para não realizar uma verificação de validação de números mágicos. Como a incompatibilidade nunca é identificada, o roteador continua a trocar pacotes keepalive PPP com o peer remoto. Para configurar esse comportamento, inclua a ignore-magic-number-mismatch declaração em um perfil de grupo L2TP, no perfil dinâmico para conexões dinâmicas de assinantes PPP terminadas no roteador ou no perfil dinâmico para assinantes PPP dinâmicos com tunelamento na LNS.

Veja também

Atualizações de status de conexão de origem RADIUS para dispositivos CPE

A partir do Junos OS Release 20.2R1, você pode usar mensagens de origem RADIUS para transmitir informações que o BNG encaminha de forma transparente para um dispositivo CPE, como um gateway doméstico. Por exemplo, essas informações podem ser largura de banda upstream ou algum outro parâmetro de taxa de conexão que o dispositivo CPE precisa. Esse recurso é útil quando você deseja aplicar dinamicamente o gerenciamento de tráfego o mais próximo possível dos assinantes.

Normalmente, você pode usar o atributo padrão RADIUS Reply-Message (18) para transmitir essas informações ao dispositivo CPE durante a autenticação do PPP. No entanto, se você já estiver usando esse atributo para outra coisa, você também pode usar o Juniper Networks Connection-Status-Message VSA (26-4874-218). Este VSA é uma extensão lógica do atributo Mensagem de Resposta (18) e tem o mesmo formato e semântica.

O PPP usa uma extensão específica do fornecedor da Juniper Networks para LCP para enviar o conteúdo do VSA de status de conexão para o gateway peer home. O PPP inclui essas informações na opção de mensagem de status de conexão de uma mensagem de solicitação de atualização de conexão LCP.

O RADIUS pode enviar a VSA de mensagem de status de conexão para authd das seguintes maneiras:

  • Na mensagem RADIUS Access-Accept durante a negociação e autorização de uma sessão de PPP

  • Em uma solicitação de CoA RADIUS a qualquer momento para uma sessão PPP ativa

Você pode usar esses dois métodos para qualquer sessão para assinantes empresariais ou residenciais. A mensagem de aceitação de acesso fornece os parâmetros iniciais de conexão. A capacidade de CoA permite que você atualize os parâmetros da taxa de conexão conforme necessário durante toda a vida de uma sessão. As informações fornecidas na VSA de status de conexão são normalmente taxas de tráfego aplicadas pela configuração local, como um perfil de serviço dinâmico ou a mensagem de porta up correspondente do ANCP.

Nota:

Se você não incluir a opção lcp-connection-update PPP no perfil dinâmico do cliente, o PPP processa a notificação a partir de authd, mas não toma nenhuma ação. Se o LCP no roteador não estiver no estado Aberto, então o PPP não agirá na VSA.

As etapas a seguir descrevem o que acontece quando o RADIUS envia o VSA em uma mensagem de aceitação de acesso:

  1. O processo authd recebe o VSA de mensagem de status de conexão em uma mensagem de aceitação de acesso do servidor RADIUS.

  2. O processo authd envia o VSA de mensagem de status de conexão para PPP (jpppd).

  3. A negociação do PPP NCP ocorre entre o cliente PPP de gateway remoto e o PPP no roteador.

  4. A negociação bem-sucedida resulta em uma solicitação de ativação familiar. A sessão de PPP entra no estado Session Up quando a família é ativada.

  5. Se o perfil dinâmico do cliente incluir a opção lcp-connection-update PPP e o LCP no roteador estiver no estado aberto, o PPP enviará uma mensagem de solicitação de atualização de conexão de LCP para o gateway. Esta mensagem inclui as informações VSA na opção De Status-Message de conexão.

    • Se o gateway oferece suporte à solicitação de atualização de conexão de LCP, ele retorna uma mensagem LCP Connection-Update-Ack ao roteador. O LCP de gateway home deve estar no estado Aberto quando receber a solicitação, caso contrário, ele descarta a solicitação.

    • Se o gateway não oferece suporte à solicitação de atualização de conexão de LCP, ele retorna uma mensagem de rejeição de código LCP ao roteador.

    Nota:

    Se o gateway não responder, o roteador refazerá a solicitação de atualização. Ele usa os valores padrão de PPP de até 10 retries máximos com um intervalo de 3 segundos entre as tentativas.
    Nota:

    Se você não incluir a opção lcp-connection-update PPP no perfil dinâmico do cliente, o PPP processa a notificação a partir de authd, mas não toma nenhuma ação. Se a opção estiver presente, mas o LCP no roteador não estiver no estado aberto, o PPP não agirá em relação ao VSA.

As etapas a seguir descrevem o que acontece quando o RADIUS envia o VSA em uma solicitação de CoA. Isso pressupõe que a negociação do NCP já foi bem sucedida e que a sessão está ativa.

  1. O processo authd recebe o VSA de mensagem de status de conexão em uma solicitação de CoA do servidor RADIUS.

  2. O processo authd envia o VSA de mensagem de status de conexão para PPP (jpppd).

  3. Se o perfil dinâmico do cliente incluir a opção lcp-connection-update PPP e o LCP no roteador estiver no estado aberto, o PPP enviará uma mensagem de solicitação de atualização de conexão de LCP para o gateway. Esta mensagem inclui as informações VSA na opção De Status-Message de conexão.

    • Se o gateway oferece suporte à solicitação de atualização de conexão de LCP, ele retorna uma mensagem LCP Connection-Update-Ack ao roteador. O LCP de gateway home deve estar no estado Aberto quando receber a solicitação, caso contrário, ele descarta a solicitação.

    • Se o gateway não oferece suporte à solicitação de atualização de conexão de LCP, ele retorna uma mensagem de rejeição de código LCP ao roteador.

    Nota:

    Se o gateway não responder, o roteador refazerá a solicitação de atualização. Ele usa os valores padrão de PPP de até 10 retries máximos com um intervalo de 3 segundos entre as tentativas.

Se o gateway doméstico não receber uma mensagem de solicitação de atualização de conexão, o roteador volta a enviar a mensagem. O roteador também retruca a solicitação quando não recebe nem um Connection-Update-Ack ou um LCP Code-Reject de volta do gateway, ou quando algo está errado com a mensagem de Ack. O intervalo de nova tentativa padrão é de 3 segundos. O roteador tentará novamente a mensagem até o padrão 10 vezes antes de parar. Se o roteador esgotar todas as tentativas de nova tentativa sem receber uma mensagem apropriada de Atualização de Conexão-Ack, ele registra a mensagem como se tivesse recebido uma mensagem PPP Code-Reject.

Nota:

O RADIUS pode incluir várias instâncias do VSA de status de conexão na mensagem de aceitação de acesso ou em uma solicitação de CoA. Se isso ocorrer, authd usa apenas a primeira instância e ignora qualquer outra.

As solicitações de aceitação de acesso ou CoA podem conter outros atributos além do VSA de status de conexão, mas não há interdependenidade entre o VSA e quaisquer outros atributos. Isso é verdade mesmo quando a mensagem inclui os VSAs de ativação (26-65) ou desativação (26-66). A falta de dependência significa que, mesmo que o authd não aplique com sucesso os outros atributos, ele ainda envia as informações de conexão para o PPP, que por sua vez envia o conteúdo VSA para o gateway doméstico.

Da mesma forma, o authd aplica quaisquer outros atributos e retorna uma resposta coa, independentemente de o PPP comunicar com sucesso o conteúdo do VSA de status de conexão para o gateway remoto. Isso é verdade mesmo quando o CoA contém apenas o VSA com status de conexão. Esse recurso é necessário porque nem todos os gateways aceitam a extensão de LCP usada neste recurso.

Formatos de mensagem e opção

A Figura 1 mostra o formato das mensagens Connection-Update-Request e Connection-Update-Ack. Os formatos são os mesmos, mas a Tabela 1mostra que alguns valores de campo são diferentes para as duas mensagens.

Figura 1: Formato de mensagem de atualização de conexão e atualização de conexão ack Connection-Update-Request and Connection-Update-Ack Message Format
Tabela 1: Valores de campo para solicitação de atualização de conexão e mensagens de atualização de conexão-Ack

Campo

Solicitação de atualização de conexão

Atualização de conexão-Ack

Código

0 para fornecedores específicos

0 para fornecedores específicos

Identificador

Identificador para pacotes específicos do fornecedor

Mesmo identificador da mensagem de solicitação de atualização de conexão. Se esse valor não corresponder, o roteador registra o erro e descarta o pacote. Isso permite que a mensagem de solicitação seja reencaída, assim como se o gateway não a tivesse recebido.

Comprimento

Número de bytes no pacote: 12 mais o comprimento da opção De Status-Mensagem de Conexão

Número de bytes no pacote Connection-Update-Ack: 12

Número mágico

Valor negociado para o número mágico local de PPP

Valor negociado para o número mágico local de PPP

Identificador exclusivo (OUI) organizacional

00-21-59 para a Juniper Networks

00-21-59 para a Juniper Networks

Tipo

1 para atualização de sessão

2 para Session-Ack. Para qualquer outro valor, o roteador registra o erro e descarta o pacote. Isso permite que a mensagem de solicitação seja reencaída, assim como se o gateway não a tivesse recebido.

Valores

Opção de status da mensagem de conexão no formato TLV

Nenhum valor é suportado

Você pode configurar como os números mágicos do PPP são usados.

  • Se você configurar ignore-magic-number-mismatch a opção PPP, você está impedindo que os números mágicos sejam validados. O PPP ignora uma incompatibilidade entre os números mágicos na solicitação e as mensagens de Ack. Se não houver outros erros de validação, o PPP aceita a mensagem Connection-Update-Ack.

  • Se você não configurar ignore-magic-number-mismatch a opção PPP, os números mágicos passarão por validação. Se o número mágico na mensagem Ack não corresponder ao número mágico do gateway estabelecido durante a negociação do LCP, o roteador registra o erro e descarta a mensagem De atualização de conexão como uma resposta inválida. Isso permite que a mensagem de solicitação seja reencaída, assim como se o gateway não a tivesse recebido.

Veja prevenção da validação de números mágicos de PPP durante as trocas de manutenção de PPP para obter mais informações sobre números mágicos.

A Figura 2 mostra o formato das opções de Status-Mensagem de Conexão. A Tabela 2 lista os valores de campo.

Figura 2: Formato de opção de mensagem de status de conexão Connection-Status-Message Option Format
Tabela 2: Valores de campo para a opção de mensagem de status de conexão

Campo

Valor

Tipo

1

Comprimento

Número de bytes na opção; 2 mais o comprimento da mensagem. O comprimento da mensagem pode ser de 1 a 247 bytes.

Mensagem de status

Conteúdo da VSA com status de conexão

Configure perfis dinâmicos para PPP

Um perfil dinâmico atua como um modelo que permite que você crie, atualize ou remova uma configuração que inclua atributos para acesso ao cliente (como, interface ou protocolo) ou serviço (como, IGMP). Usando perfis dinâmicos, você pode consolidar todos os atributos comuns de um cliente (e eventualmente um grupo de clientes) e aplicar os atributos simultaneamente.

Após a criação de perfis dinâmicos, os perfis residem em uma biblioteca de perfil no roteador. Em seguida, você pode usar a dynamic-profile declaração para anexar perfis a interfaces. Para atribuir um perfil dinâmico a uma interface PPP, você pode incluir a dynamic-profile declaração no nível de [edit interfaces interface-name unit logical-unit-number ppp-options] hierarquia:

Para monitorar a configuração, emita o show interfaces interface-name comando.

Para obter informações sobre perfis dinâmicos, veja a visão geral de perfis dinâmicos no Guia de configuração de acesso ao assinante Junos.

Para obter informações sobre a criação de perfis dinâmicos, consulte Configuração de um perfil dinâmico básico no Guia de configuração de acesso ao assinante Junos.

Para obter informações sobre a atribuição de um perfil dinâmico a uma interface PPP, consulte Anexando perfis dinâmicos a interfaces estáticas de assinantes PPP no Guia de configuração de acesso ao assinante Junos.

Para obter informações sobre o uso de perfis dinâmicos para autenticar assinantes PPP, consulte Configurando a autenticação dinâmica para assinantes PPP.

Nota:

Os perfis dinâmicos para assinantes de PPP são suportados apenas em interfaces PPPoE para este lançamento.

Evitando a validação de números mágicos de PPP durante as trocas de manutenção de PPP

Os números mágicos do PPP são negociados entre pares durante a negociação da LCP. Os pares devem ter números mágicos diferentes. Quando os números são os mesmos, ele indica que pode haver um loopback no tráfego enviado pelo peer local. Neste caso, o peer local envia um novo número para o peer remoto. Se o número mágico devolvido pelo peer remoto for diferente do número mais recente enviado pelo peer local, então os números serão acordados. Caso contrário, a troca de números mágicos continua até que um número válido (diferente) seja recebido ou o processo seja eliminado, nesse caso a sessão é descartada.

Após os números serem acordados, os pares incluem seus respectivos números mágicos quando trocam pacotes de keepalive PPP (Echo-Request/Echo-Reply). O Mecanismo de encaminhamento de pacotes valida o número mágico recebido para cada troca. Uma incompatibilidade ocorre quando o número mágico de PPP recebido do peer remoto não corresponde ao valor acordado durante a negociação da LCP. Quando a verificação de validação determina que uma incompatibilidade está presente, o Mecanismo de encaminhamento de pacotes envia o pacote echo-request fracassado para o mecanismo de roteamento. Se um Echo-Reply com um número mágico válido não for recebido em um determinado intervalo, o PPP considera isso uma falha keepalive e derruba a sessão de PPP.

Em algumas circunstâncias, esse comportamento não é desejável. Alguns equipamentos do cliente não negociam seu número mágico local; em vez disso, ele insere um valor arbitrário como o número mágico que ele envia para o roteador nos pacotes keepalive. Por padrão, esse número é identificado como uma incompatibilidade e a sessão acaba sendo descartada. Esse resultado pode ser evitado impedindo o Mecanismo de encaminhamento de pacotes de realizar a verificação de validação de números mágicos. Como a incompatibilidade nunca é identificada, o roteador continua a trocar pacotes keepalive PPP com o peer remoto.

Desativar a verificação de validação de número mágico incluindo a ignore-magic-number-mismatch declaração como uma das opções de PPP aplicadas em um perfil PPP dinâmico, perfil dinâmico L2TP LNS ou perfil de grupo L2TP. Configurar essa declaração não tem efeito na negociação de número mágico do LCP ou na troca de keepalives quando o número mágico de peer remoto é o número negociado esperado.

Nota:

Como a validação de números mágicos não é realizada, o Mecanismo de encaminhamento de pacotes não detecta se o peer remoto envia o número mágico do peer local, o que indicaria um loopback ou outro problema de rede. Esta é considerada uma situação improvável, porque a negociação da LCP foi concluída com sucesso, o que significa que nenhum loopback estava presente naquele momento.

Para configurar perfis dinâmicos para evitar que o Mecanismo de encaminhamento de pacotes detecte incompatibilidades em números mágicos:

Configure a opção PPP.

  • Para conexões dinâmicas de assinantes PPP terminadas no roteador:

  • Para assinantes PPP dinâmicos com tunelamento em interfaces de serviço em linha LNS:

Você pode usar o show ppp interface interface-name extensive comando para ver se os números mágicos são ignorados.

Como configurar as atualizações de status de conexão de origem RADIUS para dispositivos CPE

Você pode usar mensagens de origem RADIUS para transmitir informações que o BNG encaminha de forma transparente para um dispositivo CPE, como um gateway doméstico. Por exemplo, essas informações podem ser largura de banda upstream ou algum outro parâmetro de taxa de conexão que o dispositivo CPE precisa.

Quando você habilita este recurso, o PPP pode agir em uma VSA de status de conexão (26-218) recebida por authd em uma mensagem radius de aceitação de acesso ou em uma mensagem de CoA. O PPP então transmite o conteúdo do VSA em uma mensagem de solicitação de atualização de conexão de LCP para o peer remoto. Essa ação exige que o seguinte seja verdadeiro:

  • Pelo menos a família do primeiro endereço foi negociada com sucesso e a sessão está ativa.

  • O LCP do roteador está no estado aberto.

Caso contrário, o PPP não toma nenhuma ação na VSA. Se você não habilitar a opção, o lcp-connection-update PPP processa a notificação a partir de authd, mas não toma nenhuma ação.

Você configura esse recurso no perfil dinâmico do cliente associado aos assinantes usando o dispositivo CPE. Na prática, você está adicionando isso a inúmeros outros recursos no perfil do cliente. Este exemplo mostra apenas a configuração específica para este recurso. Esse recurso também exige que você configure o VSA 26-218 em seu servidor RADIUS; que está fora do escopo dessa documentação.

Para configurar as atualizações de status de conexão em um perfil dinâmico para interfaces de assinantes PPP:

  1. Edite as opções de PPP no perfil do cliente.
  2. Habilite as atualizações de status da conexão.

Você pode usar o show ppp interface extensive comando para a interface lógica PPP para determinar se as atualizações de conexão LCP são bem sucedidas. Você pode monitorar as estatísticas relevantes com o show system subscriber-management statistics ppp comando.

Anexação de perfis dinâmicos a interfaces estáticas de assinantes de PPP

Você pode anexar um perfil dinâmico a uma interface de assinante PPP estática. Quando um assinante PPP faz login, o perfil dinâmico especificado é instanciado e os serviços definidos no perfil são aplicados à interface.

Para anexar um perfil dinâmico a uma interface de assinante PPP estática:

  1. Especifique se deseja configurar opções de PPP.
  2. Especifique o perfil dinâmico que deseja associar à interface.

Migração de configurações estáticas de assinantes de PPP para uma visão geral dinâmica de perfis

Este tópico discute várias considerações para a migração de determinadas configurações de assinantes PPP estáticas e terminadas para configurações dinâmicas usando perfis dinâmicos. Provedores de serviços que gerenciam assinantes estáticos em roteadores com versões legadas do Junos OS (antes do Junos OS Release 15.1R4) têm requisitos para migrar seus assinantes estáticos para serem gerenciados com perfis dinâmicos em roteadores que executam gerenciamento aprimorado de assinantes (Junos OS Release 15.1R4 e versões posteriores). A partir do Junos OS Release 18.2R1, vários aprimoramentos foram adicionados para facilitar a transição dessas configurações estáticas de provedores de serviços para perfis dinâmicos.

Autenticação local

Alguns provedores com configurações estáticas podem usar dispositivos CPE que não oferecem suporte a nenhum protocolo de autenticação, nem mesmo AOCA ou PAP. Os provedores podem usar tabelas de nomes de serviços PPPoE como um método rudimentar para autenticar e autorizar os assinantes em interfaces lógicas de PPPoE estáticas. Se a ACI do assinante ou a ARI não corresponderem a uma entrada de tabela, os pacotes PPP PADI e PADR normalmente serão descartados. As versões legadas do Junos OS não oferecem suporte a assinantes configurados sem autenticação para o método de autenticação.

Para assinantes em que o CPE não oferece suporte a protocolos de autenticação, como PAP e CHAP, você pode configurar nomes de usuário e senhas localmente. O roteador usa esses valores quando entra em contato com o servidor RADIUS para autenticação.

  • Para configurar o nome de usuário para autenticação local, inclua a username-include declaração nas opções de PPP para a interface lógica dinâmica. Você pode definir o nome com base em um ou mais dos seguintes atributos: endereço MAC, ID do Circuito de Agente, ID remoto do agente e nome do domínio. Por padrão, um período (.) é o delimiter entre elementos do nome, mas você pode definir outros caracteres em vez disso.

  • Para configurar a senha para autenticação local, inclua a password declaração nas opções de PPP para a interface lógica dinâmica.

Você pode usar o mesmo perfil dinâmico para dar suporte a CPEs que não oferecem suporte a um protocolo de autenticação e CPEs que o fazem.

Atribuição de endereço de origem CPE

Para algumas configurações estáticas, o endereço do assinante não é atribuído usando RADIUS ou um pool de endereços local no roteador. Em vez disso, o CPE tem um endereço estático configurado para o assinante; durante a negociação do IPCP, o CPE solicita que o roteador atribua esse endereço ao assinante.

A partir do Junos OS Release 18.2R1, você pode atribuir um endereço curinga de 255.255.255.255 ao atributo de endereço de rota emoldurado [8] na configuração do seu servidor RADIUS. Quando o RADIUS devolve o atributo com esse valor, o jpppd aceita automaticamente a atribuição de endereço IP do assinante fornecida pelo cliente em uma mensagem de configuração de solicitação de IPCP em vez de atribuir outro endereço.

Atributo de rota tag2

Em algumas configurações, interfaces de assinanteS PPP estáticas são configuradas em diferentes VRFs. Cada configuração vrf tem rotas estáticas que apontam para interfaces estáticas de assinantes PPP como o endereço de próximo salto. Essas rotas podem ter o atributo tag2 configurado; é necessário pelo MP-BGP aplicar a preferência local e a comunidade apropriadas quando anuncia as rotas.

A partir da versão 18.2R1 do Junos OS, você pode configurar o servidor RADIUS para incluir o atributo tag2 no atributo Framed-Route [22] quando ele autentica um assinante.

Você também deve configurar o perfil dinâmico para obter o valor da tag2 do atributo Framed-Route. Para isso, especifique a variável predefinida $junos-framed-route-tag2 a ser usada quando a rota de acesso for instanciada dinamicamente. Como alternativa, você pode configurar o perfil dinâmico para fornecer um valor específico de tag2 para um prefixo de rota de acesso específico.

Consulte as variáveis predefinidas do Junos OS para obter mais informações sobre variáveis predefinidas.

Benefícios

  • A autenticação local permite a autenticação com senhas e nomes de usuário armazenados localmente para assinantes quando o CPE não oferece suporte a protocolos de autenticação, como PAP e CHAP.

  • A atribuição de endereços de origem CPE permite que o roteador aceite endereços IP de assinantes configurados estaticamente solicitados pelo CPE em vez de atribuir o endereço de um pool de endereços local ou de origem externa.

  • O atributo tag2 permite especificações mais detalhadas das rotas.

Configuração da autenticação local em perfis dinâmicos para assinantes PPP IPv4 estáticos encerrados

Alguns provedores com configurações estáticas podem usar dispositivos CPE que não oferecem suporte a nenhum protocolo de autenticação, nem mesmo AOCA ou PAP. Os provedores podem usar tabelas de nomes de serviços PPPoE como um método rudimentar para autenticar e autorizar os assinantes em interfaces lógicas de PPPoE estáticas. Se a ACI ou a ARI do assinante não corresponderem a uma entrada de tabela, os pacotes PPP PADI e PADR normalmente serão descartados.

A partir do Junos OS Release 18.2R1, você pode configurar nomes de usuário e senhas localmente para clientes que não suportam protocolos de autenticação, como PAP e CHAP. O roteador usa esses valores quando entra em contato com o servidor RADIUS para autenticação. Isso ajuda na migração dos assinantes estáticos a usar perfis dinâmicos em um roteador que executa gerenciamento aprimorado de assinantes.

Para configurar a autenticação local:

  1. Configure o nome de usuário usando uma ou mais das opções disponíveis.

    1. (Opcional) Especifique que o identificador de circuito do agente (ACI) está incluído no nome de usuário. A ACI é derivada de tags PPPoE.

    2. (Opcional) Especifique que a ID remota (ARI) do agente está incluída no nome de usuário. O ARI é derivado de tags PPPoE.

    3. (Opcional) Especifique que o endereço MAC da PDU do cliente está incluído no nome de usuário. O endereço MAC é derivado do pacote PPPoE.

    4. (Opcional) Especifique o nome de domínio do cliente para finalizar o nome de usuário. O roteador adiciona o caractere @ como o delimiter para esta opção.

    5. (Opcional) Especifique um delimiter para separar os componentes que compõem o nome de usuário. O delimiter padrão é um período (.). O roteador sempre usa o @ caractere como delimiter antes do nome do domínio.

  2. Configure a senha para o assinante.

O nome de usuário leva o seguinte formato quando você inclui todas as opções e usa o delimitador padrão:

Por exemplo, considere a seguinte configuração de amostra, onde a ACI é aci1002, a ARI é ari349 e o endereço MAC é 00:00:5e:00:53:ff:

Essa configuração resulta em uma senha local de $ABC 123$ABC123 para o seguinte nome de usuário local exclusivo:

0000.5e00.53ff-aci1002-ari349@example.com

Configuração de atributos da Tag2 em perfis dinâmicos para assinantes PPP IPv4 encerrados estáticos

Em algumas configurações, os assinantes de PPP usam rotas estáticas com um atributo tag2. Por exemplo, o MP-BGP usa a tag2 para permitir que ela aplique a preferência local e a comunidade apropriadas quando anuncia rotas. Quando você migra esses assinantes para usar perfis dinâmicos em um roteador que executa gerenciamento aprimorado de assinantes, você pode configurar o atributo tag2 configurando um valor específico para uma rota ou obtendo o valor de um servidor RADIUS. Esse suporte está disponível pela primeira vez no Junos OS Release 18.2R1.

  • Para configurar um valor específico de tag2 para uma rota:

    • Especifique o valor.

  • Para obter o valor da tag2 de um servidor RADIUS:

    1. Configure seu servidor RADIUS para incluir o atributo tag2 no atributo Framed-Route [22] quando ele autentica um assinante. Consulte a documentação do servidor RADIUS para obter informações de configuração. A configuração pode se parecer com o seguinte exemplo:

    2. Configure o perfil dinâmico para usar a variável predefinida $junos-framed-route-tag2 para obter dinamicamente o valor da tag2 do atributo Framed-Route.

      A variável predefinida de roteamento ip-endereço-prefixo $junos emoldurado deriva o prefixo de endereço IPv4 para a rota de acesso a partir do atributo Framed-Route.

Configuração da autenticação dinâmica para assinantes de PPP

Você pode configurar um perfil dinâmico que inclui a autenticação de PPP que permite que os clientes PPP acessem dinamicamente a rede. Você pode especificar a autenticação DO PAP ou do PAP. Opcionalmente, você também pode controlar a ordem em que o roteador negocia os protocolos CHAP e PAP.

Para interfaces dinâmicas, o roteador oferece suporte apenas à autenticação unidirecional — o roteador sempre funciona como o autenticador. Quando você configura a autenticação de PPP em um perfil dinâmico, a autenticação CHAP oferece suporte à opção challenge-length , que permite configurar o comprimento mínimo e o comprimento máximo da mensagem de desafio DESCAS. Nem a autenticação DE CAPE nem a autenticação PAP oferecem suporte a nenhuma outra opção de configuração, incluindo a passive declaração.

Nota:

Os perfis dinâmicos para assinantes de PPP são suportados apenas em interfaces PPPoE.

Para configurar a autenticação em um perfil dinâmico para interfaces de assinantes PPP:

  1. Nomeie o perfil dinâmico.
  2. Configure as interfaces e a unidade para o perfil dinâmico. Uso pp0 para o tipo de interface e a variável predefinida para a unidade.
  3. Configure as opções de PPP.
  4. Especifique o protocolo de autenticação usado no perfil dinâmico. Você pode configurar o CHAP ou o PAP. Não há opções adicionais para nenhum protocolo de autenticação.
  5. (Opcional) Configure o comprimento mínimo e o comprimento máximo da mensagem de desafio DACA.

    Veja a modificação do comprimento do desafio DALP.

  6. (Opcional) Configure a ordem em que o roteador negocia os protocolos de autenticação DELP e PAP.

    Consulte o controle da ordem de negociação dos protocolos de autenticação de PPP.

  7. (Opcional) Configure o roteador para solicitar ao CPE que negocie os endereços DNS para assinantes de PPPoE dinâmicos durante a negociação do IPCP.

    Veja como garantir a negociação do IPCP para endereços DNS primários e secundários para obter mais informações.

Modificação do comprimento do desafio DALH

Você pode modificar o comprimento mínimo padrão e a duração máxima da mensagem de desafio challenges do Challenge Authentication Protocol (CHAP) que o roteador envia para um cliente PPP. A mensagem de desafio DAC, que contém informações exclusivas de uma sessão específica de assinantes de PPP, é usada como parte do mecanismo de autenticação entre o roteador e o cliente para verificar a identidade do cliente para acesso ao roteador.

Por padrão, o comprimento mínimo do desafio CHAP é de 16 bytes, e o comprimento máximo é de 32 bytes. Você pode substituir esse padrão para configurar o desafio CAPE de comprimento mínimo e comprimento máximo na faixa de 8 bytes a 63 bytes.

Melhores práticas:

Recomendamos que você configure o comprimento mínimo e o comprimento máximo do desafio DECA para pelo menos 16 bytes.

Antes de começar:

Para configurar o comprimento mínimo e máximo da mensagem de desafio DACA:

  1. Especifique se deseja configurar opções de PPP.

    • Para interfaces dinâmicas de assinantes PPP:

    • Para interfaces estáticas com encapsulamento PPP:

  2. Especifique se deseja configurar as opções DELAs.

    • Para interfaces dinâmicas de assinantes PPP:

    • Para interfaces estáticas com encapsulamento PPP:

  3. Especifique o comprimento mínimo e o comprimento máximo do desafio CAPE.

    • Para interfaces dinâmicas de assinantes PPP:

    • Para interfaces estáticas com encapsulamento PPP:

    Por exemplo, a declaração a seguir challenge-length em um perfil dinâmico denominado perfil pppoe-cliente define o comprimento mínimo do desafio DECA para 20 bytes e o comprimento máximo para 40 bytes.

Exemplo: Perfil dinâmico mínimo de PPPoE

Este exemplo mostra a configuração mínima para um perfil dinâmico que é usado para interfaces de PPPoE estáticas. A configuração deve incluir a interfaces pp0 estrofe.

Verificação e gerenciamento da configuração de PPP para gerenciamento de assinantes

Propósito

Visualizar ou informações claras sobre a configuração do PPP para o gerenciamento de assinantes.

Ação

  • Para exibir informações sobre interfaces PPP:

  • Para exibir informações de estatísticas de PPP:

  • Para exibir informações do resumo da sessão do PPP:

  • Para exibir informações do grupo de endereços PPP:

Documentação relacionada

Tabela de histórico de lançamentos
Lançamento
Descrição
20.2R1
A partir do Junos OS Release 20.2R1, você pode usar mensagens de origem RADIUS para transmitir informações que o BNG encaminha de forma transparente para um dispositivo CPE, como um gateway doméstico.
18.2R1
A partir do Junos OS Release 18.2R1, vários aprimoramentos foram adicionados para facilitar a transição dessas configurações estáticas de provedores de serviços para perfis dinâmicos.
18.1R1
A partir do Junos OS Release 18.1R1, esse resultado pode ser evitado configurando o roteador para não realizar uma verificação de validação de números mágicos.