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 de assinantes PPP

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

Gerenciamento de assinantes O suporte a PPP 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, em seguida, aplica os atributos definidos no perfil à interface.

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

Observação:

As 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 PPP bidirecional — 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. Ao configurar opções de PPP para um perfil dinâmico, você pode configurar a autenticação do Protocolo de Autenticação de Handshake de Desafio (CHAP) ou do Protocolo de Autenticação de Senha (PAP) e pode controlar a ordem na qual o roteador negocia os protocolos CHAP e PAP. Além disso, para autenticação CHAP, você pode modificar o comprimento padrão da mensagem de desafio CHAP. 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.

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

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

Anteriormente, os pacotes de solicitação de eco LCP e os pacotes de resposta de eco LCP eram tratados em um roteador da Série MX pelo Mecanismo de Roteamento. O mecanismo pelo qual os pacotes de solicitação de eco LCP são processados pelo Mecanismo de Encaminhamento de Pacotes em vez de pelo Mecanismo de Roteamento é chamado de keepalives rápidos PPP.

Benefícios do PPP Fast Keepalives

  • Os keepalives rápidos de PPP reduzem o tempo necessário para trocas de keepalive, permitindo que o Mecanismo de Encaminhamento de Pacotes receba pacotes de solicitação de eco LCP do assinante PPP e responda com pacotes de resposta de eco LCP, sem precisar enviar os pacotes LCP ao Mecanismo de Roteamento para processamento.

  • As manutenções de atividade rápidas 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.

  • As manutenções rápidas 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 encerramento indesejado da sessão PPP, por exemplo, quando os pares remotos PPP usam números arbitrários em vez do número negociado.

Como funciona o processamento rápido de manutenção de atividade 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 keepalive rápido PPP no Mecanismo de Encaminhamento de Pacotes. O recurso é habilitado por padrão e não pode ser desabilitado.

A sequência a seguir descreve como um roteador da Série MX processa pacotes de solicitação de eco LCP e pacotes de resposta de eco LCP 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 de solicitação de eco LCP iniciado pelo assinante PPP (cliente).

  3. O Mecanismo de Encaminhamento de Pacotes valida o número mágico do 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 enviará o pacote de solicitação de eco LCP ao Mecanismo de Roteamento para processamento posterior.

    O Mecanismo de Roteamento continua a processar pacotes de solicitação de eco LCP até que a condição de loop seja eliminada.

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 o keepalive rápido PPP para um enlace 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 a quantidade de tempo desde que o roteador recebeu ou enviou o último pacote keepalive.

Efeito de alterar a configuração da classe de encaminhamento

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

Para pacotes de solicitação de eco LCP e resposta de eco LCP de manutenção rápida (em linha) PPP transmitidos entre um roteador da Série MX com MPCs/MICs e um cliente PPP, a mudança na configuração da classe de encaminhamento entra em vigor imediatamente para as novas sessões de assinante PPP-over-Ethernet (PPPoE), PPP-over-ATM (PPPoA) e servidor de rede L2TP (LNS) criadas após a mudança de configuração, e para PPPoE, PPPoA existentes, e sessões de assinante do LNS estabelecidas antes da mudança de configuração.

Ignorando uma incompatibilidade de números mágicos

Quando o Mecanismo de Encaminhamento de Pacotes valida o número mágico do peer no pacote de solicitação de eco LCP 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 do 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 de Echo-Reply com falha para o Mecanismo de Roteamento. Se um Echo-Reply com um número mágico válido não for recebido dentro de um determinado intervalo, o PPP considerará isso uma falha de keepalive e destruirá a sessão do 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 ao roteador nos pacotes keepalive. Esse número é identificado como uma incompatibilidade e a sessão é eventualmente 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úmero mágico. 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 túnel no 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 impor 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 PPP. No entanto, se você já estiver usando esse atributo para outra coisa, também poderá usar a mensagem de status de conexão da Juniper Networks VSA (26-4874–218). Este VSA é uma extensão lógica para o atributo Reply-Message (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 Connection-Status-Message para o gateway home do peer. O PPP inclui essas informações na opção Connection-Status-Message de uma mensagem LCP Connection-Update-Request.

O RADIUS pode enviar o VSA Connection-Status-Message para authd das seguintes maneiras:

  • Na mensagem RADIUS Access-Accept durante a negociação e autorização de uma sessão 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 comerciais ou residenciais. A mensagem Access-Accept fornece os parâmetros de conexão iniciais. O recurso CoA permite que você atualize os parâmetros de taxa de conexão conforme necessário ao longo da vida de uma sessão. As informações transportadas no VSA Connection-Status-Message normalmente são taxas de tráfego aplicadas pela configuração local, como um perfil de serviço dinâmico ou a mensagem ANCP Port Up correspondente.

Observação:

Se você não incluir a lcp-connection-update opção PPP no perfil dinâmico do cliente, o PPP processará a notificação do authd, mas não executará nenhuma ação. Se o LCP no roteador não estiver no estado Aberto, o PPP não executará nenhuma ação no 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 Connection-Status-Message em uma mensagem Access-Accept do servidor RADIUS.

  2. O processo authd envia o VSA Connection-Status-Message para PPP (jpppd).

  3. A negociação PPP NCP ocorre entre o cliente PPP do 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 PPP entra no estado Session Up quando a família é ativada.

  5. Se o perfil dinâmico do cliente incluir a lcp-connection-update opção PPP e o LCP no roteador estiver no estado Aberto, o PPP enviará uma mensagem LCP Connection-Update-Request ao gateway. Essa mensagem inclui as informações do VSA na opção Connection-Status-Message.

    • Se o gateway oferecer suporte à LCP Connection-Update-Request, ele retornará uma mensagem LCP Connection-Update-Ack ao roteador. O LCP do gateway doméstico deve estar no estado Aberto quando receber a solicitação, caso contrário, descartará a solicitação.

    • Se o gateway não suportar a solicitação de atualização de conexão LCP, ele retornará uma mensagem de rejeição de código LCP ao roteador.

    Observação:

    Se o gateway não responder, o roteador tentará novamente a solicitação de atualização. Ele usa os valores padrão do PPP de até um máximo de 10 tentativas com um intervalo de 3 segundos entre as tentativas.
    Observação:

    Se você não incluir a lcp-connection-update opção PPP no perfil dinâmico do cliente, o PPP processará a notificação do authd, mas não executará nenhuma ação. Se a opção estiver presente, mas o LCP no roteador não estiver no estado Aberto, o PPP não tomará nenhuma ação 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 a sessão está ativa.

  1. O processo authd recebe o VSA Connection-Status-Message em uma solicitação de CoA do servidor RADIUS.

  2. O processo authd envia o VSA Connection-Status-Message para PPP (jpppd).

  3. Se o perfil dinâmico do cliente incluir a lcp-connection-update opção PPP e o LCP no roteador estiver no estado Aberto, o PPP enviará uma mensagem LCP Connection-Update-Request ao gateway. Essa mensagem inclui as informações do VSA na opção Connection-Status-Message.

    • Se o gateway oferecer suporte à LCP Connection-Update-Request, ele retornará uma mensagem LCP Connection-Update-Ack ao roteador. O LCP do gateway doméstico deve estar no estado Aberto quando receber a solicitação, caso contrário, descartará a solicitação.

    • Se o gateway não suportar a solicitação de atualização de conexão LCP, ele retornará uma mensagem de rejeição de código LCP ao roteador.

    Observação:

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

Se o gateway doméstico não receber uma mensagem Connection-Update-Request, o roteador tentará enviar a mensagem novamente. O roteador também repete a solicitação quando não recebe um Connection-Update-Ack ou um LCP Code-Reject de volta do gateway, ou quando algo está errado com a mensagem Ack. O intervalo de repetição padrão é de 3 segundos. O roteador tentará novamente a mensagem até o padrão 10 vezes antes que ela seja encerrada. Se o roteador esgotar todas as tentativas de repetição sem receber uma mensagem Connection-Update-Ack apropriada, ele registrará a mensagem como se tivesse recebido uma mensagem de rejeição de código PPP.

Observação:

O RADIUS pode incluir várias instâncias do VSA Connection-Status-Message na mensagem Access-Accept ou em uma solicitação CoA. Se isso ocorrer, authd usará apenas a primeira instância e ignorará todas as outras.

As solicitações Access-Accept ou CoA podem conter outros atributos além do VSA Connection-Status-Message, mas não há interdependência entre o VSA e quaisquer outros atributos. Isso é verdadeiro mesmo quando a mensagem inclui os VSAs Activate-Service (26–65) ou Deactivate-Service (26–66). A falta de dependência significa que, mesmo que o authd não aplique com êxito os outros atributos, ele ainda envia as informações de conexão para o PPP, que por sua vez envia o conteúdo do VSA para o gateway doméstico.

Da mesma forma, authd aplica quaisquer outros atributos e retorna uma resposta CoA, independentemente de o PPP comunicar com sucesso o conteúdo do VSA Connection-Status-Message ao gateway remoto. Isso é verdadeiro mesmo quando o CoA contém apenas o VSA Connection-Status-Message. Esse recurso é necessário porque nem todos os gateways aceitarão a extensão LCP usada nesse 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 connection-update-request e connection-update-ack Diagram of TLV encoded data structure with fields Code, Identifier, Length, Magic Number, OUI, Kind, and Values, showing bit positions.
Tabela 1: Valores de campo para mensagens Connection-Update-Request e Connection-Update-Ack

Âmbito de aplicação

solicitação de atualização de conexão

conexão-atualização-confirmação

Código

0 para fornecedor específico

0 para fornecedor específico

Identificador

Identificador para pacote específico do fornecedor

Mesmo identificador da mensagem Connection-Update-Request. Se esse valor não corresponder, o roteador registrará o erro e descartará o pacote. Isso permite que a mensagem de solicitação seja repetida, como se o gateway não a tivesse recebido.

Comprimento

Número de bytes no pacote: 12 mais o comprimento da opção Connection-Status-Message

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

Número mágico

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

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

Identificador organizacional exclusivo (OUI)

21/00/59 para a Juniper Networks

21/00/59 para a Juniper Networks

Gentil

1 para atualização de sessão

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

Valores

Opção Connection-Status-Message no formato TLV

Não há suporte para valores

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, estará 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 Ack. Se não houver outros erros de validação, o PPP aceitará a mensagem Connection-Update-Ack.

  • Se você não configurar ignore-magic-number-mismatch a opção PPP, os números mágicos passam pela 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 LCP, o roteador registrará o erro e descartará a mensagem Connection-Update-Ack como uma resposta inválida. Isso permite que a mensagem de solicitação seja repetida, como se o gateway não a tivesse recebido.

Consulte Impedindo a validação de números mágicos PPP durante trocas de manutenção de atividade PPP para obter mais informações sobre números mágicos.

A Figura 2 mostra o formato das opções Connection-Status-Message. A Tabela 2 lista os valores dos campos.

Figura 2: Formato Diagram of MIDI message structure showing Type and Length fields in the first byte and Status Message field in the second and third bytes. da opção Connection-Status-Message
Tabela 2: Valores de campo para a opção connection-status-message

Âmbito de aplicação

Valor

Digite

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 mensagem de status de conexão VSA

Configurar perfis dinâmicos para PPP

Um perfil dinâmico atua como um modelo que permite criar, atualizar ou remover uma configuração que inclui atributos para acesso do 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.

Depois que os perfis dinâmicos são criados, eles residem em uma biblioteca de perfis no roteador. Em seguida, você pode usar a dynamic-profile instrução para anexar perfis a interfaces. Para atribuir um perfil dinâmico a uma interface PPP, você pode incluir a dynamic-profile instrução no nível da [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, consulte a visão geral dos perfis dinâmicos no Guia de configuração de acesso do Junos Subscriber.

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

Para obter informações sobre como atribuir 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 para assinantes do Junos.

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

Observação:

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

Impedindo a validação de números mágicos de PPP durante trocas de keepalive de PPP

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

Depois que os números são 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 do PPP recebido do peer remoto não corresponde ao valor acordado durante a negociação do LCP. Quando a verificação de validação determina que uma incompatibilidade está presente, o Mecanismo de Encaminhamento de Pacotes envia o pacote de solicitação de eco com falha para o Mecanismo de Roteamento. Se um Echo-Reply com um número mágico válido não for recebido dentro de um determinado intervalo, o PPP considerará isso uma falha de keepalive e destruirá a sessão do 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 envia ao roteador nos pacotes keepalive. Por padrão, esse número é identificado como uma incompatibilidade e a sessão é eventualmente descartada. Esse resultado pode ser evitado impedindo que o Mecanismo de Encaminhamento de Pacotes execute a verificação de validação do número mágico. Como a incompatibilidade nunca é identificada, o roteador continua a trocar pacotes keepalive PPP com o peer remoto.

Desative a verificação de validação do número mágico incluindo a ignore-magic-number-mismatch instruçã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. A configuração dessa declaração não tem efeito na negociação do número mágico do LCP ou na troca de keepalives quando o número mágico do peer remoto é o número negociado esperado.

Observação:

Como a validação do número mágico não é executada, 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. Essa é considerada uma situação improvável, pois a negociação do LCP foi concluída com êxito, 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 túnel 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 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 esse recurso, o PPP pode agir em uma VSA de mensagem de status de conexão (26–218) recebida pelo authd em uma mensagem de aceitação de acesso RADIUS ou em uma mensagem de CoA. Em seguida, o PPP transmite o conteúdo do VSA em uma mensagem LCP Connection-Update-Request para o peer remoto. Essa ação requer que o seguinte seja verdadeiro:

  • Pelo menos a primeira família de endereços foi negociada com êxito e a sessão está ativa.

  • O LCP do roteador está no estado Aberto.

Caso contrário, o PPP não tomará nenhuma ação no VSA. Se você não habilitar a opção, o lcp-connection-update PPP processará a notificação do authd, mas não executará nenhuma ação.

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

Para configurar as atualizações de status de conexão em um perfil dinâmico para interfaces de assinante 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 foram bem-sucedidas. Você pode monitorar as estatísticas relevantes com o show system subscriber-management statistics ppp comando.

Anexando perfis dinâmicos a interfaces estáticas de assinantes 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 que você deseja configurar as opções de PPP.
  2. Especifique o perfil dinâmico que você deseja associar à interface.

Visão geral da migração de configurações estáticas de assinantes PPP para perfis dinâmicos

Este tópico discute várias considerações para migrar determinadas configurações estáticas de assinantes IPv4 PPP terminados para configurações dinâmicas usando perfis dinâmicos. Os provedores de serviços que gerenciam assinantes estáticos em roteadores com versões legadas do Junos OS (anteriores ao 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 do provedor 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 CHAP ou PAP. Os provedores podem usar tabelas de nomes de serviço PPPoE como um método rudimentar para autenticar e autorizar os assinantes em interfaces lógicas PPPoE estáticas. Se a ACI ou o ARI do assinante 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 do agente, ID remoto do agente e nome de domínio. Por padrão, um ponto (.) é o delimitador entre os elementos do nome, mas você pode definir outros caracteres.

  • 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 oferecer suporte a CPEs que não oferecem suporte a um protocolo de autenticação e CPEs que o fazem.

Atribuição de endereços 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 Framed-Route-Address [8] na configuração do seu servidor RADIUS. Quando o RADIUS retorna o atributo com esse valor, o jpppd aceita automaticamente a designação de endereço IP do assinante fornecida pelo cliente em uma mensagem de solicitação de configuração do IPCP em vez de designar outro endereço.

Atributo da rota Tag2

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

A partir do Junos OS Release 18.2R1, você pode configurar seu servidor RADIUS para incluir o atributo tag2 no atributo Framed-Route [22] quando autenticar um assinante.

Você também deve configurar o perfil dinâmico para derivar o valor tag2 do atributo Framed-Route. Para fazer 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 de tag2 específico para um prefixo de rota de acesso específico.

Consulte 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 externo.

  • O atributo tag2 permite uma especificação mais detalhada de rotas.

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

Alguns provedores com configurações estáticas podem usar dispositivos CPE que não oferecem suporte a nenhum protocolo de autenticação, nem mesmo CHAP ou PAP. Os provedores podem usar tabelas de nomes de serviço PPPoE como um método rudimentar para autenticar e autorizar os assinantes em interfaces lógicas PPPoE estáticas. Se a ACI ou o ARI do assinante não corresponder 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 oferecem suporte a 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 para o uso de perfis dinâmicos em um roteador que executa o 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 ARI (ID remota) 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 encerrar o nome de usuário. O roteador adiciona o caractere @ como o delimitador para esta opção.

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

  2. Configure a senha do assinante.

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

Por exemplo, considere a seguinte configuração de exemplo, em que 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 Tag2 em perfis dinâmicos para assinantes IPv4 PPP terminados em estática

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

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

    • Especifique o valor.

  • Para derivar o valor tag2 de um servidor RADIUS:

    1. Configure seu servidor RADIUS para incluir o atributo tag2 no atributo Framed-Route [22] quando autenticar um assinante. Consulte a documentação do servidor RADIUS para obter informações de configuração. A configuração pode ser semelhante ao exemplo a seguir:

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

      A variável predefinida $junos-framed-route-ip-address-prefix deriva o prefixo de endereço IPv4 para a rota de acesso do atributo Framed-Route também.

Configurando a autenticação dinâmica para assinantes PPP

Você pode configurar um perfil dinâmico que inclui autenticação PPP que permite que clientes PPP acessem dinamicamente a rede. Você pode especificar a autenticação CHAP ou PAP. Opcionalmente, você também pode controlar a ordem na qual 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 PPP em um perfil dinâmico, a challenge-length autenticação CHAP oferece suporte à opção, que permite configurar o comprimento mínimo e o comprimento máximo da mensagem de desafio CHAP. Nem a autenticação CHAP nem a autenticação PAP oferecem suporte a outras opções de configuração, incluindo a passive declaração.

Observação:

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

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

  1. Nomeie o perfil dinâmico.
  2. Configure as interfaces e a unidade para o perfil dinâmico. Use 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 dos protocolos de autenticação.
  5. (Opcional) Configure o comprimento mínimo e o comprimento máximo da mensagem de desafio do CHAP.

    Consulte Modificando a duração do desafio CHAP.

  6. (Opcional) Configure a ordem na qual o roteador negocia os protocolos de autenticação CHAP e PAP.

    Consulte Controlando a Ordem de Negociação de Protocolos de Autenticação PPP.

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

    Consulte Garantindo a Negociação IPCP para Endereços DNS Primários e Secundários para obter mais informações.

Modificando a duração do desafio CHAP

Você pode modificar o comprimento mínimo padrão e o comprimento máximo da mensagem de desafio do Challenge Handshake Authentication Protocol (CHAP) que o roteador envia a um cliente PPP. A mensagem de desafio CHAP, que contém informações exclusivas de uma sessão de assinante PPP específica, é 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 comprimento mínimo e o comprimento máximo do desafio CHAP no intervalo de 8 bytes a 63 bytes.

Melhores práticas:

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

Antes de começar:

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

  1. Especifique que você deseja configurar as opções de PPP.

    • Para interfaces dinâmicas de assinante PPP:

    • Para interfaces estáticas com encapsulamento PPP:

  2. Especifique que deseja configurar as opções de CHAP.

    • Para interfaces dinâmicas de assinante PPP:

    • Para interfaces estáticas com encapsulamento PPP:

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

    • Para interfaces dinâmicas de assinante PPP:

    • Para interfaces estáticas com encapsulamento PPP:

    Por exemplo, a instrução a seguir challenge-length em um perfil dinâmico chamado pppoe-client-profile define o comprimento mínimo do desafio CHAP como 20 bytes e o comprimento máximo como 40 bytes.

Exemplo: perfil dinâmico PPPoE mínimo

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

Verificando e gerenciando a configuração do PPP para gerenciamento de assinantes

Finalidade

Exiba ou limpe informações sobre a configuração de PPP para 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 de resumo da sessão PPP:

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

Documentação relacionada

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.

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 do provedor 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úmero mágico.