🥇Fábrica VxLAN. Parte 3

Hola, Habr. Estoy terminando un ciclo de artículos, dedicados al lanzamiento del curso "Ingeniero de Redes" de OTUS, sobre la tecnología VxLAN EVPN para el enrutamiento dentro de la fábrica y el uso de Firewall para restringir el acceso entre los servicios internos.

Las partes anteriores del ciclo se pueden encontrar en los siguientes enlaces:

Hoy continuaremos estudiando la lógica de enrutamiento dentro de la fábrica VxLAN. En la parte anterior, revisamos el enrutamiento dentro de la fábrica en el marco de un VRF. Sin embargo, en la red puede haber una gran cantidad de servicios-clientes y todos deben distribuirse en diferentes VRF, para limitar el acceso entre ellos. Además del aislamiento de red, el negocio puede necesitar conectar un Firewall, para restringir el acceso entre estos servicios. Sí, no se puede considerar como la mejor solución, sin embargo, las realidades modernas exigen "soluciones modernas".

Consideremos dos variantes de enrutamiento entre VRF:

Enrutamiento, sin salir de la fábrica VxLAN;
Enrutamiento en el equipo externo.

Comencemos con la lógica de enrutamiento entre VRF. Hay una cantidad determinada de VRF. Para enrutarse entre VRF, es necesario asignar un dispositivo en la red que conozca todos los VRF (o al menos parte de ellos, entre los que se necesita el enrutamiento). Dicho dispositivo puede ser, por ejemplo, uno de los switches Leaf (o todos a la vez). Esta topología se vería así:

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

Correcto, cada Leaf debe conocer todos los VRF (y toda la información que contiene) en la red, lo que lleva a la pérdida de memoria y aumenta la carga en la red. De hecho, a menudo cada switch Leaf no necesita conocer todo lo que hay en la red.

Sin embargo, consideremos este enfoque más a fondo, ya que para redes pequeñas esta variante es bastante adecuada (si no hay requisitos específicos del negocio).

En este punto, puede surgir la pregunta de cómo transmitir información de un VRF a otro, ya que el sentido de esta tecnología radica precisamente en que la difusión de información debe ser restringida.

Y la respuesta reside en funciones como exportar e importar información de enrutamiento (la configuración de esta tecnología fue discutida en el segundo parte del ciclo). Resumiré brevemente:

Al establecer el VRF en AF, es necesario especificar route-target para importar y exportar información de rutas. Se puede especificar de manera automática. Entonces, el valor incluirá ASN BGP y L3 VNI, asociado a VRF. Esto es conveniente cuando en su fábrica se utiliza solo un ASN:

vrf context PROD20
  address-family ipv4 unicast
    route-target export auto      ! En modo automático se exporta RT-65001:99000
    route-target import auto

Sin embargo, si tiene más de un ASN y es necesario transmitir rutas entre ellos, una opción más conveniente y escalable sería la configuración manual. route-target. La recomendación en la configuración manual — el primer número, usar uno que le resulte cómodo, por ejemplo, 9999.
El segundo debe ser igual a VNI para este VRF.

Configuraremos 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         ! Ejemplo 1 import desde otro VRF
    route-target import 9999:88000         ! Ejemplo 2 import desde otro VRF

Cómo se ve en la tabla de rutas:

Leaf11# sh ip route vrf prod

192.168.20.0/24, ubest/mbest: 1/0
 *via 10.255.1.20fault, [200/0], 00:24:45, bgp-65001, internal, tag 65001
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN ! prefijo disponible a través de L3VNI 99000

Consideremos la segunda opción de enrutamiento entre VRF — a través de un equipo externo, por ejemplo, un Firewall.

Se pueden suponer varias variantes de trabajo a través de un dispositivo externo:

El dispositivo sabe qué es VxLAN y podemos añadirlo a parte de la fábrica;
El dispositivo no sabe nada sobre VxLAN.

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

Analicemos la segunda opción, cuando nuestro Firewall no sabe nada de VxLAN (actualmente, por supuesto, hay equipos con soporte para VxLAN. Por ejemplo, Checkpoint anunció su soporte en la versión R81. Se puede leer al respecto aquí, sin embargo, todo esto está en fase de prueba y no hay seguridad en la estabilidad de funcionamiento).

Al conectar un dispositivo externo, obtenemos el siguiente esquema:

Como se puede ver en el esquema — hay un cuello de botella en la conexión con el Firewall. Esto debe tenerse en cuenta al planificar la red y optimizar el tráfico de red.

Sin embargo, volvamos a la tarea original de enrutamiento entre VRF. Como resultado de la adición del Firewall, llegamos a la conclusión de que el Firewall debe conocer todos los VRF. Para esto, en los Leaf de frontera también deben estar configurados todos los VRF, y conectamos el Firewall a cada VRF mediante un enlace separado.

Como resultado, el esquema con el Firewall:

Es decir, es necesario configurar el interfaz en cada VRF que se encuentra en la red en el Firewall. En general, la lógica no parece complicada y lo único que puede no gustar es la gran cantidad de interfaces en el Firewall, pero aquí es donde se debe considerar la automatización.

Bien. Hemos conectado el Firewall y lo hemos añadido a todos los VRF. Pero, ¿cómo hacemos que el tráfico de cada Leaf pase a través de este Firewall?

En el Leaf conectado al Firewall, no habrá 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, estático       ! ruta predeterminada a través del Firewall

Sin embargo, ¿qué hacemos con los Leaf remotos? ¿Cómo les transmitimos la ruta externa predeterminada?

Correcto, a través de EVPN route-type 5, al igual que cualquier otro prefijo en la fábrica VxLAN. Sin embargo, esto no es tan sencillo (si hablamos de Cisco, no he verificado con otros proveedores).

El anuncio de la ruta predeterminada debe realizarse desde el Leaf al que está conectado el Firewall. Sin embargo, para transmitir la ruta, el Leaf debe conocerla. Y aquí surge un cierto problema (posiblemente solo para mí), la ruta debe estar configurada de forma estática en el VRF donde deseas anunciar dicha ruta:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

Luego, en la configuración de BGP, se debe especificar esta ruta en AF IPv4:

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

Sin embargo, esto no es todo. De esta manera, la ruta predeterminada no entrará en la familia l2vpn evpn. Además de esto, es necesario 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

Especificamos qué prefijos entrarían en BGP a través de 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 entra en EVPN route-type 5 y se transmite a los demás Leaf:

0.0.0.0/0, ubest/mbest: 1/0
 *via 10.255.1.5fault, [200/0], 5w6d, bgp-65001, internal, tag 65001, segid: 99000 tunnelid: 0xaff0105 encap: VXLAN
 ! 10.255.1.5 - Dirección virtual Leaf (ya que Leaf actúa como par de VPS), al que está conectado el Firewall

En la tabla BGP también podemos observar el route-type 5 recibido con la ruta predeterminada a través de 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 concluimos el ciclo de artículos dedicado a EVPN. En el futuro, intentaré abordar el funcionamiento de VxLAN en combinación con Multicast, ya que este método se considera más escalable (actualmente, una afirmación discutible).

Si aún tiene preguntas o sugerencias sobre el tema, sobre la posibilidad de analizar alguna funcionalidad de EVPN, escríbanos, lo revisaremos adicionalmente.

Fuente: habr.com