NESTA PÁGINA
Visão geral das interfaces lógicas do assinante pseudowire de redundância âncora
Configuração de uma interface lógica de assinante pseudowire
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 para assinantes pseudowire
Mudando o ponto âncora para um dispositivo de interface lógica para assinantes 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
Configuração do 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 oferece suporte à criação de interfaces de assinantes em pseudowires MPLS ponto a ponto. O recurso de interface de assinante pseudowire permite que provedores de serviços estendam um domínio MPLS da rede de agregação de acesso até a borda de serviços, onde o gerenciamento de assinantes é realizado. Os provedores de serviços podem aproveitar os recursos MPLS, como failover, redirecionamento e provisionamento uniforme de rótulos MPLS, ao mesmo tempo em que 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 assinantes pseudowire são suportadas apenas em Concentradores modulares de portas (MPCs) com placas de interface modulares (MICs) Ethernet. A terminação de PPPoE e L2TP não é suportada quando o encapsulamento VPLS e a autenticação de DHCP são usados para a interface lógica de transporte. No entanto, a funcionalidade de camada 2 de gerenciamento de assinantes de banda larga é suportada com encapsulamento VPLS. Uma interface VLAN dinâmica é criada com encapsulamento VPLS em um roteador atacadista, que realiza comutação de tags VLAN para encerrar assinantes PPPoE/DHCP na rede varejista. Para obter mais informações, veja a topologia e os elementos de configuração de topologia e configuração de camada 2 para assinantes de banda larga.
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 da 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. O término do túnel pseudowire no roteador da Série MX é semelhante a uma rescisão física de Ethernet, e é o ponto em que 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, fornecer 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.
No final do nó de acesso do pseudowire, o tráfego de assinantes pode ser preparado para o pseudowire de várias maneiras, limitado apenas pelo número e tipos de interfaces que podem ser empilhados no pseudowire. Você especifica um ponto âncora, que identifica a interface lógica de túnel que termina o túnel pseudowire no nó de acesso.
A Figura 2 mostra a pilha de protocolo para uma interface lógica de assinante pseudowire. O pseudowire é um dispositivo virtual que é empilhado acima do ponto âncora de túnel lógico na interface física (o IFD), e oferece suporte a um protocolo de Camada 2 orientado por circuito (seja vpn de Camada 2 ou circuito de Camada 2). O protocolo de Camada 2 oferece interfaces lógicas de transporte e serviço e oferece suporte à família de protocolo (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 sobre túneis lógicos redundantes é introduzido em VPNs de Camada 3 e VPNs multicast de draft-rosen. Mais cedo, as VPNs de Camada 3 forneceram suporte para serviços de assinantes pseudowire apenas em interfaces lógicas de túnel, e essas interfaces usaram 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 assinantes pseudowire, que é encerrado na instância de roteamento e encaminhamento virtual (VRF). Além disso, há um aumento no número de escala dos dispositivos de interface lógica pseudowire que fornece suporte de resiliência adicional para interfaces de assinantes pseudowire em interfaces de túnel lógicas redundantes.
Quando uma interface de serviço de assinante pseudowire é ancorada em um túnel lógico redundante cuja interface de membro (ou FPC) não existe, a interface do túnel cai. Nesses casos, as interfaces pseudowire (físicas e lógicas) também devem estar em baixa, mas, no entanto, o estado da interface lógica do assinante pseudowire permanece ativo, embora os serviços de circuito de Camada 2, como o 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 porque o lado de transporte da interface lógica do assinante pseudowire fica ativo, fazendo com que os serviços estejam ativos.
de interface de assinantes Pseudowire
A configuração pseudowire é transparente para os aplicativos de gerenciamento de assinantes e não tem impacto nas cargas de pacotes que são usadas para gerenciamento de assinantes. Aplicativos de assinantes como DHCP e PPPoE podem ser empilhados na Camada 2, semelhante à maneira como eles 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.
Começando pelo Junos OS Release 16.1R1, o IPFIX inline é suportado no lado de serviços de uma interface lógica de assinante pseudowire MPLS.
Começando pelo Junos OS Release 15.1R3 e 16.1R1 e versões posteriores, o encapsulamento de 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 assinantes pseudowire incluía:
Transporte de interfaces lógicas — encapsulamento de circuito entre conexões (CCC).
Service logical interfaces:
Encapsulamento de VPLS de ethernet
Encapsulamento da ponte VLAN
Encapsulamento de VPLS VLAN
A partir do Junos OS Release 19.1R1, encapsulamentos adicionais são adicionados às interfaces lógicas de transporte de assinantes pseudowire e serviço. A interface lógica de transporte oferece suporte ao encapsulamento Ethernet VPLS e provisionamentos para o término da interface na l2backhaul-vpn instância de roteamento. A interface lógica de serviço oferece suporte ao encapsulamento entre conexões entre circuitos (CCC) e provisionamentos para encerrar a interface em circuitos de Camada 2 comutos localmente.
Com o suporte de outros tipos de encapsulamento, 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 assinantes pseudowire estão ancoradas em túneis lógicos redundantes, esse aprimoramento também oferece redundância de placa de linha.
Começando pelo Junos OS Release 15.1R3 e 16.1R1 e versões posteriores, a proteção de negação de serviço distribuída (DDoS) é suportada no lado dos serviços de uma interface lógica de assinante pseudowire MPLS.
Começando com o Junos OS Release 15.1R3 e 16.1R1 e versões posteriores, Policer e Filter são suportados no lado de serviços de uma interface lógica de assinante pseudowire MPLS.
Começando pelo Junos OS Release 15.1R3 e 16.1R1 e versões posteriores, 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.
Começando com o Junos OS Release 17.3R1 e versões posteriores, o suporte de redundância de ponto âncora stateful é fornecido para interface lógica de assinante pseudowire pela interface de túnel lógico redundante (rlt) subjacente no modo de backup ativo. Essa redundância protege o acesso e o enlace voltado para o núcleo contra falha do PFE âncora (Packet Forwarding Engine).
Visão geral das interfaces lógicas do assinante pseudowire de redundância âncora
Em implantações pseudowire MPLS que usam interfaces lógicas de assinantes pseudowire, a falha do Mecanismo de encaminhamento de pacotes hospedando o túnel lógico que ancora essas interfaces lógicas leva à perda de tráfego e posterior perda de sessão de assinantes.
O mecanismo de encaminhamento de pacotes não depende do plano de controle para detecção de falhas; em vez disso, usa um mecanismo de detecção de vida, com um algoritmo baseado em pulsação de coração, 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 acabou levando à perda de sessão. Para evitar essa perda de sessão, é necessário um ponto âncora redundante para o qual a sessão pode ser movida sem perder tráfego.
A partir do Junos OS Release 17.3 em diante, as interfaces lógicas de assinantes pseudowire podem ser instanciadas por uma interface de túnel lógico redundante (rlt) subjacente no modo active-backup. Isso além de instalar pseudowires em uma única interface lógica de túnel. A vantagem mais perceptível da implementação da interface lógica do assinante pseudowire em interfaces lógicas de túnel redundantes é fornecer redundância do caminho de encaminhamento subjacente.
Antes do Junos OS Release 18.3R1, você pode especificar um máximo de dispositivos de interface de túnel lógico redundante para assinantes pseudowire de 2048 para um roteador da Série MX. A partir do Junos OS Release 18.3R1, em roteadores da Série MX com interfaces MPC e MIC, os dispositivos de interface lógica redundantes pseudowire escalando números aumentaram para 7000 dispositivos para fornecer suporte adicional de resiliência.
O Junos OS Release 17.3 também oferece suporte a uma infraestrutura agregada aprimorada para um Mecanismo de encaminhamento de pacotes para oferecer redundância de ponto âncora. A infraestrutura agregada aprimorada requer um mínimo de uma interface lógica de controle que precisa ser criada em uma interface de túnel lógica redundante. Tanto as interfaces lógicas de transporte quanto os serviços criados para a interface lógica do assinante pseudowire estão empilhados na interface lógica de controle subjacente para o túnel lógico redundante. Este modelo de empilhamento é usado para interfaces lógicas de assinantes pseudowire redundantes e não inferiores.
Os eventos a seguir precisam desencadear a remoção da interface física de um grupo redundante:
-
Falha de hardware no concentrador modular PIC (MPC) ou placa de interfaces modulares (MIC).
-
Falha de MPC devido a um acidente de microquenel.
-
MPC ou MIC retirados offline administrativamente.
-
Falha de energia em um MPC ou MIC.
A Figura 3 fornece os detalhes do empilhamento de interface lógica do assinante pseudowire em uma interface de túnel lógica redundante.
de túnel lógica redundante
Serviço estático sel não estiver empilhado sobre transporte ifl quando O RLT é usado.
Por padrão, a proteção de enlaces para interfaces de túnel redundantes é reversiva. Em caso de falha na conexão ativa, o tráfego é roteado pelo link de backup. Quando o link ativo é restabelecido, o tráfego é roteado automaticamente de volta para o link ativo. Isso causa perda de tráfego e perda de sessão de assinantes.
Para superar o tráfego e a perda de sessão, você pode configurar a proteção de enlaces nãoevertivos 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 de assinantes. Você também pode mudar 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 da interface lógica do assinante pseudowire e, portanto, nenhuma configuração adicional é necessária.
-
Uma interface de túnel lógica 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ógica redundante limita o número de interfaces físicas de túnel lógico para duas.
Você não pode desabilitar a interface de túnel lógico (rlt) redundante subjacente ou a interface de túnel lógico (lt) subjacente quando um pseudowire está ancorado nessa interface. Se você quiser desativar a interface subjacente, primeiro deve desativar o pseudowire.
A partir do Junos OS Release 18.4R1, o suporte para a distribuição em linha de sessões de detecção de encaminhamento bidirecional (BFD) de salto único é estendido para assinante pseudowire em interfaces de túnel lógicas redundantes. Para assinante pseudowire em interfaces lógicas de túnel, as interfaces estão ancoradas em um único Concentrador PIC Flexível (FPC), como resultado, a distribuição em linha de sessões de BFD de salto único é suportada por padrão. Com interfaces lógicas redundantes pseudowire, as interfaces lógicas de túnel dos membros 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 foi operada em um modo centralizado antes do Junos OS Release 18.4R1.
Com o suporte para a distribuição em linha de sessões de BFD de salto único em interfaces lógicas redundantes pseudowire, há uma vantagem escalonada 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 de BFD para assinantes pseudowire em interfaces lógicas redundantes é a seguinte:
-
Quando uma nova sessão de BFD é adicionada, ela pode ser ancorada em um FPC ativo ou backup.
-
Quando qualquer um dos FPCs falha ou reinicializa, todas as sessões hospedadas nesse FPC são baixadas, e a nova âncora é acionada para o próximo endereço de distribuição disponível. As sessões de BFD voltam à ativa 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 sobre o FPC de backup possam não diminuir 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 ficam ancoradas no FPC de backup. Da mesma forma, se o FPC de backup falhar, todas as sessões de BFD ficam ancoradas no FPC ativo.
-
A nova âncora da sessão da BFD não é acionada quando o FPC ativo está novamente on-line.
-
Com o comportamento não reversivo habilitado, quando o FPC anteriormente ativo estiver on-line novamente, as sessões não devem cair. Com o comportamento reversivo 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 flap.
Leve o seguinte em consideração com o suporte da distribuição em linha de sessões de BFD de salto único em assinantes pseudowire em interfaces lógicas de túnel:
-
No FPC tipo MPC 7e, com a ativação de 7000 instâncias de roteamento, leva cerca de seis minutos para que as sessões 7000 BGP se estabeleçam nas interfaces de assinantes pseudowire ancoradas em interfaces de túnel lógicas redundantes.
-
Uma nova mensagem de erro de log do sistema -
JTASK_SCHED_SLIPé registrada durante o roteamento ativo ininterrupto (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 medidas sejam tomadas.
A partir do Junos OS Release 21.4R1, apresentamos suporte a CoS para um BNG na interface de assinante em pseudowire por meio de uma interface de túnel lógico redundante (RLT) ativa para aplicativos de assinantes como DHCP e PPPoE. Esta propriedade cos é alcançada fornecendo os nós de agendamento para as ligações lógicas de túnel. Para interfaces dinâmicas, conjuntos de interfaces, interfaces estáticas subjacentes e interfaces dinâmicas subjacentes sobre RLT, a 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 direcionadas e conjuntos de interface 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 a todos os links LT primários quando o CoS for aplicado no nível de 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 de pais e filhos usadas para a hierarquia de agendamento de quatro níveis para acesso ao assinante. O PPPoE IFL dinâmico e o conjunto IFL dinâmico são nós infantis. O svlan dinâmico svlan IFL-set e nó uifl dinâmico ou estático são nós pais.
ao assinante
Ao habilitar o direcionamento em um nó, você deve permitir que o direcionamento de todos os nós infantis para CoS funcione corretamente. Para habilitar os nós da criança, 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 nas [editar perfis dinâmicos].
Aqui está 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 [edit chassis] nível hierárquicos, pois esse recurso funciona apenas no modo IP aprimorado.
O modo de múltiplos enlaces ativos e ativos com direcionamento usa os algoritmos de direcionamento para interface RLT para distribuir clientes entre os diferentes membros RLT (pares de pernas primárias/secundárias). O direcionamento pode ser aplicado a assinantes dinâmicos e conjuntos dinâmicos de interface. O algoritmo de segmentação passa pela lista de pseudo IFLs associados ao par de link do membro e seleciona o primeiro pseudo IFL que tem capacidade suficiente com base na configuração rebalance-subscriber-granularity.
Quando o direcionamento é habilitado, o assinante recebe um peso de direcionamento padrão com base no tipo de cliente. O algoritmo de direcionamento usa peso de alocação no processo de seleção 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, o peso de alocação e débito são os mesmos e você pode modificar através do perfil do cliente. No caso do IFLset, apenas o atributo de peso de alocação pode ser modificado através do perfil do cliente, e o peso do débito para o IFLset é fixo 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 |
| IFLset |
32 |
0 |
PWHT para dispositivos ACX
Para dispositivos ACX que usam o modo BNG CUPS para gerenciamento de assinantes, a 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 (término de headend pseudowire) em dispositivos ACX que oferecem suporte a esse recurso exigem que o dispositivo esteja sendo executado no modo BNG CUPS. No modo CUPS, o plano de controle é executado a partir de uma nuvem centralizada, enquanto o plano do usuário funciona 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 Feature Explorer para confirmar o suporte de plataforma e versão para recursos específicos.
PWHT é usado para encerrar o controle pseudowire MPLS no roteador de borda do provedor de serviços. Após a saída do pseudowire, as informações de controle (PPPoE ou mensagens de sinalização DHCP) são enviadas para o plano de controle centralizado, enquanto os dados regulares são encaminhados para o seu destino como pacotes IP padrão.
Para configurar o PWHT em seu dispositivo ACX, seu dispositivo deve ser configurado primeiro para o modo CUPS. Consulte a configuração do controlador BNG CUPS e a configuração de planos de usuário BNG para obter mais informações.
A configuração PWHT acontece 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 de PFE, número de núcleo e canal que são selecionados durante o comando de configuração. Este 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 nesse 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 do PWHT para dispositivos ACX
Como configurar o PWHT em dispositivos ACX no modo BNG CUPS.
Os dispositivos ACX que oferecem suporte aos recursos PWHT devem estar no modo CUPS. Consulte o Guia de usuário do BNG CUPS para configurar seu dispositivo no modo CUPS.
Para configurar sua interface lt e largura de banda total reservada, siga essas etapas.
Configuração de uma interface lógica de assinante pseudowire
Uma interface lógica de assinante pseudowire termina 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 de assinantes. Definir o número máximo também define os nomes da interface para as interfaces pseudowire. Quando você posteriormente configurar as interfaces, você deve especificar os nomes da interface na faixa de ps0 até ps(device-count - 1).
Por exemplo, se você definir o número máximo de dispositivos para 5, então você pode configurar apenas interfaces ps0, ps1, ps2, ps3 e ps4.
Antes do Junos OS Release 17.2R1, você pode especificar um máximo de dispositivos de interface lógica pseudowire de 2048 para um roteador da Série MX. A partir do Junos OS Release 17.2R1, em roteadores da Série MX com interfaces MPC e MIC, os dispositivos de interface lógica pseudowire escalando números aumentaram para 7000 dispositivos para fornecer suporte adicional de resiliência.
Da mesma forma, antes do Junos OS Release 18.3R1, você poderia especificar um máximo de dispositivos de interface de túnel lógico redundante (rlt) de assinantes pseudowire de 2048 para um roteador da Série MX. A partir do Junos OS Release 18.3R1, em roteadores da Série MX com interfaces MPC e MIC, os dispositivos de interface lógica redundantes pseudowire escalando números aumentaram para 7000 dispositivos para fornecer suporte adicional de resiliência.
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 máximos oferece a flexibilidade de configuração necessária para casos especiais que podem ocorrer para cenários de borda de negócios. No entanto, você pode exceder os recursos de PFE disponíveis enquanto configura serviços adicionais nas portas de dispositivos de interface lógica pseudowire. Para oferecer suporte a uma configuração escalonada, certifique-se de preencher o número apropriado de PFEs para o chassi e que você distribua os dispositivos de interface lógica pseudowire pelos PFEs de tal forma que garanta que nenhum PFE seja sobrecarregado com a carga de pico prevista. Como parte do planejamento de rede para sua implantação em particular, você deve considerar a combinação exata da distribuição dos dispositivos de interface lógica pseudowire e dos serviços associados aos dispositivos.
Um dispositivo de interface lógica pseudowire configurado consome recursos de grupos compartilhados mesmo quando o dispositivo não tem interfaces lógicas ativas para assinantes. Para conservar 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 ofereça suporte:
Configuração de um dispositivo de interface lógica para assinantes pseudowire
Para configurar um dispositivo de interface lógica pseudowire que o roteador usa para interfaces lógicas de assinantes, você especifica 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 o método de taging VLAN, MTU e suporte gratuito a ARP.
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, você deve criar o túnel redundante.
Para configurar o dispositivo de interface de assinante pseudowire:
Mudando o ponto âncora para um dispositivo de interface lógica para assinantes pseudowire
Você não pode mudar dinamicamente um ponto âncora que tem dispositivos pseudowire ativos empilhados acima dele. Você deve confirmar certas mudanças antes de mover o ponto âncora. Exemplos dessa situação incluem mover o ponto âncora 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 âncora entre interfaces lógicas de túnel:
Mover o ponto âncora de uma interface lógica de túnel para uma interface de túnel lógica redundante:
Desativar os pseudowires empilhados e confirmar. 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 se comprometa.
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
Vincule cada túnel lógico de membro ao túnel lógico redundante.
Nota: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 deve 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
Comprometa suas mudanças.
[edit interfaces rltnumber] user@host# commit
Altere a âncora do pseudowire desativado para a nova interface de túnel lógico redundante e se comprometa.
[edit interfaces] user@host# set psnumber anchor-point rltnumber user@host# commit
Reativar os pseudowires empilhados e confirmar.
[edit interfaces] user@host# activate psnumber user@host# commit
Mover o ponto âncora de uma interface de túnel lógica redundante para uma interface lógica de túnel que é um membro do túnel lógico redundante:
Desativar os pseudowires empilhados; isso pode exigir a diminuição de todos os assinantes que usam os pseudowires. Exclua a interface de túnel lógica redundante e comprometa suas mudanças.
[edit interfaces] user@host# deactivate psnumber user@host# delete rltnumber user@host# commit
Altere a âncora do pseudowire desativado para a nova interface lógica de túnel e se comprometa.
[edit interfaces] user@host# set psnumber anchor-point lt-fpc/pic/port user@host# commit
Reativar os pseudowires empilhados e confirmar.
[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 circuito de Camada 2.
Recomendamos que você represente unit 0 a interface lógica de transporte para o dispositivo pseudowire. Os números de unidade não 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 de interface lógica do assinante pseudowire. Você também pode usar a sinalização VPN de Camada 2 para interfaces lógicas de assinantes pseudowire. Os dois métodos são mutuamente exclusivos; você só pode usar 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 Configurando 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 de interface lógica do assinante pseudowire. Você também pode usar a sinalização de circuito de Camada 2 para interfaces lógicas de assinantes pseudowire. Os dois métodos são mutuamente exclusivos; você só pode usar 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 anexo para interfaces lógicas pseudowire.
Conforme descrito na visão geral das interfaces lógicas do assinante Pseudowire, você pode escolher se deve configurar uma interface lógica de serviço em conjunto com uma interface lógica de assinante superior, dependendo da necessidade do negócio. Em uma configuração de borda de banda larga, a interface lógica do assinante superior é o ponto de demarcação para 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 empresariais, e também serve como a interface lógica do assinante, de modo que nenhuma interface lógica do assinante está explicitamente configurada.
Os números de unidade não 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:
Configuração de um PWHT com suporte do tipo VC 11
Você pode configurar uma interface pseudowire headend termination (PWHT) em um roteador PE de serviço e configurar ethernet-tcc o encapsulamento na interface lógica de transporte de assinantes pseudowire (PS).
Quando você usa esse recurso, o roteador PE de serviço não precisa oferecer suporte ao tráfego encapsulado por TDM/SONET/SDH vindo de clientes do lado do acesso. O pseudowire ponto a ponto baseado em IP — que é um FEC 128 sinalizado por LDP (circuito virtual de circuito (VC) tipo 11) — 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 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 a mediação ARP para resolver endereços de Camada 2 quando diferentes protocolos de resolução são usados em ambas as extremidades de um circuito. Para o roteador PE de serviço, o roteador CE de acesso aparece como se estivesse conectado localmente. Essa mediação de ARP é fornecida pelo ARP proxy em endereços IPv4 e pelo Neighbor Discovery Protocol (NDP) 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 do tipo VC 11:
- Configure a sessão de LDP alvo para o circuito de Camada 2. Veja configuração do LDP para circuitos de camada 2 .
- Configure a VPN de Camada 3. Veja a introdução à configuração de VPNs de camada 3.
Ao ativar family tcc e encapsulation ethernet-tcc em uma interface PS, observe as seguintes restrições na configuração:
- Suporte a apenas um pseudowire IP por interface física de PS
- Não há suporte para uma palavra de controle; para BFD na interface PS; ou para configuração ativa de standby, hot-standby ou totalmente ativa no pseudowire IP
Para configurar PWHT no roteador PE de serviço com terminação em uma instância VPN de Camada 3:
Configuração do suporte de balanceamento de carga para tráfego de assinantes
Configure o RLT com os links LT do roteador no modo ativo. Os aplicativos RLT podem ser aprimorados para incluir links de membros infantis LT como uma propriedade agregada.
A partir do Junos OS Release 21.4R1, oferecemos suporte de balanceamento de carga para sessões de assinantes na interface PS em vários links de membros infantis LT do RLT ao mesmo tempo. A propriedade de balanceamento de carga da interface RLT permite que o tráfego de assinantes na interface PS seja dispersado e equilibrado em diferentes PICs e placas de linha.
Para a interface RLT, é compatível com a redundância do ponto âncora PS para melhorar o modo LAG. Use a opção enhanced-ip ou a opção enhanced-ethernet no nível de hierarquia [editar serviços de rede de chassi] enquanto configura o PS IFD ancorado no RLT.
Hash computado é usado na seleção de um caminho ECMP e 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 em 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 âncora do PS a menos que desabile a interface física do PS.
-
A interrupção transitória do tráfego pode ocorrer quando você adiciona ou remove um membro RLT. Adicionar ou remover o comportamento do link do membro RLT é semelhante a qualquer outro comportamento de interface agregada.
-
As estatísticas de entrada para cada membro LT não estão disponíveis. No entanto, as estatísticas agregadas de PS IFL ou IFD estão disponíveis para ambas as direções.
-
O modo RLT ativo-ativo é suportado apenas para serviços de assinantes.
Abaixo não são suportados o suporte atual de balanceamento de carga no PS sobre RLT em vários links LT de crianças ativas
-
Suporte à interface PS sobre RLT nas placas de linha MX240, MX480 e MX960.
-
Suporte coS de interface hierárquica de policiamento para links ativos de membros do modo ativo
-
CoS agregado suporte Ethernet para tráfego de assinantes na interface pseudowire service (PS)
-
Suporte para L2 Service IFL e business-edge (L3) para link de membro do modo ativo
-
Suporte de interface PS em não redundante
-
Suporte hierárquico de CoS para redundância de ponto âncora de interfaces lógicas de assinantes pseudowire
Para configurar o suporte de balanceamento de carga para tráfego de assinantes:
Veja também
Tabela de histórico de mudanças
O suporte de recursos é determinado pela plataforma e versão que você está usando. Use o Feature Explorer para determinar se um recurso é suportado em sua plataforma.
ethernet-tcc encapsulamento na interface. O pseudowire é VC tipo 11.
l2backhaul-vpn instância de roteamento. A terminação de 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 oferece suporte ao encapsulamento entre conexões entre circuitos (CCC) e provisionamentos para encerrar a interface em circuitos de Camada 2 comutos 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.