VXLAN: conceptos, funcionamiento e implementación (1/2)

Por estos días VXLAN parece cada vez más estar en boca de todos los que siguen el mercado de la virtualización de redes. Por un lado el Internet Engineering Task Force  (IETF) aprobó hace cerca de tres semanas pasar la tecnología VXLAN del estado borrador o draft a ser un protocolo reconocido por un RFC, lo que provee una base más sólida para su consolidación.

Por otra parte, el creciente auge de la suite de SDN de VMware: NSX ha llevado a partners como Juniper Networks, Arista Networks, entre otros; a ofrecer dispositivos capaces de integrarse con NSX usando como protocolo overlay a VXLAN, por sus capacidades y su flexibilidad en cuanto a requerimientos de infraestructura.

Esta es la motivación para ésta serie de 2 entradas que, dedos cruzados, se convertirán en más publicaciones sobre el avance de NSX como plataforma para SDN.

Entremos en materia.

VXLAN: ¿qué es?

Es un protocolo de superposición de redes (overlay networks) definido por el RFC 7348 que el IETF aprobó hace algunas semanas, y que hace uso del protocolo IP como la base sobre la cual implementa segmentos LAN similares a las VLAN, pero con un esquema diferente de encapsulación que eleva considerablemente el número de redes que es posible transportar, a la vez que aprovecha la ubicuidad y alcance geográfico de IP para agregar flexibilidad y extensibilidad a la implementación de redes L2.

¿Por qué VXLAN?

Uno de los desafíos a los que se enfrentan actualmente los arquitectos de red en el centro de datos moderno, consiste en las limitaciones del omnipresente Spanning Tree Protocol que es casi el mecanismo de-facto que las organizaciones implementan para evitar los loops en capa 2, sin embargo STP inevitablemente deja múltiples links sin uso por lo que en la escala masiva de los datacenter para la nube, esto significa un enorme costo de inversión en puertos que finalmente no se pueden usar.

Por otro lado y a diferencia de protocolos de capa 3 como IP, las redes de capa 2 tienen poca movilidad fuera del datacenter y ciertamente la carga operacional para extenderlos o activar dominios capa 2 en un sitio alterno reduce las opciones para la implementación efectiva de requerimientos como Disaster Recovery de cargas de trabajo virtualizadas hacia un datacenter alterno, manteniendo todas las propiedades de conectividad del sitio principal de forma automatizada.

Por si fuera poco, el mecanismo tradicional de aislamiento de red en capa 2 que son las VLANs, definen el VLAN ID como un atributo numérico de 12 bits, limitando el número de redes posibles a 4094. Por muchos años pareció lejana la posibilidad de alcanzar este límite, pero en el datacenter actual con múltiples tenants consumiendo servicios de conectividad y a la vez creando sus propias redes y servicios, éste límite rápidamente se ha convertido en un obstáculo a la vista para la escalabilidad del centro de datos.

Figura 1. VXLAN agrega un ID de 24 bits antes de transportar el paquete por la red IP. En el destino se lleva a cabo la desencapsulación.

VXLAN surge, pues, como una propuesta conjunta de fabricantes como VMware, Cisco, RedHat, Arista, entre otros; para convertirse en el mecanismo que efectivamente extienda la funcionalidad de las VLAN tanto en escala como en alcance. En escala pues su identificador de red, definido como VNI (VXLAN Network Identifier o Segment ID) es de 24 bits de longitud con lo que se alcanza un máximo de 16 millones de redes que pueden converger en una misma implementación VXLAN.

La extensión del alcance de las VLAN la logra VXLAN al valerse del protocolo IP, tan ampliamente implementado y con diversos mecanismos de movilidad, como medio de transporte para las redes L2 que viajan encapsuladas. Es por esto que a VXLAN también se le incluye en la categoría de tecnologías o protocolos de tunelamiento.

Componentes

La siguiente es una lista de componentes necesarios para una implementación de VLXAN en un entorno VMware:

A. VTEP (VXLAN Tunnel Endpoint): es la entidad que origina y/o termina túneles VXLAN. Se implementa en cada host ESXi y se compone a su vez de los siguientes módulos:

  1. Módulo vmkernel: hace parte del distributed Virtual Switch (dVS) y se instala como un vib en el hipervisor. Actúa como plano de datos al mantener las tablas de enrutamiento así como se encarga de la encapsulación y desencapsulación de paquetes
  2. Adaptador vmknic: se instala uno en cada host cuando el clúster se prepara para VXLAN. Se encarga de transportar el tráfico de control de VXLAN. Actúa en parte como control plane al alimentar la información de rutas visible en la red IP y alimentarla a la tabla mantenida por el plano de datos en el módulo vmkernel de VXLAN.
  3. Port group VXLAN: incluye la información tradicional de los portgroups dVS de vSphere, y se crea un portgroup automáticamente por cada red ó segmento VXLAN implementado.

B. vCNS Manager: este es el verdadero plano de administración o management plane, pues ofrece la gestión centralizada de los segmentos VXLAN así como de las interfaces vmknic y los clústers en cuyos hosts se ha instalado el VTEP. No administra el tráfico como tal, pero si mantiene el estado actual de la implementación VXLAN dentro de un vCenter.

C. vCNS Gateway: es un appliance que ofrece servicios de conectividad y seguridad avanzados y que es implementado y administrado por vCNS Manager. Se trata de un componente realmente especial dentro de la arquitectura de VMware VXLAN pues tiene la capacidad de dar salida a las MVs conectadas a los segmentos VXLAN hacia el “mundo exterior” con funcionalidades de NAT, Firewall perimetral, DHCP, DNS Relay, VPN, entre otras y es una alternativa para la eterna pregunta acerca de cómo terminar segmentos o túneles VXLAN en dispositivos físicos. Esto será materia de otra entrada, pero quedémonos con que el vCNS Gateway es efectivamente el puente entre redes VXLAN y servicios externos de conectividad.

vxlan_componentes
Figura 2. Arquitectura simplificada de implementación de VMware VXLAN

En la próxima entrada veremos los mecanismos bajo los cuales opera VXLAN así como los pasos prácticos para la implementación del protocolo en un entorno VMware.

Saludos!

Advertisements