¿Los artículos de tu blog publicados aquí? ¡Propón tu blog!

VMware NSX – Cómo funcionan y aprenden los VTEPs

Publicado el 10 febrero 2015 por Pipearaque

Hola

Que tal

Continuando con esta serie de Posts acerca de VMware NSX, es tiempo de hablar acerca de cómo funcionan y aprenden los VTEPs.

Mucho se ha hablado acerca del NSX Controller. Se sabe que es una máquina virtual desplegada por el NSX Manager y que puede ser construida en un clúster de nodos. También se ha visto que ésta es capaz de eliminar la necesidad de configurar IGMP y/0 PIM de la red física, dependiendo del modo de replicación. También se mencionó que podría eliminar el tráfico de broadcast. El objetivo de este Post es conocer de qué forma ayuda a la reducción de broadcast, cómo funcionan y cómo aprenden.

Recordar que el NSX Controller se encarga de administrar los módulos de Logical Switch y Logical Router de los ESXi y también almacena las siguientes tablas:

  • Tabla de VTEPs.
  • Tabla de MACs.
  • Tabla ARP.
  • Tabla de enrutamiento. (No oncluído en este Post).

Lo primero que se debe conocer es cómo aprende y de dónde obtiene esta información.

Nota: No se recomienda leer este Post sin antes haber visto o tener claro:

Construcción de la tabla VTEP

Cuando una máquina virtual es conectada a un Logical Switch y siempre y cuando esté encendida, el ESXi enviará un mensaje por medio del agente UWA al NSX Controller indicando la relación VNI/VTEP_IP.

En la figura 1 se tienen 3 ESXis. ESXi-1 tiene la VM1 conectada a la VXLAN 5001. ESXi-2 tiene la VM2 conectada a la VXLAN 5001. ESXi-3 no tiene ninguna VM encendida. Cuando VM1 se enciende en el ESXi-1, el host enviará un mensaje al NSX Controller indicando que la VNI 5001 se encuentra en la IP 10.20.10.10. Cuando la VM2 se enciende, el host envía un mensaje al NSX Controller indicando que el VNI 5001 se encuentra en la IP 10.20.10.11. Esta información es recibida por el nodo de NSX Controller que controla y administra a ese Logical Switch (dependiendo de los slices); suponer que en este caso es el nodo A. El nodo A del NSX Controller recibe esta información, actualiza su tabla VTEP y la replica a todos los ESXi conectados a la VXLAN 5001; esto significa que ESXi-3 no recibe esta actualización, ya que no tiene ninguna VM conectada en esa VXLAN (Logical Switch). De esta forma cada host recibirá la actualización del nodo A:

  • ESXi-1 actualiza su tabla VTEP y ahora conoce que 10.20.10.10 y 10.20.10.11 tienen VMs conectadas a la VXLAN 50001.
  • ESXi-2 actualiza su tabla VTEP y ahora conoce que 10.20.10.10 y 10.20.10.11 tienen VMs conectadas a la VXLAN 50001.
  • ESXi-3 no envió ni recibió actualización debido a que no tiene VMs conectadas a la VXLAN 5001.

En un paréntesis, suponer que VM1 envía un ARP request para conseguir la MAC de VM2. Este tráfico es de BUM y será tratado según el modo de replicación. Suponer que se ha configurado en modo Unicast, por lo tanto, ESXi-1 revisa su tabla VTEP y deberá enviar ese broadcast encapsulado solo a 10.20.10.11.

Como conclusión se puede decir que hay dos tablas VTEP:

  • Tabla VTEP del host
  • Tabla VTEP del NSX Controller

La tabla VTEP del host es la que finalmente se revisará para conocer a quién o quiénes debe ser enviado un tráfico de BUM (Modo de replicación).

Construcción de la tabla MAC

Cada ves que un Logical Switch aprende una dirección MAC, el ESXi que contiene a esa VM enviará un mensaje al NSX Controller encargado de esa red lógica informando acerca de la relación VNI/MAC/VTEP_IP . A continuación el nodo encargado de ese slice deberá actualizar su tabla MAC pero no enviará actualización a los ESXi. Esto significa que cada host solo tendrá inicialmente conocimiento de las direcciones MAC de las máquinas virtuales que actualmente está corriendo, pero irá aprendido con el tiempo las MAC de las VMs en otros ESXi.

En el ejemplo de la figura 2, ESXi-1 envía un mensaje a través del agente UWA al nodo encargado de esa VNI que la MAC1 se encuentra en la VNI 5001 con IP 20.10.10.10. Del mismo modo, ESXi-2 envía un mensaje a través del agente UWA al nodo encargado de esa VNI que la MAC2 se encuentra en la VNI 5001 con IP 20.10.10.11.

NSX Controller posee una tabla indicando que la MAC1 está en la VNI 5001 y en el VTEP con IP 10.20.10.10. La MAC2 está en la VNI 5001 y en el VTEP con IP 10.20.10.11. Cada host inicialmente solo tendrá información de las MAC de sus propias VMs.

Construcción de la tabla ARP

Para formar la tabla ARP es necesario que el NSX Controller tenga conocimiento de las direcciones IP de las máquinas virtuales. Un ESXi sabrá de la dirección IP de sus máquinas virtuales de dos formas:

  • Si la VM recibe IP por DHCP, el host hará un snooping del mensaje de la respuesta del mensaje DHCP.
  • Si la VM tiene IP fija, el VTEP informará la IP de la máquina virtual descubierta en los mensajes de ARP Request.

Cuando un ESXi aprende una IP de una de sus máquinas virtuales, enviará un mensaje VNI/MAC/VM_IP/VTEP_IP al nodo del NSX Controller encargado de ese Logical Switch. En este caso NSX Controller tampoco actualizará a los ESXi.

En la figura 3 por ejemplo, el ESXi-1 envía un mensaje al nodo de NSX Controller encargado de administrar el Logical Switch con VXLAN 5001 indicando que la IP1 pertenece a la MAC1 y se encuentra en la VNI 5001 con dirección de VTEP 10.20.10.10.

A continuación se estudiarán varios escenarios:

  • Escenario 1: Tráfico de BUM con modo de replicación Unicast. VM de origen y de destino se encuentran en el mismo ESXi.
  • Escenario 2: Tráfico de BUM con modo de replicación Unicast. VM de origen y de destino se encuentran en distintos ESXi.
  • Escenario 3: Tráfico de Unicast. VM de origen y de destino se encuentran en distintos ESXi.
  • Escenario 4: Tráfico de BUM con modo de replicación Multicast. VM de origen y de destino se encuentran en distintos ESXi.

Escenario 1: Tráfico de BUM con modo de replicación Unicast. VM de origen y de destino se encuentran en el mismo ESXi

Cómo aprenden y se construyen las tablas VTEPs en este escenario? A continuación un ejemplo:

En la figura 4:

Posibilidad 1: VM2 nunca se ha visto involucrado en mensajes de broadcast, como ARP y DHCP.

  • VM1 y VM2 están conectados al mismo Logical Switch (lo que es lo mismo decir que están conectados a la misma VXLAN, VNI o red lógica), en este ejemplo la VNI 5001.
  • VM1 y VM2 se encuentran en el mismo ESXi.
  • VM1 envía un mensaje de ARP Request solicitando la dirección MAC de VM2.
  • El mensaje de broadcast es recibido por el Logical Switch y reenviado a todos quienes estén conectados al mismo switch lógico del mismo host.
  • En paralelo sucederán dos cosas: VM2 recibirá el broadcast dado a que se encuentra en ese mismo Logical Switch. Mientras tanto, el módulo de seguridad del switch lógico enviará un mensaje al NSX Controller preguntando por la MAC de VM2. Según la figura 4, este mensaje será enviado por la red de administración.
  • Es evidente que VM2 responderá primero con un ARP Reply antes de que el NSX Controller envíe una respuesta.
  • El ARP reply llega el swtich lógico y es enviado a la VM1.
  • Dado a que VM2 nunca se ha visto involucrado en mensajes de broadcast, como ARP y DHCP, el NSX Controller no conoce la MAC de VM2
  • ESXi actualiza su tabla ARP y enviará una actualización VNI/MAC/VTEP_IP al NSX Controller, indicando que en la VNI 5001 hay una MAC2 en el VTEP con dirección IP 10.20.10.10.

Posibilidad 2: VM2 se ha visto involucrado en mensajes de broadcast, como ARP y DHCP.

Si el NSX Controller si tiene la MAC de VM2, responderá al ESXi, pero, es probable que responda primero VM2 con un mensaje de ARP Reply.

Conclusión:

  • No fue necesario encapsular la trama ethernet original de VM1 dado a que ambas máquinas virtuales (origen y destino), se encontraban en el mismo ESXi.
  • NSX Controller no juega un rol vital en este escenario.
  • No fue necesario emplear un Distributed Logical Router para la comunicación entre las VMs.

Escenario 2: Tráfico de BUM con modo de replicación Unicast. VM de origen y de destino se encuentran en distintos ESXi

En la Figura 5:

    VM1 y VM2 están conectadas al mismo Logical Switch 5001 pero se encuentran en distintos ESXis.

1. VM1 envía un ARP Request solicitando la MAC asociada a la IP2. El logical Switch en ESXi-1 recibe el broadcast y lo reenvía a todos los equipos conectados a la misma VXLAN del mismo ESXi. Como en ese host no está la VM2, nadie responde hasta el momento al mensaje de broadcast.

2. En paralelo al paso 1, el módulo de seguridad de ese Logical Switch envía un mensaje al NSX Controller empleando la red de administración preguntando por la dirección MAC de IP2. Si NSX Controller tuviera la respuesta, se evitaría enviar el broadcast por la red de transporte. En este ejemplo NSX Controller si tiene la respuesta en su tabla ARP.

3. NSX Controller recibe la petición.

4. NSX Controller revisa su tabla ARP y encuentra una coincidencia.

5. NSX Controller envía la respuesta al ESXi-1.

6. ESXi-1 recibe la información, actualiza su tabla y ennvía un ARP Reply en nombre de VM2; esto significa que la MAC de origen en la respuesta que dará a VM1 tendrá la MAC2. VM1 recibe la respuesta.

Conclusión:

  • Se evitó enviar un broadcast y emplear el modo de replicación ya que NSX Controller conocía la MAC de la IP2.
  • NSX Controller juega un rol vital en este escenario.
  • No fue necesario emplear un Distributed Logical Router para la comunicación entre las VMs.

Qué sucede si NSX Controller no conoce la MAC de IP2?

  • VM1 envía un ARP Request solicitando la MAC asociada a la IP2. El logical Switch en ESXi-1 recibe el broadcast y lo reenvía a todos los equipos conectados a la misma VXLAN del mismo ESXi. Como en ese host no está la VM2, nadie hasta el momento responde al mensaje de broadcast.
  • En paralelo al paso 1, el módulo de seguridad de ese Logical Switch envía un mensaje al NSX Controller empleando la red de administración preguntando por la dirección MAC de IP2. En este ejemplo NSX Controller no tiene la respuesta en su tabla ARP.
  • NSX Controller recibe la petición.
  • NSX Controller revisa su tabla ARP y no encuentra una coincidencia.

Como ESXi-1 no obtiene la MAC de IP2 del NSX Controller, se prepara entonces para tratar la comunicación como una BUM (Broadcast, Unknow Unicast and Multicast) y empleará el modo de replicación "Unicast".

  • ESXi-1 revisa su tabla de VTEP y se da cuenta que tanto 10.20.10.10 y 10.20.10.11 tienen VMs conectadas a la VNI 5001. ESXi-1 concluye que solo debe enviar a 10.20.10.11. En este ejemplo no hay segmentos VTEPs remotos, por lo tanto ESXi-1 no tiene en su tabla UTEPs.
  • ESXi encapsula la trama original de VM1 (un ARP Request) de la siguiente manera:

Donde:

  • IP DA: Es la IP del VTEP de destino en donde se encuentra VM2.
  • IP SA: Es la IP del VTEP de origen, en este caso, en donde se encuentra VM1.
  • XVLAN: VNI 5001 es la red lógica en donde se encuentra conectada VM1.
  • L2 DA: Es la MAC de la máquina virtual de destino, en este caso un broadcast, ya que se trata de un ARP Request.
  • L2 SA: Es la MAC de la máquina virtual de origen, en este caso MAC1.
  • ESXi-2 recibe la trama encapsulada, revisa si tiene VMs conectadas en esa VNI, la desencapsula y pasa a la VM2. ESXi-2 también actualiza su tabla indicando que en la VNI 5001, hay una VM1 con MAC1/IP1 en el VTEP 10.20.10.10.
  • VM2 responde con un ARP Reply (un arp reply es un mensaje de unicast) y ESXi-2 lo encapsula de la siguiente forma:

ESXi-2 acaba de aprender una nueva MAC e IP, por lo tanto se la enviará al NSX Controller para futuras referencias y consultas.

    ESXi-1 recibe la el paquete encapsulado, revisa la VNI, nota que tiene VMs conectadas a esa VXLAN, desencapsula el paquete y lo entrega a la VM1. ESXi-1 aprovecha también para actualizar su tabla.

Conclusión:

  • No se evitó enviar un broadcast y emplear el modo de replicación ya que NSX Controller no conocía la MAC de la IP2.
  • NSX Controller juega un rol vital en este escenario.
  • No fue necesario emplear un Distributed Logical Router para la comunicación entre las VMs.

La conclusión más importante del escenario 2 es que si la comunicación se realiza gracias al NSX Controller, ESXi-2 nunca recibe ese broadcast y no aprende la ubicación de VM1. Pero, si NSX Controller no es empleado, ESXi-2 recibe el broadcast y conocerá la ubicación de VM1.

Escenario 3: Tráfico de Unicast. VM de origen y de destino se encuentran en distintos ESXi

El escenario 1 y 2 mostraron cómo se aprendía en la red si el mensaje original fuese un broadcast. Una máquina virtual realizará un ARP request si al revisar su propia tabla ARP no tiene una entrada que le indique cuál es la dirección MAC para esa IP de destino. En los escenarios 1 y 2, la VM1 recibió finalmente la respuesta (ARP Reply) y actualizó su propia tabla ARP del sistema operativo. Aunque los mensajes de ARP son los paquetes de broadcast que más se difunden en las redes actuales, VM1 en realidad no ha enviado su mensaje original a VM2. Durante todo este tiempo lo ha guardado en caché a la espera de obtener la MAC de VM2 para terminar de encapsular la trama ethernet. Cuando VM1 termina de armar la trama, la enviará por su vNIC a VM2. En el escenario 3 se mostrará qué sucede cuando VM1 envía información a VM2 pero ya conociendo todos los parámetros de L2, es decir, enviará un mensaje de unicast y no un broadcast:

En la figura 6:

VM1 y VM2 se encuentran en la misma red (VXLAN 5001) pero en distintos ESXis.

VM1 se desea comunicar con VM2, pero conoce la MAC de destino.

1. VM1 envía un mensaje unicast, especificando como IP de origen IP1, IP de destino IP2, MAC de origen MAC1 y MAC de destino MAC2.

2. La trama ethernet original de VM1 es recibida por el Logical Switch y se consulta la tabla VTEP de ESXi-1. Este host ya ha tenido comunicación previa con VM2, por lo tanto, tiene una entrada que le índica a qué VTEP debe enviar esta trama. ESXi-1 encapsula la trama ethernet en como se indica en la figura, especificando que la IP de destino será el VTEP en dónde está VM2 y al envía a ese host. Notar que no se está empleando ningún modo de replicación, ya que la comunicación en sí es unicast.

3. ESXi-2 recibe el paquete, revisa la VNI, nota que tiene VMs conectadas a esa red, desencapsula la información y entrega la trama original de ethernet a VM2. Notar que las VMs no tienen idea alguna de qué es una VXLAN. Las VXLANs son totalmente transparentes para las VMS. Dependiendo si en el escenario 2 ESX-2 recibió o no el broadcast, ESXi-2 aprovecha o no para actualizar su tabla, ya que podría acabar de aprender que en la VNI 5001, hay una VM1 con IP1 y MAC2 ubicada en la VTEP 10.20.10.10.

Escenario 4: Tráfico de BUM con modo de replicación Multicast. VM de origen y de destino se encuentran en distintos ESXi

Suponer la siguiente te red virtual:

  • Cuatro ESXi en clúster.
  • Todos los VTEPs en el mismo segmento de red.
  • Se ha configurado la dirección de multicast 239.1.1.100.
  • Se ha configurado en la red física IGMP Snooping y Querier.
  • VM1 y VM2 están en la misma red lógica.
  • VM1 se desea comunicar con VM2, pero no conoce la MAC de destino.

Para comprender este ejemplo y a modo de repaso de todo lo que ha observado en esta serie de Posts, se pueden concluir varias cosas:

  • Cuando VM1 es encendida, el VTEP del Host 1 enviará un mensaje "IGMP report" para unirse al grupo de Multicast 239.1.1.100. El switch físico recibe este paquete y asocia ese puerto a ese grupo. El VTEP del host 1 también enviará un mensaje a NSX Controller indicando que en el VTEP 10.20.10.10 hay una VM conectada a la VXLAN 5001.
  • Cuando VM2 es encendida, el VTEP del Host 4 enviará un mensaje "IGMP report" para unirse al grupo de Multicast 239.1.1.100. El switch físico recibe este paquete y asocia ese puerto a ese grupo. El VTEP del host 4 también enviará un mensaje a NSX Controller indicando que en el VTEP 10.20.10.10 hay una VM conectada a la VXLAN 5001.
  • Host 2 y 3 no envían nada porque no tienen VMs encendidas en la VXLAN 5001 y otra red lógica.
  • NSX Controller recibe las actualizaciones y envía un mensaje al Host 1 y 4 para que actualicen sus tablas. Host 1 ahora sabe que hay máquinas conectadas a la VNI 5001 en el VTEP 10.20.10.10 y 10.20.10.13. Del mismo modo Host 4 sabrá que hay VMs en la VNI 5001 en el VTEP 10.20.10.13 y 10.20.10.10.

1. VM1 envía un mensaje de broadcast a VM2, ya que no conoce su dirección MAC. En el mensaje de la trama ethernet original, VM1 especificará como IP de origen IP1 e IP2 como destino. Dirección MAC de origen MAC1 y un broadcast como destino. El broadcast llega al Switch Lógico (VXLAN 5001) del host 1 y envía ese broadcast a todos los equipos que tenga conectado en esa misma red en ese mismo host. Nadie responde hasta el momento. El host 1 consulta al NSX Controller encargado de la VNI 5001. NSX Controller no tiene la dirección MAC de VM2. Host 1 envía un mensaje a NSX Controller especificando que en el VTEP 10.20.10.10 hay una MAC1 con IP1.

2. El host 1 revisa su tabla VTEP y se prepara para encapsular la trama ethernet origial. Aunque sabe que en el host 4 hay una VM en esa misma red, no sabe con certeza si esa VM tiene la MAC que esta buscando. El mensaje es un broadcast y será tratado bajo el modo de replicación configurado, en este caso, Multicast. En el paquete encapsulado que enviará, como dirección IP de origen especificará su propia IP del VTEP (10.20.10.10) y como destino, la dirección de multicast 239.1.1.100.

El switch físico recibe el paquete y lo replica por todos los puertos registrados a ese grupo de multicast; en este ejemplo, solo al host 4.

3. Host 4 recibe el paquete, aprovecha para actualizar su tabla, aprendiendo que en la VNI 5001 hay una VM con IP1, MAC1 y está ubicada en la VTEP 10.20.10.10. Revisa la VNI y se da cuenta que tiene VMs conectadas a esa misma red. Desencapsula el paquete y entrega solo la trama ethernet original a VM2.

4. VM2 recibe la trama ethernet, revisa la IP de destino, concluye que es para él mismo y responde el mensaje con un ARP Reply, especificando como IP de origen IP2, IP de destino IP1, MAC de origen MAC2 y MAC de destino MAC1. También aprovecha para actualizar su propia tabla ARP. El mensaje llega al Switch Lógico y envía un mensaje al controller indicándole que acaba de aprender la IP y MAC de VM2. De esta forma el NSX Controller podrá contar con esta información. El host 4 revisa su tabla, encapsula la trama, indicando que la IP del VTEP de origen es 10.20.10.13 y de destino 10.20.10.10. Host 1 recibe el paquete, actualiza su tabla, revisa la VNI, desencapsula y pasa a VM1. VM1 recibe, oberva la MAC de destino, concluye que es para él, desencapsula y mapea la IP2 con MAC2 en su tabla ARP.

En el próximo Post se hablará acerca del NSX Edge.

Gracias por leer!!!

Un saludo

Parte 1: Introducción a VMware NSX. Conceptos iniciales
Parte 2: VMware NSX: Planos
Parte 3: Instalación y configuración de NSX Manager 6.X 
Parte 4: VMware NSX Controller
Parte 5: VMware NSX - Introducción a la VXLAN
Parte 6: VMware NSX - Modos de Replicación 
Parte 7: VMware NSX - Logical Switches 
Parte 8: VMware NSX - Distributed Logical Router

Soy Andrés Felipe Araque D. Ingeniero dse Telecomunicaciones y apasionado por la Virtualización y VMware.


Tags: NSX CONTROLLER, VMware NSX, VTEP