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

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

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

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

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

• Nas redes de data center, oferecemos suporte a EVPN-VXLAN apenas em um Virtual Chassis ou VCF que consiste em todos os switches QFX5100, e não em nenhum outro Virtual Chassis ou VCF misto ou não misto. Oferecemos suporte a VCF em ambientes de data center EVPN-VXLAN que executam versões do Junos OS a partir de 14.1X53-D40 e antes do 17.1R1. No entanto, não recomendamos usar o EVPN-VXLAN em um QFX5100 Virtual Chassis ou VCF, pois o suporte ao recurso é compatível apenas com suporte em switches QFX5100 autônomos que executam o Junos OS Release 14.1X53-D40.

  Nós depreciamos o suporte de VCF em geral do Junos OS Release 21.4R1 em diante.

• Quando um Virtual Chassis QFX5100 aprende um endereço MAC em uma interface VXLAN, a entrada na tabela MAC pode possivelmente 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 a partir de um pacote de entrada em um switch de membro do Virtual Chassis e, em seguida, deve encaminhar esse pacote pela porta Virtual Chassis (VCP) links 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 switch de segundo membro, de modo que o endereço MAC pode não envelhecer para 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.

(apenas com switches QFX5120) O tráfego que é tunelado por uma interface de tags de Camada 3 ou interface IRB voltada para o núcleo é desativado. Para evitar essa limitação, você pode configurar tags VLAN flexíveis. Para obter mais informações, veja Entenda as VXLANs.

(QFX5110 e QFX5120) Se você configurar uma interface no estilo empresarial com encapsulamento flexível de serviços Ethernet, o dispositivo derruba pacotes encapsulados de Camada 2 VXLAN nessa interface. Para resolver 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 o estilo empresarial e as configurações de estilo de provedor de serviços, consulte o Encapsulamento flexível de serviços Ethernet. Para ter uma visão geral da configuração de serviços Ethernet flexíveis em uma malha EVPN-VXLAN, consulte Entendendo o suporte flexível aos serviços Ethernet com eVPN-VXLAN.

(switches de QFX5110 e QFX5120) Nas malhas EVPN-VXLAN, não oferecemos suporte a estilo empresarial, estilo de provedor de serviços e configurações VLAN nativas na mesma interface física se o VLAN nativo for o mesmo 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 o estilo empresarial e as configurações de estilo de provedor de serviços, consulte o Encapsulamento flexível de serviços Ethernet.

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

(switches QFX5100, QFX5110, QFX5200 e QFX5210) Oferecemos suporte à configuração de VXLAN na instância de roteamento de 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 de 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 VTEP próximo salto em interfaces IRB underlay VXLAN. Se você não quiser usar várias portas de saída, mas precisar de mais de um próximo salto VTEP, como uma solução alternativa, você pode fazer um dos seguintes:

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

• Use interfaces físicas de Camada 3 em vez de interfaces IRB para alcançar AVTEP remotamente.

(switches QFX5110) Por padrão, o roteamento do tráfego entre uma 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 está habilitado. Se essa funcionalidade de roteamento for necessária em sua rede EVPN-VXLAN, você pode realizar alguma configuração adicional para fazê-la funcionar. Para obter mais informações, veja Como configurar VXLANs e interfaces lógicas de camada 3 para interoperar.

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

(switches QFX5100, QFX5110, QFX5120, QFX5200, QFX5210, EX4300-48MP e EX4600) Uma interface física não pode ser um membro de uma VLAN e uma VXLAN. Ou seja, uma interface que executa o encapsulamento e o des encapsulamento VXLAN também não pode ser um membro de uma VLAN. Por exemplo, se um VLAN mapeado para um VXLAN for um membro da porta de tronco xe-0/0/0, qualquer outro VLAN que seja um membro do xe-0/0/0 também deve ser atribuído 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.

(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 muda dinamicamente o tráfego do VLAN original para um VLAN dinâmico que você configura como um VLAN habilitado para VXLAN. Uma VLAN habilitada para VXLAN é uma VLAN para a qual você configura um mapeamento de identificador de rede VXLAN (VNI) usando a vxlan vni vni declaração na [edit vlans vlan-name] hierarquia.

Quando você configura o VLAN dinâmico 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 um membro de uma VLAN, a porta usa o 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 lançamentos antes do Junos OS Release 22.2R3-S3, quando qualquer VLAN dinâmico é atribuído a uma porta, esse VLAN já deve ter sido configurado estaticamente em outra porta do dispositivo. A partir do Junos OS Release 22.2R3-S3, não temos mais essa restrição.

Veja a autenticação 802.1X e a 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.

Os grupos de agregação de enlaces multichassis (MC-LAGs) não têm suporte para o VXLAN.

A fragmentação e o desfragmentação de IP não são suportados no lado da Camada 3.

Os recursos a seguir 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).

• A capacidade de desativar uma interface de Camada 2 ou derrubar temporariamente a interface quando um nível de controle de tempestade é excedido não é suportada.

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

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

• DHCP bisbilhotando.

• Inspeção dinâmica de ARP.

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

Algumas exceções incluem:

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

• Nesses dispositivos que servem como gateways VXLAN L2 em redes de sobreposição de pontes com roteamento central da EVPN-VXLAN:

  • Switches multigigabit EX4300 a partir do Junos OS Release 19.4R1

  • Switches EX4400 a partir do Junos OS Release 21.1R1

  • Switches multigigabit EX4400 a partir do Junos OS Release 21.2R1

  • Switches EX4100 e EX4100-F a partir do Junos OS Release 22.3R1

  • Switches multigigabit EX4100 a partir do Junos OS Release 22.3R1

  oferecemos suporte a esses recursos de segurança de acesso em interfaces de acesso de Camada 2 que estão associadas a VLANs mapeadas por VXLAN:

  • DHCPv4 e DHCPv6 bisbilhotando

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

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

  • Guarda-fonte IPv4 e IPv6

  • Guarda de anúncio de roteador (RA)

  Oferecemos suporte a esses recursos apenas em conexões de interface de acesso de casa única.

A replicação de nós 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ós de entrada é suportada com EVPN-VXLAN.

O PIM-BIDIR e o PIM-SSM não têm suporte para VXLANs.

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

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

(switches EX4650 e série QFX5000) Filtro de firewall e suporte para o policiador:

• (switches QFX5100) Os filtros de firewall e os policiais 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 o policiamento de firewall são suportados apenas no ponto de entrada de quadros não encapsulados roteados pela interface IRB.

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

• (switches de 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 de QFX5110 e QFX5120) O suporte de filtragem e policiamento em interfaces VXLAN não roteadas se estende até a direção da 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, onde uma interface física é dividida em várias interfaces lógicas, cada uma das quais é dedicada a uma VLAN de um cliente específico. O extended-vlan-bridge tipo de encapsulamento está 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 a provedores de serviços e estilos empresariais de configuração de interface.

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

(apenas com switches QFX5100) Usando a declaração de no-arp-suppression configuração, você pode desativar a supressão de solicitações de 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 isso, você pode usar uma dessas opções de configuração:

• Use um comando de lote 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 multicaminhos hierárquicos de igual custo (ECMP), o que permite que esses switches realizem uma resolução de rota de dois níveis. No entanto, todos os outros switches QFX5xxx não oferecem suporte a ECMP hierárquico. Como resultado, quando um pacote EVPN Type-5 é encapsulado com um cabeçalho VXLAN e depois des encapsulado por um switch QFX5xxx que não oferece suporte a ECMP hierárquico, o switch é incapaz de resolver os dois níveis de rotas que estavam no pacote interno. Em seguida, o switch derruba o pacote.

(switches QFX5100, QFX5110, QFX5120, QFX5200 e QFX5210) Quando você configura as interfaces IRB em um dispositivo que está suportando simultaneamente VLANs configuradas em uma sobreposição de ponte roteada centralmente e uma sobreposição de pontes roteada na borda, o endereço MAC IRB e o endereço MAC de gateway virtual na interface IRB para a sobreposição de pontes roteada centralmente devem ser diferentes do endereço MAC IRB e endereço MAC de gateway virtual na interface IRB para a sobreposição de pontes roteadas na borda.

(apenas switches de QFX5110 e QFX5120) Em um overlay EVPN-VXLAN, não oferecemos suporte para executar 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 seguintes restrições se aplicam a VXLANs e VLANs.

• (apenas 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 do que /16 para prefixos IPv4 ou igual ou maior que /64 para prefixos IPv6. Se uma máscara de sub-rede que você especifica não atender a esses parâmetros, as rotas especificadas não serão vazados.

• (apenas com switches QFX5120) Por padrão, os switches QFX5120 alocam 5 MB de um buffer compartilhado para absorver rajadas de tráfego multicast. Se uma explosão de tráfego multicast exceder 5 MB, o switch soltará os pacotes que o switch recebe após o espaço buffer ser excedido. Para evitar que o switch deixe cair pacotes multicast quando essa situação ocorre, você pode fazer um dos seguintes:

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

  • No switch da Juniper Networks do qual as rajadas de tráfego multicast estão chegando, aplique um shaper no link de saída.

• (apenas switches QFX5xxx ) Se você tiver habilitado o controle de tempestade em uma interface, você pode 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 QFX5xx e EX46xx) Você não pode usar a detecção bidirecional de encaminhamento bidirecional (BFD) assistida por hardware com encapsulamento VXLAN de pacotes BFD. Além disso, se você configurar peerings BGP overlay EVPN, use BFD distribuído em vez de BFD em linha assistida por hardware. Veja como o BFD detecta falhas de rede para obter detalhes sobre os diferentes tipos de sessões de BFD que você pode configurar.

(switches QFX5xx 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 portas virtuais e de túnel usadas pelos conjuntos de recursos MPLS e VXLAN.

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

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

Os MC-LAGs não contam com o VXLAN.

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

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

• IGMP bisbilhotando com EVPN-VXLAN nos lançamentos 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 compatíveis com o VXLAN. Por exemplo, os seguintes recursos não são suportados:

• DHCP bisbilhotando.

• Inspeção dinâmica de ARP.

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

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

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

Quando o banco de dados de próximo salto em um switch QFX10000 inclui próximos saltos 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 segmentos Ethernet (ESI) ou uma interface de endpoint de túnel virtual (VTEP).

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

Filtros de firewall VLAN aplicados às interfaces IRB nas quais a EVPN-VXLAN está habilitada.

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

QFX10002, QFX10008 e switches de QFX10016 não suportam espelhamento e análise de portas quando a EVPN-VXLAN também está configurada.

Quando você configura as interfaces IRB em um dispositivo que está suportando simultaneamente VLANs configuradas em uma sobreposição de ponte roteada centralmente e uma sobreposição de pontes roteada na borda, o endereço MAC IRB e o endereço MAC de gateway virtual na interface IRB para a sobreposição de pontes roteada centralmente devem ser diferentes do endereço MAC IRB e endereço MAC de gateway virtual na interface IRB para a sobreposição de pontes roteadas na borda.

Em um overlay EVPN-VXLAN, não oferecemos suporte para executar 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 gatewayscast com a default-gateway declaração e a advertise declaração sobre links que participam do mesmo segmento de Ethernet (ES).

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

Você deve habilitar a rescisã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 rescisão do túnel VXLAN em portas específicas, mas pode usar o seguinte comando para bloquear o término do túnel VXLAN para uma porta:

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

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