Bouwen aan een Nexus 9000 VXLAN gedeelde grens-multilocatie met DCNM

Inleiding

Dit document legt uit hoe u een Cisco Nexus 9000 VXLAN multisite implementatie kunt implementeren met behulp van een gedeeld grensmodel met behulp van DCNM 11.2 versie. 

Topologie

Details van de topologie

DC1 en DC2 zijn twee datacenterlocaties die vxlan uitvoeren; 

DC1- en DC2-grensgateways beschikken over fysieke verbindingen met de gedeelde grenzen;

gedeelde grenzen hebben de externe connectiviteit (bijvoorbeeld; internet); daarom worden de VRF-lijnverbindingen op gedeelde grenzen beëindigd en wordt een standaardroute door de gedeelde grenzen naar Border Gateways in elke site ingespoten

Gedeelde grenzen worden in vPC ingesteld (dit is een vereiste wanneer de stof wordt uitgevoerd met behulp van DCNM)

Border Gateways worden geconfigureerd in Anycast-modus

Gebruikte componenten:

Nexus 9ks actief 9.3(2)

CNM met 11.2 versie

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u de potentiële impact van elke opdracht begrijpen.

Stappen op hoog niveau

1) Gezien het feit dat dit document is gebaseerd op twee datacenters die gebruik maken van de optie VLAN op meerdere locaties, moeten twee stoffen met een eenvoudige structuur worden gemaakt

2) Maak een ander makkelijk fabric voor de gedeelde grens

3) MSD maken en DC1 en DC2 verplaatsen

4) Externe fabric maken

5) Multisite Underlay en Overlay maken (voor Oost/West)

6) VRF-uitbreidingsbijlagen op gedeelde grenzen maken

Stap 1: Gemakkelijk maken voor DC1

• Meld u aan bij DCNM en selecteert u vanuit het Dashboard de optie-> "Fabric Builder"

• Selecteer de optie "tegenwoordig maken"

• Daarna moet u de weefselnaam, het sjabloon en vervolgens worden er meerdere tabbladen geopend, die details nodig hebben, zoals ASN, Fabric Interface Number en Any Cast Gateway MAC (AGM)

# Fabric-interfaces (die de spine/Leaf-interfaces zijn) kunnen worden "niet genummerd" of op punt worden gericht; Als niet genummerd wordt gebruikt, zijn de IP-adressen minder (aangezien het IP-adres dat van de niet genummerde loopback is)

# AGM wordt door de hosts in het fabric gebruikt als het standaard MAC-adres van de gateway; Dit is hetzelfde voor alle Leaf-switches die de standaardgateways zijn

• Vervolgens wordt de replicatiemodus ingesteld

# Hier geselecteerde replicatiemodus kan ofwel multicast ofwel IR-Ingraving replicatie zijn; IR zal elk inkomend BUM-verkeer binnen een VLAN-VLAN op een éénastmanier repliceren naar andere VTEP's die ook head-end replicatie worden genoemd, terwijl multicast-modus het BUM-verkeer stuurt met een IP-adres op de buitenste bestemming als dat van de multicastgroep die voor elke netwerk tot de spine is gedefinieerd en de multicast-replicatie doet die is gebaseerd op OIL van het externe IP-adres naar andere VTEP

# Multicast Groepssubster -> vereist om het BUM verkeer te repliceren (zoals ARP-verzoek van een host)

# Als TRM moet worden ingeschakeld, selecteert u het aankruisvakje tegen hetzelfde en geeft u het MDT-adres voor de TRM VRF’s op. 

• Tab voor "vPC" blijven standaard staan; Als er wijzigingen nodig zijn voor de back-up van SVI/VLAN, kunnen deze hier worden gedefinieerd
• Het tabblad Geavanceerd is de volgende sectie

# Site ID dat hier wordt genoemd is automatisch ingevuld op deze DCNM-versie die is afgeleid van de ASN die onder het tabblad "Algemeen" is gedefinieerd

# Vullen/Wijzigen van andere relevante velden

• Resources tabblad Next is het volgende dat het IP-adresseringsschema voor leningen nodig heeft, Underlayts

# Layer 2 VXLAN VNI-bereik -> Dit zijn de VPN’s die later in kaart worden gebracht in VLAN’s (dit wordt nader weergegeven)

# Layer 3 VXLAN VNI-bereik -> Dit zijn Layer 3 VPN’s die later ook in kaart worden gebracht in Layer 3 VNI-VLAN/VN-segment

• Andere tabbladen worden hier niet weergegeven. maar vult de andere tabbladen indien nodig in; 

• Wanneer u het filter opslaat, wordt op de pagina Fabric (Van DCNM-> Control-M)> Fabric Builder weergegeven

# Dit gedeelte toont de volledige lijst met stoffen, ASN en replicatiemodi voor elk van de stoffen

• De volgende stap is om switches aan de DC1 Fabric toe te voegen

Stap 2: Switches toevoegen aan het DC1 fabric

Klik op DC1 in het bovenstaande diagram en dat geeft de optie om switches toe te voegen.

• Geef IP-adressen en aanmeldingsgegevens van de switches die naar DC1 Fabric moeten worden geïmporteerd (Per topologie die in het begin van dit document wordt vermeld, maken DC1-VTEP, DC1-SPINE, DC1-BGW1 en DC1-BGW2 deel uit van DC1)

# Aangezien dit een Greenfield-toepassing is, merk op dat de optie "Conservation Config" is geselecteerd als "NEE"; die alle configuraties van de vakjes zullen wissen terwijl het de import doet en ook de switches opnieuw zal laden

# Selecteer de "Start discovery" zodat DCNM de switches beginnen te detecteren op basis van de IP-adressen die in de kolom "seed IP" zijn meegeleverd

• Zodra DCNM klaar is met het ontdekken van de switches, worden de IP-adressen samen met de hostnamen in het voorraadbeheer opgenomen

# Selecteer de relevante switches en klik op "Importeren in stof"

# Zodra de invoer wordt uitgevoerd, kan de topologie onder de weefselbouwers er als volgt uitzien;

# De switches kunnen rond worden verplaatst door op één schakelaar te klikken en de schakelaar uit te lijnen op de juiste locatie in het diagram

# Selecteer het gedeelte "Indeling opslaan" nadat u de switches in de volgorde hebt aangepast

• Rol instellen voor alle switches

# Klik met de rechtermuisknop op elk van de switches en stel de juiste rol in; Hier zijn DC1-BGW1 & DC1-BGW2 de grensgateways

# DC1-SPINE-> Wordt ingesteld op rollenbank, DC1-VTEP-> wordt ingesteld op role-Leaf

• Volgende stap is opslaan en implementeren

# DCNM zal nu een lijst van de switches maken en ook de voorbeeldweergave van de configuraties hebben die DCNM naar alle switches gaat duwen.

# Als de bewerking succesvol is, zal de status worden weergegeven en zullen de schakelaars in Groen worden weergegeven

Stap 3: Configuratie van netwerken/VRF’s

• Configuratie van netwerken/VRF’s

# Selecteer DC1 fabric (vanaf de rechtsboven), Control > VRF’s

# volgende is gemaakt van VRF

# 11.2 DCNM versie vult de VRF-ID automatisch in; Als dit iets anders is, typt u het formulier dat u nodig hebt en selecteert u "VRF maken"

# Hier wordt Layer 3 VPN gebruikt in 1001445

• De volgende stap is het maken van netwerken

# Geef de netwerkid op (dit is Layer 2 VLAN's corresponderende VPN-id)

# Vermeld de VRF dat de SVI deel moet uitmaken van; Standaard wordt de VRF-naam op DCNM 11.2 door de eerder gemaakte naam ingevuld; Indien nodig wijzigen

# VLAN-id is Layer 2 VL die aan deze specifieke VPN-ID is gekoppeld

# IPv4 gateway-> Dit is het IP-adres van de analoge gateway dat wordt ingesteld op SVI en dat hetzelfde is voor alle VTEP’s in het weefsel

• Advanced Tab heeft extra rijen die moeten worden ingevuld als u bijvoorbeeld wilt; DHCP Relay gebruikt;

#Zodra de velden ingevuld zijn, klik op "Netwerk maken".

# Maak andere netwerken die deel moeten uitmaken van deze structuur. 

• Op dit moment zijn VRF en netwerken net gedefinieerd in DCNM; maar niet geduwd van DCNM naar de switches in het weefsel. Dit kan worden geverifieerd aan de hand van onderstaande gegevens

# Status zal in "NA" zijn als dit NIET is geïmplementeerd op de switches. Aangezien dit een multisite is en grensgateways betreft, zal de invoering van netwerken/VRF’s verder worden besproken.

Stap 4: Dezelfde stappen voor DC2 herhalen

• Nu de DC1 volledig is gedefinieerd, zal ook dezelfde procedure voor DC2 worden uitgevoerd
• Als DC2 eenmaal volledig is gedefinieerd, zal het er als volgt uitzien

Stap 5: Maak een eenvoudige stof voor gedeelde grenzen

• Dit is waar een ander makkelijk weefsel gecreëerd wordt dat de gedeelde grenzen omvat die in vPC zijn
• Merk op dat de gedeelde grenzen tijdens het implementeren via DCNM als vPC zouden moeten worden geconfigureerd, anders worden de inter-switch links uitgeschakeld nadat een "resync"-handeling op DCNM is uitgevoerd
• De switches in Shared Border worden ingesteld met de rol van "Border"

# VRF’s worden ook aangemaakt zoals dat het geval is voor DC1- en DC2-stoffen

# netwerken zijn niet vereist op een gedeeld kader aangezien de gedeelde grens geen Layer 2 VLAN’s/VPN’s heeft; gedeelde grenzen zijn geen tunnelbeëindiging voor een oost-/West-verkeer van DC1 tot DC2; Alleen de Border Gateways zouden een rol in termen van VLAN insluiting/decapsulation voor Oost/West DC1<>DC2-verkeer spelen

Stap 6 - Creatie van MSD- en DC1- en DC2-stoffen

Ga naar Fabric-bouwer en maak een nieuwe fabric en gebruik de sjabloon -> MSD_Fabric_11_1

# Merk op dat de implementatiemethode voor meerdere sites IFC moet zijn "centralized_To_Route_Server"; Hier worden de gedeelde grenzen gezien als Routers en dus wordt deze optie gebruikt vanaf de uitrollijst

# in de "lijst van multisite routeservers"; Ga hier achter de Loopback IP-adressen van Loopback0 (wat de Routing loopback is) op gedeelde grens uit en vul het op

# ASN is de tabel op gedeeld kader (raadpleeg het diagram boven in dit document voor meer informatie); Voor de toepassing van dit document worden beide gedeelde grenzen in dezelfde ASN geconfigureerd; Invullen dienovereenkomstig

• Het volgende tabblad is voorzien van het IP-bereik van meerdere sites, zoals hieronder wordt getoond

# Zodra alle velden ingevuld zijn, klikt u op de knop "Opslaan" en er wordt een nieuw fabric gemaakt met de sjabloon-> MSD

# Next is om de DC1- en DC2-stoffen naar deze MSD te verplaatsen

# Als het wasgoed zich verplaatst, ziet het er hieronder uit

# Als u klaar bent, klikt u op de knop "Save&Deploy" om de vereiste configuraties voor wat betreft meerdere sites naar de grensgateways te drukken

Stap 7: Oprichting van externe fabricage

# Maak extern fabric en voeg de externe router toe zoals hieronder wordt getoond;

# naam van het weefsel en gebruik de sjabloon-> "Extern_Fabric_11_1"; 

# Geef de ASN op

# Aan het einde lijken de verschillende stoffen hieronder

Stap 8: eBGP Underlay voor loopback bereikbaarheid tussen BGWs (ook iBGP tussen gedeelde grenzen)

#Shared Border Manager OpenBGP l2VPN-VPN-router met de GRENSgateways en VRF-LITE-verbindingen naar de externe router

# Alvorens eBGP l2vpn op te stellen zonder de loopback-ups, moet ervoor worden gezorgd dat de loopbacks via een of andere methode bereikbaar zijn; In dit voorbeeld gebruiken we eBGP IPv4 AF van BGW's naar gedeelde grenzen en dan adverteren we met de mazen om de l2vpn evpn-buurt verder te vormen.

# Als het MSD-weefsel is geselecteerd, schakelt u over op "tabelweergave"

# Selecteer "inter-fabric" en gebruik de "Multisite_UNDERLAY"

# Wij zijn hier om een IPv4 BGP-burcht met de gedeelde grensrouter te vormen; Selecteer dus de switches en interfaces.

# Merk op dat als CDP de buurman van DC1-BGW1 tot SB1 detecteert, het alleen nodig is om de IP-adressen hier in deze sectie te geven en die de IP-adressen op de relevante interfaces effectief zal configureren na het uitvoeren van "save & Deployment"

# Zodra Save and implementation is geselecteerd, worden de vereiste configuratielijnen voor DC1-BGW1 verspreid; Dezelfde stap moet worden uitgevoerd nadat ook de 'gedeelde grens'-structuur is geselecteerd. 

# vanuit CLI kan hetzelfde worden geverifieerd met de onderstaande opdracht;

DC1-BGW1# show ip bgp sum
BGP summary information for VRF default, address family IPv4 Unicast
BGP router identifier 10.10.10.1, local AS number 65000
BGP table version is 11, IPv4 Unicast config peers 1, capable peers 1
2 network entries and 2 paths using 480 bytes of memory
BGP attribute entries [1/164], 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.4.10.2       4 65001       6       7       11    0    0 00:00:52 0 

# Merk op dat "save&Deployment" ook op de DC1-stof moet worden uitgevoerd (Selecteer de uitrollijst voor DC1 en voer vervolgens hetzelfde uit) zodat de relevante IP-adressering, BGP-configuraties worden gepropageerd naar de switches in DC1 (dat zijn de Border Gateways);

# Ook moet de multisite underlay worden gecreëerd van DC1-BGW's, DC2-BGW's naar gedeelde grenzen; daarom moeten dezelfde stappen als hierboven worden ondernomen .

# Aan het einde zullen de gedeelde grenzen eBGP IPv4 AF buurten hebben met alle BGW's in DC1 en DC2 zoals hieronder;

SHARED-BORDER1# 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 38, IPv4 Unicast config peers 4, capable peers 4
18 network entries and 20 paths using 4560 bytes of memory
BGP attribute entries [2/328], 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    1715    1708       38    0    0    1d03h 5         
10.4.10.6       4 65000    1461    1458       38    0    0    1d00h 5         
10.4.10.18      4 65002    1459    1457       38    0    0    1d00h 5         
10.4.10.22      4 65002    1459    1457       38    0    0    1d00h 5    

SHARED-BORDER2# 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 26, IPv4 Unicast config peers 4, capable peers 4
18 network entries and 20 paths using 4560 bytes of memory
BGP attribute entries [2/328], 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.10      4 65000    1459    1458       26    0    0    1d00h 5         
10.4.10.14      4 65000    1461    1458       26    0    0    1d00h 5         
10.4.10.26      4 65002    1459    1457       26    0    0    1d00h 5         
10.4.10.30      4 65002    1459    1457       26    0    0    1d00h 5 

# Boven is de noodzakelijke voorafgaande bouw van de l2vpn-evpn-wijk van BGW's naar gedeelde grenzen (Merk op dat deze niet verplicht is om BGP te gebruiken; elk ander mechanisme om achteruitloopprefixes uit te wisselen ) ; Aan het eind is het basisvereiste dat alle loopbacks (van gedeelde grenzen) van alle BGW's bereikbaar zouden moeten zijn

# Merk ook op dat er een iBGP IPv4 AF-wijk moet worden opgezet tussen gedeelde grenzen; Vanaf vandaag heeft DCNM geen optie om een iBGP tussen gedeelde grenzen te bouwen met behulp van een sjabloon/uitloop; Daartoe moet een configuratie van vrijevorming worden uitgevoerd, zoals hieronder wordt getoond;

# vind de IP-adressen die zijn ingesteld op Backup SVI van gedeelde grenzen; Zoals hierboven is aangegeven, wordt freeform toegevoegd aan de schakelaar Shared-border1 en is de gespecificeerde iBGP-buur die van Shared-border2(10.100.100.2)

# Merk op dat, terwijl de configuraties in de formaten in de configuratie in DCNM worden verstrekt, de juiste afstand na elke opdracht(laat zelfs aantal ruimtes achter); betekenis, na router bgp 65001, geef twee ruimtes en geef dan de buuropdracht <> enzovoort)

# zorgt er ook voor dat er een herverdeling plaatsvindt voor de directe routes (loopback-routes) in BGP of een andere vorm om de loopback-ups te adverteren; in het bovenstaande voorbeeld wordt een route-map direct aangemaakt om alle directe routes te koppelen en dan direct herverdelen binnen IPv4 AF BGP

# Zodra de configuratie is "opgeslagen en uitgevoerd" van DCNM, wordt de iBGP-buurt gevormd zoals hieronder wordt getoond;

SHARED-BORDER1# 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 57, IPv4 Unicast config peers 5, capable peers 5
18 network entries and 38 paths using 6720 bytes of memory
BGP attribute entries [4/656], 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    1745    1739       57    0    0    1d04h 5         
10.4.10.6       4 65000    1491    1489       57    0    0    1d00h 5         
10.4.10.18      4 65002    1490    1487       57    0    0    1d00h 5         
10.4.10.22      4 65002    1490    1487       57    0    0    1d00h 5         
10.100.100.2    4 65001      14       6       57    0    0 00:00:16 18 # iBGP neighborship from shared border1 to shared border2

# Met bovenstaande stap wordt de multisite onderlay volledig geconfigureerd.

# volgende stap is het bouwen van de multisite overlay;

Stap 9: Bouwen van multisite overlay van BGW’s naar gedeelde grenzen

# Merk op dat hier gedeelde grenzen ook de routeservers zijn

# Selecteer de MSD en ga dan naar de "Tabulaire weergave" waar een nieuwe link gecreëerd kan worden. Vanaf dat moment moet een nieuwe multisite overlay link worden gecreëerd en moeten de relevante IP-adressen de juiste ASN als volgt krijgen; Deze stap moet worden gezet voor alle l2VPN-buren (die van elke BGW naar elke gedeelde grens zijn)

# Above is één voorbeeld; hetzelfde voor alle andere multisite Overlay Links; aan het einde van de studie ziet de CLI er als volgt uit;

SHARED-BORDER1# sh bgp l2vpn evpn summary 
BGP summary information for VRF default, address family L2VPN EVPN
BGP router identifier 10.10.100.1, local AS number 65001
BGP table version is 8, L2VPN EVPN config peers 4, capable peers 4
1 network entries and 1 paths using 240 bytes of memory
BGP attribute entries [1/164], 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      21      19        8    0    0 00:13:52 0         
10.10.10.2      4 65000      22      20        8    0    0 00:14:14 0         
10.10.20.1      4 65002      21      19        8    0    0 00:13:56 0         
10.10.20.2      4 65002      21      19        8    0    0 00:13:39 0         

SHARED-BORDER2# sh bgp l2vpn evpn summary 
BGP summary information for VRF default, address family L2VPN EVPN
BGP router identifier 10.10.100.2, local AS number 65001
BGP table version is 8, L2VPN EVPN config peers 4, capable peers 4
1 network entries and 1 paths using 240 bytes of memory
BGP attribute entries [1/164], 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      22      20        8    0    0 00:14:11 0         
10.10.10.2      4 65000      21      19        8    0    0 00:13:42 0         
10.10.20.1      4 65002      21      19        8    0    0 00:13:45 0         
10.10.20.2      4 65002      22      20        8    0    0 00:14:15 0

Stap 10: Networks/VRF’s op beide locaties implementeren

# Aangezien wij de multisite Underlay en Overlay hebben voltooid, is de volgende stap de netwerken/VRFs op alle apparaten in te zetten;

# Starten met VRF’s op stoffen -> DC1, DC2 en gedeelde grenzen.

# Als de VRF-weergave is geselecteerd, klikt u op "Doorgaan"; Dit zal de apparaten in de topologie van een lijst maken

# Aangezien de VRF moet worden ingezet op meerdere switches (inclusief Border Gateways en Leaf), selecteert u het vak Checkbox aan de rechterkant en selecteert u vervolgens de switches die dezelfde rol in één keer hebben; bijvoorbeeld; DC1-BGW1 en DC1-BGW2 kunnen tegelijkertijd worden geselecteerd en vervolgens beide switches opslaan; Selecteer vervolgens de bladeswitches die van toepassing zijn (hier is het DC1-VTEP)

# Zoals hierboven wordt gezien, wanneer de optie "Deploy" is geselecteerd, zullen alle eerder geselecteerde switches de implementatie starten en uiteindelijk groen worden als de implementatie succesvol is.

# Dezelfde stappen moeten worden uitgevoerd voor het opzetten van netwerken;

# Als er meerdere netwerken worden gecreëerd, houd dan in gedachten om naar de volgende tabbladen te navigeren om de netwerken te selecteren voordat u deze implementeert

# De status wordt nu ingesteld op "DEPLOYED" van "NA" en de CLI van de switch hieronder kan worden gebruikt om de implementaties te controleren

DC1-VTEP# sh nve vni
Codes: CP - Control Plane        DP - Data Plane          
       UC - Unconfigured         SA - Suppress ARP        
       SU - Suppress Unknown Unicast 
       Xconn - Crossconnect      
       MS-IR - Multisite Ingress Replication
 
Interface VNI      Multicast-group   State Mode Type [BD/VRF]      Flags
--------- -------- ----------------- ----- ---- ------------------ -----
nve1      100144   239.1.1.144       Up    CP   L2 [144]                # Network1 which is VLan 144 mapped to VNID 100144
nve1      100145   239.1.1.145       Up    CP   L2 [145]                # Network2 Which is Vlan 145 mapped to VNID 100145
nve1      1001445  239.100.100.100   Up    CP   L3 [tenant-1]           # VRF- tenant1 which is mapped to VNID 1001445

DC1-BGW1# sh nve vni
Codes: CP - Control Plane        DP - Data Plane          
       UC - Unconfigured         SA - Suppress ARP        
       SU - Suppress Unknown Unicast 
       Xconn - Crossconnect      
       MS-IR - Multisite Ingress Replication
 
Interface VNI      Multicast-group   State Mode Type [BD/VRF]      Flags
--------- -------- ----------------- ----- ---- ------------------ -----
nve1      100144   239.1.1.144       Up    CP   L2 [144]           MS-IR 
nve1      100145   239.1.1.145       Up    CP   L2 [145]           MS-IR 
nve1      1001445  239.100.100.100   Up    CP   L3 [tenant-1]  

# hierboven is ook van BGW afkomstig; Om kort te gaan, alle switches die we eerder in de stap hadden geselecteerd zullen met de netwerken en VRF worden ingezet

# Dezelfde stappen moeten worden uitgevoerd voor de Fabric DC2, gedeelde grens ook. Houd in gedachten dat de gedeelde grenzen GEEN netwerken of Layer 2 VPN's vereisen; alleen L3 VRF is vereist.

Stap 11: Downloads voor Trunk/Access-poorten op Leaf-switches/VTEP

# In deze topologie zijn de poorten Eth1/2 en Eth1/1 van DC1-VTEP en DC2-VTEP respectievelijk verbonden met de hosts; Dus verplaatsen als boomstampoorten in DCNM GUI, zoals hieronder wordt getoond

# Selecteer de relevante interface en wijzig de "toegestane ventilatoren" van niets in "alle" (of alleen de ventilatoren die moeten worden toegestaan)

Stap 12: Vereiste formaten aan gedeelde grens

# Aangezien gedeelde grensschakelaars de routeservers zijn, is het vereist om enkele veranderingen door te voeren in termen van de BGP l2vpn evpn-buurten

# intersite BUM-verkeer wordt herhaald met behulp van Unicast; elk BUM-verkeer in VLAN 144 (bijvoorbeeld) nadat het op de BGW's aankomt; afhankelijk van welke BGW de Aangewezen expediteur (DF) is, zal DF een éénmalige replicatie naar externe site uitvoeren; Deze replicatie wordt bereikt nadat de BGW een type 3-route van de afstandsbediening van BGW ontvangt; Op dit punt vormen de BGW's l2VPN-netwerken, die alleen aan gemeenschappelijke grenzen werken; en gedeelde grenzen mogen geen Layer 2 VNID's hebben (indien gecreëerd, zal dit leiden tot het chanteren van Oost/West-verkeer). Aangezien Layer 2 VNID’s ontbreken en de route-type 3 afkomstig is van BGW’s per VNID, zal de gedeelde grenzen geen rekening houden met de BGP-update afkomstig van BGW’s; Om dit te repareren, gebruikt u "alle route behouden" onder het AF 2500 l2vpn-evpn

# Een ander punt is om ervoor te zorgen dat de gedeelde grenzen de volgende HOP (BGP BY default wijzigt de volgende hop voor eBGP buurtschappen) niet wijzigen; In dit geval moet de intersite-tunnel voor het eenstverkeer van locatie 1 tot en met 2 en omgekeerd van BGW tot BGW (van dc1 tot dc2 en omgekeerd) zijn; Om dit te bereiken, moet er een routekaart worden gecreëerd en toegepast voor elke 24VPN-evpn buurt vanaf de gedeelde grens met elke BGW

# Voor beide bovenstaande punten moet een freeform worden gebruikt aan gedeelde grenzen zoals hieronder

route-map direct
route-map unchanged
  set ip next-hop unchanged  
router bgp 65001
  address-family ipv4 unicast
    redistribute direct route-map direct
  address-family l2vpn evpn
    retain route-target all
  neighbor 10.100.100.2
    remote-as 65001
    address-family ipv4 unicast
      next-hop-self
  neighbor 10.10.10.1
    address-family l2vpn evpn
      route-map unchanged out
  neighbor 10.10.10.2
    address-family l2vpn evpn
      route-map unchanged out
  neighbor 10.10.20.1
    address-family l2vpn evpn
      route-map unchanged out
  neighbor 10.10.20.2
    address-family l2vpn evpn
      route-map unchanged out

Stap 13: Loopback binnen huurder VRF’s op BGW’s

# voor Noord/Zuid-verkeer van hosts die zijn aangesloten binnen de bladeswitches, gebruiken de BGW’s de buitenste SRC IP van het NVE Loopback1 IP-adres; De gedeelde grenzen zullen alleen standaard het NVE Peering met het IP-adres van de Multisite Loopback van BGW's vormen; dus als een VLAN-pakket bij het gedeelde kader met een extern SRC IP-adres van BGW Loopback1 komt, wordt het pakket vanwege de SRCTEP-Miss ingetrokken. Om dit te vermijden moet er een loopback in huurder-VRF worden gemaakt op elke BGW-schakelaar en dan aan de BGP adverteren, zodat de gedeelde grenzen deze update ontvangen en dan de NVE Peering met het BGW Loopback1 IP-adres vormen;

# Oorspronkelijk lijkt de NVE Peering hieronder op gedeelde grenzen

SHARED-BORDER1# sh nve pee
Interface Peer-IP                                 State LearnType Uptime   Router-Mac       
--------- --------------------------------------  ----- --------- -------- -----------------
nve1      10.222.222.1                            Up    CP        01:20:09 0200.0ade.de01   # Multisite Loopback 100 IP address of DC1-BGWs
nve1      10.222.222.2                            Up    CP        01:17:43 0200.0ade.de02   # Multisite Loopback 100 IP address of DC2-BGWs

# Zoals hierboven wordt getoond, wordt loopback2 gecreëerd vanuit DCNM en is het ingesteld in huurder-1 VRF en krijgt de tag van 12345 omdat dit de tag is die de routekaart gebruikt om de loopback te evenaren terwijl de advertentie wordt gemaakt

DC1-BGW1# sh run vrf tenant-1 

!Command: show running-config vrf tenant-1
!Running configuration last done at: Tue Dec 10 17:21:29 2019
!Time: Tue Dec 10 17:24:53 2019

version 9.3(2) Bios:version 07.66 

interface Vlan1445
  vrf member tenant-1

interface loopback2
  vrf member tenant-1
vrf context tenant-1
  vni 1001445
  ip pim rp-address 10.49.3.100 group-list 224.0.0.0/4
  ip pim ssm range 232.0.0.0/8
  rd auto
  address-family ipv4 unicast
    route-target both auto
    route-target both auto mvpn
    route-target both auto evpn
  address-family ipv6 unicast
    route-target both auto
    route-target both auto evpn
router bgp 65000
 vrf tenant-1
    address-family ipv4 unicast
      advertise l2vpn evpn
 redistribute direct route-map fabric-rmap-redist-subnet
      maximum-paths ibgp 2
    address-family ipv6 unicast
      advertise l2vpn evpn
      redistribute direct route-map fabric-rmap-redist-subnet
      maximum-paths ibgp 2


DC1-BGW1# sh route-map fabric-rmap-redist-subnet 
route-map fabric-rmap-redist-subnet, permit, sequence 10 
  Match clauses:
 tag: 12345 
  Set clauses:

# Na deze stap zullen de NVE peeringen voor alle Loopback1 IP adressen samen met het multisite loopback IP-adres tonen.

SHARED-BORDER1# sh nve pee
Interface Peer-IP                                 State LearnType Uptime   Router-Mac       
--------- --------------------------------------  ----- --------- -------- -----------------
nve1      192.168.20.1                            Up    CP        00:00:01 b08b.cfdc.2fd7   
nve1      10.222.222.1                            Up    CP        01:27:44 0200.0ade.de01   
nve1      192.168.10.2                            Up    CP        00:01:00 e00e.daa2.f7d9   
nve1      10.222.222.2                            Up    CP        01:25:19 0200.0ade.de02   
nve1      192.168.10.3                            Up    CP        00:01:43 6cb2.aeee.0187   
nve1      192.168.20.3                            Up    CP        00:00:28 005d.7307.8767   

# In dit stadium moet het Oost/West-verkeer correct worden doorgestuurd

Stap 14: VRFLITE-uitbreidingen van gedeelde grenzen naar de externe routers

# Er zullen situaties zijn waarin hosts buiten het weefsel met de hosts in het weefsel moeten praten. In dit voorbeeld wordt hetzelfde mogelijk gemaakt door de gedeelde grenzen; 

# Iedere host die in DC1 of DC2 woont, kan met externe hosts praten via de gedeelde grensswitches.

# Met het oog daarop worden gedeelde grenzen de VRF Lite beëindigd; Hier in dit voorbeeld wordt eBGP uitgevoerd van Gedeelde grenzen naar de Externe routers zoals in het diagram in het begin wordt getoond.

# Voor het configureren van dit formulier vanaf DCNM moet u vrf-verlengingsbijlagen toevoegen. Hieronder staan de stappen die moeten worden ondernomen om dit doel te bereiken.

a) Het toevoegen van interfabric-verbindingen van gedeelde grenzen aan externe routers

# Selecteer het bereik van de Fabric-bouwer in "gedeeld kader" en wijzig deze in tabelvorm

# Selecteer de koppelingen en voeg een link "Inter Fabric" toe zoals hieronder wordt getoond

# Een VRF LITE-subtype moet uit de uitrollijst worden geselecteerd

# Bron fabric is gedeelde grenzen en bestemmingspfabric is extern aangezien dit een VRF LITE zal zijn van SB naar extern

# Selecteer de relevante interfaces die naar de externe router gaan

# Geef het IP-adres en -masker en het IP-adres van het buuradres op.

# ASN wordt automatisch ingevuld.

# Klik op Opslaan als dit is gedaan

# voert hetzelfde uit voor zowel de gedeelde grenzen als voor alle externe laag 3 verbindingen die in VRFLITE zijn

b) toevoegen van VRF-uitbreidingen

# Ga naar het gedeelde Rand VRF-gedeelte

# VRF wordt in de stationaire toestand gebruikt; Selecteer het selectievenster rechts zodat er meerdere switches kunnen worden geselecteerd

# Selecteer het gedeelde kader en het venster "VRF EX-spanningsbijlage" wordt geopend

# Onder "extend", wijzig van "Geen" in "VRFLITE"

# Doe hetzelfde voor beide gedeelde grenzen

# Als dat is gebeurd, zullen "Extension Details" de VRF LITE-interfaces invullen die eerder in stap a) hierboven zijn gegeven.

# DOT1Q-id is automatisch ingevuld op 2

# Andere velden zijn ook automatisch ingevuld

# Als IPv6-buurte via VRFLITE moet worden gerealiseerd, moet stap a) voor IPv6 worden gedaan

Klik nu op Opslaan

# Ten slotte de "Deploy" rechtsboven op de webpagina uitvoeren.

# Een succesvolle implementatie zal resulteren in het duwen van configuraties naar de gedeelde grenzen die het instellen van IP adressen op die subinterfaces en het instellen van BGP IPv4-buurten met de externe routers

# Houd in gedachten dat de externe routerconfiguraties (het instellen van IP-adressen op subinterfaces en de BGP-buurstaten) in dit geval handmatig door CLI worden uitgevoerd.

# CLI-verificaties kunnen worden uitgevoerd door middel van onderstaande opdrachten aan beide gedeelde grenzen;

SHARED-BORDER1# sh ip bgp sum vr tenant-1 
BGP summary information for VRF tenant-1, address family IPv4 Unicast
BGP router identifier 172.16.22.1, local AS number 65001
BGP table version is 18, IPv4 Unicast config peers 1, capable peers 1
9 network entries and 11 paths using 1320 bytes of memory
BGP attribute entries [9/1476], 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
172.16.22.2     4 65100      20      20       18    0    0 00:07:59 1  

SHARED-BORDER2# sh ip bgp sum vr tenant-1 
BGP summary information for VRF tenant-1, address family IPv4 Unicast
BGP router identifier 172.16.222.1, local AS number 65001
BGP table version is 20, IPv4 Unicast config peers 1, capable peers 1
9 network entries and 11 paths using 1320 bytes of memory
BGP attribute entries [9/1476], 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
172.16.222.2    4 65100      21      21       20    0    0 00:08:02 1    

# Met alle bovenstaande configuraties wordt de Noord/Zuid-bereikbaarheid ook zoals hieronder aangegeven (pings van de externe router naar hosts in fabric)

EXT_RTR# ping 172.16.144.1                                   # 172.16.144.1 is Host in DC1 Fabric
PING 172.16.144.1 (172.16.144.1): 56 data bytes
64 bytes from 172.16.144.1: icmp_seq=0 ttl=251 time=0.95 ms
64 bytes from 172.16.144.1: icmp_seq=1 ttl=251 time=0.605 ms
64 bytes from 172.16.144.1: icmp_seq=2 ttl=251 time=0.598 ms
64 bytes from 172.16.144.1: icmp_seq=3 ttl=251 time=0.568 ms
64 bytes from 172.16.144.1: icmp_seq=4 ttl=251 time=0.66 ms
^[[A^[[A
--- 172.16.144.1 ping statistics ---
5 packets transmitted, 5 packets received, 0.00% packet loss
round-trip min/avg/max = 0.568/0.676/0.95 ms

EXT_RTR# ping 172.16.144.2                                  # 172.16.144.2 is Host in DC2 Fabric                
PING 172.16.144.2 (172.16.144.2): 56 data bytes
64 bytes from 172.16.144.2: icmp_seq=0 ttl=251 time=1.043 ms
64 bytes from 172.16.144.2: icmp_seq=1 ttl=251 time=6.125 ms
64 bytes from 172.16.144.2: icmp_seq=2 ttl=251 time=0.716 ms
64 bytes from 172.16.144.2: icmp_seq=3 ttl=251 time=3.45 ms
64 bytes from 172.16.144.2: icmp_seq=4 ttl=251 time=1.785 ms

--- 172.16.144.2 ping statistics ---
5 packets transmitted, 5 packets received, 0.00% packet loss
round-trip min/avg/max = 0.716/2.623/6.125 ms

# Traceroutes wijst ook naar de juiste apparaten in het pad van het pakket

EXT_RTR# traceroute 172.16.144.1 
traceroute to 172.16.144.1 (172.16.144.1), 30 hops max, 40 byte packets
 1  SHARED-BORDER1 (172.16.22.1)  0.914 ms  0.805 ms  0.685 ms
 2  DC1-BGW2 (172.17.10.2)  1.155 ms DC1-BGW1 (172.17.10.1)  1.06 ms  0.9 ms
 3  ANYCAST-VLAN144-IP (172.16.144.254) (AS 65000)  0.874 ms  0.712 ms  0.776 ms
 4  DC1-HOST (172.16.144.1) (AS 65000)  0.605 ms  0.578 ms  0.468 ms

EXT_RTR# traceroute 172.16.144.2
traceroute to 172.16.144.2 (172.16.144.2), 30 hops max, 40 byte packets
 1  SHARED-BORDER2 (172.16.222.1)  1.137 ms  0.68 ms  0.66 ms
 2  DC2-BGW2 (172.17.20.2)  1.196 ms DC2-BGW1 (172.17.20.1)  1.193 ms  0.903 ms
 3  ANYCAST-VLAN144-IP (172.16.144.254) (AS 65000)  1.186 ms  0.988 ms  0.966 ms
 4  172.16.144.2 (172.16.144.2) (AS 65000)  0.774 ms  0.563 ms  0.583 ms
EXT_RTR#