Restrições de VXLAN em dispositivos da Série EX, Série QFX, Série PTX e Série ACX

(QFX5130-32CD e QFX5700 switches) Não oferecemos suporte a uma arquitetura de ponte com roteamento central (CRB) usando um modelo de spine colapsada quando:

• Uma interface usa configurações de estilo corporativo e de provedor de serviços na edit interfaces interface-name hierarquia.

• Várias portas de acesso no mesmo domínio de ponte VXLAN usam uma mistura de estilos empresariais e de provedores de serviços.

Configuração de estilo empresarial

Configuração de estilo do Provedor de serviços

Configuração flexível de serviços Ethernet

Cenários compatíveis:

• Uma spine colapsada não colapsada e nenhuma VLAN é configurada com uma interface local.

• Uma spine colapsada e algumas VLANs no dispositivo são configuradas sem uma interface local, enquanto algumas VLANs no dispositivo são configuradas usando o estilo empresarial em interfaces voltadas para a CE.

• Uma spine colapsada e todas as VLANs no dispositivo são configuradas com flexible-ethernet-services encapsulamento em uma interface física, enquanto várias interfaces lógicas são configuradas com o estilo corporativo ou de provedor de serviços.

Cenários sem suporte:

• Uma spine colapsada e qualquer interface local no dispositivo incluem todas as VLANs configuradas. A solução alternativa para esse cenário é usar flexible-ethernet-services o encapsulamento na interface física.

• Uma spine colapsada em que algumas VLANs no dispositivo não estão configuradas em nenhuma interface local e algumas VLANs são configuradas usando o estilo de provedor de serviços em interfaces voltadas para CE. A solução alternativa para esse cenário é configurar um vlan-id.

• Uma spine colapsada em que algumas VLANs no dispositivo não fazem parte de nenhuma interface e algumas VLANs são configuradas usando flexible-ethernet-services encapsulamento em várias interfaces lógicas, usando o estilo empresarial. A solução alternativa para esse cenário é configurar um vlan-id.

O suporte a VXLAN em um Virtual Chassis ou Virtual Chassis Fabric (VCF) tem as seguintes restrições e recomendações:

• Oferecemos suporte para EVPN-VXLAN em um Virtual Chassis EX4300-48MP apenas em redes de campus.

• Os switches autônomos EX4400 e o EX4400 Virtual Chassis oferecem suporte a EVPN-VXLAN. Para casos de uso de multihoming, os hosts podem ser multihomed para switches EX4400 autônomos, mas não oferecemos suporte para multihoming de um host com interfaces ESI-LAG para o EX4400 Virtual Chassis.

• Os switches EX4100 (EX4100 e EX4100-F) autônomos e o EX4100 Virtual Chassis (EX4100 e EX4100-F) oferecem suporte a EVPN-VXLAN. Para casos de uso de multihoming, os hosts podem ser multihomed para switches EX4100 autônomos, mas não oferecemos suporte para multihoming de um host com interfaces ESI-LAG para o EX4100 Virtual Chassis.

• Em redes de data center, oferecemos suporte ao EVPN-VXLAN apenas em um Virtual Chassis ou VCF que consiste em todos os switches QFX5100, e não em qualquer outro Virtual Chassis ou VCF misto ou não misto. Oferecemos suporte ao VCF em ambientes de data center EVPN-VXLAN executando versões do Junos OS a partir de 14.1X53-D40 e anteriores a 17.1R1. No entanto, não recomendamos o uso de EVPN-VXLAN em um QFX5100 Virtual Chassis ou VCF porque o suporte ao recurso está em paridade apenas com o suporte em switches QFX5100 autônomos executando o Junos OS Release 14.1X53-D40.

  Obsolemos o suporte ao VCF em geral do Junos OS Release 21.4R1 em diante.

• Quando um QFX5100 Virtual Chassis aprende um endereço MAC em uma interface VXLAN, a entrada da tabela MAC pode levar de 10 a 15 minutos para envelhecer (duas a três vezes o intervalo de envelhecimento padrão de 5 minutos). Isso acontece quando o Virtual Chassis aprende um endereço MAC de um pacote de entrada em um switch de membro do Virtual Chassis e, em seguida, deve encaminhar esse pacote pelos links da porta do Virtual Chassis (VCP) para outro switch de membro no Virtual Chassis a caminho de seu destino. O Virtual Chassis marca o endereço MAC como visto novamente no segundo switch de membro, de modo que o endereço MAC pode não envelhecer por um ou dois intervalos de envelhecimento adicionais além do primeiro. O aprendizado MAC não pode ser desativado em interfaces VXLAN apenas no segundo switch de membro do Virtual Chassis, portanto, você não pode evitar o atraso extra neste caso.

(Somente switches QFX5120) O tráfego que é tunelado por meio de uma interface marcada de Camada 3 voltada para o núcleo ou interface IRB é descartado. Para evitar essa limitação, você pode configurar a marcação VLAN flexível. Para obter mais informações, consulte Noções básicas sobre VXLANs.

(QFX5110 e QFX5120) Se você configurar uma interface no estilo empresarial com encapsulamento flexível de serviços Ethernet, o dispositivo descartará pacotes encapsulados em VXLAN de Camada 2 de trânsito nessa interface. Para contornar esse problema, configure a interface no estilo do provedor de serviços em vez de usar o estilo empresarial. Para obter mais informações sobre configurações de estilo empresarial e de estilo de provedor de serviços, consulte Encapsulamento flexível de serviços Ethernet. Para obter uma visão geral da configuração de serviços Ethernet flexíveis em uma malha EVPN-VXLAN, consulte Entender o suporte a serviços Ethernet flexíveis com EVPN-VXLAN.

(Switches QFX5110 e QFX5120) Nas malhas EVPN-VXLAN, não oferecemos suporte ao estilo empresarial, ao estilo do provedor de serviços e às configurações de VLAN nativas na mesma interface física se a VLAN nativa for a mesma que uma das VLANs na configuração de estilo do provedor de serviços. A VLAN nativa pode ser uma das VLANs na configuração de estilo empresarial. Para obter mais informações sobre configurações de estilo empresarial e de estilo de provedor de serviços, consulte Encapsulamento flexível de serviços Ethernet.

(Switches QFX5xxx) Em uma malha EVPN-VXLAN, você não pode configurar a native-vlan-id declaração na mesma interface em que você habilita a tradução de VLAN com a vlan-rewrite declaração.

(Switches QFX5100, QFX5110, QFX5200 e QFX5210) Oferecemos suporte à configuração de VXLAN na instância de roteamento do switch padrão e em instâncias de roteamento MAC VRF (instance-type mac-vrf).

(Switches EX4300-48MP e EX4600) Oferecemos suporte à configuração de VXLAN apenas na instância de roteamento do switch padrão.

(Switches QFX5100, QFX5200, QFX5210, EX4300-48MP e EX4600) O roteamento de tráfego entre diferentes VXLANs não é suportado.

(Switches QFX5100, QFX5110, QFX5120, EX4600 e EX4650) Esses switches oferecem suporte a apenas um próximo salto VTEP em interfaces IRB de underlay VXLAN. Se você não quiser usar várias portas de saída, mas precisar de mais de uma VTEP no próximo salto, como solução alternativa, você pode fazer o seguinte:

• Coloque um roteador entre o switch e os VTEPs remotos para que apenas um próximo salto esteja entre eles.

• Use interfaces físicas de Camada 3 em vez de interfaces IRB para acessibilidade remota de VTEP.

(Switches QFX5110) Por padrão, o tráfego de roteamento entre um VXLAN e uma interface lógica de Camada 3 — por exemplo, uma interface configurada com o set interfaces interface-name unit logical-unit-number family inet address ip-address/prefix-length comando — não é habilitado. Se essa funcionalidade de roteamento for necessária em sua rede EVPN-VXLAN, você poderá executar algumas configurações adicionais para fazê-la funcionar. Para obter mais informações, consulte Entendendo como configurar VXLANs e interfaces lógicas de Camada 3 para interoperar.

As interfaces de roteamento e ponte integradas (IRB) usadas em redes overlay EVPN-VXLAN não suportam o protocolo de roteamento IS-IS.

(QFX5100, QFX5110, QFX5120, QFX5200, QFX5210, EX4300-48MP e EX4600 switches) Uma interface física não pode ser membro de uma VLAN e de uma VXLAN. Ou seja, uma interface que executa o encapsulamento e o desencapsulamento de VXLAN também não pode ser membro de uma VLAN. Por exemplo, se uma VLAN mapeada para um VXLAN for membro da porta de tronco xe-0/0/0, qualquer outra VLAN que seja membro de xe-0/0/0 também deverá ser atribuída a um VXLAN.

(Switches QFX5110, QFX5120, EX4100 e EX4400) Não oferecemos suporte a interfaces lógicas VXLAN e não VXLAN na mesma interface física usando configurações de interface de estilo empresarial.

(Switches QFX5120, EX4100, EX4300-48MP, EX4400 e EX4650) Com a autenticação 802.1X para tráfego VXLAN em uma porta de acesso, após a autenticação, o servidor RADIUS alterna dinamicamente o tráfego da VLAN original para uma VLAN dinâmica que você configura como uma VLAN habilitada para VXLAN. Uma VLAN habilitada para VXLAN é uma VLAN para a [edit vlans vlan-name] qual você configura um mapeamento de identificador de rede (VNI) VXLAN usando a vxlan vni vni declaração na hierarquia.

Ao configurar a VLAN dinâmica 802.1X e seu mapeamento VNI correspondente, você também deve configurar a VLAN original como uma VLAN habilitada para VXLAN com um mapeamento VNI. Se você não configurar explicitamente a porta como membro de uma VLAN, a porta usará a VLAN padrão. Nesse caso, você deve configurar a VLAN padrão como uma VLAN habilitada para VXLAN com um mapeamento VNI.

Além disso, em versões anteriores ao Junos OS Release 22.2R3-S3, quando qualquer VLAN dinâmica é atribuída a uma porta, essa VLAN já deve ter sido configurada estaticamente em outra porta do dispositivo. A partir do Junos OS Release 22.2R3-S3, não temos mais essa restrição.

Consulte Autenticação 802.1X e Configuração do Servidor RADIUS para Autenticação para obter mais informações sobre a atribuição dinâmica de VLAN com um servidor RADIUS.

Grupos de agregação de enlaces multichassis (MC-LAGs) não são suportados com o VXLAN.

Não há suporte para fragmentação e desfragmentação de IP no lado da Camada 3.

Os seguintes recursos não são suportados no lado da Camada 2:

• (Switches QFX5100, QFX5200, QFX5210, EX4300-48MP e EX4600) IGMP bisbilhotando com EVPN-VXLAN.

• Grupos de tronco redundantes (RTGs).

• Não há suporte para a capacidade de desligar uma interface de Camada 2 ou desativar temporariamente a interface quando um nível de controle de tempestade é excedido.

• Não oferecemos suporte a recursos completos de STP, MSTP, RSTP ou VSTP (xSTP) com o VXLAN. No entanto, você pode configurar o xSTP na borda (porta de acesso) para suporte a bloco na borda de BPDU. Consulte Proteção de BPDU para protocolos de spanning tree para obter detalhes.

Os recursos de segurança da porta de acesso, como os seguintes, não são suportados com o VXLAN:

• Espionagem de DHCP.

• Inspeção dinâmica de ARP.

• Limitação de MAC e limitação de movimento MAC.

Algumas exceções incluem:

• A limitação MAC é suportada em interfaces gerenciadas por OVSDB em um ambiente OVSDB-VXLAN com controladores Contrail. Para obter mais informações, consulte Recursos suportados em interfaces gerenciadas por OVSDB.

• Nesses dispositivos que servem como gateways L2 VXLAN em redes overlay de ponte com roteamento central EVPN-VXLAN:

  • Switches multigigabit EX4300 a partir do Junos OS versão 19.4R1

  • Switches EX4400 a partir do Junos OS versão 21.1R1

  • Switches multigigabit EX4400 a partir do Junos OS versão 21.2R1

  • Switches EX4100 e EX4100-F a partir do Junos OS versão 22.3R1

  • Switches multigigabit EX4100 a partir do Junos OS versão 22.3R1

  oferecemos suporte a esses recursos de segurança de acesso em interfaces do lado de acesso de Camada 2 associadas a VLANs mapeadas em VXLAN:

  • Bisbilhotamento de DHCPv4 e DHCPv6

  • Inspeção dinâmica de ARP (DAI)

  • Inspeção de descoberta de vizinhos (NDI)

  • Guarda de origem IPv4 e IPv6

  • Proteção de anúncio de roteador (RA)

  Oferecemos suporte a esses recursos apenas em conexões de interface de acesso single-homed.

A replicação do nó de entrada não é suportada nos seguintes casos:

• Quando o PIM é usado para o plano de controle (VXLAN manual).

• Quando um controlador SDN é usado para o plano de controle (OVSDB-VXLAN).

A replicação de nó de entrada é suportada com EVPN-VXLAN.

PIM-BIDIR e PIM-SSM não são suportados com VXLANs.

Se você configurar uma instância de espelhamento de porta para espelhar o tráfego que sai de uma interface que executa o encapsulamento VXLAN, os endereços MAC de origem e destino dos pacotes espelhados serão inválidos. O tráfego VXLAN original não é afetado.

(Somente switches QFX5110) Os filtros de firewall VLAN não são suportados em interfaces IRB nas quais o EVPN-VXLAN está habilitado.

(switches da Série EX4650 e QFX5000) Suporte a filtro de firewall e policiador:

• (Switches QFX5100) Filtros de firewall e policiadores não são suportados no tráfego de trânsito no qual a EVPN-VXLAN está habilitada. Eles são suportados apenas na direção de entrada em interfaces voltadas para CE.

• (Switches QFX5100) Para interfaces IRB em uma malha IP de uma camada EVPN-VXLAN, a filtragem e a vigilância de firewall são suportadas apenas no ponto de entrada de quadros não encapsulados roteados através da interface IRB.

• (Switches EX4650, QFX5110 e QFX5120) Oferecemos suporte à filtragem e policiamento de entrada para interfaces VXLAN roteadas (interfaces IRB) como listas de controle de acesso de rota de entrada [IRACLs].

• (Switches QFX5110, QFX5120 e QFX5210) Oferecemos suporte à filtragem e policiamento de entrada em interfaces VXLAN não roteadas como ACLs de porta de entrada [IPACLs]).

• (Switches QFX5110 e QFX5120) O suporte à filtragem e vigilância em interfaces VXLAN não roteadas se estende até a direção de saída como ACLs de porta de saída ([EPACLs]).

(Somente switches EX4300-48MP) Os seguintes estilos de configuração de interface não são suportados:

• Estilo de provedor de serviços, em que uma interface física é dividida em várias interfaces lógicas, cada uma das quais é dedicada a uma VLAN de cliente específica. O extended-vlan-bridge tipo de encapsulamento é configurado na interface física.

• Serviços Ethernet flexíveis, que é um tipo de encapsulamento que permite que uma interface física ofereça suporte aos estilos de configuração de interface do provedor de serviços e da empresa.

Para obter mais informações sobre esses estilos de configuração de interface, consulte Encapsulamento flexível de serviços Ethernet.

(Somente switches QFX5100) Usando a no-arp-suppression declaração de configuração, você pode desativar a supressão de solicitações ARP em uma ou mais VLANs especificadas. No entanto, a partir do Junos OS Release 18.4R3, você deve desativar esse recurso em todas as VLANs. Para fazer isso, você pode usar uma destas opções de configuração:

• Use um comando batch para desativar o recurso em todas as VLANs—set groups group-name vlans * no-arp-suppression. Com esse comando, usamos o asterisco (*) como um curinga que especifica todas as VLANs.

• Use um comando para desativar o recurso em cada VLAN individual—set vlans vlan-name no-arp-suppression.

Os switches QFX5120-48Y, QFX5120-32C e QFX5200 oferecem suporte a multipath hierárquico de custo igual (ECMP), que permite que esses switches executem uma resolução de rota de dois níveis. No entanto, todos os outros switches QFX5xxx não oferecem suporte ao ECMP hierárquico. Como resultado, quando um pacote EVPN Tipo 5 é encapsulado com um cabeçalho VXLAN e, em seguida, desencapsulado por um switch QFX5xxx que não oferece suporte a ECMP hierárquico, o switch não consegue resolver os dois níveis de rotas que estavam no pacote interno. Em seguida, o switch descarta o pacote.

(Switches QFX5100, QFX5110, QFX5120, QFX5200 e QFX5210) Quando você configura as interfaces IRB em um dispositivo que oferece suporte simultâneo a VLANs configuradas em uma sobreposição de ponte com roteamento central e uma sobreposição de ponte com roteamento de borda, o endereço MAC do IRB e o endereço MAC do gateway virtual na interface do IRB para a sobreposição de ponte com roteamento central devem ser diferentes do endereço MAC do IRB e do endereço MAC do gateway virtual na interface do IRB para a sobreposição de ponte com roteamento de borda.

(Somente switches QFX5110 e QFX5120) Em um overlay EVPN-VXLAN, não oferecemos suporte à execução de um protocolo de roteamento em uma interface IRB que esteja em uma instância de roteamento padrão (default.inet.0). Em vez disso, recomendamos incluir a interface IRB em uma instância de roteamento do tipo vrf.

As restrições a seguir se aplicam a VXLANs e VLANs.

• (Somente switches QFX5xxx ) Ao configurar o vazamento de rota entre instâncias de roteamento e encaminhamento virtual (VRF), você deve especificar cada prefixo com uma máscara de sub-rede igual ou maior que /16 para prefixos IPv4 ou igual ou maior que /64 para prefixos IPv6. Se uma máscara de sub-rede especificada não atender a esses parâmetros, as rotas especificadas não serão vazadas.

• (Somente switches QFX5120) Por padrão, os switches QFX5120 alocam 5 MB de um buffer compartilhado para absorver explosões de tráfego multicast. Se uma intermitência de tráfego multicast exceder 5 MB, o switch descartará os pacotes que o switch recebe depois que o espaço do buffer for excedido. Para evitar que o switch descarte pacotes de multicast quando essa situação ocorrer, você pode fazer o seguinte:

  • Use a shared-buffer declaração de configuração no [edit class-of-service] nível de hierarquia para realocar uma porcentagem maior do buffer compartilhado para tráfego multicast. Para obter mais informações sobre como ajustar um buffer compartilhado, consulte Noções básicas sobre a configuração do buffer de CoS.

  • No switch da Juniper Networks de onde vêm as rajadas de tráfego multicast, aplique um shaper no enlace de saída.

• (Somente switches QFX5xxx ) Se você tiver habilitado o controle de tempestade em uma interface, poderá notar uma diferença significativa entre as taxas de tráfego configuradas e reais para a interface. Essa diferença é o resultado de um medidor interno de controle de tempestade que quantifica a taxa de tráfego real para a interface em incrementos de 64 kbps, por exemplo, 64 kbps, 128 kbps, 192 kbps e assim por diante.

(switches QFX5xxx e EX46xx) Você não pode usar a Detecção de Encaminhamento Bidirecional (BFD) em linha assistida por hardware com encapsulamento VXLAN de pacotes BFD. Além disso, se você configurar peerings BGP de sobreposição EVPN, use BFD distribuído em vez de BFD em linha assistido por hardware. Consulte Noções básicas sobre como o BFD detecta falhas de rede para obter detalhes sobre os diferentes tipos de sessões de BFD que você pode configurar.

(switches QFX5130-32CD, QFX5130E-32CD, QFX5130-48C, QFX5700 e QFX5700E) A partir das versões 25.2X100-D10 e 25.4R1 do Junos OS Evolved, oferecemos suporte a BFD em linha assistido por hardware com temporizadores de 100 x 3 milissegundos em túneis VXLAN apenas nas plataformas listadas. Esse suporte se aplica a:

• BFD multihop tipo 2 IPv4 ou IPv6 L2 e L3 com ECMP ou VTEPs multihomed com estes requisitos:

  • Temporizadores de 100 x 3 ms

  • Peering BGP overlay entre loopbacks

  • BFD configurado nas sessões de BGP de sobreposição

• BFD multihop IPv4 ou IPv6 tipo 5 com ECMP

• Instâncias de roteamento puro tipo 5

(switches QFX5xxx e EX46xx) Não oferecemos suporte à configuração e ao uso de MPLS e EVPN-VXLAN ao mesmo tempo no mesmo dispositivo. Temos essa restrição porque as plataformas baseadas em Broadcom usam as mesmas tabelas de hardware para armazenar informações de túnel e porta virtual usadas pelos conjuntos de recursos MPLS e VXLAN.

Além disso, você não pode usar uma underlay MPLS com EVPN e uma overlay VXLAN; essa é uma limitação de hardware da Broadcom.

(switches QFX5xxx e EX46xx) Não oferecemos suporte a interfaces L3 marcadas e domínios de ponte L2 como subunidades da mesma interface com um IRB em configurações de estilo de provedor de serviços.

MC-LAGs não são suportados com VXLAN.

A fragmentação de IP não é suportada no lado da Camada 3.

Os seguintes recursos não são suportados no lado da Camada 2:

• IGMP bisbilhotando com EVPN-VXLAN nas versões do Junos OS antes do lançamento do Junos OS 17.2R1.

• STP (qualquer variante).

Os recursos de segurança da porta de acesso não são suportados com o VXLAN. Por exemplo, não há suporte para os seguintes recursos:

• Espionagem de DHCP.

• Inspeção dinâmica de ARP.

• Limitação de MAC e limitação de movimento MAC.

A replicação do nó de entrada não é suportada quando um controlador SDN é usado para o plano de controle (OVSDB-VXLAN). A replicação de nó de entrada é suportada para EVPN-VXLAN.

Os switches QFX10000 implantados em um ambiente EVPN-VXLAN não oferecem suporte a uma rede subjacente física IPv6.

Quando o banco de dados next-hop em um switch QFX10000 inclui next hops para a rede underlay e a rede overlay EVPN-VXLAN, o próximo salto para um peer VXLAN não pode ser um identificador de segmento Ethernet (ESI) ou uma interface de endpoint de túnel virtual (VTEP).

As interfaces IRB usadas em redes overlay EVPN-VXLAN não suportam o protocolo de roteamento IS-IS.

Filtros de firewall VLAN aplicados a interfaces IRB nas quais o EVPN-VXLAN está habilitado.

O encaminhamento baseado em filtro (FBF) não é suportado em interfaces IRB usadas em um ambiente EVPN-VXLAN.

Os switches QFX10002, QFX10008 e QFX10016 não oferecem suporte ao espelhamento e análise de portas quando o EVPN-VXLAN também está configurado.

Quando você configura as interfaces IRB em um dispositivo que oferece suporte simultâneo a VLANs configuradas em uma sobreposição de ponte com roteamento central e uma sobreposição de ponte com roteamento de borda, o endereço MAC do IRB e o endereço MAC do gateway virtual na interface do IRB para a sobreposição de ponte com roteamento central devem ser diferentes do endereço MAC do IRB e do endereço MAC do gateway virtual na interface do IRB para a sobreposição de ponte com roteamento de borda.

Em um overlay EVPN-VXLAN, não oferecemos suporte à execução de um protocolo de roteamento em uma interface IRB que esteja em uma instância de roteamento padrão (default.inet.0). Em vez disso, recomendamos incluir a interface IRB em uma instância de roteamento do tipo vrf.

Em um ambiente EVPN-VXLAN, não oferecemos suporte à configuração de gateways anycast com a declaração e a default-gateway advertise declaração em links que participam do mesmo segmento Ethernet (ES).

Você deve configurar regras de reescrita de classe de serviço (CoS) para que os bits de ponto de código de serviços diferenciados (DSCP) sejam copiados do cabeçalho VXLAN interno para o cabeçalho VXLAN externo.

Você deve habilitar a terminação de túnel globalmente em dispositivos da Série PTX10K em implantações EVPN-VXLAN, da seguinte forma:

set forwarding-options tunnel-termination

Você não pode usar um filtro de firewall nesses dispositivos para bloquear a terminação do túnel VXLAN em portas específicas, mas pode usar o seguinte comando para bloquear a terminação do túnel VXLAN para uma porta:

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

Os pares multihoming dentro de um DC devem ser de uma família de produtos semelhante. Não recomendamos misturar a série ACX com a série QFX, série PTX ou série MX para multihoming.

(Roteadores ACX 7xxx) Redes com escala MAC e IP devem configurar set system packet-forwarding-options hw-db-profile cloud-metro. O padrão é lean-edge, que se destina à escala de IP.

(Roteadores ACX 7xxx) O balanceamento de carga não está habilitado por padrão. Aqui está um exemplo de configuração. Configure apenas as opções necessárias para sua implantação.

(Roteadores ACX 7xxx) Configure set system packet-forwarding-options system-profile vxlan-extended para oferecer suporte a uma underlay EVPN-VXLAN IPv6.

(Roteadores ACX 7xxx) Configure set system packet-forwarding-options system-profile vxlan-stitching para oferecer suporte a pontos EVPN-VLXAN para EVPN-VXLAN e pontos EVPN-VXLAN para EVPN-MPLS com no-control-word suporte.

(Roteadores ACX 7xxx) Configure set system packet-forwarding-options system-profile vxlan-stitching control-word para oferecer suporte a funções de palavra de controle em uma rede EVPN-VXLAN para EVPN-MPLS unida. Consulte vxlan-stitching para obter informações adicionais sobre o suporte a palavras de controle.

(Roteadores ACX 7xxx) Um endereço de gateway virtual (VGA) definido pelo usuário IPv4 MAC (virtual-gateway-v4-mac) e um VGA IPv6 MAC definido pelo usuário (virtual-gateway-v6-mac) serão suportados em todo o sistema.

(Roteadores ACX 7xxx) Configure set system packet-forwarding-options no-ip-tos-rewrite para propagar informações de DSCP do payload para o cabeçalho do roteador VXLAN durante o encapsulamento do VXLAN.

(Roteadores ACX 7xxx) A configuração de ESI no modo multihoming EVPN é suportada por dispositivo de interface física ou apenas por interface LAG.

(Roteadores ACX 7xxx) As interfaces IRB não são suportadas como redes subjacentes EVPN-VXLAN.

(Roteadores ACX 7xxx) Para costura de EVPN-VXLAN para EVPN-MPLS, os dispositivos que não oferecem suporte ao encaminhamento com base em rótulos de domínio de ponte não serão compatíveis com os dispositivos da Série ACX como GWs pares de CC.

Se você configurar várias subunidades em uma porta com um ESI, não oferecemos suporte à operação de desativação (set interfaces logical-interface-name unit n disable) nessas interfaces lógicas.