GENEVE: una porción del futuro disponible hoy con NSX-T

Fue hace unos seis años cuando tuve el primer encuentro con lo que –para ése momento- era una tecnología muy joven en el campo de redes de centro de datos: Virtual Extensible LAN o VXLAN y las posibilidades que permite me dejaron cautivado. En su momento era un draft, pero ya hace un par de años es un estándard establecido por la IETF y su adopción no ha parado desde entonces convirtíendolo casi en el sinónimo de virtualizaciòn de redes (o SDN para los más osados) en el entorno empresarial.

Image result for vmware vxlan header size

Esquema de una trama TCP con el header adicional de VXLAN. Cortesía de http://bit.ly/2ukgJSe

Hemos escuchado el discurso al respecto: un header de 24 bits adicionales que nos permite transportar hasta 16M de redes virtuales; es todo lo que necesitamos por mucho tiempo.

Con el problema de escalabilidad de las VLAN tradicionales (que solo llegan hasta 4093 redes) resuelto, la industria volcó su esfuerzo a ampliar la soportabilidad de éste protocolo y fue así que casi todos los fabricantes de hardware de conectividad han llegado al punto de ofrecer dentro de su portafolio, equipos que soportan de manera nativa el protocolo e incluso pueden fungir como gateway traductor entre VXLAN/VLAN y viceversa.

Entonces, ¿hay algo más que hacer en éste campo de los protocolos de encapsulación? ¿No es suficiente con STT o VXLAN?

Parece que no. Y la principal razón es sencilla: flexibilidad.

¿Con que otro insumo podríamos garantizar la interoperabilidad, agilidad y automatización de una infraestructura de red moderna sino con flexibilidad?

Elaboremos mejor en que aporta específicamente GENEVE en éste caso.

¿Qué es GENEVE?

GENEVE (Generic Network Virtualization Encapsulation) es un esfuerzo conjunto de Microsoft, Intel y VMware entre otros para evitar crear un nuevo protocolo de redes virtuales (u overlay) al que ahora todos debamos actualizar, sino más bien crear un mecanismo modular que sea fácilmente adaptable a la infraestructura existente y mucho más rico en funciones para las redes de hiper-escala del futuro cercano.

GENEVE Packet Format

Esquema de trama GENEVE donde el único contenido fijo es de 8 bytes. Tomado de http://bit.ly/2ukimzk, adaptado de http://bit.ly/2tmFFvb

Aunque apenas completa 3 años de haber sido creado como draft o borrador en la IETF y aún no es un estandard completamente definido, la simplicidad de GENEVE es convincente: un header cuyo contenido inicial es de sólo 8 bytes (comparado con 50 bytes de VXLAN) en el que se transporta el ID de la red virtual (Virtual Network Identifier o VNI) y el campo Protocol Type. Todo lo demás es completamente definible para la implementación particular, lo que podría resultar en un tamaño de trama menor al de VXLAN (1550 bytes) pues solo transporta la información que se considere necesaria, elevando así la posibilidad de extender las redes virtuales a lo largo de la WAN, donde normalmente Jumbo Frames no es una opción viable de extremo a extremo.

Suena bien, pero… ¿alguien lo está usando?

Veamos.

 ¿Qué es NSX-T?

NSX-T es quizá la primera aventura seria de VMware fuera de su zona de comfort: un producto completo de virtualización de redes y seguridad pensado para entornos donde vSphere no está presente. Lanzado hace muy poco y con su versión 1.1 apenas liberada en Febrero de éste año, denota un esfuerzo intencional de investigaciòn y desarrollo para el mundo multi-hipervisor.

image

Arquitectura de NSX-T para entorno KVM. Imagen tomada de http://bit.ly/2tqELP7 <-Recurso recomendado

Aunque amerita un post aparte introducir NSX-T, podemos mencionar por ahora que conserva una arquitectura similar a su contraparte en vSphere (NSX-v) pero incorpora mejoras que lo hacen ver como el producto de elección para un entorno heterogéneo de nube privada o híbrida. Por ejemplo incluye:

  • Un modelo de routing multi-tenant que muestra beneficios inmediatos para operadores de nube que ya se han encontrado con los enormes retos de conectividad en un entorno heterogéneo
  • Nodos Edge (virtuales o físicos) que aprovechan las ventajas de Intel DPDK para elevar considerablemente el desempeño del procesamiento de paquetes haciendo uso del recurso de CPU de los nodos de cómputo. Esto es enorme.

Y claro, aparte de éstas y otras características, la que nos compete en éste post: a partir del release 1.1 (Feb 2017) NSX-T usa GENEVE para transportar las redes virtuales.

Una porción del futuro, disponible ahora.

 Implicaciones de adopción de GENEVE

Es importante mencionar que, por la misma naturaleza que describimos acerca del protocolo aquí, adoptar GENEVE en una red de datacenter actual:

  • No requiere adquisición de equipamiento especializado
  • Puede interoperar con topologías complejas que hagan uso de enrutamiento dinámico (muy común en redes medianas/grandes o en ISPs)
  • Viabiliza aún más el santo grial de la conectividad multi-cloud: transporte de funciones de red y seguridad a lo largo de diferentes entornos; privado, público e híbrido sin que sufran modificación. Esto requiere una enorme dosis de interoperabilidad ayudada por protocolos como GENEVE.

Conclusión

Así como BGP, LLDP –entre otros- son protocolos que dominan ampliamente su campo y han podido evolucionar y adaptarse exitosamente a las demandas modernas al adoptar un enfoque de flexibilidad, GENEVE se augura como ese sustrato confiable en el que se puedan diseñar y ejecutar los requerimientos de virtualización de red para los entornos más complejos, móviles y heterogéneos del ahora y el mañana.

Saludos!

Apuntes sobre el funcionamiento de VXLAN sobre OVS en Nutanix Acropolis Hypervisor

Acropolis Hypervisor (AHV) es la respuesta de Nutanix a algo que no todos los fabricantes de infraestructura siquiera se hubiesen detenido a pensar: VMware ESXi es el líder de los hipervisores tipo I en la industria, pero puede contener más características de las que muchos clientes llegan a conocer: ¿sería posible construir un hipervisor que brinde una alternativa viable y soportada a ESXi con las funcionalidades necesarias?

Hubiese querido iniciar la exploración de Acropolis Hypervisor en orden pero bueno, el networking es un tema que siempre captura mi atención (después de todo, es quizá el campo más académico de la industria de IT); así que en éste post veremos algunos apartes sobre el esquema de redes que AHV entrega para las máquinas virtuales.

Open vSwitch

AHV implementa la conectividad usando Open vSwitch (OVS), que es un proyecto de código abierto respaldado por Linux Foundation y que busca desarrollar un switch virtual (creo que lo intuyeron ya) pensado desde su inicio para la automatización y programabilidad. Brinda muchas de las funcionalidades que un vSphere Distributed/Standard Switch entregarían pero con un enfoque abierto. Soporta características suficientes como para considerar su introducción en las empresas, o es mi conclusión al ver en la lista a:

  • LACP
  • STP y RSTP (si, aún no han muerto)
  • NIC bonding
  • IPv6
  • IEEE 802.1Q support (VLANs para los más tradicionales)
  • Protocolos de tunelamiento: GRE,STT, Geneve y …. VXLAN

¿Para qué VXLAN?

Bueno, quizá no soy la fuente más independiente para hablar de overlays, pues vengo trabajando con VXLAN hace unos años y escribiendo también (mi post al respecto ahora es una de las referencias en la Wikipedia!). Sin embargo y aunque no es para nada el único protocolo de tunelamiento, VXLAN es el que más ampliamente se ha implementado y cuenta con un amplio soporte por parte de fabricantes en el espacio de hardware y software de redes modernas.

VXLAN es, en resumen, el habilitador de la flexibilidad de redes capa 2 dentro del centro de datos y (proveídos algunos requerimientos sencillos) entre centros de datos remotos. Esto es grande, más grande de lo que muchos hemos entendido pues si las cosas salen como lo esperan el 70% de las compañias consultadas por IDC, la nube híbrida será el modelo más ampliamente implementado en un par de años. Y si quitamos del camino los demás factores de un proyecto de éste estilo, al final del día el aspecto que realmente hace que sea viable o no es precisamente la extensión de las funciones de red y las políticas y controles de seguridad desde las premisas del cliente hacia la nube pública. VXLAN no es necesariamente requerido para ello, pero agrega una eficiencia digna de la escala de la nube (webscale).

Por otro lado, hay al menos un túnel VXLAN en ejecución internamente en AHV y es utilizado para distribuir las respuestas a solicitudes DHCP en el IPAM (IP Address Management) interno.

¿Como funcionaría?

Lamentablemente, este es otro post teórico, por lo que todavía será sujeto de completa verificación en campo. Pero con la documentación en mano y una dosis de experiencia con VXLAN puedo aportar los siguientes apuntes:

  • Actualmente OVS no soporta los aspectos multicast de VXLAN de los que, en todo caso, muchos fabricantes están tratando de alejarse; como es el caso de VMware con NSX y su soporte para Unicast desde las primeras versiones.
  • El que OVS no soporte VXLAN Multicast crea una necesidad: establecer un plano de control. El mismo RFC 7348 indica que éste plano debe ser distribuido y no administrado centralmente. En AHV ésa labor la cumplen las CVM alojadas en cada nodo (vaya que hacen multitasking éstas VMs).

Me he tomado la libertad de usar la siguiente imagen de la Nutanix Bible en la sección 4.1.4. Networking para tratar de describirlo mejor.

Open vSwitch Network Overview

Toda máquina virtual en AHV es conectada directamente a un puerto tap (como un puerto de escucha) que entra a ser parte del entorno OVS interno al que también está conectada la vNIC de la CVM (vnet0). El que se trate de un puerto tap me hace pensar que internamente, hay alguna forma de replicación o escucha de tráfico en ambas vías que debe ser el medio por el cual el CVM cumple su rol en la parte de redes frente a las VMs y las VMs hacen allí sus diferentes solicitudes al respecto.

Pero, ¿cuál es ése de rol de las CVM? Bueno, similar a como ocurre con el Controller Cluster de VMware NSX, las CVM actuarán como el plano de control “aprendiendo” ´y distribuyendo información de enrutamiento a todo el clúster Nutanix en el cual tengan alcance. Adicionalmente, deben ser las responsables de mantener y actualizar la tabla de Forwarding (entradas ARP) y distribuirla a todos los nodos. Por supuesto ésto crea ventajas pues con AHV no sería necesario desplegar un producto adicional para tener acceso a una red más controlada por software (siempre han sido definidas por software las redes) y habilita la flexibilidad y optimización propias de un overlay con VXLAN que tiene su plano de control distribuido.

 Ideas finales

En caso que AHV soporte nativamente el protocolo de administración de OVS (OVSDB), entonces una integración adicional con los equipos de red físicos es posible y allí toda esa valiosa información de enrutamiento y forwarding sería aprendida y distribuida no sólo dentro del entorno virtualizado sino hacia la red física de transporte. Algunos fabricantes de hardware de red ya soportan éste protocolo, entre ellos Cumulus Networks que está haciendo un trabajo formidable en crear infraestructura abierta y escalable para redes de todos los tamaños. En caso que AHV no lo soportara, habría que considerar VMware NSX que desde sus inicios cuenta con ésta característica.

Conclusión

Estoy consciente que éste post no resuelve una pregunta que se haga todos los días, pero si se que muchos competidores de Nutanix apuntan al “complejo” modelo de redes de AHV como un punto negativo. Aunque no lo he descifrado en éste post para nada, consideré oportuno empezar la exploración de éste tema por el núcleo de todo que es OVS y VXLAN. Espero les sea de utilidad en alguna medida.

Saludos!

Tres niveles de (in) dependencia de Multicast en VXLAN

Continuando  con la temática del protocolo VXLAN, en ésta ocasión trataré lo que ha solido citarse como la principal barrera para su adopción: el requisito de Multicast y la carga operacional que implica su administración y la complejidad de la implementación.

Para VMware y Cisco, dos de los principales impulsores de VXLAN no ha sido desconocido éste tema y han hecho diferentes actualizaciones a la línea de productos para ofrecer tunelamiento VXLAN en diferentes sabores con respecto al requisito de multicast. He identificado tres variantes hasta ahora, que pasaré a describir:

1. vCloud Networking & Security: barato como un cachorrito

Si una organización tiene acceso a vCloud Suite en edición Standard, ya tiene en su bolsillo el licenciamiento para vCNS. Con éste producto es posible crear una completa implementación de VXLAN que incluso pueda ser consumida como redes organizacionales por tenants de vCloud Director. Sin embargo aquí es completamente necesaria la presencia de Multicast en la red física, aspecto que se debe tener en cuenta a la hora de evaluar la solución y su costo operacional.

2. Cisco Nexus 1000V: viviendo al filo del RFC

A comienzos de 2013, Cisco anunció la implementación de al menos dos nuevos mecanismos en el switch Cisco Nexus 1000V que harían posible implementar VXLAN sin el requisitio de Multicast:

a. Nexus 1000V puede crear múltiples réplicas de cada paquete y enviar cada réplica a un VTEP en la red usando sólamente Unicast. Esta opción claramente dista de ser escalable pues en un entorno masivo se producirá algo similar a una “tormenta” Unicast.

b. Hacer uso del VSM (Virtual Supervisor Module) que hace parte de la implementación de Nexus 1000V para que actúe efectivamente como un plano de control distribuyendo la información de direcciones MAC de máquinas virtuales a los VEM (Virtual Ethernet Module) presentes en la red. Esto, aunque efectivo, contradice lo que establece el RFC de VXLAN con respecto a que el protocolo no debe depender de un plano de control ni entidad alguna de administración centralizada. Cisco lo sabe pero, el cliente siempre tiene la razón 😉

VMware NSX: el auge del plano de control distribuido

Durante el VMworld US 2014, el Dr. Bruce Davie compartió conceptos avanzados y el futuro de NSX en la sesión NET1674.

Allí detalló el uso de VXLAN como protocolo de tunelamiento para NSX y, con respecto a lo que nos ocupa, la manera en que NSX habilta el uso de OVSDB (Open vSwitch Database) como el protocolo a través del cual distribuye la tabla de direcciones MAC de las Máquinas virtuales a lo largo de los switches físicos que soporten el protocolo y que hagan parte de la infraestructura sobre la cual tiene alcance el NSX Controller.

OVSDB es un protocolo de administración cliente-servidor que busca dar acceso programático a la base de datos OVSDB que contiene la información de cómo opera la conmutación del Open vSwitch con datos como, por ejemplo, la tabla de direcciones MAC de las MVs del entorno.

El mecanismo principal con el cual NSX crea redes virtuales (llámense segmentos, virtual wires, túneles,etc) es VXLAN que en este caso, y dado que la tarea de distribución y actualización de direcciones MAC la asume el protocolo OVSDB, solo requiere la presencia del protocolo IP como transporte o underlay eliminando así el requerimiento de multicast en la red física.

Sin embargo, no todas las organizaciones van a poder abrazar éste enfoque pues surge un nuevo requerimiento quizá más etéreo que el de multicast: switches físicos que soporten OVSDB. Actualmente existe oferta al respecto por parte de fabricantes como Juniper o Arista y aparentemente Open vSwitch ha llegado para quedarse, que es lo que se desprende de su adopción no solo por parte de los grandes fabricantes sino de la iniciativa OpenDayLight de Linux Foundation, que busca establecer un marco de referencia para el avance de SDN como un programa abierto e interoperable (el mundo empieza a reaccionar contra la proliferación del vendor lock-in, o eso esperaría).

Saludos!

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!