Hej Habr. Jag fortsätter serien av artiklar om VxLAN EVPN-teknik, som skrevs speciellt för lanseringen av kursen av OTUS. Och idag kommer vi att överväga en intressant del av uppgifterna - routing. Hur banalt det än kan låta, men som en del av arbetet på en nätverksfabrik kan allt inte vara så enkelt.
I den sista delen uppnådde vi en sändningsdomän som byggdes ovanpå ett nätverkstyg på en Nexus 9000v. Detta är dock inte hela skalan av uppgifter som behöver lösas inom ramen för datacenternätverket. Och idag kommer vi att överväga följande uppgift - routing mellan nätverk eller mellan VNIs.
Låt mig påminna dig om att Spine-Leaf-topologin används:
Till att börja med kommer vi att analysera hur routing sker och vilka funktioner den har.
För förståelse, låt oss förenkla logikdiagrammet och lägga till ytterligare en VNI 20000 för Host-2. Resultatet är:
Hur kan du i det här fallet överföra trafik från en värd till en annan?
Det finns två alternativ:
- Behåll information om alla VNIs på alla Leaf-switchar, sedan kommer all routing att ske på den första Leaf i nätverket;
- Använd dedikerad - L3 VNI
Det första sättet är enkelt och bekvämt. Eftersom du bara behöver starta alla VNIs på alla Leaf-switchar. Men att köra några hundra eller tusentals VNI på hela Leaf verkar inte längre vara en lätt uppgift. Därför används det i arbetet ganska sällan.
Vi kommer att analysera metod 2, som mer intressant och lite mer komplicerad, men ger mer flexibilitet i att sätta upp fabriken.
Låt oss lägga till "PROD" till VRF-topologin. Låt oss lägga till gränssnitt vlan 10 på Leaf-11/12-paret och gränssnitt VLAN 20 på Leaf-21. VLAN 20 är associerat med VNI 20000
vrf context PROD
rd auto ! Route Distinguisher не принципиален и можем использовать сформированный автоматически
address-family ipv4 unicast
route-target both auto ! указываем Route-target с которым будут импортироваться и экспортироваться префиксы в/из 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 kunna använda L3VNI måste du skapa ett nytt VLAN, associera det med det nya VNI:et. Den nya VNI:en måste vara densamma på alla Leafs som är intresserade av VLAN 10- och 20-information.
vlan 99
vn-segment 99000
interface nve1
member vni 99000 associate-vrf ! Создаем L3 VNI
vrf context PROD
vni 99000 ! Привязываем L3 VNI к определенному VRFSom ett resultat kommer diagrammet att se ut så här:
Det återstår att avsluta lite - lägg till ett gränssnitt till - gränssnitt vlan 99 i VRF PROD
interface Vlan99
no shutdown
vrf member PROD
ip forward ! На интерфейсе не должно быть IP. Используется только для пересылки пакетов между LeafSom ett resultat är logiken för att överföra ramen från Host-1 till Host-2 som följer:
- En ram som skickas av Host-1 anländer på en Leaf i VLAN 10, som är associerad med VNI 10000;
- Leaf kontrollerar var destinationsadressen är och hittar den via L3 VNI på den andra Leaf-switchen;
- Så snart rutten till destinationsadressen hittats, packar Leaf ramen i en rubrik med den nödvändiga L3VNI 99000 - och skickar den mot den andra Leaf;
- Den andra Leaf-switchen tar emot data från L3VNI 99000. Hämtar den ursprungliga ramen och överför den till den nödvändiga L2VNI 20000 och sedan till VLAN 20.
Som ett resultat av detta arbete tar L3VNI bort behovet av att behålla information om alla VNI:er som finns i nätverket på alla Leaf-switchar.
Som ett resultat, när vi skickar trafik från Host-1 till Host-2, packas paketet inuti VxLAN med den nya VNI - 99000:
Det återstår att se hur exakt Leaf-1 lär sig om MAC-adressen från en annan VNI. Detta sker också med hjälp av EVPN route-typ 2 (MAC / IP).
Följande visar processen att sprida en rutt om ett prefix som finns i en annan VNI:
Det vill säga adresser som tas emot från VNI 20000 har två RT:er.
Låt mig påminna dig om att de rutter som tas emot från Update faller in i BGP-tabellen med Route-target som anges i VRF-inställningarna (processen är något mer komplicerad, men vi kommer inte att gå in på den här artikeln).
Själva RT bildas av formeln: AS:VNI (om automatiskt läge används).
Ett exempel på RT-bildning i automatiska och manuella lägen:
vrf context PROD
address-family ipv4 unicast
route-target import auto - автоматический режим работы
route-target export 65001:20000 - ручной режим формирования RTSom ett resultat kan du se ovan att prefix från en annan VNI har två RT-värden.
En av dem 65001:99000 är en extra L3 VNI. Eftersom denna VNI är densamma på alla Leafs och faller under våra importregler i VRF-inställningarna, hamnar prefixet i BGP-tabellen, vilket kan ses från utdata:
sh bgp l2vpn evpn
<.....>
Network 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
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
Route Distinguisher: 10.255.1.21:32787
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.20]/272 ! Префикс полученный из VNI 20000
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 iOm vi tittar närmare på den mottagna uppdateringen kan vi se att detta prefix har två RT:er:
Leaf11# sh bgp l2vpn evpn 5001.0008.0007
BGP routing table information for VRF default, address family L2VPN EVPN
Route Distinguisher: 10.255.1.21:32787
BGP routing table entry for [2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.2
0]/272, version 5164
Paths: (2 available, best #2)
Flags: (0x000202) (high32 00000000) on xmit-list, is not in l2rib/evpn, is not i
n HW
Path type: internal, path is valid, not best reason: Neighbor Address, no labeled nexthop
AS-Path: NONE, path sourced internal to AS
10.255.1.20 (metric 81) from 10.255.1.102 (10.255.1.102)
Origin IGP, MED not set, localpref 100, weight 0
Received label 20000 99000 ! Два label для работы VxLAN
Extcommunity: RT:65001:20000 RT:65001:99000 SOO:10.255.1.20:0 ENCAP:8 ! Два значения Route-target, на основе, которых добавили данный префикс
Router MAC:5001.0005.0007
Originator: 10.255.1.21 Cluster list: 10.255.1.102
<......>I routingtabellen på Leaf-1 kan du också se prefixet 192.168.20.20/32:
Leaf11# sh ip route vrf PROD
192.168.10.0/24, ubest/mbest: 1/0, attached
*via 192.168.10.1, Vlan10, [0/0], 01:29:28, direct
192.168.10.1/32, ubest/mbest: 1/0, attached
*via 192.168.10.1, Vlan10, [0/0], 01:29:28, local
192.168.10.10/32, ubest/mbest: 1/0, attached
*via 192.168.10.10, Vlan10, [190/0], 01:27:22, hmm
192.168.20.20/32, ubest/mbest: 1/0 ! Адрес Host-2
*via 10.255.1.20%default, [200/0], 01:20:20, bgp-65001, internal, tag 65001 ! Доступный через Leaf-2
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN ! Через VNI 99000Lägger du märke till det saknade primära prefixet 192.168.20.0/24 i routingtabellen?
Det stämmer, han är inte där. Det vill säga, remote Leafs får endast information om de värdar som finns på ditt nätverk. Och detta är det korrekta beteendet. Ovan, i alla uppdateringar, kan du se att information kommer med innehållet i MAC/IP. Det finns inga prefix att tala om.
Detta är Host Mobility Manager-protokollet (HMM), som fyller ARP-tabellen från vilken BGP-tabellen fylls i ytterligare (vi kommer att utelämna denna process inom ramen för denna artikel). Baserat på informationen som tas emot från HMM, bildas EVPN:er av rutttyp 2 (sänds av MAC / IP).
Men vad händer om det finns ett behov av att skicka information om ett prefix?
För den här typen av information finns det EVPN-rutttyp 5 - det låter dig skicka prefix via adressfamiljen l2vpn evpn (den här typen av rutt finns i skrivande stund endast i utkastversionen , på grund av detta kan olika tillverkare ha olika beteende av denna typ av rutt)
För att överföra prefix är det nödvändigt att lägga till prefix i BGP-processen för VRF, som kommer att annonseras:
router bgp 65001
vrf PROD
address-family ipv4 unicast
redistribute direct route-map VNI20000 ! В данном случае анонсируем префиксы подключение непосредственно к Leaf в VNI 20000
route-map VNI20000 permit 10
match ip address prefix-list VNI20000_OUT ! Указываем какой использовать prefix-list
ip prefix-list VNI20000_OUT seq 5 permit 192.168.20.0/24 ! Указываем какие сети будут попадать в EVPN route-type 5Som ett resultat kommer uppdateringen att vara:
Låt oss titta på BGP-tabellen. Förutom EVPN-rutttyp 2,3, har typ 5-rutter dykt upp som innehåller information om nätverksnumret:
<......>
Network Next Hop Metric LocPrf Weight Path
Route 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 ?
Route 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
Route Distinguisher: 10.255.1.12:3
*>i[5]:[0]:[0]:[24]:[192.168.10.0]/224 ! EVPN route-type 5 с номером префикса
10.255.1.10 0 100 0 ?
* i
<.......> Prefixet förekom också i routingtabellen:
Leaf21# sh ip ro vrf PROD
192.168.10.0/24, ubest/mbest: 1/0
*via 10.255.1.10%default, [200/0], 00:14:32, bgp-65001, internal, tag 65001 ! Удаленный префикс, доступный через Leaf1/2(адрес Next-hop = virtual IP между парой VPC)
(evpn) segid: 99000 tunnelid: 0xaff010a encap: VXLAN ! Префикс доступен через L3VNI 99000
192.168.10.10/32, ubest/mbest: 1/0
*via 10.255.1.10%default, [200/0], 02:33:40, bgp-65001, internal, tag 65001
(evpn) segid: 99000 tunnelid: 0xaff010a encap: VXLAN
192.168.20.0/24, ubest/mbest: 1/0, attached
*via 192.168.20.1, Vlan20, [0/0], 02:39:44, direct
192.168.20.1/32, ubest/mbest: 1/0, attached
*via 192.168.20.1, Vlan20, [0/0], 02:39:44, local
192.168.20.20/32, ubest/mbest: 1/0, attached
*via 192.168.20.20, Vlan20, [190/0], 02:35:46, hmmDetta avslutar den andra delen av en serie artiklar om VxLAN EVPN. I nästa del kommer vi att överväga olika alternativ för routing mellan VRF:er.
Källa: will.com