Conectando sistemas lógicos usando interfaces lógicas de túnel
Configuração de interfaces lógicas de túnel
As interfaces de túnel lógico (lt-
) fornecem serviços bem diferentes, dependendo do roteador host:
-
Nas séries M, Série MX e roteadores da Série T, as interfaces lógicas de túnel permitem que você conecte sistemas lógicos, roteadores virtuais ou instâncias VPN. Os roteadores da Série M e da Série T devem ser equipados com um PIC de serviços de túnel ou um módulo de serviços adaptativos (disponível apenas em roteadores M7i). Os roteadores da Série MX devem ser equipados com um módulo Trio MPC/MIC. Para obter mais informações sobre a conexão desses aplicativos, consulte a Biblioteca de VPNs do Junos OS para dispositivos de roteamento.
-
Nos gateways de serviços da Série SRX, a interface lógica do túnel é usada para interconectar sistemas lógicos. Consulte o Guia de Usuário de Sistemas Lógicos e Tenant Systems para dispositivos de segurança para obter informações sobre o uso da interface lógica do túnel na Série SRX.
-
Nos roteadores da Série ACX, as interfaces lógicas de túnel permitem que você conecte um domínio de ponte e um pseudowire. Sistemas lógicos não são suportados em roteadores da Série ACX.
Conectando sistemas lógicos
Para conectar dois sistemas lógicos, você configura uma interface lógica de túnel em ambos os sistemas lógicos. Em seguida, você configura uma relação de peer entre as interfaces lógicas do túnel, criando assim uma conexão ponto a ponto.
Para configurar uma conexão ponto a ponto entre dois sistemas lógicos, configure a interface lógica do túnel, incluindo a lt-fpc/pic/port
declaração:
lt-fpc/pic/port { unit logical-unit-number { encapsulation encapsulation; peer-unit unit-number; # peering logical system unit number dlci dlci-number; family (inet | inet6 | iso | mpls); } }
Você pode incluir esta declaração nos seguintes níveis de hierarquia:
-
[edit interfaces]
-
[edit logical-systems logical-system-name interfaces]
Ao configurar interfaces lógicas de túnel, observe o seguinte:
-
Você pode configurar cada interface lógica de túnel com um dos seguintes tipos de encapsulamento: Ethernet, Ethernet circuit cross-connect (CCC), Ethernet VPLS, Frame Relay, Frame Relay CCC, VLAN, VLAN CCC ou VLAN VPLS.
-
Você pode configurar a família de protocolos IP, IPv6, International Organization for Standardization (ISO) ou MPLS.
-
Não reconfigure uma interface de túnel lógica que seja um ponto âncora com dispositivos pseudowire empilhados acima dela, a menos que você primeiro desativar todos os assinantes de banda larga que estejam usando a interface de assinantes pseudowire.
-
As interfaces lógicas de peering devem pertencer à mesma interface lógica de túnel derivada do PIC de Serviços de Túnel ou módulo de serviços adaptativos.
-
Você pode configurar apenas uma unidade peer para cada interface lógica. Por exemplo, a unidade 0 não pode peer com a unidade 1 e a unidade 2.
-
Para habilitar a interface lógica do túnel, você deve configurar pelo menos uma declaração de interface física.
-
Os túneis lógicos não têm suporte para serviços adaptativos, multisserviços ou PICs de serviços de enlace (mas são suportados no Módulo de Serviços Adaptativos em M7i roteadores, como observado acima).
-
Em roteadores da Série M que não sejam o roteador M40e, as interfaces lógicas de túnel exigem um Concentrador PIC Flexível Aprimorado (FPC).
-
Nos roteadores da Série MX, as interfaces lógicas de túnel exigem módulos Trio MPC/MIC. Eles não exigem uma PIC de serviços de túnel no mesmo sistema.
Veja também
Diretrizes para configurar túneis lógicos em roteadores da Série MX
Quando você configura um túnel lógico em um roteador da série MX que tem um dos peer configurado no modo camada 2, garanta que o túnel lógico da camada 2 do peer faça parte de um domínio de ponte ou instância VPLS, para fluxo de tráfego bidirecional.
Para configurar um túnel lógico com encapsulamento de ponte, você deve primeiro configurar o túnel lógico para fazer parte do domínio da ponte. A configuração da amostra a seguir permite configurar um túnel lógico, lt-2/1/0.3 com encapsulamento de ponte.
user@host# edit bridge-domains { bd1 { domain-type bridge; vlan-id 1 } } user@host# edit chassis lt-2/1/0 { unit 3 { description "MPLS port mirroring Bridge ingress interface"; encapsulation ethernet-bridge; mtu 4500; peer-unit 4; family bridge { interface-mode access; vlan-id 1; } } unit 4 { description "MPLS Port mirroring L2/CCC egress interface"; encapsulation ethernet-ccc; mtu 4500; peer-unit 3; family ccc { filter { input HighPriority; } } } }
Diretrizes para configurar túneis lógicos em roteadores da Série ACX
Observe as seguintes diretrizes ao configurar interfaces de túnel lógico (lt-
) em roteadores da Série ACX:
Você pode usar uma interface lógica de túnel para conectar apenas domínios de ponte e pseudowires.
As interfaces lógicas de túnel não podem interconectar os seguintes links:
Pesudowire e uma instância de roteamento (Pseudowire terminando em um VRF)
Duas instâncias de roteamento
Instância VPLS e uma instância de roteamento
Duas instâncias de VPLS
Dois domínios da Ponte
Domínio de ponte e uma instância VPLS
Apenas um túnel lógico (interface física) por tipo de largura de banda (1 Gbps ou 10 Gbps) pode ser configurado em roteadores ACX. No entanto, você pode especificar até duas interfaces lógicas de túnel (uma com largura de banda de 1 Gb e outra com largura de banda de 10 Gb) em rotas ACX.
A largura de banda garantida para túneis lógicos é de 1 Gbps e determinadas plataformas oferecem suporte a até uma largura de banda adicional de 10 Gbps. Todos os serviços configurados usando interfaces lógicas de túnel compartilham essa largura de banda.
A largura de banda configurada na interface lógica do túnel é compartilhada entre o tráfego upstream e downstream nessa interface. A largura de banda efetiva disponível para o serviço é metade da largura de banda configurada.
Várias interfaces lógicas de túnel para permitir a configuração de serviços separados em cada interface lógica para obter maior largura de banda para cada interface individual separadamente ou o agrupamento de interfaces de túnel lógicas individuais não é suportado.
Você pode configurar Ethernet VLAN, Ethernet CCC, ponte VLAN em interfaces Ethernet e VLAN em conexões cruzadas de circuito (CCC) como tipos de encapsulamento em interfaces lógicas de túnel. Outros tipos de encapsulamento, como Ethernet, VLAN, Ethernet VPLS ou VLAN VPLS não são suportados.
Quando o encapsulamento configurado nas unidades de interface lógica é um dos tipos suportados, como ethernet VLAN ou ponte VLAN, você pode habilitar apenas domínios de ponte ou protocolos CCC em interfaces lógicas de túnel. Outras famílias de endereços ou protocolos como IPv4, IPv5, MPLS ou OSPF não são suportados.
A configuração do policial de classificação, reescrita e de entrada é suportada em interfaces lógicas de túnel. Classificadores fixos, baseados em BA e multifield são suportados nas interfaces lt no nível da interface física.
802.1p, 802.1ad, classificadores BA baseados em TOS e DSCP são suportados. As regras de observação podem ser configuradas no nível da porta na interface LT. Os campos 802.1p, 802.1ad, TOS e DSCP no pacote podem ser reescritos na interface LT. Policiais de entrada são apoiados.
Policiais de marcação tricolor simples e de taxa única (srTCM), policiais de marcação tricolor de duas categorias (trTCM) são apoiados. Os policiais de saída não são apoiados.
Os classificadores padrão não funcionam corretamente quando as interfaces lt- são configuradas em PICs não-Ethernet.
A fila no nível da porta é suportada; até oito filas por interface lt são suportadas. Essas oito filas são compartilhadas entre o tráfego upstream e downstream que atravessa a interface lt. Se a largura de banda configurada na interface lt não for adequada para o tráfego upstream e downstream dos serviços configurados na interface, uma falha ocorre com a propagação do tráfego porque várias interfaces lt- não são suportadas.
Oito classes de encaminhamento (0-7) são mapeadas para as oito filas com base na configuração global do sistema. O restante da configuração do agendador, tamanho de buffer, taxa de transmissão, taxa de modelagem, prioridade e mapas de perfis WRED ou drop podem ser configurados nas filas de interface lt.
Os seguintes tipos de filtro de firewall são suportados em interfaces lt:
Filtros lógicos de nível de interface
Filtros da família Bridge
Filtros da família CCC
Todas as configurações de firewall são suportadas. A limitação de escalonamento com esses filtros é a mesma das restrições de filtro de firewall existentes.
O OAM não é suportado em lt-interfaces.
Semelhante a outras interfaces físicas, o número de interfaces lógicas que podem ser suportadas em interfaces físicas de túnel lógico é de 30.
Quando um domínio de ponte é configurado com um VLAN ID (domínio de ponte normalizou VLANs), a diferença é que o comportamento entre roteadores da Série MX e ACX é que o roteador MX não combina com o usuário-vlan-id no filtro de saída, enquanto o roteador ACX combina com o usuário-vlan-id especificado no filtro de saída.
Se a interface lógica do túnel for criada usando PICs não Ethernet, o classificador padrão não estará vinculado à interface.
Para criar interfaces lógicas de túnel e a largura de banda em gigabits por segundo para reservar para serviços de túnel, inclua a tunnel-services bandwidth (1g | 10g)
declaração no nível de [edit chassis fpc slot-number pic number]
hierarquia:
[edit interfaces] lt-fpc/pic/port { unit logical-unit-number { encapsulation encapsulation; peer-unit unit-number; # peering logical system unit number dlci dlci-number; family (inet | inet6 | iso | mpls); } }
Os roteadores ACX5048 e ACX5096 oferecem suporte ethernet-vpls
e vlan-vpls
encapsulamentos. Esses encapsulamentos são suportados apenas na interface lógica do túnel e são necessários para configurar VPLS hierárquica.
Você pode usar qualquer porta física não usada nos roteadores ACX5048 e ACX5096 para criar uma interface de túnel lógica conforme mostrado abaixo:
user@host# edit chassis fpc 0 { pic 0 { tunnel-services { port port-number; } } }
A configuração da amostra a seguir permite encapsular vlan-ccc
a vlan-vpls
interface LT nos roteadores ACX5048 e ACX5096:
user@host# edit interfaces lt-0/0/1 { unit 0 { encapsulation vlan-ccc; vlan-id 1; peer-unit 1; } unit 1 { encapsulation vlan-vpls; vlan-id 1; peer-unit 0; } }
Exemplo: configuração de túneis lógicos
Configure três túneis lógicos:
[edit interfaces] lt-4/2/0 { description “Logical tunnel interface connects three logical systems”; } [edit logical-systems] lr1 { interfaces lt-4/2/0 { unit 12 { peer-unit 21; #Peering with lr2 encapsulation frame-relay; dlci 612; family inet; } unit 13 { peer-unit 31; #Peering with lr3 encapsulation frame-relay-ccc; dlci 613; } } } lr2 { interfaces lt-4/2/0 { unit 21 { peer-unit 12; #Peering with lr1 encapsulation frame-relay-ccc; dlci 612; } unit 23 { peer-unit 32; #Peering with lr3 encapsulation frame-relay; dlci 623; } } } lr3 { interfaces lt-4/2/0 { unit 31 { peer-unit 13; #Peering with lr1 encapsulation frame-relay; dlci 613; family inet; } unit 32 { peer-unit 23; #Peering with lr2 encapsulation frame-relay-ccc; dlci 623; } } }
Veja também
Configurando uma interface no domínio VRF para receber tráfego multicast
Você pode configurar um roteador da Série ACX para receber tráfego multicast em um domínio VRF. Em uma solução IPTV, fontes e receptores IPTV podem ser espalhados por diferentes pontos finais de uma rede em um domínio VRF. Para receber o tráfego multicast ao lado do receptor, é necessário que o tráfego multicast seja tunelado em toda a rede para chegar ao dispositivo de recebimento final ou ao assinante. Esse tunelamento geralmente é feito usando a tecnologia Multicast Virtual Private Network (MVPN).
Os roteadores da Série ACX não oferecem suporte à tecnologia MVPN. Um método alternativo para receber o tráfego multicast no domínio VRF no roteador da Série ACX é associando uma interface lógica global a uma interface lógica no domínio VRF. A interface lógica global atua como um proxy para receber o tráfego multicast na interface lógica no domínio VRF. Para associar uma interface lógica global a uma interface lógica no domínio VRF, você precisa configurar uma interface IRB em um domínio global para atuar como um proxy para a interface lógica no domínio VRF.
- Configurando uma interface lógica proxy no domínio global
- Associando a interface lógica proxy a uma interface lógica em um domínio VRF
- Limitações
Configurando uma interface lógica proxy no domínio global
Para configurar uma interface lógica de proxy no domínio global, você precisa criar interface de túnel lógico (lt-) e interface IRB e, em seguida, associar a interface IRB a um domínio de ponte. O exemplo a seguir é configurar uma interface lógica de proxy no domínio global:
Crie uma interface de túnel lógico (lt-).
[edit] user@host# set chassis aggregated-devices ethernet device-count 1 user@host# set chassis fpc 0 pic 0 tunnel-services bandwidth 1g user@host# set interfaces lt-0/0/10 unit 0 encapsulation vlan-bridge user@host# set interfaces lt-0/0/10 unit 0 vlan-id 101 user@host# set interfaces lt-0/0/10 unit 0 peer-unit 1 user@host# set interfaces lt-0/0/10 unit 1 encapsulation vlan-ccc user@host# set interfaces lt-0/0/10 unit 1 vlan-id 101 user@host# set interfaces lt-0/0/10 unit 1 peer-unit 0
Crie uma interface IRB.
[edit] user@host# set interfaces irb unit 0 family inet address 192.168.1.2/24
Associe a interface IRB a um domínio de ponte.
[edit] user@host# set bridge-domains b1 vlan-id 101 user@host# set bridge-domains b1 interface lt-0/0/10.0 user@host# set bridge-domains b1 routing-interface irb.0
Associando a interface lógica proxy a uma interface lógica em um domínio VRF
Para associar a interface lógica do proxy a uma interface lógica em um domínio VRF, você precisa executar os seguintes comandos PFE:
test pfe acx vrf-mc-leak enable
— Permite a associação de proxy.test pfe acx entry add VRF-logical-interface-name logical-tunnel-logical-interface-name IRB-logical-interface-name IRB-IP-address + 1
— Cria uma associação entre a interface lógica do proxy e a interface lógica em um domínio VRF.test pfe acx vrf-mc-leak disable
— Desativa a associação de proxy.test pfe acx entry del VRF-logical-interface-name logical-tunnel-logical-interface-name IRB-logical-interface-name IRB-IP-address + 1
— Elimina a associação entre a interface lógica do proxy e a interface lógica em um domínio VRF.show pfe vrf-mc-leak
— Exibe as entradas de associação entre a interface lógica do proxy e a interface lógica em um domínio VRF.
Quando o roteador ou PFE é reiniciado, as associações de proxy de interfaces lógicas são removidas e você precisa criar mais uma vez as associações de proxy da interface lógica.
Limitações
As seguintes limitações precisam ser consideradas para receber tráfego multicast em um domínio VRF:
No máximo 5 associações de proxy de interfaces lógicas podem ser configuradas.
O multicast VRF IPv6 não tem suporte.
A interface AE como uma interface VRF (solicitando tráfego multicast) não é suportada.
O tráfego multicast não pode ser encaminhado da interface lógica em um domínio VRF se o primeiro roteador hop for um roteador ACX.
Visão geral de túneis lógicos redundantes
Você pode conectar dois dispositivos, como um dispositivo voltado para o acesso e um dispositivo voltado para o núcleo, através de túneis lógicos. Para fornecer redundância para os túneis, você pode criar e configurar vários túneis lógicos físicos e adicioná-los a um túnel lógico redundante virtual.
Túneis lógicos redundantes são suportados apenas em roteadores da Série MX com MPCs. A partir do Junos OS Release 18.4R3, túneis lógicos redundantes são suportados no Virtual Chassis da Série MX.
Por exemplo, em uma rede de acesso MPLS, você pode configurar vários pseudowires entre um nó de acesso e um roteador da Série MX com MPCs e adicioná-los a um túnel lógico redundante. Em seguida, você pode adicionar vários túneis lógicos ao túnel lógico redundante. A Figura 1 mostra um túnel lógico redundante entre o nó de acesso e o roteador da Série MX.
O túnel lógico redundante tem interfaces lógicas peer em cada extremidade, rlt0.0 e rlt0.1. Você pode configurar recursos de roteador nessas interfaces para o túnel lógico redundante e seus membros.
Cada túnel lógico de membro tem interfaces lógicas de peer. Na Figura 1, lt-0/0/10,0 e lt-0/0/10.1 são pares.
O roteador da Série MX realiza uma busca ip na tabela de roteamento e encaminhamento de VPN de Camada 3 (VRF) no roteador onde terminam os pseudowires agrupados em túneis lógicos.
Configuração de túnel lógico redundante
No Junos OS Releases 14.1R1 e anterior, você pode criar até 16 túneis lógicos redundantes, dependendo do número de mecanismos de encaminhamento de pacotes e do número de interfaces de loopback em cada mecanismo de encaminhamento de pacotes em seu dispositivo. A partir do Junos OS Release 14.2 e para 13.3R3 e 14.1R2, o intervalo válido para a contagem de dispositivos é de 1 a 255.
Você pode somar 32 túneis lógicos como membros de um túnel lógico redundante.
Quando você adiciona mais de dois membros ao túnel lógico redundante, eles estão em modo ativo. O tráfego é equilibrado em todos os membros do túnel.
Quando você adiciona apenas dois membros ao túnel lógico redundante, você pode configurar os membros de uma dessas maneiras:
Ambos os membros no modo ativo
Um membro no modo ativo e o outro no modo de backup
Detecção e failover redundantes de falhas em túneis lógicos
Um túnel lógico falha e é removido do grupo de túneis lógicos redundantes, e o túnel lógico de backup fica ativo devido a um desses eventos:
Ocorre uma falha de hardware no módulo MPC.
Uma falha de MPC ocorre devido a um acidente de microkernel.
O módulo MPC é desligado administrativamente e removido do túnel lógico redundante.
Ocorre uma falha de energia no módulo MPC.
Você pode diminuir o tempo necessário para que a detecção de falhas e o failover ocorram. Configure a enhanced-ip
declaração no nível de [edit chassis network-services]
hierarquia para permitir a detecção de linhas de vida do Mecanismo de Encaminhamento de Pacotes.
Veja também
Configuração de túneis lógicos redundantes
Use túneis lógicos redundantes para fornecer redundância para túneis lógicos entre dois dispositivos, como um dispositivo voltado para o acesso e um dispositivo voltado para o núcleo.
Ao configurar interfaces lógicas de túnel redundantes, observe o seguinte:
A partir do Junos OS Release 13.3, você pode configurar túneis lógicos redundantes apenas em roteadores da Série MX com MPCs.
No Junos OS Releases 14.1R1 e anterior, você pode criar até 16 túneis lógicos redundantes, dependendo do número de mecanismos de encaminhamento de pacotes e do número de interfaces de loopback em cada mecanismo de encaminhamento de pacotes em seu dispositivo. A partir do Junos OS Release 14.2 e para 13.3R3 e 14.1R2, o intervalo válido para a contagem de dispositivos é de 1 a 255. O comando é mostrado abaixo.
set chassis redundancy-group interface-type redundant-logical-tunnel device-count [number]
;Você pode somar 32 túneis lógicos como membros.
Quando um túnel lógico com uma configuração existente se junta a um túnel lógico redundante, você deve configurar o túnel lógico redundante com as configurações da configuração existente.
Você pode adicionar túneis lógicos de membros a um túnel lógico dos pais para redundância.
Quando você adiciona mais de dois túneis lógicos ao túnel lógico redundante, os membros estão em modo ativo por padrão.
Ao adicionar apenas dois membros, você pode configurar os membros de uma dessas maneiras:
Ambos os membros no modo ativo
Um membro no modo ativo e o outro no modo de backup
Para configurar um túnel lógico redundante entre dois dispositivos:
Exemplo: configuração de túneis lógicos redundantes
Este exemplo mostra como configurar túneis lógicos redundantes em uma rede de acesso MPLS.
Requisitos
No Junos OS Release 13.3 ou posterior, você pode configurar túneis lógicos redundantes apenas em roteadores da Série MX com MPCs.
Visão geral
Quando um túnel lógico com uma configuração existente se junta a um túnel lógico redundante, você deve configurar o túnel lógico redundante com as configurações da configuração existente.
Você pode adicionar túneis lógicos de membros a um túnel lógico dos pais para redundância.
Nos roteadores da Série MX com MPCs, você pode configurar túneis lógicos redundantes da seguinte forma:
No Junos OS Releases 14.1R1 e anterior, você pode criar até 16 túneis lógicos redundantes, dependendo do número de mecanismos de encaminhamento de pacotes e do número de interfaces de loopback em cada mecanismo de encaminhamento de pacotes em seu dispositivo. A partir do Junos OS Release 14.2 e para 13.3R3 e 14.1R2, o intervalo válido para a contagem de dispositivos é de 1 a 255. O comando é mostrado abaixo.
set chassis redundancy-group interface-type redundant-logical-tunnel device-count [number]
;Você pode somar 32 túneis lógicos como membros.
Quando você adiciona mais de dois túneis lógicos a um túnel lógico redundante, os membros estão em modo ativo por padrão.
Ao adicionar apenas dois membros, você pode configurar os membros de uma dessas maneiras:
Ambos os membros no modo ativo
Um membro no modo ativo e o outro no modo de backup
Topologia
A Figura 2 mostra um túnel lógico redundante entre o nó de acesso e o roteador da Série MX em uma rede de acesso MPLS.
O túnel lógico redundante tem interfaces lógicas peer em cada extremidade, rlt0.0 e rlt0.1. Você pode configurar recursos de roteador nessas interfaces para o túnel lógico redundante e seus membros.
Cada túnel lógico de membro tem interfaces lógicas de peer nos dispositivos voltados para o acesso e voltados para o núcleo. Na Figura 2, lt-0/0/10.0 e lt-0/0/10.1 são pares.
O roteador da Série MX realiza uma busca ip na tabela de roteamento e encaminhamento de VPN de Camada 3 (VRF) no roteador onde terminam os pseudowires agrupados em túneis lógicos.
Configuração
Configuração rápida da CLI
Para configurar rapidamente este exemplo, copie os seguintes comandos, cole-os em um arquivo de texto, remova quaisquer quebras de linha, altere os detalhes necessários para combinar com a configuração de sua rede e, em seguida, copie e cole os comandos na CLI no nível de [edit]
hierarquia.
set chassis redundancy-group interface-type redundant-logical-tunnel device-count 4 set chassis fpc 1 pic 0 tunnel-services bandwidth 1g set chassis fpc 2 pic 2 tunnel-services bandwidth 1g set interfaces rlt0 redundancy-group member-interface lt-1/0/10 set interfaces rlt0 redundancy-group member-interface lt-2/0/10 set interfaces rlt0 unit 0 description "Towards Layer 2 Circuit" set interfaces rlt0 unit 0 encapsulation vlan-ccc set interfaces rlt0 unit 0 vlan-id 600 set interfaces rlt0 unit 0 peer-unit 1 set interfaces rlt0 unit 0 family ccc set interfaces rlt0 unit 1 description "Towards Layer 3 VRF" set interfaces rlt0 unit 1 encapsulation vlan set interfaces rlt0 unit 1 vlan-id 600 set interfaces rlt0 unit 1 peer-unit 0 set interfaces rlt0 unit 1 family inet address 10.10.10.2/24 set protocols l2circuit neighbor 192.0.2.2 interface rlt0.0 virtual-circuit-id 100 set protocols l2circuit neighbor 192.0.2.2 interface rlt0.0 no-control-word set routing-instances pe-vrf instance-type vrf set routing-instances pe-vrf interface rlt0.1 set routing-instances pe-vrf route-distinguisher 65056:1 set routing-instances pe-vrf vrf-import VPN-A-Import set routing-instances pe-vrf vrf-export VPN-A-Export set routing-instances pe-vrf vrf-table-label set routing-instances pe-vrf protocols ospf export VPN-A-Import set routing-instances pe-vrf protocols ospf area 0.0.0.0 interface rlt0.1 set protocols mpls no-cspf set protocols mpls interface all set protocols ldp interface all set protocols bgp export local-routes set protocols bgp group internal type internal set protocols bgp group internal local-address 198.51.100.3 set protocols bgp group internal family inet any set protocols bgp group internal family inet-vpn unicast set protocols bgp group internal neighbor 203.0.113.4 set protocols ospf area 0.0.0.0 interface ge-5/3/8.0 set protocols ospf area 0.0.0.0 interface ge-5/2/5.0 set protocols ospf area 0.0.0.0 interface lo0.3 passive set policy-options policy-statement VPN-A-Export term a then community add VPN-A set policy-options policy-statement VPN-A-Export term a then accept set policy-options policy-statement VPN-A-Export term b then reject set policy-options policy-statement VPN-A-Import term a from protocol bgp set policy-options policy-statement VPN-A-Import term a from community VPN-A set policy-options policy-statement VPN-A-Import term a then accept set policy-options policy-statement VPN-A-Import term b then reject set policy-options policy-statement local-routes then accept set policy-options community VPN-A members target:100:100 set routing-options router-id 198.51.100.3 set routing-options autonomous-system 65056
Procedimento
Procedimento passo a passo
Neste exemplo, todos os túneis lógicos estão em modo ativo.
Crie o túnel lógico e interfaces de túnel lógicas redundantes.
[edit chassis] user@host# set redundancy-group interface-type redundant-logical-tunnel device-count 4 user@host# set fpc 1 pic 0 tunnel-services bandwidth 1g user@host# set fpc 2 pic 2 tunnel-services bandwidth 1g
Vincule os túneis lógicos dos membros ao túnel lógico redundante.
[edit interfaces] user@host# set rlt0 redundancy-group member-interface lt-1/0/10 user@host# set rlt0 redundancy-group member-interface lt-2/0/10
Configure as interfaces de túnel lógica redundantes.
[edit interfaces] user@host# set rlt0 unit 0 description "Towards Layer 2 Circuit" user@host# set rlt0 unit 0 encapsulation vlan-ccc user@host# set rlt0 unit 0 vlan-id 600 user@host# set rlt0 unit 0 peer-unit 1 user@host# set rlt0 unit 0 family ccc user@host# set rlt0 unit 1 description "Towards Layer 3 VRF" user@host# set rlt0 unit 1 encapsulation vlan user@host# set rlt0 unit 1 vlan-id 600 user@host# set rlt0 unit 1 peer-unit 0 user@host# set rlt0 unit 1 family inet address 10.10.10.2/24
Conecte rlt0.0 a um circuito de Camada 2.
[edit protocols] user@host# set l2circuit neighbor 192.0.2.2 interface rlt0.0 virtual-circuit-id 100 user@host# set l2circuit neighbor 192.0.2.2 interface rlt0.0 no-control-word
Adicione rlt0.1 a uma instância VRF de Camada 3.
[edit routing-instances] user@host# set pe-vrf instance-type vrf user@host# set pe-vrf interface rlt0.1 user@host# set pe-vrf route-distinguisher 65056:1 user@host# set pe-vrf vrf-import VPN-A-Import user@host# set pe-vrf vrf-export VPN-A-Export user@host# set pe-vrf vrf-table-label user@host# set pe-vrf protocols ospf export VPN-A-Import user@host# set pe-vrf protocols ospf area 0.0.0.0 interface rlt0.1
Configure MPLS e LDP nos pseudowires e na VPN de Camada 3.
[edit protocols] user@host# set mpls no-cspf user@host# set mpls interface all user@host# set ldp interface all
Configure o BGP na VPN de Camada 3.
[edit protocols] user@host# set bgp export local-routes user@host# set bgp group internal type internal user@host# set bgp group internal local-address 198.51.100.3 user@host# set bgp group internal family inet any user@host# set bgp group internal family inet-vpn unicast user@host# set bgp group internal neighbor 203.0.113.4
Configure o OSPF nas interfaces voltadas para o núcleo e na interface de loopback local do roteador.
[edit protocols] user@host# set ospf area 0.0.0.0 interface ge-5/3/8.0 user@host# set ospf area 0.0.0.0 interface ge-5/2/5.0 user@host# set ospf area 0.0.0.0 interface lo0.3 passive
Defina as opções de política para BGP.
[edit policy-options] user@host# set policy-statement VPN-A-Export term a then community add VPN-A user@host# set policy-statement VPN-A-Export term a then accept user@host# set policy-statement VPN-A-Export term b then reject user@host# set policy-statement VPN-A-Import term a from protocol bgp user@host# set policy-statement VPN-A-Import term a from community VPN-A user@host# set policy-statement VPN-A-Import term a then accept user@host# set policy-statement VPN-A-Import term b then reject user@host# set policy-statement local-routes then accept user@host# set community VPN-A members target:100:100
Defina o número de ID do roteador e do sistema autônomo (AS).
[edit routing-options] user@host# set router-id 198.51.100.3 user@host# set autonomous-system 65056
Resultados
A partir do modo de configuração, confirme sua configuração inserindo os seguintes comandos:
show chassis
show interfaces
show policy-options
show protocols
show routing-instances
show routing-options
Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.
user@host# show chassis redundancy-group { interface-type { redundant-logical-tunnel { device-count 4; } } } fpc 1 { pic 0 { tunnel-services { bandwidth 1g; } } } fpc 1 { pic 2 { tunnel-services { bandwidth 1g; } } }
user@host# show interfaces rlt0 redundancy-group { member-interface lt-1/0/10; member-interface lt-2/0/10; } unit 0 { description "Towards Layer 2 Circuit"; encapsulation vlan-ccc; vlan-id 600; peer-unit 1; family ccc; } unit 1 { description "Towards Layer 3 VRF"; encapsulation vlan; vlan-id 600; peer-unit 0; family inet { address 10.10.10.2/24; } }
user@host# show protocols l2circuit neighbor 192.0.2.2 { interface rlt0.0 { virtual-circuit-id 100; no-control-word; } }
user@host# show protocols mpls { no-cspf; interface all; } bgp { export local-routes; group internal { type internal; local-address 198.51.100.3; family inet { any; } family inet-vpn { unicast; } neighbor 203.0.113.4; } } ospf { area 0.0.0.0 { interface ge-5/3/8.0; interface ge-5/2/5.0; interface lo0.3 { passive; } } } ldp { interface all; } l2circuit { neighbor 192.0.2.2 { interface rlt0.0 { virtual-circuit-id 100; no-control-word; } } }
user@host# routing-instances pe-vrf { instance-type vrf; interface rlt0.1; route-distinguisher 65056:1; vrf-import VPN-A-Import; vrf-export VPN-A-Export; vrf-table-label; protocols { ospf { export VPN-A-Import; area 0.0.0.0 { interface rlt0.1; } } } }
user@host# policy-options policy-statement VPN-A-Export { term a { then { community add VPN-A; accept; } } term b { then reject; } } policy-statement VPN-A-Import { term a { from { protocol bgp; community VPN-A; } then accept; } term b { then reject; } } policy-statement local-routes { then accept; } community VPN-A members target:100:100;
user@host# routing-options router-id 198.51.100.3; autonomous-system 65056;
Verificação
Confirme que a configuração está funcionando corretamente.
- Verificando a configuração redundante do túnel lógico
- Verificando o circuito de Camada 2
- Verificação de vizinhos do OSPF
- Verificando o BGP Group
- Verificando as rotas BGP na tabela de roteamento
Verificando a configuração redundante do túnel lógico
Propósito
Verifique se o túnel lógico redundante com as interfaces de túnel lógico infantil são criados com os encapsulamentos corretos.
Ação
user@host# run show interfaces terse | match rlt0 lt-1/0/10.0 up up container--> rlt0.0 lt-1/0/10.1 up up container--> rlt0.1 lt-2/0/10.0 up up container--> rlt0.0 lt-2/0/10.1 up up container--> rlt0.1 rlt0 up up rlt0.0 up up ccc rlt0.1 up up inet 10.10.10.2/24
Verificando o circuito de Camada 2
Propósito
Verifique se o circuito de Camada 2 está funcionando.
Ação
user@host# run show l2circuit connections Layer-2 Circuit Connections: Legend for connection status (St) EI -- encapsulation invalid NP -- interface h/w not present MM -- mtu mismatch Dn -- down EM -- encapsulation mismatch VC-Dn -- Virtual circuit Down CM -- control-word mismatch Up -- operational VM -- vlan id mismatch CF -- Call admission control failure OL -- no outgoing label IB -- TDM incompatible bitrate NC -- intf encaps not CCC/TCC TM -- TDM misconfiguration BK -- Backup Connection ST -- Standby Connection CB -- rcvd cell-bundle size bad SP -- Static Pseudowire LD -- local site signaled down RS -- remote site standby RD -- remote site signaled down HS -- Hot-standby Connection XX -- unknown Legend for interface status Up -- operational Dn -- down Neighbor: 192.0.2.2 Interface Type St Time last up # Up trans rlt0.0(vc 100) rmt Up Aug 8 00:28:04 2013 1 Remote PE: 192.0.2.2, Negotiated control-word: No Incoming label: 299776, Outgoing label: 299776 Negotiated PW status TLV: No Local interface: rlt0.0, Status: Up, Encapsulation: VLAN
Verificação de vizinhos do OSPF
Propósito
Verifique se os roteadores são adjacentes e capazes de trocar dados do OSPF.
Ação
user@host# run show ospf neighbor Address Interface State ID Pri Dead 198.168.30.2 ge-5/2/5.0 Full 203.0.113.4 128 38 198.168.20.1 ge-5/3/8.0 Full 192.0.2.2 128 38
Verificando o BGP Group
Propósito
Verifique se o grupo BGP foi criado.
Ação
user@host# run show bgp group internal Group Type: Internal AS: 65056 Local AS: 65056 Name: internal Index: 0 Flags: <Export Eval> Export: [ local-routes ] Holdtime: 0 Total peers: 1 Established: 1 203.0.113.4+179 inet.0: 1/6/3/0 inet.2: 0/0/0/0 bgp.l3vpn.0: 2/2/2/0 pe-vrf.inet.0: 2/2/2/0
Verificando as rotas BGP na tabela de roteamento
Propósito
Verifique se as rotas BGP estão na tabela de roteamento pe-vrf.inet.0.
Ação
user@host# run show route protocol bgp table pe-vrf.inet.0 pe-vrf.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 198.168.50.0/24 *[BGP/170] 01:18:14, localpref 100, from 203.0.113.4 AS path: I, validation-state: unverified > to 198.168.30.2 via ge-5/2/5.0, Push 16 198.168.51.0/24 *[BGP/170] 01:18:14, MED 2, localpref 100, from 203.0.113.4 AS path: I, validation-state: unverified > to 198.168.30.2 via ge-5/2/5.0, Push 16