Redes VXLAN: una red entre maquinas virtuales, estén donde estén
El desarrollo de la tecnología de Redes VXLAN o redes virtuales extensibles por lo regular se asocia con la implementación de las plataformas de empresas proveedoras de servicio.
Sin embargo, la idea fundamental alrededor de VXLAN es aplicable a cualquier plataforma y surge para solventar un problema de diseño de redes con el cual quizás el lector se sienta identificado.
Muchos nos hemos visto en la situación de que, teniendo una plataforma distribuida y lidiando con un problema de rendimiento, hemos deseado poder simplificar de alguna manera el diseño, de forma que existiera una red virtual entre equipos ubicados en centros de datos distintos.
Justo para solventar esta situación es que surge VXLAN, que propone la creación de un nivel ¨virtual¨ de comunicación capa 2 o red extendida. Al final del día, la idea era aplicar el paradigma de la virtualización a la plataforma de redes y comunicaciones.
Mucho ha llovido desde esa primera idea y hoy en día las redes VXLAN, en conjunto a otras herramientas de virtualización de redes como EVPN (Ethernet Virtual Private Network), ha impactado en el desarrollo de la arquitectura de red idónea para empresas proveedoras de servicio.
La plataforma resultante permite a estas empresas, entre otros, atender a una gran cantidad de clientes, ofrecer a cada uno de ellos un buen nivel de aislamiento lógico y establecer procedimientos de escalado sencillos.
Por otro lado, las redes VXLAN han estado muy relacionadas con las redes definidas por software SDN. Lo que no es de extrañar, ya que ambos conceptos comparten el punto fundamental de ser el resultado de aplicar el paradigma de la virtualización al mundo de las redes.
De hecho, hay autores que consideran que VXLAN es una pieza fundamental para el desarrollo efectivo de redes definidas por software, planteando arquitecturas que incluyen ambas ideas.
Esta combinación se logra tomando de SDN la idea de separar la parte lógica de las redes de la parte física e implementar dicha parte física considerando los preceptos de VXLAN.
A los lectores interesados en esta relación SDN – VXLAN les recomendamos dos lecturas; en primer lugar nuestro post sobre SDN para retomar los fundamentos, y en segundo el artículo publicado a finales de 2017 por IEEE en el que se plantea una arquitectura de SDN basadas en VXLAN.
La solución VXLAN
VXLAN propone generar una red virtual, también llamada superpuesta u overlay, partiendo de una infraestructura de red LAN/WAN que funcionará como base.
Para la red overlay, VXLAN describe el protocolo de encapsulación y los procesos de creación de túneles necesarios para su funcionamiento.
En cuanto a la red de base, llamada subyacente o underlay, VXLAN presupone la existencia de una red donde todos los componentes activos son capa 3, es decir, son enrutadores que implementan algún protocolo dinámico como OSPF, EIGRP o IS-IS.
Ambas redes overlay y underlay se muestran en el siguiente diagrama:
Este diagrama muestra la idea fundamental de VXLAN de tener dos redes una overlay y otra underlay
Sobre la red underlay
Hablemos un poco más de la red de base o underlay.
Esta red, como ya adelantamos, se compone de dispositivos capa 3, es decir, enrutadores que utilicen de forma óptima los caminos o rutas disponibles.
La elección de la ruta óptima se hará en función de un esquema de igual costo o ECMP (equal cost multi-path protocol).
Es interesante apuntar que las redes underlay descartan la utilización del protocolo STP (Spanning Tree Protocol). Recordemos que STP tiene como principal objetivo evitar la creación de bucles en la transmisión de los paquetes.
En un escenario de dos posibles rutas de igual costo, la aplicación de Spanning Tree resultaría en la anulación de una de las rutas con todo el coste que esta decisión supone. Justamente este coste es el que las redes underlay intentan evitar.
Por supuesto, hay tecnología especialmente diseñada para implementar las redes underlay, tal como EVPN (Ethernet VPN), por ejemplo, que inicialmente surgió como la solución para cualquier esquema de encapsulación y que actualmente utilizan VXLAN y MPLS.
Al lector interesado en revisar lo correspondiente a la capa underlay y a EVPN le recomendamos leer este interesante artículo sobre el tema.
Sobre redes overlay VXLAN
Ahora concentrémonos en VXLAN.
La capacidad de segmentación que trae consigo el concepto tradicional de VLANs bajo el estándar 802.1Q tiene una limitación en la cantidad de VLANs que se pueden crear.
Esta cantidad está restringida por el tamaño del identificador de VLANs el cual es de 12 bits, por lo que el límite de VLANs se ubica en poco más de 4000 VLANs.
Así pues, si usted administra la infraestructura de un proveedor de servicios y decide entregar 4 VLANs por cliente tendrá un límite nada alentador de 1000 clientes posibles.
Para superar este límite, VXLAN utiliza como identificador de segmento una palabra de 24 bits, conocida como VNI (VXLAN Network Identifier), lo que permite disponer de algo más de 16 millones de VXLANs posibles.
Por otra parte, VXLAN, tal como ya hemos dicho, propone la creación de una red virtual capa 2, lo que otorga un nuevo nivel de abstracción.
En este nivel se mantiene la independencia entre las redes virtuales creadas o VNs. Esto es, que no existirá comunicación entre los elementos de diferentes VNs salvo que una regla de seguridad lo permita de forma explícita y un enrutador la implemente.
Además, se considera la posibilidad de definir una VN entre los dispositivos que se encuentran ubicados en diferentes centros de datos.
Así es que podríamos tener dos máquinas virtuales ubicadas en dos centros de datos diferentes pero que están integradas a la misma red virtual o a la misma VXLAN.
En el siguiente diagrama observe las dos máquinas virtuales destacadas que pertenecen a la misma red virtual.
este diagrama muestra cómo dos máquinas virtuales de centros de datos diferentes pueden estar integradas en una misma red virtual
Ahora bien, hablemos de los componentes: para su cometido VXLAN utiliza elementos denominados VTEP (VXLAN Tunneling End Point).
Los VTEPs proveen la conexión entre la red overlay y la red underlay y efectúan el proceso de encapsulación del tráfico.
Para esto, cada VTEP dispondrá de una dirección IP correspondiente a la red underlay y una o más direcciones VNIs correspondientes a las redes virtuales extendidas que puede manejar.
En cuanto a la encapsulación, cuando el paquete a ser transmitido llega al VTEP es encapsulado en los llamados jumbo frames, que contienen el paquete original proveniente de la máquina virtual más los siguientes encabezados:
- Encabezado VXLAN, el cual contiene el identificador de la VXLAN asociada
- Encabezado UDP, con información de los puertos UDP destino y origen. Destino: 4789. Origen calculado dentro del rango 49152 y 65535.
- Encabezado IP, con la dirección del VTEP destino o una dirección Multicast.
- Encabezado Ethernet, que contendrá la dirección MAC del siguiente dispositivo físico en la red underlay. Este encabezado será el único que cambiará a medida que el jumbo frame pase por los distintos enrutadores de la red underlay.
En la siguiente imagen se muestra el encapsulamiento tipo realizado por un VTEP:
se muestra la conformación de un jumbo frame con todos los encabezados agregados durante el proceso de encapsulación
Para completar el transporte de paquetes VXLAN asociados a una VN especifica, los VTEPs deberán crear un túnel virtual, el cual permanecerá activo lo suficiente para realizar la transferencia de dichos paquetes VXLAN.
Para identificar el VTEP destino con el cual se requiere establecer el túnel se siguen las mismas operaciones de cualquier red Ethernet, es decir, toda la secuencia asociada con el protocolo ARP, incluyendo el envío de paquetes Broadcast.
La diferencia está que al momento de recibir el paquete Broadcast ARP el VTEP origen encapsulará este paquete en un paquete multicast asociado al VNI correspondiente, de manera que el VTEP destino responda y el túnel pueda ser establecido.
En cuanto a la implementación de los VTEPs debemos decir que existen dos posibilidades:
- Dispositivos físicos: se pueden utilizar dispositivos como switches o enrutadores que dispongan de la interface VTEP.
- Elementos de software: se pueden utilizar los hipervisores que permiten crear y mantener las máquinas virtuales y que a la vez ejecutan el software de VTEP.
- En muchas implementaciones se encuentra una mezcla de ambas posibilidades, ofreciendo mucha flexibilidad teniendo en cuenta que no todos los switches y enrutadores del mercado soportan la funcionalidad de VTEP.
El lector que desee profundizar en los detalles técnicos asociados con VXLAN de seguro encontrará muy interesante el RFC 7348.
Retos asociados con VXLAN
La implementación de VXLAN trae consigo un nuevo grupo de elementos que pueden afectar el rendimiento de las aplicaciones; por lo tanto, la adecuación de los procesos de monitorización es vital.
Ahora bien, los retos en la monitorización de VXLAN parten con la pérdida de visibilidad que implica el disponer de dos redes superpuestas y un proceso de encapsulación previo al uso de toda la estructura de comunicaciones.
Considerando lo cual, podemos prever que será difícil aislar el tráfico que se intenta monitorizar, así como correlacionar correctamente el tráfico generado en la red overlay con el tráfico que corresponde en la red underlay.
Por otra parte está el trabajo con los jumbo frames, los procesos de fragmentación y los procesos de encriptado y desencriptado. Debemos considerar todo el efecto negativo que estos elementos pudieran tener sobre el rendimiento de la plataforma.
Otro punto interesante a evaluar detalladamente es el coste en tiempo y recursos que implica la creación de los túneles, ya que tal como prevé la definición de VXLAN este es un proceso dinámico y recurrente.
Por lo que en una plataforma VXLAN sería interesante monitorizar los paquetes multicast generados por los VTEPs, tablas ARP y el tiempo de establecimiento de los túneles.
Creemos que sería oportuno retomar el efecto que pudieran tener los paquetes Broadcast y multicast en el rendimiento de las plataformas, para lo cual les recomendamos revisar el siguiente post.
Finalmente, la monitorización de la plataforma VXLAN no tendría sentido de forma aislada; es indispensable considerar la plataforma como un todo y adecuar los procesos de monitorización a esta estructura.
Siendo el destinatario natural de las plataformas VXLAN las empresas proveedoras de servicio, las cuales por lo regular disponen de plataformas complejas donde la automatización, la escalabilidad y flexibilidad son objetivos fundamentales, es crucial disponer de herramientas de monitorización adecuadas.
Para estos casos Pandora FMS ha desarrollado una solución pensada justo para los proveedores de servicio, y por supuesto les invitamos a investigar más sobre todas sus capacidades y ventajas.
Para ello, les recomendamos visitar este enlace, solicitar toda la información que requieran y hablarnos sobre su proyecto.
