Ejemplo: Configuración de EVPN con la solución IRB
Descripción general de la solución EVPN con IRB
Un proveedor de servicios de centro de datos (DCSP) aloja el centro de datos para sus múltiples clientes en una red física común. Para cada cliente (también llamado inquilino), el servicio se ve como un centro de datos completo que puede expandirse a 4094 VLAN y todas las subredes privadas. Para la recuperación ante desastres, la alta disponibilidad y la optimización de la utilización de recursos, es común que el DCSP se expanda a través del centro de datos a más de un sitio. Para implementar los servicios del centro de datos, un DCSP se enfrenta a los siguientes desafíos principales:
Extensión de dominios de capa 2 en más de un sitio de centro de datos. Esto requiere un reenvío óptimo de tráfico dentro de la subred.
Admite un reenvío óptimo de tráfico entre subredes y un enrutamiento óptimos en el caso de una máquina virtual (VM).
Admite varios inquilinos con VLAN y espacio de subred independientes.
La VPN Ethernet (EVPN) está dirigida a manejar todos los desafíos mencionados anteriormente, en los que:
La funcionalidad básica de EVPN permite un reenvío óptimo de tráfico dentro de la subred
La implementación de la solución de enrutamiento y puente integrados (IRB) en una implementación de EVPN permite un reenvío óptimo de tráfico entre subredes
La configuración de EVPN con compatibilidad con conmutador virtual permite que varios inquilinos con VLAN y espacio de subred independientes
Las siguientes secciones describen la solución IRB para EVPN:
- Necesidad de una solución IRB de EVPN
- Implementación de la solución IRB de EVPN
- Beneficios de la implementación de la solución IRB de EVPN
Necesidad de una solución IRB de EVPN
EVPN es una tecnología utilizada para proporcionar extensión e interconexión de capa 2 a través de una red central IP/MPLS a diferentes sitios físicos que pertenecen a un solo dominio de capa 2. En un entorno de centro de datos con EVPN, existe la necesidad de reenvío tanto de capa 2 (tráfico de intra subred) como de capa 3 (tráfico entre subredes) y potencialmente de interoperación con VPN de capa 3 de inquilino.
Con solo una solución de capa 2, no hay un reenvío óptimo del tráfico entre subredes, incluso cuando el tráfico es local, por ejemplo, cuando ambas subredes están en el mismo servidor.
Con solo una solución de capa 3, pueden surgir los siguientes problemas para el tráfico dentro de la subred:
Problema de alias de dirección MAC en el que no se detectan direcciones MAC duplicadas.
Problema de TTL para aplicaciones que usan TTL 1 para confinar tráfico dentro de una subred.
Direccionamiento local de vínculos IPv6 y detección de direcciones duplicadas que depende de la conectividad de capa 2.
El reenvío de capa 3 no admite la semántica de reenvío de una difusión de subred.
Soporte de aplicaciones que no son IP que requieren reenvío de capa 2.
Debido a las deficiencias mencionadas anteriormente de una solución pura de capa 2 y capa 3, existe la necesidad de una solución que incorpore un reenvío óptimo del tráfico de capa 2 y capa 3 en el entorno del centro de datos cuando se enfrenta a consideraciones operativas, como la interoperabilidad de VPN de capa 3 y la movilidad de máquina virtual (VM).
Una solución de enrutamiento y puentes integrados (IRB) basada en EVPN ofrece un óptimo reenvío de unidifusión y multidifusión tanto para intra subredes como para inter subredes dentro y entre centros de datos.
La función IRB EVPN es útil para los proveedores de servicios que operan en una red IP/MPLS que proporciona servicios VPN o VPLS de capa 2 y servicios VPN de capa 3 que desean extender su servicio para ofrecer servicios de computación en la nube y de almacenamiento a sus clientes existentes.
Implementación de la solución IRB de EVPN
Una solución IRB de EVPN ofrece lo siguiente:
Reenvío óptimo para tráfico de intra subred (capa 2).
Reenvío óptimo para el tráfico entre subredes (capa 3).
Compatibilidad con replicación de entrada para tráfico de multidifusión.
Soporte para modelos superpuestos basados en red y host.
Soporte para un reenvío coherente basado en políticas para el tráfico de capa 2 y capa 3.
Compatibilidad con los siguientes protocolos de enrutamiento en la interfaz IRB:
BFD
BGP
IS-IS
OSPF y OSPF versión 3
Soporte para multiconexión único y completamente activo
Junos OS admite varios modelos de configuración de EVPN para satisfacer las necesidades individuales de los clientes de servicios de nube de centro de datos y EVPN. Para ofrecer flexibilidad y escalabilidad, se pueden definir varios dominios de puente dentro de una instancia de EVPN en particular. Del mismo modo, una o más instancias de EVPN se pueden asociar con un único enrutamiento y reenvío virtual VPN de capa 3 (VRF). En general, a cada inquilino del centro de datos se le asigna una VRF vpn de capa 3 exclusiva, mientras que un inquilino puede incluir una o más instancias de EVPN y uno o más dominios de puente por instancia de EVPN. Para admitir este modelo, cada dominio de puente configurado (incluido el dominio de puente predeterminado para una instancia de EVPN) requiere una interfaz IRB para realizar las funciones de capa 2 y capa 3. Cada interfaz IRB o dominio de puente se asigna a una subred IP única en el VRF.
Puede asociar una interfaz IRB con la tabla inet.0 de la instancia principal en lugar de un VRF en una solución IRB de EVPN.
Hay dos funciones principales compatibles con IRB en EVPN.
Sincronización de MAC-IP del host
Esto incluye:
Anunciar la dirección IP junto con la ruta del anuncio MAC en EVPN. Esto se hace mediante el uso del campo IP en la ruta de anuncio mac de EVPN.
El enrutador de PE receptor instala MAC en la tabla de instancias de EVPN (EVI) e instala IP en el VRF asociado.
Sincronización de MAC-IP de puerta de enlace
Esto incluye:
Anunciar todas las direcciones MAC e IP de IRB locales en una EVPN. Esto se logra mediante la inclusión de la comunidad extendida de puerta de enlace predeterminada en la ruta publicitaria MAC de EVPN.
El PE receptor crea un estado de reenvío a enrutar paquetes destinados a la MAC de puerta de enlace, y un ARP de proxy se realiza para la IP de puerta de enlace con el MAC anunciado en la ruta.
La Figura 1 muestra el reenvío de tráfico entre dos dispositivos de borde de proveedor (PE) – PE1 y PE2. Las interfaces IRB1 e IRB2 de cada dispositivo PE pertenecen a una subred diferente, pero comparten un VRF común.

El reenvío de tráfico entre subredes se realiza de la siguiente manera:
PE2 anuncia la unión de H3-M3 y H4-M4 a PE1. Del mismo modo, PE1 anuncia la unión de H1-M1 y H2-M2 a PE2.
PE1 y PE2 instalan la dirección MAC en la tabla MAC de EVI correspondiente, mientras que las rutas IP se instalan en el VRF compartido.
El dispositivo PE publicitario se establece como el siguiente salto para las rutas IP.
Si H1 envía paquetes a H4, los paquetes se envían a IRB1 en PE1.
La búsqueda de IP para H4 ocurre en el VRF compartido en PE1. Dado que el siguiente salto para la IP H4 es PE2 (el PE publicitario), se envía un paquete de unidifusión IP a PE2.
PE1 reescribe el encabezado MAC según la información de la ruta VRF, y PE2 realiza una búsqueda MAC para reenviar el paquete a H4.
Beneficios de la implementación de la solución IRB de EVPN
El objetivo principal de la solución IRB de EVPN es proporcionar un reenvío óptimo de las capas 2 y 3. La solución es necesaria para manejar de manera eficiente el reenvío entre subredes, así como la movilidad de máquinas virtuales (VM). La movilidad de vm se refiere a la capacidad de una máquina virtual para migrar de un servidor a otro dentro del mismo centro de datos o dentro de un centro de datos diferente, a la vez que conserva su dirección MAC e IP existentes. Proporcionar un reenvío óptimo para el tráfico entre subredes y una movilidad efectiva de vm implica resolver dos problemas: el problema de la puerta de enlace predeterminada y el problema del enrutamiento triangular.
A partir de Junos OS versión 17.1R1, las direcciones IPv6 se admiten en interfaces IRB con EVPN mediante el protocolo de descubrimiento de vecinos (NDP). Se presentan las siguientes capacidades para la compatibilidad con IPv6 con EVPN:
Direcciones IPv6 en interfaces IRB en instancias de enrutamiento principal
Aprender el vecindario de IPv6 a partir del mensaje de NA solicitado
Los paquetes NS y NA en las interfaces IRB se deshabilitan desde el núcleo de la red
Las direcciones de puerta de enlace virtual se utilizan como direcciones de capa 3
Sincronización de MAC-IP de host para IPv6
Puede configurar las direcciones IPv6 en la interfaz IRB en el [edit interfaces irb]
nivel jerárquico.
Sincronización de IP y MAC de puerta de enlace
En una implementación de IRB de EVPN, la puerta de enlace IP predeterminada para una máquina virtual es la dirección IP configurada en la interfaz IRB del enrutador de borde del proveedor (PE) que corresponde al dominio de puente o VLAN del cual la máquina virtual es miembro. El problema de la puerta de enlace predeterminada surge porque una máquina virtual no vacía su tabla ARP cuando se traslada de un servidor a otro y continúa enviando paquetes con la dirección MAC de destino establecida a la de la puerta de enlace original. Si los servidores antiguos y nuevos no forman parte del mismo dominio de capa 2 (el nuevo dominio de capa 2 podría estar dentro del centro de datos actual o de un nuevo centro de datos), la puerta de enlace identificada anteriormente ya no es la puerta de enlace óptima o local. La nueva puerta de enlace debe identificar los paquetes que contienen las direcciones MAC de otras puertas de enlace en enrutadores de PE remotos y reenviar el tráfico como si los paquetes estuvieran destinados a la propia puerta de enlace local. Como mínimo, esta funcionalidad requiere que cada enrutador de PE anuncie su puerta de enlace o las direcciones MAC e IP de IRB a todos los demás enrutadores de PE de la red. El intercambio de direcciones de puerta de enlace se puede realizar mediante el mensaje de anuncio de ruta MAC estándar (incluido el parámetro de dirección IP) y etiquetar esa ruta con la comunidad extendida de puerta de enlace predeterminada para que los enrutadores de PE remotos puedan distinguir las rutas de anuncio MAC de la puerta de enlace de las rutas de anuncios de MAC normales.
Intertrabajo de VPN de capa 3
El aspecto del centro entre datos de la solución IRB EVPN implica el enrutamiento entre máquinas virtuales que están presentes en diferentes centros de datos o el enrutamiento entre un sitio host completamente fuera del entorno del centro de datos y una máquina virtual dentro de un centro de datos. Esta solución se basa en la capacidad de los anuncios de ruta MAC de EVPN para transportar información tanto de dirección MAC como de dirección IP. La funcionalidad de aprendizaje DE MAC local del enrutador de PE se extiende para capturar también información de dirección IP asociada con direcciones MAC aprendidas localmente. Esa información de asignación de direcciones IP-MAC se distribuye a cada enrutador de PE a través de procedimientos normales de EVPN. Cuando un enrutador PE recibe dicha información de MAC e IP, instala la ruta MAC en la instancia de EVPN, así como una ruta de host para la dirección IP asociada en la VRF VPN de capa 3 correspondiente a esa instancia de EVPN. Cuando una MÁQUINA virtual se mueve de un centro de datos a otro, los procedimientos normales de EVPN dan como resultado que la dirección MAC y la dirección IP se anuncien desde el nuevo enrutador de PE del que la MÁQUINA virtual reside detrás. La ruta de host instalada en el VRF asociado con un EVPN solicita tráfico de capa 3 destinado a esa MÁQUINA virtual al nuevo enrutador de PE y evita el enrutamiento triangular entre el origen, el enrutador de PE antiguo en el que residía la MÁQUINA virtual y el nuevo enrutador de PE.
La escalabilidad del BGP es una posible preocupación con la solución para evitar el enrutamiento triangular del centro de datos debido al potencial de inyección de muchas rutas de host en VPN de capa 3. Con el método descrito anteriormente, en el peor de los casos hay una ruta de host IP para cada dirección MAC aprendida a través de los procedimientos de aprendizaje de MAC de EVPN locales o a través de un mensaje de anuncio DE MAC recibido de un enrutador de PE remoto. El filtrado de destino de ruta del BGP se puede utilizar para limitar la distribución de dichas rutas.
Se requieren los siguientes elementos funcionales para implementar la evitación del enrutamiento triangular entre centros de datos mediante procedimientos de reenvío entre subredes de capa 3:
El host de origen envía un paquete IP mediante su propia MAC de origen y dirección IP con la MAC de destino de la interfaz IRB del enrutador DE PE local y la dirección IP del host de destino.
Cuando la interfaz IRB recibe la trama con su MAC como destino, realiza una búsqueda de capa 3 en el VRF asociado con la instancia de EVPN para determinar dónde enrutar el paquete.
En el VRF, el enrutador de PE encuentra la ruta de capa 3 derivada de un MAC más una ruta EVPN IP recibida del enrutador de PE remoto anteriormente. A continuación, la dirección MAC de destino se cambia a la dirección MAC de destino correspondiente a la IP de destino.
Luego, el paquete se reenvía al enrutador de PE remoto que sirve al host de destino mediante MPLS, usando la etiqueta correspondiente a la instancia de EVPN de la cual el host de destino es miembro.
El enrutador pe de salida que recibe el paquete realiza una búsqueda de capa 2 para la MAC del host de destino y envía el paquete al host de destino en la subred adjunta a través de la interfaz IRB del enrutador de PE de salida.
Dado que el enrutador de PE de entrada realiza enrutamiento de capa 3, el TTL IP se decrementa.
Ver también
Ejemplo: Configuración de EVPN-MPLS con la solución IRB
En este ejemplo, se muestra cómo configurar una solución de enrutamiento y puente integrados (IRB) en una implementación de VPN Ethernet (EVPN).
Requisitos
En este ejemplo, se utilizan los siguientes componentes de hardware y software:
-
Dos plataformas de enrutamiento de la serie MX como enrutadores pe.
-
Dos enrutadores de borde del cliente (CE), cada uno conectado a los enrutadores de PE.
-
Junos OS versión 14.1 o posterior se ejecuta en todos los enrutadores PE.
-
Actualizado y revalidado con Junos OS versión 22.1R1.
-
Antes de empezar:
-
Configure las interfaces del enrutador.
-
Configure el OSPF o cualquier otro protocolo IGP.
-
Configure BGP.
-
Configure RSVP o LDP.
-
Configure MPLS.
Visión general
En una solución de EVPN, se pueden definir varios dominios de puente dentro de una instancia de EVPN en particular, y una o más instancias de EVPN se pueden asociar con una sola VRF VPN de capa 3. En general, a cada inquilino del centro de datos se le asigna un reenvío de ruta virtual (VRF) único de VPN de capa 3, aunque el inquilino puede estar compuesto por una o más instancias de EVPN o dominios de puente por instancia de EVPN.
Para admitir este factor de flexibilidad y escalabilidad, la solución EVPN proporciona soporte para las interfaces IRB en enrutadores serie MX que contienen FPC MPC para facilitar el reenvío óptimo de las capas 2 y 3 junto con la movilidad de las máquinas virtuales. Las interfaces IRB se configuran en cada dominio de puente configurado, incluido el dominio de puente predeterminado para una instancia de EVPN.
IrB es la capacidad de hacer conmutación de capa 2 y enrutamiento de capa 3 dentro de un solo nodo, evitando así saltos adicionales para el tráfico entre subredes. La solución IRB de EVPN elimina el problema de la puerta de enlace predeterminada mediante la sincronización de IP y MAC de puerta de enlace, y evita el problema de enrutamiento triangular con la intertrabajo de capa 3 mediante la creación de rutas de host IP para máquinas virtuales (VM) en las VRF inquilinos.
Topología
La Figura 2 muestra una topología de EVPN simple con la solución IRB. Los enrutadores PE1 y PE2 son los enrutadores de borde del proveedor que se conectan a dos enrutadores de borde del cliente (CE) cada uno: CE1 y CE2.

Configuración
Procedimiento
Configuración rápida de CLI
Para configurar rápidamente este ejemplo, copie los siguientes comandos, péguelos en un archivo de texto, elimine los saltos de línea, cambie los detalles necesarios para que coincidan con su configuración de red y, luego, copie y pegue los comandos en la CLI en el [edit]
nivel de jerarquía.
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
Procedimiento paso a paso
El siguiente ejemplo requiere que navegue por varios niveles en la jerarquía de configuración. Para obtener más información acerca de cómo navegar por la CLI, consulte Uso del editor de CLI en modo de configuración.
Para configurar PE1:
Repita este procedimiento para PE2 después de modificar los nombres de interfaz, las direcciones y otros parámetros adecuados.
-
Configure las interfaces en 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
-
Establezca el ID de enrutador y el número de 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 el siguiente salto compuesto encadenado para EVPN.
user@PE1# set routing-options forwarding-table chained-composite-next-hop ingress evpn
-
Habilite RSVP en todas las interfaces de PE1, excluyendo la interfaz de administración.
user@PE1# set protocols rsvp interface all user@PE1# set protocols rsvp interface fxp0.0 disable
-
Habilite MPLS en todas las interfaces de PE1, excluyendo la interfaz de administración. Cree una ruta conmutada por etiquetas de PE1 a 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 el grupo BGP para IBGP en PE1. Asigne direcciones locales y de vecino para que PE1 se empareja con PE2 mediante la dirección de circuito cerrado. Incluya la familia
inet-vpn unicast
yevpn signaling
la información de accesibilidad de la capa de red (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 el OSPF en todas las interfaces de PE1, excluyendo la interfaz de administración. Habilite la ingeniería de tráfico para OSPF. Para los LSP señalados por RSVP con OSPF como IGP, se debe habilitar la ingeniería de tráfico para que los LSP aparezcan.
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 la instancia de enrutamiento de EVPN. Configure el identificador de VLAN, la interfaz conectada a CE1, la interfaz IRB como interfaz de enrutamiento, el distinguidor de ruta y el destino VRF para la instancia de enrutamiento 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 la instancia de enrutamiento VRF. Configure la interfaz IRB, el distinguidor de ruta, el destino VRF y la etiqueta de tabla VRF para la instancia de enrutamiento 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
Desde el modo de configuración, ingrese los comandos , show routing-options
, show protocols
y show routing-instances
para confirmar la show interfaces
configuración. Si el resultado no muestra la configuración deseada, repita las instrucciones en este ejemplo para corregir la configuración.
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;
}
Verificación
Confirme que la configuración funciona correctamente.
- Verificación de LOS MAC IRB locales
- Verificar LOS MAC de IRB remotos
- Verificación de IP IRB locales
- Verificar las IP IRB remotas
- Verificar la accesibilidad de CE-CE
- Verificar la accesibilidad del CE-PE
- Verificar la accesibilidad de PE-PE
Verificación de LOS MAC IRB locales
Propósito
Verifique que los MAC IRB locales se aprenden de L2ALD.
Acción
En PE1, determine la dirección MAC de la interfaz IRB local.
Desde el modo operativo, ejecute el 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
Desde el modo operativo, ejecute el 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
La ruta para la interfaz IRB local aparece en la tabla de ruta de instancia de EVPN en PE1 y se aprende de EVPN y se etiqueta con la comunidad extendida de puerta de enlace predeterminada.
Verificar LOS MAC de IRB remotos
Propósito
Compruebe que los MAB IRB remotos se aprenden del BGP.
Acción
En PE2, verifique que se haya aprendido el MAC IRB remoto de PE1.
Desde el modo operativo, ejecute el mismo show route table evpna.evpn.0 extensive | find 2c:6b:f5:1b:46:f0
comando que se ejecutó en 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
La ruta para la interfaz IRB remota aparece en la tabla de ruta de instancia de EVPN en PE2. La ruta se aprende del BGP y se etiqueta con la comunidad extendida de puerta de enlace predeterminada.
Verificación de IP IRB locales
Propósito
Compruebe que RPD aprende localmente las IP de IRB.
Acción
En PE1, determine las direcciones MAC e IP de la interfaz IRB local.
Desde el modo operativo, ejecute el 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
Desde el modo operativo, ejecute el 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
Desde el modo operativo, ejecute el 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
La ruta MAC más IP para la interfaz IRB local aparece en la tabla de ruta de instancia de EVPN en PE1, se aprende de EVPN y se etiqueta con la comunidad extendida de puerta de enlace predeterminada.
Verificar las IP IRB remotas
Propósito
Verifique que la IP IRB remota se haya aprendido del BGP.
Acción
En el enrutador PE2, verifique que se haya aprendido el MAC IRB remoto de PE1.
Desde el modo operativo, ejecute el mismo show route table evpna.evpn.0 extensive | find 2c:6b:f5:1b:46:f0::172.16.11.254
comando que se ejecutó en 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
La ruta MAC más IP para la interfaz IRB remota aparece en la tabla de ruta de instancia de EVPN en PE2 y está etiquetada con la comunidad extendida de puerta de enlace predeterminada.
Verificar la accesibilidad de CE-CE
Propósito
Verifique que CE1 pueda hacer ping a CE2.
Acción
Desde el modo operativo, ejecute el show route 172.16.22.1
comando en CE1 para hacer ping a 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
Desde el modo operativo, ejecute el ping
comando en CE1 para hacer ping a 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
El ping de CE1 a CE2 es exitoso.
Verificar la accesibilidad del CE-PE
Propósito
Verifique que CE1 pueda hacer ping a PE2.
Acción
Desde el modo operativo, ejecute el show route table vrf.inet.0
comando en 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
Desde el modo operativo, ejecute el ping
comando en CE1 para hacer ping a la interfaz IRB en 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
El ping de CE1 a PE2 es exitoso.
Verificar la accesibilidad de PE-PE
Propósito
Verificar que PE1 pueda hacer ping a PE2.
Acción
Desde el modo operativo, ejecute el show route table vrf.inet.0
comando en 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 el modo operativo, ejecute el ping
comando desde PE1 para hacer ping a la interfaz IRB en 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
El ping de PE1 a PE2 se realiza correctamente.