Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Interfaces de serviço em linha L2TP LNS

Configuração de um L2TP LNS com interfaces de serviço em linha

A licença do recurso L2TP LNS deve ser instalada antes de você iniciar a configuração. Caso contrário, uma mensagem de aviso será exibida quando a configuração for confirmada.

Para configurar um L2TP LNS com interfaces de serviço em linha:

  1. (Opcional) Configure um perfil de grupo de usuários que defina a configuração de PPP para assinantes de túnel.
  2. (Opcional) Configure atributos PPP para assinantes em interfaces de serviço em linha.
  3. Configure a remontagem de IP em linha.
  4. Configure um perfil de acesso L2TP que defina os parâmetros L2TP para cada cliente LNS (LAC).
  5. (Opcional) Configure um perfil de acesso AAA para substituir o perfil de acesso configurado na instância de roteamento.
  6. Configure um pool de endereços a serem atribuídos dinamicamente aos assinantes PPP com túnel.
  7. Configure a interface de peer para encerrar o túnel e o endereço IPCP do lado do servidor PPP.
  8. Habilite interfaces de serviço em linha em um MPC.
  9. Configure uma interface de serviço.
  10. Configure opções para cada interface lógica de serviço em linha.
  11. (Opcional) Configure uma interface de serviço em linha agregada e redundância stateful 1:1.
  12. Configure o grupo de túneis L2TP.
  13. (Opcional) Configure um perfil dinâmico que crie dinamicamente interfaces lógicas L2TP.
  14. (Opcional) Configure um pool de interface de serviço para sessões dinâmicas do LNS.
  15. (Opcional) Especifique quantas vezes o L2TP retransmite mensagens de controle não confirmadas.
  16. (Opcional) Especifique por quanto tempo um túnel pode permanecer ocioso antes de ser desativado.
  17. (Opcional) Especifique o tamanho da janela de recebimento L2TP para o túnel L2TP. O tamanho da janela de recebimento especifica o número de pacotes que um peer pode enviar antes de aguardar uma confirmação do roteador.
  18. (Opcional) Especifique por quanto tempo o L2TP retém informações sobre túneis dinâmicos, sessões e destinos encerrados.
  19. (Opcional) Configure o tempo limite de bloqueio de destino L2TP.
  20. (Opcional) Configure a comutação de túnel L2TP.
  21. (Opcional) Impedir a criação de novas sessões, destinos ou túneis para L2TP.
  22. (Opcional) Configure se o protocolo de failover L2TP é negociado ou se o método de failover silencioso é usado para ressincronização.
  23. (Opcional) Habilite contadores de estatísticas SNMP.
  24. (Opcional) Configure opções de rastreamento para solucionar problemas da configuração.

Você também precisa configurar o CoS para sessões LNS. Para obter mais informações, consulte Configuração de CoS dinâmico para um serviço em linha L2TP LNS.

Aplicando atributos PPP a assinantes L2TP LNS por interface de serviço em linha

Você pode configurar atributos PPP que são aplicados pelo LNS na interface de serviço inline (si) aos assinantes PPP tunelados do LAC. Como você está configurando os atributos por interface em vez de com um perfil de grupo de usuários, os atributos para assinantes podem ser variados com uma granularidade mais fina. Essa configuração corresponde à usada para assinantes PPPoE encerrados.

Para configurar os atributos PPP para interfaces si criadas dinamicamente:

  1. Especifique a interface dinâmica predefinida e as variáveis de interface lógica no perfil dinâmico.
  2. Configure o intervalo entre as mensagens de keepalive do PPP para o túnel L2TP que termina no LNS.
  3. Configure métodos de autenticação PPP que se aplicam a assinantes PPP com túnel no LNS.
  4. Especifique um conjunto de opções AAA que é usado para autenticação e autorização de assinantes PPP encapsulados no LNS que estão fazendo login por meio dos contextos de assinante e AAA especificados no conjunto de opções AAA.

    O conjunto de opções é configurado com a aaa-options aaa-options-name declaração no nível da [edit access] hierarquia.

  5. Configure o roteador para solicitar que o Customer Premises Equipment (CPE) negocie endereços DNS primários e secundários durante a negociação do IPCP para assinantes PPP com túnel no LNS.
  6. (Opcional) Desabilite a validação do número mágico do PPP durante a negociação do LCP e nas trocas de keepalive do LCP (echo-request/echo-reply). Impede a comparação do número mágico recebido com o número mágico gerado internamente, para que uma incompatibilidade não cause o encerramento da sessão.

Para configurar os atributos PPP para interfaces si criadas estaticamente:

  1. Especifique a interface de serviço lógica em linha.

  2. Configure o intervalo entre as mensagens de keepalive do PPP para o túnel L2TP que termina no LNS.

  3. Configure o número de pacotes keepalive que um destino deve deixar de receber antes que a rede desative um link.

    Observação:

    A keepalives up-count opção normalmente não é usada para gerenciamento de assinantes.

  4. Configure métodos de autenticação PPP que se aplicam a assinantes PPP com túnel no LNS.

  5. Configure o roteador para solicitar que o Customer Premises Equipment (CPE) negocie os endereços DNS primários e secundários durante a negociação do IPCP para assinantes PPP com túnel no LNS.

Melhores práticas:

Embora todas as outras instruções subordinadas a ppp-options—incluindo aquelas subordinadas a chap e pap—sejam suportadas, elas normalmente não são usadas para gerenciamento de assinantes. Recomendamos que você deixe essas outras instruções com seus valores padrão.

Observação:

Você também pode configurar atributos PPP com um perfil de grupo de usuários que aplica os atributos a todos os assinantes com esse perfil em um cliente LAC. Consulte Aplicando atributos PPP a assinantes L2TP LNS com um perfil de grupo de usuários para obter mais informações. Quando você configura os atributos PPP para assinantes L2TP LNS na interface si e nos perfis de grupo de usuários, a configuração da interface de serviço em linha tem precedência sobre a configuração do perfil do grupo de usuários.

Observação:

Quando as opções de PPP são configuradas em um perfil de grupo e dinâmico, a configuração de perfil dinâmico tem precedência completa sobre o perfil de grupo quando o perfil dinâmico inclui uma ou mais das opções de PPP que podem ser configuradas no perfil de grupo. A precedência completa significa que não há mesclagem de opções entre os perfis. O perfil de grupo é aplicado ao assinante somente quando o perfil dinâmico não inclui nenhuma opção PPP disponível no perfil de grupo.

Aplicando atributos PPP a assinantes L2TP LNS com um perfil de grupo de usuários

Você pode configurar um perfil de grupo de usuários que permite que o LNS aplique atributos PPP aos assinantes PPP tunelados do LAC. O perfil do grupo de usuários está associado a clientes (LACs) no perfil de acesso L2TP. Consequentemente, todos os assinantes tratados por um determinado cliente compartilham os mesmos atributos PPP.

Para configurar um perfil de grupo de usuários:

  1. Crie o perfil.
  2. Configure o intervalo entre as mensagens de keepalive do PPP para o túnel L2TP que termina no LNS.
    Observação:

    As alterações no intervalo de keepalive em um perfil de grupo de usuários afetam apenas as novas sessões L2TP que surgem após a alteração. As sessões existentes não são afetadas.

  3. Configure métodos de autenticação PPP que se aplicam a assinantes PPP com túnel no LNS.
  4. Especifique um conjunto de opções AAA que é usado para autenticação e autorização de assinantes PPP encapsulados no LNS que estão fazendo login por meio dos contextos de assinante e AAA especificados no conjunto de opções AAA.

    O conjunto de opções é configurado com a aaa-options aaa-options-name declaração no nível da [edit access] hierarquia.

  5. Configure o roteador para solicitar que o Customer Premises Equipment (CPE) negocie os endereços DNS primários e secundários durante a negociação do IPCP para assinantes PPP com túnel no LNS.
  6. (Opcional) Desabilite o Mecanismo de Encaminhamento de Pacotes de executar uma verificação de validação para números mágicos PPP recebidos de um peer remoto em trocas de keepalive LCP (Echo-Request/Echo-Reply). Isso impede que o PPP encerre a sessão quando o número não corresponder ao valor acordado durante a negociação do LCP. Esse recurso é útil quando os pares PPP remotos incluem números mágicos arbitrários nos pacotes keepalive. 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.
  7. Configure por quanto tempo a sessão do assinante PPP pode ficar ociosa antes de ser considerada como tendo atingido o tempo limite.
Observação:

Você também pode configurar atributos PPP por interface. Consulte Aplicando atributos PPP a assinantes L2TP LNS por interface de serviço em linha para obter mais informações. Quando você configura os atributos PPP para assinantes L2TP LNS na interface si e nos perfis de grupo de usuários, a configuração da interface de serviço em linha tem precedência sobre a configuração do perfil do grupo de usuários.

Observação:

Quando as opções de PPP são configuradas em um perfil de grupo e dinâmico, a configuração de perfil dinâmico tem precedência completa sobre o perfil de grupo quando o perfil dinâmico inclui uma ou mais das opções de PPP que podem ser configuradas no perfil de grupo. A precedência completa significa que não há mesclagem de opções entre os perfis. O perfil de grupo é aplicado ao assinante somente quando o perfil dinâmico não inclui nenhuma opção PPP disponível no perfil de grupo.

Configuração de um perfil de acesso L2TP no LNS

Os perfis de acesso definem como validar conexões e solicitações de sessão do Protocolo de Tunelamento de Camada 2 (L2TP). Em cada perfil de acesso L2TP, você configura um ou mais clientes (LACs). As características do cliente são usadas para autenticar LACs com senhas correspondentes e para estabelecer atributos do túnel e da sessão do cliente. Você pode configurar vários perfis de acesso e vários clientes em cada perfil.

Para configurar um perfil de acesso L2TP:

  1. Crie o perfil de acesso.
  2. Configure características para um ou mais clientes (LACs).
    Observação:

    Exceto no caso especial do cliente, o nome do default cliente LAC que você configura no perfil de acesso deve corresponder ao nome de host do LAC. No caso de um roteador da Juniper Networks atuando como LAC, o nome de host é configurado no perfil de túnel LAC com a gateway gateway-name declaração no [edit access tunnel-profile profile-name tunnel tunnel-id source-gateway] nível de hierarquia. Como alternativa, o nome do cliente pode ser retornado de RADIUS no atributo Tunnel-Client-Auth-Id [90].

    Observação:

    Use default como o nome do cliente quando quiser definir um cliente de túnel padrão. O cliente padrão permite a autenticação de vários LACs com o mesmo segredo e atributos L2TP. Esse comportamento é útil quando, por exemplo, muitos novos LACs são adicionados à rede, pois permite que os LACs sejam usados sem configuração adicional de perfil LNS.

    Use default apenas em roteadores da Série MX. O nome de cliente equivalente nos roteadores da Série M é *.

  3. (Opcional) Especifique um perfil de acesso local que substitua o perfil de acesso global e o perfil de acesso AAA do grupo de túneis para definir as configurações do servidor RADIUS para o cliente.
  4. Configure o LNS para renegociar o protocolo de controle de enlace (LCP) com o cliente PPP. encapsulado a partir do cliente.
  5. Configure um ou mais perfis de serviço dinâmicos para aplicar serviços a todos os assinantes do LAC. Opcionalmente, você pode passar o parâmetro para os serviços na mesma instrução.
  6. Configure o número máximo de sessões permitidas em um túnel do cliente (LAC).
  7. Configure o LNS para substituir os códigos de resultado 4 e 5 pelo código de resultado 2 nas mensagens CDN que ele envia ao LAC quando o número de sessões L2TP atinge o valor máximo configurado. Alguns LACs de terceiros não podem fazer failover para outro LNS, a menos que o código de resultado tenha um valor de 2.
  8. Configure a senha do túnel usada para autenticar o cliente (LAC).
  9. (Opcional) Associe um perfil de grupo contendo atributos PPP para aplicar às sessões PPP que estão sendo tunelamentadas a partir deste cliente LAC.
    Observação:

    Se user-group-profile for modificado ou excluído, os assinantes LNS existentes, que estavam usando essa configuração de cliente do Protocolo de Tunelamento de Camada 2, ficarão inativos.

Configuração de um perfil de acesso local AAA no LNS

Para alguns túneis LNS, talvez você queira substituir o perfil de acesso configurado na instância de roteamento que hospeda o túnel por uma configuração específica do servidor RADIUS. Você pode configurar um perfil de acesso local para fazer isso. Posteriormente, você pode usar a aaa-access-profile instrução para aplicar o perfil de acesso local a um grupo de túneis ou cliente LAC.

Um perfil de acesso local aplicado a um cliente substitui um perfil de acesso local aplicado a um grupo de túneis, que por sua vez substitui o perfil de acesso para a instância de roteamento.

Para configurar um perfil de acesso local AAA:

  1. Crie o perfil de acesso.
  2. Configure a ordem dos métodos de autenticação AAA.
  3. Configure os atributos do servidor RADIUS, como a senha de autenticação.

Configuração de um pool de atribuição de endereços para L2TP LNS com serviços em linha

Você pode configurar pools de endereços que podem ser atribuídos dinamicamente aos assinantes PPP com túnel. Os pools devem ser locais para a instância de roteamento em que o assinante aparece. Os pools configurados são fornecidos nos atributos RADIUS Framed-Pool e Framed-IPv6-Pool. Os pools são opcionais quando Framed-IP-Address é enviado por RADIUS.

Para configurar um pool de atribuição de endereços, você deve especificar o nome do pool e configurar os endereços para o pool.

Opcionalmente, você pode configurar vários intervalos nomeados, ou subconjuntos, de endereços em um pool de atribuição de endereços. Durante a atribuição dinâmica de endereços, um cliente pode receber um endereço de um intervalo nomeado específico. Para criar um intervalo nomeado, especifique um nome para o intervalo e defina o intervalo de endereços.

Observação:

Certifique-se de usar a address-assignment pools (address-assignment) declaração em vez da address pools (address-pool) declaração.

Para obter mais informações sobre pools de atribuição de endereços, consulte Visão geral dos pools de atribuição de endereços e Visão geral da configuração do pool de atribuição de endereços.

Para configurar um pool de atribuição de endereços IPv4 para L2TP LNS:

  1. Configure o nome do pool e especifique a família IPv4.
  2. Configure o endereço de rede e o comprimento do prefixo dos endereços no pool.
  3. Configure o nome do intervalo e os limites inferior e superior dos endereços no intervalo.

Por exemplo, para configurar um pool de atribuição de endereços IPv4:

Para configurar um pool de atribuição de endereços IPv6 para L2TP LNS:

  1. Configure o nome do pool e especifique a família IPv6.

  2. Configure o prefixo de rede IPv6 para o pool de endereços. A especificação de prefixo é necessária quando você configura um pool de atribuição de endereços IPv6.

  3. Configure o nome do intervalo e defina o intervalo. Você pode definir o intervalo com base nos limites inferior e superior dos prefixos no intervalo ou com base no comprimento dos prefixos no intervalo.

Por exemplo, para configurar um pool de atribuição de endereços IPv6:

Configuração da interface de peer L2TP LNS

A interface de peer conecta o LNS à nuvem em direção aos LACs para que os pacotes IP possam ser trocados entre os endpoints do túnel. MPLS e Ethernet agregada também podem ser usados para alcançar os LACs.

Observação:

Nos roteadores da Série MX, você deve configurar a interface peer em um MPC.

Para configurar a interface peer LNS:

  1. Especifique o nome da interface.
  2. Habilite VLANs.
  3. Especifique a interface lógica, vincule um ID de tag VLAN à interface e configure a família de endereços e o endereço IP para a interface lógica.
    Observação:

    A família de endereços IPv6 não é suportada como um endpoint de túnel.

Habilitação de interfaces de serviço em linha

A interface de serviço em linha é uma interface física virtual que reside no Mecanismo de Encaminhamento de Pacotes. Essa si interface, conhecida como interface âncora , possibilita fornecer serviços L2TP sem um PIC de serviços especiais. A interface de serviço em linha é suportada apenas por MPCs em roteadores da Série MX. Quatro interfaces de serviço em linha são configuráveis por slot de chassi ocupado por MPC.

Observação:

Nos roteadores MX80 e MX104, você pode configurar apenas quatro interfaces físicas de serviços em linha como interfaces âncora para sessões L2TP LNS: si-1/0/0, si-1/1/0, si-1/2/0 e si-1/3/0. Você não pode configurar si-0/0/0 para essa finalidade em roteadores MX80 e MX104.

Embora o intervalo de valores de largura de banda seja de 1 Gbps a 400 Gbps, você não pode configurar a largura de banda em números absolutos, como 12.345.878.000 bps. Você deve usar as opções disponíveis na instrução CLI:

  • 1g

  • 10gem 100g incrementos de 10 Gbps: 10g, 20g, 90g70g50g80g30g40g60g,100g

  • 100g até 400g em incrementos de 100 Gbps: 100g, 200g, 300g, 400g

A largura de banda máxima disponível varia entre os MPCs, conforme mostrado na Tabela 1. Uma mensagem de log do sistema é gerada quando você configura uma largura de banda maior do que a suportada no MPC.

Tabela 1: Largura de banda máxima para serviços em linha por MPC

MPC

Largura de banda máxima suportada

MPC2E NG, MPC2E NG Q,

80 Gbps

MPC3E NG, MPC3E NG Q

130 Gbps

100GE e 40GE MPC3 e MICs

40 Gbps

MPC4E

130 Gbps

MPC5E

130 Gbps

MPC6E

130 Gbps

MPC7E

240 Gbps

MPC8E

240 Gbps

400 Gbps no modo atualizado de 1,6 Tbps

MPC9E

400 Gbps

Para habilitar interfaces de serviço em linha:

  1. Acesse um slot ocupado por MPC e o PIC onde a interface deve ser habilitada.
  2. Habilite a interface e, opcionalmente, especifique a quantidade de largura de banda reservada em cada Mecanismo de Encaminhamento de Pacotes para tráfego de túnel usando serviços em linha. A partir do Junos OS Release 16.2, você não precisa especificar explicitamente uma largura de banda para o tráfego de túnel L2TP LNS usando serviços em linha. Quando você não especifica uma largura de banda, a largura de banda máxima suportada no PIC fica automaticamente disponível para os serviços em linha; Os serviços em linha podem usar até esse valor máximo. Em versões anteriores, você deve especificar uma largura de banda ao habilitar serviços embutidos com a inline-services instrução.

Configuração de uma interface de serviço em linha para L2TP LNS

A interface de serviço em linha é uma interface de serviço física virtual que reside no Mecanismo de Encaminhamento de Pacotes. Essa si interface, conhecida como interface âncora , possibilita fornecer serviços L2TP sem um PIC de serviços especiais. A interface de serviço em linha é suportada apenas por MPCs em roteadores da Série MX. Quatro interfaces de serviço em linha são configuráveis por slot de chassi ocupado por MPC.

Você pode maximizar o número de sessões que podem ser moldadas em uma interface de serviço definindo o número máximo de níveis de hierarquia como dois. Nesse caso, cada sessão do LNS consome um nó L3 na hierarquia do agendador para formatação.

Se você não especificar o número de níveis (dois é a única opção), o número de sessões LNS que podem ser moldadas na interface de serviço será limitado ao número de nós L2 ou 4096 sessões. Sessões adicionais ainda surgem, mas não são moldadas.

Para configurar uma interface de serviço em linha:

  1. Acesse a interface de serviço.
  2. (Opcional; somente para modelagem por sessão) Habilite a interface de serviço embutida para agendadores hierárquicos e limite o número de níveis de agendador a dois.
  3. (Opcional; somente para modelagem por sessão) Configure o encapsulamento de serviços para interface de serviço em linha.
  4. Configure a família IPv4 na interface lógica da unidade reservada 0.

Configuração de opções para a interface lógica de serviços em linha do LNS

Você deve especificar características —dial-options para cada uma das interfaces lógicas de serviços em linha configuradas para o LNS. O LNS nos roteadores da Série MX oferece suporte a apenas uma sessão por interface lógica, portanto, você deve configurá-lo como uma dedicated interface; a shared opção não é suportada. (LNS em roteadores da Série M oferece suporte dedicated e shared opções.) Você também configura um nome de identificação para a interface lógica que corresponde ao nome especificado no perfil de acesso.

Você deve especificar a família de inet endereços para cada interface lógica estática ou no perfil dinâmico para interfaces LNS dinâmicas. Embora a CLI aceite ou inet inet6 para interfaces lógicas estáticas, o assinante não pode efetuar login com êxito, a menos que a família inet de endereços esteja configurada.

Observação:

Para obter a configuração da interface dinâmica, consulte Configuração de um perfil dinâmico para sessões dinâmicas do LNS.

Para configurar as opções de interface lógica estática:

  1. Acesse a interface lógica de serviços em linha.
  2. Especifique um identificador para a interface lógica.
  3. Configure a interface lógica para ser usada apenas para uma sessão por vez.
  4. Configure a família de endereços para cada interface lógica e habilite o endereço local no LNS que fornece terminação local para o túnel L2TP seja derivado do nome de interface especificado.

Visão geral da redundância stateful do LNS 1:1

Por padrão, quando uma interface de âncora de serviço inline (si) fica inativa — por exemplo, quando a placa que hospeda a interface falha ou é reiniciada — o tráfego de assinante L2TP é perdido. Quando o temporizador de keepalive PPP para o túnel expira subsequentemente, o plano de controle fica inativo e o cliente PPP é desconectado. Consequentemente, o cliente deve se reconectar.

Você pode evitar a perda de tráfego nessas circunstâncias configurando um pacote agregado de interface de serviço em linha (asi) para fornecer redundância stateful 1:1, também chamada de hot standby ou redundância de backup ativo. O pacote consiste em um par de interfaces físicas si, o link de membro primário (ativo) e o link de membro secundário (standby ou backup). Essas interfaces devem ser configuradas em diferentes MPCs; a redundância não é alcançável se você configurar a interface primária e secundária no mesmo MPC porque ambas as interfaces de membros ficam inativas se a placa cair.

Quando os assinantes fazem login e a redundância 1:1 é configurada, a sessão L2TP é estabelecida em uma interface lógica virtual subjacente (asi.0x) na interface física asi0. Interfaces lógicas de assinante individuais são criadas na interface subjacente no formato, asiX.logical-unit-number. A sessão permanece ativa em caso de falha ou reinicialização no MPC que hospeda a interface do enlace do membro primário. Todo o tráfego de dados destinado a essa sessão L2TP é movido automaticamente para a interface de enlace de membro secundário no outro MPC.

Configuração da redundância stateful 1:1 LNS em interfaces de serviço em linha agregadas

Você pode criar um pacote agregado de interface de serviço em linha (asi) para fornecer redundância stateful 1:1 LNS para interfaces de âncora de serviço em linha (si). O pacote emparelha duas interfaces que residem em diferentes MPCs como links primários e secundários. As sessões do LNS são subseqüentemente estabelecidas em uma interface lógica virtual, asiX.logical-unit-number. O failover de sessão LNS ocorre quando a interface de âncora primária fica inativa ou a placa é reiniciada com o request chassis fpc restart comando. Quando isso acontece, o enlace secundário — em um MPC diferente — torna-se ativo e todo o tráfego de dados LNS destinado à sessão é movido automaticamente para a interface secundária. A sessão do assinante permanece ativa na interface virtual asiX.logical-unit-number Nenhuma estatística de tráfego é perdida. Quando essa redundância não está configurada, o tráfego do assinante é perdido, os keepalives expiram e o cliente PPP é desconectado e deve se reconectar.

Antes de começar, você deve fazer o seguinte:

Melhores práticas:

Siga estas diretrizes:

  • Você deve configurar unit 0 family inet para cada pacote; caso contrário, a sessão não será ativada.

  • As interfaces primária (ativa) e secundária (backup) devem estar em MPCs diferentes.

  • A largura de banda configurada no nível da [edit chassis fpc slot pic number inline-services bandwidth] hierarquia deve ser a mesma para ambos os links de membros.

  • Uma interface si configurada como membro de um pacote configurável de interface de serviço em linha agregada não pode ser configurada como membro de outro grupo de pacotes.

  • Uma interface si configurada como membro de um pacote de interface de serviço em linha agregada também não pode ser usada para nenhuma função que não esteja relacionada a serviços agregados; por exemplo, ele não pode ser usado para remontagem de IP em linha.

  • Quando você configura uma interface si como membro de um pacote de serviços em linha agregado, você não pode mais configurar essa interface si de forma independente. Você pode configurar apenas o pacote pai; A configuração do pacote é aplicada imediatamente a todas as interfaces de membros.

Para configurar a redundância stateful 1:1 LNS:

  1. Em um MPC, especifique o link de membro de serviços em linha primário (ativo) no pacote.
  2. Configure a quantidade de largura de banda reservada neste MPC para tráfego de túnel usando a interface de serviço em linha primária.
  3. Em um MPC diferente, especifique o link de membro de serviços em linha secundário (backup) no pacote.
    Observação:

    Se você configurar os links de membros ativos e de backup no mesmo MPC, a confirmação subsequente da configuração falhará.

  4. Configure a quantidade de largura de banda reservada neste MPC para tráfego de túnel usando a interface de serviço em linha secundária.
  5. Atribua o pacote configurável de interface de serviço em linha agregado a um grupo de túneis L2TP por um dos seguintes métodos:
    • Designe um único pacote especificando o nome da interface física do serviço em linha agregada.

    • Designe um ou mais conjuntos de pacotes configuráveis ao grupo de túneis.

      Observação:

      Uma piscina pode ser mista; ou seja, pode incluir pacotes de interface de serviço em linha agregados e interfaces de serviço em linha individuais. As interfaces individuais não devem ser membros de pacotes existentes.

A configuração de exemplo a seguir cria o pacote asi0 com links de membros em MPCs no slot 1 e no slot 2 e, em seguida, atribui o pacote para fornecer redundância para sessões L2TP no grupo de túnel tg1:

Verificando a redundância 1:1 da interface de serviço em linha agregada do LNS

Finalidade

Veja informações sobre pacotes agregados de interface de serviço em linha, links de membros individuais e status de redundância.

Ação

  • Para exibir informações resumidas sobre um pacote configurável de interface de serviço em linha agregado:

  • Para exibir informações detalhadas sobre um pacote de interface de serviço em linha agregado:

  • Para visualizar informações sobre uma interface de membro individual em um pacote configurável de interface de serviço em linha agregado:

  • Para exibir o status de redundância para pacotes de interface de serviço em linha agregados:

    Essa saída de exemplo mostra que as interfaces de serviço Ethernet agregadas e em linha agregadas estão configuradas para redundância. Para exibir apenas um dos pacotes configuráveis de interface de serviço em linha agregados:

  • Para exibir informações detalhadas sobre todas as interfaces de redundância configuradas:

Limites de sessão L2TP e balanceamento de carga para interfaces de serviço

A carga do LNS equilibra as sessões de assinantes nas interfaces de serviço disponíveis em um pool de dispositivos com base no número de sessões atualmente ativas nas interfaces. Você pode configurar um limite máximo por interface de serviço (si) e por interface de serviço agregada (asi). No caso de interfaces asi, você não pode configurar um limite para as interfaces de membros si individuais no pacote.

Limites de sessão em interfaces de serviço

Quando uma solicitação de sessão L2TP é iniciada para uma interface de serviço, o LNS verifica o número de sessões ativas atuais nessa interface em relação ao número máximo de sessões permitidas para a interface de serviço individual ou a interface de serviço agregada. O LNS determina se a contagem de sessões atual (exibida pelo show services l2tp summary comando) é menor que o limite configurado. Quando isso é verdade ou quando nenhum limite é configurado, a verificação é aprovada e a sessão pode ser estabelecida. Se a contagem de sessões atual for igual ao limite configurado, o LNS rejeitará a solicitação de sessão. Nenhuma solicitação subsequente pode ser aceita nessa interface até que o número de solicitações ativas caia abaixo do máximo configurado. Quando uma solicitação de sessão é rejeitada para uma interface si ou asi, o LNS retorna uma mensagem CDN com o código de resultado definido como 2 e o código de erro definido como 4.

Por exemplo, suponha que uma única interface de serviço esteja configurada no grupo de túneis. A contagem de sessões L2TP atual é de 1500, com um limite configurado de 2000 sessões. Quando uma nova sessão é solicitada, a verificação de limite é aprovada e a solicitação de sessão é aceita.

Interface

Limite de sessão configurado

Contagem de sessões atuais

Resultado da verificação de limite de sessão

si-0/0/0

2000

1500

Passe

A verificação de limite continua a ser aprovada e as solicitações de sessão são aceitas até que 500 solicitações sejam aceitas, fazendo com que a sessão atual conte 2000, o que corresponde ao máximo configurado. A verificação de limite de sessão falha para todas as solicitações subsequentes e todas as solicitações são rejeitadas até que a contagem de sessões atual na interface caia abaixo de 2000, para que a verificação de limite possa ser aprovada.

Interface

Limite de sessão configurado

Contagem de sessões atuais

Resultado da verificação de limite de sessão

si-0/0/0

2000

2000

Falha

Quando o limite de sessão é definido como zero para uma interface, nenhuma solicitação de sessão pode ser aceita. Se essa for a única interface no grupo de túneis, todas as solicitações de sessão no grupo serão rejeitadas até que o limite de sessão seja aumentado de zero ou outra interface de serviço seja adicionada ao grupo de túneis.

Quando uma interface de serviço Em um pool de dispositivos de serviço atinge o limite máximo configurado ou tem um limite configurado de zero, o LNS ignora essa interface quando uma solicitação de sessão é feita e seleciona outra interface no pool para verificar o limite da sessão. Isso continua até que uma interface seja aprovada e a sessão seja aceita ou nenhuma outra interface permaneça no pool a ser selecionada.

Balanceamento de carga de sessão entre interfaces de serviço

O comportamento da distribuição de carga de sessão em um pool de dispositivos de serviço mudou no Junos OS Release 16.2. Quando uma interface de serviço tem uma contagem de sessões menor do que outra interface no pool e ambas as interfaces estão abaixo do limite máximo de sessão, as sessões subsequentes são distribuídas para a interface com menos sessões.

Em versões anteriores, as sessões são distribuídas de maneira estritamente round-robin, independentemente da contagem de sessões. O comportamento antigo pode resultar em distribuição de sessão desigual quando o Mecanismo de Encaminhamento de Pacotes é reinicializado ou uma interface de serviço fica inativa e volta a funcionar.

Por exemplo, considere o seguinte cenário usando o antigo comportamento de distribuição round-robin para um pool com duas interfaces de serviço:

  1. Duzentas sessões são distribuídas igualmente entre as duas interfaces de serviço.

    • si-0/0/0 tem 100 sessões.

    • si-1/0/0 tem 100 sessões.

  2. A interface si-1/0/0 é reinicializada. Quando volta, inicialmente as sessões estão ativas apenas no si-0/0/0.

    • si-0/0/0 tem 100 sessões.

    • si-1/0/0 tem 0 sessões.

  3. À medida que as sessões anteriormente no si-1/0/0 se reconectam, elas são distribuídas igualmente em ambas as interfaces de serviço. Quando todas as 100 sessões estão de volta, a distribuição é significativamente desequilibrada.

    • si-0/0/0 tem 150 sessões.

    • si-1/0/0 tem 50 sessões.

  4. Após a conexão de 100 novas sessões, o si-0/0/0 atinge seu limite máximo. Sessões subseqüentes são aceitas somente em si-1/0/0.

    • si-0/0/0 tem 200 sessões.

    • si-1/0/0 tem 100 sessões.

  5. Após mais 100 sessões de conexão, si-1/0/0 atinge seu limite máximo. Nenhuma outra sessão pode ser aceita até que a contagem de sessões caia abaixo de 200 para uma das interfaces.

    • si-0/0/0 tem 200 sessões.

    • si-1/0/0 tem 200 sessões.

Agora, considere o mesmo cenário usando o comportamento de distribuição de carga atual com base no número de sessões anexadas. O pool de dispositivos novamente tem duas interfaces de serviço, cada uma com um limite máximo configurado de 200 sessões:

  1. Duzentas sessões são distribuídas igualmente entre as duas interfaces de serviço.

    • si-0/0/0 tem 100 sessões.

    • si-1/0/0 tem 100 sessões.

  2. A interface si-1/0/0 é reinicializada. Quando ele volta, as sessões estão ativas inicialmente apenas em si-0/0/0.

    • si-0/0/0 tem 100 sessões.

    • si-1/0/0 tem 0 sessões.

  3. À medida que as sessões anteriormente no si-1/0/0 se reconectam, elas são distribuídas de acordo com a carga da sessão em cada interface. Como ambas as interfaces estão abaixo de seu limite máximo e si-1/0/0 tem menos sessões que si-0/0/0, as sessões são inicialmente distribuídas apenas para si-1/0/0.

    1. Após 1 nova sessão:

      • si-0/0/0 tem 100 sessões.

      • si-1/0/0 tem 1 sessão.

    2. Após 10 novas sessões:

      • si-0/0/0 tem 100 sessões.

      • SI-1/0/0 tem 10 sessões.

    3. Após 100 novas sessões:

      • si-0/0/0 tem 100 sessões.

      • si-1/0/0 tem 100 sessões.

  4. Como ambas as interfaces agora têm a mesma contagem de sessões, a próxima sessão (#101) é distribuída aleatoriamente entre as duas interfaces. A próxima sessão depois disso (#102) vai para a interface com a menor contagem de sessões. Isso torna as interfaces iguais novamente, então a próxima sessão (# 103) é distribuída aleatoriamente. Esse padrão se repete até o limite máximo de 200 sessões para ambas as interfaces.

    • si-0/0/0 tem 200 sessões.

    • si-1/0/0 tem 200 sessões.

    Nenhuma sessão pode ser aceita em nenhuma das interfaces até que o número de sessões caia abaixo de 200 em uma das interfaces.

O comportamento do balanceamento de carga é o mesmo para interfaces de serviço agregadas. Uma interface asi é selecionada em um pool com base na contagem de sessões atual para a interface asi. Quando essa contagem é menor que o máximo, o LNS verifica a contagem de sessões atual para a interface si ativa no pacote asi. Quando essa contagem é menor que o máximo, a sessão pode ser estabelecida na interface asi.

Em um pool de dispositivos misto que tem interfaces de serviço e interfaces de serviço agregadas, as sessões são distribuídas para a interface, asi ou si, que tem a menor contagem de sessões. Quando a contagem de sessões de uma interface de qualquer tipo atinge seu limite, ela não pode mais aceitar sessões até que a contagem caia abaixo do máximo.

Você pode usar a configuração de limite de sessão para atingir um limite de sessão em mecanismos de encaminhamento de pacotes específicos. Suponha que você queira um limite de 100 sessões em um PFE0, que tem duas interfaces de serviço. Você pode definir o limite máximo em cada interface como 50 ou qualquer outra combinação que some 100 para estabelecer o limite PFE0.

Exemplo: configurar um LNS L2TP

Este exemplo mostra como você pode configurar um L2TP LNS em um roteador da Série MX para fornecer endpoints de túnel para um LAC L2TP em sua rede. Essa configuração inclui um perfil dinâmico para assinantes de pilha dupla.

Requerimentos

Este exemplo de L2TP LNS requer o seguinte hardware e software:

  • Plataforma de roteamento universal 5G da Série MX

  • Um ou mais MPCs

  • Junos OS versão 11.4 ou posterior

Nenhuma configuração especial além da inicialização do dispositivo é necessária antes que você possa configurar esse recurso.

Você deve configurar determinados atributos RADIUS padrão e VSAs da Juniper Networks na lista de retorno de atributos no servidor AAA associado ao LNS para que este exemplo funcione. A Tabela 2 lista os atributos com suas configurações e valores de ordem necessários. Recomendamos que você use o dicionário RADIUS Juniper Networks mais atual, disponível na caixa Downloads na página Gerenciamento de Assinantes do Junos OS em https://www.juniper.net/documentation/en_US/junos/information-products/pathway-pages/subscriber-access/index.html.

Tabela 2: Nomes de atributos VSA e RADIUS padrão, ordem e valores necessários, por exemplo

Nome da VSA [Número]

Ordem

Valor

Tipo de parâmetro CoS [26–108]

1

T01 Multiplay

Tipo de parâmetro CoS [26–108]

2

T02 10m

Tipo de parâmetro CoS [26–108]

3

T08 -36

Tipo de parâmetro CoS [26–108]

4

T07 modo de célula

Pool IPv6 emoldurado [100]

0

jnpr_ipv6_pool

Quadro-associação (88)

0

jnpr_pool

Nome da política de saída [26-11]

0

classificar

Nome da política de entrada [26-10]

0

classificar

Roteador virtual [26-1]

0

padrão

Visão geral

O LNS emprega perfis de grupo de usuários para aplicar atributos PPP aos assinantes PPP que são tunelados do LAC. Os LACs na rede são clientes do LNS. Os clientes estão associados a perfis de grupo de usuários no perfil de acesso L2TP configurado no LNS. Neste exemplo, o perfil ce-l2tp-group-profile do grupo de usuários especifica os seguintes atributos PPP:

  • Um intervalo de 30 segundos entre as mensagens de keepalive PPP para túneis L2TP do LAC do cliente terminando no LNS.

  • Um intervalo de 200 segundos que define por quanto tempo a sessão do assinante PPP pode ficar ociosa antes de ser considerada como tendo atingido o tempo limite.

  • PAP e CHAP como os métodos de autenticação PPP que se aplicam a assinantes PPP com túnel no LNS.

O perfil ce-l2tp-profile de acesso L2TP define um conjunto de parâmetros L2TP para cada LAC cliente. Neste exemplo, o perfil ce-l2tp-group-profile do grupo de usuários está associado a clientes e lac2. lac1 Ambos os clientes são configurados para que o LNS renegocie o protocolo de controle de enlace (LCP) com o cliente PPP, em vez de aceitar os parâmetros LCP pré-negociados que os LACs passam para o LNS. A renegociação do LCP também faz com que a autenticação seja renegociada pelo LNS; O método de autenticação é especificado no perfil do grupo de usuários. O número máximo de sessões permitidas por túnel é definido como 1000 para lac1 e como 4000 para lac2. Uma senha diferente é configurada para cada LAC.

Um perfil de acesso AAA local, aaa-profile, permite que você substitua o perfil de acesso AAA global, para que você possa especificar uma ordem de autenticação, um servidor RADIUS que deseja usar para L2TP e uma senha para o servidor.

Neste exemplo, um pool de endereços define um intervalo de endereços IP que o LNS aloca para as sessões PPP em túnel. Este exemplo define intervalos de endereços IPv4 e IPv6.

Duas interfaces de serviço em linha são habilitadas no MPC localizado no slot 5 do roteador. Para cada interface, 10 Gbps de largura de banda são reservados para o tráfego de túnel no PFE associado à interface. Essas interfaces âncora servem como a interface física subjacente. Para habilitar o suporte à fila de CoS nas interfaces de serviço lógicas em linha individuais, você deve configurar o encapsulamento de serviços (generic-services) e o suporte ao agendamento hierárquico nas âncoras. A família de endereços IPv4 é configurada para ambas as interfaces de âncora. Ambas as interfaces de âncora são especificadas no pool de dispositivos de lns_p1 serviço. O LNS pode equilibrar as cargas de tráfego nas duas interfaces âncora quando o grupo de túneis inclui o pool.

Este exemplo usa o perfil dyn-lns-profile2 dinâmico para especificar características das sessões L2TP que são criadas ou atribuídas dinamicamente quando um assinante é tunelado para o LNS. Para muitas das características, uma variável predefinida é definida; as variáveis são substituídas dinamicamente pelos valores apropriados quando um assinante é tunelado para o LNS.

A interface à qual o cliente PPP em túnel se conecta ($junos-interface-name) é criada dinamicamente na instância de roteamento ($junos-routing-instance) atribuída ao assinante. As opções de roteamento para rotas de acesso incluem o endereço do próximo salto da rota ($junos-framed-route-nexthop), métrica ($junos-framed-route-cost) e preferência ($junos-framed-route-distance). Para rotas internas de acesso, uma variável de endereço IP dinâmico ($junos-subscriber-ip-address) é definida.

As interfaces lógicas de serviço em linha são definidas pelo nome de uma interface âncora configurada ($junos-interface-ifd-name) e um número de unidade lógica ($junos-interface-unit). O perfil é atribuído l2tp-encapuslation como o identificador para a interface lógica e especifica que cada interface pode ser usada apenas para uma única sessão por vez.

O endereço IPv4 é definido como um valor retornado do servidor AAA. Para tráfego IPv4, um filtro $junos-input-filter de firewall de entrada e um filtro $junos-output-filter de firewall de saída são anexados à interface. A variável de loopback ($junos-loopback-interface) deriva um endereço IP de uma interface de loopback (lo) configurada na instância de roteamento e o usa na negociação IPCP como o endereço do servidor PPP. Por se tratar de uma configuração de pilha dupla, a família de endereços IPv6 também é definida, com os endereços fornecidos pela $junos-ipv6-address variável.

A $junos-ipv6-address variável é usada porque o Protocolo de Anúncio de Roteador também está configurado. Essa variável permite que o AAA aloque o primeiro endereço no prefixo a ser reservado como o endereço local para a interface. A configuração mínima para o Protocolo de Anúncio de Roteador no perfil dinâmico especifica as variáveis e $junos-ipv6-ndra-prefix para atribuir dinamicamente um valor de prefixo $junos-interface-name em anúncios de roteador de descoberta de vizinhos IPv6.

O perfil dinâmico também inclui a classe de configuração de serviço que é aplicada ao tráfego do túnel. O perfil de controle de tráfego (tc-profile) inclui variáveis para o mapa do agendador ($junos-cos-scheduler-map), taxa de modelagem ($junos-cos-shaping-rate), contabilidade de sobrecarga ($junos-cos-shaping-mode) e ajuste $junos-cos-byte-adjustde byte ). O perfil dinâmico aplica a configuração de CoS — incluindo a classe de encaminhamento, o perfil de controle de tráfego de saída e as regras de reescrita — às interfaces de serviço dinâmicas.

A tg-dynamic configuração do grupo de túneis especifica o perfil ce-l2tp-profilede acesso , o perfil aaa-profileAAA local e o perfil dyn-lns-profile2 dinâmico que são usados para criar dinamicamente sessões LNS e definir as características das sessões. O lns_p1 pool de dispositivos de serviço associa um pool de interfaces de serviço ao grupo para permitir que o LNS equilibre o tráfego entre as interfaces. O endereço 203.0.113.2 do gateway local corresponde ao endereço do gateway remoto configurado no LAC. O nome ce-lns do gateway local corresponde ao nome do gateway remoto configurado no LAC.

Observação:

Este exemplo não mostra todas as opções de configuração possíveis.

Configuração

Tramitação processual

Configuração rápida da CLI

Para configurar rapidamente um L2TP LNS, copie os comandos a seguir, cole-os em um arquivo de texto, remova as quebras de linha e copie e cole os comandos na CLI.

Procedimento passo a passo

O exemplo a seguir requer que você navegue por vários níveis na hierarquia de configuração. Para obter instruções sobre como fazer isso, consulte Usando o Editor de CLI no Modo de Configuração.

Para configurar um L2TP LNS com interfaces de serviço em linha:

  1. Configure um perfil de grupo de usuários que defina a configuração de PPP para assinantes de túnel.

  2. Configure um perfil de acesso L2TP que defina os parâmetros L2TP para cada LAC do cliente. Isso inclui associar um perfil de grupo de usuários ao cliente e especificar o identificador para a interface lógica de serviços em linha que representa uma sessão L2TP no LNS.

    Observação:

    Se user-group-profile for modificado ou excluído, os assinantes LNS existentes, que estavam usando essa configuração de cliente do Protocolo de Tunelamento de Camada 2, ficarão inativos.

  3. Configure um perfil de acesso AAA para substituir o perfil de acesso global para a ordem dos métodos de autenticação AAA e atributos do servidor.

  4. Configure pools de atribuição de endereços IPv4 e IPv6 para alocar endereços para os clientes (LACs).

  5. Configure a interface peer para encerrar o túnel e o endereço IPCP do lado do servidor PPP (endereço de loopback).

  6. Habilite interfaces de serviço em linha em um MPC.

  7. Configure as interfaces de serviço âncora com encapsulamento de serviços, agendamento hierárquico e a família de endereços.

  8. Configure um pool de interfaces de serviço para sessões dinâmicas do LNS.

  9. Configure um perfil dinâmico que crie dinamicamente interfaces lógicas L2TP para assinantes de pilha dupla.

  10. Configure regras de modelagem, agendamento e reescrita e aplique no perfil dinâmico ao tráfego de túnel.

  11. Configure o grupo de túneis L2TP para ativar sessões dinâmicas do LNS usando o pool de interfaces de serviço em linha para permitir o balanceamento de carga.

Resultados

No modo de configuração, confirme a configuração do perfil de acesso, do perfil de grupo, do perfil AAA e dos pools de atribuição de endereços inserindo o show access comando. Confirme a configuração de serviços em linha inserindo o show chassis comando. Confirme a configuração da interface digitando o show interfaces comando. Confirme a configuração do perfil dinâmico inserindo o show dynamic-profiles comando. Confirme a configuração do grupo de túneis digitando o show services l2tp comando. Se a saída não exibir a configuração pretendida, repita as instruções de configuração neste exemplo para corrigi-la.

Quando terminar de configurar o dispositivo, entre no commit modo de configuração.

Configuração de um grupo de túneis L2TP para sessões LNS com interfaces de serviços em linha

O grupo de túneis L2TP especifica atributos que se aplicam a túneis L2TP e sessões de um grupo de clientes LAC. Esses atributos incluem o perfil de acesso usado para validar solicitações de conexão L2TP feitas ao LNS no endereço de gateway local, um perfil de acesso local que substitui o perfil de acesso global, o temporizador keepalive e se o valor de IP ToS é refletido.

Observação:

Se você excluir um grupo de túneis, todas as sessões L2TP nesse grupo de túneis serão encerradas. Se você alterar o valor das local-gateway-addressinstruções , service-device-poolou , todas service-interface as sessões L2TP que usam essas configurações serão encerradas. Se você alterar ou excluir outras instruções no nível de [edit services l2tp tunnel-group name] hierarquia, os novos túneis estabelecidos usarão os valores atualizados, mas os túneis e sessões existentes não serão afetados.

Para configurar o grupo de túneis LNS:

  1. Crie o grupo de túneis.
    Observação:

    Você pode criar até 256 grupos de túneis.

  2. Especifique a interface de âncora de serviço responsável pelo processamento L2TP no LNS.

    Essa interface de âncora de serviço é necessária para sessões LNS estáticas e para sessões LNS dinâmicas que não equilibram o tráfego em um pool de interfaces âncora. A interface é configurada no nível da [edit interfaces] hierarquia.

  3. (Opcional; somente para sessões LNS dinâmicas de balanceamento de carga) Especifique um pool de interfaces âncora de serviço em linha para permitir o balanceamento de carga do tráfego L2TP nas interfaces.

    O pool é definido no nível da [edit services service-device-pools] hierarquia.

  4. (Somente para sessões dinâmicas do LNS) Especifique o nome do perfil dinâmico que define e instancia interfaces de serviço em linha para túneis L2TP

    O perfil é definido no nível hierárquico [edit dynamic-profiles] .

  5. Especifique o perfil de acesso que valida todas as solicitações de conexão L2TP para o endereço de gateway local.
  6. Configure o endereço do gateway local no LNS; corresponde ao endereço IP usado pelos LACs para identificar o LNS.
  7. (Opcional) Configure o nome do gateway local no LNS, retornado na mensagem SCCRP para o LAC. O nome deve corresponder ao nome do gateway remoto configurado no LAC, ou o túnel não pode ser criado.
  8. (Opcional) Configure o intervalo no qual o LNS envia mensagens de saudação se não tiver recebido nenhuma mensagem do LAC.
  9. (Opcional) Especifique um perfil de acesso local que substitua o perfil de acesso global para definir as configurações do servidor RADIUS para o grupo de túneis.

    Esse perfil local é configurado no nível da [edit access profile] hierarquia.

  10. (Opcional) Configure o LNS para refletir o valor de IP ToS do cabeçalho IP interno para o cabeçalho IP externo (aplica-se a configurações de CoS).
  11. (Opcional) Especifique um perfil de serviço dinâmico a ser aplicado à sessão L2TP no login, juntamente com quaisquer parâmetros a serem passados para o serviço.

Aplicando serviços a uma sessão L2TP sem usar o RADIUS

Os serviços são aplicados a sessões L2TP para ativação ou modificação posterior por atributos específicos do fornecedor (VSAs) do servidor RADIUS ou em solicitações de alteração de autorização (CoA) RADIUS. A partir do Junos OS Release 18.1R1, você pode aplicar serviços a sessões L2TP por meio de perfis de serviço dinâmicos sem envolver o RADIUS. Em ambientes de vários fornecedores, os clientes podem usar apenas atributos RADIUS padrão para simplificar o gerenciamento, evitando o uso de VSAs de vários fornecedores. No entanto, isso complica a aplicação de serviços a sessões L2TP porque os VSAs geralmente são obrigados a aplicar serviços. A ativação do perfil de serviço dinâmico local permite que você evite esse problema. Você também pode usar a ativação do perfil de serviço local para fornecer serviços padrão quando os servidores RADIUS estão inativos.

Você pode aplicar serviços a todos os assinantes em um grupo de túneis ou a todos os assinantes que usam um LAC específico. Você pode configurar um máximo de 12 serviços por grupo de túneis ou nome de host LAC.

Depois de configurar um ou mais perfis de serviço dinâmicos que definem serviços, você os aplica no grupo de túneis ou na configuração do perfil de acesso para um cliente LAC, especificando os nomes dos perfis de serviço. Você pode listar mais de um perfil a ser ativado, separado por um e comercial (&). Você também pode especificar parâmetros a serem usados pelo perfil de serviço que podem substituir valores configurados no próprio perfil, como uma taxa de modelagem downstream para um serviço CoS.

A lista de serviços configurada localmente (por meio de perfis de serviço) serve como autorização local que é aplicada pelo authd durante a ativação da sessão do cliente. Essa lista de serviços está sujeita à mesma validação e processamento que os serviços originados de uma autoridade externa, como a RADIUS. Esses serviços são apresentados durante o login do assinante.

Você ainda pode usar solicitações RADIUS VSAs ou CoA em conjunto com os perfis de serviço. Se os serviços forem originados de uma autoridade externa como autorização durante a autenticação ou durante o provisionamento (ativação) da sessão do assinante, os serviços da autoridade externa terão prioridade estrita sobre aqueles na configuração local. Se um serviço aplicado com RADIUS for o mesmo que um serviço aplicado com um perfil de serviço na CLI, mas com parâmetros diferentes, o serviço RADIUS será aplicado com um novo ID de sessão e terá precedência sobre o perfil de serviço anterior.

Você pode emitir comandos para desativar ou reativar qualquer serviço que tenha ativado anteriormente para um grupo de túneis ou LAC.

Defina os perfis de serviço dinâmicos que você deseja aplicar posteriormente a um grupo de túneis ou LAC.

Para aplicar perfis de serviço a todos os assinantes em um grupo de túneis:

  • Especifique um ou mais perfis de serviço e quaisquer parâmetros a serem passados para os serviços.

Para aplicar perfis de serviço a todos os assinantes de uma determinada LAC:

  • Especifique um ou mais perfis de serviço e quaisquer parâmetros a serem passados para os serviços.

    Observação:

    Quando os perfis de serviço são configurados para um cliente LAC e para um grupo de túneis que usa esse cliente, somente o perfil de serviço do cliente LAC é aplicado. Ele substitui a configuração do grupo de túneis. Por exemplo, na configuração a seguir, o grupo de túneis, tg-LAC-3, usa o cliente LAC, LAC-3, de modo que a configuração LAC3 substitui a configuração do grupo de túneis. Consequentemente, apenas o serviço cos-A3 é ativado para assinantes no grupo de túneis, em vez de Cos2 e fw1. A taxa de modelagem passada para o serviço é de 24 Mbps.

Você pode desativar qualquer serviço aplicado a uma sessão de assinante emitindo o seguinte comando:

Você pode reativar qualquer serviço aplicado a uma sessão de assinante emitindo o seguinte comando:

Para exibir as sessões de serviços para todas as sessões atuais do assinante, use o show subscribers extensive comando or show network-access aaa subscribers session-id id-number detail .

Para entender como o aplicativo de serviço local funciona, os exemplos a seguir ilustram as várias possibilidades de configuração. Primeiro, considere as seguintes configurações dinâmicas de perfil de serviço, cos2 e fw1:

A instrução a seguir aplica ambos os serviços a todos os assinantes no grupo de túneis tg1; Um valor de parâmetro de 31 Mbps é passado para o serviço cos2:

No perfil de serviço cos2, a taxa de modelagem é fornecida por uma variável definida pelo usuário com um valor padrão de 10m ou 1Mbps. Depois que a sessão L2TP estiver ativa, cos2 e fw1 serão ativados com IDs de sessão de serviço de 34 e 35, respectivamente.

O parâmetro passado para cos2 é usado como o valor para $shaping-rate; consequentemente, a taxa de modelagem do serviço é ajustada do valor padrão de 10 Mbps para 31 Mbps, conforme mostrado na saída do comando a seguir. Embora a saída indique que o aplicativo de ajuste é RADIUS CoA, o ajuste é uma consequência do parâmetro passado para o perfil de serviço. Essa operação usa a mesma estrutura interna que um CoA e é relatada como tal.

Agora, o serviço cos2 está desativado da CLI para a sessão 27 do assinante.

A saída a seguir mostra que cos2 desapareceu, deixando apenas fw1 como um serviço ativo.

O comando a seguir reativa cos2 para a sessão 27 do assinante.

O serviço cos2 reativado tem uma nova ID de sessão de serviço de 36.

O serviço cos2 reativado usa a taxa de modelagem padrão, 10 Mbps, do perfil de serviço.

Em seguida, uma solicitação de CoA RADIUS é recebida, que inclui o VSA de serviço ativado (26-65). O VSA especifica e ativa o serviço e especifica uma alteração na taxa de modelagem do cos2 do padrão de 10 Mbps para 12 Mbps. A sessão de serviço cos2 36 ainda aparece na saída, mas é substituída pela nova sessão de serviço iniciada pelo CoA, 49.

Quando um serviço é aplicado pela configuração da CLI e por um RADIUS VSA (26-65), mas com parâmetros diferentes, a configuração do RADIUS substitui a configuração da CLI. No exemplo a seguir, a configuração da CLI aplica o perfil de serviço cos2 com um valor de 31 Mbps para a taxa de modelagem.

A ativação do serviço de mensagens RADIUS Access-Accept VSA (26-65) aplica cos2 com um valor de 21 Mbps para a taxa de modelagem.

A configuração da CLI ativa a sessão de serviço 22 com uma taxa de modelagem de 31 Mbps. O RADIUS VSA ativa a sessão de serviço 23 com uma taxa de modelagem de 21 Mbps.

Configuração de um pool de interfaces de serviços em linha para sessões dinâmicas do LNS

Você pode criar um pool de interfaces de serviço em linha, também conhecido como pool de dispositivos de serviço, para permitir o balanceamento de carga do tráfego L2TP entre as interfaces. O pool é compatível com configurações dinâmicas do LNS, em que ele fornece um conjunto de interfaces lógicas que podem ser criadas dinamicamente e alocadas para sessões L2TP no LNS. O pool é atribuído a um grupo de túneis LNS. O L2TP mantém o estado de cada interface de serviço em linha e usa um método de rodízio para distribuir uniformemente a carga entre as interfaces disponíveis quando novas solicitações de sessão são aceitas.

Observação:

O balanceamento de carga está disponível apenas para interfaces de assinante criadas dinamicamente.

As sessões LNS ancoradas em um MPC não são afetadas por uma falha de MIC, desde que exista algum outro caminho para os LACs peer. Se o MPC que hospeda a interface peer falhar e não houver nenhum caminho para LACs peer, a falha iniciará o encerramento e a limpeza de todas as sessões no MPC.

Se o próprio MPC que ancora as sessões LNS falhar, o Mecanismo de Roteamento não realocará as sessões para outro slot e todas as sessões serão encerradas imediatamente. Novas sessões podem surgir em outra interface disponível quando o cliente tenta novamente.

Para configurar o pool de dispositivos de serviço:

  1. Crie o pool.
  2. Especifique as interfaces de serviço embutidas que compõem o pool.

Configuração de um perfil dinâmico para sessões dinâmicas do LNS

Você pode configurar o L2TP para atribuir dinamicamente interfaces de serviço em linha para túneis L2TP. Você deve definir um ou mais perfis dinâmicos e atribuir um perfil a cada grupo de túneis. O LNS oferece suporte a sessões IPv4/IPv6 somente IPv4, somente IPv6 e de pilha dupla.

Para configurar o perfil dinâmico L2TP:

  1. Crie o perfil dinâmico.
  2. Configure a interface a ser atribuída dinamicamente à instância de roteamento usada pelos clientes PPP em túnel.
  3. Configure as opções de roteamento para rotas de acesso na instância de roteamento.
  4. Configure as opções de roteamento para rotas internas de acesso na instância de roteamento.
  5. Defina as interfaces usadas pelo perfil dinâmico. A variável é substituída dinamicamente por uma das interfaces de serviço em linha configuradas.
  6. Configure as interfaces lógicas de serviços em linha para serem instanciadas dinamicamente.
  7. Especifique um identificador para as interfaces lógicas.
  8. Configure cada interface lógica para ser usada apenas uma sessão por vez.
  9. Configure a família de endereços para as interfaces lógicas e habilite o endereço local no LNS que fornece terminação local para o túnel L2TP seja derivado do nome de interface especificado.
    Observação:

    As sessões dinâmicas do LNS exigem que você inclua a dial-options instrução no perfil dinâmico, o que, por sua vez, exige que você inclua a family inet instrução. Isso tem as seguintes consequências:

    • Você deve sempre configurar family inet , independentemente de configurar interfaces somente IPv4, somente IPv6 ou dual-stack no perfil.

    • Ao configurar interfaces somente IPv4, você configura apenas family inet e deve configurar o endereço da interface em family inet.

    • Ao configurar interfaces somente IPv6 , você também deve configurar family inet6 e configurar o endereço da interface em family inet6. Você não configura o endereço em family inet.

    • Ao configurar interfaces IPv4/IPv6 de pilha dupla, você configura e family inet family inet6 um endereço de interface em cada família.

    Para interfaces somente IPv4:

    Para interfaces somente IPv6:

    Para interfaces IPv4/IPv6 de pilha dupla:

    Observação:

    Se o Protocolo de Anúncio de Roteador estiver configurado, você configurará um endereço numerado em vez de um endereço não numerado para o endereço local IPv6:

    Consulte o Guia do Usuário de Sessões de Assinantes de Banda Larga para obter informações sobre o uso de variáveis para endereçamento somente IPv6 e dual-stack em perfis dinâmicos.

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
18.1R1
A partir do Junos OS Release 18.1R1, você pode aplicar serviços a sessões L2TP por meio de perfis de serviço dinâmicos sem envolver o RADIUS.
16.2R1
A partir do Junos OS Release 16.2, você não precisa especificar explicitamente uma largura de banda para o tráfego de túnel L2TP LNS usando serviços em linha.