NSX: Introduccion a VXLAN

/, Software Defined Datacenter, VMware, VXLAN/NSX: Introduccion a VXLAN
[Total: 1    Average: 5/5]

Hola a todos!

En el post anterior hicimos una “breve” introducción a las Software Defined Network, y a los que nos ofrece vSphere NSX.  Continuando con lo ya visto, es momento de profundizar acerca de VXLAN.

En primer lugar, porque necesitamos VXLAN?  Hasta ahora, para aislar y segmentar trafico, así como también para limitar los dominios de broadcast, hemos utilizado nuestras queridas VLANs (802.1Q), y ha funcionado bastante bien no?  Bueno, con las VLANs tenemos un par de limitaciones que vale la pena revisar para comprender la necesidad de las VXLAN.

  • Por su diseño, al utilizar el estándar 802.1Q, las redes están limitadas a un máximo de 4096 VLANs, es decir, un máximo de 4096 segmentos de red.  Esto puede parecer suficiente para muchas empresas pequeñas y medianas, pero las grandes compañías, incluyendo a proveedores de servicios en la nube (múltiples clientes, cada uno con múltiples redes), podrían encontrar que estas 4096 VLANs no son suficientes para los distintos segmentos de red requeridos.
  • Las VLANs fueron diseñadas para ser implementadas en redes físicas.  Es decir, que su configuración y administración es realizada principalmente en los dispositivos físicos de la red corporativa.  Es cierto que en vSphere los Virtual Switches pueden hacer uso de las VLANs, pero solo de las VLANs ya existentes en la red física, es decir, desde vSphere no podemos definir nuevas VLANs sin intervención en los dispositivos de red física.
  • Debido a lo anterior, las VLANs no permiten automatizar la provisión de redes, lo cual es crucial en una plataforma de Cloud.
  • Del mismo modo, las VLANs al estar definidas en la capa de hardware, no encaja con el concepto de Software Defined Network.

Debido a lo anterior, varias compañías, entre ellas VMware y Cisco se pusieron de acuerdo para crear un nuevo Standard para segmentación de redes, cuyo diseño estuviera orientado al Software Defined Datacenter y al Cloud Computing.  De aqui surgió VXLAN, el cual utiliza un espacio de direcciones de 24 bit, lo que permite aproximadamente 16 millones de redes VXLAN, siendo cada red VXLAN una red lógica aislada.  Este aislamiento es muy similar al que se obtiene con el uso de las VLANs, pero con una escalabilidad claramente superior.

VXLAN es una tecnologia overlay “Ethernet-in-IP”, donde el frame Layer 2 original generado por una MV, es encapsulado en un paquete UDP y reenviado sobre una red de transporte.  Esta tecnologia permite extender las redes L2 a través de los limites de L3.

VXLAN tiene una serie de ventajas, que permiten que sea ideal para implementar el concepto de Software Defined Network:

  • La creación de segmentos VXLAN es realizada integramente en la capa de software, es decir en NSX.
    • Para esta tarea, no se requiere de ninguna intervención en la infraestructura de red fisica.
    • Un segmento VXLAN es representado por un Logical Switch.
    • La comunicación L2 entre máquinas virtuales en un mismo host se realiza sin salir a la red fisica.
    • La comunicacion L2 entre máquinas virtuales en distintos hosts se realiza utilizando la red de transporte VXLAN como canal de comunicacion.
    • La creación de segmentos VXLAN puede ser automatizada al integrar NSX con vRealize Automation.
  • VXLAN permite la implementación de servicios L2 a L7, como Firewall, NAT, VPN, Load Balancing, etc., a nivel de software a traves de NSX, sin requerir intervención en la red fisica.
  • El routing entre maquinas virtuales que se encuentran en distintos segmentos de VXLAN (comunicacion este-oeste) se realiza utilizando un componente conocido como Distributed Logical Router (ya hablaremos de eso).
    • En ningun caso será necesario conectarse con un dispositivo L3 en la red fisica para el routing de este trafico.
    • Si ambas máquinas virtuales se encuentran en el mismo host, la comunicacion se realiza sin salir a la red fisica.
    • Si las maquinas virtuales se encuentran en hosts distintos, entonces la comunicacion se lleva a cabo encapsulando los frames y transmitiendolos a traves de la Red de transporte VXLAN, de manera de llegar al host que contiene la maquina virtual de destino.
    • En todos los casos, la red de transporte VXLAN es utilizada simplemente como un Backplane IP, donde no requiere VLANs, ACLs, reglas de Firewall, etc.
  • Es posible conectar maquinas virtuales que pertenezcan a un segmento VXLAN con la red fisica o con cualquier red fuera del dominio VXLAN (comunicacion norte-sur) utilizando un componente conocido como NSX Edge (tambien es materia de otro post).
  • El uso de VXLAN simplifica dramaticamente la gestión de los segmentos de red y el routing, a la vez que elimina la necesidad de realizar cambios a la red fisica cuando nos encontramos en el proceso de provisionamiento de un segmento de red.

Dentro de los requerimientos para VXLAN, principalmente debemos asegurarnos de que la red de transporte VXLAN soporte MTU para un mínimo de 1600 bytes, para que cada frame incluya la cabecera VXLAN.  Este requerimiento se debe a que VXLAN agrega de 50 a 54 bytes de información a los frames generados por las MVs, dependiendo de si se usa VLAN tagging.

Virtual Tunnel End Point

Para que VXLAN, y por ende NSX, pueda operar, se debe implementar una red de transporte VXLAN.  Esta red de transporte VXLAN es creada utilizando lo que se conoce como VTEP (Virtual Tunnel End Point).  Cada host debe tener al menos un VTEP, el cual no es más que un puerto VMkernel, similar a los que hasta ahora hemos utilizado para vMotion, FT, etc.   

Captura de pantalla 2015-11-05 22.17.15Estos VTEP no lo podemos crear manualmente, sino que se crea automáticamente al momento de configurar un host para utilizar VXLAN, proceso que detallaremos en otro post.

Durante la configuración de VXLAN, y por ende, durante la creación de los VTEPs, los puertos vmkernel son creados sobre un Distributed Port Group.  Esto implica que el uso de Distributed Virtual Switch es obligatorio.

Para la conectividad entre los VTEP no es mandatorio contar con una red Layer 2 end-to-end, es decir, no es necesario que los VTEPs de todos los hosts se encuentren en el mismo segmento de red para poder crear la red de transporte VXLAN.

Para efectos de escalabilidad, de hecho es recomendado que los VTEPs se encuentren configurados en distintos segmentos IP cuando los hosts se encuentran en distintos racks. La recomendación es que el segmento L2 para los VTEP no se extienda más allá de los switches Top-of-rack.

Un VTEP entonces es una interfaz VMkernel, y sus funciones principales son:

  • Crear una red de transporte VXLAN (tunel) entre hosts ESXi.
  • Encapsular un frame Ethernet en un frame VXLAN y reenviarlo al VTEP del host de destino.
  • Desencapsular un frame VXLAN y reenviar el frame Ethernet desencapsulado a la MV de destino.

Captura de pantalla 2015-11-05 21.43.10Para poder entender un poco mejor las ventajas que nos provee VXLAN y los VTEPs, veamos lo que sucede con el trafico en un ambiente SIN VXLAN.

  • En primer lugar, cuando 2 MV que se encuentran en dos hosts distintos desean comunicarse entre si, este trafico obligatoriamente pasa por la red fisica.  Esto es lo esperable y en general no representa mayor problema.  Este trafico lo podemos ver representado en la imagen, con la linea en color rojo.
  • Cuando 2 MVs que se encuentran en segmentos de red distintos, por ejemplo en VLANs distintas, desean comunicarse entre si, este trafico obligatoriamente debe pasar por un dispositivo L3 para ser enrutado desde un segmento a otro (trafico en amarillo).  Esta es la situación que nos encontramos usualmente en plataformas virtuales, e implica que la configuración de red fisica debe realizarse en forma separada y no-integrada con la configuración de vSphere y las redes virtuales.

Veamos entonces como los VTEPs realizan el proceso de encapsulación, y como cambia el proceso de comunicación entre las máquinas virtuales cuando utilizamos NSX.

Encapsulación y Desencapsulación con VXLAN

Como ya mencionamos antes, una de las funciones principales de los VTEP es la de encapsular un frame Ethernet en un frame VXLAN, y posteriormente des-encapsularlo en el host de destino, lo cual facilita la comunicación entre redes logicas sin importar las caracteristicas de la red fisica subyacente.

Captura de pantalla 2015-11-05 20.40.25Lo que hacen entonces los VTEPs es crear un tunel VXLAN entre los hosts ESXi.  Como vemos en esta imagen, el proceso es el siguiente:

  • Una MV envia una frame a otra MV en el mismo segmento de red, o en uno distinto.
  • El VTEP del hypervisor de la MV de origen encapsula el frame, agregando cabeceras VXLAN, IP y UDP.
  • El frame encapsulado es reenviado a traves de la red fisica, especificamente a traves de la red de transporte VXLAN.
  • El VTEP del hypervisor que contiene la MV de destino, recibe el frame y lo desencapsula.
  • El frame original entonces es entregado a la MV.

Captura de pantalla 2015-11-05 22.09.14Este proceso aplica para el trafico entre máquinas virtuales, ya sea que estas se encuentren en la misma red L2, o en segmentos L2 distintos.  En ningun caso se requiere de un dispositivo L3 en la red fisica para esta comunicación, utilizando la red fisica solo para la red de transporte de VXLAN (comunicacion entre VTEPs).  Con VXLAN y NSX, todo el proceso de routing es realizado por dos componentes que detallaremos en profundidad en futuros posts, y que estan controlados enteramente por software:

  • Distributed Logical Router, optimizado para el trafico Este-Oeste
  • NSX Edge, optimizado para el trafico Norte-Sur

Captura de pantalla 2015-11-05 22.35.21En la siguiente imagen podemos ver en detalle el frame ethernet encapsulado en VXLAN que mencionamos más arriba, donde describiremos brevemente cada una de sus partes.

En primer lugar, vemos que el frame esta dividido en dos secciones principales.  “Inner” que se refiere al frame ethernet original generado por la maquina virtual, y “Outer” que se refiere a los encabezados añadidos por los VTEP durante el proceso de encapsulación del frame.

Detallemos primero las secciones del frame ethernet original generado por la maquina virtual, el Inner Ethernet Frame.

  • Destination MAC: MAC Address de destino del frame, es decir, a quien va dirigido. Corresponde a la MAC Address de la maquina virtual con la que se desea comunicar, pudiendo ser de un dispositivo fisico o virtual.  La Destination MAC podría corresponder también a la MAC del Default Gateway, en caso de que la IP de destino se encuentre en otro segmento, recordando que las MAC Address estan limitadas por los dominios de broadcast.
  • Source MAC: MAC Address de la maquina virtual que está enviando el frame.
  • EtherType: Permite indicar el tipo de frame
    • 0x0800: Frame IPv4
    • 0x86DD: Frame IPv6
    • 0x0806: Frame ARP
    • 0x8100: Frame 802.1Q (VLAN)
  • Payload: Contenido del frame, es decir los bytes de datos.  La cantidad de datos incluidos en el frame depende del tamaño del MTU definido, el cual por defecto es de 1500 bytes, a los cuales se les debe restar los bytes requeridos por los demás campos de la cabecera.  Lo usual es que los primeros 42 a 46 bytes (depende del uso o no de VLAN) queden reservados para la cabecera, dejando el resto disponible para el payload.
  • FCS (Frame Check Sequence”): Es el CRC (codigo de redundancia ciclica) que permite la detección de datos corruptos dentro del frame.  Se ejecuta un algoritmo CRC para verificar la integridad de los datos recibidos.

Veamos ahora los campos que conforman el Outer Ethernet Frame:

VXLAN Header:

  • VXLAN Flags : Son banderas utilizadas por VXLAN para efectos de replicación, es decir, como será tratado el trafico BUM (Broadcast, Unknown Unicast, Multicast)
  • Reserved: Campo reservado, sin uso actual
  • VNI – VXLAN Network Identifier:  Este campo es el que contiene el identificar de red dentro de VXLAN, permitiendo identificar a que VXLAN pertenece el frame. Como ya mencionamos anteriormente, en VXLAN los VNI son identificadores de 24 bits, lo que permite contar con más de 16 millones de posibles redes, en comparación al limite de 4096 VLANs.
  • Reserved: Campo reservado, sin uso actual.

Outer UDP Header: Campos con información asociada a los VTEPs.

  • Source Port: Puerto escogido por el VTEP del host de origen, es decir, el VTEP que realizará la encapsulación del frame ethernet original generada por la maquina virtual.  Este puerto es calculado utilizando un algoritmo hasg sobre el header del frame ethernet original.
  • Dest Port: Por defecto NSX utiliza el puerto 8742, siendo este el puerto a utilizar al momento de conectarse con el VTEP de destino.
  • UDP Length: Longitud de bytes del header UDP
  • UDP Checksum: El VTEP que enviará el frame establece el valor de esta campo, el cual debe ser 0x000.  El VTEP que recibe el frame verifica que este campo incluya ese valor exacto, de lo contrario el frame será descartado (drop) y no se realizará ninguna des-encapsulación.

Outer IP Header: Estos campos tienen como propósito especificar información de capa 3 o capa de red acerca de los VTEPs.

  • IP Header Data: Este campo esta compuesto de multiples otros campos, los cuales permiten definir información como:
    • Protocolo: Comunmente IPv4 o IPv6.
    • Header Length: Longitud de la cabecera IP.
    • Time to Live (TTL): Campo de 8 bits que evita que los datagrams vayan en circulos o loops.  Este campo limita el tiempo de vida de los datagrams en segundos.  En la practica, este campo es un contador de saltos, es decir, cada vez que el datagram llega a un router, el router reduce el valor del TTL en 1.  Cuando el TTL llega a 0, el router descarta el paquete.
  • IP Protocol: Indica el protocolo utilizado por la capa de transporte.  VXLAN, como ya mencionamos previamente, utiliza UDP como protocolo en la red de transporte.
  • Header Checksum: Campo que permite verificar la integridad de los datos.
  • Outer Source IP:  Aqui se especifica la dirección IP del VTEP de origen, es decir, del VTEP que se encargará de encapsular el frame original.
  • Outer Destination IP: Aqui se especifica la dirección IP del VTEP de destino, es decir el VTEP que recibirá el frame encapsulado y lo des-encapsulará para poder entregarlo a la maquina virtual.

Outer Ethernet Header: Información Layer 2 acerca de los VTEPs.

  • Destination Address: Dirección MAC del VTEP de destino que deberá recibir el frame encapsulado. La Destination MAC podría corresponder también a la MAC del Default Gateway, en caso de que la IP del VTEP de destino se encuentre en otro segmento, recordando que las MAC Address estan limitadas por los dominios de broadcast.
  • Source Address: MAC Address del VTEP de origen, que encapsulará y enviará el frame.
  • Optional Type: Campo opcional que indica si la red de los VTEP utilizará VLANs.
  • Outer 802.1Q: De utilizar VLAN en la configuración de la red de los VTEP, el valor de la VLAN irá en este campo.
  • Ethernet Type Indica el protocolo empleado por la red de los VTEP, por ejemplo, IPv4.

Espero les haya sido de interes.  En los proximos posts estaremos detallando lo siguiente

By | 2017-07-05T18:45:57+00:00 November 6th, 2015|NSX, Software Defined Datacenter, VMware, VXLAN|3 Comments

About the Author:

3 Comments

  1. […] NSX: Introducción a VXLAN […]

  2. […] los últimos posts he hablado un poco de NSX e hicimos una introducción a VXLAN. Bueno, siguiendo esa linea, vamos a profundizar un poco sobre VXLAN y los modos de replicación […]

  3. idiggo.com August 31, 2017 at 02:50 - Reply

    🙂

    Que tiempo has dedicado a tremendo a porte y hay muchas cosas que no conocía
    que me has enseñado, esta genial.. te quería corresponder el tiempo que dedicaste, con unas infinitas
    gracias, por instruir a personas como yo jajaja.

    Besos, saludos

Leave A Comment

EnglishPortugueseSpanish