Hej, Habr. Just nu Àr jag kursledare för "NÀtverksingenjör" pÄ OTUS.
Inför starten av det nya kursutbudet , jag har förberett en serie artiklar om VxLAN EVPN-teknologi.
Det finns ett stort antal material om VxLAN EVPN, sÄ jag vill samla olika uppgifter och metoder för att lösa problem i moderna datacenter.
I den första delen av serien om VxLAN EVPN-teknologi vill jag undersöka hur man organiserar L2-anknytning mellan vÀrdar ovanpÄ nÀtverksfabriken.
Alla exempel kommer att utföras pÄ Cisco Nexus 9000v, byggda i en Spine-Leaf-topologi. Vi kommer inte att stanna upp vid installationen av Underlay-nÀtverket i denna artikel.
- Underlay-nÀtverk
- BGP-peering för address-family l2vpn evpn
- Konfigurera NVE
- Suppression-arp
Underlay-nÀtverk
Den anvÀnda topologin ser ut som följer:
LÄt oss sÀtta adresseringen pÄ alla enheter:
Spine-1 - 10.255.1.101
Spine-2 - 10.255.1.102
Leaf-11 - 10.255.1.11
Leaf-12 - 10.255.1.12
Leaf-21 - 10.255.1.21
Host-1 - 192.168.10.10
Host-2 - 192.168.10.20LĂ„t oss kontrollera om det finns IP-anknytning mellan alla enheter:
Leaf21# sh ip route
10.255.1.11/32, ubest/mbest: 2/0 ! Leaf-11 Àr tillgÀnglig via tvÄ Spine
*via 10.255.1.101, Eth1/4, [110/81], 00:00:03, ospf-UNDERLAY, intra
*via 10.255.1.102, Eth1/3, [110/81], 00:00:03, ospf-UNDERLAY, intra
10.255.1.12/32, ubest/mbest: 2/0 ! Leaf-12 Àr tillgÀnglig via tvÄ Spine
*via 10.255.1.101, Eth1/4, [110/81], 00:00:03, ospf-UNDERLAY, intra
*via 10.255.1.102, Eth1/3, [110/81], 00:00:03, ospf-UNDERLAY, intra
10.255.1.21/32, ubest/mbest: 2/0, attached
*via 10.255.1.22, Lo0, [0/0], 00:02:20, local
*via 10.255.1.22, Lo0, [0/0], 00:02:20, direct
10.255.1.101/32, ubest/mbest: 1/0
*via 10.255.1.101, Eth1/4, [110/41], 00:00:06, ospf-UNDERLAY, intra
10.255.1.102/32, ubest/mbest: 1/0
*via 10.255.1.102, Eth1/3, [110/41], 00:00:03, ospf-UNDERLAY, intraLÄt oss kontrollera att VPC-domen Àr skapad och att bÄda switcharna har passerat konsistenskontrollen och att konfigurationerna pÄ bÄda noderna Àr identiska:
Leaf11# show vpc
vPC domain id : 1
Peer status : peer adjacency formed ok
vPC keep-alive status : peer is alive
Configuration consistency status : success
Per-vlan consistency status : success
Type-2 consistency status : success
vPC role : primary
Number of vPCs configured : 0
Peer Gateway : Disabled
Dual-active excluded VLANs : -
Graceful Consistency Check : Enabled
Auto-recovery status : Disabled
Delay-restore status : Timer is off.(timeout = 30s)
Delay-restore SVI status : Timer is off.(timeout = 10s)
Operational Layer3 Peer-router : Disabled
vPC status
----------------------------------------------------------------------------
Id Port Status Consistency Reason Active vlans
-- ------------ ------ ----------- ------ ---------------
5 Po5 up success success 1BGP-peering
Till sist kan vi gÄ vidare med konfigurationen av Overlay-nÀtverket.
I denna artikel Àr det nödvÀndigt att organisera ett nÀtverk mellan vÀrdarna, som visas i schemat nedan:
För att konfigurera Overlay-nÀtverket mÄste vi aktivera BGP med stöd för l2vpn evpn-slÀktet pÄ Spine- och Leaf-switchar.
feature bgp
nv overlay evpnDÀrefter mÄste vi konfigurera BGP-peering mellan Leaf och Spine. För att förenkla konfigurationen och optimera spridningen av routinginformation, stÀller vi in Spine som Route-Reflector-server. Vi kommer att ange alla Leaf i konfigurationen med hjÀlp av mallar för att optimera instÀllningen.
DÀrför ser instÀllningarna pÄ Spine ut sÄ hÀr:
router bgp 65001
template peer LEAF
remote-as 65001
update-source loopback0
address-family l2vpn evpn
send-community
send-community extended
route-reflector-client
neighbor 10.255.1.11
inherit peer LEAF
neighbor 10.255.1.12
inherit peer LEAF
neighbor 10.255.1.21
inherit peer LEAFInstÀllningen pÄ Leaf-switchen ser liknande ut:
router bgp 65001
template peer SPINE
remote-as 65001
update-source loopback0
address-family l2vpn evpn
send-community
send-community extended
neighbor 10.255.1.101
inherit peer SPINE
neighbor 10.255.1.102
inherit peer SPINEPĂ„ Spine kontrollerar vi peerandet med alla Leaf-switchar:
Spine1# sh bgp l2vpn evpn summary
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.255.1.11 4 65001 7 8 6 0 0 00:01:45 0
10.255.1.12 4 65001 7 7 6 0 0 00:01:16 0
10.255.1.21 4 65001 7 7 6 0 0 00:01:01 0Som vi ser finns det inga problem med BGP. LÄt oss gÄ vidare till konfigurationen av VxLAN. Den fortsatta konfigurationen kommer att utföras endast pÄ Leaf-switcharna. Spine fungerar endast som kÀrnnÀt och hanterar enbart trafiköverföringen. Allt arbete med inkapsling och vÀgval sker endast pÄ Leaf-switcharna.
Konfigurera NVE
NVE â nĂ€tverksvirtualiseringsgrĂ€nssnitt
Innan vi börjar konfigurera, lÄt oss introducera lite terminologi:
VTEP â Virtual Tunnel End Point, en enhet dĂ€r VxLAN-tunneln börjar eller slutar. VTEP behöver inte vara en nĂ€tverksenhet. Det kan ocksĂ„ vara en server som stöder VxLAN-teknologi. I vĂ„r topologi fungerar alla Leaf-switchar som VTEP.
VNI â Virtual Network Index â identifierare för nĂ€tverket inom ramen för VxLAN. Man kan dra en parallell till VLAN. Det finns dock vissa skillnader. NĂ€r man anvĂ€nder fabriken blir VLAN unika endast inom ramen för en Leaf-switch och överförs inte över nĂ€tverket. Men varje VLAN kan associeras med ett VNI-nummer som överförs över nĂ€tverket. Hur detta ser ut och hur det kan anvĂ€ndas kommer vi att diskutera nedan.
LÄt oss aktivera funktionen för VxLAN-teknologin och möjligheten att associera VLAN-nummer med VNI-nummer:
feature nv overlay
feature vn-segment-vlan-basedVi stÀller in NVE-grÀnssnittet som ansvarar för VxLAN. Detta grÀnssnitt ansvarar för inkapslingen av ramar i VxLAN-rubriker. Man kan dra en parallell till Tunnel-grÀnssnittet för att arbeta med GRE:
interface nve1
no shutdown
host-reachability protocol bgp ! vi anvÀnder BGP för att överföra ruttinformation
source-interface loopback0 ! grÀnssnittet frÄn vilket vi skickar paket loopback0PÄ Leaf-21-switchar skapas allt utan problem. Men om vi kontrollerar utdata frÄn kommandot show nve peers, kommer det att vara tomt. HÀr mÄste vi ÄtervÀnda till konfigurationen av VPC. Vi ser att Leaf-11 och Leaf-12 arbetar i par och Àr kopplade via VPC-domÀnen. HÀr ser vi följande situation:
Host-2 skickar en ram mot Leaf-21 sÄ att den kan vidarebefordra den i nÀtet mot Host-1. Men Leaf-21 ser att MAC-adressen för Host-1 Àr tillgÀnglig via tvÄ VTEP. Hur ska Leaf-21 agera i detta fall? Det betyder att en loop kan ha uppstÄtt i nÀtet.
För att lösa denna situation behöver Leaf-11 och Leaf-12 inom fabriken ocksÄ agera som en enhet. Detta kan lösas ganska enkelt. PÄ Loopback-grÀnssnittet frÄn vilket vi bygger tunneln lÀgger vi till en sekundÀr adress. Den sekundÀra adressen ska vara densamma pÄ bÄda VTEP.
interface loopback0
ip add 10.255.1.10/32 secondarySÄ frÄn andra VTEP:s synvinkel fÄr vi följande topologi:
Det betyder att tunneln nu kommer att byggas mellan IP-adressen Leaf-21 och den virtuella IP-adressen mellan Leaf-11 och Leaf-12. Nu kommer det inte att uppstÄ nÄgra problem med att lÀra sig MAC-adressen frÄn de tvÄ enheterna, och trafiken kan övergÄ frÄn en VTEP till en annan. Vilken av de tvÄ VTEP som hanterar trafiken avgörs med hjÀlp av routingtabeln pÄ Spine:
Spine1# sh ip route
10.255.1.10/32, ubest/mbest: 2/0
*via 10.255.1.11, Eth1/1, [110/41], 1d01h, ospf-UNDERLAY, intra
*via 10.255.1.12, Eth1/2, [110/41], 1d01h, ospf-UNDERLAY, intra
10.255.1.11/32, ubest/mbest: 1/0
*via 10.255.1.11, Eth1/1, [110/41], 1d22h, ospf-UNDERLAY, intra
10.255.1.12/32, ubest/mbest: 1/0
*via 10.255.1.12, Eth1/2, [110/41], 1d01h, ospf-UNDERLAY, intraSom man kan se ovan Àr adressen 10.255.1.10 tillgÀnglig via tvÄ Next-hop.
I det hÀr skedet har vi förstÄtt grundlÀggande sammanlÀnkning. LÄt oss gÄ vidare till konfigurationen av NVE-grÀnssnittet:
Vi aktiverar omedelbart Vlan 10 och kopplar det till VNI 10000 pÄ varje Leaf för vÀrdarna. Vi stÀller in en L2-tunnel mellan vÀrdarna.
vlan 10 ! Aktiverar VLAN pÄ alla VTEP anslutna till nödvÀndiga vÀrdar
vn-segment 10000 ! Kopplar VLAN till VNI-nummret
interface nve1
member vni 10000 ! LÀgger till VNI 10000 för att arbeta genom NVE-grÀnssnittet. för inkapsling i VxLAN
ingress-replication protocol bgp ! Anger att vi anvÀnder BGP för att sprida information om vÀrden.Nu kontrollerar vi nve peers och tabellen för BGP EVPN:
Leaf21# sh nve peers
Interface Peer-IP State LearnType Uptime Router-Mac
--------- --------------- ----- --------- -------- -----------------
nve1 10.255.1.10 Up CP 00:00:41 n/a ! Vi ser att peer Àr tillgÀnglig frÄn sekundÀradress
Leaf11# sh bgp l2vpn evpn
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.255.1.11:32777 (L2VNI 10000) ! FrÄn vem denna l2VNI faktiskt kom
*>l[3]:[0]:[32]:[10.255.1.10]\/88 ! EVPN route-type 3 - visar vÄr granne som ocksÄ kÀnner till l2VNI10000
10.255.1.10 100 32768 i
*>i[3]:[0]:[32]:[10.255.1.20]\/88
10.255.1.20 100 0 i
* i 10.255.1.20 100 0 i
Route Distinguisher: 10.255.1.21:32777
* i[3]:[0]:[32]:[10.255.1.20]\/88
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 iOvan ser vi endast rutter av EVPN route-type 3. Denna typ av rutter berÀttar om peer(Leaf), men var Àr vÄra vÀrdar?
Det handlar om att informationen om MAC-adresserna för vÀrdarna överförs via EVPN route-type 2.
För att se vÄra vÀrdar mÄste vi konfigurera EVPN route-type 2:
evpn
vni 10000 l2
route-target import auto ! I den hÀr artikeln anvÀnder vi ett automatiskt nummer för route-target
route-target export autoLÄt oss göra en ping frÄn Host-2 till Host-1:
Firewall2# ping 192.168.10.1
PING 192.168.10.1 (192.168.10.1): 56 data bytes
36 bytes from 192.168.10.2: Destination Host Unreachable
Request 0 timed out
64 bytes from 192.168.10.1: icmp_seq=1 ttl=254 time=215.555 ms
64 bytes from 192.168.10.1: icmp_seq=2 ttl=254 time=38.756 ms
64 bytes from 192.168.10.1: icmp_seq=3 ttl=254 time=42.484 ms
64 bytes from 192.168.10.1: icmp_seq=4 ttl=254 time=40.983 msOch nedan kan vi se att routing-tabellen för BGP har fĂ„tt route-type 2 med MAC-adresserna för vĂ€rdarna â 5001.0007.0007 och 5001.0008.0007.
Leaf11# sh bgp l2vpn evpn
NĂ€tverk Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.255.1.11:32777 (L2VNI 10000)
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]\/216 ! evpn route-type 2 och mac-adress för vÀrd 1
10.255.1.10 100 32768 i
*>i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]\/216 ! evpn route-type 2 och mac-adress för vÀrd 2
* i 10.255.1.20 100 0 i
*>l[3]:[0]:[32]:[10.255.1.10]\/88
10.255.1.10 100 32768 i
Route Distinguisher: 10.255.1.21:32777
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]\/216
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 iHÀr kan vi se detaljerad information om uppdateringen dÀr vi fick information om MAC Host. Nedan visas inte hela utdata frÄn kommandot
Leaf21# sh bgp l2vpn evpn 5001.0007.0007
BGP-routingtabellinformation för VRF standard, adressfamilj L2VPN EVPN
Route Distinguisher: 10.255.1.11:32777 ! skickade uppdatering med MAC Host. Inte VPC-adress utan Leaf-adress
BGP-routingtabellpost för [2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]\/216,
version 1507
Paths: (2 tillgÀngliga, bÀsta #2)
Flags: (0x000202) (high32 00000000) pÄ xmit-listan, Àr inte i l2rib\/evpn, Àr inte i HW
Path type: internal, vÀgen Àr giltig, inte bÀsta orsaken: Grannadress, ingen mÀrkt nexthop
AS-Path: NONE, vÀgen Àr internt till AS
10.255.1.10 (metrik 81) frÄn 10.255.1.102 (10.255.1.102) ! med vem bygger vi egentligen VxLAN-tunneln
Ursprung IGP, MED inte instÀllt, lokalpref 100, vikt 0
Mottagen label 10000 ! Nummer VNI som Àr kopplat till VLAN dÀr Host finns
Extcommunity: RT:65001:10000 SOO:10.255.1.10:0 ENCAP:8 ! HÀr kan vi se att RT formatet skapades automatiskt baserat pÄ AS-nummer och VNI
Originator: 10.255.1.11 Clusterlista: 10.255.1.102LÄt oss titta pÄ hur paketen ser ut nÀr de överförs genom fabriken:
Suppress-ARP
UtmÀrkt, L2-anslutning mellan vÀrdarna finns nu, och vi skulle kunna avsluta hÀr. Men allt Àr inte sÄ enkelt. Med fÄ vÀrdar kommer inga problem att uppstÄ. Men lÄt oss förestÀlla oss en situation dÀr vi har hundratals och tusentals vÀrdar. Vilket problem kan vi stöta pÄ?
Detta problem Àr BUM (Broadcast, Unknown Unicast, Multicast) trafik. I denna artikel kommer vi att titta pÄ alternativ för att bekÀmpa broadcast-trafik.
Den huvudsakliga generatorn av Broadcast i Ethernet-nÀt Àr sjÀlva vÀrdarna via ARP-protokollet.
PĂ„ Nexus finns följande mekanism implementerad för att bekĂ€mpa ARP-förfrĂ„gningar â suppress-arp.
Funktionen fungerar pÄ följande sÀtt:
- Host-1 skickar en ARP-förfrÄgan till broadcast-adressen för sitt nÀtverk.
- FörfrĂ„gan nĂ„r Leaf-switch och istĂ€llet för att skicka denna förfrĂ„gan vidare till fabriken mot Host-2 â svarar Leaf sjĂ€lv och anger rĂ€tt IP och MAC.
SÄledes skickades inte Broadcast-förfrÄgan till fabriken. Men hur kan detta fungera om Leaf bara kÀnner till MAC-adressen?
Det Àr ganska enkelt, EVPN route-type 2 kan förutom MAC-adressen ocksÄ överföra en kombination av MAC/IP. För detta mÄste en IP-adress konfigureras pÄ VLAN för Leaf. FrÄgan uppstÄr, vilken IP ska anges? PÄ Nexus finns möjligheten att skapa en distribuerad (samma) adress pÄ alla switchar:
feature interface-vlan
fabric forwarding anycast-gateway-mac 0001.0001.0001 ! hÀr anger vi den virtuella MAC-adressen för att skapa en distribuerad gateway mellan alla switchar
interface Vlan10
no shutdown
ip address 192.168.10.254/24 ! hÀr anger vi samma IP pÄ alla Leaf
fabric forwarding mode anycast-gateway ! vi anger att vi ska anvÀnda Virtual MACSÄledes kommer nÀtverket att se ut sÄ hÀr sett ur hosts synvinkel:
LĂ„t oss kontrollera BGP l2route evpn
Leaf11# sh bgp l2vpn evpn
NĂ€tverk NĂ€sta hopp Metric LocPrf Vikt VĂ€g
Rutt Distinguisher: 10.255.1.11:32777 (L2VNI 10000)
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]/216
10.255.1.21 100 32768 i
*>i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216
10.255.1.10 100 0 i
* i 10.255.1.10 100 0 i
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.10.20]/248
10.255.1.10 100 0 i
*>i 10.255.1.10 100 0 i
Rutt Distinguisher: 10.255.1.21:32777
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 i
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.10.20]/248
*>i 10.255.1.20 100 0 iFrÄn kommandots utdata ser vi att i EVPN route-type 2 ser vi nu ocksÄ IP-adressen för vÀrden förutom MAC.
Vi ÄtervÀnder till konfigurationen av suppress-arp. Denna instÀllning aktiveras för varje VNI separat:
interface nve1
member vni 10000
suppress-arpVidare uppstÄr viss komplexitet:
- För att denna funktion ska fungera krÀvs det plats i TCAM-minnet. Jag ger ett exempel pÄ konfiguration för suppress-arp:
hardware access-list tcam region arp-ether 256För denna konfiguration krÀvs double-wide. Det vill sÀga om du anger 256, mÄste 512 frigöras i TCAM. Konfiguration av TCAM gÄr utöver ramen för denna artikel, eftersom den beror helt pÄ uppgiften framför dig och kan variera frÄn ett nÀtverk till ett annat.
- Implementeringen av suppress-arp mÄste göras pÄ alla Leaf-switchar. Men det kan uppstÄ svÄrigheter vid konfigureringen pÄ par av Leaf som befinner sig i samma VPC-domÀn. Vid Àndring av TCAM kan konsistensen mellan paren rubbas och en av noderna kan sluta fungera. Dessutom kan en omstart av enheten krÀvas för att tillÀmpa Àndringarna i TCAM.
Som resultat mÄste man noga övervÀga om det Àr vÀrt att införa denna instÀllning pÄ en fungerande fabrik i er situation.
HÀrmed avslutar vi den första delen av cykeln. I nÀsta del kommer vi att titta pÄ routning genom VxLAN-fabriken med nÀtverkssegmentering via olika VRF.
Och nu inbjuder jag alla till , dÀr jag noggrant kommer att berÀtta om kursen. De första 20 deltagarna som registrerar sig för detta webbseminarium kommer att fÄ ett certifikat med rabatt skickat till sin e-post inom 1-2 dagar efter sÀndningen.
KĂ€lla: habr.com
