Podcast #167: VXLAN – Virtual eXensible LAN

En los centros de datos con la llegada de la virtualización apareció un problema de escalabilidad bastante importante, ya que gracias a las posibilidades de la virtualización el número de servidores aumentó drásticamente. Y con el número de servidores aumentó obviamente el número de MACs y el número de VLANs. Esto hacía que la tabla de MACs creciera y que el número de VLANs permitido por protocolo (12 btis para el VLAN ID  en IEEE 802.1Q – 4094) se agotaran. Eso sin contar los problemas con el STP, recordad que por ejemplo RSTP sólo soporta 127 instancias.

Por otro lado la gestión tradicional en este tipo de entornos se complica enormemente y hubo que buscar una solución que permitiera escalar en servidores, en vlans y solventar el problema del STP en la medida de lo posible.

Una solución fue VXLAN y de VXLAN te voy a hablar en el capítulo de hoy, así que si te interesa vamos a dedicarle un ratillo.

Yo soy Eduardo, esto es eduardocollado.com y este es el capítulo número 167, VXLAN.

VXLAN es un protocolo que tuneliza tramas ethernet sobre UDP, luego entraré en más profundidad sobre esto, pero es importante que te lo comente de entrada porque esto significa que podemos tirar los túneles sobre una red de nivel 3, es decir, la redundancia de la red ya podemos darla gracias a protocolos de encaminamiento (routing), sin tener que recaer en STP y permitiendo el uso de varios caminos simultáneamente, es decir, podemos balancear el tráfico gracias al multipath que nos ofrecen protocolos como OSPF.

Increíble, no sólo nos hemos quitado de un plumazo los problemas de STP y de las VLANS sino que además ofrecemos una redundancia o balanceo.

Pero el concepto de VLAN sigue existiendo, en VXLAN tenemos un mecanismo para separar el tráfico de varios dominios de difusión, y es la utilización de VNI, el Virtual Network Identifier que es algo a la etiqueta de VLAN_ID, pero en vez de 12 bits, aquí tenemos 24, así que pasamos de 4000 vlans a casi 17 millones, una cifra nada desdeñable.

Esto no es mágico y no está exento de problemas, piensa por ejemplo que el mundo VXLAN en algún momento es muy probable que tenga que comunicarse con un mundo VLAN, pero ¿qué te parece a priori?, desde luego aquí la gente de VMWare obtuvo una ventaja sustancial sobre el resto, VMWare apostó muy fuerte por esta tecnología al principio y este fue uno de los factores para su éxito en los proveedores de servicio.

Antes te he dicho que VXLAN tunelizaba tramas ethernet sobre UDP (puerto 4789), pero siendo más correctos VXLAN lo que hace es emplear un encapsulado MAC Address-in-User Datagram Protocol (MAC-in-UDP). A una trama ethernet con una mac de origen y una mac de destino le añadimos la cabecera VXLAN, luego a esto le añadiremos como mac de origen y destino las macs (e ips) de los vxlan tunnel endpoint (VTEP) y UDP como protocolo de nivel 4, así podremos enviar las tramas en un datagrama UDP con origen y destino los dos extremos definidos del túnel.

En cuanto a la cabecera de VXLAN (50 bytes) es un poco absurdo explicar todos los campos y flags, pero sí que es interesante comentarte que hay un campo que es el Vxlan Network Identifier, que ya te he comentado que era de 24 bits, pero la gracia no acaba ahí, pues la identificación de un puerto es gracias a la MAC y al VNI, con lo cual significa que podemos tener la misma MAC en varias VNIs (ojo, que se pueda no significa que haya que hacerlo) y claro, en cada VLAN podemos tener 24 bits de VNI, así que el número de dominios de difusión podemos decir que es ilimitado, o mejor dicho que ya no va a ser un problema.

En cuanto a los túneles, tenemos que tener en cuenta que los VTEP de cada VXLAN tienen que estar suscritos a un mismo grupo de multicast en IGMP, podemos tener la misma VXLAN en 14 hipervisores distintos y tener 14 puntos diferentes, no pensemos en túneles punto a punto sino en puntos que se unen dentro de una misma red.

Los VTEP son los encargados de encapsular y desencapsular el tráfico VXLAN e incluso podemos tener algún VTEP que sea el que haga de gateway con una red no VXLAN, para unir con el exterior por ejemplo con un firewall externo.

Si te apetece vamos a ver todo esto como funciona realmente, vamos a poner las piezas de este rompecabezas en su sitio para fijar.

Antes de nada, te he dicho hace un momento que la cabecera de VXLAN tiene un tamaño de 50 bytes, y esto hay que añadirlo a la trama ethernet, así que en los switches involucrados tenemos que habilitar jumbo frames, además recordad que hay que habilitar también multicast, esto es muy importante y recordad que hay muchos switches que para habilitar las jumbo frames es necesario reiniciarlos, así que esto grabado a fuego.

Otro factor con el que hay que tener cuidado es con el retardo, porque el heartbeat en el Vmotion de VMWare está en 10 ms, así que hay que tener cuidado con eso, vigilad la documentación de vuestro hipervisor porque este dato cambia con las versiones y en las más antiguas si no recuerdo mal estaba en 5ms.

En definitiva, cuando vayas a implementar VXLAN en tu infraestructura leeté la documentación específica no vaya a ser que te encuentres alguna sorpresa no prevista anteriormente.

Para que un host en un hipervisor pueda comunicarse con otro host en otro hipervisor se utiliza la misma lógica que en ethernet normal, la única diferencia es que para consultar el ARP el host A enviará una trama a la dirección de broadcast que el VTE1 encapsulará en VXLAN y añadirá como dirección de destino la dirección de Multicast del grupo del VNI en concreto.

Con eso se continua el proceso.

En el caso de conocer la dirección mac del destino también se conoce el VTE2 y se pondrá como dirección mac de destino después de encapsular la mac del VTE2

 

 

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.