Usuario:Carlos.perezrivas/Taller

De Wikipedia, la enciclopedia libre

VXLAN (Virtual Extensible Local Area Network) es un protocolo de superposición de redes ideado para transportar tráfico de Capa de enlace de datos sobre la Capa de red, concretamente tráfico Ethernet sobre redes IP empleando encapsulación MAC-in-UDP. Inicialmente fue ideado para proveer los mismos servicios que una red VLAN convencional aumentando la extensibilidad y la flexibilidad limitadas de este tipo de redes.

Actualmente se encuentra documentado por el IETF en el RFC 7348 en estado "Informational".


Introducción[editar]

VXLAN surgió como propuesta por parte de varios fabricantes como Arista Networks, Broadcom, Intel, VMware [1]​[2]​ y otros para evitar algunos de los problemas que se daban en los centros de datos derivados del empleo de virtualización en los servidores, lo que impone la necesidad de trabajar en entornos con cientos de miles de máquinas virtuales en algunos casos. Trabajar con tantas máquinas genera problemas relacionados con el tamaño de las tablas de direcciones MAC, y en el caso del empleo de VLANs para agrupar estas máquinas aislándolas en grupos surge el problema del número limitado de VLANs que se pueden generar debido al VLAN ID de 12 bits, que permite un máximo de 4094 redes diferentes.

Otro problema importante de los centros de datos proviene del empleo de STP (Spanning Tree Protocol) para evitar los bucles en la capa de enlace, lo que conlleva al desuso de una gran cantidad de los enlaces disponibles (En ocasiones más de la mitad) al generarse la topología en forma de árbol.

Todos estos problemas impulsaron el desarrollo de una tecnología de red que permitiese emplear una red IP para la interconexión de los servidores físicos, lo que supondría el uso de protocolos de enrutamiento de capa 3. De esta forma se eliminarían los problemas de desuso de enlaces impuestos por STP, los bucles de capa 2 y se podrían emplear "estrategias" de enrutamiento como Equal-cost multi-path routing (ECMP), que ayuda a distribuir la carga de la red entre todos los enlaces.[3]​ A pesar de todo esto seguiría siendo necesario el empleo de una red de capa 2 para la comunicación directa entre las máquinas virtuales.

Esto impulsó finalmente la aparición de VXLAN, que nos permite eliminar los problemas de escalabilidad de la red derivados del uso de VLAN mediante el empleo de un identificador de red (VNI) de 24 bits, pudiendo crear así más de 16 millones de redes virtuales que coexistan en el mismo dominio administrativo.[4]​ En VXLAN se emplea encaminamiento de capa 3, lo que elimina los problemas de desuso de enlaces mencionados anteriormente y permite un uso más eficiente de estos enlaces. El empleo de protocolos de encaminamiento de capa de red también elimina los problemas del tamaño excesivo que alcanzaban tablas de direcciones MAC en los switches que interconectaban una red de capa 2 en un centro de datos, los cuales tenían que almacenar las direcciones MAC de todas las máquinas virtuales instaladas en los servidores que se encontraban interconectados mediante ese switch.


Encapsulación y formato de paquete VXLAN[editar]

VXLAN emplea encapsulación MAC Address-in-User Datagram Protocol (MAC-in-UDP). Al paquete de Capa de enlace enviado inicialmente, que contiene las direcciones MAC del host origen y del host destino, se le añade una cabecera VXLAN. El conjunto anterior se introduce en el campo de datos de un datagrama UDP y se emplea IP como protocolo de Capa de red. Finalmente el paquete que se manda a la red IP tiene como direcciones MAC origen y destino las correspondientes a los VTEPs tras los cuales se encuentran los hosts origen y destino. De esta forma es posible encaminar el paquete inicial sobre una red IP, de manera que este pueda alcanzar a todos los hosts de la VXLAN de igual forma que si se encontrasen en la misma LAN.

Encapsulación VXLAN


Componentes de VXLAN[editar]

Cabecera VXLAN

- Cabecera VXLAN: Tiene una longitud de 8 bytes y está compuesta por cuatro campos:

  • Flags: Campo de 8 bits que contiene la secuencia de flags “R-R-R-R-I-R-R-R”. El flag denominado “I” debe contener el valor “1” para indicar un VNI válido. El resto de bits (“R”) deben contener el valor “0” a la hora de transmitir la trama y son ignorados en la recepción.
  • VXLAN Network Identifier (VNI o VNID): Se trata de un campo de 24 bits mediante el cual se identifica cada red de “Overlay”, lo que nos permite crear más de 16 millones de segmentos VXLAN en el mismo dominio administrativo. Cada VXLAN tiene un VNI diferente y cada máquina perteneciente a una VXLAN está identificada por su MAC y por su VNI, por lo que es posible tener máquinas con direcciones MAC duplicadas en distintas redes VXLAN.
  • Campos reservados: Existen dos campos reservados en la cabecera VXLAN. Uno de ellos está situado entre el campo de flags y el campo VNI y el otro se encuentra situado al final de la cabecera VXLAN. Estos campos tienen una longitud de 24 y 8 bits respectivamente, ambos deben ser enviados con valor "0" y son ignorados en la recepción del paquete. [5]​ [6]​


- VXLAN Tunnel End Point (VTEP): Se trata de una entidad que origina y termina “túneles” VXLAN, y es la encargada de encapsular las tramas Ethernet de cada red física perteneciente a una VXLAN para transportarlas sobre una red IP hacia el resto de VTEPs pertenecientes al grupo multicast de la red virtual. De igual forma se encarga de desencapsular los paquetes IP recibidos y almacena las tablas de encaminamiento necesarias para la comunicación entre los hosts conectados a ese VTEP y el resto de hosts de la red virtual.

Cada VTEP tiene al menos dos interfaces: Una de ellas es la interfaz para el segmento de área local y se encarga de proveer servicio a los sistemas finales que están directamente conectados al VTEP. La otra es una interfaz IP que se encarga de encapsular las tramas del segmento de área local para poder transmitirlas sobre una red IP hacia el resto de VTEPs pertenecientes a la red virtual. Para ello es necesario que todos los dispositivos VTEP de una misma VXLAN se unan a un grupo multicast mediante el protocolo IGMP (Internet Group Management Protocol). Al emplearse encaminamiento basado en la dirección IP externa de cada VTEP las diferentes redes locales físicas que forman una red VXLAN son independientes a la topología que las une y pueden comunicarse entre ellas como si se encontrasen en la misma red física. [7]​

- VXLAN Gateways: Se trata de un dispositivo VTEP que permite la comunicación entre nodos que soportan y que no soportan el protocolo VXLAN. De esta manera los dispositivos que no soporten esta tecnología pueden permanecer en segmentos VLAN clásicos y emplear un VXLAN Gateway para formar un dominio común de capa de enlace con una red VXLAN. Un VXLAN Gateway también puede ofrecer servicios avanzados de conectividad y seguridad a la red VXLAN, como por ejemplo proporcionando funcionalidades de NAT (dando acceso hacia la red exterior), actuando como Firewall, servidor DHCP y DNS entre otras cosas. [8]​


Para formar un paquete VXLAN también son necesarias las siguientes cabeceras:

  • Cabecera externa UDP que contenga el puerto origen del VTEP y el puerto destino (Definido por el IANA el puerto 4789 como puerto UDP por defecto en VXLAN). [9]​
  • Una cabecera externa IP que contenga las direcciones IP del VTEP origen y del VTEP destino necesarias para encaminar el paquete sobre la red IP. La dirección IP destino puede ser una dirección unicast o multicast dependiendo de si el VTEP origen conoce o no la dirección del VTEP al que pertenece el dispositivo al que va dirigido el paquete.
  • Cabecera externa Ethernet que contiene las direcciones MAC origen y destino de los VTEP para que puedan comunicarse entre ellos. [10]​

Tanto la cabecera UDP como IP proporcionan adicionalmente un campo checksum para verificar la integridad de los datos del paquete.

Por último, para establecer una red VXLAN es necesario que la red IP sobre la que se encaminen los paquetes soporte funcionalidades de encaminamiento multicast como IGMP y PIM, protocolos de encaminamiento como OSPF y BGP y protocolos de estado de enlace como IS-IS.

Funcionamiento de VXLAN[editar]

El funcionamiento de VXLAN se basa principalmente en encapsular el tráfico de capa de enlace de una red de área local y transportarlo sobre una red IP hasta otra LAN física diferente, consiguiendo así que los hosts de ambas redes se puedan comunicar de igual manera que si se encontrasen en la misma red de área local. Para conseguir esto se emplean “túneles” entre los distintos VTEPs por los cuales se transmite el tráfico de “overlay”, de forma que este llegue al otro extremo en el mismo estado en el que se encontraba en la red LAN origen.

Túnel entre dos VTEP

En cada red LAN los hosts pertenecientes a la VXLAN se encuentran conectados a un VTEP. Este dispositivo será el encargado de encapsular las tramas de los hosts de un segmento VXLAN y encaminarlas por la red IP para que lleguen al resto de dispositivos de la VXLAN.

Cada segmento VXLAN está identificado por su VNI (VXLAN Network Identifier). En base a este VNI el VTEP se encargará de que los paquetes solo sean enviadas a los hosts que pertenezcan a un mismo segmento VXLAN. Para ello se emplea el protocolo IGMP, todos los VTEP de un mismo segmento VXLAN se suscriben a un grupo multicast, de manera que solo se envíen entre ellos los paquetes relativos a ese segmento VXLAN.

Cada vez que un host de la VXLAN envía una trama cuyo destino es otro host del mismo segmento VXLAN el VTEP encapsula la trama añadiéndole las cabeceras correspondientes y lo envía sobre la red IP de manera que alcance el VTEP tras el cual se encuentra el host destino.

Para realizar el encaminamiento sobre la red IP cada VTEP almacena en sus tablas de encaminamiento la correspondencia de cada MAC de un host con la IP del VTEP al que le debe enviar el paquete si quiere alcanzar dicho host. Esto hace que se puedan producir dos situaciones distintas a la hora de querer enviar un paquete a un host:

  • El VTEP tiene almacenadas en sus tablas la IP del VTEP y la MAC del host destino: En este caso la comunicación es unicast y por tanto el VTEP origen envía la trama directamente al VTEP destino.
  • El VTEP no conoce la correspondencia de la dirección MAC del host destino con la IP del VTEP destino: En este caso se lleva a cabo un envío multicast, de manera que el VTEP manda el paquete a todos los VTEP que pertenezcan a ese segmento VXLAN con el objetivo de alcanzar finalmente al host destino.

En el caso de emplear la comunicación multicast cada VTEP involucrado en la comunicación almacenará en sus tablas las direcciones correspondientes a ese intercambio de paquetes, de forma que los próximos paquetes podrán ser enviados empleando una comunicación unicast.[11]​

Comunicación Unicast:[12]​[13]​[14]​[editar]

Ejemplo de comunicación unicast en VXLAN:[editar]

Basándonos en un esquema como el de la Figura 1, en el que existen dos hosts dentro de un mismo segmento VXLAN, encontrándose estos en diferentes redes de área local, y suponiendo que ambas máquinas conocen de antemano las direcciones de la otra máquina y cada VTEP sabe como comunicarse con el otro VTEP. Si uno de los hosts intentase comunicarse con el otro se seguiría la secuencia siguiente:

Figura 1: Ejemplo de red VXLAN con reenvío unicast


  1. El Host-A envía sobre la red de área local una trama MAC cuya dirección MAC destino es la del Host-B, de igual manera que lo haría en un escenario LAN normal.
  2. El VTEP-1 recibe la trama y comprueba el VNI que el Host-A tiene asociado. Tras esto se determina si la dirección MAC destino se encuentra en el mismo segmento de red o si existe una entrada en las tablas de encaminamiento que relacione esta dirección MAC con la de otro VTEP en cuya red física se encuentra la máquina destino.
  3. El VTEP-1 encuentra en sus tablas que la dirección del Host-B se encuentra asignada a la dirección IP del VTEP-2. Por lo tanto añade a la trama original una cabecera VXLAN con el VNI de la red virtual a la que pertenecen los hosts, una cabecera IP con las direcciones IP externas del VTEP-1 y VTEP-2 como origen y destino respectivamente, y una cabecera MAC externa que contiene las direcciones MAC origen y destino de los VTEP. Finalmente reenvía la trama por la red IP hacia el VTEP-2.
  4. El VTEP-2 recibe la trama y verifica si el VNI de la cabecera VXLAN es válido y si existe algún host en su red física que pertenezca a esa VXLAN y tenga como dirección MAC la dirección destino del paquete encapsulado en la trama recibida.
  5. El VTEP-2 encuentra que el Host-B coincide con estos datos y por tanto desencapsula la trama recibida eliminando las cabeceras externas y reenvía el paquete al Host-B.
  6. Adicionalmente el VTEP-2 aprende la relación entre la dirección MAC origen interna (Dirección del Host-A) y la dirección IP externa (Dirección del VTEP-1) y las guarda en su tabla de encaminamiento. De esta forma cuando el Host-B responda al mensaje no será necesario descubrir la correspondencia del Host-A con el VTEP-1.



En todo el proceso no es necesario que ninguno de los hosts sea consciente de que se está comunicando con una máquina que no se encuentra en su red física. Los hosts tampoco tienen por qué saber que forman parte de una VXLAN. El VTEP almacena el VNI correspondiente a cada host al que se encuentra conectado y por lo tanto es capaz de enviar los paquetes de un determinado host a otro de la red virtual a la que pertenece sin que ninguno de los puntos finales tenga que llevar a cabo un comportamiento distinto al que tendría en una red LAN clásica.


Comunicación multicast:[15]​[16]​[editar]

Consideraremos en este caso que la máquina que intenta comunicarse con otra no conoce la correspondencia MAC con IP destino y que el VTEP encargado de encaminar el paquete IP no tiene en sus tablas de encaminamiento la información necesaria para saber a que VTEP le tiene que reenviar la trama para que esta llegue al dispositivo destino. Para evitar inundar la red IP con tráfico broadcast se emplea tráfico multicast, de esta manera solo se envían paquetes a los VTEP que pertenecen a un grupo multicast determinado.

Dado que el dispositivo origen no conoce la MAC destino enviará una trama ARP request usando como dirección MAC destino la dirección de broadcast. El VTEP recibirá la trama, le añadirá la cabecera VXLAN conteniendo el VNI correspondiente a la red junto con las cabeceras IP y UDP y reenviará la trama al grupo multicast al que pertenece la red VXLAN.

Los VTEP pertenecientes al grupo multicast recibirán la trama y la reenviarán a sus redes locales, por lo que esta alcanzará finalmente al host destino. En todo el proceso los diferentes dispositivos intermedios habrán almacenado en sus tablas de encaminamiento todas las direcciones necesarias para poder comunicarse con el host origen, por lo tanto a la hora de encaminar la respuesta (ARP reply) se empleará una dirección IP unicast como destino.

Para que todo esto funcione es necesario que cada VTEP conozca la relación del VNI con el grupo multicast al que pertenece, lo que se consigue configurando cada VTEP por separado mediante un canal de administración. De esta manera un VTEP puede informar a su router de salida a la red IP sobre la unión a un nuevo grupo multicast o la salida de uno empleando el protocolo IGMP, lo que puede resultar interesante en un entorno en el que al VTEP se conectan y desconectan con frecuencia máquinas pertenecientes a distintos segmentos VXLAN. Un ejemplo práctico es la movilidad de las máquinas virtuales de un centro de datos.

Como protocolo de encaminamiento entre los miembros del grupo multicast se emplea PIM (Protocol Independent Multicast). Cabe mencionar que algunas de las implementaciones de VXLAN permiten a los VTEPs pertenecer a varios grupos multicast diferentes a la vez.

Ejemplo de comunicación multicast en VXLAN:[editar]

En el esquema de la Figura 2 se pueden apreciar tres VTEP pertenecientes al mismo grupo multicast, lo que limitará la inundación de tramas a los dispositivos pertenecientes al mismo segmento VXLAN evitando así congestionar el resto de la red.

Secuencia de comunicación multicast en la que el Host-A quiere comunicarse con el Host-B basándonos en el esquema de la Figura 2:

Figura 2: Ejemplo de red VXLAN con reenvío multicast
  1. El Host-A quiere comunicarse con el Host-B, pero no conoce su direccón MAC. Envía por tanto un ARP request con dirección destino IP-B sobre su red VXLAN de capa dos con el propósito de recibir un ARP reply por parte del Host-B del cual pueda aprender su dirección MAC.
  2. El VTEP-1 recibe la trama y comprueba si conoce la correspondencia de la IP-B con la IP del VTEP tras el que se encuentra esta dirección. Como no la conoce encapsula la petición ARP en un paquete IP multicast y lo envía al grupo multicast de la red VXLAN. El paquete IP multicast tiene como dirección IP origen la del VTEP-1 y como dirección destino la del grupo multicast al que pertenece la VXLAN.
  3. El paquete llega a todos los VTEPs que pertenecen al grupo multicast. Todos ellos desencapsulan el paquete y comprueban el VNI de la cabecera VXLAN. Como el VNI coincide con el de su segmento VXLAN los VTEP reenvían la petición ARP a sus redes de área local. Durante el proceso cada VTEP del grupo multicast aprende la dirección IP del VTEP-1 que contiene la cabecera IP externa, e inspeccionan la cabecera interna para aprender la dirección MAC del Host-A. Finalmente guardan esta correspondencia en sus tablas de direcciones.
  4. El Host-B recibe el ARP request que le ha enviado el VTEP-2 y responde a la petición con un ARP reply que contiene su dirección MAC. En el proceso el Host-B ha aprendido la dirección MAC del Host-A, por lo que la dirección MAC destino ya no es la de broadcast.
  5. El VTEP-2 recibe la respuesta del Host-B. Ahora conoce la correspondencia de la MAC del Host-A con la IP del VTEP-1, por lo que encapsula el paquete del Host-B y lo reenvía como un paquete unicast hacia el VTEP-1. Este paquete tiene como dirección IP origen la del VTEP-2.
  6. El VTEP-1 recibe la respuesta ARP encapsulada enviada por el VTEP-2 y aprende su dirección IP de la cabecera IP externa. Desencapsula el paquete y reenvía la respuesta ARP al Host-A.
  7. El Host-A recibe el ARP reply y aprende la dirección MAC del Host-B, por lo que ya se puede comunicar con este host.

Los siguientes paquetes que se envíen entre los Hosts A y B serán reenviados como paquetes unicast por los VTEPs 1 y 2 debido a que estos han aprendido las direcciones necesarias para no tener que volver a emplear reenvío multicast. De manera opcional, dado que los VTEPs 1 y 2 han aprendido las direcciones MAC de los hosts B y A respectivamente pueden actuar como Proxy ARP, evitando así nuevas peticiones de las MAC de estos dos hosts.


Consideraciones de seguridad[editar]

Por norma general una red local de capa de enlace solo puede ser atacada por un nodo malicioso que se encuentre dentro de la red. En el caso de una red VXLAN el hecho de transportar el tráfico de capa dos sobre una red IP hace que la red sea susceptible a ser atacada por nodos maliciosos que no pertenezcan a la red local.

Un posible peligro es que un atacante se suscriba al grupo multicast de un segmento VXLAN y por tanto pueda recibir el tráfico multicast enviado por la red o insertar paquetes con destino ese grupo multicast en la red de transporte.

Para aumentar la seguridad de la red de transporte se proponen medidas como el empleo de IPsec en los paquetes que se envían por la red, lo que permite autenticar y encriptar el tráfico VXLAN, impidiendo así los problemas mencionados anteriormente.

Otra recomendación para el aumento de la seguridad en el ámbito local de una VXLAN es designar una VLAN sobre la que se envíe el tráfico VXLAN que se genera entre los VTEPs y los hosts de la red local. De esta manera solo los hosts configurados para pertenecer a la VLAN tendrán acceso al tráfico VXLAN de la red de área local, a diferencia de si se emplease una LAN clásica. También sería necesario tener un buen control por parte de una entidad administrativa de los hosts que pertenecen a la red LAN. [17]​


Referencias[editar]

  1. ↑ Timothy Prickett Morgan (30 August 2011). «VMware, Cisco stretch virtual LANs across the heavens». The Register. Consultado el 20 de noviembre de 2016. 
  2. ↑ «Arista and VMware have coauthored a new standard in cloud networking: the Virtual eXtensible LAN (VXLAN)». Consultado el 20 de noviembre de 2016. 
  3. ↑ «Virtual Extensible LAN (VXLAN) Best Practices White Paper». Consultado el 20 de noviembre de 2016. 
  4. ↑ «Virtual Extensible LAN (VXLAN) Best Practices White Paper». Consultado el 20 de noviembre de 2016. 
  5. ↑ «VXLAN: conceptos, funcionamiento e implementación (1/2)». Consultado el 26 de noviembre de 2016. 
  6. ↑ «VXLAN Encapsulation and Packet Format». Consultado el 26 de noviembre de 2016. 
  7. ↑ «Entendiendo VXLAN». Consultado el 26 de noviembre de 2016. 
  8. ↑ M. Mahalingam, D. Dutt, K. Duda, P. Agarwal, L. Kreeger, T. Sridhar, M. Bursell, C. Wright (August 2014). «RFC7348: Section 6: VXLAN Deployment Scenarios». Consultado el 26 de noviembre de 2016. 
  9. ↑ M. Mahalingam, D. Dutt, K. Duda, P. Agarwal, L. Kreeger, T. Sridhar, M. Bursell, C. Wright (August 2014). «RFC7348: Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks». Consultado el 26 de noviembre de 2016. 
  10. ↑ M. Mahalingam, D. Dutt, K. Duda, P. Agarwal, L. Kreeger, T. Sridhar, M. Bursell, C. Wright (August 2014). «RFC7348: Section 5: VXLAN Frame Format». Consultado el 26 de noviembre de 2016. 
  11. ↑ M. Mahalingam, D. Dutt, K. Duda, P. Agarwal, L. Kreeger, T. Sridhar, M. Bursell, C. Wright (August 2014). «RFC7348: Section 4: VXLAN». Consultado el 3 de diciembre de 2016. 
  12. ↑ Arista Networks,. «VXLAN Overview». Consultado el 27 de noviembre de 2016. 
  13. ↑ Patricio Cerda (9 de noviembre de 2016). «NSX: Modos de replicación VXLAN». Consultado el 27 de noviembre de 2016. 
  14. ↑ M. Mahalingam, D. Dutt, K. Duda, P. Agarwal, L. Kreeger, T. Sridhar, M. Bursell, C. Wright (August 2014). «RFC7348: Section 4.1: Unicast VM-to-VM Communication». Consultado el 27 de noviembre de 2016. 
  15. ↑ Cisco. «Layer 2 Mechanisms for Broadcast, Unknown Unicast, and Multicast Traffic». Consultado el 2 de diciembre de 2016. 
  16. ↑ M. Mahalingam, D. Dutt, K. Duda, P. Agarwal, L. Kreeger, T. Sridhar, M. Bursell, C. Wright (August 2014). «RFC7348: Section 4.2: Broadcast Communication and Mapping to Multicast». Consultado el 2 de diciembre de 2016. 
  17. ↑ M. Mahalingam, D. Dutt, K. Duda, P. Agarwal, L. Kreeger, T. Sridhar, M. Bursell, C. Wright (August 2014). «RFC7348: Section 7: Security Considerations». Consultado el 3 de diciembre de 2016. 

Enlaces Externos[editar]

Obtenido de «https://es.wikipedia.org/w/index.php?title=Usuario:Carlos.perezrivas/Taller&oldid=95494884»