Ahoj Habr. Pokračujem v sérii článkov o technológii VxLAN EVPN, ktorá boli napísané špeciálne pre spustenie kurzu spoločnosťou OTUS. A dnes zvážime zaujímavú časť úloh - smerovanie. Bez ohľadu na to, ako banálne to môže znieť, ako súčasť práce sieťovej továrne nemusí byť všetko také jednoduché.
V poslednej časti sme dosiahli jednu vysielaciu doménu postavenú na sieťovej štruktúre na zariadení Nexus 9000v. Toto však nie je celý rad úloh, ktoré je potrebné v rámci siete dátových centier riešiť. A dnes zvážime nasledujúcu úlohu - smerovanie medzi sieťami alebo medzi VNI.
Dovoľte mi pripomenúť, že sa používa topológia Spine-Leaf:
Najprv analyzujeme, ako dochádza k smerovaniu a aké funkcie má.
Pre pochopenie si zjednodušíme logický diagram a pridáme ďalší VNI 20000 pre Host-2. Výsledkom je:
Ako môžete v tomto prípade preniesť návštevnosť z jedného hostiteľa na druhého?
Existujú dve možnosti:
- Uchovávajte informácie o všetkých VNI na všetkých prepínačoch Leaf, potom sa všetko smerovanie uskutoční na prvom Leaf v sieti;
- Použite vyhradený - L3 VNI
Prvý spôsob je jednoduchý a pohodlný. Pretože stačí spustiť všetky VNI na všetkých prepínačoch Leaf. Prevádzkovať niekoľko stoviek či tisícok VNI na celom Leafe sa však už nezdá byť jednoduchou úlohou. Preto sa v práci používa pomerne zriedka.
Metódu 2 budeme analyzovať ako zaujímavejšiu a trochu komplikovanejšiu, ale poskytuje väčšiu flexibilitu pri nastavovaní továrne.
Pridajme k topológii VRF „PROD“. Pridajme k nemu rozhranie vlan 10 na dvojici Leaf-11/12 a rozhranie VLAN 20 na Leaf-21. VLAN 20 je spojená s 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-gatewayAk chcete použiť L3VNI, musíte vytvoriť novú sieť VLAN a priradiť ju k novej VNI. Nové VNI musí byť rovnaké na všetkých listoch, ktoré majú záujem o informácie VLAN 10 a 20.
vlan 99
vn-segment 99000
interface nve1
member vni 99000 associate-vrf ! Создаем L3 VNI
vrf context PROD
vni 99000 ! Привязываем L3 VNI к определенному VRFV dôsledku toho bude diagram vyzerať takto:
Zostáva trochu dokončiť - pridať ďalšie rozhranie - rozhranie vlan 99 vo VRF PROD
interface Vlan99
no shutdown
vrf member PROD
ip forward ! На интерфейсе не должно быть IP. Используется только для пересылки пакетов между LeafV dôsledku toho je logika odovzdávania rámca z hostiteľa-1 do hostiteľa-2 nasledovná:
- Rámec odoslaný hostiteľom-1 prichádza na list vo VLAN 10, ktorý je spojený s VNI 10000;
- Leaf skontroluje, kde je cieľová adresa a nájde ju cez L3 VNI na druhom prepínači Leaf;
- Hneď ako sa nájde cesta k cieľovej adrese, Leaf zabalí rámec do hlavičky s potrebným L3VNI 99000 - a odošle ho do druhého listu;
- Druhý Leaf prepínač prijíma dáta z L3VNI 99000. Získa pôvodný rámec a prenesie ho do požadovaného L2VNI 20000 a následne do VLAN 20.
Výsledkom tejto práce je, že L3VNI odstraňuje potrebu uchovávať informácie o všetkých VNI, ktoré sú v sieti, na všetkých prepínačoch Leaf.
Výsledkom je, že keď odosielame prenos z hostiteľa-1 na hostiteľa-2, paket je zabalený vo VxLAN s novým VNI - 99000:
Zostáva zistiť, ako presne sa Leaf-1 dozvie o MAC adrese z iného VNI. To sa deje aj pomocou EVPN trasy typu 2 (MAC / IP).
Nasledujúci text ukazuje proces šírenia trasy okolo predpony umiestnenej v inom VNI:
To znamená, že adresy prijaté z VNI 20000 majú dva RT.
Pripomínam, že prijaté trasy z Update spadajú do tabuľky BGP s Route-target zadaným v nastaveniach VRF (proces je o niečo komplikovanejší, ale do tohto článku sa nebudeme venovať).
Samotný RT je tvorený vzorcom: AS:VNI (ak je použitý automatický režim).
Príklad tvorby RT v automatickom a manuálnom režime:
vrf context PROD
address-family ipv4 unicast
route-target import auto - автоматический режим работы
route-target export 65001:20000 - ручной режим формирования RTVýsledkom je, že vyššie vidíte, že predpony z iného VNI majú dve hodnoty RT.
Jeden z nich 65001:99000 je dodatočný L3 VNI. Keďže toto VNI je rovnaké na všetkých listoch a spadá pod naše pravidlá importu v nastaveniach VRF, predpona sa dostane do tabuľky BGP, čo je vidieť z výstupu:
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 iAk sa bližšie pozrieme na prijatú aktualizáciu, vidíme, že táto predpona má dve RT:
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
<......>V smerovacej tabuľke na Leaf-1 môžete vidieť aj prefix 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 99000Všimli ste si chýbajúcu primárnu predponu 192.168.20.0/24 v smerovacej tabuľke?
Presne tak, nie je tam. To znamená, že vzdialené listy prijímajú informácie iba o hostiteľoch, ktorí sú vo vašej sieti. A toto je správne správanie. Vyššie vo všetkých aktualizáciách môžete vidieť, že informácie prichádzajú s obsahom MAC / IP. Nedá sa hovoriť o žiadnych predponách.
Ide o protokol Host Mobility Manager (HMM), ktorý vypĺňa tabuľku ARP, z ktorej sa ďalej napĺňa tabuľka BGP (v rámci tohto článku tento proces vynecháme). Na základe informácií prijatých z HMM sa vytvoria EVPN typu 2 (vysielané MAC / IP).
Čo však v prípade, ak je potrebné odovzdať informácie o prefixe?
Pre tento typ informácií existuje EVPN route-type 5 - umožňuje posielať prefixy cez address-family l2vpn evpn (tento typ trasy je v čase písania tohto článku len v draftovej verzii z tohto dôvodu môžu mať rôzni výrobcovia odlišné správanie tohto typu trasy)
Pre prenos prefixov je potrebné pridať prefixy v procese BGP pre VRF, ktoré budú inzerované:
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 5V dôsledku toho bude aktualizácia:
Pozrime sa na tabuľku BGP. Okrem trasy EVPN typu 2,3 sa objavili trasy typu 5, ktoré obsahujú informácie o čísle siete:
<......>
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
<.......> Predpona sa objavila aj v smerovacej tabuľke:
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, hmmTýmto sa uzatvára druhá časť série článkov o VxLAN EVPN. V ďalšej časti zvážime rôzne možnosti smerovania medzi VRF.
Zdroj: hab.com