Entendendo os VXLANs

A tecnologia VXLAN permite segmentar suas redes (como as VLANs), mas oferece benefícios que as VLANs não podem. Aqui estão os benefícios mais importantes do uso de VXLANs:

• Teoricamente, é possível criar até 16 milhões de VXLANs em um domínio administrativo (em vez de 4.094 VLANs em um dispositivo da Juniper Networks).

  • Os roteadores da Série MX e os switches EX9200 oferecem suporte a até 32.000 VXLANs, 32.000 grupos multicast e 8000 endpoints de túnel virtual (VTEPs). Isso significa que os VXLANs baseados em roteadores da Série MX oferecem segmentação de rede na escala exigida pelos construtores de nuvem para oferecer suporte a um número muito grande de locatários.

  • Os switches da Série QFX10000 oferecem suporte a 4000 VXLANs e 2000 VTEPs remotos.

  • Os switches QFX5100, QFX5110, QFX5200, QFX5210 e EX4600 oferecem suporte a 4000 VXLANs, 4000 grupos multicast e 2000 VTEPs remotos.

  • Os switches EX4300-48MP oferecem suporte a 4000 VXLANs.

• Você pode habilitar a migração de máquinas virtuais entre servidores que existem em domínios de Camada 2 separados tunelando o tráfego em redes de Camada 3. Essa funcionalidade permite que você aloque recursos dinamicamente em ou entre data centers sem ser limitado por limites de Camada 2 ou ser forçado a criar domínios de Camada 2 grandes ou geograficamente estendidos.

Usar VXLANs para criar domínios de Camada 2 menores conectados em uma rede de Camada 3 significa que você não precisa usar o Spanning Tree Protocol (STP) para convergir a topologia, mas pode usar protocolos de roteamento mais robustos na rede de Camada 3. Na ausência do STP, nenhum dos seus links é bloqueado, o que significa que você pode obter o valor total de todas as portas que comprar. O uso de protocolos de roteamento para conectar seus domínios de Camada 2 também permite balancear a carga do tráfego para garantir que você obtenha o melhor uso da largura de banda disponível. Dada a quantidade de tráfego leste/oeste que geralmente flui dentro ou entre data centers, maximizar o desempenho da rede para esse tráfego é muito importante.

O vídeo Por que usar uma rede overlay em um data center? apresenta uma breve visão geral das vantagens do uso de VXLANs.

O VXLAN é frequentemente descrito como uma tecnologia de sobreposição porque permite que você estenda conexões de Camada 2 em uma rede de Camada 3 intermediária encapsulando (tunelando) quadros Ethernet em um pacote VXLAN que inclui endereços IP. Os dispositivos que oferecem suporte a VXLANs são chamados de endpoints de túnel virtual (VTEPs) — eles podem ser hosts finais ou switches de rede ou roteadores. Os VTEPs encapsulam o tráfego VXLAN e desencapsulam esse tráfego quando ele sai do túnel VXLAN. Para encapsular um quadro Ethernet, os VTEPs adicionam vários campos, incluindo os seguintes campos:

• Endereço de destino do controle de acesso ao meio externo (MAC) (endereço MAC do endpoint do túnel VTEP)

• Endereço de origem MAC externo (endereço MAC do VTEP de origem do túnel)

• Endereço IP de destino externo (endereço IP do VTEP do endpoint do túnel)

• Endereço IP de origem externo (endereço IP do VTEP de origem do túnel)

• Cabeçalho UDP externo

• Um cabeçalho VXLAN que inclui um campo de 24 bits — chamado de identificador de rede VXLAN (VNI) — que é usado para identificar exclusivamente o VXLAN. O VNI é semelhante a um ID de VLAN, mas ter 24 bits permite que você crie muito mais VXLANs do que VLANs.

A Figura 1 mostra o formato de pacote VXLAN.

Figura 1: Formato de pacote VXLAN

O Junos OS oferece suporte à implementação de VXLANs nos seguintes ambientes:

• VXLAN manual — Nesse ambiente, um dispositivo da Juniper Networks atua como um dispositivo de trânsito para dispositivos downstream que atuam como VTEPs, ou um gateway que fornece conectividade para servidores downstream que hospedam máquinas virtuais (VMs), que se comunicam por uma rede de Camada 3. Nesse ambiente, os controladores de rede definida por software (SDN) não são implantados.

  Observação:

  Os switches QFX10000 não oferecem suporte a VXLANs manuais.

• OVSDB-VXLAN— Nesse ambiente, os controladores SDN usam o protocolo de gerenciamento Open vSwitch Database (OVSDB) para fornecer um meio pelo qual os controladores (como um controlador VMware NSX ou Juniper Networks Contrail) e dispositivos da Juniper Networks que oferecem suporte a OVSDB podem se comunicar.

• EVPN-VXLAN— Nesse ambiente, a VPN Ethernet (EVPN) é uma tecnologia de plano de controle que permite que hosts (servidores físicos e VMs) sejam colocados em qualquer lugar de uma rede e permaneçam conectados à mesma rede overlay lógica de Camada 2, e o VXLAN cria o plano de dados para a rede overlay de Camada 2.

Você pode configurar os switches para executar todas as seguintes funções:

• (Todos os switches, exceto EX4300-48MP) Em um ambiente sem um controlador SDN, atue como um switch de Camada 3 de trânsito para hosts downstream atuando como VTEPs. Nessa configuração, você não precisa configurar nenhuma funcionalidade de VXLAN no switch. Você precisa configurar IGMP e PIM para que o switch possa formar as árvores multicast para os grupos multicast VXLAN. (Veja VXLANs manuais exigem PIM para mais informações.)

• (Todos os switches, exceto EX4300-48MP) Em um ambiente com ou sem um controlador SDN, atue como um gateway de Camada 2 entre redes virtualizadas e não virtualizadas no mesmo data center ou entre data centers. Por exemplo, você pode usar o switch para conectar uma rede que usa VXLANs a uma que usa VLANs.

• (Switches EX4300-48MP) Atuar como um gateway de Camada 2 entre redes virtualizadas e não virtualizadas em uma rede de campus. Por exemplo, você pode usar o switch para conectar uma rede que usa VXLANs a uma que usa VLANs.

• (Todos os switches, exceto EX4300-48MP) Atua como um gateway de Camada 2 entre redes virtualizadas no mesmo data center ou em data centers diferentes e permite que máquinas virtuais se movam (VMotion) entre essas redes e data centers. Por exemplo, se você quiser permitir o VMotion entre dispositivos em duas redes diferentes, poderá criar a mesma VLAN em ambas as redes e colocar os dois dispositivos nessa VLAN. Os switches conectados a esses dispositivos, atuando como VTEPs, podem mapear essa VLAN para o mesmo VXLAN, e o tráfego VXLAN pode então ser roteado entre as duas redes.

• (Switches QFX5110 e QFX5120 com EVPN-VXLAN) Atue como um gateway de Camada 3 para rotear o tráfego entre diferentes VXLANs no mesmo data center.

• (Switches QFX5110 e QFX5120 com EVPN-VXLAN) Atua como um gateway de Camada 3 para rotear o tráfego entre diferentes VXLANs em diferentes data centers por meio de uma WAN ou da Internet usando protocolos de roteamento padrão ou túneis de serviço de LAN privada virtual (VPLS).

Como os cabeçalhos adicionais adicionam 50 a 54 bytes, talvez seja necessário aumentar a MTU em um VTEP para acomodar pacotes maiores. Por exemplo, se o switch estiver usando o valor de MTU padrão de 1514 bytes e você quiser encaminhar pacotes de 1500 bytes pelo VXLAN, será necessário aumentar o MTU para permitir o aumento do tamanho do pacote causado pelos cabeçalhos adicionais.

Começando com o Junos OS versão 14.1X53-D25 nos switches QFX5100, o Junos OS versão 15.1X53-D210 nos switches QFX5110 e QFX5200, o Junos OS versão 18.1R1 nos switches QFX5210 e o Junos OS versão 18.2R1 nos switches EX4600, você pode configurar a porta UDP usada como porta de destino para o tráfego VXLAN. Para configurar a porta de destino do VXLAN para ser algo diferente da porta UDP padrão de 4789, insira a seguinte declaração:

set protocols l2-learning destination-udp-port port-number

A porta que você configurar será usada para todos os VXLANs configurados no switch.

Por padrão, quando a tabela de host atinge sua capacidade, as entradas de host adicionais transbordam para a tabela LPM (Correspondência de Prefixo Mais Longa). Isso pode causar uma degradação do desempenho de roteamento que resulta de entradas de host menores consumindo espaço valioso na tabela LPM.

A partir do Junos OS Release 25.2R1, você pode evitar que as entradas do host transbordem para a tabela LPM configurando a set forwarding-options no-host-as-lpm declaração. Quando você habilita essa opção, as entradas do host são impedidas de entrar na tabela LPM e uma mensagem de erro é registrada para notificá-lo sobre a condição da tabela de host completa. Essa restrição mantém a integridade da tabela LPM para rotas de sub-rede maiores, que normalmente são mais críticas para uma operação de rede eficiente. Essa configuração requer uma reinicialização do PFE para limpar todas as entradas de host existentes da tabela LPM, garantindo que a tabela seja dedicada exclusivamente às rotas de sub-rede que avançam. A reinicialização é crucial para manter um estado limpo, pois evita que qualquer entrada de host residual afete a utilização do espaço de tabela.

A prevenção de estouro de entrada de host é particularmente benéfica para ambientes com altas demandas de entrada de host. O recurso oferece suporte a rotas IPv4 e IPv6 e se aplica a ambientes VXLAN e não VXLAN, tornando-o versátil para vários cenários de implantação. A segregação de rotas de host e sub-rede evita a degradação do desempenho de roteamento resultante do transbordamento de entradas de host para a tabela LPM. Além disso, o sistema gera uma mensagem de log do sistema cada vez que você alterna a opção CLI, fornecendo uma trilha de auditoria para gerenciamento de mudanças e solução de problemas. Aproveitando esse recurso, você pode aprimorar o gerenciamento da tabela de roteamento, melhorar a eficiência do roteamento e garantir o controle sistemático sobre as entradas da tabela de roteamento.

Consulte o Explorador de Recursos para obter uma lista completa dos produtos que oferecem suporte ao recurso de prevenção de estouro de entrada do host.

Quando o switch que atua como um VTEP recebe um pacote de broadcast, unicast desconhecido ou multicast, ele executa as seguintes ações no pacote:

1. Ele desencapsula o pacote e o entrega aos hosts conectados localmente.

2. Em seguida, ele adiciona o encapsulamento VXLAN novamente e envia o pacote para os outros VTEPs no VXLAN.

Essas ações são executadas pela interface de loopback usada como endereço de túnel VXLAN e podem, portanto, afetar negativamente a largura de banda disponível para o VTEP. Começando com o Junos OS versão 14.1X53-D30 para switches QFX5100, o Junos OS versão 15.1X53-D210 para switches QFX5110 e QFX5200, o Junos OS versão 18.1R1 para switches QFX5210 e o Junos OS versão 18.2R1 para switches EX4600, se você souber que não há receptores multicast conectados a outros VTEPs no VXLAN que desejam tráfego para um grupo multicast específico, Você pode reduzir a carga de processamento na interface de loopback inserindo a seguinte declaração:

Nesse caso, nenhum tráfego será encaminhado para o grupo especificado, mas todos os outros tráfegos multicast serão encaminhados. Se você não quiser encaminhar nenhum tráfego multicast para outros VTEPs no VXLAN, insira a seguinte declaração:

Você pode configurar um roteador da Série MX, switch EX9200 ou switch QFX10000 para atuar como um VTEP e executar todas as seguintes funções:

• Atuar como um gateway de Camada 2 entre redes virtualizadas e não virtualizadas no mesmo data center ou entre data centers. Por exemplo, você pode usar um roteador da Série MX para conectar uma rede que usa VXLANs a uma que usa VLANs.

• Atua como um gateway de Camada 2 entre redes virtualizadas no mesmo data center ou em data centers diferentes e permite que máquinas virtuais se movam (VMotion) entre essas redes e data centers.

• Atue como um gateway de Camada 3 para rotear o tráfego entre diferentes VXLANs no mesmo data center.

• Atua como um gateway de Camada 3 para rotear o tráfego entre diferentes VXLANs em diferentes data centers por meio de uma WAN ou da Internet usando protocolos de roteamento padrão ou túneis de serviço de LAN privada virtual (VPLS).

Em um ambiente com um controlador (como um controlador VMware NSX ou Juniper Networks Contrail), você pode provisionar VXLANs em um dispositivo da Juniper Networks. Um controlador também fornece um plano de controle que os VTEPs usam para anunciar sua acessibilidade e aprender sobre a acessibilidade de outros VTEPs. Você também pode criar VXLANs manualmente em dispositivos da Juniper Networks em vez de usar um controlador. Se você usar essa abordagem, também deverá configurar o Protocol Independent Multicast (PIM) nos VTEPs para que eles possam criar túneis VXLAN entre si.

Você também deve configurar cada VTEP em um determinado VXLAN para ser membro do mesmo grupo multicast. (Se possível, você deve atribuir um endereço de grupo multicast diferente a cada VXLAN, embora isso não seja necessário. Vários VXLANs podem compartilhar o mesmo grupo multicast.) Os VTEPs podem então encaminhar solicitações ARP que recebem de seus hosts conectados para o grupo multicast. Os outros VTEPs no grupo desencapsulam as informações de VXLAN e (supondo que sejam membros do mesmo VXLAN) encaminham a solicitação ARP para seus hosts conectados. Quando o host de destino recebe a solicitação ARP, ele responde com seu endereço MAC e seu VTEP encaminha essa resposta ARP de volta para o VTEP de origem. Por meio desse processo, os VTEPs aprendem os endereços IP dos outros VTEPs no VXLAN e os endereços MAC dos hosts conectados aos outros VTEPs.

Os grupos e árvores multicast também são usados para encaminhar tráfego de broadcast, unicast desconhecido e multicast (BUM) entre VTEPs. Isso evita que o tráfego BUM seja inundado desnecessariamente fora do VXLAN.

As rotas de Camada 3 que formam túneis VXLAN usam balanceamento de carga por pacote por padrão, o que significa que o balanceamento de carga é implementado se houver caminhos ECMP para o VTEP remoto. Isso é diferente do comportamento normal de roteamento, no qual o balanceamento de carga por pacote não é usado por padrão. (O roteamento normal usa o balanceamento de carga por prefixo por padrão.)

O campo de porta de origem no cabeçalho UDP é usado para permitir o balanceamento de carga ECMP do tráfego VXLAN na rede de Camada 3. Esse campo é definido como um hash dos campos de pacote internos, o que resulta em uma variável que o ECMP pode usar para distinguir entre túneis (fluxos).

Nenhum dos outros campos que o ECMP baseado em fluxo normalmente usa é adequado para uso com VXLANs. Todos os túneis entre os mesmos dois VTEPs têm os mesmos endereços IP de origem e destino externos, e a porta de destino UDP é definida como a porta 4789 por definição. Portanto, nenhum desses campos fornece uma maneira suficiente para o ECMP diferenciar os fluxos.

Quando um switch QFX5120 tenta encapsular o tráfego em túneis em interfaces marcadas de Camada 3 voltadas para o núcleo ou interfaces IRB, o switch descarta os pacotes. Para evitar esse problema, você pode configurar um firewall simples baseado em filtro de dois termos na interface marcada de Camada 3 ou IRB.

Por exemplo:

O termo 1 corresponde e aceita o tráfego destinado ao switch QFX5210, que é identificado pelo endereço IP VTEP de origem (192.168.0.1/24) atribuído à interface de loopback do switch. Para o termo 1, observe que, ao especificar uma ação, você pode, alternativamente, contar o tráfego em vez de aceitá-lo.

O termo 2 corresponde e encaminha todos os outros tráfegos de dados para uma instância de roteamento (rota 1), que é configurada como interface et-0/0/3.

Neste exemplo, observe que a interface et-0/0/3 é referenciada pela instância de roteamento route1. Como resultado, você deve incluir o set firewall family inet filter vxlan100 term 2 then routing-instance route1 comando. Sem esse comando, o filtro de firewall não funcionará corretamente.

Nos switches QFX5100 e QFX5110, você pode usar os comandos and traceroute para solucionar problemas de ping fluxo de tráfego por meio de um túnel VXLAN incluindo o overlay parâmetro e várias opções. Você usa essas opções para forçar os ping pacotes ou traceroute a seguir o mesmo caminho que os pacotes de dados através do túnel VXLAN. Em outras palavras, você faz com que os pacotes underlay (ping e traceroute) sigam a mesma rota que os pacotes overlay (tráfego de dados). Consulte sobreposição de ping e sobreposição de traceroute para obter mais informações.

RFCs e rascunhos da Internet que definem padrões para VXLAN:

• RFC 7348, Rede de área local virtual eXtensível (VXLAN): Uma estrutura para sobrepor redes de camada 2 virtualizadas sobre redes de camada 3

• Internet draft draft-ietf-nvo3-vxlan-gpe, extensão de protocolo genérico para VXLAN