SDN: ¿Qué es VXLAN y como funciona?

      3 Comments on SDN: ¿Qué es VXLAN y como funciona?

Con la llegada de las redes definidas por software (SDN) se nos ha venido un montón de tecnologías nuevas, protocolos, aplicaciones y soluciones que debemos no solamente aprender, sino saber implementar de acuerdo a los requerimientos de un cliente o según las necesidades de una organización. Una de estas tecnologías es VXLAN o “Virtual eXtensible LAN” y en este artículo veremos de qué se trata y bajo qué escenario conviene implementarla (para facilitar la lectura, al final del artículo dejaré un mini glosario con los términos que pueden ser difíciles de comprender y aquellos conceptos nuevos que se utilizan con VXLAN).

Las infraestructuras en la nube (pública, privada o híbrida) y los datacenters son geniales. Nadie lo puede negar. Es simplemente extraordinario poder levantar una infraestructura completa con un par de clicks y desecharla así de rápido si no te gusta. En el mundo de IaaS (Infrastructure-as-a-Service) es posible hacer esto de manera muy simple para el usuario, pero no tanto para el ingeniero que diseña estas soluciones.  Tanto IaaS como sus subservicios (VPNaaS, FWaaS, etc) requieren un completo arsenal de nuevos protocolos, tecnologías de tipo Overlay, medidas de seguridad y muchas otras cosas que nosotros, la gente de networking, debemos preocuparnos para implementar redes rápidas, resilientes, redundantes, seguras y estables para nuestros colegas de los pisos superiores (Normalmente utilizo esta analogía para referirme a nuestros queridos ingenieros de software y desarrolladores que trabajan en los “pisos superiores” del modelo OSI).  Dentro de ese lote de tecnologías viene VXLAN.

La idea de las LAN extensibles virtuales es conectar dos redes separadas físicamente utilizando el mismo bloque IP y la misma etiqueta (tag) de VLAN en ambos sitios si así se requiere. Aparte de eso, VXLAN ofrece más de 16 millones de VLAN IDs al utilizar 24 bits para este campo, derrotando por knockout la falta de flexibilidad de las VLANs tradicionales que utilizan encapsulación troncal 802.1q, donde solo se utilizan 12 bits para el VLAN ID, generando un máximo de 4096 VLANs (incluso menos, sabiendo que algunos fabricantes como Cisco reservan la VLAN 0 para usos especiales).

Con tal cantidad de VLAN IDs, VXLAN se convierte en una excelente solución para entornos virtualizados de tipo multi-tenants  (o multi-clientes) y una tecnología de tipo Overlay muy escalable para ser utilizado dentro de ecosistemas de datacenters virtuales (vDC). VXLAN puede también utilizar multicast para descubrir otros VTEPs o VXLAN Tunnel Endpoints en la misma red. Esto es muy útil cuando se utilizan switches virtuales distribuidos, como es el caso de una implementación vSphere de VMware o Nexus 1000v de Cisco en múltiples servidores físicos.

Para entender VXLAN veamos la siguiente topología (click para agrandar imagen).

VXLAN1

En este escenario tenemos dos máquinas virtuales, VM1 y VM2 (aunque pueden ser miles o millones) que están en segmentos físicamente diferentes, separadas por un core de capa 3 (como puede ser, por ejemplo, una red MPLS o Internet mismo). Ambas máquinas necesitan conectarse a la misma VLAN y utilizar la misma subred IP en ambos casos. Esto pareciera a simple vista romper todos los esquemas tradicionales y muy probablemente algún ingeniero poco experimentado inmediatamente declare la inviabilidad de este requerimiento. Y claro, sin VXLAN las opciones son muy limitadas y prácticamente solo podríamos utilizar IRB (Integrated Routing and Bridging), pero hablar esto nos llevaría a analizar un enfoque totalmente distinto al objetivo de este post, que es explicar VXLAN.

Estas dos máquinas virtuales pueden trabajar en la misma subred en ambos extremos al utilizar VXLAN como transporte overlay, aún cuando ambos dominios de capa 2 (L2) están separados por múltiples dispositivos de capa 3. Entonces ¿cómo funciona? Esto es pura brujería de redes 😉

VXLAN es una tecnología de túnel, al igual que GRE, PPPoE, 6to4, etc. Que sea túnel significa que se toma un paquete o una trama original, con sus encabezados completos y se trata como la carga útil (payload) de un paquete o trama nuevo.

Veamos entonces lo que sucede en nuestro diagrama.
1) Cuando VM1 envía un paquete IP destinado a la IP 172.23.153.20 (VM2), este paquete será encapsulado en una trama Ethernet estándar en la red local (aquí asumiremos que no hay VLANs solamente para simplificar el ejemplo) con los siguientes parámetros.

IP de destino: 172.23.153.20 (VM2)
IP de origen  : 172.23.153.10 (VM1)
MAC de destino: 00:BB:AA:00:00:12 (VM2)
MAC de origen: 00:BB:AA:00:00:11 (VM1)

Esta trama será enviada a su respectivo VTEP, en este caso VTEP-1 y la llamaremos “trama interna Ethernet” o inner Ethernet frame en inglés. Asumiremos que paquete IP contenido en esta trama transporta datos de una sesión SSH entre ambas máquinas (es decir, el paquete IP transporta un segmento TCP + datos de aplicación de tipo SSH).
A modo de ejemplo, el tamaño de los datos de aplicación será de 92 bytes y el tamaño del encabezado TCP de 32 bytes (asumiremos, además, que TCP utiliza sus campos opcionales ya que no deben olvidar que el mínimo del encabezado TCP es de 20 bytes y el máximo puede llegar hasta 60).  Entonces, VM1 envía un segmento de 124 bytes de longitud que es transportado dentro de un paquete IP, el cual agrega 20 bytes extra  que corresponden al tamaño del encabezado IPv4.

Hasta este punto tenemos un paquete IP de 144 bytes siendo encapsulado dentro de una trama Ethernet estándar viajando desde VM1 hacia su próxima parada que es VTEP-1:

VXLAN2

La trama Ethernet interna tiene un encabezado normal de 14 bytes (No se cuenta el preámbulo, 6 bytes de MAC de destino + 6 bytes de MAC de origen + 2 bytes de Tipo/Longitud. Recuerden que no usamos VLANs aquí) más un trailer normal de 4 bytes para FCS. En total: 14 (Header) +144 (Paquete IP) +4 (FCS) bytes en la trama Ethernet interna.

2) Una vez que este mensaje llega a VTEP-1 comienza la encapsulación VXLAN. Este dispositivo agrega un encabezado VXLAN de 8 bytes que contiene un VNI o VXLAN Network Identifier con el valor 5000 (puede llegar a +16.000.0000). No se considera el FCS ya que no es necesario para el transporte de extremo a extremo. A la trama de 14 bytes + 144 (ahora sin FCS) se le suman los 8 bytes de VXLAN.

Lo interesante sucede a partir de este momento. VTEP-1 convierte esa trama Ethernet interna, (incluyendo el encabezado VXLAN) en la carga útil o payload de un paquete UDP. A este paquete UDP, el cual llamaremos “UDP externo” se le agrega un encabezado IPv4 normal y nuevamente se encapsula en una trama Ethernet (la cual esta vez llamaremos trama Ethernet externa u outer Ethernet frame)

VXLAN3

Repasemos antes de seguir:

  • Se envía una trama Ethernet normal desde VM1 hacia VTEP-1 que contiene un paquete IP, que a su vez contiene un segmento TCP con datos de aplicación de tipo SSH. Todo esto mide 14+144+4 (Encabezado Ethernet + Paquete IP completo + FCS).
  • Al llegar a VTEP-1 se descarta el FCS y se toma esta trama Ethernet (ahora solo de 14+144 bytes) y se le agrega un encabezado VXLAN de 8 bytes que contiene, entre otras cosas, el valor de identificador de VXLAN o VNI). Tenemos 8 + 158 bytes hasta este punto.
  • Estos 166 bytes se guardan como carga útil dentro de un mensaje UDP, quien agrega 8 bytes más (el encabezado UDP siempre es de 8 bytes). Este es el paquete UDP externo u outer UDP.
  • Como el outer UDP no puede viajar solo por el mundo, se le agrega un encabezado IPv4 (20 bytes) con los valores de IP origen/destino de los VTEPs.
  • Y como ese paquete IP necesita una trama para moverse en su red local, se encapsula dentro de una trama Ethernet estándar (outer Ethernet) quien agrega nuevamente 14 bytes de encabezado + 4 bytes de trailer. Todo esto suma 208 bytes.

Sigamos. Esta trama sale del VTEP-1 hacia el siguiente router dentro del backbone IP y es tratado como cualquier paquete IP normal (gracias al encabezado IP externo), enrutándose de acuerdo a su IP de destino. El backbone IP encaminará este paquete hacia VTEP-2

La trama Ethernet externa saliente de VTEP-1 lleva los siguientes parámetros:

MAC de destino: 00:CC:CC:12:34:56 (Correspondiente a la puerta de enlace predeterminada de VTEP-1)
MAC de origen: 00:DD:DD:22:22:22 (VTEP-1)

Mientras que el paquete IP externo, utilizado para llegar a VTEP-2 contiene:

IP de destino: 197.23.66.214 (VTEP-2)
IP de origen : 88.25.190.2 (VTEP-1)

3) Justo antes de llegar a VTEP-2, démosle un vistazo al paquete IP externo y la trama que lo encapsula

VXLAN4

Como puedes ver, nada ha cambiado en nuestro paquete IP externo (ni en su carga útil, que corresponde a la información VXLAN + la trama interna + paquete IP interno + TCP interno + datos de aplicación) a excepción de la dirección MAC de origen y destino entre el último router y VTEP-2.

4) VTEP-2 recibe la trama externa y la desencapsula, remueve el paquete IPv4 externo y también el encabezado UDP externo para revisar el VNI, que en nuestro caso identifica al cliente 5000. Su configuración interna le indica que el VNI 5000 solo tiene permitido conectarse a VM2. Ahora que VTEP-2 eliminó todos los valores externos, solamente queda la trama interna Ethernet que se originó en VM1 (y vino viajando por todo el trayecto oculta en la carga útil del paquete UDP externo). Con esta información, la trama interna se mueve hacia VM2 tal como si estuviese conectada en la misma LAN física.

En este punto, el contenido de la trama Ethernet interna es el mismo que en el punto 1. Se le agrega el FCS para respetar el estándar y verificar errores.

VXLAN5

Finalmente la trama generada en VM1 llega a VM2, quien desencapsula nuevamente esta trama interna, elimina el encabezado TCP y examina los datos de aplicación. Por supuesto que la respuesta desencadenará el mismo procedimiento a la inversa para llegar a VM1.

Esta habilidad permite a la infraestructura gestionar redes multi-tenants al ser capaz de encapsular millones de VNIs dentro de un paquete UDP normal, soportando a la vez tanto direcciones IP como MACs sobrepuestas (overlapped) entre un cliente y otro (no dentro del mismo VNI, por supuesto).

VXLAN6

Los diseños de redes redes multi-tenants son críticos para implementar soluciones basadas en la nube y VXLAN se está convirtiendo en uno de los protocolos preferidos para ofrecer seguridad y flexibilidad a los clientes. Algunos argumentan que es preferible utilizar GRE pero la diferencia (para no hablar de desventajas) es que GRE al ser una tecnología de capa 3 requiere obligatoriamente diferentes subredes en ambos extremos. Otros podrían decir que QinQ solucionaría el problema, pero esta es una tecnología de capa 2 y nadie quiere sustentar su infraestructura completa en diseño tan pobre. VXLAN se está convirtiendo en el estándar de-facto para la virtualización de redes y en mi opinión se quedará un buen tiempo entre nosotros.

Glosario

IaaS: Infraestructure-as-a-Service. En palabras simples, es la capacidad de una nube de ofrecer servicios virtualizados completos de infraestructura de redes a sus clientes (enlaces, subredes, routers, VPN, firewalls).
Tenants: Sinónimo de cliente. En inglés, tenant significa “inquilino” o alguien que arrienda un espacio. En las nubes, los clientes no son dueños de sus infraestructuras sino que las arriendan a un proveedor de Cloud. Por eso reciben este nombre. Las redes multi-tenants, entonces, son aquellas que permiten múltiples clientes simultáneos incluso cuando entre ellos tengan las mismas subredes, direcciones MACs y otros valores que puedan traslaparse sin interferirse.
Overlay: Sobreposición. Las tecnologías de tipo overlay son aquellas que permiten transportar datos de un extremo a otro y dejar que los datos originales viajen en la red de destino como si fuesen originados en ella. (Imagínense el siguiente escenario: Hay dos tinajas y usted se sienta entremedio de ellas. En la tinaja de su derecha están los cachorros de perros recién nacidos y en la tinaja a su izquierda está la madre. Usted toma los cachorros con su mano derecha y uno a uno los va depositando suavemente en la tinaja izquierda donde está la madre. Usted está actuando como un protocolo overlay ;))
VTEP: VXLAN Tunnel EndPoint o Punto de terminación del túnel VXLAN. Corresponde a los dispositivos de capa 3 que se encargarán de interconectar los túneles VXLAN y que actuarán como extremos del mismo. Algo así como los “crypto peers” en IPsec o “tunnel source/destination” en GRE.
Payload: Carga útil de un paquete, segmento o datagrama.
VNI: VXLAN Network Identifier. Es el valor que identifica a un cliente o tenant dentro de una infraestructura VXLAN. Puede ofrecer más de 16.000.000 de valores diferentes.

  • Enrique Villar

    Hola. Interesante artículo. Lo leí en base a un video tuyo explicando SDN y VXLAN. Por casualidad, ¿sabrás que dispositivos CISCO soportan VTEP aparte de los Nexus 9000? Muchas gracias.

  • Esaúl

    Buena explicación, muchas gracias. Solo te advierto de una correción, en la frase:
    MAC de destino: 00:CC:CC:12:34:56 (Correspondiente a la puerta de enlace predeterminada de VTEP-1)

    Sería VTEP2, 😉 Saludos

  • Rodolfo Casás

    Muy buena entrada Paulo, gracias