Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
NESTA PÁGINA
 

Como configurar o DCI OTT em uma rede EVPN

Requisitos

Este exemplo de configuração usa os seguintes dispositivos e versões de software:

  • Dispositivos spine que consistem em switches QFX5120-32C que executam o Junos OS Release 19.1R3-S2 em ambos os DCs.

  • Dispositivos Leaf compostos por switches QFX5110-48S que executam o Junos OS Release 18.4R2-S5 em DC1.

  • Dispositivos Leaf compostos por switches QFX5120-48Y que executam o Junos OS Release 18.4R2-S5 em DC2.

Visão geral

Nesta implantação, usamos uma arquitetura com duas redes de malha de data center que foram configuradas em um modelo de sobreposição de pontes com roteamento de borda (ERB). Os data centers estão interconectados com uma rede underlay IP de Camada 3. A Figura 1 mostra a conectividade WAN que fornece o transporte underlay entre os dois data centers. Usamos uma arquitetura de DCI EVPN-VXLAN over-the-top para fornecer conectividade de Camada 2 e Camada 3 para endpoints e máquinas virtuais nos dois data centers.

Figura 1: Arquitetura Network topology diagram showing two data centers connected via WAN underlay, using a spine-leaf architecture for scalability and performance. OTT DCI

Por este exemplo, algumas VLANs estão configuradas para existir apenas em um data center específico, enquanto outras VLANs abrangem os dois data centers. A Figura 2 mostra as VLANs que estão configuradas nos dois data centers. Configuramos as VLANs da seguinte forma:

  • As VLANs 10, 11 e 12 são locais para data center 1. Os endpoints nessas VLANs usam o roteamento de Camada 3 para alcançar outras VLANs no data center 2.

  • As VLANs 170, 171 e 172 são locais para data center 2. Os endpoints nessas VLANs usam o roteamento de Camada 3 para alcançar outras VLANs no data center 1.

  • As VLANs 202 e 203 são comuns ao data center 1 e ao data center 2. Essas VLANs se estendem por todos os dispositivos leaf em ambos os data centers. Os endpoints nessas VLANs usam a ponte de Camada 2 para chegar aos endpoints no outro data center.

Figura 2: VLANs em data centers Network topology of two data centers connected via WAN underlay with spine-leaf architecture using BGP for routing. DC1 has VLANs 10, 11, 12, 202, 203 and ASN 64730. DC2 has VLANs 170, 171, 172, 202, 203 and ASN 64830.

Você pode usar qualquer protocolo de roteamento na rede underlay. O protocolo de roteamento underlay permite que os dispositivos troquem endereços IP de loopback entre si. Neste exemplo, o eBGP é usado como protocolo de roteamento underlay em cada malha de data center. O protocolo eBGP também é usado para estender a rede underlay através da conexão WAN entre os dois data centers. Você pode usar o iBGP ou o eBGP como protocolo de roteamento de overlay entre os DCs. A escolha depende se você usa os mesmos ou diferentes números de sistema autônomo para seus data centers. Neste exemplo, usaremos o iBGP para o protocolo de overlay em uma malha e eBGP entre os dois data centers. A Figura 3 mostra os números do sistema autônomo e endereços IP usados neste exemplo.

Figura 3: Detalhes para peering Network topology with two data centers connected via WAN underlay. Data Center 1: DC1-Spine1 172.16.1.7, ASN 65001/64730; DC1-Spine2 172.16.1.5, ASN 65002/64730. Data Center 2: DC2-Spine1 172.16.1.9, ASN 65101/64830; DC2-Spine2 172.16.1.11, ASN 65102/64830. WAN underlay ASNs: 65199 172.16.1.6/1.4, 65299 172.16.1.8/1.10. Uses EBGP for routing. Solid lines for physical, dashed for overlay connections. de roteador WAN

Configure os dispositivos Border Spine para conectividade WAN

Requisitos

Configuração de underlay de Border Spine WAN

Nota:

As configurações mostradas nesta página estão estabelecidas em uma malha EVPN pré-existente com uma rede operacional underlay e overlay. Em outras palavras, esta seção mostra apenas as configurações adicionais necessárias para estender a subcamadas de DC para uma nuvem WAN. Em contraste, as configurações detalhadas mostram a configuração completa de cada dispositivo DC.

Esta seção mostra como configurar a configuração underlay da WAN para dispositivos spine de borda. Para a brevidade, só mostraremos as etapas para configurar um dispositivo spine em cada data center. Você pode configurar os outros dispositivos spine de borda aplicando etapas de configuração semelhantes.

Nota:

Repita esses procedimentos para todos os dispositivos spine de borda em cada data center.

Consulte as configurações detalhadas para a rede EVPN-VXLAN para os data centers para obter as configurações completas usadas neste exemplo.

Border Spine WAN Underlay

Procedimento

Procedimento passo a passo

  1. Adicione a sessão de peering WAN ao grupo underlay existente no Data Center 1 Spine 1 (DC1-Spine1). Os dispositivos spine de borda usam a rede underlay WAN para trocar informações de endereço de loopback entre os data centers. Isso, por sua vez, permite que os dispositivos spine formem uma conexão overlay eBGP em toda a nuvem wan.

    Neste exemplo, o peering do roteador WAN é adicionado ao grupo de peer BGP pré-existente UNDERLAY . Como esse grupo já está configurado como parte do underlay do DC, você só precisa adicionar o roteador WAN como um vizinho ao grupo existente UNDERLAY .

  2. Adicione o peering WAN ao grupo existente UNDERLAY no Data Center 2 Spine 1 (DC2-Spine1).

  3. Configure a política de underlay WAN comum usada nos dispositivos spine e leaf em ambos os data centers. Reservamos a sub-rede 10.80.224.128/25 para endereço loopback no Data center 1 e sub-rede 10.0.0/24 para endereço de loopback no Data center 2. Ao especificar uma gama reservada de endereços de loopback em nossa política, não precisamos atualizar a política quando um dispositivo é adicionado enquanto o dispositivo estiver configurado com um endereço de loopback reservado.

    Neste exemplo, a underlay troca apenas rotas de loopback dentro e entre os DCs. As políticas de importação e exportação para a underlay são escritas de tal forma que podem ser usadas por todos os dispositivos em ambos os DCs. Por exemplo, a UNDERLAY-EXPORT política está configurada para combinar com os endereços de loopback local e remoto de DC. Quando aplicado a um dispositivo em DC1, apenas o 10.80.224.128/25 orlonger termo é compatível. Ter o termo extra route-filter para os endereços de loopback atribuídos ao DC2 não causa nenhum dano, e permite que a mesma política seja aplicada à underlay em ambos os DCs.

Border Spine WAN Overlay

Procedimento passo a passo

Para a sobreposição da malha, você configura uma malha completa de peering eBGP entre todos os dispositivos spine de borda em ambos os data centers usando eBGP. Os dispositivos spine funcionam como refletores de rota overlay dentro de seus respectivos DC. A sessão de peering overlay estende a sobreposição de EVPN entre os DCs.

Como a sessão de overlay inter-DC é executado por uma detecção bidirecional de falha na nuvem wan (BFD) não está habilitada para esse grupo de peer. O BFD é habilitado para ser executado dentro de cada DC, tanto no underlay quanto no overlay.

Nota:

Por padrão, o eBGP altera o endereço IP no campo de next-hop do Protocolo para usar seu próprio endereço IP quando se anuncia novamente as rotas. Neste caso, queremos que o campo de próximo salto de protocolo use o endereço IP VTEP do dispositivo leaf que originou a rota. Para evitar que o BGP altere os próximos saltos de rotas overlay, habilitamos a opção no-nexthop-change no OVERLAY_INTERDC grupo de peer.

  1. Configure a rede overlay wan no DC1-Spine1.

  2. Configure a rede overlay wan no DC2-Spine1.

Configure os dispositivos Leaf para oferecer suporte a DCI de Camada 2

Para estender a conectividade de Camada 2 (VLAN) pelos dois DCs, devemos configurar a rede para estender o domínio de transmissão de Camada 2 para todos os endpoints na VLAN compartilhada. Neste exemplo, os endpoints das VLANs 202 e 203 pertencem ao mesmo domínio de Camada 2, independentemente de os endpoints estarem nos data centers locais ou remotos. O objetivo é estender ou estender essas VLANs entre os dois DCs.

Para estender a conectividade de Camada 2 para essas VLANs compartilhadas entre os DCs, você deve configurar o seguinte:

  • Configure alvos de rota exclusivos de identificador de rede VXLAN (VNI) para rotas EVPN tipo 2 e EVPN tipo 3 associadas às VLANs estendidas sob a protocols evpn hierarquia.

  • Aplique uma política de importação para aceitar os alvos de rota exclusivos que estão vinculados ao VLANS estendido usando o vrf-import comando na switch-options hierarquia. As VLANS estendidas são rotas EVPN tipo 2 e tipo 3 que são anunciadas pelo data center remoto.

Nota:

Repita esses procedimentos para todos os dispositivos leaf no data center relevante. Os comandos mostrados abaixo são adicionados às hierarquias e protocols evpn existentes switch-options para estender as VLANs compartilhadas entre os dois DCs.

Procedimento

Procedimento passo a passo

  1. Configure alvos específicos de VNI para as VLANs estendidas no Data Center 1 Leaf 1 (DC1-Leaf1).

  2. Configure uma política de importação VRF para corresponder às metas de VNI para as VLANs estendidas no Data Center 1 Leaf 1 (DC1-Leaf1). A política também corresponde às rotas padrão EVPN tipo 1 usadas para Auto-Discovery (AD). A política em si é definida em uma etapa posterior.

  3. Configure alvos específicos de VNI para as VLANs estendidas no Data Center 2 Leaf 1 (DC2-Leaf1).

  4. Especifique uma política de importação VRF para combinar com as metas de VNI para as VLANs estendidas no Data Center 2 Leaf 1 (DC2-Leaf1).

  5. Defina a política de importação de VRF que você configurou na switch-options vrf-import hierarquia na etapa anterior. Neste exemplo, usamos metas de rota exclusivas para cada data center e para cada domínio de Camada 2 que é estendido entre os DCs. A política está definida para importar a rota AD tipo 1 EVPN associada a cada DC/POD, bem como as rotas EVPN tipo 2 e EVPN tipo 3 que são usadas pelas VLANs estendidas em ambos os data centers.

    Essa política deve ser configurada em todos os dispositivos leaf em ambos os DCs.

    Nota:

    Em sua implantação, você pode usar um alvo de rota comum para os dispositivos leaf em seus data centers. Quando você usa um alvo de rota comum, as rotas dos data centers serão automaticamente importadas como parte da política de importação implícita.

    Os valores usados para as comunidades e comm_po2 os comm_pod1 valores correspondem aos valores especificados com a vrf-target statement switch-options hierarquia dos dispositivos leaf em DC1 e DC2, respectivamente. Este é o alvo de rota que é adicionado a todas as rotas EVPN tipo 1, que são usadas para descoberta automática. Esse alvo também está vinculado a todas as outras rotas EVPN que não têm um alvo específico de VNI especificado na protocols evpn hierarquia.

    Neste exemplo, as VLANs estendidas estão configuradas para usar alvos específicos de VNI. Portanto, a política de importação está escrita para corresponder aos três alvos usados por cada DC. Mais uma vez, essa abordagem permite que uma política comum seja usada em todos os dispositivos leaf em ambos os DCs.

Requisitos

Configure os dispositivos Leaf para oferecer suporte a DCI de Camada 3

As rotas EVPN tipo 5 são usadas para conectividade de Camada 3 entre DCs para VLANs que não estão estendidas. Uma rota EVPN tipo 5 também é chamada de rota de prefixo IP. Em outras palavras, uma rota tipo 5 é usada quando o domínio de broadcast de Camada 2 está limitado dentro do data center. As rotas EVPN tipo 5 permitem a conectividade de Camada 3 anunciando o prefixo IP da interface IRB associada a VLANs não estendidas. Neste exemplo, as VLANs (10, 11, 12) estão confinadas ao Data Center 1, enquanto as VLANs (170, 171, 172) estão confinadas no Data Center 2. Estabelecemos a conectividade entre data centers da Camada 3 entre os membros dessas VLANs usando rotas de prefixo IP.

Procedimento

Procedimento passo a passo

  1. Configure o DCI de Camada 3 no DC1-Leaf1 definindo um VRF de Camada 3 com suporte para rotas EVPN tipo 5.

  2. Configure o DCI de Camada 3 no DC2-Leaf1 definindo um VRF de Camada 3 com suporte para rotas EVPN tipo 5.

  3. Configure a política de DCI de Camada 3 para todos os dispositivos leaf em DC1

  4. Configure a política de DCI de Camada 3 para todos os dispositivos leaf em DC2

Configuração de política alternativa para importação de alvos de rota

Requisitos

Neste exemplo, os alvos de rota derivados automáticos incluem o número AS de overlay como parte de seu identificador. Como resultado, você acaba com diferentes metas de rota para o mesmo VNI no data center 1 e data center 2.

Para uma configuração de política mais simples, você pode obter automaticamente alvos de rota, incluindo a vrf-target declaração com a opção auto na switch-options hierarquia. Quando você habilita vrf-target auto, o Junos cria automaticamente os alvos de rota usados para rotas EVPN tipos 2 e tipo 3. Para eVPN-VXLAN, o alvo de rota é derivado automaticamente do identificador de rede VXLAN (VNI). Neste exemplo, os alvos de rota EVPN tipo 2 e tipo 3 derivados para VNI 1202 são alvo:64730:268436658 no Data center 1 e target:64830:268436658 no data center 2. Esses alvos de rota são então anexados a rotas EVPN tipo 2 e tipo 3 associadas. A vrf-target auto declaração cria uma política de importação implícita para combinar e importar os mesmos valores-alvo de rota para essas VNIs.

Com a política mais simples, as rotas EVPN tipo 2 e 3 para VLAN 202 e 203 não são importadas automaticamente. Para importar rotas EVPN tipo 2 e 3 de um data center com um número de sistema autônomo diferente, inclua a vrf-target auto import-as declaração.

Aqui está o exemplo de configuração do Leaf 1 no Data center 1.

Verificação

Procedimento

Requisitos

Visão geral

Verifique o peering do BGP

Propósito

Verifique as sessões de peering bgp entre DC, overlay e underlay.

Ação

Verifique se todas as sessões de peering BGP underlay e overlay estão estabelecidas. Isso inclui o peering de sobreposição eBGP entre DCs formados na nuvem WAN.

O abaixo é extraído do dispositivo DC2-Spine1 em DC2. Todas as sessões de peering BGP devem ser estabelecidas em todos os dispositivos leaf e spines em ambos os DCs.

Significado

A saída no DC2-Spine1 confirma que todas as suas sessões BGP estão estabelecidas. Há uma sessão de underlay e overlay por leaf local, além da sessão de peering wan, e as 2 sessões de peering overlay para os dispositivos spine no DC remoto. Isso eleva o número total de sessões para 9. A capacidade de estabelecer o peering overlay para o DC remoto confirma a troca adequada de rotas underlay na nuvem WAN.

Verifique os VTEPs em um dispositivo Leaf

Propósito

Verifique a conexão de Camada 2 entre dois dispositivos leaf em data centers diferentes.

Ação

Verifique se as interfaces VTEP estão ativas nos dispositivos leaf nos data centers locais e remotos.

O seguinte é um trecho da saída do status de VTEP de uma leaf no data center 1.

Significado

A saída no DC1-Leaf1 mostra que túneis VXLAN de Camada 2 são criados entre este dispositivo leaf e os outros dispositivos leaf na malha de data center local (o endereço VTEP do leaf 2 em DC1 é mostrado no trecho). A saída também mostra que os VTEPs são aprendidos entre este dispositivo leaf e os outros dispositivos leaf na malha remota de data center (o VTEP para leaf 2 em DC2 é mostrado no trecho). Os contadores de pacotes de entrada e saída verificam a transmissão bem-sucedida de dados entre os endpoints nesses VTEPs.

Verificar rotas EVPN tipo 1

Propósito

Verifique se as rotas do tipo 1 da EVPN estão sendo adicionadas à tabela de roteamento.

Ação

Verifique se a rota EVPN type1 (AD/ESI) foi recebida e instalada..

Exibir informações de instâncias de roteamento EVPN. O trecho abaixo é tirado na folha 1 em DC1.

Significado

Essas saídas mostram que o DC1-Leaf1 recebeu rotas EVPN tipo1 (AD/ESI) a partir do data center remoto. Você pode usar a saída do show route extensive comando para mostrar que essas rotas têm um alvo de rota de "target:64830:999" e que essas rotas foram instaladas com sucesso. O ESI 02:02:02:02:01 e 02:02:02:02:02 são segmentos de ethernet no data center remoto. Essa saída também mostra que os PEs remotos com endereços IP de 10,0.0.18 e 10.0.0.19 fazem parte desses segmentos de Ethernet.

Verifique as rotas EVPN Tipo 2

Propósito

Verifique se as rotas do tipo 2 da EVPN estão sendo adicionadas à tabela de roteamento.

Ação

Verifique se uma rota EVPN tipo 2 foi recebida e instalada na tabela de rotas em um dispositivo leaf no data center 1.

Use a rota de exibição para encontrar um endpoint na VLAN 203 que está no data center remoto.

Use a visão detalhada para a rota de exibição para ver mais detalhes.

Use o show vlans comando para encontrar as informações sobre o VLAN 203.

A saída acima mostra que o VLAN 203 está configurado em VTEPs "vtep.32769 - 10.80.224.141 – DC1-Leaf2", "vtep.232772 – 10.0.0.18 – DC2-Leaf2", "vtep.32770 - 10.0.0.19 – DC2-Leaf1". A saída também indica que existem endpoints conectados ao VLAN v203 nesses VTEPs. Você pode usar show interfaces VTEP para obter o endereço IP VTEP para esses VTEPs. Use o show evpn database e os show ethernet-switching-table comandos para encontrar o endereço MAC e o endereço IP para esses endpoints.

Use o show evpn database para encontrar entradas no banco de dados EVPN.

Use o show ethernet-switching table comando para exibir informações para um endereço MAC específico.

Significado

A saída mostra que o endereço MAC de um dispositivo na VLAN 203 no PE remoto foi instalado no banco de dados EVPN e está na tabela de comutação Ethernet.

Verifique o DCI da camada 3

Propósito

Verifique se as rotas de Camada 3 estão instaladas na tabela de roteamento.

Ação

Verifique se uma rota EVPN tipo 5 foi recebida e instalada na tabela de rotas em um dispositivo leaf no data center 1.

Verifique se você está recebendo rotas EVPN tipo 5 a partir do 10.1.170.0/24, que é a sub-rede para VLAN 170. Esta VLAN é local para data center 2. Para chegar a essa sub-rede a partir do Data Center 1, é necessário roteamento de Camada 3.

Você pode ver mais detalhes sobre a rota EVPN tipo 5 para a rede 10.1.170.0/24. O tráfego enviado deste dispositivo leaf para esta sub-rede é encapsulado no túnel VXLAN com VNI 9999 e enviado para a leaf remota 10.0.0.18 no data center 2.

A saída confirma que as rotas para a sub-rede 10.1.170.0/24 estão presentes neste dispositivo leaf. Como estamos exportando e importando rotas de host, você vê as rotas de host EVPN tipo 5 específicas.

A saída mostra rotas para a sub-rede 10.1.203.0/24 neste dispositivo leaf. Neste caso, a VLAN 203 se estende por ambos os data centers. Quando você limita apenas as rotas EVPN tipo 5 para rotas de sub-rede, você terá o roteamento inter-vni assimétrico para VLANs estendidas L2. Se você preferir implantar um modelo simétrico para roteamento entre vni para VLANs estendidas L2, você deve exportar e importar rotas de host tipo 5 EVPN.

Este exemplo usa a T5_EXPORT política aplicada à TENANT_1_VRF política de exportação para o protocolo EVPN para efetivar o anúncio de /32 rotas de host. Como resultado, este exemplo demonstra roteamento simétrico para roteamento entre VLAN quando essas VLANs são estendidas entre DCs.

Significado

Essa saída mostra que tanto a sub-rede 10.1.203.0/24 quanto a rota de host específica para 10.1.203.52/32 (o endereço IP de um endpoint no Data Center 2) foram instalados. A rota mais EVPN tipo 5 é preferida na rota EVPN tipo 2 para a rota 10.1.203.52/32. Isso resulta em roteamento simétrico entre VNI sobre VLANs estendidas de Camada 2.