El Logical Distributed Switch en VMware NSX (Parte 1 de 2)

Hola amigo, soy Alberto Giorgi y en esta nota sobre NSX intentaré explicar el Logical Distributed Switch (LDS), probablemente el concepto más importante que incluye el producto.

Trataré de ser lo más didáctico posible, ya que es un concepto complejo y muy importante porque determina el servicio de nivel 2 sobre el cual se apoyan todos los demás servicios que ofrece NSX.

Debido a que esta es probablemente la tecnología más compleja que maneja NSX, dividiré la nota en dos partes. En la primera parte hablaré de los elementos y conceptos que definen VXLAN. En la segunda parte explicaré como trabaja VXLAN dependiendo de la red de transporte en la cual se basa.

El LDS es la funcionalidad que permite crear un servicio de nivel 2 que pueda abarcar múltiples hosts, independientemente de que se hallen conectados a una red de transporte de nivel 2 (Ethernet) o de nivel 3 (IP).

El LDS se basa en la tecnología de VXLAN que es un mecanismo que intenta resolver algunos de los problemas que solemos encontrar en los grandes DataCenters (DCs).

VXLAN es una red overlay, es decir una red sobre otra red. Probablemente el término overlay no les sea familiar, a pesar de que seguramente utilizan esta tecnología a menudo.

Las VPN son otro ejemplo de red overlay. Cuando estamos de viaje y necesitamos conectarnos a la oficina para acceder a nuestras aplicaciones de negocio, solemos usar un programa que establece una conexión con un extremo (generalmente un firewall o un router de borde) al que identificamos mediante una IP pública. Al establecerse la VPN quedamos conectados “directamente” a la red corporativa, a pesar de que nuestro tráfico está pasando por una decena de routers. Sin embargo si hacemos un trace a una dirección interna de un servidor corporativo lo más probable es que veríamos un solo salto.

VXLAN nos permitirá establecer una red de nivel 2 entre dos segmentos aunque estén conectados a través de una red de nivel 3, utilizando el mismo mecanismo que utiliza la VPN, el encapsulamiento de los paquetes Ethernet dentro de paquetes IP.

Pero prefiero ir poco a poco en esta explicación, porque sin duda hay muchos escenarios distintos en los que podamos implementar NSX. Mi idea es comenzar desde lo más simple a lo más complejo para que quede claro cómo trabaja. Además hay una serie de componentes que debemos conocer, y una serie de topologías soportadas que también debemos comprender para saber cual se adapta mejor a nuestro caso.

Si hablamos de servicios de nivel 2, lo primero que quisiera mencionar es que el componente fundamental del NSX es nuestro viejo conocido, el switch distribuido.

Daré por hecho que todos saben lo que es un switch distribuido, ya que existe en vSphere desde la versión 4. Todos sabemos por lo tanto que es un switch que se distribuye entre varios servidores ESX, y que se configura desde el vCenter. El switch distribuido es un prerrequisito para instalar el NSX, y como sabemos, requiere la licencia Enterprise Plus, que es otro prerrequisito.

VXLAN (Virtual Extended LAN)

Quizás para algunos VXLAN no sea una novedad. Al fin y al cabo, esta tecnología ya se utilizaba en vCloud Director 5.1. Sin embargo la versión que incluye NSX tiene algunas mejoras sobre la anterior.

En cambio para los que no conocían sobre VXLAN, primero es necesario que sepan que no se trata de una tecnología propietaria, sino de un draft estándar del IETF , aunque es fácil confundirse porque VMware ha sido uno de sus principales promotores (Cisco, RedHat y Citrix han sido otros).

Como ya he dicho, VXLAN es una red de overlay de nivel 2, aunque no es la única. Existen otros protocolos Overlay de nivel 2 como STT o NVGRE. De hecho Nicira desarrolló la opción de STT y esta es una de las alternativas que soporta el NSX MultiHypervisor. En cambio la versión de NSX para vSphere utiliza VXLAN.

Quizás el concepto más revolucionario (y “marketinero”) de VXLAN, es que resuelve el problema de la limitación de escalabilidad de las VLANs. En ciertos entornos muy complejos 4096 VLANs pueden resultar insuficientes. VXLAN permite mantener la segmentación de tráfico mediante un concepto muy parecido al de las VLANs, pero en lugar de dedicarle solo 12 bits al ID (2^12=4096) le dedica 24 bits, lo que permite que los segmentos diferenciados sean (2^24= 16777216) más de 16 millones, lo que lo hace sumamente escalable.

Normalmente los segmentos comienzan a diferenciarse a partir del ID 5000.

VXLAN trabaja de una manera muy parecida a como trabajan las VLANs para mantener el tráfico segmentado.

Si recordamos que las VLANs son un concepto que solo manejan los switches y que los ordenadores o VMs son totalmente ajenos a dicho concepto, recordaremos también que cuando una trama entra a un switch, este es el responsable de agregarle una etiqueta de 4 bytes que contiene entre otras cosas el VLAN ID (los 12 bits).

Si esta trama llega hasta un Logical Switch NSX que trabaja con VXLAN y la dirección de destino es otro Host que forma parte del mismo LDS, este encapsulará la trama con la VLAN, dentro de otra trama UDP, a la que le agregará una cabecera VXLAN que tiene un campo con el VXLAN ID de 24 bits. Este switch es un NSX Logical Distributed Switch, y puede distribuirse entre uno o varios dvSwitches. Es el componente fundamental del NSX para las funciones de nivel 2, y puede verse representado en esta figura.

Analicemos la figura por partes

En este caso el Logical Distributed Switch (LDS) abarca 2 Host, que además soportan un mismo vdSwitch. En este caso el LDS abarca el mismo alcance que el dvSwitch.

Prestemos atención a la trama que agrega el LDS a partir de una trama VLAN convencional.

Podemos notar que hay varios encabezados, de adentro hacia afuera:

• Un encabezado VXLAN que agrega entre otros el campo VXLAN Network Identifier (VNI). Este es el campo de 24 bits mencionado anteriormente.
• Un encabezado UDP con puerto UDP de destino = 8472 (VXLAN Well Known Port)
• Un encabezado IP, que permitirá que el tráfico de este segmento pase a través de routers para alcanzar al Host de destino. Si la trama interna tiene prioridad marcada de QoS, el campo DSCP es copiado en el encabezado IP para que sea tratado de la misma manera.
• Un encabezado Ethernet, que se irá agregando y quitando hasta que el paquete llegue a su destino. Si la trama interna tiene prioridad marcada de QoS, el campo 802.1p es copiado en el encabezado IP para que sea tratado de la misma manera.
• En total 50 bytes adicionales a la trama original.

Una de las cosas que me asombró del NSX LDS es que se puede distribuir a través de múltiples dvSwitches. En realidad, cuando creamos el LDS, resulta ser ni más ni menos que un PortGroup tradicional que puede abarcar múltiples dvSwitches y al que las VMs se pueden conectar de la misma forma que lo harían a un PortGroup (PG) convencional.

En la siguiente figura vemos un NSX LDS que abarca cuatro Host y dos dvSwitches distintos.

La red física que une a todos estos host conforma la red de transporte del NSX. Esa red podría ser una red de nivel 2, pero también podría ser una red de nivel 3 como en este ejemplo dividida en los segmentos 10.20.10.0/24 a la izquierda, con el 10.20.20.0/24 a la derecha.

La red física pasa a ser la red de transporte que conecta a todos los componentes del LDS. Las tramas transportadas son del tipo VXLAN (VXLAN encapsulated frames). Lo único que necesitamos de esta red subyacente es que pueda transportar IP con QoS y que soporte tramas de hasta 1600 bytes. La red puede tener o no soporte de Multicast, aunque es mejor desde el punto de vista del rendimiento, si lo tiene.

También podemos ver que existe la red de Management, que también abarca a todos los Hosts y que comunica los distintos componentes del LDS.

Es importante notar que la red de Management conecta al NSX Controller Cluster que es el componente del NSX encargado de mantener y distribuir la información de las tablas de los protocolos de control (ARP, Routing, VXLAN, etc.)

La pregunta es, ¿cómo hace entonces el LDS para poder enviar los broadcast o multicast si hay un router entre medio que los filtrará?

Y aquí es donde interviene el concepto de encapsulamiento y overlay.

Para poder entender como resuelve en NSX este problema debo presentar antes el concepto de VTEP.

VTEP significa VXLAN Tunnel EndPoint, y es un proceso que corre en cada ESXi que conforma el NSX LDS y que se encarga de enviar las tramas de las VMs locales a sus correspondientes destinos. Una de sus responsabilidades es establecer túneles con sus pares, que pueden estar dentro de una misma red de nivel 2 o bien en otras redes o subredes de nivel 3.

Una de las responsabilidades del VTEP es saber donde se encuentran las direcciones MAC y hacer una relación entre dichas MACs y los túneles por los que debe enviar las tramas para que lleguen a su destino.

Pero además, tiene como responsabilidad manejar las tramas BCAST y MCAST.

También es el responsable de mantener las direcciones MAC asociadas con su correspondiente VXLAN ID (VNI), de la misma manera que un switch estándar asocia las direcciones MAC con la VLAN a la que pertenece.

En la figura el VTEP está representado por el símbolo X.

Vamos a suponer que las VMs forman parte de la red 192.168.0.0/24 y que la VXLAN asociada a este LDS es la 5020, es decir que todos los VTEPs estarán asociados a ese VNI.

Es importante comprender que cada VTEP interactúa con el NSC Controller Cluster que es responsable de distribuir las direcciones MAC conocidas a todos los VTEPs.

Cuando se enciende una VM en un Host el vCenter envía al NSX Controller Cluster la información de la/s MAC/s asociada/s a esa VM, y el NSX Controller se encarga de distribuir la información a todos los VTEPs que forman el LDS. Esto hace que el mecanismo de descubrimiento de direcciones MAC sea mucho más eficiente que utilizando los tradicionales métodos como ARP, lo que ahorra una importante cantidad de tráfico BCAST. Sin embargo puede ocurrir que el NSX Controller Cluster no conozca una determinada MAC, por ejemplo si el LDS está conectado a una VLAN física gracias al servicio de Brige mencionado en mi primera nota sobre NSX.

Cuando el VTEP necesita enviar una trama UCAST a una dirección MAC que no conoce, consulta al NSX Controller Cluster y si este conoce la MAC, le indica la IP del Host en donde está corriendo esa VM. El VTEP selecciona el túnel que le corresponde con ese Host y envía la trama hacia el destino. Si el NSX Controller Cluster no conoce la MAC de destino, entonces el VTEP averigua la MAC mediante el método tradicional de aprendizaje (ARP request/response).

Un Host se convierte en activo para un determinado VNI cuando una VM es encendida y se conecta a un PG asociado a dicha VNI. El agente (UWA) en dicho Host se conecta al NSX Control Cluster y sincroniza las MACs con las IPs de los demás VTEPs. Si no hay túneles establecidos con alguno de los VTEPs entonces los establece.

Ahora necesitaríamos definir qué clase de red de transporte tenemos, pero esto lo veremos en la segunda parte de esta nota, para lo que habrá que esperar hasta la próxima semana.

Espero que lo visto hasta ahora haya permitido entender los conceptos básicos y cuáles son los componentes de VXLAN.

Valora este articulo para mejorar la calidad del blog. Gracias