Exemplo: configurar a EVPN com a solução IRB
Visão geral da solução EVPN com IRB
Um provedor de serviços de data center (DCSP) hospeda o data center para seus vários clientes em uma rede física comum. Para cada cliente (também chamado de tenant), o serviço parece um data center completo que pode se expandir para 4094 VLANs e todas as sub-redes privadas. Para recuperação de desastres, alta disponibilidade e otimização da utilização de recursos, é comum que o DCSP atravesse o data center até mais de um site. Para implantar os serviços de data center, um DCSP enfrenta os seguintes principais desafios:
Estendendo domínios de Camada 2 em mais de um site de data center. Isso requer um encaminhamento ideal de tráfego intra-subnet.
Suporte ao encaminhamento ideal de tráfego entre sub-redes e ao roteamento ideal em caso de máquina virtual (VM).
Suporte a vários locatários com VLAN independente e espaço de sub-rede.
A VPN Ethernet (EVPN) tem como alvo lidar com todos os desafios mencionados acima, em que:
A funcionalidade EVPN básica permite o encaminhamento ideal de tráfego intra-subnet
Implementar a solução integrada de roteamento e ponte (IRB) em uma implantação de EVPN permite o encaminhamento ideal de tráfego entre sub-redes
Configurar a EVPN com suporte a switch virtual permite que vários locatários com VLAN independente e espaço de sub-rede
As seções a seguir descrevem a solução IRB para EVPNs:
- Necessidade de uma solução EVPN IRB
- Implementação da solução EVPN IRB
- Benefícios da implementação da solução EVPN IRB
Necessidade de uma solução EVPN IRB
A EVPN é uma tecnologia usada para fornecer extensão e interconexão de Camada 2 em uma rede núcleo IP/MPLS para diferentes locais físicos pertencentes a um único domínio de Camada 2. Em um ambiente de data center com EVPN, existe a necessidade de encaminhamento de Camada 2 (tráfego intra-subnet) e Camada 3 (tráfego inter-subnet) e potencialmente interoperação com VPNs de Camada 3 de tenant.
Com apenas uma solução de Camada 2, não há encaminhamento ideal do tráfego entre sub-redes, mesmo quando o tráfego é local, por exemplo, quando ambas as sub-redes estão no mesmo servidor.
Com apenas uma solução de Camada 3, os seguintes problemas para o tráfego intra-subnet podem surgir:
MAC resolver problema de aliasing onde endereços MAC duplicados não são detectados.
Problema de TTL para aplicativos que usam TTL 1 para limitar o tráfego em uma sub-rede.
Endereçamento local de enlace IPv6 e detecção de endereço duplicado que depende da conectividade de Camada 2.
O encaminhamento de Camada 3 não suporta a semântica de encaminhamento de uma transmissão de sub-rede.
Suporte a aplicativos não IP que exigem encaminhamento de Camada 2.
Devido às deficiências mencionadas acima de uma solução pura de Camada 2 e Camada 3, existe a necessidade de uma solução que incorpore o encaminhamento ideal do tráfego de Camada 2 e Camada 3 no ambiente do data center diante de considerações operacionais, como a interoperabilidade de VPN de Camada 3 e a mobilidade de máquina virtual (VM).
Uma solução de roteamento e ponte integrada (IRB) baseada em EVPN oferece o melhor encaminhamento unicast e multicast para intra-subnets e inter-subnets dentro e entre data centers.
O recurso EVPN IRB é útil para provedores de serviços que operam em uma rede IP/MPLS que fornece serviços VPN ou VPLS de Camada 2 e serviços VPN de Camada 3 que desejam estender seus serviços para fornecer serviços de computação e armazenamento em nuvem aos seus clientes existentes.
Implementação da solução EVPN IRB
Uma solução EVPN IRB fornece o seguinte:
Encaminhamento ideal para tráfego intra-subnet (Camada 2).
Encaminhamento ideal para tráfego entre subnet (Camada 3).
Suporte para replicação de ingresso para tráfego multicast.
Suporte para modelos de overlay baseados em rede e baseados em host.
Suporte para encaminhamento consistente baseado em políticas para tráfego de Camada 2 e Camada 3.
Suporte para os seguintes protocolos de roteamento na interface IRB:
BFD
BGP
IS-IS
OSPF e OSPF versão 3
Suporte para multihoming único ativo e totalmente ativo
O Junos OS oferece suporte a vários modelos de configuração de EVPN para atender às necessidades individuais dos clientes de serviços de nuvem de EVPN e data center. Para oferecer flexibilidade e escalabilidade, vários domínios de ponte podem ser definidos em uma instância EVPN específica. Da mesma forma, uma ou mais instâncias de EVPN podem ser associadas a um único roteamento e encaminhamento virtual VPN de Camada 3 (VRF). Em geral, cada locatário de data center recebe uma VPN VRF única de Camada 3, enquanto um locatário pode incluir uma ou mais instâncias de EVPN e um ou mais domínios de ponte por instância EVPN. Para dar suporte a esse modelo, cada domínio de ponte configurado (incluindo o domínio da ponte padrão para uma instância EVPN) requer uma interface IRB para executar as funções de Camada 2 e Camada 3. Cada domínio de ponte ou mapas de interface IRB para uma sub-rede IP única no VRF.
Você pode associar uma interface IRB à tabela inet.0 de instância primária em vez de uma VRF em uma solução EVPN IRB.
Existem duas funções importantes que são suportadas para IRB na EVPN.
Sincronização MAC-IP do host
Isso inclui:
Anunciando o endereço IP junto com a rota de anúncio MAC na EVPN. Isso é feito usando o campo IP na rota de anúncios EVPN MAC.
O roteador PE recebedor instala MAC na tabela de instâncias EVPN (EVI) e instala IP no VRF associado.
Sincronização MAC-IP do gateway
Isso inclui:
Anunciando todos os endereços IRB MAC e IP locais em uma EVPN. Isso é conseguido incluindo a comunidade estendida de gateway padrão na rota de anúncios EVPN MAC.
O PE recebendo cria um estado de encaminhamento para pacotes de roteamento destinados ao MAC de gateway, e um ARP proxy é feito para o IP do gateway com o MAC anunciado na rota.
A Figura 1 ilustra o encaminhamento de tráfego entre sub-rede entre dois dispositivos de borda de provedor (PE) – PE1 e PE2. As interfaces IRB1 e IRB2 em cada dispositivo PE pertencem a uma sub-rede diferente, mas compartilham um VRF comum.

O encaminhamento de tráfego entre sub-redes é realizado da seguinte forma:
O PE2 anuncia a vinculação H3-M3 e H4-M4 ao PE1. Da mesma forma, o PE1 anuncia a vinculação H1-M1 e H2-M2 ao PE2.
PE1 e PE2 instalam o endereço MAC na tabela EVI MAC correspondente, enquanto as rotas IP são instaladas no VRF compartilhado.
O dispositivo PE publicitário é definido como o próximo salto para as rotas IP.
Se h1 enviar pacotes para H4, os pacotes são enviados para IRB1 no PE1.
A busca por IP para H4 acontece no VRF compartilhado no PE1. Como o próximo salto para o IP H4 é PE2 (o PE publicitário), um pacote ip unicast é enviado para PE2.
O PE1 reescreve o cabeçalho MAC com base nas informações da rota VRF, e o PE2 realiza uma busca MAC para encaminhar o pacote ao H4.
Benefícios da implementação da solução EVPN IRB
O principal objetivo da solução EVPN IRB é fornecer o melhor encaminhamento de Camada 2 e Camada 3. A solução é necessária para lidar com o encaminhamento inter-subnet de maneira eficiente, bem como a mobilidade de máquinas virtuais (VM). A mobilidade de VM refere-se à capacidade de uma VM de migrar de um servidor para outro dentro do mesmo ou de um data center diferente, mantendo seu endereço MAC e IP existentes. Fornecer o encaminhamento ideal para tráfego inter-subnet e mobilidade VM eficaz envolve a resolução de dois problemas: o problema padrão do gateway e o problema do roteamento intrinquente.
A partir do Junos OS Release 17.1R1, os endereços IPv6 são suportados em interfaces IRB com EVPN usando o Neighbor Discovery Protocol (NDP). Os seguintes recursos são introduzidos para suporte ao IPv6 com EVPN:
Endereços IPv6 em interfaces IRB em instâncias primárias de roteamento
Aprendendo o bairro IPv6 com uma mensagem de NA solicitada
Os pacotes NS e NA nas interfaces IRB são desativados do núcleo de rede
Endereços de gateway virtuais são usados como endereços de Camada 3
Sincronização MAC-IP hospedada para IPv6
Você pode configurar os endereços IPv6 na interface IRB no nível de [edit interfaces irb]
hierarquia.
Sincronização de GATEWAY MAC e IP
Em uma implantação de EVPN IRB, o gateway padrão IP para uma VM é o endereço IP configurado na interface IRB do roteador de borda do provedor (PE) correspondente ao domínio da ponte ou VLAN do qual o VM é um membro. O problema do gateway padrão surge porque uma VM não libera sua tabela ARP ao realocar de um servidor para outro e continua enviando pacotes com o endereço MAC de destino definido para o do gateway original. Se os servidores antigos e novos não fizerem parte do mesmo domínio de Camada 2 (o novo domínio de Camada 2 pode estar dentro do data center atual ou de um novo data center), o gateway identificado anteriormente não é mais o gateway ideal ou local. O novo gateway precisa identificar pacotes contendo os endereços MAC de outros gateways em roteadores PE remotos e encaminhar o tráfego como se os pacotes fossem destinados ao gateway local. No mínimo, essa funcionalidade requer que cada roteador PE anuncie seu gateway ou endereços MAC e IP IRB para todos os outros roteadores PE da rede. A troca de endereços de gateway pode ser realizada usando a mensagem de anúncio de rota MAC padrão (incluindo o parâmetro de endereço IP) e marcando essa rota com a comunidade estendida de gateway padrão para que os roteadores PE remotos possam distinguir as rotas de anúncio mac de gateway das rotas de anúncio MAC normais.
Interworking de VPN de Camada 3
O aspecto inter-data center da solução EVPN IRB envolve o roteamento entre VMs presentes em diferentes data centers ou roteamento entre um site de host completamente fora do ambiente do data center e uma VM dentro de um data center. Essa solução depende da capacidade dos anúncios de rota EVPN MAC de transportar informações de endereço MAC e endereço IP. A funcionalidade de aprendizado MAC local do roteador PE é estendida para também capturar informações de endereço IP associadas aos endereços MAC aprendidos localmente. Essas informações de mapeamento de endereço IP-MAC são então distribuídas a cada roteador PE por meio de procedimentos EVPN normais. Quando um roteador PE recebe essas informações de MAC e IP, ele instala a rota MAC na instância EVPN, bem como uma rota de host para o endereço IP associado na VPN VRF de Camada 3 correspondente a essa instância EVPN. Quando uma VM muda de um data center para outro, procedimentos EVPN normais resultam na divulgação do endereço MAC e IP do novo roteador PE que o VM reside atrás. A rota de host instalada no VRF associada a uma EVPN solicita tráfego de Camada 3 destinado a essa VM para o novo roteador PE e evita o roteamento intrinquente entre a fonte, o antigo roteador PE que a VM estava atrás e o novo roteador PE.
A escalabilidade do BGP é uma preocupação potencial com a solução de prevenção de roteamento de triângulos entre data centers devido ao potencial de injeção de muitas rotas de host na VPN de Camada 3. Com o método descrito anteriormente, na pior das hipóteses existe uma rota de host IP para cada endereço MAC aprendido através dos procedimentos locais de aprendizado EVPN MAC ou através de uma mensagem de anúncio MAC recebida de um roteador PE remoto. A filtragem de alvo de roteamento BGP pode ser usada para limitar a distribuição dessas rotas.
Os seguintes elementos funcionais são necessários para implementar a prevenção do roteamento intrinca entre data centers usando procedimentos de encaminhamento inter-subnet de Camada 3:
O host de origem envia um pacote IP usando seu próprio endereço MAC e IP de origem com o MAC de destino da interface IRB do roteador PE local e o endereço IP do host de destino.
Quando a interface IRB recebe o quadro com seu MAC como destino, ele executa uma busca de Camada 3 no VRF associado à instância EVPN para determinar onde rotear o pacote.
No VRF, o roteador PE encontra a rota de Camada 3 derivada de um MAC mais uma rota IP EVPN recebida do roteador PE remoto mais cedo. O endereço MAC de destino é então alterado para o endereço MAC de destino correspondente ao IP de destino.
O pacote é então encaminhado ao roteador PE remoto que atende ao host de destino usando MPLS, usando o rótulo correspondente à instância EVPN da qual o host de destino é um membro.
O roteador PE de saída que recebe o pacote realiza uma busca de Camada 2 para o MAC do host de destino e envia o pacote para o host de destino na sub-rede conectada pela interface IRB do roteador PE de saída.
Como o roteador PE de entrada está realizando o roteamento de Camada 3, o IP TTL está decremente.
Veja também
Exemplo: configurar eVPN-MPLS com solução IRB
Este exemplo mostra como configurar uma solução integrada de roteamento e ponte (IRB) em uma implantação de VPN Ethernet (EVPN).
Requisitos
Este exemplo usa os seguintes componentes de hardware e software:
-
Duas plataformas de roteamento da Série MX como roteadores PE.
-
Dois roteadores de borda do cliente (CE), cada um conectado aos roteadores PE.
-
Junos OS Release 14.1 ou posterior em todos os roteadores PE.
-
Atualizado e validado novamente usando o Junos OS Release 22.1R1.
-
Antes de começar:
-
Configure as interfaces do roteador.
-
Configure o OSPF ou qualquer outro protocolo IGP.
-
Configure BGP.
-
Configure RSVP ou LDP.
-
Configure MPLS.
Visão geral
Em uma solução EVPN, vários domínios de ponte podem ser definidos em uma instância EVPN específica, e uma ou mais instâncias de EVPN podem ser associadas a uma única VPN VRF de Camada 3. Em geral, cada locatário de data center recebe um encaminhamento exclusivo de rota virtual VPN de Camada 3 (VRF), embora o locatário possa ser composto por uma ou mais instâncias de EVPN ou domínios de ponte por instância EVPN.
Para dar suporte a esse fator de flexibilidade e escalabilidade, a solução EVPN oferece suporte para as interfaces IRB em roteadores da Série MX que contêm FPCs MPC para facilitar o encaminhamento ideal de Camada 2 e Camada 3, juntamente com a mobilidade de máquina virtual. As interfaces IRB estão configuradas em cada domínio de ponte configurado, incluindo o domínio de ponte padrão para uma instância EVPN.
A IRB é a capacidade de fazer comutação de Camada 2 e roteamento de Camada 3 em um único nó, evitando assim saltos extras para tráfego inter-subnet. A solução EVPN IRB elimina o problema padrão do gateway usando o gateway MAC e a sincronização IP, e evita o problema de roteamento intrinquente com a intertrabalhamento da Camada 3, criando rotas de host IP para máquinas virtuais (VMs) nos VRFs de locatários.
Topologia
A Figura 2 ilustra uma topologia EVPN simples com solução IRB. Os roteadores PE1 e PE2 são os roteadores de borda do provedor que se conectam a dois roteadores de borda do cliente (CE) cada – CE1 e CE2.

Configuração
Procedimento
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.
CE1
set interfaces ge-0/0/0 vlan-tagging set interfaces ge-0/0/0 unit 0 vlan-id 10 set interfaces ge-0/0/0 unit 0 family inet address 172.16.11.1/24 set routing-options static route 172.16.22.0/24 next-hop 172.16.11.254
PE1
set interfaces ge-0/0/0 unit 0 family inet address 10.1.0.1/24 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/2 flexible-vlan-tagging set interfaces ge-0/0/2 encapsulation flexible-ethernet-services set interfaces ge-0/0/2 unit 0 encapsulation vlan-bridge set interfaces ge-0/0/2 unit 0 vlan-id 10 set interfaces irb unit 0 family inet address 172.16.11.254/24 set interfaces lo0 unit 0 family inet address 10.1.255.1/32 set routing-instances evpna instance-type evpn set routing-instances evpna protocols evpn interface ge-0/0/2.0 set routing-instances evpna vlan-id 10 set routing-instances evpna routing-interface irb.0 set routing-instances evpna interface ge-0/0/2.0 set routing-instances evpna route-distinguisher 10.1.255.1:1 set routing-instances evpna vrf-target target:65000:1 set routing-instances vrf instance-type vrf set routing-instances vrf interface irb.0 set routing-instances vrf route-distinguisher 10.1.255.1:10 set routing-instances vrf vrf-target target:65000:10 set routing-instances vrf vrf-table-label set routing-options router-id 10.1.255.1 set routing-options autonomous-system 65000 set routing-options forwarding-table chained-composite-next-hop ingress evpn set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 10.1.255.1 set protocols bgp group ibgp family inet-vpn unicast set protocols bgp group ibgp family evpn signaling set protocols bgp group ibgp neighbor 10.1.255.2 set protocols mpls label-switched-path PE1-to-PE2 from 10.1.255.1 set protocols mpls label-switched-path PE1-to-PE2 to 10.1.255.2 set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface fxp0.0 disable set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable
PE2
set interfaces ge-0/0/0 unit 0 family inet address 10.1.0.2/24 set interfaces ge-0/0/0 unit 0 family mpls set interfaces ge-0/0/1 flexible-vlan-tagging set interfaces ge-0/0/1 encapsulation flexible-ethernet-services set interfaces ge-0/0/1 unit 0 encapsulation vlan-bridge set interfaces ge-0/0/1 unit 0 vlan-id 20 set interfaces irb unit 0 family inet address 172.16.22.254/24 set interfaces lo0 unit 0 family inet address 10.1.255.2/32 set routing-instances evpna instance-type evpn set routing-instances evpna protocols evpn interface ge-0/0/1.0 set routing-instances evpna vlan-id 20 set routing-instances evpna routing-interface irb.0 set routing-instances evpna interface ge-0/0/1.0 set routing-instances evpna route-distinguisher 10.1.255.2:1 set routing-instances evpna vrf-target target:65000:1 set routing-instances vrf instance-type vrf set routing-instances vrf interface irb.0 set routing-instances vrf route-distinguisher 10.1.255.2:10 set routing-instances vrf vrf-target target:65000:10 set routing-instances vrf vrf-table-label set routing-options router-id 10.1.255.2 set routing-options autonomous-system 65000 set routing-options forwarding-table chained-composite-next-hop ingress evpn set protocols bgp group ibgp type internal set protocols bgp group ibgp local-address 10.1.255.2 set protocols bgp group ibgp family inet-vpn unicast set protocols bgp group ibgp family evpn signaling set protocols bgp group ibgp neighbor 10.1.255.1 set protocols mpls label-switched-path PE2-to-PE1 from 10.1.255.2 set protocols mpls label-switched-path PE2-to-PE1 to 10.1.255.1 set protocols mpls interface all set protocols mpls interface fxp0.0 disable set protocols ospf traffic-engineering set protocols ospf area 0.0.0.0 interface all set protocols ospf area 0.0.0.0 interface fxp0.0 disable set protocols rsvp interface all set protocols rsvp interface fxp0.0 disable
CE2
set interfaces ge-0/0/1 vlan-tagging set interfaces ge-0/0/1 unit 0 vlan-id 20 set interfaces ge-0/0/1 unit 0 family inet address 172.16.22.1/24 set routing-options static route 172.16.11.0/24 next-hop 172.16.22.254
Procedimento passo a passo
O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar na CLI, consulte Use o CLI Editor no modo de configuração.
Para configurar o PE1:
Repita este procedimento para PE2, depois de modificar os nomes, endereços e outros parâmetros de interface apropriados.
-
Configure as interfaces no PE1.
user@PE1# set interfaces ge-0/0/0 unit 0 family inet address 10.1.0.1/24 user@PE1# set interfaces ge-0/0/0 unit 0 family mpls user@PE1# set interfaces ge-0/0/2 flexible-vlan-tagging user@PE1# set interfaces ge-0/0/2 encapsulation flexible-ethernet-services user@PE1# set interfaces ge-0/0/2 unit 0 encapsulation vlan-bridge user@PE1# set interfaces ge-0/0/2 unit 0 vlan-id 10 user@PE1# set interfaces irb unit 0 family inet address 172.16.11.254/24 user@PE1# set interfaces lo0 unit 0 family inet address 10.1.255.1/32
-
Defina o ID do roteador e o número do sistema autônomo para PE1.
user@PE1# set routing-options router-id 10.1.255.1 user@PE1# set routing-options autonomous-system 65000
-
Configure o próximo hop composto em cadeia para EVPN.
user@PE1# set routing-options forwarding-table chained-composite-next-hop ingress evpn
-
Habilite o RSVP em todas as interfaces do PE1, excluindo a interface de gerenciamento.
user@PE1# set protocols rsvp interface all user@PE1# set protocols rsvp interface fxp0.0 disable
-
Habilite o MPLS em todas as interfaces do PE1, excluindo a interface de gerenciamento. Crie um caminho comutador de rótulos de PE1 para PE2.
user@PE1# set protocols mpls label-switched-path PE1-to-PE2 from 10.1.255.1 user@PE1# set protocols mpls label-switched-path PE1-to-PE2 to 10.1.255.2 user@PE1# set protocols mpls interface all user@PE1# set protocols mpls interface fxp0.0 disable
-
Configure o grupo BGP para IBGP no PE1. Atribua endereços locais e vizinhos para PE1 a peer com PE2 usando o endereço de loopback. Inclua a família
inet-vpn unicast
eevpn signaling
as informações de alcance da camada de rede (NLRI).user@PE1# set protocols bgp group ibgp type internal user@PE1# set protocols bgp group ibgp local-address 10.1.255.1 user@PE1# set protocols bgp group ibgp family inet-vpn unicast user@PE1# set protocols bgp group ibgp family evpn signaling user@PE1# set protocols bgp group ibgp neighbor 10.1.255.2
-
Configure o OSPF em todas as interfaces do PE1, excluindo a interface de gerenciamento. Habilite a engenharia de tráfego para OSPF. Para LSPs sinalizados por RSVP com OSPF como IGP, a engenharia de tráfego deve ser habilitada para que os LSPs adigram.
user@PE1# set protocols ospf traffic-engineering user@PE1# set protocols ospf area 0.0.0.0 interface all user@PE1# set protocols ospf area 0.0.0.0 interface fxp0.0 disable
-
Configure a instância de roteamento EVPN. Configure o identificador VLAN, a interface conectada ao CE1, a interface IRB como uma interface de roteamento, o distinguidor de rotas e o alvo VRF para a instância de roteamento evpna.
user@PE1#set routing-instances evpna instance-type evpn user@PE1#set routing-instances evpna protocols evpn interface ge-0/0/2.0 user@PE1#set routing-instances evpna vlan-id 10 user@PE1#set routing-instances evpna routing-interface irb.0 user@PE1#set routing-instances evpna interface ge-0/0/2.0 user@PE1#set routing-instances evpna route-distinguisher 10.1.255.1:1 user@PE1#set routing-instances evpna vrf-target target:65000:1
-
Configure a instância de roteamento VRF. Configure a interface IRB, o distinguidor de rotas, o alvo VRF e o rótulo de tabela VRF para a instância de roteamento vrf.
user@PE1# set routing-instances vrf instance-type vrf user@PE1# set routing-instances vrf interface irb.0 user@PE1# set routing-instances vrf route-distinguisher 10.1.255.1:10 user@PE1# set routing-instances vrf vrf-target target:65000:10 user@PE1# set routing-instances vrf vrf-table-label
Resultados
A partir do modo de configuração, confirme sua configuração entrando nosshow interfaces
, show routing-options
show protocols
e show routing-instances
comandos. Se a saída não exibir a configuração pretendida, repita as instruções neste exemplo para corrigir a configuração.
user@PE1# show interfaces
ge-0/0/0 {
unit 0 {
family inet {
address 10.1.0.1/24;
}
family mpls;
}
}
ge-0/0/2 {
flexible-vlan-tagging;
encapsulation flexible-ethernet-services;
unit 0 {
encapsulation vlan-bridge;
vlan-id 10;
}
}
irb {
unit 0 {
family inet {
address 172.16.11.254/24;
}
}
}
lo0 {
unit 0 {
family inet {
address 10.1.255.1/32;
}
}
}
user@PE1# show routing-options
router-id 10.1.255.1;
autonomous-system 65000;
forwarding-table {
chained-composite-next-hop {
ingress {
evpn;
}
}
}
user@PE1# show protocols
bgp {
group ibgp {
type internal;
local-address 10.1.255.1;
family inet-vpn {
unicast;
}
family evpn {
signaling;
}
neighbor 10.1.255.2;
}
}
mpls {
label-switched-path PE1-to-PE2 {
from 10.1.255.1;
to 10.1.255.2;
}
interface all;
interface fxp0.0 {
disable;
}
}
ospf {
traffic-engineering;
area 0.0.0.0 {
interface all;
interface fxp0.0 {
disable;
}
}
}
rsvp {
interface all;
interface fxp0.0 {
disable;
}
}
user@PE1# show routing-instances
evpna {
instance-type evpn;
protocols {
evpn {
interface ge-0/0/2.0;
}
}
vlan-id 10;
routing-interface irb.0;
interface ge-0/0/2.0;
route-distinguisher 10.1.255.1:1;
vrf-target target:65000:1;
}
vrf {
instance-type vrf;
interface irb.0;
route-distinguisher 10.1.255.1:10;
vrf-target target:65000:10;
vrf-table-label;
}
Verificação
Confirme que a configuração está funcionando corretamente.
- Verificando MACs locais de IRB
- Verificação de MACs remotos de IRB
- Verificação de IPs locais de IRB
- Verificação de IPs remotos de IRB
- Verificando a alcance do CE-CE
- Verificando a alcance do CE-PE
- Verificando a alcance do PE-PE
Verificando MACs locais de IRB
Propósito
Verifique se os MACs IRB locais são aprendidos com L2ALD.
Ação
No PE1, determine o endereço MAC da interface IRB local.
Do modo operacional, execute o show interfaces irb extensive | match "Current address"
comando.
user@PE1> show interfaces irb extensive | match "Current address" Current address: 2c:6b:f5:1b:46:f0, Hardware address: 2c:6b:f5:1b:46:f0
Do modo operacional, execute o show route table evpna.evpn.0 extensive | find 2c:6b:f5:1b:46:f0
comando.
user@PE1> show route table evpna.evpn.0 extensive | find 2c:6b:f5:1b:46:f0 2:10.1.255.1:1::10::2c:6b:f5:1b:46:f0/304 MAC/IP (1 entry, 1 announced) *EVPN Preference: 170 Next hop type: Indirect, Next hop index: 0 Address: 0x7a18b78 Next-hop reference count: 12, key opaque handle: 0x0 Protocol next hop: 10.1.255.1 Indirect next hop: 0x0 - INH Session ID: 0 State: <Active Int Ext> Age: 1:34:57 Validation State: unverified Task: evpna-evpn Announcement bits (1): 2-rt-export AS path: I Communities: evpn-default-gateway Route Label: 299936 ESI: 00:00:00:00:00:00:00:00:00:00 Thread: junos-main
Significado
A rota para a interface IRB local aparece na tabela de rotas de instâncias EVPN no PE1 e é aprendida com a EVPN e marcada com a comunidade estendida de gateway padrão.
Verificação de MACs remotos de IRB
Propósito
Verifique se os MACs IRB remotos são aprendidos com o BGP.
Ação
No PE2, verifique se o IRB MAC remoto do PE1 é aprendido.
Do modo operacional, execute o mesmo show route table evpna.evpn.0 extensive | find 2c:6b:f5:1b:46:f0
comando executado no PE1.
user@PE2> show route table evpna.evpn.0 extensive | find 2c:6b:f5:1b:46:f0 2:10.1.255.1:1::10::2c:6b:f5:1b:46:f0/304 MAC/IP (1 entry, 1 announced) *BGP Preference: 170/-101 Route Distinguisher: 10.1.255.1:1 Next hop type: Indirect, Next hop index: 0 Address: 0x7a19160 Next-hop reference count: 10, key opaque handle: 0x0 Source: 10.1.255.1 Protocol next hop: 10.1.255.1 Indirect next hop: 0x2 no-forward INH Session ID: 0 State: <Secondary Active Int Ext> Local AS: 65000 Peer AS: 65000 Age: 1:41:11 Metric2: 1 Validation State: unverified Task: BGP_65000.10.1.255.1 Announcement bits (1): 0-evpna-evpn AS path: I Communities: target:65000:1 evpn-default-gateway Import Accepted Route Label: 299936 ESI: 00:00:00:00:00:00:00:00:00:00 Localpref: 100 Router ID: 10.1.255.1 Primary Routing Table: bgp.evpn.0 Thread: junos-main Indirect next hops: 1 Protocol next hop: 10.1.255.1 Metric: 1 Indirect next hop: 0x2 no-forward INH Session ID: 0 Indirect path forwarding next hops: 1 Next hop type: Router Next hop: 10.1.0.1 via ge-0/0/0.0 Session Id: 0 10.1.255.1/32 Originating RIB: inet.3 Metric: 1 Node path count: 1 Forwarding nexthops: 1 Next hop type: Router Next hop: 10.1.0.1 via ge-0/0/0.0 Session Id: 0
Significado
A rota para a interface IRB remota aparece na tabela de rotas de instâncias EVPN no PE2. A rota é aprendida com o BGP e marcada com a comunidade estendida de gateway padrão.
Verificação de IPs locais de IRB
Propósito
Verifique se os IPs IRB locais são aprendidos localmente pelo RPD.
Ação
No PE1, determine os endereços MAC e IP da interface IRB local.
Do modo operacional, execute o show interfaces irb extensive | match "Current address"
comando.
user@PE1> show interfaces irb extensive | match "Current address" Current address: 2c:6b:f5:1b:46:f0, Hardware address: 2c:6b:f5:1b:46:f0
Do modo operacional, execute o show interfaces irb.0 terse | match inet
comando.
user@PE1> show interfaces irb.0 terse | match inet irb.0 up up inet 172.16.11.254/24
Do modo operacional, execute o show route table evpna.evpn.0 extensive | find "a8:d0:e5:54:0d:10::10.0.0.251"
comando.
user@PE1> show route table evpna.evpn.0 extensive | find 2c:6b:f5:1b:46:f0::172.16.11.254 2:10.1.255.1:1::10::2c:6b:f5:1b:46:f0::172.16.11.254/304 MAC/IP (1 entry, 1 announced) *EVPN Preference: 170 Next hop type: Indirect, Next hop index: 0 Address: 0x7a18b78 Next-hop reference count: 12, key opaque handle: 0x0 Protocol next hop: 10.1.255.1 Indirect next hop: 0x0 - INH Session ID: 0 State: <Active Int Ext> Age: 2:12:19 Validation State: unverified Task: evpna-evpn Announcement bits (1): 2-rt-export AS path: I Communities: evpn-default-gateway Route Label: 299936 ESI: 00:00:00:00:00:00:00:00:00:00 Thread: junos-main
Significado
A rota MAC mais IP para a interface IRB local aparece na tabela de rotas de instâncias EVPN no PE1 e é aprendida com a EVPN e marcada com a comunidade estendida de gateway padrão.
Verificação de IPs remotos de IRB
Propósito
Verifique se o IP IRB remoto é aprendido com o BGP.
Ação
No Roteador PE2, verifique se o IRB MAC remoto do PE1 é aprendido.
Do modo operacional, execute o mesmo show route table evpna.evpn.0 extensive | find 2c:6b:f5:1b:46:f0::172.16.11.254
comando executado no PE1.
user@PE2> show route table evpna.evpn.0 extensive | find 2c:6b:f5:1b:46:f0::172.16.11.254 2:10.1.255.1:1::10::2c:6b:f5:1b:46:f0::172.16.11.254/304 MAC/IP (1 entry, 1 announced) *BGP Preference: 170/-101 Route Distinguisher: 10.1.255.1:1 Next hop type: Indirect, Next hop index: 0 Address: 0x7a19160 Next-hop reference count: 10, key opaque handle: 0x0 Source: 10.1.255.1 Protocol next hop: 10.1.255.1 Indirect next hop: 0x2 no-forward INH Session ID: 0 State: <Secondary Active Int Ext> Local AS: 65000 Peer AS: 65000 Age: 2:13:11 Metric2: 1 Validation State: unverified Task: BGP_65000.10.1.255.1 Announcement bits (1): 0-evpna-evpn AS path: I Communities: target:65000:1 evpn-default-gateway Import Accepted Route Label: 299936 ESI: 00:00:00:00:00:00:00:00:00:00 Localpref: 100 Router ID: 10.1.255.1 Primary Routing Table: bgp.evpn.0 Thread: junos-main Indirect next hops: 1 Protocol next hop: 10.1.255.1 Metric: 1 Indirect next hop: 0x2 no-forward INH Session ID: 0 Indirect path forwarding next hops: 1 Next hop type: Router Next hop: 10.1.0.1 via ge-0/0/0.0 Session Id: 0 10.1.255.1/32 Originating RIB: inet.3 Metric: 1 Node path count: 1 Forwarding nexthops: 1 Next hop type: Router Next hop: 10.1.0.1 via ge-0/0/0.0 Session Id: 0
Significado
A rota MAC mais IP para a interface IRB remota aparece na tabela de rotas de instâncias EVPN no PE2 e é marcada com a comunidade estendida de gateway padrão.
Verificando a alcance do CE-CE
Propósito
Verifique se o CE1 pode ping CE2.
Ação
Do modo operacional, execute o show route 172.16.22.1
comando no CE1 até o ping CE2.
user@CE1> show route 172.16.22.1 inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.16.22.0/24 *[Static/5] 02:28:23 > to 172.16.11.254 via ge-0/0/0.0
Do modo operacional, execute o ping
comando no CE1 até o ping CE2.
user@CE1> ping 172.16.22.1 count 2 PING 172.16.22.1 (172.16.22.1): 56 data bytes 64 bytes from 172.16.22.1: icmp_seq=0 ttl=62 time=4.890 ms 64 bytes from 172.16.22.1: icmp_seq=1 ttl=62 time=4.658 ms --- 172.16.22.1 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 4.658/4.774/4.890/0.116 ms
Significado
O ping de CE1 para CE2 é bem-sucedido.
Verificando a alcance do CE-PE
Propósito
Verifique se o CE1 pode ping PE2.
Ação
Do modo operacional, execute o show route table vrf.inet.0
comando no PE2.
user@PE2> show route table vrf.inet.0 vrf.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.16.11.0/24 *[BGP/170] 02:27:44, localpref 100, from 10.1.255.1 AS path: I, validation-state: unverified > to 10.1.0.1 via ge-0/0/0.0, label-switched-path PE2-to-PE1 172.16.11.1/32 *[BGP/170] 02:27:44, localpref 100, from 10.1.255.1 AS path: I, validation-state: unverified > to 10.1.0.1 via ge-0/0/0.0, label-switched-path PE2-to-PE1 172.16.22.0/24 *[Direct/0] 02:28:14 > via irb.0 172.16.22.1/32 *[EVPN/7] 02:24:44 > via irb.0 172.16.22.254/32 *[Local/0] 02:28:14 Local via irb.0
Do modo operacional, execute o ping
comando no CE1 até ping da interface IRB no PE2.
user@CE1> ping 172.16.22.254 count 2 PING 172.16.22.254 (172.16.22.254): 56 data bytes 64 bytes from 172.16.22.254: icmp_seq=0 ttl=63 time=3.662 ms 64 bytes from 172.16.22.254: icmp_seq=1 ttl=63 time=2.766 ms --- 172.16.22.254 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 2.766/3.214/3.662/0.448 ms
Significado
O ping de CE1 para PE2 é bem-sucedido.
Verificando a alcance do PE-PE
Propósito
Verifique se o PE1 pode ping PE2.
Ação
Do modo operacional, execute o show route table vrf.inet.0
comando no PE1.
user@PE1> show route table vrf.inet.0 vrf.inet.0: 5 destinations, 5 routes (5 active, 0 holddown, 0 hidden) + = Active Route, - = Last Active, * = Both 172.16.11.0/24 *[Direct/0] 02:40:42 > via irb.0 172.16.11.1/32 *[EVPN/7] 02:37:42 > via irb.0 172.16.11.254/32 *[Local/0] 02:40:42 Local via irb.0 172.16.22.0/24 *[BGP/170] 02:35:48, localpref 100, from 10.1.255.2 AS path: I, validation-state: unverified > to 10.1.0.2 via ge-0/0/0.0, label-switched-path PE1-to-PE2 172.16.22.1/32 *[BGP/170] 02:32:46, localpref 100, from 10.1.255.2 AS path: I, validation-state: unverified > to 10.1.0.2 via ge-0/0/0.0, label-switched-path PE1-to-PE2
Desde o modo operacional, execute o ping
comando do PE1 até a interface IRB no PE2.
user@PE1> ping 172.16.22.254 routing-instance vrf count 2 PING 172.16.22.254 (172.16.22.254): 56 data bytes 64 bytes from 172.16.22.254: icmp_seq=0 ttl=64 time=1.946 ms 64 bytes from 172.16.22.254: icmp_seq=1 ttl=64 time=2.151 ms --- 172.16.22.254 ping statistics --- 2 packets transmitted, 2 packets received, 0% packet loss round-trip min/avg/max/stddev = 1.946/2.048/2.151/0.102 ms
Significado
O ping de PE1 para PE2 é bem-sucedido.