NESTA PÁGINA
 

Funcionalidade suportada por EVPN sobre VXLAN

A seguinte funcionalidade é suportada para o encapsulamento do plano de dados EVPN sobre VXLAN:

Encapsulamento VXLAN

A EVPN oferece suporte ao tipo de encapsulamento de plano de dados VXLAN na mesma instância EVPN. Para oferecer suporte ao tipo de encapsulamento VXLAN, todos os dispositivos EVPN PE especificam o tipo de túnel como VXLAN na comunidade estendida de encapsulamento BGP. O PE de entrada determina quais tipos de encapsulamento usar com base em sua própria capacidade de encapsulamento e aquela anunciada por seu dispositivo PE remoto EVPN.

Quando a EVPN é usada como solução overlay para a rede IP underlay com encapsulamento VXLAN, o pacote de dados é encapsulado com um cabeçalho VXLAN no dispositivo PE de entrada, e o pacote de dados é desencapsulado do cabeçalho VXLAN no dispositivo PE de saída. A Figura 1 mostra o formato do pacote quando um pacote é encaminhado no núcleo através da rede IP underlay com encapsulamento VXLAN:

Figura 1: Rede IP underlay com encapsulamento VXLAN encapsulated packet structure showing outer Ethernet, IP, UDP headers, VXLAN header, and original Ethernet frame. VXLAN

Se a rede underlay usar o protocolo IPv4 e o endereçamento IPv4, o cabeçalho IP externo no pacote VXLAN será um cabeçalho IPv4. Todas as plataformas que suportam EVPN-VXLAN funcionam com uma rede underlay IPv4.

Em algumas plataformas, você pode configurar a underlay para usar o protocolo IPv6 e o endereçamento IPv6. Nesses casos, o cabeçalho IP externo no pacote VXLAN é um cabeçalho IPv6 e você configura o endereço de origem VTEP como um endereço IPv6. Consulte EVPN-VXLAN com um IPv6 Underlay para obter detalhes sobre como usar um IPv6 Underlay.

Rotas e atributos de BGP de EVPN

As rotas e atributos BGP da EVPN oferecem suporte ao encapsulamento do plano de dados EVPN-over-VXLAN e são afetados da seguinte forma:

  • Ao anexar o atributo de comunidade estendida de encapsulamento BGP com o tipo de encapsulamento de túnel VXLAN nas rotas MAC da EVPN, o dispositivo PE de saída anuncia a rota multicast inclusiva EVPN e a EVPN por descoberta automática de rota EVI.

  • Os campos de tag Ethernet para todas as rotas BGP da EVPN são definidos como zero para oferecer suporte apenas ao modo baseado em identificador de rede VXLAN (VNI).

  • O VNI, também conhecido como campo VNI na sobreposição EVPN, é colocado nos campos MPLS para a rota MAC EVPN, a rota multicast inclusiva EVPN e por rota de descoberta automática de instância EVPN.

  • O campo de rótulo do identificador de segmento Ethernet é definido como zero para a rota de descoberta automática de EVPN por segmento Ethernet porque não existe nenhum rótulo de identificador de segmento Ethernet para o tipo de encapsulamento VXLAN suportado.

  • Todas as rotas EVPN correspondentes do dispositivo PE remoto são resolvidas pela tabela inet.0 ou :vxlan.inet.0 em vez da tabela inet.3 para IPv4. Quando você usa uma underlay IPv6 para tunelamento EVPN-VXLAN, o mesmo vale para as tabelas inet6.0 e :vxlan.inet6.0.

Procedimento de multihoming EVPN

Você pode fazer multihome de um servidor bare-metal (BMS) para um par de switches top-of-rack (TOR) da Juniper Networks, por exemplo, switches QFX5100, por meio de uma interface de grupo de agregação de enlaces (LAG) de Camada 2. Por causa da interface LAG, apenas uma cópia do tráfego BUM é encaminhada de um BMS para o roteador de núcleo. Para evitar um loop de Camada 2 e inundação do tráfego BUM de volta para o mesmo segmento Ethernet ao qual o BMS multihomed está conectado, o tráfego BUM aplica a regra de filtragem multihomed active-active split-horizon. Para oferecer suporte total ao recurso de modo ativo-ativo multihomed EVPN, o switch TOR da Juniper Networks também anuncia a rota de aliasing EVPN para outros dispositivos EVPN PE.

A falta de suporte ao rótulo MPLS para EVPN sobre IP com encapsulamento de plano de dados VXLAN afeta as seguintes funções do modo ativo-ativo multihomed da EVPN:

Observação:

A EVPN sobre VXLAN não oferece suporte ao modo de operação de espera ativa. Você pode configurar apenas o modo ativo-ativo usando a all-active opção na configuração da interface ESI. Não há suporte para segmentos Ethernet de homing único com EVPN usando encapsulamento VXLAN com a single-active opção.

A partir do Junos OS Release 22.2R1, a EVPN adiciona suporte a redundância totalmente ativa, aliasing e retirada de MAC em massa, incluindo a integração do plano de dados VXLAN, para fornecer conectividade resiliente entre data centers às suas tecnologias de Interconexão de data center (DCI) estabelecidas. Esse novo suporte cria uma solução DCI de ponta a ponta integrando o multicast EVPN com o plano de dados VXLAN.

Em uma topologia ativa-ativa, ambos os links são usados para balancear a carga do tráfego. O tráfego unicast originado do domínio EVPN-MPLS é balanceado para ambos os gateways e é encaminhado através do túnel VXLAN para o roteador final VXLAN remoto. Pacotes com balanceamento de carga podem vir de qualquer um dos gateways e causar um problema de flip-flop MAC no roteador final VXLAN. Você pode superar esse problema de flip-flop MAC configurando um endereço IP anycast como um endereço secundário nas interfaces de loopback dos gateways. Quando você define o endereço anycast como vxlan-source-ip, o túnel VXLAN será criado para o endereço anycast e o MAC será aprendido a partir do endereço anycast do VTEP.

Use as instruções a seguir para definir a redundância ativa-ativa no nível de ESI e um endereço anycast na interface lo0. Adicione um endereço secundário com um IP anycast à interface lo0 e inclua-o como a interface vxlan-source-ip VTEP na instância de roteamento e no secondary-vtep-address PIM sob protocolos.

Viés local e regra de filtragem de horizonte dividido

Devido à falta do rótulo MPLS, a regra de filtragem de horizonte dividido para o segmento Ethernet multihomed é modificada e baseada no endereço IP do dispositivo EVPN PE em vez do rótulo do segmento Ethernet MPLS. Para o tráfego proveniente da interface de acesso, qualquer encaminhamento de tráfego para o segmento Ethernet multihomed é baseado no viés local para EVPN com encapsulamento de plano de dados VXLAN. Cada dispositivo EVPN PE rastreia o endereço IP de seu dispositivo EVPN PE multihomed peer para o qual compartilha o mesmo segmento Ethernet. Esse rastreamento fornece o endereço IP VTEP de origem (no cabeçalho IP externo) para cada pacote VXLAN recebido do outro dispositivo EVPN PE. A regra de filtragem de horizonte dividido é aplicada em dispositivos PE de entrada e saída para tráfego de vários destinos:

  • PE de entrada — responsável por encaminhar pacotes de vários destinos provenientes de qualquer uma de suas interfaces de acesso diretamente conectadas aos segmentos Ethernet multihomed associados restantes, independentemente do status de eleição do encaminhador designado (DF) do dispositivo PE de entrada do assunto.

  • PE de saída — não permite o encaminhamento de pacotes de vários destinos para o mesmo segmento Ethernet multihomed com o qual um PE de saída compartilha com seu dispositivo PE de entrada, independentemente do status de eleição DF do dispositivo PE de saída do assunto.

Aliasing

Quando você conecta um BMS a um par de switches TOR da Juniper Networks por meio de um pacote de interface LAG, apenas um dos switches pode aprender o endereço MAC local. Para oferecer suporte ao balanceamento de carga do tráfego unicast conhecido vindo do VXLAN para o BMS entre os switches, o dispositivo EVPN PE no switch deve anunciar EVPN por rota de descoberta automática de instância EVPN. Esse anúncio sinaliza aos dispositivos PE EVPN remotos que o MAC aprendeu com o segmento Ethernet multihomed de seu dispositivo PE multihomed peer também é alcançável. Para encapsulamento VXLAN, não há alteração no procedimento EVPN ao fornecer a função de aliasing EVPN.

Encaminhamento de próximo salto

O daemon de aprendizado de endereço de Camada 2 (l2ald) cria o próximo salto composto de encapsulamento VXLAN na entrada e o próximo salto composto de desencapsulamento VXLAN na saída. O next-hop composto de encapsulamento VXLAN encaminha o tráfego unicast de Camada 2 para o dispositivo PE remoto com o encapsulamento VXLAN. Se vários caminhos estiverem disponíveis para alcançar um MAC remoto (como no caso ativo-ativo da EVPN multihomed), o daemon de protocolo de roteamento (rpd) informa o l2ald de todos os endereços IP VTEP remotos associados ao MAC remoto. O l2ald é responsável por construir um próximo salto multipath (ECMP) de custo igual para o MAC remoto. O next-hop composto de desencapsulamento de VXLAN desencapsula o cabeçalho do túnel de VXLAN na saída e encaminha o tráfego para o BMS.

Para tráfego unicast conhecido:

  • Na entrada, o rpd não precisa adicionar uma rota de rótulo na tabela mpls.0.

  • Na saída, o rpd não precisa adicionar uma rota de rótulo para apontar para a tabela next-hop na tabela mpls.0.

Prevenção de loop IRB de sobreposição

As rotas de túnel VXLAN são resolvidas na underlay. A sobreposição usa a resolução de rota underlay para alcançabilidade. A underlay, em determinadas condições, pode usar a sobreposição para alcançabilidade, o que pode levar a loops de roteamento.

Considere um cenário em que você configura o VXLAN e um IRB na mesma instância de roteamento, enquanto também configura o IRB no protocolo OSPF ou por meio de roteamento estático. Você pode configurar o IRB explicitamente usando set protocols ospf area # interface irb a opção ou usando a opção set protocols ospf area # interface all"interface all" . Qualquer uma das abordagens permite que a underlay use a sobreposição para resolução de rota de túnel.

Impeça que a underlay resolva rotas usando a sobreposição configurando a overlay-vxlan-interfaces declaração. Em seguida, configure uma política de roteamento, conforme mostrado aqui:

Examine a tabela :vxlan.inet.0 para verificar se o sistema bloqueia as rotas IRB. Primeiro, examine um cenário em que a underlay pode usar rotas de sobreposição. A rota ativa usa o IRB:

Essa opção é compatível com IPv4 e IPv6. Aqui está a tabela :vxlan.inet6.0 com a rota IRB:

Observe a mesma saída quando a overlay-vxlan-interfaces instrução impedir que a rota IRB seja adicionada à tabela. As tabelas IPv4 e IPv6 são mostradas aqui:

Método de aprendizagem MAC do plano de controle

Uma característica única da EVPN é que o aprendizado de endereço MAC entre dispositivos PE ocorre no plano de controle. O roteador PE local detecta um novo endereço MAC de um dispositivo CE e, em seguida, usando o MP-BGP, anuncia o endereço para todos os dispositivos PE remotos. Esse método difere das soluções VPN de Camada 2 existentes, como VPLS, que aprendem inundando unicast desconhecidos no plano de dados. Esse método de aprendizado MAC de plano de controle é um componente crucial dos recursos e benefícios que a EVPN oferece. Como o aprendizado MAC é tratado no plano de controle, a EVPN tem a flexibilidade de oferecer suporte a diferentes tecnologias de encapsulamento de plano de dados entre dispositivos PE. Essa flexibilidade é importante porque nem toda rede de backbone pode estar executando MPLS, especialmente em redes corporativas.

Para o aprendizado MAC remoto do plano de controle, como o l2ald cria o next-hop composto de encapsulamento VXLAN e o next-hop composto de desencapsulamento VXLAN, o rpd não cria mais um next-hop indireto usado na tabela de encaminhamento MAC. O rpd depende do mecanismo existente para informar o l2ald dos endereços MAC remotos aprendidos com o plano de controle. Em vez de informar o l2ald sobre o ID da VLAN e o índice indireto de next-hop usado pelo MAC remoto na tabela MAC FIB, o rpd informa o l2ald sobre o endereço IP VTEP remoto e o identificador de rede VXLAN. A rota remota aprendida do MAC do plano de controle aponta para o next-hop composto de encapsulamento VXLAN ou um next-hop ECMP criado pelo l2ald na tabela de encaminhamento MAC.

Para EVPN multihomed ativo-ativo, um par de endereços IP VTEP remotos está associado ao endereço MAC remoto. Os endereços IP VTEP remotos são obtidos da rota MAC recebida do dispositivo PE remoto ou da rota de aliasing do dispositivo PE remoto. Quando um dispositivo PE remoto retira uma rota MAC ou a rota de aliasing para o segmento Ethernet de onde o MAC aprendeu, o rpd alerta o l2ald sobre a mudança para o par de endereços IP VTEP remotos de acordo. Como resultado, o l2ald atualiza o próximo salto uni-list criado para este MAC. Quando as rotas MAC remotas e sua rota de aliasing associada são retiradas ou não resolvidas, o rpd informa o l2ald sobre a exclusão desse MAC remoto e o l2ald retira esse MAC da tabela de encaminhamento MAC.

Contrail vRouters e a tabela L3-VRF

O software de virtualização Contrail cria redes virtuais (VNs) associadas a rotas em uma tabela de roteamento e encaminhamento virtual de Camada 3 (L3-VRF).

A seguir estão as rotas associadas:

Rotas de sub-rede para uma interface IRB

Para cada par de tabelas MAC-(roteamento e encaminhamento virtual) VRF e L3-VRF criadas para uma rede virtual em um roteador da Série MX, uma interface IRB correspondente é associada ao par de tabelas MAC-VRF e L3-VRF. A tabela L3-VRF no roteador da Série MX tem a rota de sub-rede da interface IRB associada às suas redes virtuais locais, bem como todas as rotas de sub-rede das interfaces IRB associadas a outras redes virtuais dentro de um data center fornecido pelo recurso de vazamento de roteamento do Junos OS. Os roteadores da Série MX anunciam essas rotas de sub-rede através do MP-BGP para os nós de controle do Contrail. Como resultado, a tabela L3-VRF no Contrail vRouter contém o mesmo conjunto de rotas de sub-rede para as interfaces IRB em seu IP FIB, e as rotas de sub-rede apontam seus próximos saltos para os roteadores da Série MX.

Rotas de host de máquina virtual

Os vRouters do Contrail oferecem suporte a ARP de proxy e anunciam o endereço IP com a rota MAC EVPN para sua máquina virtual (VM). Para roteadores Contrail vRouters e roteadores da Série MX, a tabela L3-VRF para uma rede virtual contém todas as rotas de host VM para essas VMs que residem na mesma rede virtual, bem como rotas em todas as outras redes virtuais. o tráfego de rede intravirtual e de rede intervirtual entre as VMs é encaminhado diretamente na Camada 3 entre os vRouters Contrail.

Rotas de host de servidor bare-metal

Um switch TOR da Juniper Networks, por exemplo, um switch QFX5100, não anuncia o endereço IP com a rota MAC EVPN para o servidor bare-metal (BMS) ao qual ele está conectado. Como resultado do anúncio de rota MAC EVPN do switch, nenhuma rota de host BMS é instalada na tabela L3-VRF em roteadores Contrail vRouters e da Série MX. No entanto, as rotas ARP para os BMSs são instaladas no kernel do roteador da Série MX se o roteador da Série MX receber respostas ARP dos BMSs.

Eleição do encaminhador designado

Para fornecer melhor balanceamento de carga e topologia mais flexível, a escolha do encaminhador designado é determinada selecionando o ID mínimo de VLAN ou ID de rede VXLAN para cada segmento Ethernet em vez de selecionar com base na instância EVPN. A Figura 2 mostra uma amostra designada de topologia de eleição de encaminhador.

Figura 2: Topologia Network topology with CE devices CE1 and CE2 linked to PE devices PE1, PE2, PE3. Each PE has VLANs configured: PE1 with 100, 101, 201; PE2 with 100, 101; PE3 with 201. CE1 and CE2 use ESIs ES1 and ES2 for redundancy and load balancing. Orange lines show designated links for traffic flow. de eleição do encaminhador designado

O dispositivo CE (CE1) tem um valor de identificador de segmento Ethernet configurado igual a ES1 e está conectado a dispositivos PE1 e PE2, com VLANs 100 e 101 configuradas. O roteador PE1 é eleito como o encaminhador designado para as duas VLANs.

O dispositivo CE (CE2) tem um valor de identificador de segmento Ethernet configurado igual a ES2 e está conectado a dispositivos PE1 e PE3, com VLAN 201 configurada. O roteador PE3 é eleito como o encaminhador designado para esta VLAN.

O ID da marca Ethernet pode ser um dos seguintes:

  • ID da VLAN (para EVPN-MPLS)

  • ID de rede VXLAN (para EVPN-VXLAN)

Documentação relacionada