Hola, Habr. Continúo con la serie de artículos sobre la tecnología VxLAN EVPN, que fueron escritos especialmente para el lanzamiento del curso de OTUS. Hoy examinaremos una parte interesante de las tareas: la enrutación. Puede sonar banal, pero en el contexto del funcionamiento de la fábrica de redes, todo puede ser más complicado de lo que parece.
En la parte anterior logramos un dominio de broadcast, construido sobre la fábrica de redes en el Nexus 9000v. Sin embargo, este no es el único espectro de tareas que hay que resolver dentro de la red del centro de datos. Hoy veremos la siguiente tarea: enrutación entre redes o entre VNI.
Recordemos que se utiliza la topología Spine-Leaf:
Primero, analicemos cómo se lleva a cabo el enrutamiento y cuáles son sus particularidades.
Para entenderlo, simplificaremos el esquema lógico y añadiremos otro VNI 20000 para Host-2. El resultado es el siguiente:
¿Cómo se puede transmitir el tráfico de un Host a otro en este caso?
Hay dos opciones:
- Mantener en todos los switches Leaf la información sobre todos los VNI, de manera que todo el enrutamiento se realice en el primer Leaf de la red;
- Utilizar un VNI L3 dedicado
El primer método es simple y conveniente. Solo requiere introducir todos los VNI en todos los switches Leaf. Sin embargo, introducir cientos o miles de VNI en todos los Leaf ya no parece ser una tarea sencilla. Por esta razón, su uso es bastante raro.
Analicemos el segundo método, que es más interesante y un poco más complicado, pero proporciona una mayor flexibilidad en la configuración de la fábrica.
Añadiremos a la topología el VRF "PROD". En este, añadiremos el interfaz vlan 10 en el par Leaf-11/12 y el interfaz VLAN 20 en el Leaf-21. VLAN 20 se asocia con VNI 20000.
vrf context PROD
rd auto ! El Route Distinguisher no es crítico y podemos usar uno formado automáticamente
address-family ipv4 unicast
route-target both auto ! Indicamos el Route-target con el que se importarán y exportarán los prefijos dentro/fuera del VRF
vlan 20
vn-segment 20000
interface nve 1
member vni 20000
ingress-replication protocol bgp
interface Vlan10
no shutdown
vrf member PROD
ip address 192.168.20.1/24
fabric forwarding mode anycast-gatewayPara poder utilizar L3VNI, es necesario crear un nuevo VLAN, asociarlo con un nuevo VNI. El nuevo VNI debe ser el mismo en todos los Leaf interesados en la información sobre VLAN 10 y 20.
vlan 99
vn-segment 99000
interface nve1
member vni 99000 associate-vrf ! Creamos L3 VNI
vrf context PROD
vni 99000 ! Asociamos L3 VNI a un VRF específicoComo resultado, el esquema se representará así:
Solo queda un poco más por hacer: añadir otra interfaz, interface vlan 99 en VRF PROD.
interface Vlan99
no shutdown
vrf member PROD
ip forward ! No debe haber IP en la interfaz. Se utiliza solo para el reenvío de paquetes entre Leaf.En consecuencia, la lógica de paso del marco de Host-1 a Host-2 es la siguiente:
- El marco enviado desde Host-1 llega al Leaf en VLAN 10, que está asociado con VNI 10000;
- El Leaf verifica dónde se encuentra la dirección de destino y la encuentra a través de L3 VNI en el segundo conmutador Leaf;
- Tan pronto como se encuentra la ruta hacia la dirección de destino, el Leaf empaqueta el marco en un encabezado con el necesario L3VNI 99000 y lo envía hacia el segundo Leaf;
- El segundo conmutador Leaf recibe los datos del L3VNI 99000. Recupera el marco original y lo transporta al L2VNI necesario 20000 y luego a VLAN 20.
El resultado de tal trabajo del L3VNI elimina la necesidad de mantener información sobre todos los VNI en todos los conmutadores Leaf.
En consecuencia, al enviar tráfico de Host-1 a Host-2, el paquete se empaqueta dentro de VxLAN con un nuevo VNI — 99000:
Queda por entender cómo exactamente Leaf-1 conoce la dirección MAC de otro VNI. Esto también ocurre mediante el EVPN route-type 2 (MAC/IP).
A continuación se muestra el proceso de propagación de la ruta de un prefijo que se encuentra en otro VNI:
Es decir, las direcciones obtenidas del VNI 20000 tienen dos RT.
Recuerden que las rutas obtenidas de la actualización entran en la tabla BGP con el Route-target especificado en las configuraciones de VRF (el proceso es un poco más complicado, pero en este artículo no profundizaremos).
El RT se forma con la fórmula: AS:VNI (si se utiliza el modo automático).
Ejemplo de formación de RT en modo automático y manual:
vrf context PROD
address-family ipv4 unicast
route-target import auto - modo automático de operación
route-target export 65001:20000 - modo manual de formación de RT.Como resultado, se observa que los prefijos de otro VNI tienen dos valores de RT.
Uno de ellos es 65001:99000 — un L3 VNI adicional. Como este VNI es idéntico en todos los Leaf y está bajo nuestras reglas de importación en la configuración de VRF, el prefijo entra en la tabla BGP, como se puede ver en la salida:
sh bgp l2vpn evpn
Red Siguiente Salto Métrica LocPrf Peso Ruta
Identificador de Ruta: 10.255.1.11:32777 (L2VNI 10000)
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]\/216
10.255.1.10 100 32768 i
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[32]:[192.168.10.10]\/272
10.255.1.10 100 32768 i
*>l[3]:[0]:[32]:[10.255.1.10]\/88
10.255.1.10 100 32768 i
Identificador de Ruta: 10.255.1.21:32787
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.20]\/272 ! Prefijo obtenido de VNI 20000
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 iSi observamos más de cerca la actualización recibida, podemos ver que este prefijo tiene dos RT:
Leaf11# sh bgp l2vpn evpn 5001.0008.0007
Información de la tabla de enrutamiento BGP para VRF por defecto, familia de direcciones L2VPN EVPN
Identificador de Ruta: 10.255.1.21:32787
Entrada de la tabla de enrutamiento BGP para [2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.20]\/272, versión 5164
Rutas: (2 disponibles, mejor #2)
Banderas: (0x000202) (high32 00000000) en la lista de transmisión, no está en l2rib/evpn, no está en HW
Tipo de ruta: interno, la ruta es válida, no es la mejor razón: Dirección del vecino, no hay next-hop etiquetado
AS-Path: NINGUNO, ruta proveniente internamente a AS
10.255.1.20 (métrica 81) de 10.255.1.102 (10.255.1.102)
Origen IGP, MED no establecido, localpref 100, peso 0
Etiqueta recibida 20000 99000 ! Dos etiquetas para el funcionamiento de VxLAN
Extcommunity: RT:65001:20000 RT:65001:99000 SOO:10.255.1.20:0 ENCAP:8 ! Dos valores de Route-target, con base en los cuales se añadió este prefijo
MAC del enrutador:5001.0005.0007
Originador: 10.255.1.21 Lista de clústeres: 10.255.1.102En la tabla de enrutamiento de Leaf-1 también se puede observar el prefijo 192.168.20.20\/32:
Leaf11# sh ip route vrf PROD
192.168.10.0/24, ubest/mbest: 1/0, adjunto
*via 192.168.10.1, Vlan10, [0/0], 01:29:28, directo
192.168.10.1/32, ubest/mbest: 1/0, adjunto
*via 192.168.10.1, Vlan10, [0/0], 01:29:28, local
192.168.10.10/32, ubest/mbest: 1/0, adjunto
*via 192.168.10.10, Vlan10, [190/0], 01:27:22, hmm
192.168.20.20/32, ubest/mbest: 1/0 ! Dirección Host-2
*via 10.255.1.20fault, [200/0], 01:20:20, bgp-65001, interno, etiqueta 65001 ! Accesible a través de Leaf-2
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN ! A través de VNI 99000¿Notaron la ausencia del prefijo principal 192.168.20.0\/24 en la tabla de enrutamiento?
Exacto, no está allí. Es decir, los Leaf remotos obtienen información solo sobre los hosts que hay en su red. Y es el comportamiento correcto. Arriba, en todas las actualizaciones, se puede ver que llega información con el contenido MAC\/IP. No se menciona nada sobre prefijos.
Este es el funcionamiento del protocolo Host Mobility Manager (HMM), que completa la tabla ARP de la cual después se llena la tabla BGP (dentro de este artículo omitiremos este proceso). Con la información obtenida del HMM se forman rutas EVPN de tipo 2 (se transmite MAC\/IP).
Sin embargo, ¿qué hacer si es necesario transmitir información sobre algún prefijo?
Para este tipo de información existe el tipo de ruta EVPN 5, que permite transmitir prefijos a través de address-family l2vpn evpn (este tipo de rutas, al momento de escribir el artículo, se encuentra solo en versión borrador. , por lo que el comportamiento de este tipo de ruta puede variar entre diferentes fabricantes).
Para transmitir prefijos, es necesario agregar los prefijos que serán anunciados en el proceso BGP para VRF:
router bgp 65001
vrf PROD
address-family ipv4 unicast
redistribute direct route-map VNI20000 ! En este caso, anunciamos prefijos conectados directamente a Leaf en VNI 20000
route-map VNI20000 permit 10
match ip address prefix-list VNI20000_OUT ! Especificamos qué prefix-list utilizar
ip prefix-list VNI20000_OUT seq 5 permit 192.168.20.0/24 ! Especificamos qué redes estarán incluidas en el EVPN route-type 5.Como resultado, en la actualización aparecerá:
Veamos la tabla BGP. Además de los tipos de ruta EVPN 2 y 3, han aparecido las rutas de tipo 5, que contienen información sobre el número de la red:
Red Siguiente Salto Métrica LocPrf Peso Camino
Distinguido de Ruta: 10.255.1.11:3
* i[5]:[0]:[0]:[24]:[192.168.10.0]/224
10.255.1.10 0 100 0 ?
*>i 10.255.1.10 0 100 0 ?
Distinguido de Ruta: 10.255.1.11:32777
* i[2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]/216
10.255.1.10 100 0 i
*>i 10.255.1.10 100 0 i
* i[2]:[0]:[0]:[48]:[5001.0007.0007]:[32]:[192.168.10.10]/272
10.255.1.10 100 0 i
*>i 10.255.1.10 100 0 i
* i[3]:[0]:[32]:[10.255.1.10]/88
10.255.1.10 100 0 i
*>i 10.255.1.10 100 0 i
Distinguido de Ruta: 10.255.1.12:3
*>i[5]:[0]:[0]:[24]:[192.168.10.0]/224 ! EVPN route-type 5 con número de prefijo
10.255.1.10 0 100 0 ?
* i En la tabla de enrutamiento, el prefijo también apareció:
Leaf21# sh ip ro vrf PROD
192.168.10.0/24, ubest/mbest: 1/0
*via 10.255.1.10fault, [200/0], 00:14:32, bgp-65001, interno, etiqueta 65001 ! Prefijo remoto, accesible a través de Leaf1/2 (dirección Next-hop = IP virtual entre el par VPC)
(evpn) segid: 99000 tunnelid: 0xaff010a encap: VXLAN ! Prefijo accesible a través de L3VNI 99000
192.168.10.10/32, ubest/mbest: 1/0
*via 10.255.1.10fault, [200/0], 02:33:40, bgp-65001, interno, etiqueta 65001
(evpn) segid: 99000 tunnelid: 0xaff010a encap: VXLAN
192.168.20.0/24, ubest/mbest: 1/0, adjunto
*via 192.168.20.1, Vlan20, [0/0], 02:39:44, directo
192.168.20.1/32, ubest/mbest: 1/0, adjunto
*via 192.168.20.1, Vlan20, [0/0], 02:39:44, local
192.168.20.20/32, ubest/mbest: 1/0, adjunto
*via 192.168.20.20, Vlan20, [190/0], 02:35:46, hmmCon esto, concluimos la segunda parte de la serie de artículos sobre VxLAN EVPN. En la próxima parte, revisaremos diferentes opciones de enrutamiento entre VRF.
Fuente: habr.com
