NESTA PÁGINA
Visão geral das interfaces lógicas do assinante Pseudowire de redundância âncora
Configurando o número máximo de dispositivos de interface lógica pseudowire suportados no roteador
Configurando um dispositivo de interface lógica de assinante pseudowire
Mudando o ponto âncora 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
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 de assinantes 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ç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, 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.
Interfaces lógicas de assinantes pseudowire são suportadas apenas em Concentradores modulares de portas (MPCs) com placas de interface modular (MICs) Ethernet. O encerramento de PPPoE e L2TP não é suportado quando o encapsulamento de VPLS e a autenticação 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 executa comutação de tag VLAN para encerrar assinantes ppPoE/DHCP na rede varejista. Para obter detalhes, consulte os elementos 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) até o roteador da Série MX que hospeda os serviços de gerenciamento de assinantes. O encerramento do túnel pseudowire no roteador da Série MX é semelhante a um encerramento físico da 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 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 âncora, que identifica a interface lógica do 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 fornece interfaces lógicas de transporte e serviço e oferece suporte à 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 assinantes pseudowire em túneis lógicos redundantes é introduzido em VPNs de Camada 3 e VPNs multicast 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 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 assinantes pseudowire, que é encerrado na instância de roteamento e encaminhamento virtual (VRF). Além disso, há um aumento no número de escalabilidade 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ógica redundante.
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 de 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 ocorre porque o lado de transporte da interface lógica do assinante pseudowire permanece ativo, fazendo com que os serviços estejam ativos.
de protocolos 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 usadas para gerenciamento de assinantes. Aplicativos de assinantes como DHCP e PPPoE podem ser empilhados sobre a 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.
A partir do 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 entre conexões cruzadas (CCC).
Service logical interfaces:
Encapsulamento de Ethernet VPLS
Encapsulamento da ponte VLAN
Encapsulamento de VLAN VPLS
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 provisões para encerrar a interface na l2backhaul-vpn instância de roteamento. A interface lógica de serviço oferece suporte ao encapsulamento entre conexões cruzadas (CCC) de circuitos e provisões para encerrar 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 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 do lado dos 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, 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 precisas de transmissão na interface lógica são suportadas do lado dos 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 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 batimentos cardíacos 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 acabou levando à perda de sessão. Para evitar esta 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, interfaces lógicas de assinantes pseudowire podem ser instanciadas por uma interface de túnel lógico (rlt) redundante em modo de backup ativo. Isso se soma à instalação de 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 de túnel lógicas redundantes é fornecer redundância do caminho de encaminhamento subjacente.
Antes do Junos OS Release 18.3R1, você poderia especificar um máximo de dispositivos de interface de túnel lógico redundantes 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 fornecer redundância de pontos â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. As interfaces lógicas de transporte e serviços criadas para a interface lógica do assinante pseudowire estão empilhadas 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 micronuvem.
-
MPC ou MIC retirados de linha administrativamente.
-
Falha de energia em um MPC ou MIC.
A Figura 3 fornece os detalhes da interface lógica do assinante pseudowire empilhando 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 o transporte ifl quando RLT for usado.
Por padrão, a proteção de enlace para interfaces de túnel redundantes é reversiva. Em caso de falha no enlace ativo, o tráfego é roteado pelo enlace de backup. Quando o enlace ativo é restabelecido, o tráfego é automaticamente roteado de volta para o enlace ativo. Isso causa perda de tráfego e perda de sessão de assinantes.
Para superar a perda de tráfego e sessão, você pode configurar a proteção de enlace nãoevertivo 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 enlace 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 na 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ógico redundante limita o número de interfaces físicas de túnel lógico para duas.
Você não pode desativar 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 por meio de 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 de túnel lógico dos membros podem ser hospedadas em diferentes placas de linha. Como o endereço de distribuição não está disponível para 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 single-hop 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 assinante 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 de backup.
-
Quando qualquer um dos FPCs falha ou reinicializa, todas as sessões hospedadas nesse FPC são baixadas, e a ancoragem é acionada 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 sobre o FPC de backup não caiam quando o FPC ativo falha dependendo do tempo de detecção de BFD configurado, pois o estado de encaminhamento do 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 reescoragem da sessão BFD não é acionada quando o FPC ativo está on-line novamente.
-
Com o comportamento não reversivo habilitado, quando o FPC anteriormente ativo estiver on-line novamente, não se espera que as sessões caiam. 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 bater.
Leve o seguinte em consideração com o suporte da distribuição em linha de sessões de BFD de salto único sobre 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 assinantes pseudowire ancoradas em interfaces de túnel lógicas redundantes.
-
Uma nova mensagem
JTASK_SCHED_SLIPde erro de log do sistema é registrada durante o roteamento ativo (NSR) sem parar. Esse é o comportamento esperado do NSR com alta escala e pode ser ignorado com segurança, a menos que haja outras questões, como abas de sessão, que exijam ações a serem tomadas.
A partir do Junos OS Release 21.4R1, introduzimos o suporte de 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, o CoS aloca nós de agendamento para cada enlace no RLT, que tem vários links de túnel lógicos no modo ativo-ativo. Em 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 para todos os enlaces 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 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 conjunto Svlan IFL dinâmico e o nó uifl dinâmico ou estático são nós-pais.
ao assinante
Quando você habilita 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 infantis, 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 nos [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 nível de [edit chassis] hierarquia, porque esse recurso funciona apenas no modo IP aprimorado.
O modo de enlace múltiplo ativo-ativo com direcionamento usa os algoritmos de segmentação 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 enlaces de membros e seleciona o primeiro pseudo IFL que tem capacidade suficiente com base no configurado rebalance-subscriber-granularity.
Quando o direcionamento é ativado, o assinante recebe um peso-alvo padrão com base no tipo de cliente. O algoritmo de segmentação usa peso de alocação no processo de seleção pseudo IFL e o peso debit do IFL é o peso contado com o pseudo IFL atribuído. Para todos os objetos, exceto o IFLset, a alocação e o peso dobit 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 dobit para o IFLset é fixo em um valor de 0.
| Tipo de cliente |
Peso de alocação |
Peso dobit |
|---|---|---|
| Dvlan |
1 |
1 |
| IpDemux |
1 |
1 |
| PPP |
1 |
1 |
| IFLset |
32 |
0 |
Configurando 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 pseudowire para assinantes:
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ê configura as interfaces posteriormente, 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 redundantes de túnel lógico (rlt) 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.
A partir do Junos OS Release 20.4R1, nos 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 máximos de interface lógica pseudowire oferece 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 de PFE disponíveis conforme configura serviços adicionais nas portas de dispositivos de interface lógica pseudowire. Para dar suporte a uma configuração escalonada, garanta que você preencha 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 pela carga máxima esperada. Como parte do planejamento de rede para sua implantação específica, você deve considerar a mistura 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 pools 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:
Configurando 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 assinantes, você especifica o túnel lógico que processa o encerramento 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 marcação 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 de assinante pseudowire
Você não pode mudar dinamicamente um ponto âncora que tenha dispositivos pseudowire ativos empilhados acima dele. Você deve cometer 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:
Para 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 comprometer. Isso pode exigir a derrubada de todos os assinantes usando 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 em 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 comprometer.
[edit interfaces] user@host# activate psnumber user@host# commit
Para 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 derrubada de quaisquer assinantes que usem os pseudowires. Exclua a interface de túnel lógica redundante e cometa suas alterações.
[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 comprometer.
[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ê 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 à 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 circuitos 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 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. 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 configura 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 assinantes. No entanto, em uma configuração de borda empresarial, 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, 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
RESUMO Você pode configurar uma interface de encerramento de headend pseudowire (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 a tráfego encapsulado por TDM/SONET/SDH proveniente de clientes do lado do acesso. O pseudowire ponto a ponto baseado em IP — que é um fec 128 (vc) sinalizado por LDP (circuito virtual(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 de 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. Esta mediação de ARP é fornecida por proxy ARP 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 LDP alvo para o circuito de Camada 2. Veja configuração de LDP para circuitos de Camada 2 .
- Configure a VPN de Camada 3. Veja a introdução à configuração de VPNs de Camada 3.
Quando você habilita family tcc e encapsulation ethernet-tcc em uma interface PS, observe as seguintes restrições na configuração:
- Suporte para apenas um pseudowire IP por interface física de PS
- Sem suporte para uma palavra de controle; para BFD na interface PS; ou para configuração ativa, de espera a quente ou totalmente ativa no pseudowire IP
Para configurar PWHT no roteador PE de serviço com encerramento 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 enlaces 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, fornecemos suporte para balanceamento de carga para sessões de assinantes na interface PS em vários enlaces 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 disperso e equilibrado em diferentes PICs e placas de linha.
Para a interface RLT, oferece suporte à redundância de pontos âncora de PS para melhorar o modo LAG. Use a opção enhanced-ip ou a opção enhanced-ethernet no nível de hierarquia [edite serviços de rede de chassi] enquanto configura o PS IFD ancorado no RLT.
O hash computado é usado na seleção de um caminho ECMP e balanceamento de carga. Você pode configurar o balanceamento de carga para o 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 para balanceamento de carga BNG no recurso de interface de assinante pseudowire (PS) é suportado apenas para todas as placas de linha baseadas em trio que oferecem suporte ao modelo de acesso BBE nos roteadores da Série MX.
-
Você não pode alterar o ponto âncora do PS a menos que desabiibilize a interface física do PS.
-
A interrupção transitória do tráfego pode ocorrer quando você adiciona ou remove um membro do RLT. Adicionar ou remover o comportamento do enlace de membro RLT é semelhante a qualquer outro comportamento de interface agregada.
-
As estatísticas de ingresso para cada membro da 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 enlaces LT infantis ativos
-
Suporte para interface PS over 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
-
Suporte agregado de Ethernet cos para tráfego de assinantes em interface de serviço pseudowire (PS)
-
Suporte para L2 Service IFL e business-edge (L3) para link de membro do modo ativo
-
Suporte para 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 o tráfego de assinantes:
Veja também
ethernet-tcc encapsulamento na interface. O pseudowire é VC tipo 11.
l2backhaul-vpn instância de roteamento. O encerramento de PPPoE e L2TP não é suportado 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 cruzadas (CCC) de circuitos e provisões para encerrar 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.