VMware NSX – Introducción a las VXLAN

Publicado el 16 enero 2015 por Pipearaque

Hola que tal

Por años la tecnología de las VLANs han suplido distintas necesidades a nivel de seguridad, segmentación/aislamiento, reducción del broadcast y administración. Hoy en día siguen siendo ampliamente utilizadas por pequeñas, medianas y grandes empresas en todo el mundo; sin embargo, para algunos tipos de negocio el número de VLANs disponibles es pequeño. Por citar un caso se puede observar a los Proveedores de Servicios de Nube. Para un proveedor de este tipo, el cual puede llegar a tener muchos clientes y cada uno de estos distintas redes, 4096 VLANs o redes es poco. Aquí es cuando entra a jugar la VXLAN en cuyo caso permite más de 16 millones de segmentos de red.

VXLAN

VXLAN es una tecnología tipo "Overlay Network". Por Overlay Network se entiende como una red lógica creada encima de una red física existente. En algunos casos incluso puede ser independiente de la red física. Para que una red sea catalogada "Overlay Network" debe cumplir con lo siguiente:

  • Ser una red lógica.
  • Contar con un proceso de encapsulación/desencapsulación.
  • Comunicación desarrollada entre un túnel establecido por dos terminales.

VXLAN cumple con estas tres consideraciones:

  • Ser una red lógica: VXLAN por sus siglas en inglés "Virtual Extensible Local Area Network" es una tecnología que permite segmentar las redes de forma virtual/lógica.
  • Contar con un proceso de encapsulación/desencapsulación: VXLAN encapsula la trama Ethernet original (la trama ethernet de la máquina virtual) en un paquete UDP.
  • Comunicación desarrollada entre un túnel establecido por dos terminales: En VXLAN el encargado de encapsular y desencapsular las tramas ethernet de las máquina virtuales es el VTEP "Virtual Tunnel Endpoint". El VTEP es un vmkernel port en un ESXi. Cada Host (en realidad clúster) que desee participar en una red VXLAN deberá tener el VTEP (vmkernel port) instalado y funcionando.

VXLAN aunque no ha sido estandarizada ya ha sido enviada a la IETF para su estandarización. Fue desarrollada inicialmente por varias compañías, como VMware, Arista Networks y Cisco.

VXLAN permite en si extender redes de capa 2 a través de los límites de red de capa 3. Mediante la encapsulación, VXLAN permite ampliar el número de redes de capa 2, empleando un Identificador de Red Virtual ó VNI "Virtual Network Identifier", el cual tiene una longitud de 24 bits. Con 24 bits se puede tener hasta 16'777.216 de redes lógicas, mucho mayor que las 4096 proporcionadas por las VLAN.

Dada la anterior introducción es hora de profundizar en cada concepto. Se comenzará por los VTEP.

VTEP: Virtual Tunnel End Point

VTEP es el encargado de encapsular y desencapsular el tráfico de las máquinas virtuales en paquetes o encabezados UDP.

Nota: Para una máquina virtual las VXLAN serán totalmente trasparentes.

A continuación suponer que se tiene dos Cluster (A y B). En el Cluster A ha sido configurada la VLAN X y el Cluster B la VLAN Y.

Como se puede ver en la figura 1 no existe configuración de VXLAN. Para que las máquinas virtuales de la VLAN X del cluster A logren comunicarse con las máquinas virtuales de la VLAN Y del cluster B es necesario contar con un router que interconecte ambos cluster.

Nota: Notar que hay dos redes distintas (VLAN X y Y).

Al configurar VXLAN, la figura 1 ahora se vería de la siguiente forma:

En este caso ya no es necesario contar con un router. Las máquinas virtuales del cluster A y del B pueden estar en la misma red de capa 2 (mismo dominio de broadcast de capa 2). Las VLANs no son necesarias ya que la VXLAN en si está garantizando el aislamiento.

Nota: VXLAN Wire es una representación lógica de la conexión entre dos VTEPs.

Nota: Vale la pena resaltar que VXLAN solo encapsula y de ninguna manera cifra la información.

En un post anterior sobre los planos de NSX se explicó que, VMware NSX Manager instala tres VIB "vSphere Installation Bundles" en los ESXi en un proceso conocido como "Host Preparation". Los VIBs son:

  • VXLAN.
  • Dsitributed Logical Router.
  • Distributed Firewall.

Nota: Estos VIBs son instalados directamente en el ESXi. También se conocen como "Hypervisor Kernel Modules".

En cuanto a VXLAN se refiere, NSX Manager prepara los ESXi instalando y configurando en éstos los VTEPs. Los pasos para realizar esta labor son los siguientes:

Paso 1: Conectado a vCenter Server con el Web Client, ir a Home, Inventories, Networking and Security:

Paso 2: En la barra lateral izquierda, seleccionar "Installation" y luego en "Host Preparation":

Nota: En "Installation Status" notar que la opción es "Install". Esto significa que el Clúster Gold no tiene aún instalado los tres módulos de Kernel (VXLAN, Logical Distributed Router y Logical Distributed Firewall). Notar también que no da la opción de escoger un ESXi en particular; en vez de eso se debe seleccionar es en qué Clústeres se desea instalar los módulos.

Paso 3: Para cada Clúster de interés, clic en "Install". Se podrá monitorear el estado de la instalación en "Installation Status":

La clave para saber si la instalación finalizó consiste en observar el "Installation Status"; cuando este esté en "Unistall" significa que se encuentra listo.

Notar en la figura 6 que la opción "Configure" de VXLAN está ahora habilitada.

Trama VXLAN

VTEP es el encargado de encapsular y desencupsular la trana ethernet original de las máquina virtuales. A continuación se detallará en qué consiste este proceso de encapsulación.

La siguiente es la trama XVLAN para IPV4:

Nota: En la figura 7 se puede apreciar dos conceptos "Inner y Outer". Inner hace referencia a la trama ethernet original, es decir, la trama que envía una máquina virtual. Por otro lado Outer establece los campos/encabezados que estará instalando el VTEP dentro del proceso de encapsulación.

De izquierda a derecha:

Inner L2 Header and Payload: Esta es la trama original Ethernet de capa 2 de la máquina virtual. Sus campos son:

  • Destination Address (4 bytes): Dirección MAC de destino (dirección MAC a quién va dirigida la trama) con la cual la máquina virtual de origen se desea comunicar. Esta dirección puede ser la MAC de un dispositivo físico o virtual siempre y cuando la IP de destino esté en la misma red que la máquina de origen. También podría ser la MAC del default geteway si la dirección IP de destino está en otra red.
  • Source Address (4 bytes): Esta es la dirección MAC de la máquina virtual que envía la trama.
  • VLAN Type 0x8100 (2 bytes): Solo sí esta máquina virtual de origen se encuentra en un grupo de puertos de máquina virtual configurado con una VLAN, el switch virtual (sea el Standard o Distrbuted) debe colocar un Tag, cuyo valor puede variar entre 1 y 4094. En caso de ser así, en la trama ethernet original VMware debe agregar un campo de 2 bytes justo despúes del "Source Address". Este campo siempre será 0x8100 (cuatro dígitos hexadecimales lo que equivale a 16 bits) indicando que la trama ethernet ha sido modificado para llevar un VLAN ID, es decir, una VLAN. Por otro lado, si la máquina virtual se encuentra conectada a un grupo de puertos de máquina virtual que no precisa de un tag, es decir que el valor del VLAN es cero, el grupo de puertos no coloca un tag a la trama de la máquina virtual y este campo no se empleará. En conclusión, este campo es opcional y podría o no emplearse dependiendo si las VLANs son o no utilizadas.
  • VLAN ID (2 bytes): El campo de VLAN ID está compuesto por tres campos; User Priority con 3 bits, CFI con 1 y finalmente VLAN ID con 12. La función de User Priority es la de proporcionar QoS o calidad de servicio de capa 2, también conocido como Class of Service. Al tener 3 bits establece 8 posibles valores para QoS. CFI o "Canonical Format Indicator" es un campo que ayuda a identificar si los 12 bits siguientes de VLAN ID son para el protocolo Ethernet o Token Ring. Si este valor es "0" significa que es Ethernet. Si es "1" es Token Ring. El último campo, VLAN ID, se emplea para identificar la VLAN (Tag). Al tener este campo 12 bits da la posibilidad de tener hasta 4096 VLANs.
  • Ethernet Type 0x0800 (2 bytes): Este campo indica el tipo de protocolo que contiene los Datos o Payload. Si los datos o payload están basados en IPv4, este campo será 0x0800. Si fuese por ejemplo IPv6 sería entonces 0x86DD.
  • Payload o Datos (1500 bytes): Aquí viene los datos que entrega la capa 3 o capa de red. Recordar que la capa de red del modelo OSI se encarga de fragmentar los datos. Los fragmentos tendrán un tamaño igual a la MTU, es decir, 1500 bytes. La MTU solo significa la cantidad de información que Ethernet podrá transportar sin importar cuál es el header o el Trailer de capa 2. Finalmente clarificar que los fragmentos de 1500 bytes que crea la capa de red no contiene el paquete IP entero, es solo los datos.
  • FCS (4 bytes): FCS o "Frame Check Sequence" es el encargado de hacer el CRC o código de reduncia cíclica. Este campo se encarga de velar por la integridad de la información.

VXLAN Header:

Outer UDP Header: Estos campos tienen como propósito especificar información de capa 4 o capa de transporte para los VTEPs.

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

    Misc Data (9 bytes): Son una combinación de varios campos, tales como:

- Versión (4 Bits): Si este valor es 4 significa que la versión de IP es IPv4. De no ser así simplemente no es IPv4.

- IHL (4 bits): IHL o "Internet Header Length" se encarga de avisar si el campo de "Options" será o no utilizado.

- Type of Service (1 byte): Permite establecer calidad de servicio de capa 3, también conocido como DSCP "Differentiated Services Code Point".

- Total Length (2 bytes): Este campo establece el tamaño total del paquete, incluyendo el header. Este valor en el caso de IPv4 es de 20 Bytes.

- Time to Live (1 byte): Time to Live o TTL es el encargado de eliminar bucles de capa 3.

- Options (3 bytes): Permite ampliar las opciones de IPv4.

- Padding (1 byte): Este campo se encarga de garantizar que la longitud del paquete sea múltiplo de 32.

Nota: Los campos Identification, Flags y Fragment offset no son empleados por la tecnología de VXLAN. Los VTEPs no desfragmentan la información.

Outer Mac Header: Estos campos tienen como propósito especificar información de capa 2 o capa de enlace de datos acerca de los VTEPs.

  • Destination Address (4 bytes): Dirección MAC de destino (dirección MAC del VTEP a quien va dirigida la trama) con la cual el VTEP de origen se desea comunicar. Puede suceder que la comunicación sea local, es decir en la misma red. También podría pasar que el destino se encuentre en otra red. En este caso la dirección MAC podría ser de un dispositivo de capa 3 que se encargue de enrutar el tráfico de Multicast (PIM Protocol) o de un VTEP Proxy. De esto se hablará en el siguiente Post.
  • Source Address (4 bytes): Esta es la dirección MAC del VTEP que enviará la trama.
  • VLAN Type 0x8100 (2 bytes): Es opcional en VXLAN. Podría ser que una o varias VXLAN viaje a través de una VLAN. De ser así, si el vmkernel port del VTEP especifica una VLAN, 0x8100 dictará que los siguientes 12 bits son el VLAN ID.
  • VLAN ID (2 bytes): De nuevo, utilizar VLAN es opcional en una implemnentación de VXLAN. De ser empleado el valor de la VLAN irá en este campo.
  • Ethernet Type 0x0800 (2 bytes): Este campo indica el tipo de protocolo que VTEP empleará en capa 3. Si VTEP emplea IPv4, este campo será 0x0800.

La siguiente es la trama de VXLAN para IPv6:

Es muy importante notar que en la figura 7, en el caso de IPv4, el tamaño total es de 1564 bytes sin emplear VLANs y de 1572 bytes con VLANs. En el caso de IPv6 sin VLAN es de 1592 bytes y 1600 bytes con VLANs. El peor escenario es de 1600 bytes. VMware recomienda que de ser empleado IPv4 ó IPv6, con o sin VLANs, la MTU para VXLAN debe ser configurada con un valor de 1600 bytes. La red física debe ser acondicionada con este valor, de lo contratio VXLAN no funcionará.

De la figura 8 solo es necesario explicar el siguiente campo:

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

    Misc Data (7 Bytes): Contiene una serie de campo, descritos a continuación:

- Versión (4 bits): Este campo siempre tendrá como valor 6, especificando que la versión de IP es IPv6.

- Class of Traffic (1 byte): Permite establecer calidad de servicio de capa 3, también conocido como DSCP "Differentiated Services Code Point".

- Flow Label (20 bits): Permite marcar el paquete por el VTEP de origen para que los dispositivos como Routers le den un tratamiento especial.

- Payload Length (2 bytes): El tamaño del Payload en bytes.

- Hop Limit (1 byte): Este campo reemplaza al campo de TTL de IPv4.

Configuración de VXLAN en los ESXi

Para la configuración de VXLAN en los ESXi seguir los siguientes pasos:

Paso 1: En la figura 6 dar clic en "Configure".

Paso 2: Configurar la red de VXLAN:

  • Switch: Seleccionar el Switch Distribuido en dónde se creará el vmkernel port para los VTEP.
  • VLAN: Especificar si se utilizará una VLAN para transportar el tráfico de VTEP. Si este valor es cero "O" significa que no hay tag y el tráfico de las VTEPs serán pasadas por la VLAN nativa de los switches físicos. De ser requerido la confgiruación de VLAN, el rango permitido es de 1 a 4094.
  • MTU: Máxima Unidad de Trasnferencia. VMware recomienda configurar el MTU en 1600 bytes, con el fin de acomodar los campos adicionales que conlleva la encapsulación de la trama original de ethernet. Recordar que a la red subyacente también se debe cambiar la MTU.
  • VMKnic IP addresing: VMware proporciona dos formas de dar dirección IP a los vmkernel ports que emplearán las VTEP. Una opción es emplear DHCP. En caso de optar por esta configuración, un servidor DHCP debería existir en la red. La segunda opción consiste en crear un Pool de direcciones para ser entregadas a las VTEP.
  • VMKnic Teaming Policy: Permite especificar la política de balanceo de carga en el grupo de puertos vmkernel de las VTEP. Si se requiere dotar con alta disponibilidad al tráfico de VTEP, una opción es contar con dos tarjetas físicas atadas al grupo de puertos de VTEP y configurar la política de balanceo que más se ajuste a las necesidades actuales.
  • VTEP: En este campo se puede especificar el número de VTEPs por ESXi.

Si la configuración incluye un pool para VTEP, la siguiente figura muestra qué valores pueden ser configurados:

Paso 3: Verificación.

Para la verificación basta con observar el estado del campo VXLAN:

También se podrá verificar si los ESXi recibieron dirección IP:

Otra forma de verificar la configuración es ir directamente al switch distribuido:

En el siguiente Post se verá:

  • Zonas de transporte.
  • Modos de replicación.
  • Tipos de VTEP.

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

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


Tags: VMware NSX