¿Qué es GENEVE?

Tuve mi primera experiencia con un túnel de superposición en 2003 mientras trabajaba en un proyecto para crear un proxy transparente basado en Squid y el WCCP (protocolo de comunicaciones de caché web) desarrollado por Cisco. En parte de la configuración entre el enrutador Cisco y el proxy Squid se necesitaba usar túneles GRE (Generic Routing Encapsulation) para comunicarse. En ese entonces, no entendía del todo la necesidad de protocolos de túnel. Ahora, años más tarde, comprendo su importancia porque las VLAN en grandes nubes multiempresa están rotas.

Las VLAN se desarrollaron para segmentar el tráfico de red en redes más pequeñas y simples. El inconveniente es que solo tienen un campo fijo de 12 bits, lo que significa que solo se pueden tener alrededor de 4000 VLAN en una topología de red. A fines de la década de 1990 y principios de la primera década del siglo XXI, estos segmentos eran más que suficientes para las redes. Sin embargo, con el surgimiento de la era de la nube y los entornos multiempresa, surgió la necesidad de muchos más túneles de red individuales.

Para abordar el problema, varios proveedores propusieron diferentes soluciones: VXLAN (Virtual Extensible LAN), NVGRE (virtualización de red con encapsulación de enrutamiento genérico) y STT (Stateless Transport Tunneling). Los tres encapsulan los datos de las aplicaciones en un nuevo campo de encabezado fijo más grande. Ese tamaño de encabezado es de 24 bits para VXLAN y NVGRE (a este último lo utiliza sobre todo Microsoft) y de 64 bits para STT. Ninguno de estos métodos de tunelización y encapsulamiento requiere que se cambie en modo alguno la infraestructura de redes de hardware, aunque algunos proveedores ofrecen hardware que puede acelerar la eficiencia de la solución. Sin embargo, las soluciones son incompatibles entre sí.

Pero no todo está perdido en la era actual de las grandes nubes multiempresa. Apareció un nuevo estándar de virtualización de red: GENEVE (Generic Network Virtualization Encapsulation, encapsulamiento de virtualización de red genérica), que promete abordar las limitaciones que se identificaron en las especificaciones anteriores y admitir todas las capacidades de VXLAN, NVGRE y STT. Muchos creen que GENEVE podría, con el tiempo, reemplazar estos formatos anteriores por completo.

El objetivo de GENEVE es definir solo un formato de encapsulamiento de datos. A diferencia de los anteriores, no incluye información o especificaciones para el plano de control. En palabras de los autores:

"Decidirse por un formato de datos tiene una ventaja clara: la mayoría de los protocolos tienen solo diferencias superficiales y no tiene sentido duplicar los esfuerzos. Sin embargo, no se puede decir lo mismo de los planos de control, que difieren en cuestiones muy fundamentales. El caso de la estandarización también es menos claro dada la amplia variedad de requisitos, objetivos y situaciones de implementación".

Para lograr estos objetivos, los autores de GENEVE acordaron que el formato de los datos debe ser lo más flexible y ,ampliable posible. Si bien los campos de identificador de túnel actuales de 24 bits en VXLAN y NVGRE y los de 64 bits en STT son más que suficientes para especificar todas las redes virtuales que se requerirán, se cree que los futuros desarrolladores subdividirán este campo para incluir más información. Los autores comparan los usos potenciales de este campo con la información de estado del sistema que se intercambia actualmente dentro de los servidores virtualizados o entre las tarjetas de línea en un conmutador de chasis. Observan que no se puede especificar un tamaño de campo fijo que sea suficiente para todos los usos futuros posibles. Además, los autores de GENEVE se inspiran en muchos otros protocolos que demostraron tener una larga vida. Los protocolos como BGP (protocolo de puerta de enlace de frontera), LLDP (protocolo de detección de capa de enlace), IS-IS (Sistema intermedio a sistema intermedio) y muchos otros existen desde hace varias décadas y siguen siendo tan populares como siempre.

Y la razón es simple: son extensibles. Evolucionan con el tiempo, no a partir de revisar los protocolos básicos, sino de agregar nuevas capacidades opcionales.

Los paquetes encapsulados GENEVE están diseñados para transmitirse a través de equipos de red estándar. Se envían desde un extremo del túnel a uno o más extremos mediante direcciones de unicast o multicast. La aplicación cliente y el host en el que se ejecuta no se modifican en manera alguna. Las aplicaciones generan paquetes IP idénticos, como si se comunicaran a través de conmutadores y enrutadores de hardware. La dirección IP de destino incluida en el paquete es significativa solo dentro de la red virtual del usuario de la nube. El extremo del túnel encapsula el paquete IP del usuario final en el encabezado GENEVE, y agrega el identificador del túnel que especifica la red virtual del usuario seguido de las opciones que haya. El encabezado consta de los campos que especifican que se trata de un paquete GENEVE, la longitud total de las opciones (si las hay), el identificador del túnel y la serie de opciones. A continuación, el paquete completo se transmite al extremo de destino en un paquete UDP estándar que es compatible con IPv4 e IPv6. El extremo receptor del túnel elimina el encabezado, interpreta las opciones incluidas y dirige el paquete del usuario final a su destino dentro de la red virtual indicada por el identificador del túnel.

La especificación GENEVE ofrece recomendaciones sobre maneras de lograr un funcionamiento eficiente al evitar la fragmentación y aprovechar las instalaciones de descarga de hardware de ECMP (múltiples rutas de igual costo) y NIC. También brinda opciones en relación a la compatibilidad con los servicios diferenciados y la notificación de congestión explícita. Los autores no anticipan que haya problemas cuando GENEVE y uno o más de los otros métodos de encapsulamiento estén en uso en el mismo sistema. Los extremos de túnel GENEVE se comunicarán solo entre sí y la infraestructura de red gestionará los paquetes de forma idéntica a cualquier otro paquete UDP. El formato de datos admite todas las capacidades de VXLAN, NVGRE y STT, por lo que con el tiempo es posible que se utilicen menos estos tres formatos. Dado que no se especifica un protocolo de plano de control, los autores esperan que sea admita cualquier protocolo en uso con los otros métodos de encapsulamiento. Una ventaja clave que tiene sobre los otros métodos de encapsulamiento es el formato de opción flexible de GENEVE y el uso de IANA (Internet Assigned Numbers Authority) para designar las clases de opciones. Los desarrolladores pueden incluir tantas opciones como deseen de forma dinámica, ya no están limitados a utilizar 24 bits ni deben incurrir en la sobrecarga de un campo de 64 bits cuando solo se necesita una fracción de ese tamaño.

La transición a GENEVE no será inmediata. Los otros métodos de encapsulamiento se utilizan desde hace algún tiempo y es posible usar varios métodos dentro del mismo sistema. Sin embargo, se está adoptando GENEVE como el protocolo de tunelización predeterminado para OVN (Open Virtual Network) que, a su vez, se promociona como una implementación de OVS (OpenvSwitch) en futuras versiones de OpenStack.

La experiencia con grandes nubes multiempresa sigue aumentando y es posible que ningún método de encapsulamiento se convierta en el estándar aceptado. Sin embargo, GENEVE es un gran candidato a recibir una amplia adopción gracias su formato de opción flexible y soporte para todas las capacidades de los otros métodos.

[[nid: 555451]]

Benjamin Schmaus es TAM de Red Hat Cloud en la región central de América del Norte. Está involucrado con Linux desde 1998 y ha apoyado entornos empresariales en varios sectores: comercio minorista, defensa, software, finanzas, educación superior y educación secundaria. Más recientemente, se ha centrado en permitir que nuestros clientes implementen, operen y admitan Red Hat OpenStack Platform y Red Hat Ceph Storage.

Los profesionales con el título de Red Hat Technical Account Manager (TAM) son especialistas en productos que trabajan en conjunto con las empresas de TI para planificar de forma estratégica el éxito de las implementaciones y para optimizar el rendimiento y el crecimiento. Los TAM forman parte del grupo internacional Customer Experience and Engagement de Red Hat y ofrecen orientación y recomendaciones preventivas para que usted pueda identificar y abordar los problemas posibles antes de que ocurran. En caso de que se produzca un inconveniente, el TAM se hará cargo del asunto y convocará a los mejores recursos para resolverlo tan pronto como sea posible, con una interrupción mínima de sus actividades comerciales.