Ahoj, Habr. Pokračuji v cyklu článků o technologii VxLAN EVPN, které byly napsány speciálně k spuštění kurzu od OTUS. A dnes se podíváme na zajímavou část úloh — routování. Ačkoliv to může znít banálně, v rámci práce síťové fabriky může být vše složitější.
V minulé části jsme dosáhli jednoho broadcast domény, postavené na síťové fabrice na Nexus 9000v. Avšak to není celý rozsah úloh, které je třeba vyřešit v rámci datového centra. Dnes prozkoumáme další úkol — routování mezi sítěmi nebo mezi VNI.
Připomínám, že se používá topologie Spine-Leaf:
Nejprve si vysvětlíme, jak probíhá routování a jaké má své zvláštnosti.
Abychom to usnadnili, zjednodušíme logické schéma a přidáme další VNI 20000 pro Host-2. V konečném důsledku to bude vypadat takto:
Jak lze v takovém případě přenést provoz od jednoho hostitele k druhému?
Existují dvě možnosti:
- Na všech Leaf přepínačích uchovávat informace o všech VNI, potom veškeré routování proběhne na prvním Leaf v síti;
- Použít speciálně vyhrazený — L3 VNI
První způsob je jednoduchý a pohodlný. Je totiž třeba pouze zavést všechny VNI na všechny Leaf přepínače. Avšak zavést několik set nebo tisíc VNI na všechny Leaf už se nezdá jako jednoduchý úkol. Proto se v praxi používá poměrně zřídka.
Prozkoumáme druhý způsob, který je zajímavější a o něco složitější, ale poskytuje větší flexibilitu v nastavení fabriky.
Přidáme do topologie VRF "PROD". Do něj přidáme interface vlan 10 na páru Leaf-11/12 a interface VLAN 20 na Leaf-21. VLAN 20 asociujeme s VNI 20000.
vrf context PROD
rd auto ! Route Distinguisher není zásadní a můžeme použít automaticky vytvořený
address-family ipv4 unicast
route-target both auto ! uvádíme Route-target, se kterým budou importovány a exportovány prefixy do/z 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-gatewayAbychom mohli použít L3VNI, je nutné vytvořit nový VLAN a asociovat ho s novým VNI. Nový VNI musí být stejný na všech Leaf, které mají zájem o informace o VLAN 10 a 20.
vlan 99
vn-segment 99000
interface nve1
member vni 99000 associate-vrf ! Vytváříme L3 VNI
vrf context PROD
vni 99000 ! Připojujeme L3 VNI k určitému VRFVýsledná schéma bude vypadat takto:
Zbývá jen trochu doplnit — přidat další rozhraní — interface vlan 99 do VRF PROD
interface Vlan99
no shutdown
vrf member PROD
ip forward ! Na rozhraní by neměla být IP adresa. Používá se pouze pro přenos datových paketů mezi LeafLogika přenosu rámce z Host-1 do Host-2 je následující:
- Rámec, který je odeslán z Host-1, přichází na Leaf v VLAN 10, která je asociována s VNI 10000;
- Leaf kontroluje, kde se nachází cílová adresa, a nachází ji prostřednictvím L3 VNI na druhém Leafovém přepínači;
- Jakmile je nalezena cesta k cílové adrese, Leaf zabalí rámec do hlavičky s požadovaným L3VNI 99000 — a odešle jej směrem k druhému Leafu;
- Druhý Leaf přepínač přijímá data z L3VNI 99000. Vyjme původní rámec a převede jej do potřebného L2VNI 20000 a dále do VLAN 20.
Výsledkem této práce L3VNI odstraňuje potřebu uchovávat na všech Leafových přepínačích informace o všech VNI, které existují v síti.
Když posíláme provoz z Host-1 do Host-2, paket se zabalí do VxLAN s novým VNI — 99000:
Je třeba pochopit, jak přesně Leaf-1 zjistí MAC adresu z jiného VNI. Děje se to také pomocí EVPN route-type 2 (MAC/IP).
Následuje proces šíření trasy o prefixu nacházejícím se v jiném VNI:
To znamená, že adresy získané z VNI 20000 mají dvě RT.
Připomínám, že trasy získané z Update se dostanou do tabulky BGP s Route-target, jak je uvedeno v nastavení VRF (proces je poněkud složitější, avšak v rámci tohoto článku se nebudeme hlouběji zabývat).
Samotné RT se vytváří podle vzorce: AS:VNI (pokud je použito automatické režimu).
Příklad tvorby RT v automatickém a ručním režimu:
vrf context PROD
address-family ipv4 unicast
route-target import auto - automatický režim
route-target export 65001:20000 - ruční režim tvorby RTZ výše uvedeného je patrné, že prefixy z jiného VNI mají dva hodnoty RT.
Jedna z nich je 65001:99000 — dodatečný L3 VNI. Protože tento VNI je stejný na všech Leaf a spadá pod naše importní pravidla v nastavení VRF — prefix se dostane do tabulky BGP, jak lze vidět z výstupu:
sh bgp l2vpn evpn
Síť Další skok Metrika LocPrf Hmotnost Cesta
Rozlišovač trasy: 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
Rozlišovač trasy: 10.255.1.21:32787
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.20]\/272 ! Prefix získaný z VNI 20000
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 iPokud se podíváme podrobněji na obdrženou aktualizaci, lze vidět, že tento prefix má dvě RT:
Leaf11# sh bgp l2vpn evpn 5001.0008.0007
Informace o BGP routovací tabulce pro VRF default, adresní rodina L2VPN EVPN
Rozlišovač trasy: 10.255.1.21:32787
Záznam BGP routovací tabulky pro [2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.20]\/272, verze 5164
Cesty: (2 dostupné, nejlepší #2)
Flagy: (0x000202) (high32 00000000) na xmit-list, není v l2rib/evpn, není v HW
Typ cesty: interní, cesta je platná, není nejlepší důvod: Adresa souseda, žádný označený next-hop
AS-Cesta: ŽÁDNÝ, cesta nesená interně do AS
10.255.1.20 (metrika 81) od 10.255.1.102 (10.255.1.102)
Původ IGP, MED není nastaven, lokální preference 100, hmotnost 0
Přijatý štítek 20000 99000 ! Dva štítky pro práci s VxLAN
Extcommunity: RT:65001:20000 RT:65001:99000 SOO:10.255.1.20:0 ENCAP:8 ! Dva hodnoty Route-target, na základě kterých byl přidán tento prefix
Router MAC:5001.0005.0007
Původce: 10.255.1.21 Seznam clusterů: 10.255.1.102V routovací tabulce na Leaf-1 lze také pozorovat prefix 192.168.20.20\/32:
Leaf11# sh ip route vrf PROD
192.168.10.0/24, ubest/mbest: 1/0, připojeno
*via 192.168.10.1, Vlan10, [0/0], 01:29:28, přímé
192.168.10.1/32, ubest/mbest: 1/0, připojeno
*via 192.168.10.1, Vlan10, [0/0], 01:29:28, lokální
192.168.10.10/32, ubest/mbest: 1/0, připojeno
*via 192.168.10.10, Vlan10, [190/0], 01:27:22, hmm
192.168.20.20/32, ubest/mbest: 1/0 ! Adresa Host-2
*via 10.255.1.20fault, [200/0], 01:20:20, bgp-65001, interní, tag 65001 ! Přístupné přes Leaf-2
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN ! Přes VNI 99000Všimli jste si, že v routovací tabulce chybí hlavní prefix 192.168.20.0\/24?
Přesně tak, tam není. To znamená, že vzdálené Leaf dostávají informace pouze o hostech, kteří jsou ve vaší síti. A to je správné chování. V předchozích aktualizacích je vidět, že přicházejí informace o obsahu MAC\/IP. O žádných prefixech se nediskutuje.
Funguje protokol Host Mobility Manager (HMM), který vyplňuje ARP tabulku, ze které se pak vyplňuje BGP tabulka (v rámci tohoto článku tento proces opustíme). Na základě informací získaných z HMM se vytvářejí EVPN route-type 2 (přenáší se MAC\/IP).
Co však dělat, pokud je potřeba přenést informace o nějakém prefixu?
Pro tento typ informací existuje EVPN route-type 5 — umožňuje přenášet prefixy přes address-family l2vpn evpn (tento typ tras na moment psaní článku se nachází pouze v draft verzi) , kvůli tomu se může chování tohoto typu trasy lišit u různých výrobců)
Pro přenos prefixů je nutné v procesu BGP pro VRF přidat prefixy, které budou vyhlašovány:
router bgp 65001
vrf PROD
address-family ipv4 unicast
redistribute direct route-map VNI20000 ! V tomto případě vyhlašujeme prefixy připojení přímo k Leaf ve VNI 20000
route-map VNI20000 permit 10
match ip address prefix-list VNI20000_OUT ! Určujeme, jaký prefix-list použít
ip prefix-list VNI20000_OUT seq 5 permit 192.168.20.0\/24 ! Určujeme, které sítě budou zahrnuty do EVPN route-type 5V konečném důsledku bude v aktualizaci:
Podívejme se na tabulku BGP. Kromě EVPN route-type 2,3 se objevily trasy typu 5, které obsahují informace o čísle sítě:
Síť Další skok Metoda LocPrf Váha Trajektorie
Politik návrhu trasy: 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 ?
Politik návrhu trasy: 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
Politik návrhu trasy: 10.255.1.12:3
*>i[5]:[0]:[0]:[24]:[192.168.10.0]\/224 ! EVPN route-type 5 s číslem prefixu
10.255.1.10 0 100 0 ?
* i V tabulce tras se prefix také objevil:
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 ! Vzdálený prefix, dostupný přes Leaf1/2 (adresa Next-hop = virtuální IP mezi párem VPC)
(evpn) segid: 99000 tunnelid: 0xaff010a encap: VXLAN ! Prefix dostupný přes 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, připojeno
*via 192.168.20.1, Vlan20, [0/0], 02:39:44, přímé
192.168.20.1/32, ubest/mbest: 1/0, připojeno
*via 192.168.20.1, Vlan20, [0/0], 02:39:44, lokální
192.168.20.20/32, ubest/mbest: 1/0, připojeno
*via 192.168.20.20, Vlan20, [190/0], 02:35:46, hmmNa tomto končíme druhou část cyklu článků o VxLAN EVPN. V další části probereme různé možnosti směrování mezi VRF.
Zdroj: habr.com
