NESTA PÁGINA
redundância de âncora Pseudowire Visão geral das interfaces lógicas do assinante
Configurando o número máximo de dispositivos de interface lógica pseudowire suportados no roteador
Configuração de um dispositivo de interface lógica de assinante pseudowire
Alterando o ponto de ancoragem para um dispositivo de interface lógica de assinante pseudowire
Configurando a Interface Lógica de Transporte para uma Interface Lógica de Assinante Pseudowire
Configuração da sinalização de circuito de Camada 2 para interfaces lógicas de assinantes Pseudowire
Configuração da sinalização VPN de Camada 2 para interfaces lógicas de assinantes Pseudowire
Configurando a Interface Lógica de Serviço para uma Interface Lógica de Assinante Pseudowire
Configurando o Suporte de Balanceamento de Carga para Tráfego de Assinantes
Interfaces lógicas de assinantes pseudowire MPLS
Visão geral das interfaces lógicas do assinante Pseudowire
O gerenciamento de assinantes suporta a criação de interfaces de assinante em pseudowires MPLS ponto a ponto. O recurso de interface de assinante pseudowire permite que os provedores de serviços estendam um domínio MPLS da rede de agregação de acesso até a borda de serviço, onde o gerenciamento de assinantes é realizado. Os provedores de serviços podem aproveitar os recursos do MPLS, como failover, reencaminhamento e provisionamento uniforme de rótulos MPLS, enquanto usam um único pseudowire para atender a um grande número de assinantes DHCP e PPPoE na rede de serviços.
As interfaces lógicas de assinante pseudowire são suportadas apenas em concentradores modulares de portas (MPCs) com placas de interface modular (MICs) Ethernet. A terminação PPPoE e L2TP não é suportada quando o encapsulamento VPLS e a autenticação DHCP são usados para a interface lógica de transporte. No entanto, a funcionalidade de atacado da camada 2 de gerenciamento de assinantes de banda larga é suportada com o encapsulamento VPLS. Uma interface VLAN dinâmica é criada com encapsulamento VPLS em um roteador atacadista, que executa a comutação de tags VLAN para encerrar assinantes PPPoE/DHCP na rede do varejista. Para obter detalhes, consulte Topologia de atacado de camada 2 de gerenciamento de assinantes de banda larga e elementos de configuração.
O pseudowire é um túnel que é uma VPN de Camada 2 baseada em MPLS ou um circuito de Camada 2. O túnel pseudowire transporta o tráfego encapsulado Ethernet de um nó de acesso (por exemplo, um DSLAM ou outro dispositivo de agregação) para o roteador da Série MX que hospeda os serviços de gerenciamento de assinantes. A terminação do túnel pseudowire no roteador da Série MX é semelhante a uma terminação física Ethernet e é o ponto no qual as funções de gerenciamento de assinantes são executadas. Um provedor de serviços pode configurar vários pseudowires por DSLAM e, em seguida, provisionar suporte para um grande número de assinantes em um pseudowire específico.
A Figura 1 mostra uma rede MPLS que oferece suporte ao gerenciamento de assinantes.
Na extremidade do nó de acesso do pseudowire, o tráfego do assinante pode ser preparado para o pseudowire de várias maneiras, limitado apenas pelo número e tipos de interfaces que podem ser empilhadas no pseudowire. Você especifica um ponto de ancoragem, que identifica a interface de túnel lógico que termina o túnel pseudowire no nó de acesso.
ao gerenciamento de assinantes
A Figura 2 mostra a pilha de protocolos para uma interface lógica de assinante pseudowire. O pseudowire é um dispositivo virtual que é empilhado acima do ponto de ancoragem do túnel lógico na interface física (o IFD) e suporta um protocolo de Camada 2 orientado a circuito (VPN de Camada 2 ou circuito de Camada 2). O protocolo de Camada 2 fornece as interfaces lógicas de transporte e serviço e suporta a família de protocolos (IPv4, IPv6 ou PPPoE).
A partir do Junos OS Release 18.3R1, em roteadores da Série MX com interfaces MPC e MIC, o suporte para interface de serviço de assinante pseudowire em túneis lógicos redundantes é introduzido em VPNs de Camada 3 e VPNs multicast draft-rosen. Anteriormente, as VPNs de Camada 3 forneciam suporte para serviços de assinante pseudowire apenas em interfaces de túnel lógico, e essas interfaces usavam protocolos de roteamento unicast, como OSPF ou BGP. Com esse suporte, você pode provisionar um protocolo de roteamento multicast, Protocol Independent Multicast (PIM), nas interfaces de assinante pseudowire, que é terminado na instância de roteamento de roteamento virtual e encaminhamento (VRF). Além disso, há um aumento nos números de dimensionamento dos dispositivos de interface lógica pseudowire que fornecem suporte de resiliência adicional para interfaces de assinante pseudowire em interfaces de túnel lógico redundantes.
Quando uma interface de serviço de assinante pseudowire é ancorada a um túnel lógico redundante cuja interface de membro (ou FPC) não existe, a interface de túnel cai. Nesses casos, as interfaces pseudowire (físicas e lógicas) também devem estar inativas, mas, no entanto, o estado da interface lógica do assinante pseudowire permanece ativo, embora os serviços de circuito de Camada 2, como ping em direção a um dispositivo de borda do cliente (CE) do lado de serviço da interface de serviço do assinante pseudowire, não estejam disponíveis.
Isso ocorre porque o lado do transporte da interface lógica do assinante pseudowire permanece ativo, fazendo com que os serviços fiquem ativos.
A configuração pseudowire é transparente para os aplicativos de gerenciamento de assinantes e não tem impacto nas cargas úteis de pacotes usadas para gerenciamento de assinantes. Aplicativos de assinantes, como DHCP e PPPoE, podem ser empilhados na Camada 2 de forma semelhante à maneira como são empilhados em uma interface física.
Começando com o Junos OS versão 16.1R1, family inet e family inet6 são suportados no lado de serviços de um assinante pseudowire MPLS, bem como interface lógica não-assinante.
A partir do Junos OS Release 16.1R1, o IPFIX em linha é suportado no lado de serviços de uma interface lógica de assinante pseudowire MPLS.
A partir do Junos OS Release 15.1R3 e 16.1R1 e versões posteriores, o encapsulamento CCC é suportado no lado de transporte de uma interface lógica de assinante pseudowire MPLS.
Antes do Junos OS Release 19.1R1, o único tipo de encapsulamento suportado nas interfaces de assinante pseudowire incluía:
-
Interfaces lógicas de transporte — encapsulamento de conexão cruzada de circuito (CCC).
-
Service logical interfaces:
-
Encapsulamento Ethernet VPLS
-
Encapsulamento de ponte VLAN
-
Encapsulamento VLAN VPLS
-
A partir do Junos OS Release 19.1R1, encapsulamentos adicionais são adicionados às interfaces lógicas de serviço e transporte de assinantes pseudowire. A interface lógica de transporte oferece suporte ao encapsulamento Ethernet VPLS e provisões para encerrar a l2backhaul-vpn interface na instância de roteamento. A interface lógica de serviço suporta encapsulamento de conexão cruzada de circuito (CCC) e provisões para terminar a interface em circuitos de Camada 2 comutados localmente.
Com o suporte de tipos de encapsulamento adicionais, você pode se beneficiar do demux de uma l2backhaul VPN em vários serviços de VPN, como circuito de Camada 2 e VPN de Camada 3. Como as interfaces de assinante pseudowire são ancoradas em túneis lógicos redundantes, esse aprimoramento também fornece redundância de placa de linha.
A partir do Junos OS Release 15.1R3 e 16.1R1 e versões posteriores, a proteção contra negação de serviço distribuída (DDoS) é suportada no lado de serviços de uma interface lógica de assinante pseudowire MPLS.
A partir do Junos OS versão 15.1R3 e 16.1R1 e versões posteriores, o Policer e o Filter são suportados no lado de serviços de uma interface lógica de assinante pseudowire MPLS.
A partir do Junos OS Release 15.1R3 e 16.1R1 e versões posteriores, as estatísticas de transmissão precisas na interface lógica são suportadas no lado de serviços de uma interface lógica de assinante pseudowire MPLS.
A partir do Junos OS Release 17.3R1 e versões posteriores, o suporte à redundância de ponto âncora stateful é fornecido para a interface lógica de assinante pseudowire pela interface lógica de túnel lógico redundante (rlt) subjacente no modo de backup ativo. Essa redundância protege o link de acesso e o núcleo contra falhas de PFE (Mecanismo de Encaminhamento de Pacotes) âncora.
redundância de âncora Pseudowire Visão geral das interfaces lógicas do assinante
Em implementações pseudowire MPLS que usam interfaces lógicas de assinante pseudowire, a falha do Mecanismo de Encaminhamento de Pacotes que hospeda o túnel lógico que ancora essas interfaces lógicas leva à perda de tráfego e subsequente perda de sessão do assinante.
O Mecanismo de Encaminhamento de Pacotes não depende do plano de controle para detecção de falhas; em vez disso, ele usa um mecanismo de detecção de atividade, com um algoritmo baseado em pulsação subjacente, para detectar a falha de outros mecanismos de encaminhamento de pacotes no sistema. A falha de um Mecanismo de Encaminhamento de Pacotes também indica a falha do túnel lógico hospedado, o que acaba levando à perda de sessão. Para evitar essa perda de sessão, é necessário um ponto de ancoragem redundante para o qual a sessão pode ser movida sem perder tráfego.
As interfaces lógicas de assinante pseudowire podem ser instanciadas em uma interface de túnel lógico redundante (RLT) subjacente no modo de backup ativo ou ativo. Isso além da instalação de pseudowires em uma única interface de túnel lógico. A vantagem mais notável de implementar a interface lógica do assinante pseudowire em interfaces RLT é fornecer redundância do caminho de encaminhamento subjacente. Isso permite que o sistema traga novos assinantes e mantenha os assinantes existentes operacionais, mesmo que uma interface de membro do RLT fique inativa devido a uma desativação do PFE. Os assinantes permanecerão ativos enquanto houver pelo menos um link de membro RLT em um PFE ativo.
Antes do lançamento do Junos OS 18.3R1, você podia especificar um máximo de 2048 dispositivos de interface de túnel lógico redundantes para assinantes pseudowire para um roteador da Série MX. A partir do Junos OS Release 18.3R1, nos roteadores da Série MX com interfaces MPC e MIC, os números de escala dos dispositivos de interface lógica redundantes pseudowire aumentaram para 7000 dispositivos para fornecer suporte de resiliência adicional.
O Junos OS Release 17.3 também oferece suporte a uma infraestrutura agregada aprimorada para um Mecanismo de Encaminhamento de Pacotes para fornecer redundância de ponto âncora. A infraestrutura agregada aprimorada requer no mínimo uma interface lógica de controle que precisa ser criada em uma interface lógica de túnel redundante. As interfaces lógicas de transporte e serviços criadas para a interface lógica do assinante pseudowire são empilhadas na interface lógica de controle subjacente para o túnel lógico redundante. Esse modelo de empilhamento é usado para interfaces lógicas de assinante pseudowire redundantes e não redundantes.
Os seguintes eventos devem disparar a remoção da interface física de um grupo redundante:
-
Falha de hardware no Concentrador PIC Modular (MPC) ou na Placa de Interfaces Modulares (MIC).
-
Falha do MPC devido a falha do microkernel.
-
MPC ou MIC colocados offline administrativamente.
-
Falha de energia em um MPC ou MIC.
A Figura 3 fornece os detalhes do empilhamento da interface lógica do assinante pseudowire em uma interface de túnel lógica redundante.
de túnel lógico redundante
O serviço estático ifl não é empilhado sobre o transporte ifl quando o RLT é usado.
Por padrão, a proteção de link para interfaces de túnel redundantes é revertiva. Em caso de falha do link ativo, o tráfego é roteado pelo link de backup. Quando o link ativo é restabelecido, o tráfego é automaticamente roteado de volta para o link ativo. Isso causa perda de tráfego e perda de sessão do assinante.
Para superar a perda de tráfego e sessão, você pode configurar a proteção de link não reversivo para interfaces de túnel redundantes usando a declaração set interfaces rltX logical-tunnel-options link-protection non-revertivede configuração. Com essa configuração, quando o link ativo é restabelecido, o tráfego não é roteado de volta para o link ativo e continua a ser encaminhado no link de backup. Portanto, não há perda de tráfego ou perda de sessão do assinante. Você também pode alternar manualmente o tráfego do link de backup para o link ativo usando o request interface (revert | switchover) interface-name comando.
A comutação manual do tráfego incorre em perda de tráfego.
-
Uma interface lógica de controle é criada implicitamente em uma interface de túnel redundante com a configuração de interface lógica do assinante pseudowire e, portanto, nenhuma configuração adicional é necessária.
-
Uma interface de túnel lógico redundante permite interfaces físicas de túnel lógico de 32 membros. No entanto, uma interface lógica de assinante pseudowire hospedada na interface de túnel lógico redundante limita o número de interfaces físicas de túnel lógico a duas.
Você não pode desabilitar a interface de túnel lógico redundante (rlt) subjacente ou a interface de túnel lógico (lt) subjacente quando um pseudowire está ancorado nessa interface. Se você quiser desabilitar a interface subjacente, primeiro desative o pseudowire.
A partir do Junos OS Release 18.4R1, o suporte para distribuição em linha de sessões de Detecção de Encaminhamento Bidirecional (BFD) de salto único é estendido para assinantes pseudowire em interfaces de túnel lógico redundantes. Para interfaces de túnel lógico de assinante pseudowire, as interfaces são ancoradas em um único Concentrador PIC Flexível (FPC), como resultado, a distribuição em linha de sessões BFD de salto único é suportada por padrão. Com interfaces lógicas redundantes pseudowire, as interfaces de túnel lógico de membro podem ser hospedadas em diferentes placas de linha. Como o endereço de distribuição não está disponível para as interfaces lógicas redundantes, a distribuição de sessões de BFD de salto único era operada em modo centralizado antes do Junos OS Release 18.4R1.
Com o suporte para distribuição em linha de sessões de BFD de salto único em interfaces lógicas redundantes pseudowire, há uma vantagem de escala de até 2000 sessões de BFD de salto único em um intervalo de um segundo e melhoria no tempo de detecção melhorando o desempenho das sessões.
A operação BFD para assinantes pseudowire em interfaces lógicas redundantes é a seguinte:
-
Quando uma nova sessão BFD é adicionada, ela pode ser ancorada em um FPC ativo ou de backup.
-
Quando um dos FPCs falha ou é reinicializado, todas as sessões hospedadas nesse FPC ficam inativas e a reancoragem é disparada para o próximo endereço de distribuição disponível. As sessões de BFD voltam depois que as sessões são instaladas no outro FPC e a troca de pacotes BFD é iniciada.
No entanto, também é possível que as sessões no FPC de backup não fiquem inativas quando o FPC ativo falhar, dependendo do tempo de detecção de BFD configurado, pois o estado de encaminhamento para o novo FPC ativo pode levar algum tempo para ser programado.
-
Quando o FPC ativo falha, todas as sessões de BFD são ancoradas no FPC de backup. Da mesma forma, se o FPC de backup falhar, todas as sessões de BFD serão ancoradas no FPC ativo.
-
A reancoragem da sessão BFD não é acionada quando o FPC ativo está online novamente.
-
Com o comportamento não revertivo habilitado, quando o FPC ativo anteriormente estiver online novamente, não se espera que as sessões sejam desativadas. Com o comportamento revertivo padrão, é possível que o estado de encaminhamento precise ser atualizado e, dependendo da configuração do tempo de detecção, a sessão pode ou não oscilar.
Leve em consideração o seguinte com o suporte da distribuição em linha de sessões BFD de salto único em assinantes pseudowire em interfaces lógicas de túnel:
-
No FPC tipo MPC 7e, com a ativação da instância de roteamento 7000, leva cerca de seis minutos para que as sessões de BGP 7000 se estabeleçam nas interfaces de assinante pseudowire ancoradas em interfaces de túnel lógico redundantes.
-
Uma nova mensagem de erro de log do sistema -
JTASK_SCHED_SLIP- é registrada durante o roteamento ativo sem interrupções (NSR). Esse é o comportamento esperado do NSR com alta escala e pode ser ignorado com segurança, a menos que haja outros problemas, como flaps de sessão, que exijam que uma ação seja tomada.
A partir do Junos OS Release 21.4R1, introduzimos o suporte de CoS para um BNG na interface do assinante em pseudowire por meio de uma interface de túnel lógico redundante (RLT) ativa-ativa para aplicativos de assinantes, como DHCP e PPPoE. Essa propriedade de CoS é obtida fornecendo os nós de agendamento para os links de túnel lógico. Para interfaces dinâmicas, conjuntos de interfaces, interfaces subjacentes estáticas e interfaces subjacentes dinâmicas sobre RLT, o CoS aloca nós de agendamento para cada link no RLT, que tem vários links de túnel lógico no modo ativo-ativo. No caso de interfaces e conjuntos de interfaces direcionados, que têm links primários e de backup, o CoS aloca nós de agendamento nos links primários e de backup para otimizar o uso de nós de agendamento. O tráfego para as interfaces direcionadas ao assinante será distribuído para todos os links LT primários quando o CoS for aplicado no nível do assinante. Além disso, o tráfego de qualquer assinante é sempre processado pelo mesmo Mecanismo de Encaminhamento de Pacotes.
A Figura 4 fornece os detalhes das interfaces pai e filho usadas para a hierarquia do agendador de quatro níveis para acesso do assinante. O IFL PPPoE dinâmico e o conjunto IFL dinâmico são nós filhos. O dinâmico svlan IFL-set e o nó uifl dinâmico ou estático são nós pai.
do assinante
Ao habilitar o direcionamento em um nó, você deve habilitar o direcionamento para todos os nós filhos para que o CoS funcione corretamente. Para habilitar os nós filho, configure o perfil dinâmico no [edit interfaces ps1 auto-configure stacked-vlan-ranges dynamic-profile]. Crie um perfil dinâmico configurando interfaces direcionadas dinâmicas e conjuntos de interfaces em [edit dynamic-profiles].
Veja um exemplo da configuração dinâmica do perfil:
dvlanProf {
interfaces {
"$junos-interface-ifd-name" {
unit "$junos-interface-unit" {
demux-source [ inet inet6 ];
no-traps;
proxy-arp;
vlan-tags outer "$junos-stacked-vlan-id" inner "$junos-vlan-id";
targeted-distribution;
family inet {
unnumbered-address lo0.0 preferred-source-address 100.0.0.1;
}
family inet6 {
unnumbered-address lo0.0 preferred-source-address 1000:0::1;
}
family pppoe {
duplicate-protection;
dynamic-profile pppoeClientSvlanSetVar;
}
}
}
}
}
pppoeClientSvlanSetVar {
interfaces {
interface-set "$junos-svlan-interface-set-name" {
targeted-distribution;
interface pp0 {
unit "$junos-interface-unit";
}
}
pp0 {
unit "$junos-interface-unit" {
actual-transit-statistics;
ppp-options {
pap;
}
pppoe-options {
underlying-interface "$junos-underlying-interface";
server;
}
targeted-distribution;
keepalives interval 30;
family inet {
unnumbered-address "$junos-loopback-interface";
}
}
}
}
}
Além disso, você deve configurar os serviços enhanced-ip de rede no nível da [edit chassis] hierarquia porque esse recurso funciona apenas no modo IP aprimorado.
O modo de link múltiplo ativo-ativo com direcionamento usa os algoritmos de direcionamento para a interface RLT para distribuir clientes entre os diferentes membros do RLT (pares de pernas primárias/secundárias). O direcionamento pode ser aplicado a assinantes dinâmicos e conjuntos de interfaces dinâmicas. O algoritmo de direcionamento percorre a lista de pseudo IFLs associados ao par de links de membros e seleciona o primeiro pseudo IFL que tem capacidade suficiente com base no .rebalance-subscriber-granularity
Quando o direcionamento está habilitado, o assinante recebe um peso de direcionamento padrão com base no tipo de cliente. O algoritmo de direcionamento usa o peso de alocação no processo de seleção de pseudo-IFL e o peso de débito do IFL é o peso contado em relação ao pseudo-IFL atribuído. Para todos os objetos, exceto o IFLset, a alocação e o peso do débito são os mesmos e você pode modificar por meio do perfil do cliente. No caso do IFLset, somente o atributo de peso de alocação pode ser modificado por meio do perfil do cliente, e o peso do débito para o IFLset é fixado em um valor de 0.
| Tipo de cliente |
Peso de alocação |
Peso do débito |
|---|---|---|
| Dvlan |
1 |
1 |
| IpDemux |
1 |
1 |
| PPP |
1 |
1 |
| Conjunto de IFLs |
32 |
0 |
PWHT para dispositivos ACX
Para dispositivos ACX que usam o modo BNG CUPS para gerenciamento de assinantes, o PWHT encerra o controle pseudowire MPLS e encaminha pacotes de dados para seu destino usando o protocolo IP padrão.
Os recursos Pseudowire e PWHT (terminação de cabeçalho pseudowire) em dispositivos ACX que oferecem suporte a esse recurso exigem que o dispositivo esteja em execução no modo BNG CUPS. No modo CUPS, o plano de controle é executado a partir de uma nuvem centralizada, enquanto o plano do usuário é executado no dispositivo. Todos os recursos pseudowire e PWHT estão disponíveis para você no modo BNG CUPS. Consulte o Guia do usuário do BNG CUPS para obter mais detalhes sobre como configurar seu dispositivo no modo CUPS.
Use o Explorador de Recursos para confirmar o suporte à plataforma e à versão para recursos específicos.
O PWHT é usado para encerrar o controle pseudowire MPLS no roteador de borda do provedor de serviços. Ao sair do pseudowire, as informações de controle (mensagens de sinalização PPPoE ou DHCP) são direcionadas para o plano de controle centralizado, enquanto os dados regulares são encaminhados ao seu destino como pacotes IP padrão.
Para configurar o PWHT em seu dispositivo ACX, seu dispositivo deve primeiro ser configurado para o modo CUPS. Consulte Configuração do controlador BNG CUPS e configuração de planos de usuário BNG para obter mais informações.
A configuração do PWHT ocorre no plano do usuário (seu dispositivo) e não no plano de controle (nuvem). Isso é feito porque as interfaces lógicas de túnel (lt) e pseudowire (ps) devem ser criadas dentro do plano de usuário dentro do Junos OS Evolved. Os comandos para configurar suas interfaces lt e ps são os mesmos do Junos OS; no entanto, os dispositivos ACX exigem os números de slot e núcleo da âncora PWHT na configuração. Os dispositivos ACX também exigem que você configure manualmente sua reserva de largura de banda.
Ao contrário do Junos OS, as interfaces LT são criadas com base no número FPC ou FEB, número PFE, número do núcleo e canal que são selecionados durante o comando de configuração. Esse local não é baseado na largura de banda. Nos exemplos a seguir, o LT IFD seria lt-0/0/0:0. Se outra interface LT fosse necessária no mesmo slot, ela estaria em um canal diferente - por exemplo, lt-0/0/0:1.
Aqui está um exemplo de uma configuração para um dispositivo ACX baseado em FEB.
chassis {
feb 0 {
pfe 0 {
core 0 {
channel 0 {
tunnel-services {
bandwidth 10g;
}
}
}
}
}
}
Aqui está um exemplo de uma configuração para um dispositivo ACX baseado em FPC.
chassis {
fpc 0 {
pfe 0 {
core 0 {
channel 0 {
tunnel-services {
bandwidth 10g;
}
}
}
}
}
}
Aqui está um exemplo de uma configuração de interface pseudowire (ps).
interfaces {
ps1 {
anchor-point {
lt-0/0/0:0 {
}
flexible-vlan-tagging;
auto-configure {
stacked-vlan-ranges {
dynamic-profile svlan-prof {
accept [dhcp-v4 dchp-v6 pppoe];
ranges {
any,any;
}
}
}
}
set interfaces ps1 unit 0 encapsulation ethernet-ccc
}
}
Veja também
Configuração de PWHT para dispositivos ACX
Como configurar o PWHT em dispositivos ACX no modo BNG CUPS.
Os dispositivos ACX que oferecem suporte a recursos PWHT devem estar no modo CUPS. Consulte o Guia do usuário do BNG CUPS para configurar seu dispositivo no modo CUPS.
Para configurar sua interface lt e largura de banda total reservada, siga estas etapas.
Configurando uma interface lógica de assinante pseudowire
Uma interface lógica de assinante pseudowire encerra um túnel pseudowire MPLS de um nó de acesso para o roteador da Série MX que hospeda o gerenciamento de assinantes e permite que você execute serviços de gerenciamento de assinantes na interface.
Para criar uma interface lógica de assinante pseudowire:
Configurando o número máximo de dispositivos de interface lógica pseudowire suportados no roteador
Você deve definir o número máximo de dispositivos de interface lógica pseudowire (túneis pseudowire) que o roteador pode usar para interfaces lógicas do assinante. Definir o número máximo também define os nomes de interface para as interfaces pseudowire. Ao configurar as interfaces posteriormente, você deve especificar os nomes de interface no intervalo de ps0 a ps(device-count - 1).
Por exemplo, se você definir o número máximo de dispositivos como 5, poderá configurar apenas as interfaces ps0, ps1, ps2, ps3 e ps4.
Antes do lançamento do Junos OS 17.2R1, você podia especificar um máximo de 2048 dispositivos de interface lógica pseudowire para um roteador da Série MX. A partir do Junos OS Release 17.2R1, nos roteadores da Série MX com interfaces MPC e MIC, os números de dimensionamento dos dispositivos de interface lógica pseudowire aumentaram para 7000 dispositivos para fornecer suporte de resiliência adicional.
Da mesma forma, antes do lançamento do Junos OS 18.3R1, você poderia especificar um máximo de 2048 dispositivos de interface de túnel lógico redundante (RLT) para assinante pseudowire para um roteador da Série MX. A partir do Junos OS Release 18.3R1, nos roteadores da Série MX com interfaces MPC e MIC, os números de escala dos dispositivos de interface lógica redundantes pseudowire aumentaram para 7000 dispositivos para fornecer suporte de resiliência adicional.
A partir do Junos OS Release 20.4R1, em roteadores MX2010 e MX2020 com a placa de linha MX2K-MPC9E ou MX2K-MPC11E, você pode especificar até 18000 dispositivos de interface lógica pseudowire.
O PFE que hospeda os dispositivos de interface lógica pseudowire no máximo fornece a flexibilidade de configuração necessária para casos especiais que podem ocorrer em cenários de borda de negócios. No entanto, você pode exceder os recursos PFE disponíveis ao configurar serviços adicionais nas portas dos dispositivos de interface lógica pseudowire. Para oferecer suporte a uma configuração em escala, certifique-se de preencher o número apropriado de PFEs para o chassi e de distribuir os dispositivos de interface lógica pseudowire entre os PFEs de forma a garantir que nenhum PFE seja sobrecarregado pela carga de pico prevista. Como parte do planejamento de rede para sua implantação específica, você deve considerar a combinação exata da distribuição dos dispositivos de interface lógica pseudowire e os serviços associados aos dispositivos.
Um dispositivo de interface lógica pseudowire configurado consome recursos de pools compartilhados mesmo quando o dispositivo não tem interfaces lógicas de assinante ativas. Para economizar recursos, não implante um número excessivo de dispositivos pseudowire que você não pretende usar.
Para configurar o número de dispositivos de interface lógica pseudowire que você deseja que o roteador suporte:
Configuração de um dispositivo de interface lógica de assinante pseudowire
Para configurar um dispositivo de interface lógica pseudowire que o roteador usa para interfaces lógicas de assinante, especifique o túnel lógico que processa a terminação pseudowire. Você também pode usar túneis lógicos redundantes para fornecer redundância para túneis lógicos de membros. Você pode configurar parâmetros opcionais adicionais para o dispositivo de interface, como método de marcação VLAN, MTU e suporte ARP gratuito.
Você deve criar um túnel lógico para o dispositivo de interface lógica pseudowire. Se você estiver usando túneis lógicos redundantes, deverá criar o túnel redundante.
Para configurar o dispositivo de interface de assinante pseudowire:
Alterando o ponto de ancoragem para um dispositivo de interface lógica de assinante pseudowire
Não é possível alterar dinamicamente um ponto de ancoragem que tenha dispositivos pseudowire ativos empilhados acima dele. Você deve confirmar certas mudanças antes de mover o ponto de ancoragem. Exemplos dessa situação incluem mover o ponto de ancoragem de um túnel lógico para outro túnel lógico, de um túnel lógico para um túnel lógico redundante e de um túnel lógico redundante para um túnel lógico.
Para mover o ponto de ancoragem entre interfaces lógicas de túnel:
Para mover o ponto de ancoragem de uma interface de túnel lógico para uma interface de túnel lógico redundante:
Desative os pseudowires empilhados e confirme. Isso pode exigir derrubar todos os assinantes que usam os pseudowires.
[edit interfaces] user@host# deactivate psnumber user@host# commit
Adicione a nova interface de túnel lógico redundante e confirme.
Crie o túnel e defina o número máximo de dispositivos permitidos.
[edit chassis] user@host# set redundancy-group interface-type redundant-logical-tunnel device-count count
Associe cada túnel lógico de membro ao túnel lógico redundante.
Observação:Os túneis lógicos redundantes exigem que os membros estejam no modo de backup ativo. O túnel lógico de backup deve estar em um FPC diferente do túnel lógico ativo. Por exemplo, se o túnel ativo estiver no FPC 3, o túnel de backup deverá estar em um FPC diferente, como o FPC 4.
[edit interfaces rltnumber] user@host# set redundancy-group member-interface lt-fpc/pic/port active user@host# set redundancy-group member-interface lt-fpc/pic/port backup
Confirme suas alterações.
[edit interfaces rltnumber] user@host# commit
Altere a âncora no pseudowire desativado para a nova interface de túnel lógico redundante e confirme.
[edit interfaces] user@host# set psnumber anchor-point rltnumber user@host# commit
Reative os pseudowires empilhados e confirme.
[edit interfaces] user@host# activate psnumber user@host# commit
Para mover o ponto de ancoragem de uma interface de túnel lógico redundante para uma interface de túnel lógico que seja membro do túnel lógico redundante:
Desative os pseudowires empilhados; Isso pode exigir derrubar todos os assinantes que usam os pseudowires. Exclua a interface de túnel lógico redundante e confirme suas alterações.
[edit interfaces] user@host# deactivate psnumber user@host# delete rltnumber user@host# commit
Altere a âncora no pseudowire desativado para a nova interface de túnel lógico e confirme.
[edit interfaces] user@host# set psnumber anchor-point lt-fpc/pic/port user@host# commit
Reative os pseudowires empilhados e confirme.
[edit interfaces] user@host# activate psnumber user@host# commit
Configurando a Interface Lógica de Transporte para uma Interface Lógica de Assinante Pseudowire
Este tópico descreve como configurar uma interface lógica de transporte pseudowire. Um dispositivo pseudowire pode ter apenas uma interface lógica de transporte.
Um dispositivo lógico pseudowire e suas interfaces lógicas pseudowire relacionadas dependem do estado do dispositivo de interface de transporte lógico subjacente, que é a VPN de Camada 2 ou o circuito de Camada 2.
Recomendamos que você use unit 0 para representar a interface lógica de transporte para o dispositivo pseudowire. Os números de unidade diferentes de zero representam interfaces lógicas de serviço usadas para interfaces de assinantes pseudowire.
Para configurar uma interface lógica de transporte pseudowire:
Configuração da sinalização de circuito de Camada 2 para interfaces lógicas de assinantes Pseudowire
Este tópico descreve as etapas para configurar a sinalização de circuito de Camada 2 usada para o suporte da interface lógica do assinante pseudowire. Você também pode usar a sinalização VPN de Camada 2 para interfaces lógicas de assinante pseudowire. Os dois métodos são mutuamente exclusivos; Você pode usar apenas um método para um pseudowire específico.
Para configurar a sinalização de circuito de Camada 2 para interfaces pseudowire:
Para obter mais informações sobre circuitos de Camada 2, consulte Configuração de interfaces para circuitos de Camada 2.
Configuração da sinalização VPN de Camada 2 para interfaces lógicas de assinantes Pseudowire
Este tópico descreve as etapas para configurar a sinalização VPN de Camada 2 usada para o suporte à interface lógica do assinante pseudowire. Você também pode usar a sinalização de circuito de Camada 2 para interfaces lógicas de assinante pseudowire. Os dois métodos são mutuamente exclusivos; Você pode usar apenas um método em um pseudowire específico.
Para configurar a sinalização VPN de Camada 2 para interfaces pseudowire:
Configurando a Interface Lógica de Serviço para uma Interface Lógica de Assinante Pseudowire
Este tópico descreve como configurar uma interface lógica de serviço pseudowire. As interfaces lógicas de serviço representam os circuitos de conexão para interfaces lógicas pseudowire.
Conforme descrito na Visão geral das interfaces lógicas do assinante pseudowire, você pode escolher se deseja configurar uma interface lógica de serviço junto com uma interface lógica de assinante superior, dependendo da necessidade de negócios. Em uma configuração de borda de banda larga, a interface lógica do assinante superior é o ponto de demarcação para os assinantes. No entanto, em uma configuração de borda de negócios, a interface lógica de serviço é o ponto de demarcação para os assinantes de negócios e também serve como a interface lógica do assinante, portanto, nenhuma interface lógica de assinante é configurada explicitamente.
Os números de unidade diferentes de zero representam interfaces lógicas de serviço usadas para interfaces de assinantes pseudowire. Use unit 0 para representar a interface lógica de transporte para o dispositivo pseudowire.
Para configurar uma interface lógica de serviço pseudowire:
Configurando um PWHT com suporte ao tipo VC 11
Você pode configurar uma interface de terminação de cabeçalho pseudowire (PWHT) em um roteador PE de serviço e configurar ethernet-tcc o encapsulamento na interface lógica de transporte do assinante pseudowire (PS).
Quando você usa esse recurso, o roteador PE de serviço não precisa oferecer suporte ao tráfego encapsulado TDM/SONET/SDH proveniente de clientes do lado do acesso. O pseudowire ponto a ponto baseado em IP — que é um FEC 128 (circuito virtual (VC) tipo 11) sinalizado por LDP — conecta o roteador PE de serviço ao dispositivo de acesso conectado ao roteador CE. Você configura o pseudowire para terminar em uma instância VPN de Camada 3 ou em uma tabela IP global.
O recurso oferece suporte a cargas IPv4 e IPv6 e tráfego unicast e multicast.
O roteador PE de serviço usa mediação ARP para resolver endereços de Camada 2 quando diferentes protocolos de resolução são usados em cada extremidade de um circuito. Para o roteador PE de serviço, o roteador CE de acesso aparece como se estivesse conectado localmente. Essa mediação ARP é fornecida pelo proxy ARP em endereços IPv4 e pelo NDP (Neighbor Discovery Protocol) em endereços IPv6. O roteador PE de serviço cria uma entrada ARP local que corresponde ao endereço IPv4 do roteador CE de acesso ou adiciona o endereço IPv6 do roteador CE de acesso à tabela vizinha.
Antes de configurar as interfaces e o l2circuit protocolo para o PWHT com suporte ao tipo VC 11:
- Configure a sessão LDP de destino para o circuito de Camada 2. Consulte Configuração de LDP para circuitos de Camada 2 .
- Configure a VPN de Camada 3. Consulte Introdução à Configuração de VPNs de Camada 3.
Ao habilitar family tcc e encapsulation ethernet-tcc em uma interface PS, observe as seguintes restrições na configuração:
- Suporte para apenas um pseudowire de IP por interface física PS
- Sem suporte para uma palavra de controle; para BFD na interface PS; ou para configuração de espera ativa, espera ativa ou totalmente ativa no pseudowire de IP
Para configurar o PWHT no roteador PE de serviço com terminação em uma instância VPN de Camada 3:
Configurando o Suporte de Balanceamento de Carga para Tráfego de Assinantes
Configure o RLT com os links LT do roteador no modo ativo-ativo. Os aplicativos RLT podem ser aprimorados para incluir links de membros filho LT como uma propriedade agregada.
A partir do Junos OS Release 21.4R1, oferecemos suporte ao balanceamento de carga para sessões de assinantes na interface PS em vários links de membros filhos LT do RLT ao mesmo tempo. A propriedade de balanceamento de carga da interface RLT permite que o tráfego do assinante na interface PS seja disperso e balanceado em diferentes PICs e placas de linha.
Para a interface RLT, oferece suporte à redundância do ponto de ancoragem PS para aprimorar o modo LAG. Use a enhanced-ip opção ou a enhanced-ethernet opção no nível de [edit chassis network-services] hierarquia ao configurar o PS IFD ancorado no RLT.
O hash calculado é usado na seleção de um caminho ECMP e no balanceamento de carga. Você pode configurar o balanceamento de carga para tráfego IPv4 em pseudowires Ethernet de Camada 2. Você também pode configurar o balanceamento de carga para pseudowires Ethernet com base nas informações de IP.
Limitações
-
O suporte de balanceamento de carga BNG no recurso de interface de assinante pseudowire (PS) é suportado apenas para todas as placas de linha baseadas em trio que suportam o modelo de acesso BBE nos roteadores da Série MX.
-
Você não pode alterar o ponto de ancoragem do PS, a menos que desative a interface física do PS.
-
Interrupções transitórias de tráfego podem ocorrer quando você adiciona ou remove um membro da RLT. Adicionar ou remover o comportamento do link do membro RLT é semelhante a qualquer outro comportamento de interface agregada.
-
As estatísticas de ingresso para cada membro LT não estão disponíveis. No entanto, estatísticas agregadas PS IFL ou IFD estão disponíveis para ambas as direções.
-
O modo ativo-ativo RLT é suportado apenas para serviços de assinante.
Abaixo não há suporte para o suporte de balanceamento de carga atual no PS sobre RLT em vários links LT filhos ativos
-
Suporte de interface PS sobre RLT em placas de linha MX240, MX480 e MX960.
-
Suporte de CoS da interface do policiador hierárquico para links de membros do modo ativo-ativo
-
Suporte Ethernet agregado de CoS para tráfego de assinantes na interface de serviço pseudowire (PS)
-
IFL de serviço L2 e suporte de borda de negócios (L3) para link de membro do modo ativo-ativo
-
Suporte à interface PS em não redundantes
-
Suporte CoS hierárquico para redundância de ponto âncora de interfaces lógicas de assinante pseudowire
Para configurar o suporte de balanceamento de carga para tráfego de assinantes:
Veja também
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.
ethernet-tcc encapsulamento na interface. O pseudowire é VC tipo 11.
l2backhaul-vpn interface na instância de roteamento. A terminação PPPoE e L2TP não é suportada quando o encapsulamento VPLS é usado para a interface lógica de transporte. A interface lógica de serviço suporta encapsulamento de conexão cruzada de circuito (CCC) e provisões para terminar a interface em circuitos de Camada 2 comutados localmente.
family inet e
family inet6 são suportados no lado de serviços de um assinante pseudowire MPLS, bem como interface lógica não-assinante.