Здравей, Хабр. Продължавам цикъла от статии за технологията VxLAN EVPN, които бяха написани специално за старта на курса от OTUS. И днес ще разгледаме интересна част от задачите — маршрутизация. Както и да звучи банално, в рамките на работата на мрежовата фабрика всичко може да е много по-сложно.
В предишната част успяхме да постигнем един широковещателен домейн, построен върху мрежовата фабрика на Nexus 9000v. Въпреки това, това далеч не е целият спектър от задачи, които е необходимо да решим в рамките на мрежата на ЦОД. Днес ще разгледаме следната задача — маршрутизация между мрежи или между VNI.
Напомням, че се използва топология Spine-Leaf:
Първо, нека разгледаме как се осъществява маршрутизацията и какви са особеностите.
За улеснение ще опростим логичната схема и ще добавим още един VNI 20000 за Host-2. В крайна сметка получаваме:
Как в такъв случай можем да предадем трафик от един Host на друг?
Има два варианта:
- Да запазим информация за всички VNI на всички Leaf комутатори, така че цялата маршрутизация да се осъществява на първия Leaf в мрежата;
- Да използваме специално определен — L3 VNI
Първият метод е прост и удобен. Необходимо е само да въведем всички VNI на всички Leaf комутатори. Въпреки това, въвеждането на стотици или хиляди VNI на всички Leaf вече не изглежда толкова лесна задача. Следователно, той се използва доста рядко.
Нека разгледаме втория метод, който е по-интересен и малко по-сложен, но предоставя по-голяма гъвкавост в конфигурацията на фабриката.
Добавяме към топологията VRF "PROD". В него добавяме interface vlan 10 на двойката Leaf-11/12 и interface VLAN 20 на Leaf-21. VLAN 20 асоциираме с 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-gatewayЗа да използваме L3VNI, е необходимо да създадем нов VLAN, да го асоциираме с нов VNI. Новият VNI трябва да бъде еднакъв на всички Leaf, заинтересовани от информация за VLAN 10 и 20
vlan 99
vn-segment 99000
interface nve1
member vni 99000 associate-vrf ! Създаваме L3 VNI
vrf context PROD
vni 99000 ! Привързваме L3 VNI към определен VRFВ резултат схемата ще се представя така:
Остана малко да завършим — да добавим още един интерфейс — interface vlan 99 в VRF PROD
interface Vlan99
no shutdown
vrf member PROD
ip forward ! На интерфейса не трябва да има IP. Използва се само за пренос на пакети между LeafВ крайна сметка логиката на преминаване на кадрите от Host-1 до Host-2 е следната:
- Кадърът, изпратен от Host-1, достига до Leaf в VLAN 10, който е асоцииран с VNI 10000;
- Leaf проверява къде се намира адресът на дестинацията и го намира чрез L3 VNI на втория Leaf комутатор;
- След като е намерен маршрутът до адреса на дестинацията, Leaf опаковает кадъра в заглавие с необходимия L3VNI 99000 — и го изпраща в посока втория Leaf;
- Вторият Leaf комутатор получава данни от L3VNI 99000. Извлича оригиналния кадър и го пренасочва в необходимия L2VNI 20000 и после в VLAN 20.
Резултатът от такава работа L3VNI премахва необходимостта от съхраняване на информация за всички VNI, които съществуват в мрежата на всички Leaf комутатори.
В крайна сметка, когато изпращаме трафик от Host-1 до Host-2, пакета се опакова в VxLAN с нов VNI — 99000:
Остава да разберем как точно Leaf-1 научава за MAC адреса от друг VNI. Това става така също с помощта на EVPN route-type 2 (MAC/IP).
По-долу е показан процесът на разпространение на маршрута за префикса, намиращ се в друг VNI:
Тоест адресите, получени от VNI 20000, имат два RT.
Напомням, че маршрути, получени от Update, попадат в BGP таблицата с Route-target, посочен в настройките на VRF (процесът е малко по-сложен, но в рамките на тази статия няма да се задълбочаваме).
Самият RT се формира по формулата: AS:VNI (ако се използва автоматичен режим).
Пример за формиране на RT в автоматичен и ръчен режим:
vrf context PROD
address-family ipv4 unicast
route-target import auto - автоматичен режим на работа
route-target export 65001:20000 - ръчен режим на формиране на RTВ резултат на горното е видно, че префиксите от друг VNI имат две стойности RT.
Едната от тях е 65001:99000 — допълнителен L3 VNI. Тъй като този VNI е еднакъв на всички Leaf и попада под нашите правила за import в настройките на VRF — префиксът попада в BGP таблицата, което може да се види от изхода:
sh bgp l2vpn evpn
Мрежа Следваща скок Метрика LocPrf Тежест Път
Идентификатор на маршрута: 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
Идентификатор на маршрута: 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 iАко погледнем по-внимателно полученото обновление, ще видим, че този префикс има два RT:
Leaf11# sh bgp l2vpn evpn 5001.0008.0007
Информация за таблицата на BGP маршрути за VRF по подразбиране, адресно семейство L2VPN EVPN
Идентификатор на маршрута: 10.255.1.21:32787
Запис в таблицата на BGP маршрути за [2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.20]\/272, версия 5164
Пътища: (2 налични, най-добрият #2)
Флагове: (0x000202) (high32 00000000) в xmit-list, не е в l2rib\/evpn, не е в HW
Тип на пътя: вътрешен, пътят е валиден, не е най-добър, причина: адрес на съсед, няма етикетирана следваща стъпка
AS-Път: НЯМА, пътят е източен вътрешно към AS
10.255.1.20 (метрика 81) от 10.255.1.102 (10.255.1.102)
Произход IGP, MED не е зададен, локален преференс 100, тежест 0
Получен етикет 20000 99000 ! Два етикета за работа с VxLAN
Extcommunity: RT:65001:20000 RT:65001:99000 SOO:10.255.1.20:0 ENCAP:8 ! Два стойности Route-target, на основание, на които е добавен този префикс
MAC на рутера:5001.0005.0007
Инициатор: 10.255.1.21 Списък на клъстера: 10.255.1.102В таблицата на маршрутизацията на Leaf-1 може също да се наблюдава префикс 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.20fault, [200/0], 01:20:20, bgp-65001, internal, tag 65001 ! Достъпен чрез Leaf-2
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN ! Чрез VNI 99000Забелязахте ли отсъствието на основния префикс 192.168.20.0\/24 в таблицата на маршрутизацията?
Точно така, няма го. Тоест отдалечените Leaf получават информация само за хостовете, които са в мрежата ви. И това е правилното поведение. По-горе във всички обновления е видно, че идва информация с MAC\/IP съдържание. За никакви префикси не се говори.
Тук работи протоколът Host Mobility Manager (HMM), който запълва ARP таблицата, от която по-натам се попълва BGP таблицата (в рамките на тази статия ще пропуснем този процес). На основата на информацията, получена от HMM, се формират EVPN route-type 2 (предава се MAC\/IP).
Но какво да направим, ако е необходимо да предадем информация за някакъв префикс?
За този вид информация съществува EVPN route-type 5 — позволява предаване на префикси чрез address-family l2vpn evpn (този тип маршрути в момента на написване на статията се намира само в чернова версия , поради това различните производители може да имат различно поведение при работа с този тип маршрут)
За предаване на префиксите е необходимо в процеса на BGP за VRF да се добавят префиксите, които ще бъдат анонсирани:
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 5В резултат в Update ще бъде:
Нека погледнем таблицата BGP. В допълнение към EVPN route-type 2,3 се появиха маршрути от 5-ти тип, които съдържат информация за номера на мрежата:
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 В таблицата за маршрутирането префиксът също се появи:
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, internal, tag 65001 ! Удален префикс, достъпен чрез Leaf1/2 (адрес Next-hop = виртуален IP между парите VPC)
(evpn) segid: 99000 tunnelid: 0xaff010a encap: VXLAN ! Префиксът е достъпен чрез L3VNI 99000
192.168.10.10/32, ubest/mbest: 1/0
*via 10.255.1.10fault, [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, hmmС това завършваме втората част от цикъла статии по VxLAN EVPN. В следващата част ще разгледаме различни варианти за маршрутизиране между VRF.
Източник: habr.com
