El Logical Distributed Switch en VMware NSX (Parte 2 de 2)
Alberto Giorgi
Posted On octubre 16, 2014
Hola, soy Alberto Giorgi y esta nota es la continuación de la nota sobre el Logical Distributed Switch (LDS) del VMware NSX, así que para aquellos que no hayan tenido la oportunidad de leer la primera, les recomiendo que lo hagan antes que esta, sino la probabilidad de entender de lo que hablo será muy poca.
En dicha nota definí los conceptos y componentes fundamentales de la tecnología de overlay VXLAN y en esta explicaré la red de transporte.
La red de transporte
Como he mencionado, la red de transporte es transparente a los efectos de VXLAN, y lo único que necesitamos de ella es que sea capaz de transportar paquetes IPs de 1600 bytes. Pero dependiendo de las capacidades de esa red podremos hacer un uso más o menos eficiente para transmitir el tráfico de control y de datos.
Lo primero que deberíamos tener en cuenta de la red de transporte que clase de servicios soporta y cuál es su alcance.
Supongamos que nuestra red comprende dos DCs conformados por dos host a la izquierda (10.20.10.10 y .11) y otros dos host a la derecha (10.20.20.10 y .11). A su vez ambos DCs están conectados por una red de un proveedor de servicios como se muestra en la figura de encabezado de este post
Sobre esta red hemos definido un LDS que abarca los 4 Hosts y 2 dvSwitches mediante una red lógica (VXLAN 5020) que conecta 8 VMs. Gracias al mecanismo de overlay las VM creen estar conectadas a un solo segmento de nivel 2 y por lo tanto tienen direcciones IP de una misma red (192.168.0.0/24).
Ahora analizaremos como podemos configurar el LDS en caso de que la red de transporte soporte o no MCAST.
NSX soporta tres tipos de red de transporte.
- Unicast
- Multicast
- Híbirdo
UNICAST
El primer tipo es para aquellas redes que no soportan protocolos MCAST.
La siguiente figura representa ese escenario.
En versiones anteriores a NSX 6.0, VXLAN requería una red de transporte MCAST. El soporte de UCAST es una de las mejoras que se ha introducido en NSX. No es una mejora desde el punto de vista del rendimiento, es decir no es más eficiente transmitir con UCAST, sino que es una mejora en cuanto a la flexibilidad de los requerimientos dado que muchas redes de proveedores de servicios carecen de esta funcionalidad.
La solución para este escenario se basa en replicar los paquetes BUM (Broadcast, Unknown, Multicast, es decir los que requieren FLOOD) por parte del VTEP del host donde se originan, replicando el paquete y enviándolo a el resto de los host.
Para tratar de optimizar la tarea el LDS definirá un VTEP especial llamado Unicast Tunnel Endpoint (UTEP) que actuará como un VTEP Proxy para su segmento. Esta asignación es determinada por el NSX Controller cluster.
Cuando un VTEP necesita transmitir un BUM al resto de los hosts, solo necesitará replicar las tramas a los VTEP Proxys (UTEPs) de cada segmento y estos a su vez se encargarán de replicarlos a todos los VTEPs dentro de su segmento. Esto minimiza el esfuerzo del VTEP de origen pero agrega un pequeño delay.
A pesar de esta optimización, es posible que piense que en un entorno con una elevada cantidad de paquetes BCAST o MCAST esta tarea puede consumir mucha CPU, tanto por parte de los host de origen como los de destino, y efectivamente así es.
Los ARP Request
Los ARP Request son una clase de BCAST que tiene un tratamiento ligeramente distinto. Sabemos que son paquetes de control que intentan resolver las direcciones MAC de destino.
Es posible que los VTEPs puedan conocer las direcciones MAC de destino ya que las aprenden gracias al NSX Controller cluster, que se encarga de distribuirlas a cada uno de los host que forman parte del mismo LDS en el momento en el que una VM se enciende.
Eso significa que si la VM envía un ARP request consultando por una dirección MAC que no conoce, el request es interceptado por el VTEP local, quien verificará si conoce o no que VTEP tiene la dirección MAC de destino. Si no la conoce le preguntará al NSX Controller Cluster, si este la conoce entonces el VTEP contesta a la VM como lo haría un Proxy ARP. Esto permite reducir una gran cantidad de tráfico BCAST cuando las direcciones MAC son desconocidas por las VMs.
Si el NSX Controller Cluster tampoco conoce quien tiene la dirección MAC de destino entonces el VTEP de origen trata ese request como un BCAST tradicional y lo envía a todos los UTEPs que forman parte del LDS para esa VXLAN. A su vez, cada UTEP replicará la trama a todos los VTEPs locales.
Observe que al hacer esta replicación cada VTEP aprenderá la dirección MAC de origen y la relacionará con el VTEP de origen de una forma similar a como lo hace un switch convencional cuando aprende una nueva dirección MAC en un puerto y la asocia en su tabla de direcciones (transparent learning).
La VM dueña de la dirección MAC recibirá así el ARP request y responderá con un ARP replay UCAST, que será enviado directamente al VTEP de origen que a su vez lo enviará a la VM de origen. El VTEP de origen agregará la dirección MAC aprendida a su tabla. El NSX Controller cluster actualizará las tablas correspondientes.
También observe que este procedimiento solo es necesario si la dirección MAC de destino está en un segmento VXLAN distinto al de origen. Es decir que si la dirección MAC de destino estuviera en el mismo host, nada de esto sería necesario (como cuando un switch tradicional escucha una trama con una dirección MAC que conoce que está en conectada en el mismo puerto, DISCARD), al igual que si ambas VMs están conectadas al mismo dvSwitch. En ninguno de los dos casos es necesario encapsular la trama de origen y enviarla a través de un túnel hasta otro host, porque en ambos casos hay una conexión más directa entre las VMs origen y destino.
MULTICAST (IPV4)
El soporte de tráfico MCAST requiere de ciertos protocolos por debajo, tales como IGMP y probablemente PIM u otro protocolo de routing MCAST.
En alguna otra nota futura explicaré como funciona Multicast en IPv4 dado que es un protocolo complejo.
Para esta nota será suficiente que sepan que el tráfico MCAST se diferencia por grupos. Esos grupos se identifican por direcciones IP de clase D (224.0.0.0 a 239.255.255.255).
Todos los dispositivos que estén interesados en recibir tráfico MCAST de un grupo determinado, se asocian mediante un protocolo llamado IGMP y a partir de ese momento los routers intermedios entre el origen y todos los destinos comienzan a enrutar el tráfico de manera eficiente, de forma de que cada trama en el origen alcance solo a aquellos dispositivos que pertenecen al grupo MCAST.
Veamos en esta figura un escenario como nos puede interesar segmentar el tráfico utilizando los servicios de MCAST y de paso vemos la relación con la VXLAN.
En principio contamos con 4 DCs conectados por una red MCAST. Cada DC tiene su VTEP con una dirección IP única.
Ahora añadamos que queremos diferenciar dos tipos de tráfico distinto (multitenant), el tráfico del cliente A (tenant azul) y el tráfico de cliente B (tenant rojo) para mantenerlos aislados.
Para ello asociamos a cada grupo MCAST un VXLAN (VNI) distinto.
Esto sería lo óptimo, pero debemos notar que podría haber muchos más segmentos VXLAN que direcciones MCAST disponibles, por lo tanto hay que tener muy en cuenta antes de elegir este diseño cuantas serán las direcciones MCAST con las que podemos contar.
Pero las direcciones MCAST no son una limitación, de hecho podríamos contar con solo una dirección IP MCAST que conectara a todos los nodos. El tráfico todavía se mantendría segmentado gracias al VXLAN ID (VNI), pero no sería tan eficiente, dado que habría BCAST (o BUM) del cliente azul que llegarían al VTEP 192.168.40.1 y deberían ser descartados por no pertenecer a dicha VXLAN.
Si la red de transporte soporta MCAST, entonces los BUMs solo necesitan ser encapsulados en una trama MCAST para poder llegar a todos los VTEPs, el protocolo MCAST se encargará de hacer que esa trama llegue a todos los VTEPs involucrados de la forma más eficiente.
Con este mecanismo no hace falta UTEPs, ni repetir la trama múltiples veces.
El problema es que la probabilidad de contar con una red de transporte que soporte MCAST no solo en los DC, sino en la red de backbone del proveedor es muy baja.
HÍBRIDO
En este escenario el soporte de MCAST es solo local, pero no global. Este puede ser un escenario frecuente, ya que muchas organizaciones tienen soporte de MCAST en sus DCs, pero conectan sus DCs a través de un proveedor que no brinda ese servicio.
En esta figura trata de representar dicho escenario:
El modo híbrido trata de optimizar y nos ofrece la mejor solución para ambos casos.
El NSX Controller cluster vuelve a crear en estos casos el rol llamado VTEP Proxy en cada uno de los dos segmentos locales, pero en este escenario los llamaremos MTEPs.
Si la VM 1 genera un BUM, el VTEP de origen replicará la trama con un MCAST con destino 239.1.1.1 en el segmento local y un unicast que enviará al MTEP 2 (10.20.20.10). A su vez el MTEP replicará la trama como un MCAST con destino 239.1.1.2 para que llegue a todos los VTEPs en el segmento de la derecha.
El modo híbrido nos permite por lo tanto resolver el problema de no contar con una red MCAST global usando UCAST para ese propósito a la vez que optimiza el tráfico dentro de cada DC generando solo una trama para cada tipo de paquete BUM.
Conclusiones
VXLAN es una poderosa tecnología que nos permite librarnos de las limitaciones que podemos encontrar en los grande DCs.
Nos permite escalar mucho más allá de las 4096 VLANs y nos permiten conectar DC separados mediante redes de nivel 3 en forma transparente.
La nueva versión disponible en NSX permite optimizar el tráfico si la red de transporte soporta MCAST o bien prescindir de este requerimiento con un mecanismo inteligente que trata de minimizar el esfuerzo.
Valora este articulo para mejorar la calidad del blog. Muchas gracias.
