Posted by En la parte 5 dejamos preparados nuestros EDGE y el clúster de EDGE, en esta parte 6 vamos a ver como configurar nuestros Tier 1 y Tier 0 Gateways.
Vamos a analizar la arquitectura y características de routing en NSX-T.
Los T1/T0 Gateway realizan las funciones de router lógicos. Un router lógico proporciona routing norte-sur o este-oeste entre diferentes subredes y tiene dos tipos de componentes:
- Distributed router (DR) que se ejecuta como un módulo del kernel en el hipervisor
- Service router (SR) para encargarse de funciones centralizadas como NAT, DHCP, balanceo de carga y proporcionar conectividad a la infraestructura física, los SR se instancian en nuestro clúster de EDGE.
NSX-T soporta un modelo de routing «multi-tier» con separación lógica entre las funciones del router del provider y las funciones de routing del tenant. El concepto de «multi-tenancy» está integrado directamente en la plataforma. El router lógico de nivel superior se conoce como Tier-0, mientras que el router lógico de nivel inferior es el Tier-1.
¿Es obligatorio usar el modelo de routing «multi-tier» ?
La respuesta es que no. Podemos tener un solo router lógico T0 que puede conectarse a la infraestructura física en dirección norte y a los segmentos (logical switch) en dirección sur. Este modelo «single-tier» nos da todas las funcionalidades de routing Este/Oeste distribuido en el kernel y el routing Norte/Sur centralizado. Eso si, hay que tener en cuenta que el balanceo de carga solo esta soportado en T1.
¿Entonces porque usar el modelo «multi-tier» ?
El primer ejemplo claro que me viene a la cabeza es un entorno con vCloud donde queremos tener todo separado en tenants, o por ejemplo en entornos Openstack.
También si usamos NSX-T para provisionar redes y seguridad en entornos con Kubernetes «multi-tier» seria la opción correcta.
Algunos benéficos de usar el modelo «multi-tier» :
- Esta arquitectura brinda a los administradores del provider y del tenant un control completo sobre sus servicios y políticas. El administrador del provider controla y configura los servicios y el routing de nivel 0, y los administradores del tenant controlan y configuran sus routers lógicos de nivel 1 específicos de su tenant.
- Esta arquitectura también elimina la dependencia del administrador de la infraestructura física para cambiar configuraciones cuando se configura un nuevo tenant en el centro de datos.
- Fácil integración con CMPs (Cloud Management Platforms). Con OpenStack o vCloud por ejemplo, para un nuevo tenant solo hay que implementar router lógicos de nivel 1 y conectarlos al router lógico de nivel 0 ya existente. Tier-0 simplemente anuncia las nuevas rutas del nuevo tenant (aprendidas del Tier-1 del tenant) en la adyacencia de routing ya establecida con la infraestructura física.
Vistas las opciones de modelos de routing, en mi opinión las bondades del modelo «multi-tier» superan al «single-tier» , es más en nuestro caso para un entorno Cloud es obvio que es el camino a seguir.
Pasamos a ver los tipos de interface en un router lógico:
Downlink: Interfaz que se conecta a un segmento (logical switch).
Uplink: Interfaz que se conecta a la infraestructura física / router físico.
RouterLink: Interfaz que conecta dos router lógicos.
El T0 se conecta a uno o más router físicos hacia el norte utilizando Uplink y se conecta a uno o varios T1 con RouterLink (en un modelo «single-tier» T0 va directamente a los segmentos/logical switch con Downlink). Los T1 se conectan hacia el sur a través de un Downlink.
A cada conexión de T0 a T1 se le proporciona una IP dentro del rango de direcciones reservado 100.64.0.0/31 (RFC6598). Tenemos la flexibilidad de cambiar este rango de subred y usar otra subred si queremos. Este enlace se crea automáticamente cuando crea un router de nivel 1 y se conecta a un router de nivel 0.
Os pongo una imagen para intentar aclarar un poco el modelo «multi-tier» y todo el esquema de red que hemos visto hasta ahora en esta serie de post (en un «single-tier» desaparecería de la imagen el T1).
Un componente DR para T1 Gateway se instancia en los nodos de transporte cuando un segmento está conectado a un T1 Gateway y proporciona routing este-oeste.
Un componente SR para T1 Gateway se instancia en los EDGE cuando se configura con DNAT, cortafuegos perimetral, un balanceador de carga o DHCP.
Consideraciones de T1 Gateways:
- El tráfico desde/hacia otro T1 Gateway se procesa en el siguiente orden: primero DNAT, luego edge firewall y después balanceo de carga.
- El tráfico dentro del T1 Gateway se procesa a través de DNAT primero y luego el balanceador de carga, se omite el procesamiento de edge firewall.
- Los balanceadores de carga solo son compatibles con un T1 Gateway.
Explicada un poco la arquitectura de routing de NSX-T, nos ponemos manos a la obra, vamos a crear nuestro primer T1, vamos a «Networking» -> «Tier-1 Gateways» -> «ADD TIER-1 GATEWAY» .
No es necesario elegir el clúster de EDGE ya que como hemos comentado antes solo se instancia un SR en los EDGE para servicios que no se pueden distribuir, es decir, conectividad física, NAT, DHCP, balanceadores de carga, etc.
Ahora vamos a asociar nuestros segmentos al T1.
Editamos nuestro segmento App.
En «Connectivity» seleccionamos el T1 que hemos creado.
Añadimos nuestra subred App.
Hacemos lo mismo para los segmentos restantes.
Probamos la conectividad desde una VM en el segmento Web hacia VMs en el segmento App y DB.
Vemos que falla, esto es porque anteriormente en esta serie de post asignamos el segmento Web a las VM Web pero no lo hicimos en las VM de DB y App, vamos a ello.
Ahora vemos que si que hay conectividad desde una VM Web a VMs en App y DB, al agregar nuestro T1 y la subnet a los segmentos hemos habilitado esta conectividad, se crean los Downlink desde T1 a los segmentos y se ha distribuido un DR al kernel de todos los hypervisores conectados a la zona de transporte a la que están asociados los segmentos.
Vista la parte de T1 Gateway vamos con los T0.
En este laboratorio no tengo disponible un router físico o virtual que simule un físico, con lo que os voy a explicar como conectar nuestro Tier 0 a un router físico y a un T1 pero no podre probarlo.
Lo importante es quedarse con el concepto de que el flujo hacia el mundo exterior como podemos ver en la primera imagen del post, se hará VM -> Tier 1 -> Tier 0 -> Mundo.
Vamos a crear los Uplink que conectarían el T0 con el router físico, como no voy a poder probarlo crearemos solo 1 (por lógica deberían crearse 2 al menos).
Vamos a «Segments» y creamos uno nuevo que se llamara Uplink-1 en la transport zone TZ-VLAN-Lab y lo defino en la VLAN 0, obviamente en el mundo real no usaríamos la 0 si no la que nos diese conectividad con el router físico.
Creado el segmento vamos a «Networking» -> «Tier-0 Gateways» -> «ADD GATEWAY» -> «Tier-0» (como veis también podría ser un VRF).
Como vemos aquí si seleccionamos el clúster de EDGE ya que para la conectividad física si se instancia un SR en los EDGE.
Configuramos la redistribución de rutas hacia T1.
Configuramos los «Interfaces» que hablaran con el router físico, como hemos comentado en nuestro caso usaremos solo 1.
Es de tipo externo, con una IP/Mascara para llegar al router, y usara el segmento que hemos creado antes en la TZ-VLAN-Lab. Lo normal seria poner un interface en un EDGE y el segundo en el otro EDGE.
Configuramos el BGP.
Definimos la vecindad BGP.
Conectamos nuestro T1 al T0.
Si vamos al recien creado T0 y pinchamos sobre «Linked Tier-1 Gateways».
Veremos como se ha creado el RouterLink en la subnet 100.64.240.0/31 tal y como hemos explicado al principio del post.
Y con esto terminamos con el routing, ya que como he indicado no tengo posibilidad de probar la conectividad al exterior en nuestro labo.
Importante quedarnos con el concepto de que aunque cuando «pintamos» el esquema vemos elementos T1 y T0, estos realmente realizan sus funciones a través del EDGE clúster, no son más EDGE ni más VMs. Evidentemente a medida que se van añadiendo servicios que dependan de nuestro EDGE clúster, habrá que ir creciendo ese clúster en consecuencia.
En esta parte 6 hemos repasado la parte de routing de NSX-T, en la parte 7 pasaremos a la parte de seguridad en concreto nos centraremos en el Distributed Firewall (DFW).
Comparte si te gusta 🙂