Hej, Habr. Jag fortsĂ€tter med cykeln av artiklar om VxLAN EVPN-teknologin som skrevs specifikt inför lanseringen av kursen frĂ„n OTUS. Idag kommer vi att titta pĂ„ en intressant del av uppgiften â ruttningsprocessen. Hur trivialt det Ă€n lĂ„ter kan det dock vara mer komplicerat i nĂ€tverksfabriken.
I den föregĂ„ende delen uppnĂ„dde vi en bredkastsdomĂ€n byggd ovanpĂ„ nĂ€tverksfabriken pĂ„ Nexus 9000v. Men detta Ă€r lĂ„ngt ifrĂ„n hela spektrumet av uppgifter som mĂ„ste lösas inom datacentret. Idag kommer vi att titta pĂ„ nĂ€sta uppgift â ruttning mellan nĂ€tverk eller mellan VNI.
Jag pÄminner om att topologin Spine-Leaf anvÀnds:
Först ska vi gÄ igenom hur ruttningsprocessen gÄr till och vilka speciella egenskaper som finns.
För att förstÄ ska vi förenkla den logiska schemat och lÀgga till Ànnu en VNI 20000 för Host-2. Resultatet blir:
Hur kan man i sÄdana fall överföra trafik frÄn en Host till en annan?
Det finns tvÄ alternativ:
- Att ha information om alla VNI pÄ alla Leaf-switchar, sÄ att all rutting sker pÄ den första Leaf i nÀtverket;
- Att anvĂ€nda en sĂ€rskild â L3 VNI
Den första metoden Àr enkel och praktisk. Eftersom det bara krÀvs att registrera alla VNI pÄ alla Leaf-switchar. Men att registrera flera hundra eller tusen VNI pÄ alla Leaf verkar inte vara en enkel uppgift. DÀrför anvÀnds den i praktiken ganska sÀllan.
Vi gÄr igenom det andra alternativet, som Àr mer intressant och lite mer komplicerat, men ger större flexibilitet vid konfigurationen av fabriken.
Vi lÀgger till VRF "PROD" i topologin. I den lÀgger vi till interface vlan 10 pÄ Leaf-11/12 och interface VLAN 20 pÄ Leaf-21. VLAN 20 kopplas till VNI 20000.
vrf context PROD
rd auto ! Route Distinguisher Àr inte avgörande och vi kan anvÀnda den automatiskt formade
address-family ipv4 unicast
route-target both auto ! vi anger route-target som prefixen kommer importeras och exporteras till/frÄn VRF
vlan 20
vn-segment 20000
interface nve 1
member vni 20000
ingress-replication protocol bgp
interface Vlan10
no shutdown
vrf member PROD
ip address 192.168.20.1/24
fabric forwarding mode anycast-gatewayFör att anvÀnda L3VNI mÄste vi skapa en ny VLAN och koppla den till en ny VNI. Den nya VNI:n mÄste vara densamma pÄ alla Leaf som Àr intresserade av information om VLAN 10 och 20.
vlan 99
vn-segment 99000
interface nve1
member vni 99000 associate-vrf ! Skapa L3 VNI
vrf context PROD
vni 99000 ! Koppla L3 VNI till en specifik VRFResultatet blir att schemat presenteras sÄ hÀr:
Det finns bara lite kvar att göra - att lÀgga till ett till interface - interface vlan 99 i VRF PROD
interface Vlan99
no shutdown
vrf member PROD
ip forward ! Det fÄr inte finnas nÄgot IP-adress pÄ interfacet. AnvÀnds endast för att vidarebefordra paket mellan LeafSlutligen Àr logiken för hur ramen passerar frÄn Host-1 till Host-2 som följer:
- Ramen som skickas frÄn Host-1 kommer till Leaf i VLAN 10, som Àr kopplat till VNI 10000;
- Leaf kontrollerar var destinationsadressen ligger och hittar den genom L3 VNI pÄ den andra Leaf-switch;
- SÄ snart vÀgen till destinationsadressen hittas, packar Leaf ramen i en rubrik med nödvÀndig L3VNI 99000 - och skickar den mot den andra Leaf;
- Den andra Leaf-switchen tar emot data frÄn L3VNI 99000. Den tar ut den ursprungliga ramen och flyttar den till det nödvÀndiga L2VNI 20000 och vidare till VLAN 20.
Resultatet av detta arbete Àr att L3VNI eliminerar behovet av att hÄlla information om alla VNI pÄ alla Leaf-switchar.
SÄ, nÀr vi skickar trafik frÄn Host-1 till Host-2 packas paketet in i VxLAN med det nya VNI - 99000:
Det ÄterstÄr att förstÄ hur Leaf-1 fÄr reda pÄ MAC-adressen frÄn ett annat VNI. Det hÀnder ocksÄ genom EVPN route-type 2 (MAC/IP).
Nedan visas processen för spridning av rutt om ett prefix som finns i ett annat VNI:
Det vill sÀga adresser som erhÄllits frÄn VNI 20000 har tvÄ RT.
Kom ihÄg att rutter som erhÄllits frÄn Update hamnar i BGP-tabellen med Route-target angiven i VRF-instÀllningarna (processen Àr nÄgot mer komplex, men vi ska inte gÄ djupare in pÄ det i denna artikel).
SjÀlva RT formuleras enligt formeln: AS:VNI (om automatisk lÀge anvÀnds).
Exempel pÄ hur RT formas i bÄde automatisk och manuell lÀge:
vrf context PROD
address-family ipv4 unicast
route-target import auto - automatiskt lÀge
route-target export 65001:20000 - manuellt lÀge för att forma RTSom syns ovan har prefixen frÄn ett annat VNI tvÄ RT-vÀrden.
Ett av dem Àr 65001:99000 - en extra L3 VNI. Eftersom detta VNI Àr detsamma pÄ alla Leaf och omfattas av vÄra importregler i VRF-instÀllningarna - hamnar prefixet i BGP-tabellen, vilket kan ses i utskriften:
sh bgp l2vpn evpn
NĂ€tverk NĂ€sta hopp Metrik LocPrf Vikt Stig
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.10 100 32768 i
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[32]:[192.168.10.10]\/272
10.255.1.10 100 32768 i
*>l[3]:[0]:[32]:[10.255.1.10]\/88
10.255.1.10 100 32768 i
Rutt Distinguisher: 10.255.1.21:32787
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.20]\/272 ! Prefix erhÄllet frÄn VNI 20000
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 iOm vi tittar noggrannare pÄ den mottagna uppdateringen, sÄ ser vi att denna prefix har tvÄ RT:
Leaf11# sh bgp l2vpn evpn 5001.0008.0007
BGP-routingtabellens information för VRF standard, adressfamilj L2VPN EVPN
Rutt Distinguisher: 10.255.1.21:32787
BGP-routingtabellspost för [2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.20]\/272, version 5164
VÀgar: (2 tillgÀngliga, bÀsta #2)
Flaggor: (0x000202) (high32 00000000) pÄ xmit-lista, finns inte i l2rib/evpn, finns inte i HW
VÀgtillstÄnd: internt, vÀgen Àr giltig, inte bÀsta orsaken: Grannadress, ingen mÀrkt nÀsta hopp
AS-VÀg: INGEN, vÀg som Àr kÀllad internt till AS
10.255.1.20 (metrik 81) frÄn 10.255.1.102 (10.255.1.102)
Ursprung IGP, MED inte instÀllt, localpref 100, vikt 0
Mottagen etikett 20000 99000 ! TvÄ etiketter för att arbeta med VxLAN
Extcommunity: RT:65001:20000 RT:65001:99000 SOO:10.255.1.20:0 ENCAP:8 ! TvÄ vÀrden Route-target, baserat pÄ vilka, denna prefix har lagts till
Router MAC:5001.0005.0007
Ursprung: 10.255.1.21 Klusterlista: 10.255.1.102I routingtabellen pÄ Leaf-1 kan vi ocksÄ observera prefixet 192.168.20.20\/32:
Leaf11# sh ip route vrf PROD
192.168.10.0\/24, ubest\/mbest: 1\/0, bifogad
*via 192.168.10.1, Vlan10, [0\/0], 01:29:28, direkt
192.168.10.1\/32, ubest\/mbest: 1\/0, bifogad
*via 192.168.10.1, Vlan10, [0\/0], 01:29:28, lokal
192.168.10.10\/32, ubest\/mbest: 1\/0, bifogad
*via 192.168.10.10, Vlan10, [190\/0], 01:27:22, hmm
192.168.20.20\/32, ubest\/mbest: 1\/0 ! Adress Host-2
*via 10.255.1.20fault, [200\/0], 01:20:20, bgp-65001, intern, tag 65001 ! TillgÀnglig via Leaf-2
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN ! Genom VNI 99000Har du mÀrkt att den primÀra prefixen 192.168.20.0\/24 saknas i routingtabellen?
Just det, den finns inte dÀr. Det vill sÀga att avlÀgsna Leaf fÄr information endast om vÀrdar som finns i ditt nÀtverk. Och det Àr korrekt beteende. Ovan i alla uppdateringar syns det att information kommer med innehÄll av MAC\/IP. Ingen diskussion om prefixen.
Det Àr protokollet Host Mobility Manager (HMM) som fyller i ARP-tabellen dÀrifrÄn BGP-tabellen fylls (i denna artikel kommer vi att utelÀmna den processen). Baserat pÄ informationen som hÀmtas frÄn HMM bildas EVPN route-type 2 (MAC\/IP överförs).
Men vad ska man göra om det finns ett behov av att överföra information om en viss prefix?
För denna typ av information finns det EVPN route-type 5 â det möjliggör överföring av prefixer via address-family l2vpn evpn (denna typ av rutter befinner sig vid tidpunkten för denna text endast i utkastversion) , vilket gör att beteendet för denna typ av rutt kan variera mellan olika tillverkare)
För att överföra prefixer Àr det nödvÀndigt att lÀgga till de prefixer som ska annonseras i BGP för VRF under processen:
router bgp 65001
vrf PROD
address-family ipv4 unicast
redistribute direct route-map VNI20000 ! HĂ€r annonserar vi prefixer kopplade direkt till Leaf i VNI 20000
route-map VNI20000 permit 10
match ip address prefix-list VNI20000_OUT ! Specificera vilken prefix-list som ska anvÀndas
ip prefix-list VNI20000_OUT seq 5 permit 192.168.20.0/24 ! Specificera vilka nÀtverk som kommer ingÄ i EVPN route-type 5Resultatet i Update kommer vara:
LÄt oss titta pÄ BGP-tabellen. Förutom EVPN route-type 2 och 3 har route-type 5 rutter kommit, som innehÄller information om nÀtverksnumret:
NĂ€tverk NĂ€sta Hopp Metrik LocPrf Vikt VĂ€g
Rutt Distinguisher: 10.255.1.11:3
* i[5]:[0]:[0]:[24]:[192.168.10.0]/224
10.255.1.10 0 100 0 ?
*>i 10.255.1.10 0 100 0 ?
Rutt Distinguisher: 10.255.1.11:32777
* i[2]:[0]:[0]:[48]:[5001.0007.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.0007.0007]:[32]:[192.168.10.10]/272
10.255.1.10 100 0 i
*>i 10.255.1.10 100 0 i
* i[3]:[0]:[32]:[10.255.1.10]/88
10.255.1.10 100 0 i
*>i 10.255.1.10 100 0 i
Rutt Distinguisher: 10.255.1.12:3
*>i[5]:[0]:[0]:[24]:[192.168.10.0]/224 ! EVPN route-type 5 med prefixnummer
10.255.1.10 0 100 0 ?
* i Prefixet har ocksÄ dykt upp i ruttningstabellen:
Leaf21# sh ip ro vrf PROD
192.168.10.0/24, ubest/mbest: 1/0
*via 10.255.1.10fault, [200/0], 00:14:32, bgp-65001, intern, tag 65001 ! AvlÀgset prefix, tillgÀngligt genom Leaf1/2 (Next-hop adress = virtuell IP mellan VPC-par)
(evpn) segid: 99000 tunnelid: 0xaff010a encap: VXLAN ! Prefixet Àr tillgÀngligt via L3VNI 99000
192.168.10.10/32, ubest/mbest: 1/0
*via 10.255.1.10fault, [200/0], 02:33:40, bgp-65001, intern, tag 65001
(evpn) segid: 99000 tunnelid: 0xaff010a encap: VXLAN
192.168.20.0/24, ubest/mbest: 1/0, kopplad
*via 192.168.20.1, Vlan20, [0/0], 02:39:44, direkt
192.168.20.1/32, ubest/mbest: 1/0, kopplad
*via 192.168.20.1, Vlan20, [0/0], 02:39:44, lokal
192.168.20.20/32, ubest/mbest: 1/0, kopplad
*via 192.168.20.20, Vlan20, [190/0], 02:35:46, hmmVi avslutar den andra delen av artikelsviten om VxLAN EVPN hÀr. I nÀsta del kommer vi att titta nÀrmare pÄ olika alternativ för ruttning mellan VRF.
KĂ€lla: habr.com
