Apéndice B: Implementación de la superposición IPv4 sobre la estructura subyacente IPv4
En esta sección, se describen los componentes de configuración para una implementación subyacente IPv4 y una superposición IPv4.
Implementación del plano de control con base IPv4 y superposición IPv4
Este modelo proporciona una base de transporte IPv4 y un transporte EVPN/VXLAN IPv4 en la superposición que puede admitir dispositivos solo IPv4 que se comunican a través de la estructura. Este modelo se alinea con los diseños tradicionales de estructura IP, donde el direccionamiento de la interfaz está totalmente controlado y visible, las relaciones de vecino están definidas explícitamente y son compatibles con dispositivos finales solo IPv4.
Las interfaces entre los nodos leaf y nodos spine se configuran con direcciones IPv4 /31 explícitas asignadas desde un conjunto de direcciones IPv4 reservadas para la capa subyacente. Cada dispositivo en el vínculo punto a punto está configurado con una de las dos direcciones IPv4 utilizables en la subred /31 correspondiente. Esto permite asignaciones de direcciones eficientes para los vínculos punto a punto entre los nodos leaf y nodos spine. Todos los nodos leaf y nodos spine también están configurados con direcciones IPv4 en la interfaz de circuito cerrado (lo0.0).
Las sesiones de EBGP subyacentes se configuran entre los nodos leaf y nodos spine, mediante la configuración explícita de cada vecino, utilizando las direcciones /31 IPv4 asignadas entre ellos.
La configuración del EBGP para este modelo incluye la dirección IPv4 y el número de sistema autónomo (AS) de cada vecino, el número de sistema autónomo (AS) local y la política de exportación que permite anunciar rutas para llegar a todos los nodos spine y leaf de la estructura. Estas rutas son estándar de unidifusión IPv4 que anuncian las direcciones IPv4 asignadas a la interfaz de circuito cerrado (lo0.0).
Las sesiones de EBGP superpuestas también se configuran mediante la configuración explícita de cada vecino mediante las direcciones IPv4 de las interfaces de circuito cerrado anunciadas por las sesiones de EBGP subyacentes, y también se establecen entre los nodos leaf y nodos spine.
Los nodos leaf actúan como VTEP y anuncian los prefijos IPv4 asignados a los vínculos entre los servidores de GPU y los nodos leaf mediante rutas EVPN tipo 5.
Ejemplo:
Considere el ejemplo representado en la Figura 55.
Para la capa subyacente, STRIPE1 LEAF 1 en AS 201 establece una sesión de EBGP con SPINE 1 en AS 101, a través del vínculo IPv4 conectado directamente 10.2.1.2/31 <=> 10.2.1.1/31. De manera similar, STRIPE2 LEAF 1 en AS 209 establece una sesión de EBGP con SPINE 1 a través del vínculo 10.2.9.2/31 <=> 10.2.9.1/31.
Figura 55: Ejemplo de superposición IPv4 subyacente e IPv4
Estas sesiones intercambian rutas de unidifusión IPv4 que anuncian la dirección de la interfaz circuito cerrado (lo0.0) de STRIPE1 LEAF 1 (10.0.1.1), STRIPE2 LEAF 1 (10.0.1.9) y SPINE 1 (10.0.0.1).
Aunque no se muestra en el diagrama, STRIPE1 LEAF 1 y STRIPE2 LEAF 1 también establecerán sesiones de EBGP con SPINE 2, SPINE 3 y SPINE 4 para garantizar que haya varias rutas disponibles para el tráfico.
Las sesiones de EBGP se establecen entre los nodos leaf y SPINE 1 mediante sus direcciones de circuito cerrado (10.0.1.1, 10.0.1.9 y 10.0.0.1, respectivamente).
Los nodos leaf que actúan como VTEP anuncian los vínculos que conectan los servidores de GPU y los nodos leaf como rutas /31 EVPN tipo 5.
Por ejemplo, STRIPE1 LEAF 1 anuncia rutas a las direcciones IPv4 en los vínculos que conectan el SERVIDOR 1 GPU1 y el SERVIDOR 2 GPU1 a STRIPE1 LEAF 1 (10.1.1.0/31 y 10.1.1.16/31 respectivamente). Del mismo modo, STRIPE2 LEAF 1 anuncia enrutador a las direcciones IPv4 en los enlaces que conectan el SERVER 3 GPU1 y el SERVER 4 GPU1 (10.1.1.32/31 y 10.1.1.40/31 respectivamente).
Suponiendo que las cuatro GPU del ejemplo pertenecen al mismo inquilino, sus interfaces asociadas se asignan al mismo VRF, RT5-IP-VRF_TENANT-1.
RT5-IP-VRF_TENANT-1 está configurado en STRIPE1 LEAF 1 y STRIPE2 LEAF 1 con el mismo identificador de red VXLAN (VNI) y destinos de ruta. STRIPE1 LEAF 1 anuncia los prefijos 10.1.1.0/31 y 10.1.1.16/31 a SPINE 1 como tipo de ruta EVPN 5, con su propio circuito cerrado (10.0.1.1) como el VTEP de salto siguiente. STRIPE2 LEAF 1 anuncia 10.1.1.32/31 y 10.1.1.40/31 con 10.0.1.9 como el siguiente salto.
Cuando SERVER 1 GPU1 envía tráfico a SERVER 3 GPU1, las direcciones de destino 10.1.1.32, por ejemplo, se encuentran en la tabla de enrutamiento VRF en STRIPE1 LEAF 1 (Tenant-1.inet.0). La ruta apunta a STRIPE2 LEAF 1 (VTEP en 10.0.1.9) como el siguiente salto de protocolo (que se resuelve en las direcciones del nodos spine). La ruta también especifica VNI 1 como ID de encapsulación de VXLAN. El paquete se encapsula con el encabezado VXLAN y se tuneliza a través de la estructura hasta su destino.
Nodos spine a conexiones leaf
Las interfaces entre los nodos spine y leaf no requieren direcciones IP configuradas explícitamente y se configuran como interfaces sin etiqueta con solo family inet e family inet6 para habilitar el procesamiento del tráfico IPv4 e IPv6, como se muestra en la Figura 56.
Figura 56: Ejemplo de configuración de superposición IPv4 subyacente e IPv4
Las interfaces entre los nodos leaf y nodos spine se configuran con direcciones /31, tal y como se muestra en la tabla 58.
Tabla 58. Asignaciones de direcciones IPv4 para interfaces de leaf a spine (/31 subredes)
| INTERFAZ DE NODO LEAF | DIRECCIÓN IPv4 DEL nodo LEAF | INTERFAZ DE NODO SPINE | DIRECCIÓN IPv4 SPINE |
|---|---|---|---|
| Raya 1 Hoja 1 - et-0/0/30:0 | 10.0.2.65/31 | Columna vertebral 1 – et-0/0/0:0 | 10.0.2.64/31 |
| Raya 1 Hoja 1 - et-0/0/31:0 | 10.0.2.83/31 | Spine 2 – et-0/0/1:0 | 10.0.2.82/31 |
| Raya 1 Hoja 1 - et-0/0/32:0 | 10.0.2.99/31 | Spine 3 – et-0/0/2:0 | 10.0.2.98/31 |
| Raya 1 Hoja 1 - et-0/0/33:0 | 10.0.2.115/31 | Espina 4 – et-0/0/3:0 | 10.0.2.114/31 |
| Raya 1 Hoja 5 - et-0/0/30:0 | 10.0.2.69/31 | Columna vertebral 1 – et-0/0/0:0 | 10.0.2.68/31 |
| Raya 1 Hoja 2 - et-0/0/31:0 | 10.0.2.85/31 | Spine 2 – et-0/0/1:0 | 10.0.2.84/31 |
| Raya 1 Hoja 2 - et-0/0/32:0 | 10.0.2.101/31 | Spine 3 – et-0/0/2:0 | 10.0.2.100/31 |
| Raya 1 Hoja 2 - et-0/0/33:0 | 10.0.2.119/31 | Espina 4 – et-0/0/3:0 | 10.0.2.118/31 |
| . . . |
|||
Estas interfaces se configuran como interfaces sin etiqueta, con inet de familia y direcciones IPv4 estáticas, como se muestra en el ejemplo del vínculo entre la hoja 1 de la franja 1 y la spine 1 a continuación:
Tabla 59. Ejemplo de configuración de Junos para interfaz IPv4 leaf-spine
Los números de circuito cerrado y de sistema autónomo de todos los dispositivos de la estructura se incluyen en la tabla 60:
Tabla 60. Direcciones IPv4 de circuito cerrado y números de sistema autónomo para dispositivos de estructura
| INTERFAZ DE NODO LEAF | DIRECCIÓN IPv4 lo0.0 | Local AS # |
|---|---|---|
| Raya 1 Hoja 1 | 10.0.1.1/32 | 201 |
| Raya 1 Hoja 2 | 10.0.1.2/32 | 202 |
| Raya 1 Hoja 3 | 10.0.1.3/32 | 203 |
| Raya 1 Hoja 4 | 10.0.1.4/32 | 204 |
| Raya 1 Hoja 5 | 10.0.1.5/32 | 205 |
| Raya 1 Hoja 6 | 10.0.1.6/32 | 206 |
| Raya 1 Hoja 7 | 10.0.1.7/32 | 207 |
| Raya 1 Hoja 8 | 10.0.1.8/32 | 208 |
| . . . |
||
| SPINE1 | 10.0.0.1/32 | 101 |
| SPINE2 | 10.0.0.2/32 | 102 |
| SPINE3 | 10.0.0.3/32 | 103 |
| SPINE4 | 10.0.0.4/32 | 104 |
Tabla 61. Ejemplo de configuración de Junos para interfaces de circuito cerrado y opciones
de enrutamiento
Subyacente de la estructura de backend de GPU con IPv4
Las sesiones de EBGP subyacentes se configuran entre los nodos leaf y nodos spine utilizando las direcciones IP de los vínculos conectados directamente, como se muestra en el ejemplo entre Stripe1 Leaf 1 y los nodos spine a continuación:
Cuadro 62. Ejemplo de configuración de base EBGP : Franja 1 Leaf 1 a spine 1
Cuadro 63. Ejemplo de configuración de base EBGP : Franja 1 Leaf 1 a spine 2
Todas las sesiones de BGP están configuradas con multipath multiple-as, lo que permite considerar varias rutas (al mismo destino) con diferentes rutas de AS para el enrutamiento ECMP (rutas múltiples de igual costo) y con BFD para mejorar la convergencia en caso de fallas.
Para controlar la propagación de rutas, se aplican políticas de exportación a estas sesiones de EBGP, como se muestra en el ejemplo de la tabla 64.
Tabla 64. Ejemplo de política de exportación para anunciar rutas IPv4 a través de una base IPv4
Estas políticas garantizan que la accesibilidad del circuito cerrado se anuncie de forma limpia y sin riesgo de bucles de ruta.
En el nodos spine, las rutas se exportan solo si son aceptadas por las políticas de exportación de SPINE_TO_LEAF_FABRIC_OUT y BGP-AOS-Policy:
- La política de SPINE_TO_LEAF_FABRIC_OUT no tiene condiciones de coincidencia y acepta todas las rutas incondicionalmente, etiquetándolas con la comunidad FROM_SPINE_FABRIC_TIER (0:15).
- BGP-AOS-Policy acepta rutas aprendidas de BGP, así como cualquier ruta aceptada por la política AllPodNetworks anidada.
- La política de AllPodNetworks, a su vez, hace coincidir las rutas IPv4 directamente conectadas y las etiqueta con la comunidad DEFAULT_DIRECT_V4 (1:20007 y 21001:26000 en Spine1).
Como resultado, cada spine anuncia tanto sus rutas conectadas directamente (incluida su interfaz de circuito cerrado) como cualquier ruta que haya recibido de otros nodos leaf.
Ejemplo:
jnpr@spine1> show route advertising-protocol bgp 10.0.2.65 | match /32
* 10.0.0.1/32 Self I
* 10.0.1.2/32 Self 202 I
* 10.0.1.3/32 Self 203 I
---more---
jnpr@spine1> show route advertising-protocol bgp 10.0.2.65 10.0.0.1/32 extensive
inet.0: 85 destinations, 169 routes (85 active, 0 holddown, 0 hidden)
Restart Complete
* 10.0.0.1/32 (1 entry, 1 announced)
BGP group l3clos-underlay type External
Nexthop: Self
AS path: [101] I
Communities: 0:15 1:20007 21001:26000
jnpr@spine2> show route advertising-protocol bgp 10.0.2.65 10.0.1.2/32 extensive
inet.0: 85 destinations, 169 routes (85 active, 0 holddown, 0 hidden)
Restart Complete
* 10.0.1.2/32 (2 entries, 1 announced)
BGP group l3clos-underlay type External
AS path: [101] 202 I
Communities: 0:15 6:20007 21001:26000
En los nodos leaf, las rutas se exportan solo si son aceptadas por las políticas de exportación de LEAF_TO_SPINE_FABRIC_OUT y BGP-AOS-Policy:
- La política de LEAF_TO_SPINE_FABRIC_OUT acepta todas las rutas, excepto las aprendidas a través del BGP que están etiquetadas con la comunidad FROM_SPINE_FABRIC_TIER (0:15). Estas rutas se rechazan explícitamente para evitar que se vuelvan a anunciar rutas aprendidas de spine en la capa spine. Como se describió anteriormente, los nodos spine etiquetan todas las rutas que anuncian a los nodos leaf con esta comunidad para facilitar esta lógica de filtrado.
- BGP-AOS-Policy acepta todas las rutas permitidas por la política AllPodNetworks anidada, que hace coincidir las rutas IPv4 directamente conectadas y las etiqueta con la comunidad DEFAULT_DIRECT_V4 (5:20007 y 21001:26000 para Stripe1-Leaf1).
Como resultado, los nodos leaf anunciarán solo sus rutas de interfaz conectadas directamente, incluidas sus interfaces de circuito cerrado, a las espinas.
jnpr@stripe1-leaf1> show route advertising-protocol bgp 10.0.2.64 | match /32
* 10.0.1.1/32 Self I
jnpr@stripe1-leaf1> show route advertising-protocol bgp 10.0.2.64 10.0.1.1/32 extensive
inet.0: 48 destinations, 257 routes (48 active, 0 holddown, 0 hidden)
Restart Complete
* 10.0.1.1/32 (1 entry, 1 announced)
BGP group l3clos-underlay type External
Nexthop: Self
AS path: [201] I
Communities: 5:20007 21001:26000
Superposición de estructura de backend de GPU con IPv4
Las sesiones de EBGP superpuestas se configuran entre los nodos leaf y nodos spine mediante las direcciones IPv4 de las interfaces de circuito cerrado, tal y como se muestra en el ejemplo entre Stripe1 Leaf 1 y Spines.
Cuadro 65. Ejemplo de configuración de EBGP de superposición EVPN : Franja 1 Leaf 1 a spine 1
Tabla 66. Ejemplo de configuración de EBGP de superposición EVPN : Franja 2 Leaf 1 a spine 1
Las sesiones de BGP superpuestas utilizan la señalización de EVPN de familia para habilitar el intercambio de rutas EVPN. La multihop ttl 1 instrucción permite establecer sesiones de EBGP entre las interfaces de circuito cerrado.
Al igual que con las sesiones de BGP subyacentes, estas sesiones están configuradas con multipath multiple-as, lo que permite considerar varias rutas de EVPN con diferentes rutas de AS para el enrutamiento ECMP (rutas múltiples de igual costo). BFD (detección de reenvío bidireccional) también está habilitada para mejorar el tiempo de convergencia en caso de fallas.
La no-nexthop-change perilla se utiliza para conservar la dirección original del próximo salto, lo cual es fundamental en EVPN para garantizar que se pueda acceder directamente al VTEP remoto. La vpn-apply-export instrucción se incluye para garantizar que las políticas de exportación se evalúen para las familias de direcciones VPN, como EVPN, lo que permite un control detallado sobre las rutas que se anuncian a cada par.
Para controlar la propagación de rutas, se aplican políticas de exportación a estas sesiones de EBGP, como se muestra en el ejemplo de la tabla 67.
Cuadro 67. Ejemplo de política de exportación para anunciar rutas EVPN a través de superposición IPv4
.png)
Estas políticas tienen una estructura más simple y están destinadas a permitir el alcance de EVPN de extremo a extremo entre las GPU de inquilino, a la vez que evitan los bucles de ruta dentro de la superposición.
Las rutas solo se anunciarán si se crearon instancias de enrutamiento EVPN. Ejemplo:
Tabla 68. Ejemplo de instancias de enrutamiento EVPN para un solo inquilino en diferentes nodos leaf..png)
En el nodos spine, las rutas se exportan si son aceptadas por la política de SPINE_TO_LEAF_EVPN_OUT:
- La política de SPINE_TO_LEAF_EVPN_OUT no tiene condiciones de coincidencia y acepta todas las rutas. Etiqueta cada ruta exportada con la comunidad FROM_SPINE_EVPN_TIER (0:14).
Como resultado, los nodos spine exportan rutas EVPN recibidas de una hoja a todos los demás nodos leaf, lo que permite la comunicación de inquilino a inquilino en toda la estructura.
Ejemplo:
jnpr@spine1> show route advertising-protocol bgp 10.0.1.1 | match 5:10.*2001.*31 5:10.0.1.2:2001::0::10.200.0.2::31/248 5:10.0.1.2:2001::0::10.200.0.66::31/248 5:10.0.1.9:2001::0::10.200.1.0::31/248 5:10.0.1.9:2001::0::10.200.1.64::31/248 5:10.0.1.10:2001::0::10.200.1.2::31/248 5:10.0.1.10:2001::0::10.200.1.66::31/248 jnpr@spine1> show route advertising-protocol bgp 10.0.1.1 match-prefix 5:10.0.1.2:2001::0::10.200.0.2::31/248 bgp.evpn.0: 378 destinations, 378 routes (378 active, 0 holddown, 0 hidden) Restart Complete Prefix Nexthop MED Lclpref AS path bgp.evpn.0: 20 destinations, 20 routes (20 active, 0 holddown, 0 hidden) 5:10.0.1.2:2001::0::10.200.0.2::31/248 * 10.0.1.2 202 I
En los nodos leaf, las rutas se exportan si son aceptadas por las políticas de LEAF_TO_SPINE_EVPN_OUT y EVPN_EXPORT:
- La política de LEAF_TO_SPINE_EVPN_OUT rechaza cualquier ruta aprendida de BGP que lleve a la comunidad FROM_SPINE_EVPN_TIER (0:14). Estas rutas se rechazan explícitamente para evitar que se vuelvan a anunciar rutas aprendidas de spine en la capa spine. Como se describió anteriormente, los nodos spine etiquetan todas las rutas que anuncian a los nodos leaf con esta comunidad para facilitar esta lógica de filtrado.
- La política de EVPN_EXPORT acepta todas las rutas sin condiciones adicionales.
Como resultado, los nodos leaf exportan solo rutas EVPN originadas localmente para las interfaces conectadas directamente entre los servidores de GPU y los nodos leaf. Estas rutas forman parte de las instancias de enrutamiento del inquilino y son necesarias para establecer la accesibilidad entre GPU que pertenecen al mismo inquilino.
jnpr@stripe1-leaf1> show route advertising-protocol bgp 10.0.0.1 table Tenant-1 Tenant-1.evpn.0: 12 destinations, 39 routes (12 active, 0 holddown, 0 hidden) Restart Complete Prefix Nexthop MED Lclpref AS path 5:10.0.1.1:2001::0::10.200.0.0::31/248 * Self I 5:10.0.1.1:2001::0::10.200.0.64::31/248 * Self I 5:10.0.1.1:2001::0::192.168.11.1::32/248 * Self I jnpr@stripe1-leaf1> show route advertising-protocol bgp 10.0.0.1 table Tenant-2 Tenant-2.evpn.0: 8 destinations, 20 routes (8 active, 0 holddown, 0 hidden) Restart Complete Prefix Nexthop MED Lclpref AS path 5:10.0.1.1:2002::0::10.200.0.32::31/248 * Self I 5:10.0.1.1:2002::0::10.200.0.96::31/248 * Self I 5:10.0.1.1:2002::0::192.168.11.2::32/248 * Self I
Ejemplo de configuración y verificación
Considere el siguiente escenario en el que al inquilino-1 se le ha asignado la GPU 0 en el servidor 1 y la GPU 1 en el servidor 2, y al inquilino-2 se le ha asignado la GPU 0 en el servidor 2 y la GPU 1 en el servidor 1, como se muestra en la figura 57.
Figura 57: Asignación de GPU en los servidores para el inquilino 1 y el inquilino 2
Tanto la Hoja 1 como la Hoja 2 de la Franja 1 se han configurado para el Inquilino-1 y el Inquilino-2 como se muestra a continuación:
Tabla 69. Instancia de enrutamiento EVPN para los inquilinos 1 y 2 en las franjas 1 y 2
Las instancias de enrutamiento crean espacios de enrutamiento independientes para los dos inquilinos, lo que proporciona aislamiento completo de ruta y tráfico en toda la estructura EVPN/VXLAN. Cada instancia de enrutamiento se configuró con los siguientes elementos clave:
- Interfaces:
Las interfaces enumeradas en cada VRF de inquilino (por ejemplo, et-0/0/0:0.0 y et-0/0/1:0.0) se agregan explícitamente a la tabla de enrutamiento correspondiente. Al colocar estas interfaces bajo el VRF, todas las decisiones de enrutamiento y el reenvío de tráfico asociados con ellas se aíslan de otros inquilinos y de la tabla de enrutamiento global. La asignación de una interfaz que conecta una GPU determinada al nodo leaf asigna efectivamente esa GPU a un inquilino específico, aislándola de las GPU asignadas a otros inquilinos.
- Distinguidor de rutas (RD):
10.0.1.1:2001 y 10.0.1.1:2002 identifican de forma exclusiva las rutas EVPN del inquilino-1 y del inquilino-2, respectivamente. Incluso si ambos inquilinos usan prefijos IP superpuestos, el RD garantiza que sus rutas permanezcan distintas en el plano de control del BGP. Aunque los vínculos de GPU a leaf usan prefijos /127 únicos, se sigue necesitando un RD para anunciar estas rutas a través de EVPN.
- Comunidad de destino de ruta (RT):
Los objetivos de VRF 20001:1 y 20002:1 controlan desde qué rutas se exportan e importan a cada tabla de enrutamiento de inquilino. Estos valores determinan qué rutas se comparten entre VRF que pertenecen al mismo inquilino en toda la estructura y son esenciales para habilitar la conectividad de inquilinos en toda la estructura, por ejemplo, cuando un inquilino tiene GPU asignadas a varios servidores en diferentes franjas.
- Protocolos Parámetros de EVPN:
- ip-prefix-routes controla cómo se anuncian las rutas de prefijo IP (rutas EVPN tipo 5).
- El próximo salto directo de anuncio permite que el nodo leaf envíe información de prefijo IP mediante rutas puras de tipo 5 de EVPN, lo que incluye una comunidad extendida de MAC de enrutador. Estas rutas incluyen una comunidad extendida de MAC de enrutador, que permite que el VTEP remoto resuelva la dirección MAC del próximo salto sin depender de rutas de tipo 2.
- La vxlan de encapsulación indica que el tráfico de carga para este inquilino se encapsulará mediante VXLAN. El mismo tipo de encapsulación debe usarse de extremo a extremo.
- El identificador de red VXLAN (VNI) actúa como etiqueta de encapsulación para el tráfico enviado a través de la estructura EVPN/VXLAN. Cuando se anuncian rutas de EVPN tipo 5 (prefijo IP), el VNI asociado se incluye en la actualización del BGP. Esto garantiza que los VTEP remotos puedan identificar el segmento VXLAN correcto para devolver tráfico al VRF del inquilino.
- A diferencia de los casos de uso tradicionales en los que un VNI se asigna a un solo segmento de capa 2, en EVPN tipo 5 el VNI representa el dominio de enrutamiento de capa 3 de todo el inquilino. Todas las subredes punto a punto, como los vínculos /127 entre los servidores de GPU y la hoja, que pertenecen al mismo VRF se anuncian con el mismo VNI.
En esta configuración, los VNI 20001 y 20002 se asignan a los VRF de inquilino-1 y inquilino-2, respectivamente. Todo el tráfico destinado a las interfaces del inquilino 1 se reenviará mediante VNI 20001 y todo el tráfico del inquilino 2 utilizará VNI 20002.
Observe que el mismo VNI está configurado para el inquilino tanto en Stripe1-Leaf1 como en Stripe2-Leaf1.
La política de exportación BGP-AOS-Policy-Tenant-1 controla qué prefijos de este VRF se pueden anunciar en EVPN.
Tabla 70. Ejemplos de políticas para el inquilino 1 y el inquilino 2 en Stripe 1 y Stripe 2
Lógica de política de exportación
Las rutas EVPN Tipo 5 del inquilino-1 se exportan si son aceptadas por la política de exportación BGP-AOS-Policy-Tenant-1, que hace referencia a una política anidada denominada AllPodNetworks-Tenant-1.
- La política BGP-AOS-Policy-Tenant-1 acepta cualquier ruta permitida por la política AllPodNetworks-Tenant-1 y rechaza explícitamente todas las demás rutas.
- Política AllPodNetworks-Tenant-1 acepta rutas IPv6 conectadas directamente (familia inet6, protocolo directo) que forman parte del VRF de inquilino-1. Etiqueta estas rutas con la comunidad TENANT-1_COMMUNITY_V4 (5:20007 21002:26000) antes de aceptarlas. Se rechazan todas las demás rutas.
Como resultado, solo las rutas IPv6 conectadas directamente desde el inquilino 1 (vínculos /127 entre servidores de GPU y la hoja) se exportan como rutas EVPN tipo 5.
Para comprobar las asignaciones de interfaz a los distintos inquilinos, utilice: show interfaces routing-instance <tenant-name> terse.
jnpr@stripe1-leaf1> show interfaces routing-instance Tenant-1 terse
Interface Admin Link Proto Local Remote
et-0/0/0:0.0 up up inet 10.200.0.0/31
multiservice
lo0.1 up up inet 192.168.11.1 --> 0/0
jnpr@stripe1-leaf1> show interfaces routing-instance Tenant-2 terse
et-0/0/1:0.0 up up inet 10.200.0.16/31
multiservice
lo0.1 up up inet 192.168.11.2 --> 0/0
jnpr@stripe1-leaf2> show interfaces routing-instance Tenant-1 terse
Interface Admin Link Proto Local Remote
et-0/0/0:0.0 up up inet 10.200.0.2/31
multiservice
lo0.1 up up inet 192.168.12.1 --> 0/0
jnpr@stripe1-leaf2> show interfaces routing-instance Tenant-2 terse
et-0/0/1:0.0 up up inet 10.200.0.18/31
multiservice
lo0.1 up up inet 192.168.12.2 --> 0/0
También puede comprobar las rutas directas instaladas en la tabla de enrutamiento correspondiente:
jnpr@stripe1-leaf1> show route protocol direct table Tenant-1.inet.0
Tenant-1.inet.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
Restart Complete
@ = Routing Use Only, # = Forwarding Use Only
+ = Active Route, - = Last Active, * = Both
10.200.0.0/31 *[Direct/0] 02:24:29
> via et-0/0/12:0.0
192.168.11.1/32 *[Direct/0] 02:16:52
> via lo0.1
jnpr@stripe1-leaf1> show route protocol direct table Tenant-2.inet.0
Tenant-2.inet.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
Restart Complete
@ = Routing Use Only, # = Forwarding Use Only
+ = Active Route, - = Last Active, * = Both
10.200.0.16/31 *[Direct/0] 02:24:29
> via et-0/0/12:0.0
192.168.11.1/32 *[Direct/0] 02:16:52
> via lo0.2
jnpr@stripe1-leaf2> show route protocol direct table Tenant-1.inet.0
tenant-1.inet.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
Restart Complete
@ = Routing Use Only, # = Forwarding Use Only
+ = Active Route, - = Last Active, * = Both
10.200.0.2/31 *[Direct/0] 1d 17:42:33
> via et-0/0/2:0.0
192.168.12.1/32 *[Direct/0] 02:16:52
> via lo0.1
jnpr@stripe1-leaf2> show route protocol direct table Tenant-2.inet.0
tenant-1.inet.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
Restart Complete
@ = Routing Use Only, # = Forwarding Use Only
+ = Active Route, - = Last Active, * = Both
10.200.0.18/31 *[Direct/0] 1d 17:42:33
> via et-0/0/3:0.0
192.168.12.1/32 *[Direct/0] 02:16:52
> via lo0.2
Para comprobar los contextos L3 de EVPN, como la encapsulación, el VNI y la dirección MAC del enrutador, utilice show evpn l3-context
Use <tenant-name> extensive para obtener detalles sobre el modo.
jnpr@stripe1-leaf1> show evpn l3-context L3 context Type Adv Encap VNI/Label Router MAC/GW intf dt4-sid dt6-sid dt46-sid Tenant-1 Cfg Direct VXLAN 20001 9c:5a:80:c1:b3:06 Tenant-2 Cfg Direct VXLAN 20002 9c:5a:80:c1:b3:06 jnpr@stripe1-leaf2> show evpn l3-context L3 context Type Adv Encap VNI/Label Router MAC/GW intf dt4-sid dt6-sid dt46-sid Tenant-1 Cfg Direct VXLAN 20001 58:86:70:79:df:db Tenant-2 Cfg Direct VXLAN 20002 58:86:70:79:df:db jnpr@stripe1-leaf1> show evpn l3-context Tenant-1 extensive L3 context: Tenant-1 Type: Configured Advertisement mode: Direct nexthop, Router MAC: 9c:5a:80:c1:b3:06 Encapsulation: VXLAN, VNI: 20001 IPv4 source VTEP address: 10.0.1.1 IP->EVPN export policy: BGP-AOS-Policy-Tenant-1 Flags: 0xc209 <Configured IRB-MAC ROUTING RT-INSTANCE-TARGET-IMPORT-POLICY RT-INSTANCE-TARGET-EXPORT-POLICY> Change flags: 0x20000 <VXLAN-VNI-Update-RTT-OPQ> Composite nexthop support: Disabled Route Distinguisher: 10.0.1.1:2001 Reference count: 5 EVPN Multicast Routing mode: CRB jnpr@stripe1-leaf1> show evpn l3-context Tenant-2 extensive L3 context: Tenant-2 Type: Configured Advertisement mode: Direct nexthop, Router MAC: 9c:5a:80:c1:b3:06 Encapsulation: VXLAN, VNI: 20002 IPv4 source VTEP address: 10.0.1.1 IP->EVPN export policy: BGP-AOS-Policy-Tenant-2 Flags: 0xc209 <Configured IRB-MAC ROUTING RT-INSTANCE-TARGET-IMPORT-POLICY RT-INSTANCE-TARGET-EXPORT-POLICY> Change flags: 0x20000 <VXLAN-VNI-Update-RTT-OPQ> Composite nexthop support: Disabled Route Distinguisher: 10.0.1.1:2002 Reference count: 5 EVPN Multicast Routing mode: CRB jnpr@stripe1-leaf2> show evpn l3-context Tenant-1 extensive L3 context: Tenant-1 Type: Configured Advertisement mode: Direct nexthop, Router MAC: 58:86:70:79:df:db Encapsulation: VXLAN, VNI: 20001 IPv4 source VTEP address: 10.0.1.2 IP->EVPN export policy: BGP-AOS-Policy-Tenant-1 Flags: 0xc209 <Configured IRB-MAC ROUTING RT-INSTANCE-TARGET-IMPORT-POLICY RT-INSTANCE-TARGET-EXPORT-POLICY> Change flags: 0x20000 <VXLAN-VNI-Update-RTT-OPQ> Composite nexthop support: Disabled Route Distinguisher: 10.0.1.2:2001 Reference count: 5 EVPN Multicast Routing mode: CRB jnpr@stripe1-leaf2> show evpn l3-context Tenant-1 extensive L3 context: Tenant-2 Type: Configured Advertisement mode: Direct nexthop, Router MAC: 58:86:70:79:df:db Encapsulation: VXLAN, VNI: 20002 IPv4 source VTEP address: 10.0.1.2 IP->EVPN export policy: BGP-AOS-Policy-Tenant-2 Flags: 0xc209 <Configured IRB-MAC ROUTING RT-INSTANCE-TARGET-IMPORT-POLICY RT-INSTANCE-TARGET-EXPORT-POLICY> Change flags: 0x20000 <VXLAN-VNI-Update-RTT-OPQ> Composite nexthop support: Disabled Route Distinguisher: 10.0.1.2:2002 Reference count: 5 EVPN Multicast Routing mode: CRB jnpr@stripe1-leaf1> show evpn ip-prefix-database L3 context: Tenant-1 IPv4->EVPN Exported Prefixes Prefix EVPN route status 10.200.0.0/31 Created 192.168.11.1/32 Created EVPN->IPv4 Imported Prefixes Prefix Etag 10.200.0.2/31 0 Route distinguisher VNI/Label/SID Router MAC Nexthop/Overlay GW/ESI Route-Status Reject-Reason 10.0.1.2:2001 20001 58:86:70:79:df:db 10.0.1.2 Accepted n/a 192.168.12.1/32 0 Route distinguisher VNI/Label/SID Router MAC Nexthop/Overlay GW/ESI Route-Status Reject-Reason 10.0.1.2:2001 20001 58:86:70:79:df:db 10.0.1.2 Accepted n/a L3 context: Tenant-2 IPv4->EVPN Exported Prefixes Prefix EVPN route status 10.200.0.16/31 Created 192.168.11.2/32 Created EVPN->IPv4 Imported Prefixes Prefix Etag 10.200.0.18/31 0 Route distinguisher VNI/Label/SID Router MAC Nexthop/Overlay GW/ESI Route-Status Reject-Reason 10.0.1.2:2002 20002 58:86:70:79:df:db 10.0.1.2 Accepted n/a 192.168.12.2/32 0 Route distinguisher VNI/Label/SID Router MAC Nexthop/Overlay GW/ESI Route-Status Reject-Reason 10.0.1.2:2002 20002 58:86:70:79:df:db 10.0.1.2 Accepted n/a
Cuando se utiliza EVPN tipo 5 para implementar el aislamiento de inquilinos L3 en una estructura VXLAN, se crean instancias de varias tablas de enrutamiento en cada nodo leaf participante. Estas tablas son responsables de administrar la separación del plano de control, hacer cumplir los límites de los inquilinos y admitir el modelo de reenvío de superposición. Cada instancia de enrutamiento (VRF) crea su propio conjunto de tablas de enrutamiento y reenvío, además de las tablas globales y específicas de EVPN que se usan para la comunicación en toda la estructura. Estas tablas se enumeran en la Tabla 71.
Tabla 71. Tablas de enrutamiento y reenvío para EVPN tipo 5
| TABLA | DESCRIPCIÓN |
|---|---|
| bgp.evpn.0 | Contiene la información de rutas EVPN recibidas a través del BGP, incluidas las rutas de tipo 5 (prefijo IP) y otros tipos de rutas EVPN. Este es el origen del plano de control para las rutas aprendidas de EVPN |
| :vxlan.inet.0 | Se utiliza internamente para la resolución de túneles VXLAN. Asigna direcciones IP VTEP a próximos saltos físicos. |
| <inquilino>.inet.0 | La tabla de enrutamiento de unidifusión IPv6 específica del inquilino. Contiene prefijos de tipo 5 conectados directamente e importados por EVPN para ese inquilino. Se utiliza para enrutar el tráfico del plano de datos. |
| <inquilino>.evpn.0 | La tabla EVPN específica del inquilino. |
El protocolo next hop se extrae de cada ruta EVPN, se extrae y se resuelve en inet.0. La ruta EVPN se agrega a la tabla bgp.evpn.0. El resultado se coloca en :vxlan.inet.0.
El valor de comunidad route-target se utiliza para determinar a qué inquilino pertenece la ruta y la ruta se coloca en tenant.evpn.0. Desde allí, las rutas IPv4 se importan a tenant.inet.0 para usarse en búsquedas de rutas cuando el tráfico llega a las interfaces que pertenecen al VRF.
Se deben establecer sesiones de EBGP IPv4 que anuncien rutas EVPN para el inquilino 1 y el inquilino 2. Las rutas deben instalarse tanto en la tabla bgp.evpn.0 como en la tabla <Tenant>.inet.0.
jnpr@stripe1-leaf1> show bgp summary | no-more ---more--- Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 10.0.0.1 101 5 4 0 0 18 Establ bgp.evpn.0: 4/4/4/0 Tenant-1.evpn.0: 2/2/2/0 Tenant-2.evpn.0: 2/2/2/0 10.0.0.2 102 5 4 0 0 14 Establ bgp.evpn.0: 0/4/4/0 Tenant-1.evpn.0: 0/2/2/0 Tenant-2.evpn.0: 0/2/2/0 10.0.0.3 103 5 4 0 0 10 Establ bgp.evpn.0: 0/4/4/0 Tenant-1.evpn.0: 0/2/2/0 Tenant-2.evpn.0: 0/2/2/0 10.0.0.4 104 5 4 0 0 6 Establ bgp.evpn.0: 0/4/4/0 Tenant-1.evpn.0: 0/2/2/0 Tenant-2.evpn.0: 0/2/2/0 jnpr@stripe2-leaf1> show bgp summary | no-more ---more--- Peer AS InPkt OutPkt OutQ Flaps Last Up/Dwn State|#Active/Received/Accepted/Damped... 10.0.0.1 101 206 199 0 0 1:29:40 Establ bgp.evpn.0: 0/4/4/0 Tenant-1.evpn.0: 0/2/2/0 Tenant-2.evpn.0: 0/2/2/0 10.0.0.2 102 206 199 0 0 1:29:25 Establ bgp.evpn.0: 0/4/4/0 Tenant-1.evpn.0: 0/2/2/0 Tenant-2.evpn.0: 0/2/2/0 10.0.0.3 103 206 199 0 0 1:29:26 Establ bgp.evpn.0: 0/4/4/0 Tenant-1.evpn.0: 0/2/2/0 Tenant-2.evpn.0: 0/2/2/0 10.0.0.4 104 207 199 0 0 1:29:39 Establ bgp.evpn.0: 0/4/4/0 Tenant-1.evpn.0: 0/2/2/0 Tenant-2.evpn.0: 0/2/2/0
Para comprobar que se anuncian rutas EVPN, utilice show route advertising-protocol bgp <neighbor>. Para una ruta específica, use la match-prefix opción e incluya todo el prefijo evpn como se muestra en el ejemplo siguiente:
jnpr@stripe1-leaf1> show route advertising-protocol bgp 10.0.0.1 table Tenant | match 5:10.0.1.1:2001 | match 31/248
5:10.0.1.1:2001::0::10.200.0.0::31/248
jnpr@stripe1-leaf1> show route advertising-protocol bgp 10.0.0.1 table Tenant | match 5:10.0.1.1:2002 | match 31/248
5:10.0.1.1:2002::0::10.200.0.16::31/248
jnpr@stripe1-leaf2> show route advertising-protocol bgp 10.0.0.1 table Tenant | match 5:10.0.1.2:2001 | match 31/248
5:10.0.1.2:2001::0::10.200.0.2::31/248
jnpr@stripe1-leaf2> show route advertising-protocol bgp 10.0.0.1 table Tenant | match 5:10.0.1.2:2002 | match 31/248
5:10.0.1.2:2002::0::10.200.0.18::31/248
jnpr@ stripe1-leaf1> show route advertising-protocol bgp 10.0.0.1 match-prefix 5:10.0.1.1:2001::0::10.200.0.0::31/248 table Tenant-1
Tenant-1.evpn.0: 12 destinations, 54 routes (12 active, 0 holddown, 0 hidden)
Restart Complete
Prefix Nexthop MED Lclpref AS path
5:10.0.1.1:2001::0::10.200.0.0::31/248 * Self I
jnpr@ stripe1-leaf1> show route advertising-protocol bgp 10.0.0.1 match-prefix 5:10.0.1.1:2002::0::10.200.0.16::31/248 table Tenant-2
Tenant-2.evpn.0: 12 destinations, 54 routes (12 active, 0 holddown, 0 hidden)
Restart Complete
Prefix Nexthop MED Lclpref AS path
5:10.0.1.1:2002::0::10.200.0.16::31/248 * Self I
jnpr@stripe1-leaf2> show route advertising-protocol bgp 10.0.0.1 match-prefix 5:10.0.1.2:2001::0::10.200.0.2::31/248 table Tenant-1
Tenant-1.evpn.0: 12 destinations, 54 routes (12 active, 0 holddown, 0 hidden)
Restart Complete
Prefix Nexthop MED Lclpref AS path
5:10.0.1.2:2001::0::10.200.0.2::31/248 * Self I
jnpr@stripe1-leaf2> show route advertising-protocol bgp 10.0.0.1 match-prefix 5:10.0.1.2:2002::0::10.200.0.18::31/248 table Tenant-2
Tenant-2.evpn.0: 12 destinations, 54 routes (12 active, 0 holddown, 0 hidden)
Restart Complete
Prefix Nexthop MED Lclpref AS path
5:10.0.1.2:2002::0::10.200.0.18::31/248 * Self I
Los prefijos /248 representan el tipo de ruta 5 de EVPN que anuncia cada prefijo IPv4 que conecta los servidores de GPU y los nodos leaf.
Por ejemplo: 5:10.0.1.2:2001::0::10.200.0.0::31/248 es un tipo de ruta EVPN 5 para el prefijo 10.200.0.0/31 donde:
Cuadro 72. Descripción de los campos de anuncio de ruta de EVPN tipo 5.
| Nombre | Valor | Descripción |
|---|---|---|
| Tipo de ruta | 5: | Indica que la ruta es una ruta de tipo 5 (prefijo IP) |
| Distinguidor de rutas | 10.0.1.2:2001 | Identifica de forma exclusiva las rutas |
| Campos de marcador de posición | ::0:: | Para la dirección MAC y otros campos relacionados con el tipo 2 (no se utiliza aquí) |
| Prefijo IP | 10.200.0.4::31 | El prefijo real que se anuncia |
| VNI | 20001 | VNI para impulsar el tráfico al destino |
| Enrutador de publicidad | 10.0.0.1 (spine 1) | Spine del que se recibió la ruta. |
Para comprobar que se están recibiendo rutas EVPN, utilice show route receive-protocol bgp <neighbor>. Para una ruta específica, use la match-prefix opción e incluya todo el prefijo evpn como se muestra en el ejemplo siguiente:
jnpr@stripe1-leaf1> show route receive-protocol bgp 10.0.0.1 | match 5:10.0.1.2:2001 | match 31 5:10.0.1.2:2001::0::10.200.0.2::31/248 jnpr@stripe1-leaf1> show route receive-protocol bgp 10.0.0.1 | match 5:10.0.1.2:2002 | match 31 5:10.0.1.2:2002::0::10.200.0.18::31/248 jnpr@stripe1-leaf2> show route receive-protocol bgp 10.0.0.1 | match 5:10.0.1.1:2001 | match 31 5:10.0.1.1:2001::0::10.200.0.0::31/248 jnpr@stripe1-leaf2> show route receive-protocol bgp 10.0.0.1 | match 5:10.0.1.1:2002 | match 31 5:10.0.1.1:20021::0::10.200.0.16::31/248
En los ejemplos se muestran las rutas recibidas de la spine 1, pero cada ruta se recibe de los 4 nodos spines, lo cual también puede confirmarse ingresando:
jnpr@stripe1-leaf1> show route table bgp.evpn.0 match-prefix 5:10.0.1.2:2001::0::10.200.0.2::31/248 | match BGP
bgp.evpn.0: 314 destinations, 1040 routes (314 active, 0 holddown, 0 hidden)
* [BGP/170] 11:31:33, localpref 100, from 10.0.0.1
[BGP/170] 11:31:21, localpref 100, from 10.0.0.2
[BGP/170] 11:31:14, localpref 100, from 10.0.0.3
[BGP/170] 11:31:10, localpref 100, from 10.0.0.4
jnpr@stripe1-leaf2> show route table bgp.evpn.0 match-prefix 5:10.0.1.1:2001::0::10.200.0.0::31/248 | match BGP
bgp.evpn.0: 314 destinations, 1040 routes (314 active, 0 holddown, 0 hidden)
* [BGP/170] 11:31:13, localpref 100, from 10.0.0.1
[BGP/170] 11:31:41, localpref 100, from 10.0.0.2
[BGP/170] 11:31:12, localpref 100, from 10.0.0.3
[BGP/170] 11:31:52, localpref 100, from 10.0.0.4
Se puede encontrar información adicional para una ruta determinada utilizando la palabra clave extensa:
jnpr@stripe1-leaf1> show route table bgp.evpn.0 match-prefix 5:10.0.1.2:2001::0::10.200.0.2::31/248 active-path extensive
bgp.evpn.0: 314 destinations, 1040 routes (314 active, 0 holddown, 0 hidden)
Restart Complete
5:10.0.1.2:2001::0::10.200.0.2::31/248 (4 entries, 0 announced)
*BGP Preference: 170/-101
Route Distinguisher: 10.0.1.2:2001
Next hop type: Indirect, Next hop index: 0
Address: 0x55dfb9c305fc
Next-hop reference count: 48
Kernel Table Id: 0
Source: 10.0.0.1
Protocol next hop: 10.0.1.2
Label operation: Push 20001
Label TTL action: prop-ttl
Load balance label: Label 20001: None;
Indirect next hop: 0x2 no-forward INH Session ID: 0
Indirect next hop: INH non-key opaque: (nil) INH key opaque: (nil)
State: <Active Ext>
Local AS: 201 Peer AS: 101
Age: 7:54:49 Metric2: 0
Validation State: unverified
Task: BGP_109.10.0.0.1
AS path: 109 210 I
Communities: 0:14 7:20007 21002:26000 target:20001:1
encapsulation:vxlan(0x8) router-mac:58:86:70:7b:10:db
Import Accepted
Route Label: 20001
Overlay gateway address: 0.0.0.0
ESI 00:00:00:00:00:00:00:00:00:00
Localpref: 100
Router ID: 10.0.0.1
Secondary Tables: Tenant-1.evpn.0
Thread: junos-main
Indirect next hops: 1
Protocol next hop: 10.0.1.2 ResolvState: Resolved
Label operation: Push 20001
Label TTL action: prop-ttl
Load balance label: Label 20001: None;
Indirect next hop: 0x2 no-forward INH Session ID: 0
Indirect next hop: INH non-key opaque: (nil) INH key opaque: (nil)
Indirect path forwarding next hops: 4
Next hop type: Router
Next hop: 10.0.2.64 via et-0/0/2:0.0
Session Id: 0
Next hop: 10.0.2.82 via et-0/0/3:0.0
Session Id: 0
Next hop: 10.0.2.98 via et-0/0/0:0.0
Session Id: 0
Next hop: 10.0.2.114 via et-0/0/1:0.0
Session Id: 0
10.0.1.2/32 Originating RIB: inet.0
Node path count: 1
Forwarding nexthops: 4
---(more)---
Cuadro 73. Campos de anuncio de ruta EVPN tipo 5 Descripción: extensa
| Nombre | Valor | Descripción |
|---|---|---|
| Tipo de ruta | 5: | Indica que la ruta es una ruta de tipo 5 (prefijo IP) |
| Distinguidor de rutas | 10.0.1.2:2001 | Identifica de forma exclusiva las rutas |
| Campos de marcador de posición | ::0:: | Para la dirección MAC y otros campos relacionados con el tipo 2 (no se utiliza aquí) |
| Prefijo IP | 10.200.105.0::24 | El prefijo real que se anuncia |
| VNI | 20001 | VNI para impulsar el tráfico al destino |
| Enrutador de publicidad | 10.0.0.1 | Spine del que se recibió la ruta. |
| Protocolo siguiente salto | 10.0.1.2 (Franja 1, Hoja 2) | Enrutador que originó la ruta EVPN (VTEP remoto) |
| Encapsulación | Tipo: 0x08 | Valor estandarizado asignado por la AANI para la encapsulación de VXLAN en la comunidad extendida de encapsulación EVPN (RFC 9014) |
| Destino de ruta | Objetivo:20001:1 | Identifica la ruta como perteneciente al inquilino 1 |
Para comprobar que las rutas se importan a las tablas de enrutamiento del arrendatario correspondiente, utilice show route table <tenant-name>.inet.0 protocol evpn, como se muestra en el ejemplo siguiente:
jnpr@stripe1-leaf1> show route table Tenant-1.inet.0 protocol evpn | match /31 10.200.0.2/31 *[EVPN/170] 04:02:04 jnpr@stripe1-leaf1> show route table Tenant-2.inet.0 protocol evpn | match /31 10.200.0.18/31 *[EVPN/170] 04:02:04 jnpr@stripe1-leaf2> show route table Tenant-1.inet.0 protocol evpn | match /31 10.200.0.0/31 *[EVPN/170] 04:02:04 jnpr@stripe1-leaf2> show route table Tenant-2.inet.0 protocol evpn | match /31 10.200.0.16/31 *[EVPN/170] 04:02:04