Creazione di un Nexus 9000 VXLAN Multisite TRM con DCNM

Introduzione

Questo documento spiega come implementare un Cisco Nexus 9000 VXLAN Multisite TRM Fabric con gateway bordo connessi tramite switch DCI

Topologia

Dettagli della topologia

• DC1 e DC2 sono due posizioni del centro dati che eseguono VXLAN.
• I gateway di frontiera DC1 e DC2 sono collegati tra loro tramite switch DCI.
• Gli switch DCI non eseguono alcuna VXLAN; Questi eseguono eBGP per l'underlay per la raggiungibilità da DC1 a DC2 e viceversa. Anche gli switch DCI sono configurati con il tenant vrf; In questo esempio, sarebbe vrf- "tenant-1".
• Gli switch DCI si connettono anche a reti esterne non VXLAN.
• Le connessioni VRFLITE sono terminate sui gateway di confine (supporto della coesistenza delle funzioni VRFLITE e Border Gateway è iniziato da NXOS-9.3(3) e DCNM-11.3(1))
• Border Gateway sono operativi in modalità Anycast; Quando si esegue TRM(Tenant Routed Multicast) su questa versione, i gateway del bordo non possono essere configurati come vPC (per altre limitazioni, fare riferimento alla guida alla configurazione di TRM multisito)
• Per questa topologia, tutti gli switch BGW hanno due connessioni fisiche verso ciascuno degli switch DCI; Un collegamento sarà nel VRF predefinito (che verrà utilizzato per il traffico tra siti) e l'altro collegamento sarà nel tenant VRF-1 che viene utilizzato per estendere VFLITE all'ambiente non vxlan.

Dettagli PIM/Multicast (specifici di TRM)

• L'RP PIM sottostante per entrambi i siti sono gli switch Spine e Loopback254 è configurato per lo stesso. L'RP PIM sottostante viene utilizzato in modo che i VTEP possano inviare i registri PIM e i join PIM ai dorsi (ai fini della replica del traffico BUM per vari VNID)
• Per TRM, RP può essere specificato con diversi mezzi; Ai fini del documento, PIM RP è il router principale nella parte superiore della topologia, esterna al fabric VXLAN. 
• Tutti i VTEP avranno il router principale indicato come PIM RP configurato nei rispettivi VRF
• DC1-Host1 sta inviando il multicast al gruppo- 239.144.144.144; DC2-Host1 è il ricevitore per questo gruppo in DC2 e anche un host esterno (172.17.100.100) alla vxlan sta effettuando la sottoscrizione a questo gruppo
• DC2-Host1 sta inviando il multicast al gruppo- 239.145.145.145; DC1-Host1 è il ricevitore per questo gruppo in DC1 e anche un host esterno (172.17.100.100) alla vxlan sta effettuando la sottoscrizione a questo gruppo
• DC2-Host2 si trova nella Vlan 144 e riceve i dati per i gruppi multicast - 239.144.144.144 e 239.100.100.100
• L'host esterno (172.17.100.100) sta inviando il traffico per il quale sia DC1-Host1 che DC2-Host1 sono ricevitori.
• Sono inclusi i flussi di traffico East/West Inter e Intra Vlan e multicast North/South

Componenti usati

• Switch Nexus 9k con versione 9.3(3)
• DCNM con versione 11.3(1)

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Passi di alto livello

1) Considerando che questo documento si basa su due controller di dominio che utilizzano la funzionalità multisito VXLAN, è necessario creare due fabric semplici

2) Creare MSD e spostare DC1 e DC2

3) Creazione di un fabric esterno e aggiunta di switch DCI

4) Creazione della sovrapposizione e della sovrapposizione multisito

5) Creazione di allegati di estensione VRF su gateway di confine

6) Verifica del traffico unicast

7) Verifica del traffico multicast

Passaggio 1: Creazione di Easy Fabric per DC1

• Accedere a DCNM e dal dashboard selezionare l'opzione-> "Fabric Builder"

• Selezionare l'opzione "Create Fabric"

• Fornire quindi il nome del fabric, il modello e nella scheda "Generale" compilare l'ASN pertinente, la numerazione dell'interfaccia fabric, Any Cast Gateway MAC(AGM)

# AGM viene utilizzato dagli host nell'infrastruttura come indirizzo MAC del gateway predefinito. Questo sarà lo stesso su tutti gli switch foglia (poiché tutti gli switch foglia all'interno del fabric eseguono anycast Fabric Forwarding). L'indirizzo IP del gateway predefinito e l'indirizzo MAC saranno gli stessi su tutti gli switch foglia

• Impostare la modalità di replica

# La modalità di replica per questo scopo del documento è Multicast; In alternativa è possibile utilizzare la replica in ingresso

# La subnet del gruppo multicast sarà il gruppo multicast utilizzato dai VTEP per replicare il traffico BUM (come le richieste ARP)

# È necessario abilitare la casella di controllo "Abilita il multicast di routing del tenant (TRM)"

# Popolare altre caselle come richiesto.

• La scheda per vPC non viene modificata poiché la topologia non utilizza alcun vPC
• Accanto è visualizzata la scheda Protocolli

# Modificare le caselle in base alle esigenze.

• Scheda Avanzate

# Per questo scopo del documento, tutti i campi sono lasciati in posizione predefinita.

# ASN viene inserito automaticamente da quello fornito nella scheda Generale

• Quindi riempire i campi nella scheda "Risorse"

# L'intervallo IP di loopback del routing per underlay è quello utilizzato per protocolli come BGP, OSPF

# L'intervallo IP di loopback VTEP sottostante è quello che verrà utilizzato per l'interfaccia NVE.

# L'RP di underlay è per l'RP PIM utilizzato per i gruppi multicast BUM.

• Compilare le altre schede con le informazioni pertinenti e quindi "salvare"

Passaggio 2: Creazione di Easy Fabric per DC2

• Eseguire la stessa operazione descritta al passaggio 1 per creare un'infrastruttura semplice per CD2
• Assicurarsi di specificare un blocco di indirizzi IP diverso in Risorse per NVE e Loopback di routing e in qualsiasi altra area pertinente
• Anche gli ASN devono essere diversi
• I VNID di livello 2 e 2 sono uguali

Passaggio 3: Creazione di MSD per multisito

• È necessario creare un fabric MSD come illustrato di seguito.

• Compilare anche la scheda DCI 

# Sovrapposizione multisito Il metodo di distribuzione IFC è "Direct_To_BGWS", in quanto i DC1-BGW formano la connessione di sovrapposizione con i DC2-BGW. Gli switch DCI mostrati nella topologia sono solo dispositivi di transito di layer 3 (e VRFLITE)

• Il passo successivo consiste nel menzionare l'intervallo di loopback multisito (questo indirizzo IP verrà utilizzato come indirizzo IP di loopback multisito su CD1 e CD2 BGW; DC1-BGW1 e DC1-BGW2 condividono lo stesso IP di loopback multisito; DC2-BGW1 e DC2-BGW2 condividono lo stesso IP di loopback multisito, ma saranno diversi da quelli dei DC1-BGW

# Dopo aver compilato i campi, fare clic su "save" (salva).

# Una volta completati i passaggi da 1 a 3, la pagina Fabric Builder avrà l'aspetto seguente.

Passaggio 4: Spostamento di fabric DC1 e DC2 in MSD multisito

# In questo passaggio, i fabric DC1 e DC2 vengono spostati su Multisite-MSD, creato al passaggio 3. Di seguito sono riportate le schermate su come ottenere lo stesso risultato.

# Selezionare l'MSD, fare clic su "sposta fabric" e selezionare CD1 e CD2 uno alla volta, quindi "aggiungi".

# Una volta spostati entrambi i fabric, la home page sarà simile a quella riportata di seguito

# Multisite-MSD visualizzerà DC1 e DC2 come fabric membro

Passaggio 5: Creazione di VRF

# La creazione di VRF può essere eseguita dal fabric MSD che sarà applicabile a entrambi i fabric. Di seguito sono riportati gli screenshot per ottenere lo stesso risultato.

# Compilare anche la scheda Avanzate e quindi "creare"

Passaggio 6: Creazione di reti

# Creazione di Vlan e VNID corrispondenti, le SVI possono essere eseguite dal fabric MSD che sarà applicabile a entrambi i fabric.

# Nella scheda "Avanzate", selezionare la casella di controllo se i BGW devono essere il gateway per le reti

# Dopo aver compilato tutti i campi, fare clic su "Crea rete"

# Ripetizione degli stessi passaggi su altre Vlan/reti

Passaggio 7: Creazione di un fabric esterno per gli switch DCI

# In questo esempio vengono presi in considerazione gli switch DCI che si trovano nel percorso del pacchetto da DC1 a DC2 (per quanto riguarda la comunicazione tra siti) che in genere si verifica quando sono presenti più di 2 fabric. 

# External Fabric includerà i due switch DCI in cima alla topologia mostrata all'inizio di questo documento

# Creazione dell'infrastruttura con il modello "esterno" e specificazione dell'ASN

# Modifica di altri campi rilevanti per la distribuzione

Passaggio 8: Aggiunta di switch in ciascun fabric

# Qui, tutti gli switch per struttura verranno aggiunti al rispettivo fabric.

La procedura per aggiungere switch è mostrata negli screenshot seguenti.

# Se "Preserva configurazione" è "NO"; qualsiasi configurazione di switch presente verrà cancellata; L'eccezione è il nome host, la variabile di avvio, l'indirizzo IP MGMT0 e la route nella gestione del contesto VRF

# Impostazione corretta dei ruoli sugli switch (facendo clic con il pulsante destro del mouse sullo switch, impostando il ruolo e quindi il ruolo rilevante)

# Disporre il layout degli switch in modo appropriato e fare clic su "salva layout"

Passaggio 9: Impostazioni TRM per singoli fabric

• Il passaggio successivo consiste nell'attivare le caselle di controllo TRM su ciascun fabric

# Esecuzione di questo passaggio per tutte le reti per tutte le infrastrutture.

• Al termine, per apportare alcune modifiche e aggiungere informazioni, è necessario utilizzare anche i VRF nei singoli fabric, come indicato di seguito.

# Questa operazione deve essere eseguita anche su DC1 e DC2 per la sezione VRF.

# Notare che il gruppo multicast per VRF-> 239.1.2.100 è stato modificato manualmente da quello popolato automaticamente; È buona norma utilizzare un gruppo diverso per il VNI VRF di layer 3 e per qualsiasi gruppo multicast di traffico BUM di VLAN L2

Passaggio 10: Configurazione VFLITE su gateway di confine

# A partire da NXOS 9.3(3) e DCNM 11.3(1), i Border Gateway possono fungere da Border Gateway e da punto di connettività VRFLITE (consentendo al Border Gateway di avere un router esterno VRFLITE e ai dispositivi esterni di comunicare con i dispositivi della struttura)

# Ai fini di questo documento, i gateway di confine stanno formando un vicinato VFLITE con il router DCI che si trova a nord della topologia mostrata sopra. 

# Da notare che: I collegamenti VFLITE e Sottolineato multisito non possono essere gli stessi collegamenti fisici. I collegamenti separati dovranno essere suddivisi per formare il sottostrato virtualizzato e multisito

# Le schermate che seguono illustrano come ottenere sia VRF LITE che estensioni multisito su Border Gateway.

# Passa alla "visualizzazione tabulare"

# Spostarsi nella scheda "links" e aggiungere un collegamento "inter-fabric VFLITE". Sarà necessario specificare il fabric di origine come DC1 e il fabric di destinazione come DCI

# Selezione dell'interfaccia corretta per l'interfaccia di origine che porta allo switch DCI corretto

# in profilo collegamento, fornire gli indirizzi IP locale e remoto

# Abilitare anche la casella di controllo- "flag di distribuzione automatica" in modo che anche la configurazione degli switch DCI per VFLITE venga popolata automaticamente (questa operazione verrà effettuata in un passaggio successivo)

N. ASN popolati automaticamente

# Dopo aver inserito le informazioni corrette in tutti i campi, fare clic sul pulsante "salva"

• Il passaggio precedente dovrà essere eseguito su tutte le connessioni BGW-DCI sui 4 gateway di confine verso i due switch DCI.
• Considerando la topologia di questo documento, ci saranno in totale 8 connessioni VRF LITE tra fabric e avrà l'aspetto seguente.

Passaggio 11: Configurazione della sovrapposizione multisito sui gateway di confine

# Il passaggio successivo consiste nella configurazione della sovrapposizione multisito su ogni Border Gateway di ciascun fabric.

# A questo scopo, saranno necessari collegamenti fisici separati dai BGW agli switch DCI. I collegamenti utilizzati per VFLITE nel passaggio 10 non possono essere utilizzati per la sovrapposizione multisito

# Queste interfacce faranno parte del "vrf predefinito", a differenza della precedente in cui le interfacce faranno parte del tenant vrf (questo esempio è tenant-1)

# Le schermate seguenti consentono di eseguire in modo semplificato i passaggi necessari per eseguire questa configurazione.

# Sarà necessario eseguire lo stesso passaggio per tutte le connessioni dai BGW agli switch DCI

# Alla fine, un totale di 8 connessioni di intreccio multisito tra fabric sarà visto come di seguito.

Passaggio 12: Impostazioni sovrapposizione multisito per TRM

# Una volta completata la sovrapposizione multisito, le interfacce/i collegamenti della sovrapposizione multisito vengono popolati automaticamente e possono essere visualizzati nella vista tabulare sotto i collegamenti all'interno della struttura MSD multisito.

# Per impostazione predefinita, la sovrapposizione multisito formerà solo il vicinato bgp l2vpn evpn da ogni sito BGW all'altro necessario per la comunicazione unicast da un sito all'altro. Tuttavia, quando è necessario eseguire il multicast tra i siti (connessi dalla funzionalità multisito vxlan), è necessario abilitare la casella di controllo TRM come mostrato di seguito per tutte le interfacce di overlay all'interno di Multisite MSD Fabric. Nelle schermate verrà illustrato come eseguire questa operazione.

Passaggio 13: Salvataggio/installazione in MSD e su singoli fabric

# Esecuzione di un'operazione di salvataggio/distribuzione che eseguirà il push delle configurazioni pertinenti in base ai passaggi precedenti

# Quando si seleziona MSD, le configurazioni da sottoporre a push saranno applicabili solo per i Border Gateway.

# Di conseguenza, è necessario salvare/installare per i singoli fabric, il che spingerà le relative configurazioni su tutti i normali Leaf switch/VTEP

Passaggio 14: Allegati di estensione VRF per MSD

# Selezionare la scheda MSD e andare alla sezione VRF

# L'opzione Extend deve essere "MULTISITE+VRF_LITE", come in questo documento, la funzionalità border Gateway e la VRFLITE sono integrate sugli switch Border Gateway.

# AUTO_VRF_LITE verrà impostato su true

# PEER VRF NAME dovrà essere compilato manualmente per tutti gli 8 switch, come mostrato di seguito, dai BGW agli switch DCI (in questo esempio viene utilizzato lo stesso NOME VRF sugli switch DCI)

# Al termine, fare clic su "salva"

# Durante la creazione delle estensioni VRF, solo i gateway della scheda dispongono di configurazioni aggiuntive per gli switch VFLITE DCI

# Di conseguenza, le foglie normali dovranno essere selezionate separatamente e poi fare clic sulle "caselle di controllo" per ogni VRF tenant come mostrato sopra.

# Fare clic su Deploy per eseguire il push delle configurazioni

Passaggio 15: Push delle configurazioni di rete nel fabric da MSD

# Selezione delle reti rilevanti all'interno dell'infrastruttura MSD 

# Notare che al momento sono selezionati solo i Border Gateway; Procedere allo stesso modo e selezionare gli interruttori a foglia regolare/VTEP-> DC1-VTEP e DC2-VTEP in questo caso.

# Al termine, fare clic su "deploy" (distribuzione) (per eseguire il push delle configurazioni su tutti e 6 gli switch indicati sopra)

Passaggio 16: Verifica di VRF e reti su tutti i VRF

# Questo passaggio consente di verificare se il VRF e le reti sono visualizzati come "Distribuiti" su tutti i fabric; se viene visualizzato come in sospeso, assicurarsi di "distribuire" le configurazioni.

Passaggio 17: Distribuzione delle configurazioni su fabric esterno

# Questo passaggio è necessario per trasferire tutte le configurazioni BGP, VFLITE e di indirizzamento IP sugli switch DCI.

# A tale scopo, selezionare la struttura esterna e fare clic su "save & Deploy"

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     

# Una volta implementato, vedremo 4 quartieri BGP IPv4 da ogni switch DCI a tutti i BGW e 4 quartieri BGP IPv4 VRF (che è per il tenant VRF EXtension)

Passaggio 18: Configurazione di iBGP tra switch DCI

# Considerando che gli switch DCI sono collegati tra loro, un protocollo iBGP IPv4 adiacente è ideale in modo che se si interrompe una connessione a valle sullo switch DCI-1, il traffico da nord a sud può comunque essere inoltrato tramite DCI-2

# Per questa operazione, è richiesta una relazione di vicinato IPv4 iBGP tra gli switch DCI e l'uso dell'hop successivo su entrambi i lati. 

# Per ottenere questo risultato, è necessario eseguire lo spin-up di una figura a mano libera sugli switch DCI. Le linee di configurazione richieste sono le seguenti.

# Gli switch DCI nella topologia sopra indicata sono configurati in vPC; quindi, l'SVI di backup può essere utilizzato per costruire iBGP Neighborships

# Selezionare il fabric DCI e fare clic con il pulsante destro del mouse su ciascuno switch e selezionare "visualizza/modifica criteri"

# Effettuare la stessa modifica sullo switch DCI-2, quindi selezionare "save&Deploy" per trasferire le configurazioni effettive sugli switch DCI

# Al termine, è possibile eseguire la verifica CLI utilizzando il comando seguente.

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

Passaggio 19: Verifica dei quartieri IGP/BGP

Vicini OSPF

# Poiché in questo esempio l'IGP Underlay è OSPF, tutti i VTEP formeranno il vicinato OSPF con gli spine e questo include anche gli switch BGW in un unico sito.

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

# Tutti i loopback (ID router BGP, loopback NVE) vengono pubblicizzati in OSPF; Pertanto, all'interno di un fabric, tutti i loopback vengono appresi tramite il protocollo di routing OSPF che contribuirebbe a formare ulteriormente il vicinato evpn l2vpn

Villaggi BGP

# All'interno di una struttura, questa topologia disporrà di quartieri evpn l2vpn dagli spine ai VTEP regolari e anche ai Border Gateway.

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 che si tratta di una distribuzione multisito con peer Border Gateway da un sito all'altro utilizzando eBGP l2vpn evpn, lo stesso può essere verificato utilizzando il comando riportato di seguito su uno switch Border Gateway.

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     

Neighborship BGP MVPN per TRM

# Con le configurazioni TRM attivate, tutti gli switch Leaf (inclusi i BGW) formeranno una relazione mvpn con le spine

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    

# Inoltre, i Border Gateway devono formare il vicinato mvpn tra di loro in modo che il traffico multicast est/ovest attraversi correttamente.

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  

Passaggio 20: Creazione di loopback VRF tenant sugli switch Border Gateway

# Creazione di loopback nel VRF tenant con indirizzi IP univoci su tutti i gateway di confine.

# A tale scopo, selezionare DC1, fare clic con il pulsante destro del mouse su DC1-BGW1, gestire le interfacce e creare il loopback come mostrato di seguito.

# Lo stesso passaggio dovrà essere eseguito sugli altri 3 gateway di confine.

Passaggio 21: Configurazioni VFLITE sugli switch DCI

# In questa topologia, gli switch DCI sono configurati con VFLITE verso i BGW. Verflite è configurato anche per la parte settentrionale degli switch DCI (ossia per gli switch Core)

# Per scopi TRM, il PIM RP all'interno del tenant VRF-1 si trova nello switch core collegato tramite VRFLITE agli switch DCI

# Questa topologia presenta una affinità IPv4 BGP tra gli switch DCI e lo switch Core nel tenant VRF-1, che si trova nella parte superiore del diagramma.

# A questo scopo, vengono create e assegnate sottointerfacce con indirizzi IP e vengono stabilite anche le relazioni BGP (queste operazioni vengono effettuate dalla CLI direttamente sugli switch DCI e Core)

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

# In rosso, sopra è riportato il router BGP adiacente verso lo switch Core da 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

# Sono necessarie configurazioni BGP corrispondenti anche sullo switch Core (si torna a DCI-1 e DCI-2)

Verifiche unicast

Est/Ovest da DC1-Host1 a DC2-Host1

# Con tutte le configurazioni di cui sopra inserite da DCNM e CLI manuale (fasi da 1 a 21), la raggiungibilità unicast dovrebbe funzionare East/West

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

Nord/Sud da 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

Verifiche Multicast

Ai fini del presente documento, il PIM RP per il VRF "tenant-1" è configurato e presente all'esterno del fabric VXLAN; In base alla topologia, il PIM RP è configurato sullo switch Core con l'indirizzo IP-> 10.200.200.100

Origine in non vxlan(dietro switch core), ricevitore in DC2

Fare riferimento alla sezione Topologia visualizzata all'inizio.

# Traffico multicast nord/sud proveniente da host non VXLAN-> 172.17.100.100, il ricevitore è presente in entrambi i data center; DC1-Host1-> 172.16.144.1 e DC2-Host1-> 172.16.144.2, Group -> 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

Sorgente in DC1, ricevitore in DC2 e

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 ---

Sorgente in DC2, ricevitore in DC1 e

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 ---