Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
NESTA PÁGINA
 

Suporte à EVPN da Juniper

Visão geral

O recurso multihoming Junos EVPN ESI permite que você conecte servidores finais diretamente a dispositivos leaf e ofereça conectividade redundante via multihoming. Esse recurso é suportado apenas em LAGs que abrangem dois dispositivos leaf na malha. A EVPN ESI também elimina a necessidade de "peer-link" e, portanto, facilita o design limpo de leaf-spine.

Os blueprints que usam o protocolo de controle de overlay MP-EBGP EVPN podem usar dispositivos Junos da Juniper. Racks com redundância de par de folhas podem implementar multihoming EVPN ESI.

O multihoming EVPN ESI ajuda a manter o serviço EVPN e o encaminhamento de tráfego de e para o site multi-homed no caso dos seguintes tipos de falhas de rede e evita um único ponto de falha conforme os cenários abaixo:

  • Falha de link de um dos dispositivos leaf ao dispositivo do servidor final
  • Falha de um dos dispositivos leaf
  • Convergência rápida no VTEP local, alterando as adjacências de next-hop e mantendo a acessibilidade do host final em vários VTEPs remotos

Terminologia e conceitos de multihoming EVPN

A terminologia e os conceitos a seguir são usados com o multihoming da EVPN:

EVI — Instância EVPN que se estende entre os dispositivos leaf que compõem a EVPN. Ele é representado pelo identificador de rede virtual (VNI). O EVI é mapeado para redes virtuais (VN) do tipo VXLAN.

MAC-VRF - Uma tabela de roteamento e encaminhamento virtual (VRF) para abrigar endereços MAC no dispositivo leaf VTEP (geralmente chamada de "tabela MAC"). Um diferenciador de rota exclusivo e um destino VRF são configurados por MAC-VRF.

Segmento Ethernet (ES) - Os links Ethernet abrangem de um host final a vários dispositivos leaf ToR e formam ES. Constitui um conjunto de links agrupados.

Identificador de segmento Ethernet (ESI) - Representa cada ES de forma exclusiva em toda a rede. O ESI só é suportado em LAGs que abrangem dois dispositivos leaf na malha.

A ESI ajuda com a redundância no nível do host final em um blueprint baseado em EVPN VXLAN. Os links Ethernet de cada folha ToR da Juniper conectada ao servidor são agrupados como uma interface Ethernet agregada. O LACP é habilitado para cada interface Ethernet agregada dos dispositivos da Juniper. As interfaces multi-homed no ES são identificadas usando o ESI.

A ESI tem certas restrições e requisitos, conforme listado abaixo:

  • Os dispositivos leaf ToR baseados em ESI não podem ter links peer L2/L3, pois o multihoming EVPN elimina os links peer usados pelo MLAG/vPC.
  • Uma ligação de duas interfaces físicas em direção a uma única folha não é suportada na implementação de ESI; certifique-se de que o servidor com LAG nesse tipo de rack abrange dois dispositivos leaf.
  • Os tipos de rack baseados em ESI e MLAG/vPC não podem ser misturados em um único blueprint.
  • Não há suporte para pontos de conectividade externa (ECPs) L2 com um tipo de rack baseado em ESI. Somente ECPs L3 são suportados.
  • Atribuição de VN por leaf - não há suporte para diferentes conjuntos de VLAN entre dispositivos leaf individuais para um canal de porta baseado em ESI.
  • Conectar um único servidor a uma única folha usando uma ligação de duas interfaces físicas não pode usar uma ESI.
  • O ESI é suportado apenas em LAGs (canais de porta) e não diretamente em interfaces físicas. Isso não tem impacto funcional, pois os canais de porta locais leaf para links multi-home são gerados automaticamente.
  • Há suporte apenas para o modo de redundância ativa-ativa de ESI. O modo de espera ativo não é suportado.
  • O modo de redundância ativo-ativo só é suportado para multihoming EVPN da Juniper, onde cada folha ToR da Juniper conectada a um ES tem permissão para encaminhar o tráfego de e para uma determinada VLAN.
  • Não há suporte para mais de dois dispositivos leaf em um segmento ESI que usam tipos de rack baseados em ESI.
  • A comutação de um tipo de rack ESI para MLAG ou vice-versa não é suportada nas operações de expansão de malha flexível (FFE).

Especificação de topologia

No exemplo abaixo, Leaf1 e Leaf2 fazem parte do mesmo ES, e Leaf3 é o switch que envia tráfego para o ES.

O multihoming EVPN da Juniper usa cinco tipos de rotas:

  • Tipo 1 - Rota Ethernet Auto-Discovery (EAD)
  • Tipo 2 - Rota de anúncio MAC
  • Tipo 3 - Rota multicast inclusiva
  • Tipo 4 - Rota de segmento Ethernet
  • Tipo 5 - Rota de prefixo IP

A BGP EVPN em execução em dispositivos Juniper usa:

  • Tipo 2 para anunciar informações de MAC e IP (host)
  • Tipo 3 para transportar informações de VTEP
  • Digite 5 para anunciar prefixos de IP em uma NLRI (Informações de Alcance de Camada de Rede).
Observação:

No Junos MAC/IP Tipo 2, o tipo de rota não contém VNI e RT para a parte IP da rota, ele é derivado do tipo de rota Tipo 5 que o acompanha.

As rotas do tipo 1 são usadas para descoberta automática (A-D) por ES para anunciar o modo multihoming EVPN. Os dispositivos leaf ToR remotos na rede EVPN usam a funcionalidade do tipo de rota EVPN Tipo 1 para aprender as rotas MAC EVPN Tipo 2 de outros dispositivos leaf. Nesse tipo de rota, ESI e Ethernet Tag ID são considerados parte do prefixo no NLRI. Após uma falha de enlace entre o ToR, o leaf e o servidor final, o VTEP retira as rotas de descoberta automática de Ethernet (Tipo 1) por ES. O valor da tag Ethernet multihoming EVPN da Juniper é definido como o ID de VLAN para os tipos de rota ES autodiscovery/ES.

Retirada em massa - Usado para convergência rápida durante cenários de falha de link entre dispositivos leaf para o servidor final usando rotas EAD/ES Tipo 1.

DF Election - Usado para evitar o encaminhamento dos loops e das duplicatas, pois apenas um único switch tem permissão para descapsular e encaminhar o tráfego para um determinado ES. A rota de segmento Ethernet é exportada e importada quando a ESI é configurada localmente no LAG. O NLRI tipo 4 é usado principalmente para eleições de encaminhador designado (DF) e para aplicar a filtragem de horizonte dividido.

Split Horizon - É usado para evitar o encaminhamento dos loops e das duplicatas para o tráfego Broadcast, Unknown-unicast e Multicast (BUM). Somente o tráfego BUM originado de um site remoto pode ser encaminhado para um site local.

Serviços de EVPN

Reconhecimento de VLAN EVPN

O Junos pode oferecer suporte a três serviços Ethernet: (1) baseado em VLAN, (2) pacote de VLAN ou (3) reconhecimento de VLAN. O design de referência do data center do Apstra aproveita nativamente o modelo VLAN-Aware. Com o serviço EVPN VLAN-Aware, cada VLAN é mapeada diretamente para sua própria instância EVPN (EVI). O mapeamento entre VLAN, Bridge Domain (BD) e instância EVPN (EVI) é N:1:1. Por exemplo, N VLANs são mapeadas em um único BD mapeado em um único EVI. Neste modelo, todos os IDs de VLAN compartilham o mesmo EVI, conforme mostrado abaixo:

Os serviços Ethernet com reconhecimento de VLAN no Junos têm um destino de rota separado para cada VLAN (que é a otimização interna da Juniper), portanto, cada VLAN tem um rótulo para imitar implementações baseadas em VLAN.

Da perspectiva do plano de controle, as rotas EVPN MAC/IP (Tipo 2) para serviços com reconhecimento de VLAN carregam o ID de VLAN no atributo de ID da tag Ethernet que é usado para desambiguar as rotas MAC recebidas.

Do ponto de vista do plano de dados - cada VLAN é marcada com seu próprio VNI que é usado durante a pesquisa de pacotes para colocá-lo no domínio de ponte (BD)/VLAN correto.

Criar rede EVPN

A criação de uma rede EVPN segue o mesmo fluxo de trabalho que para outras redes.

  1. Criar/instalar agentes de dispositivo offbox para todos os switches. (Agentes onbox não são suportados no Junos.)
  2. Confirme se o catálogo global inclui dispositivos lógicos (Design > Logical Devices) que atendem aos requisitos Juniper dispositivo; Crie-os, se necessário:
  3. Confirme se o catálogo global inclui mapas de interface (Design > Interface Maps) que mapeiam os dispositivos lógicos para os perfis de dispositivo corretos para os dispositivos Juniper; crie-os, se necessário.
  4. Crie um tipo de rack.
    • Para racks de folha única, especifique o protocolo de redundância Nenhum na seção Leaf .
    • Para racks de duas folhas
      • Especifique o protocolo de redundância ESI na seção Leaf .
      • Ao especificar o servidor final na seção Servidor , especifique o tipo de anexo como Dual-Homed para dispositivos leaf ToR baseados em ESI. As EVPNs que usam ESs têm uma opção de agregação de links. Selecione o modo LAG LACP (ativo)
  5. Crie um modelo baseado em rack.
  6. Crie um sistema genérico para um roteador externo.
  7. Crie pools de recursos para ASNs, endereços IP e VNIs.
  8. Crie um blueprint com base no modelo baseado em ESI e, em seguida, crie a topologia de rede baseada em EVPN para os dispositivos da Juniper atribuindo recursos, perfis e IDs de dispositivo.

Renderização de configuração

Design de referência

  • Underlay - A underlay na malha do data center é configurada na Camada 3 usando eBGP padrão nas interfaces físicas dos dispositivos da Juniper.
  • Overlay - A overlay é configurada como eBGP sobre lo0.0 o endereço. A EVPN VXLAN é usada como um protocolo de overlay. Todos os dispositivos ToR são habilitados com L2 VN. Cada uma dessas VNs L2 pode ter seu gateway padrão hospedado em dispositivos leaf ToR conectados. Para o tráfego entre VNs, o roteamento VXLAN é feito na malha usando VNIs L3 nos dispositivos leaf de borda, conforme o projeto padrão.
  • VTEPs VXLAN - Nos dispositivos leaf da Juniper, é renderizado um endereço IP que lo0.0 é usado como endereço VTEP. O endereço IP VTEP é usado para estabelecer o túnel VXLAN.
  • LAG multihoming EVPN — Valor exclusivo de ESI e IDs de sistema LACP são usados por LAG EVPN. Os links multi-homed são configurados com um ESI e um identificador de sistema LACP é especificado para cada link. O ESI é usado para identificar grupos LAG e prevenção de loops. Para oferecer suporte a Ativo/Ativo e multihoming para dispositivos leaf da Juniper, eles são configurados com o mesmo parâmetro LACP para um determinado ESI para que apareçam como um único sistema.

    Os endereços MAC da ESI são gerados automaticamente internamente. Você pode configurar o valor do byte mais significativo (msb) usado no MAC gerado. Uma nova API de fachada é adicionada para atualizar o valor do MSB. Um novo nó é adicionado ao modelo baseado em rack que contém o valor MAC MSB. O valor padrão desse byte é 2 e você pode alterá-lo para qualquer número par até 254. A atualização desse valor resulta na regeneração de todos os MACs de ESI no blueprint. Isso é exposto para atender a casos de uso de DCI em que as ESIs devem ser exclusivas em vários blueprints (malhas de IP).

  • L3VNIs - L3VNI é renderizado como uma zona de roteamento por VRF. A funcionalidade Multitenancy está disponível para garantir que as cargas de trabalho permaneçam logicamente separadas dentro de uma construção VN (overlay) usando a zona de roteamento.

  • Alvo de rota (RT) para VNIs L2/L3 - Gerado automaticamente para VNIs L2/L3 no formato VNI:1. Há 1 RT (em toda a malha) por MAC-VRF (ou seja, L3VNI). O valor deve ser o mesmo em todos os switches que participam de um EVI. Você pode encontrar o RT no blueprint navegando até Redes virtuais > virtuais > preparadas e clicando no nome do VN. RT está na seção de parâmetros.

  • Route Distinguisher (RD) para VNIs L2/L3 - Para o modelo baseado em Junos VLAN-Aware, o RD é por EVI (switch). Não há RD para cada VNI l2. RD existe apenas para VRF de zona de roteamento no formato {primary_loopback}:vlan_id.

  • Configuração de switch virtual - Na hierarquia switch-options para dispositivos Juniper, o parâmetro vtep-source-interface é renderizado e, em seguida, o endereço IP VTEP usado para estabelecer o túnel VXLAN é especificado. A acessibilidade à interface de loopback (por exemplo, lo0.0) é fornecida pela underlay. O RD aqui define o RD específico do EVI transportado pelas rotas Tipo 1, Tipo 2, Tipo 3. RD para as opções de switch global é fornecido no formato {loopback_id}:65534.

    O RT aqui define o RT global herdado pelas rotas EVPN. É usado por rotas Tipo 1. Um valor RT padrão é renderizado para it (100:100) para opções de switch globais em todos os switches.

  • MTU - Os valores de MTU que são renderizados para dispositivos da Juniper:

    • Portas L2: 9100
    • Portas L3: 9216
    • Interfaces de roteamento e ponte integradas (IRB): 9000

  • Gateway Anycast - O mesmo IP nas interfaces IRB de todos os dispositivos leaf é configurado e nenhum gateway virtual é definido. Cada interface IRB que participa do serviço L2 estendido tem o mesmo IP/MAC configurado conforme abaixo:

Nesse modelo, todas as interfaces IRB de gateway padrão em uma sub-rede overlay são configuradas com o mesmo endereço IP e endereço MAC. Um benefício desse modelo é que apenas um único endereço IP é necessário por sub-rede para o endereçamento da interface IRB do gateway padrão, o que simplifica a configuração do gateway em sistemas finais.

Aqui, o endereço MAC do IRB é gerado automaticamente.

Limitações

As seguintes limitações se aplicam às topologias multihoming EVPN para dispositivos Juniper:

  • Apenas o multi-homing bidirecional é suportado. Não há suporte para mais de dois dispositivos leaf da Juniper em um grupo multihomed.
  • Não há suporte para a Juniper EVPN com EVPN em outros fornecedores de rede no mesmo blueprint.
  • Sem suporte para malha de IP puro.
  • As malhas baseadas em IPv6 não oferecem suporte ao Junos.
  • No multihoming EVPN da Juniper, há suporte para pontos de conectividade externos (ECP) L3 em direção a sistemas genéricos; Não há suporte para o ECP L2.
  • O roteamento BGP de dispositivos leaf Junos para servidores de Camada 3 gerenciados pelo Apstra não é suportado.

Veja também