Descripción de las VXLAN
La tecnología del protocolo LAN virtual extensible (VXLAN) permite que las redes admitan más VLAN. Según el estándar IEEE 802.1Q, los identificadores de VLAN tradicionales tienen una longitud de 12 bits, lo que limita las redes a 4094 VLAN. El protocolo VXLAN supera esta limitación mediante el uso de un identificador de red lógico más largo que permita más VLAN y, por consiguiente, más aislamiento de red lógico para redes grandes, como nubes que suelen albergar muchas máquinas virtuales.
Beneficios de VXLAN
La tecnología VXLAN le permite segmentar sus redes (como lo hacen las VLAN), pero ofrece ventajas que las VLAN no pueden. Estas son las ventajas más importantes de usar VXLAN:
-
En teoría, puede crear hasta 16 millones de VXLAN en un dominio administrativo (en vez de 4094 VLAN en un dispositivo de Juniper Networks).
-
Los enrutadores de la serie MX y los conmutadores EX9200 admiten hasta 32 000 VXLAN, 32 000 grupos de multidifusión y 8000 puntos de conexión de túnel virtual (VTEP). Esto significa que las VXLAN basadas en enrutadores de la serie MX proporcionan segmentación de red a la escala que los creadores de la nube requieren para admitir un número muy elevado de inquilinos.
-
Los conmutadores de la serie QFX10000 admiten 4000 VXLAN y 2000 VTEP remotos.
-
Los conmutadores QFX5100, QFX5110, QFX5200, QFX5210 y EX4600 admiten 4000 VXLAN, 4000 grupos de multidifusión y 2000 VTEP remotos.
-
Los conmutadores EX4300-48MP admiten 4000 VXLAN.
-
-
Puede habilitar la migración de máquinas virtuales entre servidores que existan en dominios diferentes de 2 capas mediante la canalización del tráfico por redes de capa 3. Esta funcionalidad le permite asignar recursos de forma dinámica dentro o entre centros de datos sin estar restringidos por límites de capa 2 o estar obligado a crear dominios de capa 2 grandes o ampliados geográficamente.
El uso de VXLAN para crear dominios más pequeños de capa 2 que estén conectados a través de una red de capa 3 significa que no es necesario usar STP (Spanning Tree Protocol, protocolo de árbol de expansión) para convergir la topología, sino que puede usar protocolos de enrutamiento más robustos en la red de capa 3. En ausencia del STP, no se bloquea ninguno de sus vínculos, lo que significa que puede obtener el valor completo de todos los puertos que compre. El uso de protocolos de enrutamiento para conectar los dominios de capa 2 también le permite equilibrar la carga de tráfico para asegurarse de que obtiene el mejor uso del ancho de banda disponible. Dada la cantidad de tráfico de este a oeste que a menudo fluye dentro o entre centros de datos, es muy importante maximizar el rendimiento de la red para ese tráfico.
El video ¿Por qué usar una red de superposición en un centro de datos? presenta una breve descripción de las ventajas de usar VXLAN.
¿Cómo funciona VXLAN?
VXLAN se describe a menudo como una tecnología de superposición, ya que permite expandir las conexiones de capa 2 mediante una red de capa 3 intermedia mediante encapsulación (tunelización) de tramas Ethernet en un paquete VXLAN con direcciones IP. Los dispositivos que admiten VXLAN se denominan puntos de conexión de túnel virtual (VTEP): pueden ser hosts finales, o conmutadores de red o enrutadores. Los VTEP encapsulan el tráfico de VXLAN y desencapsulan dicho tráfico cuando salen del túnel de VXLAN. Para encapsular una trama Ethernet, los VTEP agregan varios campos, incluidos los siguientes:
-
Dirección de destino MAC externa (dirección MAC del punto de conexión del túnel VTEP)
-
Dirección MAC de origen externa (dirección MAC del VTEP de origen del túnel)
-
Dirección de destino IP externa (dirección IP del punto de conexión del túnel VTEP)
-
Dirección IP de origen externa (dirección IP del VTEP de origen del túnel)
-
Encabezado UDP externo
-
Un encabezado VXLAN que incluye un campo de 24 bits, llamado identificador de red VXLAN (VNI), que se usa para identificar de forma exclusiva la VXLAN. El VNI es similar a un ID de VLAN, pero 24 bits le permiten crear muchas más VXLAN que las VLAN.
Dado que las VXLAN agregan de 50 a 54 bytes de información adicional de encabezado para la trama Ethernet original, es posible que desee aumentar la UMT de la red subyacente. En este caso, configure la UMT de las interfaces físicas que participan en la red VXLAN, no la UMT de la interfaz de origen de VTEP lógica, que se omite.
La figura 1 muestra el formato de paquete VXLAN.
de paquete VXLAN
Métodos de implementación de VXLAN
Junos OS admite la implementación de VXLAN en los siguientes entornos:
-
Manual VXLAN: en este entorno, un dispositivo de Juniper Networks actúa como un dispositivo de tránsito para dispositivos descendentes que actúan como VTEP o una puerta de enlace que proporciona conectividad para servidores descendentes que alojan máquinas virtuales (VM), que se comunican a través de una red de capa 3. En este entorno, los controladores de redes definidas por software (SDN) no se despliegan.
Nota:Los conmutadores QFX10000 no admiten VXLAN manuales.
-
OVSDB-VXLAN: en este entorno, los controladores de la RDS utilizan el protocolo de administración Open vSwitch Database (OVSDB) para proporcionar un medio mediante el cual los controladores (como un controlador de VMware NSX o Juniper Networks Contrail) y los dispositivos de Juniper Networks que admiten OVSDB puedan comunicarse.
-
EVPN-VXLAN: en este entorno, Ethernet VPN (EVPN) es una tecnología de plano de control que permite que los hosts (servidores físicos y VM) se coloquen en cualquier lugar de una red y permanezcan conectados a la misma red superpuesta lógica de capa 2, y VXLAN crea el plano de datos para la red superpuesta de capa 2.
Uso de QFX5100, QFX5110, QFX5120, QFX5200, QFX5210, EX4300-48MP y EX4600 Conmutadores con VXLAN
Puede configurar los conmutadores para que realicen todas las funciones siguientes:
-
(Todos los conmutadores, excepto el EX4300-48MP) En un entorno sin controlador SDN, actuar como un conmutador de tránsito de capa 3 para los hosts descendentes que actúen como VTEP. En esta configuración, no es necesario configurar ninguna funcionalidad de VXLAN en el conmutador. Debe configurar IGMP y PIM para que el conmutador pueda formar los árboles de multidifusión para los grupos de multidifusión de VXLAN. (Consulte Las VXLAN manuales requieren PIM para obtener más información.)
-
(Todos los conmutadores, excepto el EX4300-48MP) En un entorno con o sin controlador SDN, actuar como puerta de enlace de capa 2 entre las redes virtualizadas y no virtualizadas en el mismo centro de datos o entre centros de datos. Por ejemplo, puede usar el conmutador para conectar una red que use VXLAN a una que use VLAN.
-
(Conmutadores EX4300-48MP) Actuar como puerta de enlace de capa 2 entre las redes virtualizadas y no virtualizadas en una red de campus. Por ejemplo, puede usar el conmutador para conectar una red que use VXLAN a una que use VLAN.
-
(Todos los conmutadores, excepto el EX4300-48MP) Actuar como una puerta de enlace de capa 2 entre las redes virtualizadas en el mismo centro de datos o en otros, y permitir que las máquinas virtuales se muevan entre estas redes y los centros de datos. Por ejemplo, si desea permitir VMotion entre dispositivos en dos redes diferentes, puede crear la misma VLAN en ambas redes y colocar ambos dispositivos en dicha VLAN. Los conmutadores conectados a estos dispositivos que actúan como VTEPs pueden asignar esa VLAN a la misma VXLAN y el tráfico VXLAN se puede enrutar entonces entre las dos redes.
-
(Conmutadores QFX5110 y QFX5120 con EVPN-VXLAN) Actuar como puerta de enlace de capa 3 para enrutar el tráfico entre diferentes VXLAN del mismo centro de datos.
-
(Conmutadores QFX5110 y QFX5120 con EVPN-VXLAN) Actuar como puerta de enlace de capa 3 para enrutar el tráfico entre VXLAN de distintos centros de datos mediante una WAN o Internet con protocolos de enrutamiento estándar o túneles del servicio de LAN privada virtual (VPLS).
Si desea que un conmutador QFX5110 o QFX5120 sea una puerta de enlace VXLAN de capa 3 en un entorno EVPN-VXLAN, debe configurar las interfaces de enrutamiento y puente (IRB) integradas para conectar las VXLAN, del mismo modo que lo haría si desea enrutar el tráfico entre redes VLAN.
Dado que los encabezados adicionales suman de 50 a 54 bytes, es posible que tenga que aumentar la UMT en un VTEP para dar cabida a paquetes más grandes. Por ejemplo, si el conmutador usa el valor de UMT predeterminado de 1514 bytes y desea reenviar paquetes de 1500 bytes mediante la VXLAN, debe aumentar la UMT para permitir el aumento del tamaño del paquete que provocaron los encabezados adicionales.
Cambiar el puerto UDP en QFX5100, QFX5110, QFX5200, QFX5210 y EX4600 Conmutadores
A partir de la versión 14.1X53-D25 de Junos OS en conmutadores QFX5100, la versión 15.1X53-D210 de Junos OS en conmutadores QFX5110 y QFX5200, la versión 18.1R1 de Junos OS en conmutadores QFX5210 y la versión 18.2R1 de Junos OS en conmutadores EX4600, puede configurar el puerto UDP que se usará como puerto de destino para el tráfico de la VXLAN. Para configurar el puerto de destino de la VXLAN para que no sea un puerto UDP predeterminado de 4789, escriba la siguiente instrucción:
set protocols l2-learning destination-udp-port port-number
El puerto que configure se usará para todas las VXLAN configuradas en el conmutador.
Si realiza este cambio en un conmutador de una VXLAN, debe realizar el mismo cambio en todos los dispositivos que terminan las VXLAN configuradas en el conmutador. Si no lo hace, se interrumpirá el tráfico de todas las VXLAN configuradas en el conmutador. Cuando cambie el puerto UDP, el VTEP y los Mac remotos ya aprendidos se pierden y el tráfico de VXLAN se interrumpe hasta que el conmutador vuelve a aprender los VTEP y Mac remotos.
Prevención de desbordamiento de entrada de host
De forma predeterminada, cuando la tabla de host alcanza su capacidad, las entradas de host adicionales se desbordan en la tabla de coincidencia de prefijo más largo (LPM). Esto puede provocar una degradación del rendimiento del enrutamiento como resultado de entradas de host más pequeñas que consumen espacio valioso en la tabla LPM.
A partir de Junos OS versión 25.2R1, puede evitar que las entradas de host se desborden en la tabla LPM configurando la set forwarding-options no-host-as-lpm instrucción. Cuando habilita esta opción, se bloquea la entrada de host para que no entren en la tabla LPM y se registra un mensaje de error para notificarle la condición completa de la tabla host. Esta restricción mantiene la integridad de la tabla LPM para rutas de subred más grandes, que suelen ser más críticas para una operación de red eficiente. Esta configuración requiere un reinicio de PFE para borrar cualquier entrada de host existente de la tabla LPM, lo que garantiza que la tabla esté dedicada únicamente a las rutas de subred en el futuro. El reinicio es fundamental para mantener un estado limpio, ya que evita que las entradas de host residuales afecten a la utilización del espacio de tablas.
La configuración de la set forwarding-options no-host-as-lpm instrucción reinicia la PFE en dispositivos independientes. Los dispositivos de chasis virtual (VC) requieren un reinicio manual. Al reiniciar la PFE, se eliminan las entradas de host aprendidas previamente de la tabla LPM.
La prevención de desbordamiento de entrada de host es particularmente beneficiosa para entornos con altas demandas de entrada de host. La función admite rutas IPv4 e IPv6 y se aplica a entornos VXLAN y no VXLAN, lo que la hace versátil para varios escenarios de despliegue. La segregación de rutas de host y subred evita la degradación del rendimiento del enrutamiento que resulta de las entradas de host que se desbordan a la tabla LPM. Además, el sistema genera un mensaje de registro del sistema cada vez que activa la opción CLI, lo que proporciona una pista de auditoría para la administración de cambios y la solución de problemas. Al aprovechar esta función, puede mejorar la administración de la tabla de enrutamiento, mejorar la eficiencia del enrutamiento y garantizar el control sistemático de las entradas de la tabla de enrutamiento.
Consulte el Explorador de características para obtener una lista completa de los productos que admiten la función de prevención de desbordamiento de entrada de host.
Comandos de la CLI
Para configurar la función de prevención de desbordamiento de entrada de host, utilice el siguiente comando de la CLI:
set forwarding-options no-host-as-lpm
Este comando habilita la función que bloquea las entradas de host para que no se agreguen a la tabla LPM cuando la tabla de host está llena, conservando el espacio LPM para rutas de subred más grandes.
Para verificar el estado de la función de prevención de desbordamiento de entrada de host, utilice el comando:
show forwarding-options no-host-as-lpm
Este comando muestra el estado de configuración actual, lo cual indica si la función está habilitada o deshabilitada.
Para mostrar un resumen de las rutas en las tablas de reenvío de host y LPM del motor de reenvío de paquetes, utilice el comando:
show pfe route summary hw
Con estos comandos, puede administrar y supervisar eficazmente las entradas de la tabla de enrutamiento, lo que garantiza un rendimiento y una escalabilidad óptimos en su entorno de red.
Control del tráfico de multidifusión de tránsito en QFX5100, QFX5110, QFX5200, QFX5210 y EX4600 Conmutadores
Cuando el conmutador que actúa como VTEP recibe una difusión, una unidifusión desconocida o un paquete de multidifusión, realiza las acciones siguientes en el paquete:
-
Desencapsula el paquete y lo entrega a los hosts conectados localmente.
-
A continuación, agrega la encapsulación de VXLAN de nuevo y envía el paquete a los demás VTEP en la VXLAN.
Estas acciones las realiza la interfaz de circuito cerrado que se usa como dirección del túnel VXLAN y, por lo tanto, pueden afectar negativamente al ancho de banda disponible para el VTEP. A partir de Junos OS versión 14.1X53-D30 para conmutadores QFX5100, versión 15.1X53-D210 de Junos OS para conmutadores QFX5110 y QFX5200, versión 18.1R1 de Junos OS para conmutadores QFX5210 y versión 18.2R1 de Junos OS para conmutadores EX4600, si sabe que no hay receptores de multidifusión conectados a otros VTEP en la VXLAN que deseen el tráfico de un grupo de multidifusión específico, Puede reducir la carga de procesamiento en la interfaz de circuito cerrado si especifica la instrucción siguiente:
set protocols l2-learning disable-vxlan-multicast-transit vxlan-multicast-group multicast-group
En este caso, no se reenviará tráfico para el grupo especificado, pero se reenviará todo el resto del tráfico de multidifusión. Si no desea reenviar tráfico de multidifusión a otros VTEP de la VXLAN, escriba la instrucción siguiente:
set protocols l2-learning disable-vxlan-multicast-transit vxlan-multicast-group all
Uso de enrutadores de la serie MX, conmutadores EX9200 o conmutadores QFX10000 como VTEP
Puede configurar un enrutador de la serie MX, un conmutador EX9200 o un conmutador QFX10000 para que actúe como VTEP y realice todas las funciones siguientes:
-
Actuar como puerta de enlace de capa 2 entre las redes virtualizadas y no virtualizadas en el mismo centro de datos o entre centros de datos. Por ejemplo, puede usar un enrutador de la serie MX para conectar una red que use VXLAN a una que use VLAN.
-
Actuar como una puerta de enlace de capa 2 entre las redes virtualizadas en el mismo centro de datos o en otros, y permitir que las máquinas virtuales se muevan entre estas redes y los centros de datos.
-
Actuar como puerta de enlace de capa 3 para enrutar el tráfico entre diferentes VXLAN del mismo centro de datos.
-
Actuar como puerta de enlace de capa 3 para enrutar el tráfico entre VXLAN de distintos centros de datos mediante una WAN o Internet con protocolos de enrutamiento estándar o túneles del servicio de LAN privada virtual (VPLS).
Si desea que uno de los dispositivos descritos en esta seccion sea una puerta de enlace VXLAN de capa 3, debe configurar las interfaces de enrutamiento y puente (IRB) integradas para conectar las VXLAN, del mismo modo que lo haría si desea enrutar el tráfico entre VLAN.
Las VXLAN manuales requieren PIM
En un entorno con un controlador (como VMware NSX o un controlador de Juniper Networks Contrail), puede aprovisionar VXLAN en un dispositivo de Juniper Networks. Un controlador también proporciona un plano de control que los VTEP usan para anunciar su accesibilidad y aprenden sobre la accesibilidad de otros VTEP. También puede crear VXLAN de forma manual en dispositivos de Juniper Networks en lugar de usar un controlador. Si usa este método, también debe configurar la multidifusión independiente del protocolo (PIM, Protocol Independent Multicast) en los VTEP para que pueda crear túneles VXLAN entre ellos.
También debe configurar cada VTEP en una VXLAN dada para que sea miembro del mismo grupo de multidifusión. (Si es posible, debería asignar una dirección de grupo de multidifusión diferente a cada VXLAN, aunque esto no es obligatorio. Varias VXLAN pueden compartir el mismo grupo de multidifusión.) A continuación, los VTEP podrán reenviar las solicitudes ARP que reciban de sus hosts conectados al grupo de multidifusión. Los otros VTEP del grupo desencapsulan la información de la VXLAN y (suponiendo que sean miembros de la misma VXLAN) reenvíen la solicitud ARP a sus hosts conectados. Cuando el host de destino recibe la solicitud ARP, responde con su dirección MAC, y su VTEP reenvía esta respuesta ARP al VTEP de origen. Mediante este proceso, los VTEP aprenden las direcciones IP de los otros VTEP de la VXLAN y las direcciones MAC de los hosts conectados a los demás VTEP.
Los grupos y árboles de multidifusión también se utilizan para enviar tráfico de difusión, unidifusión desconocida y multidifusión (BUM) entre VTEP. Esto impide que el tráfico BUM se inunde innecesariamente fuera de la VXLAN.
El tráfico de multidifusión que se reenvía a través de un túnel VXLAN se envía solo a los VTEP remotos de la VXLAN. Es decir, el VTEP de encapsulación no copia ni envía copias de los paquetes según el árbol de multidifusión; solo reenvía los paquetes de multidifusión recibidos a los VTEP remotos. Los VTEP remoto desencapsula los paquetes de multidifusión encapsulados y los reenvía a las interfaces apropiadas de capa 2.
Equilibrio de carga de tráfico VXLAN
Las rutas de capa 3 que forman túneles VXLAN usan el equilibrio de carga por paquete de forma predeterminada, lo que significa que el equilibrio de carga se implementa si hay rutas ECMP al VTEP remoto. Esto difiere del comportamiento normal de enrutamiento, en el que no se usa el equilibrio de carga por paquete de forma predeterminada. (El enrutamiento normal usa el equilibrio de carga por prefijo de forma predeterminada).
El campo puerto de origen del encabezado UDP sirve para habilitar el equilibrio de carga ECMP del tráfico VXLAN en la red de capa 3. Este campo se establece en un valor hash de los campos de paquetes internos, lo que da como resultado una variable que el ECMP puede usar para distinguir entre túneles (flujos).
Ninguno de los otros campos que el ECMP basado en flujo usa de modo normal son aptos para su uso con VXLAN. Todos los túneles entre los mismos dos VTEP tienen las mismas direcciones IP de origen y destino externas, y el puerto de destino UDP se configura en el puerto 4789 por definición. Por lo tanto, ninguno de estos campos es suficiente para que el ECMP diferencie flujos.
Habilitación de los conmutadores QFX5120 para el tráfico de túnel en las interfaces IRB y etiquetadas de núcleo frontal de capa 3
Esta sección solo se aplica a los conmutadores QFX5120 que ejecutan las versiones de Junos OS 18.4R1, 18.4R2, 18.4R2-S1 a 18.4R2-S3, 19.1R1, 19.1R2, 19.2Rx y 19.3Rx.
Cuando un conmutador QFX5120 intenta túnel tráfico en interfaces etiquetadas de núcleo frontal de capa 3 o IRB, el conmutador deja caer los paquetes. Para evitar este problema, puede configurar un firewall sencillo de dos términos basado en filtros en la interfaz etiquetada de capa 3 o IRB.
Los conmutadores QFX5120 admiten un máximo de 256 firewalls basados en filtros de dos términos.
Por ejemplo:
set interfaces et-0/0/3 unit 0 family inet filter input vxlan100 set firewall family inet filter vxlan100 term 1 from destination-address 192.168.0.1/24 then accept set firewall family inet filter vxlan100 term 2 then routing-instance route1
El término 1 coincide y acepta el tráfico destinado al conmutador QFX5210, que se identifica mediante la dirección IP VTEP de origen (192.168.0.1/24) asignada a la interfaz de circuito cerrado del conmutador. Para el término 1, tenga en cuenta que, cuando especifique una acción, también puede contar el tráfico en lugar de aceptarlo.
El término 2 hace coincidir y reenvía todo el resto del tráfico de datos a una instancia de enrutamiento (ruta 1), que está configurada como interfaz et-0/0/3.
En este ejemplo, observe que la instancia de enrutamiento route1 hace referencia a la interfaz et-0/0/3. Como resultado, debe incluir el set firewall family inet filter vxlan100 term 2 then routing-instance route1 comando. Si este comando no se usa, el filtro del firewall no funcionará correctamente.
Uso de ping y traceroute con una VXLAN
En los conmutadores QFX5100 y QFX5110, puede utilizar los comandos y traceroute para solucionar problemas de ping flujo de tráfico a través de un túnel VXLAN si incluye el overlay parámetro y varias opciones. Estas opciones se usan para hacer que los ping traceroute o paquetes sigan la misma ruta que los paquetes de datos a través del túnel VXLAN. Es decir, hace que los paquetes subyacentes (ping y traceroute) tomen la misma ruta que los paquetes de superposición (tráfico de datos). Consulte ping superpuesto y traceroute superpuesta para obtener más información.
Estándares de VXLAN compatibles
Documentos RFC y borradores de Internet que definen los estándares de VXLAN:
-
RFC 7348, Red virtual de área local extensible (VXLAN): Un marco para superponer redes virtualizadas de capa 2 mediante redes de capa 3
-
Borrador de Internet draft-ietf-nvo3-vxlan-gpe, Extensión de protocolo genérico para VXLAN
Tabla de historial de cambios
La compatibilidad de la función depende de la plataforma y la versión que utilice. Utilice el Explorador de características para determinar si una característica es compatible con su plataforma.