Hola Habr. Continúo la serie de artículos sobre tecnología VxLAN EVPN, que fueron escritos específicamente para el lanzamiento del curso por OTUS. Y hoy consideraremos una parte interesante de las tareas: el enrutamiento. No importa cuán trillado pueda sonar, sin embargo, como parte del trabajo de una fábrica de redes, todo puede no ser tan simple.
En la última parte, logramos un dominio de transmisión construido sobre un tejido de red en un Nexus 9000v. Sin embargo, esta no es toda la gama de tareas que deben resolverse en el marco de la red del centro de datos. Y hoy consideraremos la siguiente tarea: enrutamiento entre redes o entre VNI.
Les recuerdo que se utiliza la topología Spine-Leaf:
Para empezar, analizaremos cómo se produce el enrutamiento y qué características tiene.
Para entender, simplifiquemos el diagrama lógico y agreguemos otro VNI 20000 para Host-2. El resultado es:
¿Cómo, en este caso, se puede transferir tráfico de un Host a otro?
Hay dos opciones:
- Mantenga la información sobre todos los VNI en todos los conmutadores Leaf, luego todo el enrutamiento ocurrirá en la primera hoja en la red;
- Usar dedicado - L3 VNI
La primera forma es simple y conveniente. Dado que solo necesita iniciar todos los VNI en todos los conmutadores Leaf. Sin embargo, ejecutar unos cientos o miles de VNI en todo el Leaf ya no parece una tarea fácil. Por lo tanto, en el trabajo se usa muy raramente.
Analizaremos el método 2, como más interesante y un poco más complicado, pero brindando más flexibilidad en la configuración de la fábrica.
Agreguemos "PROD" a la topología VRF. Agreguemos la interfaz vlan 10 en el par Leaf-11/12 y la interfaz VLAN 20 en Leaf-21. VLAN 20 está asociado con VNI 20000
vrf context PROD
rd auto ! Route Distinguisher не принципиален и можем использовать сформированный автоматически
address-family ipv4 unicast
route-target both auto ! указываем Route-target с которым будут импортироваться и экспортироваться префиксы в/из 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 usar L3VNI, debe crear una nueva VLAN y asociarla con la nueva VNI. El nuevo VNI debe ser el mismo en todos los Leaf interesados en la información de VLAN 10 y 20.
vlan 99
vn-segment 99000
interface nve1
member vni 99000 associate-vrf ! Создаем L3 VNI
vrf context PROD
vni 99000 ! Привязываем L3 VNI к определенному VRFComo resultado, el diagrama se verá así:
Queda por terminar un poco - agregar una interfaz más - interfaz vlan 99 en VRF PROD
interface Vlan99
no shutdown
vrf member PROD
ip forward ! На интерфейсе не должно быть IP. Используется только для пересылки пакетов между LeafComo resultado, la lógica de pasar la trama del Host-1 al Host-2 es la siguiente:
- Una trama enviada por Host-1 llega a un Leaf en VLAN 10, que está asociado con VNI 10000;
- Leaf verifica dónde está la dirección de destino y la encuentra a través de L3 VNI en el segundo interruptor Leaf;
- Tan pronto como se encuentra la ruta a la dirección de destino, el Leaf empaqueta el marco en un encabezado con el L3VNI 99000 necesario y lo envía hacia el segundo Leaf;
- El segundo conmutador Leaf recibe datos de L3VNI 99000. Obtiene la trama original y la transfiere al L2VNI 20000 requerido y luego a la VLAN 20.
Como resultado de este trabajo, L3VNI elimina la necesidad de mantener información sobre todos los VNI que están en la red en todos los conmutadores Leaf.
Como resultado, cuando enviamos tráfico del Host-1 al Host-2, el paquete se empaqueta dentro de VxLAN con el nuevo VNI - 99000:
Queda por ver cómo Leaf-1 aprende exactamente sobre la dirección MAC de otro VNI. Esto también sucede con la ayuda de la ruta EVPN tipo 2 (MAC/IP).
A continuación se muestra el proceso de propagación de una ruta sobre un prefijo ubicado en otro VNI:
Es decir, las direcciones recibidas desde VNI 20000 tienen dos RT.
Permítame recordarle que las rutas recibidas de Update caen en la tabla BGP con el Route-target especificado en la configuración de VRF (el proceso es un poco más complicado, pero no entraremos en este artículo).
El RT en sí está formado por la fórmula: AS:VNI (si se usa el modo automático).
Un ejemplo de formación de RT en modos automático y manual:
vrf context PROD
address-family ipv4 unicast
route-target import auto - автоматический режим работы
route-target export 65001:20000 - ручной режим формирования RTComo resultado, puede ver arriba que los prefijos de otro VNI tienen dos valores RT.
Uno de ellos 65001:99000 es un L3 VNI adicional. Dado que este VNI es el mismo en todas las hojas y se rige por nuestras reglas de importación en la configuración de VRF, el prefijo ingresa en la tabla BGP, que se puede ver en la salida:
sh bgp l2vpn evpn
<.....>
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 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
Route Distinguisher: 10.255.1.21:32787
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.20]/272 ! Префикс полученный из 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
BGP routing table information for VRF default, address family L2VPN EVPN
Route Distinguisher: 10.255.1.21:32787
BGP routing table entry for [2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.2
0]/272, version 5164
Paths: (2 available, best #2)
Flags: (0x000202) (high32 00000000) on xmit-list, is not in l2rib/evpn, is not i
n HW
Path type: internal, path is valid, not best reason: Neighbor Address, no labeled nexthop
AS-Path: NONE, path sourced internal to AS
10.255.1.20 (metric 81) from 10.255.1.102 (10.255.1.102)
Origin IGP, MED not set, localpref 100, weight 0
Received label 20000 99000 ! Два label для работы VxLAN
Extcommunity: RT:65001:20000 RT:65001:99000 SOO:10.255.1.20:0 ENCAP:8 ! Два значения Route-target, на основе, которых добавили данный префикс
Router MAC:5001.0005.0007
Originator: 10.255.1.21 Cluster list: 10.255.1.102
<......>En la tabla de enrutamiento en Leaf-1, también puede ver el prefijo 192.168.20.20/32:
Leaf11# sh ip route vrf PROD
192.168.10.0/24, ubest/mbest: 1/0, attached
*via 192.168.10.1, Vlan10, [0/0], 01:29:28, direct
192.168.10.1/32, ubest/mbest: 1/0, attached
*via 192.168.10.1, Vlan10, [0/0], 01:29:28, local
192.168.10.10/32, ubest/mbest: 1/0, attached
*via 192.168.10.10, Vlan10, [190/0], 01:27:22, hmm
192.168.20.20/32, ubest/mbest: 1/0 ! Адрес Host-2
*via 10.255.1.20%default, [200/0], 01:20:20, bgp-65001, internal, tag 65001 ! Доступный через Leaf-2
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN ! Через VNI 99000¿Observa el prefijo principal faltante 192.168.20.0/24 en la tabla de enrutamiento?
Así es, él no está allí. Es decir, los Leaf remotos reciben información solo sobre los hosts que están en su red. Y este es el comportamiento correcto. Arriba, en todas las actualizaciones, puedes ver que información viene con el contenido de MAC/IP. No hay prefijos de los que hablar.
Este es el protocolo Host Mobility Manager (HMM), que completa la tabla ARP a partir de la cual se completa la tabla BGP (omitiremos este proceso en el marco de este artículo). Con base en la información recibida del HMM, se forman las EVPN de ruta tipo 2 (transmitidas por MAC/IP).
Sin embargo, ¿qué sucede si es necesario pasar información sobre un prefijo?
Para este tipo de información, existe la ruta EVPN tipo 5: le permite enviar prefijos a través de la familia de direcciones l2vpn evpn (este tipo de ruta en el momento de escribir este artículo solo está en la versión preliminar) , debido a esto, diferentes fabricantes pueden tener un comportamiento diferente de este tipo de ruta)
Para transferir prefijos, es necesario agregar prefijos en el proceso BGP para VRF, que se anunciarán:
router bgp 65001
vrf PROD
address-family ipv4 unicast
redistribute direct route-map VNI20000 ! В данном случае анонсируем префиксы подключение непосредственно к Leaf в VNI 20000
route-map VNI20000 permit 10
match ip address prefix-list VNI20000_OUT ! Указываем какой использовать prefix-list
ip prefix-list VNI20000_OUT seq 5 permit 192.168.20.0/24 ! Указываем какие сети будут попадать в EVPN route-type 5Como resultado, la actualización será:
Veamos la tabla BGP. Además de la ruta EVPN tipo 2,3, han aparecido rutas tipo 5 que contienen información sobre el número de red:
<......>
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 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 ?
Route Distinguisher: 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
Route Distinguisher: 10.255.1.12:3
*>i[5]:[0]:[0]:[24]:[192.168.10.0]/224 ! EVPN route-type 5 с номером префикса
10.255.1.10 0 100 0 ?
* i
<.......> El prefijo también apareció en la tabla de enrutamiento:
Leaf21# sh ip ro vrf PROD
192.168.10.0/24, ubest/mbest: 1/0
*via 10.255.1.10%default, [200/0], 00:14:32, bgp-65001, internal, tag 65001 ! Удаленный префикс, доступный через Leaf1/2(адрес Next-hop = virtual IP между парой VPC)
(evpn) segid: 99000 tunnelid: 0xaff010a encap: VXLAN ! Префикс доступен через L3VNI 99000
192.168.10.10/32, ubest/mbest: 1/0
*via 10.255.1.10%default, [200/0], 02:33:40, bgp-65001, internal, tag 65001
(evpn) segid: 99000 tunnelid: 0xaff010a encap: VXLAN
192.168.20.0/24, ubest/mbest: 1/0, attached
*via 192.168.20.1, Vlan20, [0/0], 02:39:44, direct
192.168.20.1/32, ubest/mbest: 1/0, attached
*via 192.168.20.1, Vlan20, [0/0], 02:39:44, local
192.168.20.20/32, ubest/mbest: 1/0, attached
*via 192.168.20.20, Vlan20, [190/0], 02:35:46, hmmEsto concluye la segunda parte de una serie de artículos sobre VxLAN EVPN. En la siguiente parte, consideraremos varias opciones para el enrutamiento entre VRF.
Fuente: habr.com