Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

Restricciones de VXLAN en dispositivos de las series EX, QFX y PTX

Al configurar LAN virtuales extensibles (VXLAN) en conmutadores serie QFX y serie EX, tenga en cuenta las restricciones descritas en las secciones siguientes. En estas secciones, "lado de la capa 3" se refiere a una interfaz orientada a la red que realiza la encapsulación y desencapsulación de VXLAN, y "lado de la capa 2" se refiere a una interfaz orientada al servidor que es miembro de una VLAN que está asignada a una VXLAN.

Restricciones de VXLAN en conmutadores QFX5xxx, EX4100, EX4100-F, EX4300-48MP, EX4400 y EX4600

  • La compatibilidad con VXLAN en un Virtual Chassis o Virtual Chassis Fabric (VCF) tiene las siguientes restricciones y recomendaciones:

    • Admitimos EVPN-VXLAN en un chasis virtual EX4300-48MP solo en redes de campus.

    • Los conmutadores EX4400 independientes y el chasis virtual EX4400 admiten EVPN-VXLAN. Para casos de uso de multiconexión, los hosts se pueden alojar de forma múltiple en conmutadores EX4400 independientes, pero no se admite la multiconexión de un host con interfaces ESI-LAG al chasis virtual EX4400.
    • Los conmutadores EX4100 independientes (EX4100 y EX4100-F) y el chasis virtual EX4100 (EX4100 y EX4100-F) admiten EVPN-VXLAN. Para casos de uso de multiconexión, los hosts pueden ser multihost en conmutadores EX4100 independientes, pero no se admite la multiconexión de un host con interfaces ESI-LAG al chasis virtual EX4100.

    • Los conmutadores EX4100 independientes (EX4100 y EX4100-F) y el chasis virtual EX4100 (EX4100 y EX4100-F) admiten EVPN-VXLAN. Para casos de uso de multiconexión, los hosts pueden ser multihost en conmutadores EX4100 independientes, pero no se admite la multiconexión de un host con interfaces ESI-LAG al chasis virtual EX4100.

    • En las redes de centros de datos, solo admitimos EVPN-VXLAN en un Virtual Chassis o VCF compuesto por todos los conmutadores QFX5100, y no en ningún otro Virtual Chassis o VCF mixto o no mezclado. Admitimos VCF en entornos de centros de datos EVPN-VXLAN que ejecutan versiones de Junos OS a partir de 14.1X53-D40 y anteriores a 17.1R1. Sin embargo, no recomendamos usar EVPN-VXLAN en un Virtual Chassis o VCF QFX5100, ya que la compatibilidad con las funciones solo está a la par con la compatibilidad con conmutadores QFX5100 independientes que ejecutan Junos OS versión 14.1X53-D40.

      En general, hemos dejado de ser compatibles con VCF desde la versión 21.4R1 de Junos OS en adelante.

    • Cuando un QFX5100 Virtual Chassis aprende una dirección MAC en una interfaz VXLAN, la entrada de la tabla MAC puede tardar entre 10 y 15 minutos en caducar (dos o tres veces el intervalo de antigüedad predeterminado de 5 minutos). Esto sucede cuando Virtual Chassis aprende una dirección MAC de un paquete entrante en un conmutador miembro Virtual Chassis y, a continuación, debe reenviar ese paquete a través de los vínculos del puerto Virtual Chassis (VCP) a otro conmutador miembro en el Virtual Chassis de camino a su destino. El Virtual Chassis marca la dirección MAC como se ve de nuevo en el conmutador del segundo miembro, por lo que es posible que la dirección MAC no expire durante uno o dos intervalos de antigüedad adicionales más allá del primero. El aprendizaje de MAC no se puede desactivar en las interfaces VXLAN solo en el segundo conmutador miembro del chasis virtual, por lo que no puede evitar el retraso adicional en este caso.

  • (Solo QFX5120 conmutadores) El tráfico que se tuneliza a través de una interfaz etiquetada de capa 3 orientada hacia el núcleo o una interfaz IRB se descarta. Para evitar esta limitación, puede configurar el etiquetado flexible de VLAN. Para obtener más información, consulte Descripción de las VXLAN.

  • (QFX5110 y QFX5120) Si configura una interfaz de estilo empresarial con encapsulación flexible de servicios Ethernet, el dispositivo descarta los paquetes encapsulados en VXLAN de capa 2 de tránsito en esa interfaz. Para evitar este problema, configure la interfaz en el estilo de proveedor de servicios en lugar de utilizar el estilo de empresa. Para obtener más información sobre las configuraciones de estilo empresarial y de proveedor de servicios, consulte Encapsulación flexible de servicios Ethernet. Para obtener información general sobre la configuración de servicios Ethernet flexibles en una estructura EVPN-VXLAN, consulte Descripción de la compatibilidad de servicios Ethernet flexibles con EVPN-VXLAN.

  • (Conmutadores QFX5110 y QFX5120) En las estructuras EVPN-VXLAN, no se admiten configuraciones de estilo empresarial, estilo de proveedor de servicios y VLAN nativas en la misma interfaz física si la VLAN nativa es la misma que una de las VLAN en la configuración de estilo de proveedor de servicios. La VLAN nativa puede ser una de las VLAN en la configuración de estilo empresarial. Para obtener más información sobre las configuraciones de estilo empresarial y de proveedor de servicios, consulte Encapsulación flexible de servicios Ethernet.

  • (Conmutadores QFX5xxx) En una estructura EVPN-VXLAN, no puede configurar la instrucción native-vlan-id en la misma interfaz en la que habilita la traducción de VLAN con la instrucción vlan-rewrite .

  • (Conmutadores QFX5100, QFX5110, QFX5200 y QFX5210) Se admite la configuración de VXLAN en la instancia de enrutamiento del conmutador predeterminado y en las instancias de enrutamiento VRF de MAC (instance-type mac-vrf).

    (Conmutadores EX4300-48MP y EX4600) Solo se admite la configuración de VXLAN en la instancia predeterminada de enrutamiento del conmutador.

  • (Conmutadores QFX5100, QFX5200, QFX5210, EX4300-48MP y EX4600) No se admite el enrutamiento de tráfico entre diferentes VXLAN.

    Nota:

    Los siguientes conmutadores admiten el enrutamiento VXLAN a partir de las versiones indicadas, por lo que esta limitación ya no se aplica:

    • Conmutadores EX4300-48MP: a partir de Junos OS versión 19.4R1.

    • Conmutadores QFX5210: a partir de Junos OS versión 21.3R1.

  • (Conmutadores QFX5100, QFX5110, QFX5120, EX4600 y EX4650) Estos conmutadores solo admiten un próximo salto VTEP en interfaces IRB subyacentes de VXLAN. Si no desea utilizar varios puertos de salida, pero necesita más de un próximo salto de VTEP, como solución alternativa, puede realizar una de las siguientes acciones:

    • Coloque un enrutador entre el conmutador y los VTEP remotos de manera que solo haya un salto siguiente entre ellos.

    • Utilice interfaces físicas de capa 3 en lugar de interfaces IRB para la accesibilidad remota de VTEP.

  • (QFX5110 conmutadores) De forma predeterminada, el tráfico de enrutamiento entre una VXLAN y una interfaz lógica de capa 3 (por ejemplo, una interfaz configurada con el set interfaces interface-name unit logical-unit-number family inet address ip-address/prefix-length comando) no está habilitado. Si esta funcionalidad de enrutamiento es necesaria en su red EVPN-VXLAN, puede realizar alguna configuración adicional para que funcione. Para obtener más información, consulte Descripción de cómo configurar VXLAN e interfaces lógicas de capa 3 para interoperar.

  • Las interfaces de enrutamiento y puente integrados (IRB) usadas en las redes superpuestas EVPN-VXLAN no admiten el protocolo de enrutamiento IS-IS.

  • (Conmutadores QFX5100, QFX5110, QFX5120, QFX5200, QFX5210, EX4300-48MP y EX4600) Una interfaz física no puede ser miembro de una VLAN y una VXLAN. Es decir, una interfaz que realiza la encapsulación y desencapsulación de VXLAN no puede ser también miembro de una VLAN. Por ejemplo, si una VLAN asignada a una VXLAN es miembro del puerto troncal xe-0/0/0, cualquier otra VLAN que sea miembro de xe-0/0/0 también debe asignarse a una VXLAN.

    Nota:

    A partir de las versiones 18.1R3 y 18.4R1 de Junos OS para conmutadores QFX5100, QFX5110, QFX5200 y QFX5210, y de la versión 19.4R1 de Junos OS para conmutadores QFX5120 y EX4650, esta limitación ya no se aplica porque puede configurar servicios Ethernet flexibles en la interfaz física. (Lo mismo ocurre con las interfaces de paquete Ethernet (AE) agregadas).

    Además, a partir de Junos OS versión 20.3R1 en conmutadores QFX5110 y QFX5120, admitimos interfaces lógicas VLAN y VXLAN de capa 2 en la misma interfaz física utilizando únicamente configuraciones de interfaz de estilo de proveedor de servicios.

    Para obtener más información, consulte Descripción de la compatibilidad de servicios Ethernet flexibles con EVPN-VXLAN.

  • (QFX5120, conmutadores EX4100, EX4300-48MP, EX4400 y EX4650) Con la autenticación 802.1X para el tráfico VXLAN en un puerto de acceso, tras la autenticación, el servidor RADIUS cambia dinámicamente el tráfico de la VLAN original a una VLAN dinámica que se configura como VLAN habilitada para VXLAN. Una VLAN habilitada para VXLAN es una VLAN para la cual se configura una asignación de identificador de red VXLAN (VNI) mediante la vxlan vni vni instrucción en la [edit vlans vlan-name] jerarquía.

    Al configurar la VLAN dinámica 802.1X y su asignación de VNI correspondiente, también debe configurar la VLAN original como una VLAN habilitada para VXLAN con una asignación de VNI. Si no configura explícitamente el puerto como miembro de una VLAN, el puerto utiliza la VLAN predeterminada. En ese caso, debe configurar la VLAN predeterminada como una VLAN habilitada para VXLAN con una asignación de VNI.

    Además, en versiones anteriores a Junos OS versión 22.2R3-S3, cuando cualquier VLAN dinámica se asigna a un puerto, dicha VLAN ya debe haberse configurado estáticamente en otro puerto del dispositivo. A partir de Junos OS versión 22.2R3-S3, ya no tenemos esta restricción.

    Consulte Autenticación 802.1X y Configuración del servidor RADIUS para la autenticación para obtener más información sobre la asignación de VLAN dinámica con un servidor RADIUS.

  • Los grupos de agregación de vínculos de varios chasis (MC-LAG) no son compatibles con VXLAN.

    Nota:

    En un entorno EVPN-VXLAN, se utiliza el modo activo-activo de multiconexión EVPN en lugar de MC-LAG para la conectividad redundante entre hosts y dispositivos leaf.

  • La fragmentación y desfragmentación de IP no son compatibles en el lado de la capa 3.

  • Las siguientes características no son compatibles en el lado de la capa 2:

    • (Conmutadores QFX5100, QFX5200, QFX5210, EX4300-48MP y EX4600) Espionaje IGMP con EVPN-VXLAN.

    • Grupos troncales redundantes (RTG).

    • No se admite la capacidad de apagar una interfaz de capa 2 o desactivar temporalmente la interfaz cuando se supera un nivel de control de tormenta.

    • No se admiten funciones completas de STP, MSTP, RSTP o VSTP (xSTP) con VXLAN. Sin embargo, puede configurar xSTP en el borde (puerto de acceso) para la compatibilidad de bloque en borde de BPDU. Consulte Protección BPDU para protocolos de árbol de expansión para obtener más información.

  • Las características de seguridad del puerto de acceso, como las siguientes, no son compatibles con VXLAN:

    • Espionaje DHCP.

    • Inspección ARP dinámica.

    • Limitación de MAC y limitación de movimiento de MAC.

    Algunas excepciones incluyen:

    • La limitación de MAC se admite en interfaces administradas por OVSDB en un entorno OVSDB-VXLAN con controladores Contrail. Para obtener más información, consulte Características admitidas en interfaces administradas por OVSDB.

    • En estos dispositivos que sirven como puertas de enlace L2 VXLAN en redes superpuestas de puente de enrutamiento centralizado EVPN-VXLAN:

      • Conmutadores multigigabit EX4300 a partir de Junos OS versión 19.4R1

      • Conmutadores EX4400 a partir de Junos OS versión 21.1R1

      • Conmutadores multigigabit EX4400 a partir de Junos OS versión 21.2R1

      • Conmutadores EX4100 y EX4100-F a partir de Junos OS versión 22.3R1

      • Conmutadores multigigabit EX4100 a partir de Junos OS versión 22.3R1

      admitimos estas funciones de seguridad de acceso en interfaces del lado de acceso de capa 2 asociadas con VLAN asignadas por VXLAN:

      • Espionaje de DHCPv4 y DHCPv6

      • Inspección ARP dinámica (DAI)

      • Inspección de descubrimiento de vecinos (NDI)

      • Protección de origen IPv4 e IPv6

      • Protección de anuncio de enrutador (RA)

      Solo admitimos estas características en conexiones de interfaz de acceso de base única.

  • La replicación de nodos de entrada no se admite en los siguientes casos:

    • Cuando se utiliza PIM para el plano de control (VXLAN manual).

    • Cuando se utiliza un controlador SDN para el plano de control (OVSDB-VXLAN).

    La replicación del nodo de entrada es compatible con EVPN-VXLAN.

  • PIM-BIDIR y PIM-SSM no son compatibles con VXLAN.

  • Si configura una instancia de creación de reflejo de puerto para reflejar el tráfico que sale de una interfaz que realiza la encapsulación de VXLAN, las direcciones MAC de origen y destino de los paquetes reflejados no son válidas. El tráfico VXLAN original no se ve afectado.

  • (Solo QFX5110 conmutadores) Los filtros de firewall VLAN no son compatibles con las interfaces IRB en las que está habilitada EVPN-VXLAN.

  • (Conmutadores de las series EX4650 y QFX5000) Compatibilidad con filtros de firewall y aplicadores de política:

    • (QFX5100 conmutadores) Los filtros de firewall ni las políticas no se admiten en el tráfico de tránsito en el que está habilitada EVPN-VXLAN. Solo se admiten en la dirección de entrada en interfaces orientadas a CE.

    • (QFX5100 conmutadores) Para las interfaces IRB en una estructura IP de una capa EVPN-VXLAN, el filtrado y la vigilancia del firewall solo se admiten en el punto de entrada de tramas no encapsuladas enrutadas a través de la interfaz IRB.

    • (Conmutadores EX4650, QFX5110 y QFX5120) Admitimos el filtrado y la vigilancia de entrada para interfaces VXLAN enrutadas (interfaces IRB) como listas de control de acceso de ruta de entrada [IRACL].

    • (conmutadores QFX5110, QFX5120 y QFX5210) Admitimos el filtrado y la vigilancia de entrada en interfaces VXLAN no enrutadas como ACL de puerto de entrada [IPACL]).

    • (Conmutadores QFX5110 y QFX5120) La compatibilidad con filtrado y políticas en interfaces VXLAN no enrutadas se extiende a la dirección de salida como ACL de puerto de salida ([EPACL]).

  • (Solo conmutadores EX4300-48MP) No se admiten los siguientes estilos de configuración de interfaz:

    • Estilo de proveedor de servicios, donde una interfaz física se divide en varias interfaces lógicas, cada una de las cuales está dedicada a una VLAN de cliente en particular. El extended-vlan-bridge tipo de encapsulación se configura en la interfaz física.

    • Servicios Ethernet flexibles, que es un tipo de encapsulación que permite que una interfaz física admita estilos de configuración de interfaz tanto de proveedor de servicios como de empresa.

    Para obtener más información acerca de estos estilos de configuración de interfaz, consulte Encapsulación flexible de servicios Ethernet.

  • (Solo QFX5100 conmutadores) Con la instrucción configuration no-arp-suppression , puede desactivar la supresión de solicitudes ARP en una o más VLAN especificadas. Sin embargo, a partir de Junos OS versión 18.4R3, debe desactivar esta función en todas las VLAN. Para ello, puede utilizar una de estas opciones de configuración:

    • Utilice un comando por lotes para desactivar la función en todas las VLAN—set groups group-name vlans * no-arp-suppression. Con este comando, usamos el asterisco (*) como un comodín que especifica todas las VLAN.

    • Utilice un comando para desactivar la función en cada VLAN individual—set vlans vlan-name no-arp-suppression.

    Nota:

    La no-arp-suppression instrucción ya no se admite en los conmutadores serie EX y QFX a partir de Junos OS versión 19.1R1. La instrucción ha quedado obsoleta.

  • Los conmutadores QFX5120-48Y, QFX5120-32C y QFX5200 admiten múltiples rutas jerárquicas de igual costo (ECMP), lo que permite que estos conmutadores realicen una resolución de ruta de dos niveles. Sin embargo, todos los demás conmutadores QFX5xxx no admiten ECMP jerárquico. Como resultado, cuando un paquete EVPN tipo 5 se encapsula con un encabezado VXLAN y luego se desencapsula mediante un conmutador QFX5xxx que no admite ECMP jerárquico, el conmutador no puede resolver los dos niveles de rutas que estaban en el paquete interno. A continuación, el conmutador descarta el paquete.

  • (Conmutadores QFX5100, QFX5110, QFX5120, QFX5200 y QFX5210) Cuando configure las interfaces IRB en un dispositivo que admita simultáneamente VLAN configuradas tanto en una superposición de puente de enrutamiento centralizado como en una superposición de puente de enrutamiento de borde, la dirección MAC IRB y la dirección MAC de puerta de enlace virtual en la interfaz IRB para la superposición de puente de enrutamiento centralizado deben ser diferentes de la dirección MAC IRB y la dirección MAC de puerta de enlace virtual en la interfaz IRB para la superposición de puente enrutado de borde.

  • (Solo conmutadores QFX5110 y QFX5120) En una superposición EVPN-VXLAN, no se admite la ejecución de un protocolo de enrutamiento en una interfaz IRB que se encuentre en una instancia de enrutamiento predeterminada (default.inet.0). En su lugar, recomendamos incluir la interfaz IRB en una instancia de enrutamiento del tipo vrf.

  • Las siguientes restricciones se aplican tanto a las VXLAN como a las VLAN.

    • (Solo conmutadores QFX5xxx ) Al configurar la fuga de ruta entre instancias de enrutamiento y reenvío virtual (VRF), debe especificar cada prefijo con una máscara de subred igual o mayor que /16 para prefijos IPv4 o igual o mayor que /64 para prefijos IPv6. Si una máscara de subred que especifique no cumple estos parámetros, las rutas especificadas no se filtrarán.

    • (Solo QFX5120 conmutadores) De forma predeterminada, los conmutadores QFX5120 asignan 5 MB de búfer compartido para absorber ráfagas de tráfico de multidifusión. Si una ráfaga de tráfico de multidifusión supera los 5 MB, el conmutador descartará los paquetes que reciba después de exceder el espacio de búfer. Para evitar que el conmutador descarte paquetes de multidifusión cuando se produce esta situación, puede realizar una de las siguientes acciones:

      • Utilice la shared-buffer instrucción configuration en el nivel de jerarquía para reasignar un porcentaje mayor del búfer compartido para el [edit class-of-service] tráfico de multidifusión. Para obtener más información acerca del ajuste fino de un búfer compartido, consulte Descripción de la configuración del búfer de CoS.

      • En el conmutador de Juniper Networks del que provienen las ráfagas de tráfico de multidifusión, aplique un modelador en el vínculo de salida.

    • (Solo conmutadores QFX5xxx ) Si ha habilitado el control de tormentas en una interfaz, es posible que observe una diferencia significativa entre las tasas de tráfico configuradas y reales para la interfaz. Esta diferencia es el resultado de un medidor de control de tormentas interno que cuantifica la tasa de tráfico real para la interfaz en incrementos de 64 kbps, por ejemplo, 64 kbps, 128 kbps, 192 kbps, etc.

  • (Conmutadores QFX5xxx y EX46xx) No puede usar la detección de reenvío bidireccional en línea (BFD) asistida por hardware con encapsulación VXLAN de paquetes BFD. Además, si configura emparejamientos BGP de superposición EVPN, utilice BFD distribuido en lugar de BFD en línea asistido por hardware. Consulte Descripción de cómo BFD detecta errores de red para obtener detalles sobre los diferentes tipos de sesiones de BFD que puede configurar.

  • (Conmutadores QFX5xxx y EX46xx) No se admite la configuración y el uso de MPLS y EVPN-VXLAN al mismo tiempo en el mismo dispositivo. Tenemos esta restricción porque las plataformas basadas en Broadcom usan las mismas tablas de hardware para almacenar información de túneles y puertos virtuales que usan los conjuntos de características MPLS y VXLAN.

    Además, no puede usar una base MPLS con EVPN y una superposición VXLAN; esta es una limitación de hardware de Broadcom.

  • (Conmutadores QFX5xxx y EX46xx) No se admiten interfaces L3 etiquetadas ni dominios de puente L2 como subunidades de la misma interfaz con un IRB en configuraciones de estilo de proveedor de servicios.

Restricciones de VXLAN en conmutadores de la serie QFX10000

  • Los MC-LAG no son compatibles con VXLAN.

    Nota:

    En un entorno EVPN-VXLAN, se utiliza el modo activo-activo de multiconexión EVPN en lugar de MC-LAG para la conectividad redundante entre hosts y dispositivos leaf.

  • La fragmentación IP no es compatible con el lado de la capa 3.

  • Las siguientes características no son compatibles en el lado de la capa 2:

    • Espionaje IGMP con EVPN-VXLAN en versiones de Junos OS anteriores a Junos OS versión 17.2R1.

    • STP (cualquier variante).

  • Las funciones de seguridad del puerto de acceso no son compatibles con VXLAN. Por ejemplo, no se admiten las siguientes características:

    • Espionaje DHCP.

    • Inspección ARP dinámica.

    • Limitación de MAC y limitación de movimiento de MAC.

  • La replicación del nodo de entrada no se admite cuando se utiliza un controlador SDN para el plano de control (OVSDB-VXLAN). La replicación del nodo de entrada es compatible con EVPN-VXLAN.

  • QFX10000 conmutadores que se implementan en un entorno EVPN-VXLAN no admiten una red subyacente física IPv6.

  • Cuando la base de datos del siguiente salto en un conmutador de QFX10000 incluye los siguientes saltos tanto para la red subyacente como para la red superpuesta EVPN-VXLAN, el siguiente salto a un par VXLAN no puede ser un identificador de segmento Ethernet (ESI) o una interfaz de extremo de túnel virtual (VTEP).

  • Las interfaces IRB utilizadas en las redes superpuestas EVPN-VXLAN no admiten el protocolo de enrutamiento IS-IS.

  • Filtros de firewall VLAN aplicados a interfaces IRB en las que está habilitada EVPN-VXLAN.

  • El reenvío basado en filtros (FBF) no se admite en las interfaces IRB utilizadas en un entorno EVPN-VXLAN.

  • Los conmutadores QFX10002, QFX10008 y QFX10016 no admiten la duplicación de puertos ni el análisis cuando también se configura EVPN-VXLAN.

  • Cuando configure las interfaces IRB en un dispositivo que admita simultáneamente VLAN configuradas tanto en una superposición de puente de enrutamiento centralizado como en una superposición de puente de enrutamiento de borde, la dirección MAC IRB y la dirección MAC de puerta de enlace virtual en la interfaz IRB para la superposición de puente de enrutamiento centralizado deben ser diferentes de la dirección MAC IRB y la dirección MAC de puerta de enlace virtual en la interfaz IRB para la superposición de puente enrutado de borde.

  • En una superposición EVPN-VXLAN, no se admite la ejecución de un protocolo de enrutamiento en una interfaz IRB que se encuentre en una instancia de enrutamiento predeterminada (default.inet.0). En su lugar, recomendamos incluir la interfaz IRB en una instancia de enrutamiento del tipo vrf.

  • En un entorno EVPN-VXLAN, no se admite la configuración de puertas de enlace anycast con la default-gateway instrucción y la advertise instrucción en vínculos que participan en el mismo segmento Ethernet (ES).

  • Debe configurar reglas de reescritura de clase de servicio (CoS) para que los bits de punto de código de servicios diferenciados (DSCP) se copien desde el encabezado VXLAN interno al encabezado VXLAN externo.

Restricciones de VXLAN en enrutadores de la serie PTX10000

  • Debe habilitar la terminación de túnel globalmente en dispositivos de la serie PTX10K en implementaciones EVPN-VXLAN, como se indica a continuación:

    set forwarding-options tunnel-termination

    Esta opción está desactivada de forma predeterminada.

  • No puede usar un filtro de firewall en estos dispositivos para bloquear la terminación del túnel VXLAN en puertos específicos, pero puede usar el siguiente comando para bloquear la terminación del túnel VXLAN para un puerto:

    set interfaces logical-interface-name unit n family inet/inet6 no-tunnel-termination

    Agregar la opción sin terminación de túnel deshabilita la terminación de túnel para todo el tráfico en el puerto específico donde está configurado.

Restricciones de VXLAN en todos los dispositivos

  • Si configura varias subunidades en un puerto con un ESI, no se admite la operación de desactivación (set interfaces logical-interface-name unit n disable) en esas interfaces lógicas.