VMware NSX – VXLAN – Modos de Replicación

Hola buen día

Continuando con VXLAN es tiempo de hablar acerca de la Zona de Transporte y los modos de replicación.

En el pasado Post se introdujo acerca de las VXLAN y se mencionó varias veces qué es un VTEP. Virtual Tunnel End Point es el encargado de encapsular y desencapsular la trama ethernet de las máquinas virtuales en paquetes UDP. También se mostró cómo instalar y configurar VTEP. Recordar que en un proceso conocido como "Host Preparation", NSX Manager instala tres módulos en los ESXi:

En cuanto al módulo de VXLAN, NSX permite configurar VTEP en los clústeres.

Nota: Se puede pensar en una VXLAN como una VLAN, excepto que se tiene un número mucho mayor de redes lógicas con VXLAN.

Tras un rápido repaso, es hora de hablar acerca de la zona de transporte.

Transport Zone:

Una zona de transporte define qué VTEPs serán capaces de comunicarse y participar en una red VXLAN. Realmente cuando se está creando una zona de transporte no es posible elegir qué VTEPs participarán en esta. Lo que si se puede hacer es escoger qué Clústeres harán parte de la zona de transporte. (Un clúster contiene ESXi y éstos últimos tienen configurado los VTEP).

Una zona de transporte puede incluir ESXi de diferentes clústeres y un clúster puede pertenecer a más de una zona de transporte. Una zona de transporte también puede tener uno o varios VNI. Por ejemplo, por una zona de transporte llamada A existen tres redes lógicas, VXLAN 5000, 50001 y 5002. Todos los clústeres que pertenecen a la misma zona de transporte comparten el mismo VNI. Como se verá más adelante, una zona de transporte también permite definir qué Logical Switchs serán parte de ésta. El "Logical Switch" es tal vez el parámetro más importante en el momento de diseñar cuántas zonas de transporte se necesitarán. Por lo general con tan sola una es suficiente.

Antes de crear una zona de transporte es preciso primero configurar un "Segment ID pool", ó Identificadores de segmento de VXLAN, el cual definirá el rango de VXLAN.

Identificadores de Segmentos de VXLAN

En el pasado Post se habló acerca de la trama encapsulada de VXLAN. Un valor dentro del Header de VXLAN es el VNI o Virtual Network Identifier. Este campo tiene 24 bits (dos elevado a ese valor da más de 16 millones). Esto significa que con VXLAN se pueden crear más de 16 millones de redes lógicas. Aunque técnicamente es posible trabajar con todo este rango, VMware ha decidido iniciar con el número 5000 con el fin de no interferir con el rango actual de la VLAN (0-4096).

Para crear un Identificador de segmento de VXLAN o "Segment ID Pool", seguir los siguientes pasos:

Paso 1: Conectado a vCenter Server con el Web Client, ir a Home, Inventories y clic en "Networking and Security".

Paso 2: Clic en "Installation", ubicado en la barra lateral izquierda. A continuación hacer clic en "Logical Network Preparation" y finalmente en "Segment ID":

Paso 3: A la derecha de "Segment ID pool:" clic en "Edit".

• Segment ID Pool: Este campo permite definir el rango de identificadores de red de VXLAN. Este rango será utilizado de forma secuencial cada vez que se cree un segmento de red virtual (Logical Switch). Notar que el rango puede ser del 5000 al 16'777.216.
• Enable Multicast Addreessing: Es muy prematuro hablar acerca de este campo, pero, si se tiene planeado utilizar el modo de replicación Multicast o Híbrido, seleccionar esta opción y configurar una rango de direcciones multicast. Por otro lado, si se empleará el modo de replicación Unicast, no seleccionarla. Si la versión de los ESXi es 5.1, esta opción debe ser seleccionada. En la versión 5.5 de VMware, Multicast ya no es una obligación y trae dos modos de replicación adicionales (Híbrido y Multicast).

Para verificar si el pool fue definido de forma correcta basta con observar el campo "segment ID pool":

En la figura 3 notar que:

• El rango de XLVAN es del 5000-6000.
• No se está empleando el modo de replicación multicast o híbrido.

Cómo crear una Zona de Transporte:

Una vez definido el rango de las VXLAN, el siguiente paso es crear la zona de transporte.

Paso 1: Clic en Transport Zones:

Paso 2: Clic en el símbolo de "más" de color verde. A continuación aparecerá la siguiente ventana:

Name: El nombre que se dará a esta zona de transporte.

Description: De forma opcional, una descripción de la zona de transporte.

Control Plane Mode: En este campo se debe definir el modo de replicación (Multicast, Unicast o Híbrido).

Select clusteres to add: Clic en los clústeres que se desean incluir en esta zona de transporte.

Al finalizar verificar que la zona haya sido creada de manera exitosa:

Nota: Cuando en un Transport Zone ha sido creado un Logical Switch, éste podrá ser visto por todos los clústeres de la zona.

Según la figura 5 hay tres modos de replicación:

Antes de introducir cada uno es necesario que se tengan los conceptos claros acerca de Multicast. Se comenzará por los modos de comunicación.

Tipos de modos comunicación

Un modo de comunicación define la forma cómo se comunican las entidades en una red. Existen varios modos.

Modos en IPv4

Modos en IPv6

Comunicación Unicast

Para comprender cómo funciona Unicast, suponer que en la figura 7 hay seis Nodos. Un nodo puede verse como una computadora. El Nodo 1 desea comunicarse con el Nodo 2. Si la comunicación es Unicast significa que será "" y N2, N3, N4, N5 y N6 no la verán. El único que verá y recibirá la comunicación será N2. En conclusión, unicast es una comunicación uno a uno y solo involucra dos entidades en una red (el que envía y el que recibe).

Comunicación Broadcast

En una comunicación del tipo broadcast, un mensaje originado por un nodo irá dirigido a todos los nodos de la misma red. En este caso, la información que enví N1 será recibida y escuchada por todos los nodos. Es una comunicación de "".

Observando las figuras 7 y 8, cómo podría N1 enviar un mensaje no a uno, ni a todos, sino a un grupo de nodos. Por ejemplo, suponer que N1 desea enviar un mensaje a N5 y N6, pero no a N2, N3 y N4. Al tratar de emplear broadcast es evidente que no funciona para este caso. Qué sucede con Unicast?. N6 envía un mensaje unicast solicitando un servicio a N1. N1 envía el mensaje unicast a N6. N5 envía un mensaje unicast solicitando servicio a N1. N1 envía el mensaje unicast a N5. Esto significa que N1 habrá enviados dos mensajes (el mismo mensaje) por la red. Unicast tampoco es eficiente en este tipo de comunicación y nace la necesidad de emplear Multicast.

Comunicación Multicast

En Multicast, un nodo envía un mensaje a un grupo de receptores. La ventaja de este tipo de comunicación con respecto a Unicast reside en la forma y cantidad de veces en que el emisor debe enviar el mensaje. Con Multicast, el mensaje puede ser enviado tan solo una vez a diferencia de varias veces si fuese el caso de Unicast.

En IPv4 existen 5 clases de direcciones IP:

• Clase A (Rango: 0-127)
• Clase B (Rango: 128-191)
• Clase C (Rango 192-223)
• Clase D (Rango: 224-239)
• Clase E (Rango: 240-255)

Unicast utiliza las clases A, B y C. Por ejemplo, En la figura 7 suponer que N1 tiene la dirección IP 172.16.25.10/24 y N2 172.16.25.89/24. Estas direcciones son clase B.

Broadcast emplea la dirección 255.255.255.255. En la Figura 8 suponer que N1 es un nodo que desea adquirir dirección IP por DHCP. N1 envía un mensaje con destino a 255.255.255.255, el cual llegará a todos los nodos de la misma red.

Multicast se encuentra en le rango de la Clase D. En la figura 9 suponer que N1 es un VTEP con dirección 239.1.1.1. N5 y N6 también son VTEPs en otros ESXi con la misma dirección (239.1.1.1). Si N1 envía un mensaje de multicast, sólo N5 y N6 recibirán los datos.

Para comprender los modos de replicación en VXLAN es preciso tratar también dos protocolos de multicast:

• IGMP (Internet Group Managment Protocol)
• PIM (Protocol Independent Multicast)

IGMP

Es un protocolo de capa de red o tres del modelo de referencia OSI, el cual permite vincular Nodos a un Grupo de Multicast . En la figura 7 suponer que N5 y N6 han eviado peticiones a N1 para unirse al grupo de multicast 239.1.1.1. Cuando N1 envía un mensaje a esta dirección, N5 y N6 recibirán esos datos.

IGMP Snooping

Para que un dispositivo de capa 2 como un Switch físico pueda utilizar IGMP es preciso configurar sobre éste IGMP Snooping. IGMP Snooping le permite a un Switch conocer qué dispositivos pertenecen a qué grupos de multicast. Para comprender cómo funciona suponer que se tiene la siguiente red:

La anterior red consta de dos servidores Webcast. Webcast A tiene la dirección de Multicast 239.1.1.1 y Webcast B 239.1.1.2. La principal función de IGMP Snooping, protocolo que corre en el swtich físico, es la de monitorear los siguientes de mensajes:

Con base en esos mensajes, IGMP Snooping construye la tabla de envío. Podría darse dos casos:

Caso 1: Los nodos envían mensajes de reporte no solicitados.

Si N1 y N2 son configurados para pertenecer al grupo de Multicast 239.1.1.1, estos enviarán un Report message (mensaje de reporte no solicitado) al switch físico solicitando unirse al grupo 239.1.1.1 . El switch lo recibirá y ahora sabrá que los puertos P1 y P2 pertenecen al grupo de Multicast 239.1.1.1. De forma similiar, si N4 y N5 son configurados en el grupo de Multicast 239.1.1.2, estos dos nodos enviarán un Report message y el switch físico maperará los puertos P4 y P5 al grupo de Multicast 239.1.1.2. Si el servidor Webmaster A envía un mensaje a 239.1.1.1, el switch físico revisa su tabla y nota que los puertos P1 y P2 están mapeados a ese grupo y solo lo reenvía a los nodos N1 y N2. N3 y N6 son nodos que no pertenecen a ningún grupo, por lo tanto nunca recibirán nada de Webmaster A ni B. Lo que envíe Webmaster B será escuchado solo por N4 y N5.

Caso 2: El router envía menajes de query.

En el caso 1 los nodos son quienes piden unirse a un grupo. En el caso 2 es el router quien pide a los nodos unirse. Cuando un router envía un mensaje de query, el swtich lo recibe y replica en todos los puertos de la VLAN especificada en el mensaje. Los nodos conectados a esos puertos enviarán un mensaje de report y se atarán al grupo de multicast.

PIM

PIM es configurado en dispositivos de capa tres como Routers. PIM permite enrutar el tráfico de Multicast. Este protocolo tiene tres modos de configuración:

VMware recomienda emplear el modo bidireccional.

Nota: Este Post no pretende adentrarse en la configuración de los dispositivos físicos. IGMP Sooping y PIM no serán tratados con detalle debido a que estos son configurados en el lado de la red físico y no dentro de VMware. Además PIM no es estrictamente necesario para que la solución funcione.

Regresando al tema, según la figura 5 existen tres modos de replicación; Unicast, Hibrid y Multicast. El modo de replicación define cómo será tratado el tráfico BUM (Broadcast, Unknow unicast and Multicast). Por ejemplo, si una máquina virtual conectada a la VXLAN 5000 envía un mensaje de broadcast a una máquina virtual en otro ESXi, cómo será transportado? A esto se refiere los modos de replicación.

Antes de comprender los tres modos es necesario entender lo que es un "Segmento VTEP".

En la figura 11 suponer que se tienen dos Clúster. El Clúster A está constituido por ESXi-1 y ESXi-2. El Clúster B tiene a ESXi-3 y ESXi-4. El Clúster A y B están compartiendo el mismo Switch Distribuido. En el Clúster A ha sido configurado el segmento de VTEP 10.20.10.0/24, mientras que en B es 10.20.11.0/24. Ambos Clústeres pertenecen a la misma zona de transporte. De esta figura finalmente se puede concluir que hay dos segmentos VTEP:

VXLAN Transport Subet A 10.20.10.0/24 (ESXi-1 y ESXi-2)

VXLAN Transport Subet B 10.20.11.0/24 (ESXi-3 y ESXi-4)

Modo Unicast

El modo Unicast es el más fácil de configurar. No requiere ninguna configuración en los switches ni routers físicos aparte de la MTU, sin embargo, para ambientes grandes es ineficiente en consumo de ancho de banda y CPU de los ESXi. Este modo está basado en el NSX Controller, quien administra el plano de control en este caso.

En el modo Unicast tanto el tráfico local como remoto es replicado empleando unicast. Los ESXi son divididos en grupos o segmentos VTEP, dependiendo del direccionamiento IP al que pertenecen. NSX Controller elige un VTEP en cada segmento de VTEP. A este VTEP se le conoce como "Proxy VTEP" y en el caso de Unicast como UTEP "Unicast Tunnel End Point". Esta elección es por VNI.

Si por ejemplo se tiene una máquina virtual VM1 conectada a una VXLAN 5001 en el ESXi-1 y requiere comunicarse con una máquina virtual VM2 en la misma VXLAN en un ESXi-2, pero VMA no conoce la MAC de VMB, el tráfico de broadcast de la máquina virtual A será encapsulado en una trama VXLAN. El VTEP de origen (el VTEP del ESXi01) deberá replicar esta trama a cada uno de los VTEPs del mismo segmento y al UTEP del segmento remoto:

De la figura 12 se puede deducir que:

• Hay 4 VMs, todas conectadas a las misma VXLAN 5001.
• Hay 2 clúster. Cada uno con dos ESXi y distinto segmento de VTEP.
• Hay dos segmentos de VTEP.
• La VXLAN 5001 abarca dos clústeres.
• NSX Controller es quien elige el UTEP en cada segmento de VTEP.
• ESXi-2 es el UTEP del segmento 10.20.10.0/24.
• ESXi-3 es el UTEP del segmento 10.20.11.0/24.

1. VM1 envía un broadcast (ARP Request) en busca de la dirección MAC de destino de VM2.

2. ESXi-1 (Source VTEP) mira su tabla de VTEP y observa que debe replicarla a todos los ESXi del mismo segmento VTEP y a cada UTEP de cada segmento VTEP remoto. Dado que hay solo dos segmentos, ESXi-1 encapsula la trama original de VM1 (el ARP request que en realidad es un broadcats) en un paquete UDP y replica ésta por unicast al VTEP de ESXi-2 (es el único VTEP local) y también es replicada al ESXi-3 (ya que este el UTEP del segmento remoto).

A modo de paréntesis, recordar la trama encapsulada de VXLAN:

Específicamente en el encabezado de VXLAN "VXLAN Flags" de 8 bits, un bit llamado "REPLICATE_LOCALLY" es usado para el UTEP. Continuando con la explicación del punto 2, cuando ESXi-1 envía la trama a ESXi-2, el bit REPLICATE_LOCALLY es cero dado a que el VTEP de ESXi-2 es local y no un UTEP remoto. Pero, cuando ESXi-1 envía la trama al UTEP remoto ESXi-3, el bit es "1" indicando al UTEP que esta trama proviene de un VTEP de un segmento remoto y que debe ser replicada localmente en su segmento de VTEP.

3. El UTEP del segmento remoto (ESXi-3) recibe la trama con el bit REPLICATE_LOCALLY = 1, revisa su tabla VTEP y la replica a todos los VTEPs de su segmento local.

4. Cada máquina virtual recibirá la trama ethernet original (desencapsulada por el VTEP) y solo responderá al broadcast aquella que coincida con la IP de destino contenida en el mensaje de ARP Request.

Conclusiones:

• La trama encapsulada de VXLAN fue entregada tanto a ESXi-2, ESXi-3 y ESXi-4 empleando Unicast.
• Cuando la trama encapsulada de VXLAN llegó a ESXi-2, éste la desencapsuló y entregó el broadcast a VM2. VM2 responde con un ARP Reply y el VTEP de ESXi-2 encapsula la trama y es enviada solo a ESXi-1.
• Cuando la trama encapsulada de VXLAN llegó a ESXi-3, éste la desencapsuló y envió el broadcast a VM3. VM3 la descarta ya que la IP de destino no es la de él. Sin embargo ESXi-2 es el UTEP de ese segmento remoto, así que la replicará a todos los VTEP del mismo segmento.
• Cuando la trama encapsulada de VXLAN llegó a ESXi-4, éste la desencapsuló y envió el broadcast a VM4. VM4 la descarta ya que la IP de destino no es la de él.

Observaciones:

Cambiando un poco el ejemplo, suponer que VM2 envía un ARP request en busca de la dirección MAC de destino de VM1. En este caso ESXi-2 es quien recibe la trama original de la máquina virtual y la debe encapsular para su envío. ESXi-2 revisa su tabla VTEP y replica la trama a ESXi-1 y al UTEP remoto. Lo interesante aquí es que el UTEP remoto no necesariamente debería ser ESXi-3, podría pasar que para este caso sea ESXi-4. NSX Controller elige los UTEP de forma local (al interior de los ESXi) e independientemente de cada ESXi.

En resumen:

Source VTEP

• Replica por medio de unicast la trama encapsulada a todos los VTEP del segmento VTEP local.
• Replica por medio de unicast la trama encapsulada al UTEP de cada segmento VTEP remoto.

Destination UTEP

• Es quien recibe la trama encapsulada del Source VTEP.
• Replica la trama encapsulada por medio de unicast a cada VTEP local de su segmento local.

Requerimientos:

• Red Física: Solo se necesita configurar una MTU de 1600 bytes. No es necesario IGMP Snooping ni PIM.
• El modo unicats puede ser configurado por VNI durante la creación del Logical Switch.

El modo híbrido es una combinación entre Multicast y Unicast. Este es también el método más recomendado por VMware. Aparte de una MTU de 1600, el método híbrido y a diferencia de unicast, si requiere una configuración especifica en la red física. Este modo también está basado en el NSX Controller, quien administra el plano de control en este caso.

Cuando el Modo Híbrido es seleccionado, la replicación local se hace por medio de Multicast (IGMP Snooping) pero para la replicación remota se emplea Unicast, eliminando la necesidad de emplear protocolos de enrutamiento multicast como PIM. NSX Controller elige un VTEP en cada segmento VTEP. A este VTEP se le conoce como "Proxy VTEP" y en el caso del modo Híbrido como MTEP "Multicast Tunnel End Point". Esta elección es por VNI.

Suponer que se tiene la siguiente red:

De la figura 14 se puede deducir que:

• Hay 4 VMs, todas conectadas a las misma VXLAN 5001.
• Hay 2 clúster. Cada uno con dos ESXi y distinto segmento de VTEP.
• Hay dos segmentos de VTEP.
• La VXLAN 5001 abarca dos clústeres.
• NSX Controller es quien elige el MTEP en cada segmento de VTEP.
• ESXi-2 es el MTEP del segmento 10.20.10.0/24.
• ESXi-3 es el MTEP del segmento 10.20.11.0/24.
• El grupo de multicast es 239.1.1.1.
• Cada uno de los ESXi ha enviado un mensaje de Reporte para unirse al grupo 239.1.1.1.

1. VM1 desea comunicarse con VM2 pero no conoce su dirección MAC de destino. VM2 envía un ARP Request solicitando esta información. Como ESXi-1, ESXi-2, ESXi-3 y ESXi-4 tienen al menos una máquina vitual en la VXLAN 50001 (VNI 5001), cada ESXi envía al switch físico (al swtich que los conecta a la red física) un mensaje de Reporte para unirse al grupo de multicast 239.1.1.1.

2. ESXi (Source VTEP) recibe la trama, observa su tabla VTEP y la encapsula con dirección IP de destino 239.1.1.1. La dirección IP de destino del campo "Destination Address" del "Outer IP Header" de la figura 13 es definida como 239.1.1.1 por el VTEP de ESXi-1 El switch físico recibe el paquete UDP y lo reenvía a todos los VTEPs del segmento local, en este caso, solo a ESXi-2 (ESXi-2 recibe la trama encapsulada con el bit REPLICATE_LOCALLY = 0).

3. En la tabla VTEP de ESXi-1 también se establece que debe replicar por medio de unicast esta trama al MTEP de cada segmento remoto (solo a ESXi-3 en este ejemplo). En este caso ESXi-3 recibe la trama encapsulada con el bit REPLICATE_LOCALLY = 1, indicándole que proviene de un VTEP remoto y que debe replicarla por medio de multicast a cada VTEP de su propio segmento local.

4. ESXi-3 replica por medio de multicast (al grupo 239.1.1.1) la trama encapsulada a cada VTEP del segmento local (solo ESXi-4 en este ejemplo).

5. Cada máquina virtual recibirá la trama ethernet original (desencapsulada por el VTEP) y solo responderá al broadcast aquella VM que coincida con la IP de destino contenida en el mensaje de ARP Request.

Conclusiones:

• La trama encapsulada de VXLAN fue entregada a ESXi-2 con multicast, a ESXi-3 con unicast y ESXi-4 con multicast.
• Cuando la trama encapsulada de VXLAN llegó a ESXi-2, éste la desencapsuló y entregó el broadcast a VM2. VM2 responde con un ARP Reply y el VTEP de ESXi-2 encapsula la trama y es enviada solo a ESXi-1.
• Cuando la trama encapsulada de VXLAN llegó a ESXi-3, éste la desencapsuló y envió el broadcast a VM3. VM3 la descarta ya que la IP de destino no es la de él. Sin embargo ESXi-2 es el MTEP de ese segmento remoto, así que la replicará a todos los VTEP del mismo segmento emplenado multicast.
• Cuando la trama encapsulada de VXLAN llegó a ESXi-4, éste la desencapsuló y envió el broadcast a VM4. VM4 la descarta ya que la IP de destino no es la de él.

Observaciones:

Cambiando un poco el ejemplo, suponer que VM2 envía un ARP request en busca de la dirección MAC de destino de VM1. En este caso ESXi-2 es quien recibe la trama original de la máquina virtual y la debe encapsular para su envío. ESXi-2 revisa su tabla VTEP y replica la trama a ESXi-1 y al MTEP remoto. Lo interesante aquí es que el MTEP remoto no necesariamente debería ser ESXi-3, podría pasar que para este caso sea ESXi-4. NSX Controller elige los UTEP de forma local (Al interior de los ESXi) e independientemente de cada ESXi.

En resumen:

Source VTEP

• Replica por medio de Multicast la trama encapsulada a todos los VTEP del segmento VTEP local.
• Replica por medio de unicast la trama encapsulada al MTEP de cada segmento VTEP remoto.

Destination MTEP

• Es quien recibe la trama encapsulada del Source VTEP.
• Replica la trama encapsulada por medio de multicast a cada VTEP local de su segmento.

Requerimientos:

• Red física: Los switches que conectan a los ESXi (a las tarjetas físicas mapeadas a los VTEPs) deben estar configurados con IGMP Snooping. De esta forma los mensjaes de report enviados por los VTEPs serán interpretados por la infraestructura física. Los routers no requieren PIM, ya que la replicación remota se hace por medio de unicast.
• Se requiere direccionamiento Multicast. En la figura 2 se debe especificar un rango para multicast.
• Se puede configurar por VNI durante la creación del Logical Switch.
• MTU 1600 bytes.

Modo Multicast

El modo multicast es quizás el tipo de replicación más compleja de mantener. Aparte de una MTU de 1600 bytes, requiere una configuración de IGMP Snooping pero también de PIM con el fin de enrutar el tráfico de multicast. Este modo es totalmente independiente del NSX Controller, ya que no se elegirán VTEP proxy en segmentos VTEP remotos, por lo tanto, multicast está basado en el plano de datos y no en el de control.

En el modo multicast el tráfico local y remoto es replicado utilizando multicast. No existen los roles de UTEP o MTEP, ya que el protocolo PIM es utilizado para replicar de forma remota.

Suponer que se tiene la siguiente red:

De la figura 15 se puede deducir que:

• Hay 3 VMs, todas conectadas a las misma VXLAN 5001.
• Hay 2 clúster. Cada uno con dos ESXi y distinto segmento de VTEP.
• Hay dos segmentos de VTEP.
• La VXLAN 5001 abarca dos clústeres.
• NSX Controller no juega un papel en este caso.
• El grupo de multicast es 239.1.1.1.

ESXi-1, ESXi-2 y ESXi-3 tienen al menos una VM encendida en la VXLAN 5001, por lo tanto, el VTEP de cada ESXi envía un mensaje de IGMP a los switches físicos para unirsen al grupo 239.1.1.1. ESXi-4 no envía ningún mensaje ya que no tiene máquinas vituales encendidas en esa VXLAN.

Si la VM1 desea comunciarse con la VM2 y no conoce la dirección MAC de destino, enviará un ARP request (broadcast) y el flujo y tipos de mensajes de la figura 15 se vería ahora de la siguiente forma:

1. VM1 envía un ARP Request en busca de la dirección MAC de destino de VM2.

2. ESXi-1 recibe la trama original (broadcast de VM1) y la encapsula. La dirección IP de destino del campo "Destination Address" del "Outer IP Header" de la figura 13 es definida como 239.1.1.1 por el VTEP de ESXi-1.

3. El switch físico recibe el paquete multicast y lo replica por medio de IGMP snooping a todos los VTEPs conectados al grupo 239.1.1.1 (en este caso solo a ESXi-2 y la interfaz del router conectada al swtich físico).

4. El router recibe la trama y la enruta por medio de PIM a la red 10.20.11.0/24.

5. El switch físico recibe la trama encapsulada y la replica a todos los VTEPs conectados a 239.1.1.1 (en este caso solo a ESXi-3).

6. Cada máquina virtual recibirá la trama ethernet original (desencapsulada por el VTEP) y solo responderá al broadcast aquella VM que coincida con la IP de destino.

Conclusiones:

En resumen:

Source VTEP

Replica por medio de Multicast la trama encapsulada a todos los VTEP del segmento VTEP local y remoto.

Destination

El modo multicast no tiene los roles de UTEP y MTEP.

Requerimientos:

• Red física: Los switches que conectan a los ESXi (a las tarjetas físicas mapeadas a los VTEPs) deben estar configurados con IGMP Snooping. De esta forma los mensjaes de report y query enviados por los VTEPs serán interpretados por la infraestructura física. Los routers requieren PIM. Re recomeinda PIM bidireccional.
• Se requiere direccionamiento Multicast. En la figura 2 se debe especificar un rango para multicast.
• Se puede configurar por VNI durante la creación del Logical Switch.
• MTU de 1600 bytes.

Nota final: Tener en cuenta que cada vez que se mencionaba la palabra "encapsula o encapsular" se hace referencia al proceso que lleva a cabo un VTEP. El VTEP toma la trama ethernet original de la máquina virtual (en todos los ejemplos era un ARP Request) y lo encapsulaba en una trama VXLAN como el de la figura 13. Por otro lado, desencapsular hace referencia al VTEP que recibe la trama y elimina todos los encabezados a excepción del "Inner L2 Header and Payload de la figura 13″, el cual es en realidad la única información que le interesa a la máquina virtual de destino. Tener presente que VXLAN es transparente para las máquinas virtuales.

Pata finalizar, la siguiente tabla muestra la diferencia entre cada modo de replicación:

NSX Controller

Basado en NSX Controller

Basado en NSX Controller

No basado en NSX Controller

VTEP Proxy Role?

NSX Controller elige un UTEP por cada segmento

NSX Controller elige un MTEP por cada segmento

No existe el rol de VTEP Proxy

IGMP Snooping

No es necesario

Es necesario

Es necesario

PIM

No es necesario

No es necesario

Es necesario

Source VTEP

Replica por medio de unicast la trama encapsulada a todos los VTEP del segmento VTEP local.
Replica por medio de unicast la trama encapsulada al UTEP de cada segmento VTEP remoto.

Replica por medio de Multicast la trama encapsulada a todos los VTEP del segmento VTEP local.
Replica por medio de unicast la trama encapsulada al MTEP de cada segmento VTEP remoto.

Replica por medio de Multicast la trama encapsulada a todos los VTEP del segmento VTEP local y remoto.

Destination Proxy

Es el UTEP. Es quien recibe la trama encapsulada del Source VTEP.
Replica la trama encapsulada por medio de unicast a cada VTEP local de su segmento local.

Es el MTEP. Es quien recibe la trama encapsulada del Source VTEP.
Replica la trama encapsulada por medio de multicast a cada VTEP local de su segmento.

El modo multicast no tiene los roles de UTEP ni MTEP.

En el próximo post se verá acerca de los Logical Switchs.

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 las VXLAN

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