Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
NESTA PÁGINA
 

Exemplo: configure uma malha de ponte com roteamento central EVPN-VXLAN usando roteadores MX como spines

Este exemplo mostra como configurar EVPN e VXLAN em uma malha DE IP para oferecer suporte ao encaminhamento ideal de quadros Ethernet, fornecer segmentação de rede em ampla escala, permitir o aprendizado MAC baseado em plano de controle e muitas outras vantagens. Este exemplo é baseado em uma arquitetura EVPN de ponte (CRB) roteada centralmente em uma malha Clos de 5 estágios.

Nas interfaces IRB de arquitetura crb oferecem conectividade de Camada 3 a servidores e VMS que pertencem a diferentes VLANs e redes. Essas interfaces IRB servem como o gateway padrão para tráfego entre VLAN dentro de uma malha, e também para destinos que são remotos para a malha, por exemplo, no caso da Interconexão de Data Center (DCI). Em um design crb você define as interfaces IRB apenas nos dispositivos spine. Tal design é, portanto, referido como sendo roteado centralmente, pois todo roteamento ocorre nas spines.

Para um exemplo de um projeto de ponte com roteamento de borda (ERB), veja Exemplo: Configuração de uma malha de ponte com roteamento de borda EVPN-VXLAN com um gateway Anycast

Para obter informações de fundo sobre a tecnologia EVPN-VXLAN e arquiteturas suportadas, veja EVPN Primer.

Requisitos

O exemplo original usava os seguintes componentes de hardware e software:

  • Dois roteadores da Série MX da Juniper Networks atuam como gateways IP para o overlay da EVPN

  • Quatro switches QFX5100 da Juniper Networks. Dois desses switches atuam como dispositivos PE na topologia EVPN, e os outros dois switches agem como transporte ip puro para a underlay.

  • Junos OS Release 16.1 ou posterior.

    • Atualizado e validado novamente usando o Junos OS Release 21.3R1.9

  • Começando pelo Junos OS Release 17.3R1, a EVPN-VXLAN também tem suporte para switches EX9200. Anteriormente, apenas o encapsulamento MPLS era suportado. Neste exemplo, o switch EX9200 funcionaria como um gateway IP para overlay EVPN. Existem algumas diferenças de configuração entre os roteadores da Série MX e os switches EX9200. A seção de configuração posteriormente neste tópico tem mais informações sobre a configuração específica de um EX9200.

Visão geral

As VPNs de ethernet (EVPNs) permitem que você conecte grupos de sites de clientes dispersos usando pontes virtuais de Camada 2 e LANs virtuais extensíveis (VXLANs) permitem que você estique a conexão de Camada 2 em uma rede de Camada 3 intervindo, ao mesmo tempo em que fornece segmentação de rede como uma VLAN, mas sem a limitação de escala das VLANs tradicionais. A EVPN com encapsulamento VXLAN lida com a conectividade de Camada 2 na escala exigida pelos provedores de serviços de nuvem e substitui protocolos de limitação como STP, liberando sua rede de Camada 3 para usar protocolos de roteamento mais robustos.

Esta configuração de exemplo mostra como configurar a EVPN com o encapsulamento de VXLAN. Neste exemplo, os roteadores da Série MX são chamados de Core-1 e Core-2. Os switches QFX5100 são chamados leaf-1, Leaf-2, Spine-1 e Spine-2. Os roteadores de núcleo atuam como gateways IP para overlay EVPN, os switches leaf atuam como dispositivos PE na topologia EVPN, e os switches spine agem como transporte ip puro para a underlay (também conhecido como "lean spine").

Topologia

Em nossa topologia de amostra, demonstramos o acesso ao servidor usando interfaces não registradas e com tronco (taged). Uma interface de tronco usa tags VLAN explícitas. Tanto o servidor A quanto o C estão configurados para o tronco, enquanto o servidor B usa uma interface de acesso não registrada para ambas as folhas.

Configuração

Configuração rápida da CLI

Para configurar este exemplo rapidamente, copie os seguintes comandos, cole-os em um arquivo de texto, remova qualquer quebra de linha, altere os detalhes necessários para combinar com a configuração da sua rede e, em seguida, copie e cole os comandos no CLI no nível de [edit] hierarquia.

Leaf-1

Leaf-2

Spine-1

Spine-2

Núcleo 1

Núcleo 2

Configuração do EX9200

Nos switches EX9200, a vlans declaração é usada em vez de bridge-domains, e a l3-interface declaração é usada em vez de routing-interface.

O exemplo a seguir mostra como configurar essas declarações. Todas as outras configurações mostradas para roteadores da Série MX neste exemplo também se aplicam aos switches EX9200.

Nota:

Neste exemplo, onde quer bridge-domains que ou routing-interface as declarações sejam usadas, para configurar switches EX9200, usar vlans e l3-interface , em vez disso.

Configuração do Leaf-1

Procedimento passo a passo

O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar na CLI, consulte Usando o Editor de CLI no modo de configuração no Guia do usuário da CLI.

Nota:

As etapas para configurar o Leaf-2 são semelhantes ao Leaf-1 e, portanto, só mostraremos os procedimentos passo a passo para o Leaf-1.

Para configurar o Leaf-1:

  1. Definir o nome de host do sistema.

  2. Configure opções de roteamento. A load-balance política de exportação está configurada na próxima etapa.

  3. Configure a política de balanceamento de carga.

  4. Configure o EBGP underlay para os dispositivos spine. A lo0 política de exportação está configurada na próxima etapa.

  5. Configure uma política para anunciar o endereço de loopback no underlay. Neste exemplo, você escreve uma política portátil que é agnóstica de endereço de loopback, combinando apenas rotas diretas com um comprimento de prefixo de /32. O resultado é uma política que combina com qualquer endereço de loopback e é reutilizável em todos os dispositivos da topologia.

  6. Configure opções de switch A interface de endpoint de túnel virtual é lo0.0, que deve ser acessível por meio do protocolo de roteamento underlay. O diferencial de rota deve ser único em todos os switches da rede para garantir que todos os anúncios de rota dentro do overlay MP-BGP sejam únicos globalmente. A meta da tabela VRF no switch da Série QFX é, no mínimo, a comunidade que o switch envia anexa a todas as rotas de ESI (Tipo-1). A vrf-import vrf-imp declaração define a lista da comunidade-alvo, que é importada para a instância a default-switch.evpn.0 bgp.evpn.0 partir da tabela.

  7. Configure a política de importação da tabela VRF.

  8. Configure as comunidades relacionadas.

  9. Configure a lista de identificadores de rede virtual (VNI) estendidos para estabelecer as VNIs que você deseja fazer parte do domínio EVPN. Você também configura a replicação de entrada; na replicação de entrada EVPN-VXLAN é usada para lidar com multicast sem exigir uma subcamada multicast capaz. Diferentes alvos de rota são especificados para cada instância de identificador de rede VXLAN em vni-routing-options.

  10. Mapeie IDs VLAN localmente significativos para identificadores de rede VXLAN globalmente significativos.

  11. Configure as sessões de overlay de IBGP capazes de EVPN.

    Nota:

    Algumas malhas de IP usam um overlay EVPN-VXLAN baseado em EBGP. Para um exemplo de uma malha de IP que usa o EBGP tanto para underlay quanto para overlay, veja Exemplo: configurando uma malha de ponte com roteamento de borda EVPN-VXLAN com um gateway Anycast. Observe que a escolha do EBGP vs. IBGP para overlay não afeta a arquitetura da malha. Os designs de ponte com roteamento de borda (ERB) e CRB oferecem suporte a qualquer tipo de overlay.

  12. Configure as interfaces de malha.

  13. Configure as interfaces de acesso. Observe novamente que demonstramos uma mistura de interfaces de acesso e tronco para o anexo do servidor.

  14. Configure a interface LAG habilitada para LACP. O valor da ESI é globalmente único em todo o domínio EVPN. A all-active declaração de configuração garante que todos os roteadores PE aos quais este locatário multihomed está conectado podem encaminhar o tráfego do dispositivo CE, de modo que todos os links CE sejam usados ativamente.

  15. Configure o endereço da interface de loopback.

Configuração do Spine-1

Procedimento passo a passo

O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar na CLI, consulte Usando o Editor de CLI no modo de configuração no Guia do usuário da CLI.

Nota:

As etapas para configurar o Spine-2 são semelhantes à Spine-1 e, portanto, só mostraremos os procedimentos passo a passo para o Spine-1.

Para configurar o Spine-1:

  1. Definir o nome de host do sistema.

  2. Configure as opções de roteamento.

  3. Configure uma política de balanceamento de carga.

  4. Configure a underlay do EBGP com peering para dispositivos leaf e núcleo. A lo0 política que anuncia o endereço lo0 é aplicada nesta etapa; a configuração da política em si é mostrada na próxima etapa.

  5. Configure uma política nomeada lo0 para anunciar /32 rotas. A política é igual ao endereço de loopback, sem especificar nenhum IP específico. Dessa forma, a mesma política é reutilizável em qualquer dispositivo de malha.

Configuração do Núcleo 1

Procedimento passo a passo

O exemplo a seguir exige que você navegue por vários níveis na hierarquia de configuração. Para obter informações sobre como navegar na CLI, consulte Usando o Editor de CLI no modo de configuração no Guia do usuário da CLI.

Nota:

As etapas para configurar o Core-2 são semelhantes ao Core-1 e, portanto, só mostraremos os procedimentos passo a passo para o Core-1.

Para configurar o Core-1:

  1. Definir o nome de host do sistema.

  2. Configure as opções de roteamento. A load-balance política é aplicada durante esta etapa. Você cria a política na próxima etapa

  3. Configure uma política de balanceamento de carga nomeada load-balance.

  4. Configure o peering underlay do BGP. A lo0 política que anuncia o endereço de loopback é aplicada durante esta etapa. Você configura essa política na próxima etapa.

  5. Configure uma política nomeada lo0 para anunciar rotas de loopback.

  6. Uma grande parte da configuração do Core-1 ocorre na [routing-instance] hierarquia. Configure os roteadores virtuais e configure uma política única de importação de tabela VRF para cada switch virtual.

  7. Configure a política para cada instância de roteamento.

  8. Configure as comunidades. Certifique-se de que a comm-leaf política aceite rotas marcadas com o alvo 65000:1. Isso garante que todos os switches virtuais importem as rotas ESI tipo 1 de todos os leafs.

  9. Configure as interfaces IRB. Cada IRB tem um endereço de gateway virtual, que é um endereço MAC compartilhado e endereço IP em Core-1 e Core-2.

  10. Configure as sessões de overlay do IBGP em direção ao Leaf-1 e Leaf-2. Incluímos um peering entre os dispositivos Core para o compartilhamento de rotas entre dispositivos Core.

Verificação

Verificando a acessibilidade mac a um dispositivo CE de casa única (Leaf-1)

Propósito

Verifique a capacidade de alcance do MAC para Tenant_A. Este usuário é um único lar do Leaf-1. Primeiro, verifique se o endereço MAC é aprendido localmente no Leaf-1. O Leaf-1 gera a rota EVPN tipo 2 somente depois de aprender o endereço MAC.

Ação

Verifique se o endereço MAC é aprendido localmente no Leaf-1.

Significado

A saída mostra que o MAC 56:04:15:00:bb:02 é aprendido com sucesso com o dispositivo Tenant_A CE, que é o Servidor A na interface xe-0/3.0.

Verificando a acessibilidade mac a um dispositivo CE de casa única (Tipo 2)

Propósito

Verifique a acessibilidade mac a um dispositivo CE de casa única (Tipo 2)

Ação

Verifique a geração da rota Tipo 2 para o Core-1.

Significado

A saída mostra que o MAC e o MAC/IP estão sendo anunciados.

No Core-1, a rota EVPN Type-2 é recebida bgp.evpn.0.

A saída mostra as rotas Tipo 2 para 56:04:15:00:bb:02. O diferencial de rota é do Leaf-1 e está definido para 10.1.255.111:1.

Verificação de rotas importadas

Propósito

Verifique se a rota EVPN Tipo 2 é importada.

Ação

No Core-1, verifique se as rotas EVPN Type-2 são importadas com sucesso da bgp.evpn.0 tabela para a instância de switch EVPN.

Significado

A saída mostra que, no switch virtual da Tenant_A, a rota EVPN Type-2 é anunciada com o alvo correto, target:1:101. Use a opção extensive para revisar a rota Tipo 2 com mais detalhes.

A saída mostra que o Core-1 recebe duas cópias. O primeiro é o anúncio da Leaf-1 (Fonte: 10.1.255.111). O segundo é o anúncio do Core-2 (Fonte: 10.1.255.2).

Verificando a cópia do daemon de aprendizado de endereço da Camada 2

Propósito

Verifique a cópia do daemon de aprendizado de endereço da Camada 2.

Ação

Verifique a cópia do daemon de aprendizado de endereço de Camada 2 inserindo o show bridge-mac table comando.

Significado

A saída mostra que 56:04:15:00:bb:02 é acessível através da interface lógica vtep.32771 para Leaf-1.

Nota:

Nos switches EX9200, o show ethernet-switching table-instance instance-name comando corresponde ao show bridge mac-table instance instance-name comando usado aqui para roteadores da Série MX

Verificando a tabela de encaminhamento no nível do Kernel

Propósito

Verifique a tabela de encaminhamento no nível do kernel, o identificador de próximo salto e a tabela e o hardware MAC de Camada 2.

Ação

Consulte a tabela de encaminhamento no nível do kernel, correlacione o identificador de próximo salto do índice com o identificador de rede virtual correto e analise a tabela MAC e o hardware da Camada 2.

Significado

O MAC da Tenant_A, 56:04:15:00:bb:02, é acessível pelo índice 687.

Correlacione o índice 687 (NH-Id) com o identificador de rede virtual 101 e o VTEP-ID remoto de 10,1.255,111.

Nota:

Nos switches EX9200, o show ethernet-switching comando corresponde ao show l2-learning show de comando aqui para roteadores da Série MX.

Verificando a acessibilidade mac a um dispositivo CE multihomed

Propósito

Verifique a acessibilidade mac do dispositivo Tenant_B CE multihomed no Leaf-1 e Leaf-2.

Ação

Verifique se o Leaf-1 e o Leaf-2 estão anunciando a acessibilidade do Tipo 1 e Do Tipo 2 em direção ao dispositivo CE multihomed.

Significado

A saída mostra que 2c:6b:f5:43:12:c0 representa o MAC do Tenant_B anexado ao Leaf-1 e Leaf-2.

Verificando a EVPN, o daemon de aprendizado de endereços de Camada 2 e as tabelas de encaminhamento de kernel para dispositivos multihomed CE

Propósito

Verifique a tabela de EVPN do locatário B e a tabela de daemon de aprendizado de endereços de Camada 2 do Core-1 e a tabela de encaminhamento do kernel.

Ação

No Core-1, exibir a tabela EVPN do Locatário B.

Exibir a tabela de daemon de aprendizado de endereços de Camada 1 do Core-1.

Nota:

Nos switches EX9200, o show ethernet-switching table-instance instance-name comando corresponde ao show bridge mac-table instance instance-name show de comando aqui para roteadores da Série MX

Exibir a tabela de encaminhamento do kernel do Core-1.

Significado

Para o dispositivo Tenant_B CE, quatro rotas diferentes estão listadas para ESI 00:01:01:01:01:01:01:01:01:01:01:

  • 1:10.1.255.111:0:010101010101010101:FFFF:FFFF/192 AD/ESI

    Essa rota A-D Tipo-1 EVPN por segmento de Ethernet teve origem no Leaf-1. O diferencial de rota é obtido de nível routing-optionsglobal. O Core-1 recebe essa rota Tipo 1, originária do Leaf-1, tanto do Leaf-1 quanto do Leaf-2.

  • 1:10.1.255.111:1:010101010101010101:0/192 AD/EVI

    Esta é a rota EVPN por EVI A-D Tipo-1. O diferencial de rota é obtido da instância de roteamento, ou no caso de QFX5100, o switch-options. O Core-1 recebe essa rota Tipo 1, originária do Leaf-1, tanto do Leaf-1 quanto do Leaf-2.

  • 1:10.1.255.112:0:010101010101010101:FFFF:FFFF/192 AD/ESI

    Esta é a rota EVPN por segmento de Ethernet A-D Tipo-1 originada do Leaf-2. O diferencial de rota é obtido de nível routing-optionsglobal. O Core-1 recebe essa rota Tipo 1, originária do Leaf-2, tanto do Leaf-2 quanto do Leaf-1.

  • 1:10.1.255.112:1:010101010101010101:0/192 AD/EVI

    Esta é a rota EVPN por EVI A-D Tipo-1. O diferencial de rota é obtido da instância de roteamento, ou no caso de QFX5100, switch-options. O Core-1 recebe essa rota Tipo 1, originária do Leaf-2, tanto do Leaf-2 quanto do Leaf-1.

As rotas Tipo 2 para o MAC físico e um virtual associados ao Tenant_B dispositivo CE multihomed são originadas como esperado.

A partir da saída ainda não podemos determinar quais VTEPs são usados para encaminhamento à ESI 00:01:01:01:01:01:01:01:01:01:01. Para determinar o VTEPS, exibir os ESIs de endpoint do túnel VXLAN.

Nota:

Nos switches EX9200, o show ethernet-switching comando corresponde ao show l2-learning show de comando aqui para roteadores da Série MX.

A saída mostra balanceamento ativo de carga nas interfaces VTEP para Leaf-1 e Leaf-2 para os endereços MAC neste ESI, que valida a configuração totalmente ativa no Leaf-1 e Leaf-2.

Documentação relacionada