Fábrica de VxLAN. Parte 3

Hola Habr. Estoy terminando una serie de artículos, dedicado al lanzamiento del curso "Ingeniero de redes" por OTUS, utilizando la tecnología VxLAN EVPN para enrutamiento dentro de la estructura y usando Firewall para restringir el acceso entre servicios internos

Las partes anteriores de la serie se pueden encontrar en los siguientes enlaces:

• 1 parte del ciclo - Conectividad L2 entre servidores
• Parte 2 de la serie: enrutamiento entre VNI
• Parte 2.5 de la serie - Digresión teórica

Hoy continuaremos estudiando la lógica de enrutamiento dentro de la estructura VxLAN. En la parte anterior, analizamos el enrutamiento dentro de la estructura dentro de un único VRF. Sin embargo, puede haber una gran cantidad de servicios de cliente en la red y todos ellos deben distribuirse en diferentes VRF para diferenciar el acceso entre ellos. Además de la separación de la red, es posible que una empresa necesite conectar un firewall para restringir el acceso entre estos servicios. Sí, ésta no puede considerarse la mejor solución, pero las realidades modernas requieren “soluciones modernas”.

Consideremos dos opciones para el enrutamiento entre VRF:

1. Enrutamiento sin salir de la estructura VxLAN;
2. Enrutamiento en equipos externos.

Comencemos con la lógica de enrutamiento entre VRF. Hay una cierta cantidad de VRF. Para enrutar entre VRF, debe seleccionar un dispositivo en la red que conozca todos los VRF (o partes entre las cuales se necesita enrutamiento). Dicho dispositivo podría ser, por ejemplo, uno de los conmutadores Leaf (o todos a la vez). . Esta topología se verá así:

¿Cuáles son las desventajas de esta topología?

Así es, cada Leaf necesita conocer todos los VRF (y toda la información que contienen) en la red, lo que provoca pérdida de memoria y una mayor carga de la red. Después de todo, muy a menudo cada conmutador Leaf no necesita saber todo lo que hay en la red.

Sin embargo, consideremos este método con más detalle, ya que para redes pequeñas esta opción es bastante adecuada (si no existen requisitos comerciales específicos)

En este punto, es posible que tenga dudas sobre cómo transferir información de VRF a VRF, porque el objetivo de esta tecnología es precisamente que la difusión de información debe ser limitada.

Y la respuesta está en funciones como la exportación e importación de información de enrutamiento (la configuración de esta tecnología se consideró en segundo partes del ciclo). Permítanme repetir brevemente:

Al configurar VRF en AF, debe especificar route-target para importar y exportar información de rutas. Puede especificarlo automáticamente. Luego, el valor incluirá el ASN BGP y el VNI L3 asociados con el VRF. Esto es conveniente cuando solo tiene un ASN en su fábrica:

vrf context PROD20
  address-family ipv4 unicast
    route-target export auto      ! В автоматическом режиме экспортируется RT-65001:99000
    route-target import auto

Sin embargo, si tiene más de un ASN y necesita transferir rutas entre ellos, la configuración manual será una opción más conveniente y escalable. route-target. La recomendación para la configuración manual es el primer número, use uno que le resulte conveniente, por ejemplo, 9999.
El segundo debe configurarse para que sea igual al VNI para ese VRF.

Configurémoslo de la siguiente manera:

vrf context PROD10
  address-family ipv4 unicast
    route-target export 9999:99000          
    route-target import 9999:99000
    route-target import 9999:77000         ! Пример 1 import из другого VRF
    route-target import 9999:88000         ! Пример 2 import из другого VRF

Cómo se ve en la tabla de enrutamiento:

Leaf11# sh ip route vrf prod
<.....>
192.168.20.0/24, ubest/mbest: 1/0
    *via 10.255.1.20%default, [200/0], 00:24:45, bgp-65001, internal, tag 65001
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN          ! префикс доступен через L3VNI 99000

Consideremos la segunda opción para el enrutamiento entre VRF: a través de equipos externos, por ejemplo Firewall.

Hay varias opciones para trabajar a través de un dispositivo externo:

1. El dispositivo sabe qué es VxLAN y podemos agregarlo a parte del fabric;
2. El dispositivo no sabe nada sobre VxLAN.

No nos detendremos en la primera opción, ya que la lógica será casi la misma que se muestra arriba: llevamos todos los VRF al Firewall y configuramos el enrutamiento entre los VRF en él.

Consideremos la segunda opción, cuando nuestro Firewall no sabe nada sobre VxLAN (ahora, por supuesto, están apareciendo equipos con soporte VxLAN. Por ejemplo, Checkpoint anunció su soporte en la versión R81. Puede leer sobre esto aquí, sin embargo, todo esto está en etapa de prueba y no hay confianza en la estabilidad del funcionamiento).

Al conectar un dispositivo externo, obtenemos el siguiente diagrama:

Como puede ver en el diagrama, aparece un cuello de botella en la interfaz con el Firewall. Esto debe tenerse en cuenta en el futuro a la hora de planificar la red y optimizar el tráfico de la red.

Sin embargo, volvamos al problema original del enrutamiento entre VRF. Como resultado de agregar el Firewall, llegamos a la conclusión de que el Firewall debe conocer todos los VRF. Para hacer esto, todos los VRF también deben configurarse en los Leafs fronterizos y el Firewall debe estar conectado a cada VRF con un enlace separado.

Como resultado, el esquema con Firewall:

Es decir, en el Firewall es necesario configurar una interfaz para cada VRF ubicado en la red. En general, la lógica no parece complicada y lo único que no me gusta aquí es la gran cantidad de interfaces en el Firewall, pero es hora de pensar en la automatización.

Bien. Conectamos el Firewall y lo agregamos a todos los VRF. Pero, ¿cómo podemos forzar ahora que el tráfico de cada Leaf pase a través de este Firewall?

En Leaf conectado al Firewall, no surgirán problemas, ya que todas las rutas son locales:

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.254.13.55, [1/0], 6w5d, static       ! маршрут по-умолчанию через Firewall

Sin embargo, ¿qué pasa con los Leafs remotos? ¿Cómo pasarles la ruta externa predeterminada?

Así es, a través de la ruta EVPN tipo 5, como cualquier otro prefijo sobre la estructura VxLAN. Sin embargo, esto no es tan sencillo (si hablamos de Cisco, ya que no lo he consultado con otros proveedores)

La ruta predeterminada debe anunciarse desde el Leaf al que está conectado el Firewall. Sin embargo, para transmitir la ruta, Leaf debe conocerla por sí mismo. Y aquí surge cierto problema (quizás solo para mí), la ruta debe estar registrada estáticamente en el VRF donde se quiere anunciar dicha ruta:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

A continuación, en la configuración de BGP, configure esta ruta en AF IPv4:

router bgp 65001
    vrf prod
        address-family ipv4 unicast
            network 0.0.0.0/0

Sin embargo, eso no es todo. De esta forma la ruta predeterminada no se incluirá en la familia. l2vpn evpn. Además de esto, necesitas configurar la redistribución:

router bgp 65001
    vrf prod
        address-family ipv4 unicast
            network 0.0.0.0/0
            redistribute static route-map COMMON_OUT

Indicamos qué prefijos entrarán en BGP mediante la redistribución

route-map COMMON_OUT permit 10
  match ip address prefix-list COMMON_OUT

ip prefix-list COMMON_OUT seq 10 permit 0.0.0.0/0

Ahora el prefijo 0.0.0.0/0 cae en la ruta EVPN tipo 5 y se transmite al resto de Leaf:

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.255.1.5%default, [200/0], 5w6d, bgp-65001, internal, tag 65001, segid: 99000 tunnelid: 0xaff0105 encap: VXLAN
    ! 10.255.1.5 - Виртуальный адрес Leaf(так как Leaf выступают в качестве VPС пары), к которому подключен Firewall

En la tabla BGP también podemos observar la ruta resultante tipo 5 con la ruta predeterminada vía 10.255.1.5:

* i[5]:[0]:[0]:[0]:[0.0.0.0]/224
                      10.255.1.5                        100          0 i
*>i                   10.255.1.5                        100          0 i

Con esto concluye la serie de artículos dedicados a EVPN. En el futuro, intentaré considerar el funcionamiento de VxLAN junto con Multicast, ya que este método se considera más escalable (afirmación controvertida en este momento)

Si aún tiene preguntas/sugerencias sobre el tema, considere cualquier funcionalidad de EVPN; escriba, lo consideraremos más a fondo.

Fuente: habr.com