Criando um Nexus 9000 VXLAN Multisite TRM usando DCNM

Introduction

Este documento serve para explicar como implantar uma estrutura TRM multisite Cisco Nexus 9000 VXLAN onde os gateways de borda estão conectados através de Switches DCI

Topologia

Detalhes da topologia

• DC1 e DC2 são dois locais de datacenter que estão executando VXLAN.
• Os gateways de borda DC1 e DC2 são conectados entre si através de Switches DCI.
• Os switches DCI não executam nenhuma VXLAN; Eles estão executando o eBGP para a base para acessibilidade de DC1 para DC2 e vice-versa. Além disso, os Switches DCI são configurados com o vrf do locatário; Neste exemplo, seria vrf- "tenant-1".
• Os switches DCI também se conectam a redes externas que não são VXLAN.
• As conexões VRFLITE são terminadas em gateways de borda(Suporte à coexistência de funções VRFLITE e gateway de borda iniciado de NXOS-9.3(3) e DCNM-11.3(1))
• Os gateways de borda estão em execução no modo Anycast; Ao executar o TRM(Multisite Routed Multicast) nesta versão, os Gateways de Borda não podem ser configurados como vPC(consulte o Guia de Configuração do TRM Multisite para obter outras limitações)
• Para essa topologia, todos os switches BGW terão duas conexões físicas para cada um dos switches DCI; Um link estará no VRF padrão (que será usado para o tráfego entre locais) e outro link estará no VRF tenant-1, que é usado para estender VRFLITE para o ambiente não-vxlan.

Detalhes de PIM/Multicast(Específico para TRM)

• O PIM RP subjacente para ambos os locais são os switches Spine e o Loopback254 está configurado para o mesmo. O PIM RP subjacente é usado para que os VTEPs possam enviar registros PIM, bem como PIM Joins para os Spines (para fins de replicação de tráfego BUM para vários VNIDs)
• Para o TRM, o RP pode ser especificado por diferentes meios; Aqui, para a finalidade do documento, o PIM RP é o roteador central na parte superior da topologia externa à estrutura de VXLAN. 
• Todos os VTEPs terão o roteador Core apontado como PIM RP configurado nos respectivos VRFs
• DC1-Host1 está enviando multicast para o grupo 239.144.144.144; DC2-Host1 é receptor para esse grupo em DC2 e um Host Externo(172.17.100.100) para a vxlan também está se inscrevendo nesse grupo
• DC2-Host1 está enviando multicast para o grupo 239.145.145.145; DC1-Host1 é receptor para esse grupo em DC1 e um Host Externo(172.17.100.100) para a vxlan também está se inscrevendo nesse grupo
• DC2-Host2 está na Vlan 144 e é receptor para grupos Multicast- 239.144.144.144 e 239.100.100.100
• Host Externo(172.17.100.100) está enviando tráfego para o qual DC1-Host1 e DC2-Host1 são receptores.
• Isso abrange os fluxos de tráfego entre o leste/oeste e entre vlan e norte/sul e multicast

Componentes Utilizados

• Switches Nexus 9k executando 9.3(3)
• DCNM em execução 11.3(1)

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Etapas de alto nível

1) Considerando que este documento é baseado em dois DCs utilizando o recurso VXLAN Multisite, duas malhas fáceis precisam ser criadas

2) Criar MSD e mover DC1 e DC2

3) Criar estrutura externa e adicionar switches DCI

4) Crie a sobreposição e a sobreposição de vários locais

5) Criar anexos de extensão VRF nos gateways de borda

6) Verificação do tráfego unicast

7) Verificação do tráfego multicast

Passo 1: Criação de malha fácil para DC1

• Faça login no DCNM e, no painel, selecione a opção -> "Fabric Builder"

• Selecione a opção "Create Fabric" (Criar estrutura)

• Em seguida, forneça o Nome da estrutura, o Modelo e, em seguida, a guia "Geral", Preencha o ASN relevante, a numeração da interface de estrutura, Qualquer MAC de gateway de transmissão (AGM)

# AGM é usado por Hosts na estrutura como o endereço MAC do gateway padrão. Isso será o mesmo em todos os switches leaf (como todos os switches Leaf dentro da estrutura estão executando qualquer encaminhamento de estrutura). O endereço IP e o endereço MAC do gateway padrão serão os mesmos em todos os switches leaf

• O próximo é definir o modo de Replicação

# O modo de replicação para esta finalidade de documento é Multicast; Outra opção é usar a replicação de entrada (IR)

# A sub-rede do grupo multicast será o grupo multicast usado por VTEPs para replicar o tráfego de BUM (como solicitações ARP)

# A caixa de seleção "Enable Tenant Routed Multicast(TRM)" (Habilitar multicast roteado pelo usuário) precisa estar habilitada

# Preencha outras caixas conforme necessário.

• A guia para vPC não é tocada, pois a topologia aqui não está usando nenhum vPC
• Em seguida, na guia Protocolos

# Modifique as caixas relevantes conforme necessário.

• Em seguida, a guia Avançado

# Para esta finalidade de documento, todos os campos são deixados como padrão.

# O ASN é preenchido automaticamente a partir do que foi fornecido na guia Geral

• Em seguida, preencha os campos na guia "Recursos"

# O intervalo de IP de loopback de roteamento de subcamada seria aquele usado para protocolos como BGP, OSPF

# Sublay VTEP loopback IP range são os que serão usados para a interface NVE.

# Underlay RP é para o PIM RP usado para grupos multicast de BUM.

• Preencha outras guias com as informações relevantes e, em seguida, "salve"

Passo 2: Criação de malha fácil para DC2

• Execute a mesma tarefa da etapa 1 para criar uma estrutura fácil para DC2
• Certifique-se de fornecer um bloco de endereços IP diferente em Recursos para NVE e Loopbacks de roteamento e quaisquer outras áreas relevantes
• As ASNs também devem ser diferentes
• Os VNIDs de Camada 2 e Camada 2 são os mesmos

Passo 3: Criação de MSD para vários locais

• Uma estrutura MSD deverá ser criada conforme mostrado abaixo.

• Preencha também a guia DCI 

# O método de implantação IFC de sobreposição de vários locais é "Direct_To_BGWS", pois aqui DC1-BGWs formarão a conexão de sobreposição com DC2-BGWs. Os switches DCI mostrados na topologia são apenas dispositivos de camada 3 de trânsito (assim como VRFLITE)

• A próxima etapa é mencionar a faixa de loopback multisite(esse endereço IP será usado como o IP de loopback multisite em BGWs DC1 e DC2; DC1-BGW1 e DC1-BGW2 compartilham o mesmo IP de loopback multisite; DC2-BGW1 e DC2-BGW2 compartilham o mesmo IP de loopback multisite, mas serão diferentes dos DC1-BGWs

# Quando os campos estiverem preenchidos, clique em "salvar".

# Após concluir as etapas de 1 a 3, a página do Fabric builder será como abaixo.

Passo 4: Migração da estrutura DC1 e DC2 para o MSD multilocal

# Nesta etapa, as malhas DC1 e DC2 são movidas para MSD multisite criado na Etapa 3. Abaixo estão as capturas de tela sobre como alcançar o mesmo objetivo.

# Selecione o MSD, clique em "move Fabrics" (mover estrutura) e selecione DC1 e DC2 um por um e depois "add" (adicionar).

# Quando ambas as malhas forem movidas, a página inicial será como abaixo

# MSD multisite mostrará DC1 e DC2 como malhas membro

Passo 5: Criação de VRFs

# Criar VRFs pode ser feito a partir da estrutura MSD que será aplicável para ambas as estruturas. Abaixo estão as capturas de tela para alcançar o mesmo resultado.

# Preencha também a guia avançada e depois "crie"

Passo 6: Criação de redes

# Criando Vlans e VNIDs correspondentes, as SVIs podem ser feitas a partir da estrutura MSD que será aplicável para ambas as estruturas.

# Na guia "advanced" (avançado), ative a caixa de seleção se os BGWs precisarem ser o Gateway para as redes

# Quando todos os campos estiverem preenchidos, clique em "Criar rede"

# Repita as mesmas etapas para qualquer outra VLAN/rede

Passo 7: Criação de malha externa para os switches DCI

# Este exemplo leva em consideração os switches DCI que estão no caminho do pacote de DC1 para DC2 (no que diz respeito à comunicação entre locais) que é comumente visto quando há mais de 2 malhas. 

# Estrutura externa incluirá os dois Switches DCI que estão na parte superior da topologia mostrada no início deste documento

# Crie o formato com o modelo "externo" e especifique o ASN

# Modificar quaisquer outros campos relevantes para a implantação

Passo 8: Adição de switches em cada malha

# Aqui, todos os switches por malha serão adicionados à respectiva malha.

O procedimento para adicionar switches é mostrado nas capturas de tela abaixo.

# Se "Preseve Config" for "NO"; qualquer configuração de switch presente será apagada; A exceção é o nome do host, a variável de inicialização, o endereço IP MGMT0, a rota no gerenciamento de contexto VRF

# Defina as funções nos switches corretamente (clique com o botão direito do mouse no switch, defina a função e depois a função relevante

# Também organize o layout dos switches de acordo e clique em "salvar layout"

Etapa 9: Configurações de TRM para estruturas individuais

• A próxima etapa é ativar as caixas de seleção do TRM em cada estrutura

# Execute esta etapa para todas as redes para todas as estruturas.

• Depois disso, os VRFs em malhas individuais também são necessários para fazer algumas alterações e adicionar informações conforme abaixo.

# Isso precisa ser feito em DC1 e DC2 também para a seção VRF.

# Observe que o grupo multicast para o VRF-> 239.1.2.100 foi alterado manualmente do grupo preenchido automaticamente; A prática recomendada é usar um grupo diferente para o VRF VNI de Camada 3 e para qualquer grupo multicast de tráfego de VNI de VLAN L2

Etapa 10: Configuração VRFLITE em gateways de borda

# A partir do NXOS 9.3(3) e do DCNM 11.3(1), os Gateways de Borda podem atuar como Gateways de Borda e ponto de conectividade VRFLITE (o que permitirá que o Gateway de Borda tenha uma vizinhança VRFLITE com um roteador externo e assim os dispositivos externos podem se comunicar com os dispositivos na estrutura)

# Para o propósito deste documento, os Gateways de borda estão formando a vizinhança VRFLITE com o roteador DCI que estão no norte da topologia mostrada acima. 

# Um ponto a ser observado é que: VRFLITE e links de subcamada multisite não podem ser os mesmos links físicos. Links separados precisarão ser ativados para formar a subcamada de vários sites e vrflite

# Capturas de tela abaixo ilustrarão como obter extensões VRF LITE e multisite em Gateways de borda.

# Mudar para a "vista tabular"

# Mova para a guia "links" e adicione um link "VRFLITE entre estruturas" e terá que especificar a estrutura de origem como DC1 e estrutura de destino como DCI

# Selecione a interface certa para a interface de origem que leva ao Switch DCI correto

No perfil do link, forneça os endereços IP locais e remotos

# Também habilite a caixa de seleção - "flag de implantação automática" para que a configuração dos switches DCI para VRFLITE também seja preenchida automaticamente (isso é feito em uma etapa futura)

# ASNs são preenchidos automaticamente

# Quando todos os campos estiverem preenchidos com as informações corretas, clique no botão "salvar"

• A etapa acima terá que ser feita para todas as conexões BGW para DCI em todos os 4 gateways de borda em direção aos dois switches DCI.
• Considerando a topologia deste documento, haverá um total de 8 conexões VRF LITE entre estruturas e a aparência abaixo.

Etapa 11: Configuração de subcamada de vários sites em gateways de borda

# A próxima etapa é configurar a Subcamada multisite em cada Border Gateway em cada estrutura.

# Para essa finalidade, precisaremos de links físicos separados de BGWs para switches DCI. Os links usados para VRFLITE na etapa 10 não podem ser usados para Sobreposição de vários sites

# Essas interfaces farão parte do "vrf padrão" ao contrário do anterior, em que as interfaces farão parte do vrf do locatário (este exemplo, é o locatário 1)

# Abaixo, as capturas de tela ajudarão a seguir as etapas para fazer essa configuração.

# A mesma etapa terá que ser executada para todas as conexões de BGWs a switches DCI

# No final, um total de 8 conexões de sub-camada multilocal entre estruturas será visto como abaixo.

Etapa 12: Configurações de sobreposição de vários sites para TRM

# Quando a Subcamada Multisite for concluída, as interfaces/links de sobreposição multisite serão preenchidos automaticamente e poderão ser vistos na exibição em forma de tabela em links na malha MSD multisite.

# Por padrão, a Sobreposição de vários locais formará apenas o vizinho vpn l2vpn bgp de cada local BGWs para o outro, o que é necessário para a comunicação unicast de um local para outro. No entanto, quando o Multicast é necessário para ser executado entre os sites (que são conectados pelo recurso multisite vxlan), é necessário ativar a caixa de seleção TRM, conforme visto abaixo, para todas as interfaces de sobreposição dentro do MSD Fabric multisite. Capturas de tela ilustrarão como fazer isso.

Passo 13: Salvar/implantar em MSD e estruturas individuais

# Execute uma ação de salvar/implantar que irá enviar as configurações relevantes de acordo com as etapas acima

# Ao selecionar o MSD, as configurações que serão enviadas serão aplicadas somente aos Gateways de borda.

# Assim, é necessário salvar/implantar as malhas individuais, que enviarão as configurações relevantes para todos os switches/VTEPs leaf regulares

Passo 14: Anexos de extensão VRF para MSD

# Selecione o MSD e vá para a seção VRF

# Observe que a opção Extend deve ser "MULTISITE+VRF_LITE", como neste documento, a funcionalidade do gateway de borda e o VRFLITE estão integrados aos switches do gateway de borda.

# AUTO_VRF_LITE será definido como verdadeiro

# O NOME DO VRF DO PAR precisará ser preenchido manualmente para todos os 8 conforme mostrado abaixo, de BGWs a Switches DCI (aqui, o exemplo usa o mesmo NOME do VRF em Switches DCI)

# Depois de concluído, clique em "salvar"

# Durante a criação de extensões VRF, somente os Gateways de Borda terão configurações adicionais para os switches ICD VRFLITE

# Assim, a folha normal terá que ser selecionada separadamente e, em seguida, clicar nas "caixas de seleção" para cada VRFs do usuário, como mostrado acima.

# Clique em Implantar para enviar as configurações

Etapa 15: Distribuindo configurações de rede para a estrutura a partir do MSD

# Selecione as redes relevantes na malha MSD 

# Observe que somente os Gateways de Borda são selecionados no momento; Execute o mesmo procedimento e selecione os switches de folha regular/VTEPs-> DC1-VTEP e DC2-VTEP neste caso.

# Depois de concluir, clique em "implantar" (o que irá enviar configurações para todos os 6 switches acima)

Passo 16: Verificação de VRF e redes em todos os VRFs

# Esta etapa é para verificar se o VRF e as redes são mostradas como "Implantadas" em todas as estruturas; se estiver sendo exibido como pendente, certifique-se de "implantar" as configurações.

Passo 17: Implantação de configurações na malha externa

# Esta etapa é necessária para enviar todas as configurações relevantes de endereçamento IP, BGP e VRFLITE para os Switches DCI.

# Para fazer isso, selecione a Estrutura externa e clique em "salvar e implantar"

DCI-1# sh ip bgp sum
BGP summary information for VRF default, address family IPv4 Unicast
BGP router identifier 10.10.100.1, local AS number 65001
BGP table version is 173, IPv4 Unicast config peers 4, capable peers 4
22 network entries and 28 paths using 6000 bytes of memory
BGP attribute entries [3/504], BGP AS path entries [2/12]
BGP community entries [0/0], BGP clusterlist entries [0/0]

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.4.10.1       4 65000      11      10      173    0    0 00:04:42 5         
10.4.10.9       4 65000      11      10      173    0    0 00:04:46 5         
10.4.20.37      4 65002      11      10      173    0    0 00:04:48 5         
10.4.20.49      4 65002      11      10      173    0    0 00:04:44 5         
DCI-1# sh ip bgp sum vrf tenant-1
BGP summary information for VRF tenant-1, address family IPv4 Unicast
BGP router identifier 10.33.10.2, local AS number 65001
BGP table version is 14, IPv4 Unicast config peers 4, capable peers 4
2 network entries and 8 paths using 1200 bytes of memory
BGP attribute entries [2/336], BGP AS path entries [2/12]
BGP community entries [0/0], BGP clusterlist entries [0/0]

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.33.10.1      4 65000       8      10       14    0    0 00:01:41 2         
10.33.10.9      4 65000      10      11       14    0    0 00:03:16 2         
10.33.20.1      4 65002      11      10       14    0    0 00:04:40 2         
10.33.20.9      4 65002      11      10       14    0    0 00:04:39 2    

DCI-2# sh ip bgp sum
BGP summary information for VRF default, address family IPv4 Unicast
BGP router identifier 10.10.100.2, local AS number 65001
BGP table version is 160, IPv4 Unicast config peers 4, capable peers 4
22 network entries and 28 paths using 6000 bytes of memory
BGP attribute entries [3/504], BGP AS path entries [2/12]
BGP community entries [0/0], BGP clusterlist entries [0/0]

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.4.10.5       4 65000      12      11      160    0    0 00:05:10 5         
10.4.10.13      4 65000      12      11      160    0    0 00:05:11 5         
10.4.20.45      4 65002      12      11      160    0    0 00:05:10 5         
10.4.20.53      4 65002      12      11      160    0    0 00:05:07 5         
DCI-2# sh ip bgp sum vrf tenant-1 
BGP summary information for VRF tenant-1, address family IPv4 Unicast
BGP router identifier 10.33.10.6, local AS number 65001
BGP table version is 14, IPv4 Unicast config peers 4, capable peers 4
2 network entries and 8 paths using 1200 bytes of memory
BGP attribute entries [2/336], BGP AS path entries [2/12]
BGP community entries [0/0], BGP clusterlist entries [0/0]

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.33.10.5      4 65000      10      11       14    0    0 00:03:28 2         
10.33.10.13     4 65000      11      11       14    0    0 00:04:30 2         
10.33.20.5      4 65002      12      11       14    0    0 00:05:05 2         
10.33.20.13     4 65002      12      11       14    0    0 00:05:03 2     

# Depois de implantado, veremos 4 vizinhos IPv4 BGP de cada Switch DCI para todos os BGWs e 4 vizinhos IPv4 VRF BGP também(que é para o locatário VRF EXtension)

Passo 18: Configuração do iBGP entre switches DCI

# Considerando que os switches DCI estão tendo links conectados entre si, um vizinho IPv4 do iBGP é ideal para que se qualquer conexão downstream for desativada no switch DCI-1, o tráfego de norte a sul ainda possa ser encaminhado através do DCI-2

# Para isso, uma vizinhança IPv4 do iBGP é necessária entre os switches DCI e usa o Next-Hop-Self também em cada lado. 

# Um Forma Livre terá que ser usado em switches DCI para conseguir isso. As linhas de configuração necessárias são as abaixo.

# Os switches DCI na topologia acima estão configurados no vPC; assim, o SVI de backup pode ser usado para criar os vizinhos do iBGP

# Selecione a estrutura DCI e clique com o botão direito do mouse em cada switch e clique em "exibir/editar políticas"

# Faça a mesma alteração no switch DCI-2 e, em seguida, "save&Deploy" (salvar e implantar) para enviar as configurações reais para os switches DCI

# Uma vez concluída, a verificação CLI pode ser feita usando o comando abaixo.

DCI-2# sh ip bgp sum
BGP summary information for VRF default, address family IPv4 Unicast
BGP router identifier 10.10.100.2, local AS number 65001
BGP table version is 187, IPv4 Unicast config peers 5, capable peers 5
24 network entries and 46 paths using 8400 bytes of memory
BGP attribute entries [6/1008], BGP AS path entries [2/12]
BGP community entries [0/0], BGP clusterlist entries [0/0]

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.4.10.5       4 65000    1206    1204      187    0    0 19:59:17 5         
10.4.10.13      4 65000    1206    1204      187    0    0 19:59:19 5         
10.4.20.45      4 65002    1206    1204      187    0    0 19:59:17 5         
10.4.20.53      4 65002    1206    1204      187    0    0 19:59:14 5         
10.10.8.1       4 65001      12       7      187    0    0 00:00:12 18    # iBGP neighborship from DCI-2 to DCI-1

Passo 19: Verificação dos vizinhos IGP/BGP

Vizinhos OSPF

# Como todo o IGP subjacente é OSPF neste exemplo, todos os VTEPs formarão a vizinhança do OSPF com os spines e isso inclui os switches BGW em um local também.

DC1-SPINE# show ip ospf neighbors 
 OSPF Process ID UNDERLAY VRF default
 Total number of neighbors: 3
 Neighbor ID     Pri State            Up Time  Address         Interface
 10.10.10.3        1 FULL/ -          1d01h    10.10.10.3      Eth1/1     # DC1-Spine to DC1-VTEP
 10.10.10.2        1 FULL/ -          1d01h    10.10.10.2      Eth1/2     # DC1-Spine to DC1-BGW2
 10.10.10.1        1 FULL/ -          1d01h    10.10.10.1      Eth1/3     # DC1-Spine to DC1-BGW1

# Todos os loopbacks (IDs do roteador BGP, loopbacks NVE) são anunciados no OSPF; Dessa forma, em uma estrutura, todos os loopbacks são aprendidos através do protocolo de roteamento OSPF, o que ajudaria a formar ainda mais a vizinhança de vpn de l2vpn

vizinhos de BGP

# Dentro de uma estrutura, essa topologia terá vizinhos de vpn l2vpn de Spines para VTEPs regulares e também para Gateways de borda.

DC1-SPINE# show  bgp l2vpn evpn sum
BGP summary information for VRF default, address family L2VPN EVPN
BGP router identifier 10.10.10.4, local AS number 65000
BGP table version is 80, L2VPN EVPN config peers 3, capable peers 3
22 network entries and 22 paths using 5280 bytes of memory
BGP attribute entries [14/2352], BGP AS path entries [1/6]
BGP community entries [0/0], BGP clusterlist entries [0/0]

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.10.1      4 65000    1584    1560       80    0    0    1d01h 10        # DC1-Spine to DC1-BGW1
10.10.10.2      4 65000    1565    1555       80    0    0    1d01h 10        # DC1-Spine to DC1-BGW2
10.10.10.3      4 65000    1550    1554       80    0    0    1d01h 2         # DC1-Spine to DC1-VTEP

# Considerando que esta é uma Implantação de vários locais com Gateways de borda compartilhando de um site para outro usando a vpn l2vpn do eBGP, o mesmo pode ser verificado usando o comando abaixo em um switch de gateway de borda.

DC1-BGW1# show  bgp l2vpn evpn sum
BGP summary information for VRF default, address family L2VPN EVPN
BGP router identifier 10.10.10.1, local AS number 65000
BGP table version is 156, L2VPN EVPN config peers 3, capable peers 3
45 network entries and 60 paths using 9480 bytes of memory
BGP attribute entries [47/7896], BGP AS path entries [1/6]
BGP community entries [0/0], BGP clusterlist entries [2/8]

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.10.4      4 65000    1634    1560      156    0    0    1d01h 8       # DC1-BGW1 to DC1-SPINE  
10.10.20.3      4 65002    1258    1218      156    0    0 20:08:03 9       # DC1-BGW1 to DC2-BGW1  
10.10.20.4      4 65002    1258    1217      156    0    0 20:07:29 9       # DC1-BGW1 to DC2-BGW2  

Neighbor        T    AS PfxRcd     Type-2     Type-3     Type-4     Type-5    
10.10.10.4      I 65000 8          2          0          1          5         
10.10.20.3      E 65002 9          4          2          0          3         
10.10.20.4      E 65002 9          4          2          0          3     

Vizinhos BGP MVPN para TRM

# Com as configurações de TRM em vigor, todos os switches leaf (incluindo BGWs) formarão a vizinhança de mvpn com os spines

DC1-SPINE# show bgp ipv4 mvpn summary
BGP summary information for VRF default, address family IPv4 MVPN
BGP router identifier 10.10.10.4, local AS number 65000
BGP table version is 20, IPv4 MVPN config peers 3, capable peers 3
0 network entries and 0 paths using 0 bytes of memory
BGP attribute entries [0/0], BGP AS path entries [0/0]
BGP community entries [0/0], BGP clusterlist entries [0/0]

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.10.1      4 65000    2596    2572       20    0    0    1d18h 0         
10.10.10.2      4 65000    2577    2567       20    0    0    1d18h 0         
10.10.10.3      4 65000    2562    2566       20    0    0    1d18h 0    

# Além disso, os Gateways de Borda são necessários para formar a vizinhança de mvpn entre si para que o tráfego multicast leste/oeste passe corretamente.

DC1-BGW1# show bgp ipv4 mvpn summary
BGP summary information for VRF default, address family IPv4 MVPN
BGP router identifier 10.10.10.1, local AS number 65000
BGP table version is 6, IPv4 MVPN config peers 3, capable peers 3
0 network entries and 0 paths using 0 bytes of memory
BGP attribute entries [0/0], BGP AS path entries [0/0]
BGP community entries [0/0], BGP clusterlist entries [2/8]

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.10.10.4      4 65000    2645    2571        6    0    0    1d18h 0         
10.10.20.3      4 65002    2273    2233        6    0    0    1d12h 0         
10.10.20.4      4 65002    2273    2232        6    0    0    1d12h 0  

Passo 20: Criação de loopback VRF de locatário em switches de gateway de borda

# Criar loopbacks no VRF de locatário com endereços IP exclusivos em todos os gateways de borda.

# Para essa finalidade, selecione DC1, clique com o botão direito em DC1-BGW1, Gerencie interfaces e crie loopback conforme mostrado abaixo.

# A mesma etapa deverá ser feita em outros 3 Gateways de borda.

Passo 21: Configurações VRFLITE em switches DCI

# Nesta topologia, os Switches DCI são configurados com VRFLITE em direção aos BGWs. O VRFLITE também é configurado para os switches North Of DCI (ou seja, para os switches Core)

# Para fins de TRM, o PIM RP dentro do espaço 1 de VRF está localizado no Switch principal que está conectado via VRFLITE aos switches DCI

# Esta topologia tem a vizinhança de BGP IPv4 de switches DCI para o Switch Core no espaço VRF 1 que está na parte superior do diagrama.

# Para essa finalidade, as subinterfaces são criadas e atribuídas com endereços IP e os vizinhos de BGP também são estabelecidos (isso é feito pela CLI diretamente nos ICD e nos Switches de núcleo)

DCI-1# sh ip bgp sum vrf tenant-1 
BGP summary information for VRF tenant-1, address family IPv4 Unicast
BGP router identifier 10.33.10.2, local AS number 65001
BGP table version is 17, IPv4 Unicast config peers 5, capable peers 5
4 network entries and 10 paths using 1680 bytes of memory
BGP attribute entries [3/504], BGP AS path entries [3/18]
BGP community entries [0/0], BGP clusterlist entries [0/0]

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.33.10.1      4 65000    6366    6368       17    0    0    4d10h 2         
10.33.10.9      4 65000    6368    6369       17    0    0    4d10h 2         
10.33.20.1      4 65002    6369    6368       17    0    0    4d10h 2         
10.33.20.9      4 65002    6369    6368       17    0    0    4d10h 2         
172.16.111.2    4 65100      68      67       17    0    0 00:49:49 2  # This is towards the Core switch from DCI-1

# Acima em vermelho está o vizinho BGP em direção ao switch Core do DCI-1.

DCI-2# sh ip bgp sum vr tenant-1 
BGP summary information for VRF tenant-1, address family IPv4 Unicast
BGP router identifier 10.33.10.6, local AS number 65001
BGP table version is 17, IPv4 Unicast config peers 5, capable peers 5
4 network entries and 10 paths using 1680 bytes of memory
BGP attribute entries [3/504], BGP AS path entries [3/18]
BGP community entries [0/0], BGP clusterlist entries [0/0]

Neighbor        V    AS MsgRcvd MsgSent   TblVer  InQ OutQ Up/Down  State/PfxRcd
10.33.10.5      4 65000    6368    6369       17    0    0    4d10h 2         
10.33.10.13     4 65000    6369    6369       17    0    0    4d10h 2         
10.33.20.5      4 65002    6370    6369       17    0    0    4d10h 2         
10.33.20.13     4 65002    6370    6369       17    0    0    4d10h 2         
172.16.222.2    4 65100      53      52       17    0    0 00:46:12 2  # This is towards the Core switch from DCI-2

# As respectivas configurações de BGP também são necessárias no switch Core (de volta ao DCI-1 e ao DCI-2)

Verificações unicast

Leste/Oeste de DC1-Host1 a DC2-Host1

# Com todas as configurações acima enviadas do DCNM e CLI manual (Etapas 1 a 21), a acessibilidade do unicast deve estar funcionando no Leste/Oeste

DC1-Host1# ping 172.16.144.2 source 172.16.144.1
PING 172.16.144.2 (172.16.144.2) from 172.16.144.1: 56 data bytes
64 bytes from 172.16.144.2: icmp_seq=0 ttl=254 time=0.858 ms
64 bytes from 172.16.144.2: icmp_seq=1 ttl=254 time=0.456 ms
64 bytes from 172.16.144.2: icmp_seq=2 ttl=254 time=0.431 ms
64 bytes from 172.16.144.2: icmp_seq=3 ttl=254 time=0.454 ms
64 bytes from 172.16.144.2: icmp_seq=4 ttl=254 time=0.446 ms

--- 172.16.144.2 ping statistics ---
5 packets transmitted, 5 packets received, 0.00% packet loss
round-trip min/avg/max = 0.431/0.529/0.858 ms

Norte/Sul de DC1-Host1 a PIM RP(10.200.200.100)

DC1-Host1# ping 10.200.200.100 source 172.16.144.1
PING 10.200.200.100 (10.200.200.100) from 172.16.144.1: 56 data bytes
64 bytes from 10.200.200.100: icmp_seq=0 ttl=250 time=0.879 ms
64 bytes from 10.200.200.100: icmp_seq=1 ttl=250 time=0.481 ms
64 bytes from 10.200.200.100: icmp_seq=2 ttl=250 time=0.483 ms
64 bytes from 10.200.200.100: icmp_seq=3 ttl=250 time=0.464 ms
64 bytes from 10.200.200.100: icmp_seq=4 ttl=250 time=0.485 ms

--- 10.200.200.100 ping statistics ---
5 packets transmitted, 5 packets received, 0.00% packet loss
round-trip min/avg/max = 0.464/0.558/0.879 ms

Verificações multicast

Para esta finalidade de documento, o PIM RP para o VRF "espaço-1" é configurado e presente externo à VXLAN Fabric; De acordo com a topologia, o PIM RP é configurado no switch central com o endereço IP -> 10.200.200.100

Fonte em não-vxlan (atrás do switch central), receptor em DC2

Refira a topologia mostrada no início.

# Tráfego multicast norte/sul proveniente de host não-VXLAN-> 172.17.100.100, Receptor está presente em ambos os datacenters; DC1-Host1-> 172.16.144.1 e DC2-Host1-> 172.16.144.2, Grupo -> 239.100.100.100

Legacy-SW#ping 239.100.100.100 source 172.17.100.100 rep 1
Type escape sequence to abort.
Sending 1, 100-byte ICMP Echos to 239.100.100.100, timeout is 2 seconds:
Packet sent with a source address of 172.17.100.100

Reply to request 0 from 172.16.144.1, 3 ms
Reply to request 0 from 172.16.144.1, 3 ms
Reply to request 0 from 172.16.144.2, 3 ms
Reply to request 0 from 172.16.144.2, 3 ms

Fonte em DC1, Receptor em DC2 e externo

DC1-Host1# ping multicast 239.144.144.144 interface vlan 144 vrf vlan144 cou 1
PING 239.144.144.144 (239.144.144.144): 56 data bytes
64 bytes from 172.16.144.2: icmp_seq=0 ttl=254 time=0.781 ms       # Receiver in DC2
64 bytes from 172.17.100.100: icmp_seq=0 ttl=249 time=2.355 ms     # External Receiver

--- 239.144.144.144 ping multicast statistics ---
1 packets transmitted,
From member 172.17.100.100: 1 packet received, 0.00% packet loss
From member 172.16.144.2: 1 packet received, 0.00% packet loss
--- in total, 2 group members responded ---

Fonte em DC2, Receptor em DC1 e externo

DC2-Host1# ping multicast 239.145.145.145 interface vlan 144 vrf vlan144  cou 1
PING 239.145.145.145 (239.145.145.145): 56 data bytes
64 bytes from 172.16.144.1: icmp_seq=0 ttl=254 time=0.821 ms       # Receiver in DC1
64 bytes from 172.17.100.100: icmp_seq=0 ttl=248 time=2.043 ms     # External Receiver

--- 239.145.145.145 ping multicast statistics ---
1 packets transmitted,
From member 172.17.100.100: 1 packet received, 0.00% packet loss
From member 172.16.144.1: 1 packet received, 0.00% packet loss
--- in total, 2 group members responded ---