Restricciones de VXLAN en dispositivos de la serie EX, la serie QFX, la serie PTX y la serie ACX

(Conmutadores QFX5130-32CD y QFX5700) No se admite una arquitectura de puente de enrutamiento centralizado (CRB) mediante un modelo de spine colapsada cuando:

• Una interfaz utiliza configuraciones de estilo empresarial y de proveedor de servicios en la edit interfaces interface-name jerarquía.

• Varios puertos de acceso en el mismo dominio de puente VXLAN usan una mezcla de estilos empresariales y de proveedores de servicios.

Configuración de estilo empresarial

Configuración de estilo de proveedor de servicios

Configuración flexible de servicios Ethernet

Escenarios admitidos:

• Un spine colapsada y ninguna VLAN está configurado con una interfaz local.

• Una spine colapsada y algunas VLAN en el dispositivo se configuran sin una interfaz local, mientras que algunas VLAN en el dispositivo se configuran mediante el estilo empresarial en interfaces orientadas a CE.

• Un spine colapsado y todas las VLAN del dispositivo se configuran con flexible-ethernet-services encapsulación en una interfaz física, mientras que varias interfaces lógicas se configuran con el estilo empresarial o de proveedor de servicios.

Escenarios no admitidos:

• Un spine colapsada y cualquier interfaz local en el dispositivo incluye todas las VLAN configuradas. La solución alternativa para este escenario es utilizar flexible-ethernet-services la encapsulación en la interfaz física.

• Un spine colapsada en el que algunas VLAN del dispositivo no están configuradas en ninguna interfaz local y algunas VLAN están configuradas con el estilo del proveedor de servicios en interfaces orientadas a la CE. La solución alternativa para este escenario es configurar un vlan-idarchivo .

• Una spine colapsada en la que algunas VLAN del dispositivo no forman parte de ninguna interfaz y algunas VLAN están configuradas mediante flexible-ethernet-services encapsulación en varias interfaces lógicas con estilo empresarial. La solución alternativa para este escenario es configurar un vlan-idarchivo .

La compatibilidad con VXLAN en un chasis virtual o una estructura del chasis virtual (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 conectar de múltiples conexiones a conmutadores EX4400 independientes, pero no se admite la multiconexión de un host con interfaces ESI-LAG para EX4400 Chasis virtual.

• 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 se pueden multiconexión en conmutadores EX4100 independientes, pero no se admite la multiconexión de un host con interfaces ESI-LAG para el chasis virtual EX4100.

• En las redes de centros de datos, admitimos EVPN-VXLAN solo en un chasis virtual o VCF que consista en todos los conmutadores QFX5100, y no en ningún otro chasis virtual o VCF mixto o no mixto. Admitimos VCF en entornos de centro 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 chasis virtual o VCF QFX5100, ya que la compatibilidad de la función solo está a la par con la compatibilidad de conmutadores QFX5100 independientes que ejecutan Junos OS versión 14.1X53-D40.

  Hemos dejado de ser compatibles con VCF en general a partir de la versión 21.4R1 de Junos OS.

• Cuando un chasis virtual QFX5100 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 el chasis virtual aprende una dirección MAC de un paquete entrante en un conmutador miembro de chasis virtual y, luego, debe reenviar ese paquete a través de los vínculos del puerto de chasis virtual (VCP) a otro conmutador miembro en el chasis virtual en el camino hacia su destino. El chasis virtual marca la dirección MAC como vista de nuevo en el segundo conmutador miembro, por lo que es posible que la dirección MAC no agotada durante uno o dos intervalos de antigüedad adicionales después del primero. El aprendizaje de MAC no se puede desactivar en interfaces VXLAN solo en el segundo conmutador miembro de chasis virtual, por lo que no puede evitar el retraso adicional en este caso.

(Solo conmutadores QFX5120) El tráfico que se tuneliza a través de una interfaz etiquetada de núcleo frontal de capa 3 o una interfaz IRB se descarta. Para evitar esta limitación, puede configurar el etiquetado de VLAN flexible. 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 de servicios Ethernet flexible, el dispositivo deja caer el tránsito de paquetes encapsulados en VXLAN de capa 2 en esa interfaz. Para solucionar este problema, configure la interfaz en el estilo del proveedor de servicios en lugar del estilo empresarial. Para obtener más información sobre las configuraciones de estilo empresarial y estilo de proveedor de servicios, consulte Encapsulación de servicios Ethernet flexibles. Para obtener una descripción general de 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 admitimos configuraciones de estilo empresarial, estilo de proveedor de servicios y VLAN nativa 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 estilo de proveedor de servicios, consulte Encapsulación de servicios Ethernet flexibles.

(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 predeterminada de enrutamiento de conmutadores 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 de conmutadores.

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

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

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

• Utilice interfaces físicas de capa 3 en lugar de interfaces IRB para el acceso remoto de VTEP.

(Conmutadores QFX5110) De forma predeterminada, el enrutamiento del tráfico entre una interfaz lógica 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) que se usan en redes superpuestas EVPN-VXLAN no admiten el protocolo de enrutamiento SI-SI.

(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 la 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 de troncalización xe-0/0/0, cualquier otra VLAN que sea miembro de xe-0/0/0 también debe asignarse a una VXLAN.

(Conmutadores QFX5110, QFX5120, EX4100 y EX4400) No se admiten interfaces lógicas VXLAN y no VXLAN en la misma interfaz física que usa configuraciones de interfaz de estilo empresarial.

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

Cuando configure 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 utilizará 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 se asigna una VLAN dinámica a un puerto, esa 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 autenticación para obtener más información sobre la asignación dinámica de VLAN con un servidor RADIUS.

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

La fragmentación y desfragmentación de IP no se admiten en el lado de la capa 3.

Las siguientes características no se admiten en el lado de la capa 2:

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

• Grupos de troncos redundantes (RTG).

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

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

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

• Supervisión de 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 de Contrail. Para obtener más información, consulte Características compatibles con interfaces administradas por OVSDB.

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

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

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

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

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

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

  admitimos estas características de seguridad de acceso en interfaces de acceso de capa 2 asociadas con VLAN asignadas a VXLAN:

  • Supervisión 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 (AR)

  Estas características solo se admiten en conexiones de interfaz de acceso de una sola conexión.

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 usa un controlador SDN para el plano de control (OVSDB-VXLAN).

La replicación de nodos de entrada se admite con EVPN-VXLAN.

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

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

(Solo conmutadores QFX5110) Los filtros de firewall de VLAN no se admiten en interfaces IRB en las que EVPN-VXLAN está habilitado.

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

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

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

• (Conmutadores EX4650, QFX5110 y QFX5120) Admitimos el filtrado y la regulación 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 regulación de entrada en interfaces VXLAN no enrutadas como ACL de puerto de entrada [IPACL]).

• (Conmutadores QFX5110 y QFX5120) El soporte de 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 de Ethernet flexibles, que es un tipo de encapsulación que permite que una interfaz física admita los estilos de configuración de interfaz de proveedor de servicios y empresa.

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

(Solo conmutadores QFX5100) Con la no-arp-suppression instrucción de configuración, puede desactivar la supresión de solicitudes ARP en una o más VLAN especificadas. Sin embargo, a partir de la versión 18.4R3 de Junos OS, 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 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 .

Los conmutadores QFX5120-48Y, QFX5120-32C y QFX5200 admiten multirrutas 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, a continuación, se desencapsula mediante un conmutador QFX5xxx que no admite ECMP jerárquico, el conmutador no puede resolver los dos niveles de rutas que se encontraban en el paquete interno. Luego, 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 puentes de enrutamiento centralizado como en una superposición de puentes de enrutamiento perimetral, la dirección MAC de 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 de IRB y la dirección MAC de puerta de enlace virtual en la interfaz IRB para la superposición de puente de borde enrutado.

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

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

• (Solo conmutadores QFX5120) De forma predeterminada, los conmutadores QFX5120 asignan 5 MB de un 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 superar el espacio de búfer. Para evitar que el conmutador deje caer paquetes de multidifusión cuando se produzca esta situación, puede realizar una de las siguientes acciones:

  • Utilice la shared-buffer instrucción de configuración 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 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 formador en el vínculo de salida.

• (Solo conmutadores QFX5xxx ) Si habilitó el control de tormentas en una interfaz, es posible que observe una diferencia significativa entre las velocidades de tráfico configuradas y reales de la interfaz. Esta diferencia es el resultado de un medidor interno de control de tormentas que cuantifica la velocidad de tráfico real de 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 de 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 más información sobre los diferentes tipos de sesiones de BFD que puede configurar.

(Conmutadores QFX5130-32CD, QFX5130E-32CD, QFX5130-48C, QFX5700 y QFX5700E) A partir de las versiones 25.2X100-D10 y 25.4R1 de Junos OS evolucionado, admitimos BFD en línea asistido por hardware con temporizadores de 100 x 3 milisegundos a través de túneles VXLAN solo en las plataformas enumeradas. Esta compatibilidad se aplica a:

• BFD multisalto tipo 2 IPv4 o IPv6 L2 y L3 con ECMP o VTEP multiconexión con estos requisitos:

  • Temporizadores de 100 x 3 ms

  • Superposición de emparejamiento de BGP entre circuitos cerrados

  • BFD configurado en las sesiones de BGP superpuestas

• BFD de múltiples saltos IPv4 o IPv6 tipo 5 con ECMP

• Instancias de enrutamiento puro tipo 5

(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 puertos virtuales y de túneles que usan los conjuntos de características de 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 y dominios de puente L2 como subunidades de la misma interfaz con un IRB en configuraciones de estilo de proveedor de servicios.

Los MC-LAG no son compatibles con VXLAN.

La fragmentación de IP no se admite en el lado de la capa 3.

Las siguientes características no se admiten en el lado de la capa 2:

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

• STP (cualquier variante).

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

• Supervisión de DHCP.

• Inspección ARP dinámica.

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

La replicación de nodos de entrada no se admite cuando se usa un controlador SDN para el plano de control (OVSDB-VXLAN). La replicación de nodos de entrada se admite para EVPN-VXLAN.

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

Cuando la base de datos de salto siguiente en un conmutador QFX10000 incluye saltos siguientes para la red subyacente y la red superpuesta EVPN-VXLAN, el salto siguiente a un par VXLAN no puede ser un identificador de segmento Ethernet (ESI) o una interfaz de punto de conexión de túnel virtual (VTEP).

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

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

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

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

Cuando configure las interfaces IRB en un dispositivo que admita simultáneamente VLAN configuradas tanto en una superposición de puentes de enrutamiento centralizado como en una superposición de puentes de enrutamiento perimetral, la dirección MAC de 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 de IRB y la dirección MAC de puerta de enlace virtual en la interfaz IRB para la superposición de puente de borde enrutado.

En un entorno de EVPN-VXLAN, no se admite la configuración de puertas de enlace de difusión por proximidad con la default-gateway instrucción y la advertise instrucción en vínculos que participen en el mismo segmento de 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 del encabezado VXLAN interno al encabezado VXLAN externo.

Debe habilitar la terminación de túnel globalmente en dispositivos serie PTX10000 en implementaciones de EVPN-VXLAN, de la siguiente manera:

set forwarding-options tunnel-termination

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

Los pares de multiconexión dentro de un centro de datos deben ser de una familia de productos similar. No recomendamos mezclar la serie ACX con la serie QFX, la serie PTX o la serie MX para la multiconexión.

(Enrutadores ACX 7xxx) Las redes con escala MAC e IP deben configurar set system packet-forwarding-options hw-db-profile cloud-metro. El valor predeterminado es lean-edge, que está pensado para la escala IP.

(Enrutadores ACX 7xxx) El equilibrio de carga no está habilitado de forma predeterminada. Aquí se muestra una configuración de ejemplo. Configure solo las opciones necesarias para su despliegue.

(Enrutadores ACX 7xxx) Configure set system packet-forwarding-options system-profile vxlan-extended para admitir una base IPv6 EVPN-VXLAN.

(Enrutadores ACX 7xxx) Configure set system packet-forwarding-options system-profile vxlan-stitching para admitir la unión de EVPN-VLXAN a EVPN-VXLAN y la unión de EVPN-VXLAN a EVPN-MPLS con no-control-word soporte.

(Enrutadores ACX 7xxx) Configure set system packet-forwarding-options system-profile vxlan-stitching control-word para admitir funciones de palabra de control en una red EVPN-VXLAN a EVPN-MPLS cosida. Consulte vxlan-stitching para obtener información adicional acerca de la compatibilidad con palabras de control.

(Enrutadores ACX 7xxx) Una dirección de puerta de enlace virtual definida por el usuario (VGA) IPv4 MAC (virtual-gateway-v4-mac) y una VGA definida por el usuario IPv6 MAC (virtual-gateway-v6-mac) serán compatibles con todo el sistema.

(Enrutadores ACX 7xxx) Configure set system packet-forwarding-options no-ip-tos-rewrite para propagar la información DSCP de la carga útil al encabezado del enrutador VXLAN durante la encapsulación de VXLAN.

(Enrutadores ACX 7xxx) La configuración de ESI en modo de multiconexión EVPN se admite por dispositivo de interfaz física o solo por interfaz LAG.

(Enrutadores ACX 7xxx) Las interfaces IRB no se admiten como redes subyacentes EVPN-VXLAN.

(Enrutadores ACX 7xxx) Para la unión de EVPN-VXLAN a EVPN-MPLS, los dispositivos que no admitan el reenvío basado en etiquetas de dominio de puente no serán compatibles con los dispositivos de la serie ACX como GW de par de CC.

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

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

La detección de UMT de ruta (PMTUD) no se admite en interfaces VTEP en implementaciones de EVPN-VXLAN. Los encabezados VXLAN agregan de 50 a 54 bytes a los paquetes a lo largo de las rutas de transmisión de túnel VXLAN. Dado que el método PMTUD no se puede usar para determinar dinámicamente el tamaño de UMT, debe asegurarse de establecer manualmente el tamaño de UMT adecuadamente en las interfaces físicas de VTEP para manejar paquetes encapsulados por VXLAN sin fragmentación.