Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Redes Vxlan
Redes Vxlan
NIVEL: 8vo A
FECHA: 30/07/2018
1. DOCUMENTACION
1.1. Tema: VXLAN (Virtual Extensible Local Area Network)
1.2. Objetivo Principal: Desarrollar tanto la parte teorica y practica acerca del protocolo de
extensión virtual de redes de área local (VXLAN).
1.3. Objetivos específicos:
Realizar una breve introducción acerca de los conceptos básicos de vxlan para poder
comprender los conceptos más complejos.
Consultar acerca de los principales protocolos y estándares que forman parte de la
arquitectura de Vxlan.
Investigar las circunstancias dentro de la red en la cual es oportuna la implementación
de este protocolo.
Explicar a breves rasgos la relación entre vxlan y snx.
Desarrollar una topología en donde se implemente dicho protocolo haciendo uso del
emulador GNS3 y el switch multilayer Cumulus VX.
2. INTRODUCCION
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.
Surgió como propuesta por parte de varios fabricantes como Arista Networks, Broadcom, Intel,
VMware 12 y otros para evitar algunos de los problemas (el limitado numero de vlan’s , el uso poco
eficiente de los enlaces, debido al protocolo sapnning-tree) 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.
VXLAN 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.3 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.
2.2. Componentes de VXLAN
Encapsulación y formato de paquete VXLAN: 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.
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.
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 VTEP’s 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.
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 VTEP’s 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).
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.
En este escenario tenemos dos máquinas virtuales, VM1 y VM2 (aunque pueden ser miles o millones) que
están en segmentos físicamente diferentes, separadas por un core de capa 3 (como puede ser, por ejemplo, una
red MPLS o Internet mismo). Ambas máquinas necesitan conectarse a la misma VLAN y utilizar la misma
subred IP en ambos casos. Estas dos máquinas virtuales pueden trabajar en la misma subred en ambos
extremos al utilizar VXLAN como transporte overlay, aún cuando ambos dominios de capa 2 (L2) están
separados por múltiples dispositivos de capa 3. VXLAN es una tecnología de túnel, al igual que GRE, PPPoE,
6to4, etc. Que sea túnel significa que se toma un paquete o una trama original, con sus encabezados completos
y se trata como la carga útil (payload) de un paquete o trama nueva.
Los siguientes son algunos de los protocolos clave que se usan en una red compatible con multidifusión
Protocolo de gestión de grupos de Internet (IGMP v1, v2, v3). IGMP administra grupos de
multidifusión utilizando mensajes de consulta e informe.
Protocolos de enrutamiento de multidifusión - PIM - modos diferentes (dispersos, densos)
Los dispositivos de red utilizan estos protocolos para conocer qué nodos se han unido a qué grupos de
multidifusión y dónde están los nodos en la red.
Cuando se trata de VXLAN, los requisitos de soporte de multidifusión en la red física están dictados por el
número de VLAN de transporte utilizado en el diseño. Como se estudio en clase, la VLAN de transporte
transporta tráfico encapsulado en VXLAN. Si está utilizando una sola VLAN de transporte, entonces no hay
necesidad de un protocolo de enrutamiento de multidifusión (PIM). Sin embargo, necesita las siguientes
funciones habilitadas en los conmutadores y enrutadores
Debido a que vxlan es un protocolo overlayer, trabaja en capa tres, para lo cual emplea los protocolos de
multicast para poder llevar a cabo la comunicación entre los diferentes dispositivos terminales remotos dentro
de la red, a continuación explicare como se opera los protocolos de multicast dentro de vxlan, en el siguiente
ilustracion, VXLAN 5001 es una red lógica de Capa 2 que abarca cuatro hosts. Las máquinas virtuales que se
ejecutan en el Host 1 y el Host 4 están conectadas a la misma red lógica (VXLAN 5001).
La pregunta es cómo se maneja el tráfico de difusión en la red lógica. Cualquier paquete de difusión de un
dispositivo conectado a la red lógica debe llegar a todos los dispositivos en esa red. Por ejemplo, en el
siguiente diagrama, si la máquina virtual 1 en el Host 1 envía un paquete de difusión, ese paquete debe
alcanzar la máquina virtual que se ejecuta en el Host 4. Como puede ver, el paquete debe atravesar los VTEP
y la red física para llegar al máquina virtual ejecutándose en el Host 4, hay pocas opciones de comunicación
disponibles para VTEP en el host 1 cuando se trata de entregar paquetes de difusión desde la red lógica.
Puede usar unidifusión, difusión o multidifusión. La multidifusión es mucho más eficiente al utilizar los
recursos de la red física y se usa cuando se envía un paquete de difusión desde la red lógica.
Para el despliegue de VXLAN con una red lógica , expondré de manera detallada cómo fluye el paquete a
través del VTEP y la red física. Tomaremos el mismo ejemplo de una red lógica que abarca 4 Hosts. La
topología física proporciona una sola VLAN 2000 para transportar el tráfico de transporte VXLAN. En este
caso, solo IGMP snooping e IGMP querier se configuran en la red física. Al igual que vimos en la clase de
multicast aquí con la operación de multidifusión , primero deben ocurrir pocas cosas antes de que los
dispositivos de red física manejen los paquetes de multidifusión.
Para Los Flujos de paquetes IGMP, En la ilustración de arriba, los círculos azules con número indican el flujo
de paquetes: La máquina virtual (MAC1) en el Host1 está conectada a la red lógica de Layer 2 Network
VXLAN 5001 y está encendida. VTEP en el Host 1 envía un mensaje de IGMP join a la red y se une a la
dirección del grupo de multidifusión 239.1.1.100 que está asociada con la red lógica VXLAN 5001. De
manera similar, la máquina virtual (MAC2) en el Host 4 está conectada a VXLAN 5001 y está encendida.
VTEP en el Host 4 envía un mensaje de unión IGMP a la red y se une a la dirección del grupo de
multidifusión 239.1.1.100 que está asociada con la red lógica VXLAN 5001
Los VTEPs Host 2 y Host 3 no se unen a la dirección del grupo de multidifusión porque no tienen máquinas
virtuales ejecutándose y que estén conectadas a la red lógica VXLAN 5001. Aquí es donde se observa la
optimización de multidifusión. Solo los VTEP que estén interesados en escuchar el tráfico de grupo de
multidifusión se unen al grupo.
Cuando un paquete de difusión es generado por una máquina virtual en el Host 1, así es como el paquete fluye
a través de la topología física y se entrega a la máquina virtual que se ejecuta en el host 4.
Así es como se usa multicast para entregar el tráfico de broadcast generado en cualquier red lógica. Los otros
dos tipos de tráfico en la red lógica que harán uso de multidifusión en la red física son:
Todos los otros tipos de comunicación en la red lógica se manejan a través de la ruta de unicast normal en la
red física.
La finalidad de este tipo de protocolo es de extender el alcance de las Vlans, razón por la cual se varios
fabricantes tiene tecnologías similares pero siempre con la misma finalidad, tenemos a:
En su mayor parte, los dispositivos de red procesan el tráfico VXLAN de forma transparente. Es decir, el
tráfico encapsulado IP se conmuta o enruta como cualquier tráfico IP. Las pasarelas VXLAN, también
llamadas puntos de extremo de túnel virtual (VTEP), proporcionan el encapsulamiento /
desencapsulación servicios centrales para VXLAN. VTEPS puede ser puentes virtuales en el hipervisor,
aplicaciones VM con reconocimiento VXLAN o conmutación con capacidad VXLAN hardware.
Los VTEP son la clave para virtualizar redes a través de la infraestructura existente del centro de datos.
Cada segmento de red VXLAN está asociado con un identificador de red VXLAN único de 24 bits, o
VNI. El espacio de direcciones de 24 bits permite escalando redes virtuales más allá de la 4096
disponible con 802.1Q a 16.7 millones de redes virtuales posibles.
Sin embargo, multicast y las limitaciones de hardware de red reducirán la cantidad utilizable de redes
virtuales en la mayoría de las implementaciones. VMs en un dominio L2 lógico usa la misma subred y
está mapeado a un VNI común. Es la asignación de L2 a VNI que permite a las VM comunicarse entre
sí. Tenga en cuenta que VXLAN no cambia los esquemas de direccionamiento de la capa 3. Las reglas
de direccionamiento IP empleadas en un L2 físico todavía se aplican a la red virtual
5. Vxlan y nsx
Los switches Top-of-Rack (ToR) han estado adaptando VXLAN durante un tiempo, trabajando para una pila
completamente integrada con la capa física y virtual para administrarse como una sola. Vendedores como
Arista , Brocade , Cumulus , HP y Juniper han estado integrando sus conmutadores de hardware con una red
VXLAN abierta, lo que les permite funcionar como puntos finales de túnel VXLAN (VTEP) dentro de la red
de transporte NSX. En una implementación estándar de NSX, solo sus hosts ESXi participarán en la red
VXLAN, lo que permite que el tráfico VXLAN solo se realice entre hosts ESXi. Al integrar los interruptores
de ToR en esta red de transporte, el hardware de la red se dará cuenta de la existencia de las redes virtuales y
abrirá su red a infinitas posibilidades para integrar la capa física y virtual.
Con 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).
6. Desarrollo de la parte practica
La topología
COMPROBACION
Ping 10.10.20.20
net show bridge vlan
Configuración
VXLAN
=======================
leaf01
=======================
net add loopback lo ip address 1.1.1.1/32
net add interface swp1 ip address 200.10.10.1/30
net add interface swp2 ip address 200.10.10.5/30
net pending
net commit
net add bridge bridge ports swp3
net add bridge alias layer2_bridge
net add interface swp3 bridge access 10
net add bridge bridge vlan-aware
net pending
net commit
net add bridge bridge ports swp4
net add bridge alias layer2_bridge
net add interface swp4 bridge access 20
net add bridge bridge vlan-aware
net pending
net commit
net add vlan 100 ip address 172.16.10.1/24
net pending
net commit
net add vlan 200 ip address 10.10.20.1/24
net pending
net commit
net add interface swp5 ip address 10.0.3.1/32
net commit
net add interface swp6 ip address 10.0.4.1/32
net commit
net add bgp autonomous-system 65000
net add bgp router-id 1.1.1.1
net add bgp neighbor 200.10.10.2 remote-as 65001
net add bgp neighbor 200.10.10.6 remote-as 65001
net add bgp ipv4 unicast network 1.1.1.1 activate
net add bgp redistribute connected
net pending
net commit
net add vxlan vni-1010 vxlan id 1010
net add vxlan vni-1010 bridge access 10
net add vxlan vni-1010 vxlan local-tunnelip 10.0.3.1
net add vxlan vni-1010 mtu 9152
net pending
net commit
net add vxlan vni-1020 vxlan id 1020
net add vxlan vni-1020 bridge access 20
net add vxlan vni-1020 vxlan local-tunnelip 10.0.4.1
net add vxlan vni-1020 mtu 9152
net pending
net commit
net add bgp evpn neighbor 200.10.10.2 activate
net add bgp evpn neighbor 200.10.10.6 activate
net add bgp evpn advertise-all-vni
net add bgp evpn vni 1010 rd 1.1.1.1:1010
net add bgp evpn vni 1010 route-target import 65000:1010
net commit
net add bgp evpn neighbor 200.10.10.2 activate
net add bgp evpn neighbor 200.10.10.6 activate
net add bgp evpn advertise-all-vni
net add bgp evpn vni 1020 rd 1.1.1.1:1020
net add bgp evpn vni 1020 route-target import 65000:1020
net commit
net add vxlan vni-1010 bridge learning off
net commit
net add vxlan vni-1020 bridge learning off
net commit
=======================
leaf02
=======================
net add loopback lo ip address 2.2.2.2/32
net add interface swp1 ip address 200.10.10.13/30
net add interface swp2 ip address 200.10.10.9/30
net pending
net commit
net add bridge bridge ports swp3
net add bridge alias layer2_bridge
net add interface swp3 bridge access 10
net add bridge bridge vlan-aware
net pending
net commit
net add bridge bridge ports swp4
net add bridge alias layer2_bridge
net add interface swp4 bridge access 20
net add bridge bridge vlan-aware
net pending
net commit
net add vlan 100 ip address 172.16.10.1/24
net pending
net commit
net add vlan 200 ip address 10.10.20.1/24
net pending
net commit
net add bgp autonomous-system 65003
net add bgp router-id 2.2.2.2
net add bgp neighbor 200.10.10.10 remote-as 65001
net add bgp neighbor 200.10.10.14 remote-as 65001
net add bgp ipv4 unicast network 2.2.2.2 activate
net add bgp redistribute connected
net pending
net commit
net add interface swp5 ip address 10.0.3.2/32
net commit
net add interface swp6 ip address 10.0.4.2/32
net commit
net add vxlan vni-1010 vxlan id 1010
net add vxlan vni-1010 bridge access 10
net add vxlan vni-1010 vxlan local-tunnelip 10.0.3.2
net add vxlan vni-1010 mtu 9152
net add vxlan vni-1020 vxlan id 1020
net add vxlan vni-1020 bridge access 20
net add vxlan vni-1020 vxlan local-tunnelip 10.0.4.2
net add vxlan vni-1020 mtu 9152
net add bgp evpn neighbor 200.10.10.14 activate
net add bgp evpn neighbor 200.10.10.10 activate
net add bgp evpn advertise-all-vni
net add bgp evpn vni 1010 rd 2.2.2.2:1010
net add bgp evpn vni 1010 route-target import 65003:1010
net commit
net add bgp evpn neighbor 200.10.10.14 activate
net add bgp evpn neighbor 200.10.10.10 activate
net add bgp evpn advertise-all-vni
net add bgp evpn vni 1020 rd 2.2.2.2:1020
net add bgp evpn vni 1020 route-target import 65003:1020
net commit
net add vxlan vni-1010 bridge learning off
net commit
net add vxlan vni-1020 bridge learning off
net commit
====================================================
#Spine01
====================================================
net add int swp1 ip address 200.10.10.2/30
net add int swp1 alias link_to_leaf01-swp1
net add int swp2 ip address 200.10.10.10/30
net add int swp2 alias link_to_leaf02-swp2
net commit
net add bgp autonomous-system 65001
net add bgp router-id 3.3.3.3
net add bgp neighbor 200.10.10.1 remote-as 65000
net add bgp neighbor 200.10.10.9 remote-as 65003
net add bgp ipv4 unicast network 3.3.3.3/32
net commit
net add bgp evpn neighbor 200.10.10.1 activate
net add bgp evpn neighbor 200.10.10.9 activate
net commit
====================================================
#Spine02
====================================================
net add int swp1 ip address 200.10.10.14/30
net add int swp1 alias link_to_leaf01-swp2
net add int swp2 ip address 200.10.10.6/30
net add int swp2 alias link_to_leaf02-swp1
net commit
net add bgp autonomous-system 65001
net add bgp router-id 4.4.4.4
net add bgp neighbor 200.10.10.5 remote-as 65000
net add bgp neighbor 200.10.10.13 remote-as 65003
net add bgp ipv4 unicast network 4.4.4.4/32
net commit
net add bgp evpn neighbor 200.10.10.5 activate
net add bgp evpn neighbor 200.10.10.13 activate
net commit
====================================================
7. Conclusiones
Para la configuración de vxlan usando cúmulos, se debe activar las opciones en la configuracion, en
este caso activamos zebra, y bgp aunque se puede activar otras opciones para el enrutamiento con
ospf, is-is, etc.
En versiones anteriores a la 3.5 de cumulus se debe agregar la librería de quagga para realizar esto.
Mediante vxlan podemos usar un solo túnel para poder enviar varias Vlans en nuestro caso enviamos
2 vlans.
8. Referencias
http://www.redescisco.net/sitio/2015/11/24/sdn-que-es-vxlan-y-como-funciona/comment-page-1/
https://es.wikipedia.org/wiki/Virtual_Extensible_LAN
https://blogs.vmware.com/vsphere/2013/05/vxlan-series-multicast-usage-in-vxlan-part-3.html
https://www.juniper.net/documentation/en_US/junos/topics/topic-map/sdn-vxlan.html
https://www.ietf.org/rfc/rfc2362.txt
http://dmrodriguez.50megs.com/ProtEnrut/PIMSM01.html
https://www.arista.com/assets/data/pdf/Whitepapers/Arista_Networks_VXLAN_White_Paper.pdf
https://www.enterprisetech.com/2014/07/01/vxlan-future-networking-cloud/
https://www.serro.com/vxlan-vxlan-really-future-data-center-networks/
https://vcloudopia.wordpress.com/2014/09/11/vxlan-conceptos-funcionamiento-e-implementacion-12/
https://vcloudopia.wordpress.com/2014/12/11/tres-niveles-de-in-dependencia-de-multicast-en-vxlan/