Szia Habr. Folytatom a VxLAN EVPN technológiáról szóló cikksorozatot, amely kifejezetten a tanfolyam elindításához írták az OTUS által. És ma megvizsgáljuk a feladatok egy érdekes részét - az útválasztást. Bármennyire is elcsépeltnek hangzik, egy hálózati gyár munkájának részeként azonban minden nem lehet olyan egyszerű.
Az utolsó részben elértünk egy Nexus 9000v hálózatra épített sugárzási tartományt. Ez azonban nem az adatközponti hálózat keretein belül megoldandó feladatok teljes köre. És ma megvizsgáljuk a következő feladatot - útválasztás a hálózatok között vagy a VNI-k között.
Hadd emlékeztesselek arra, hogy a Spine-Leaf topológiát használják:
Először elemezzük, hogyan történik az útválasztás, és milyen funkciókkal rendelkezik.
A megértés érdekében egyszerűsítsük a logikai diagramot, és adjunk hozzá egy másik VNI 20000-t a Host-2 számára. Az eredmény:
Ebben az esetben hogyan tudja átvinni a forgalmat egyik gazdagépről a másikra?
Két lehetőség van:
- Az összes VNI-ről az összes Leaf kapcsolón tárolja az információkat, akkor minden útválasztás a hálózat első Leafjén fog megtörténni;
- Használjon dedikált - L3 VNI-t
Az első módszer egyszerű és kényelmes. Mivel csak az összes VNI-t kell elindítania az összes Leaf kapcsolón. Néhány száz vagy több ezer VNI futtatása a teljes Leaf-en azonban már nem tűnik könnyű feladatnak. Ezért a munkában meglehetősen ritkán használják.
A 2. módszert elemezzük, mint érdekesebb és kicsit bonyolultabb, de nagyobb rugalmasságot biztosít a gyár felállításában.
Adjuk hozzá a "PROD"-ot a VRF topológiához. Adjuk hozzá a VLAN 10 interfészt a Leaf-11/12 páron és a VLAN 20 interfészt a Leaf-21-en. A VLAN 20 a VNI 20000-hez van társítva
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-gatewayAz L3VNI használatához létre kell hoznia egy új VLAN-t, és társítania kell az új VNI-hez. Az új VNI-nek azonosnak kell lennie minden VLAN 10 és 20 információ iránt érdeklődő Leaf-en.
vlan 99
vn-segment 99000
interface nve1
member vni 99000 associate-vrf ! Создаем L3 VNI
vrf context PROD
vni 99000 ! Привязываем L3 VNI к определенному VRFEnnek eredményeként a diagram így fog kinézni:
Még egy kicsit be kell fejezni - adjunk hozzá még egy interfészt - a vlan 99 interfészt a VRF PROD-ban
interface Vlan99
no shutdown
vrf member PROD
ip forward ! На интерфейсе не должно быть IP. Используется только для пересылки пакетов между LeafEnnek eredményeként a keretnek az 1-es állomásról a 2-es gépre történő átadásának logikája a következő:
- A Host-1 által küldött keret egy VLAN 10-es Leafre érkezik, amely a VNI 10000-hez van társítva;
- A Leaf ellenőrzi, hogy hol van a célcím, és a második Leaf kapcsolón lévő L3 VNI-n keresztül találja meg;
- Amint megtalálja a célcímhez vezető útvonalat, a Leaf egy fejlécbe csomagolja a keretet a szükséges L3VNI 99000-nel - és elküldi a második Leaf felé;
- A második Leaf kapcsoló az L3VNI 99000-től fogad adatokat. Lekéri az eredeti keretet, és átviszi a szükséges L2VNI 20000-be, majd a VLAN 20-ba.
E munka eredményeként az L3VNI megszünteti annak szükségességét, hogy minden Leaf kapcsolón megőrizze a hálózaton lévő összes VNI adatait.
Ennek eredményeként, amikor forgalmat küldünk a Host-1-ről a Host-2-re, a csomag a VxLAN-on belül van becsomagolva az új VNI - 99000-vel:
Azt még látni kell, hogy a Leaf-1 pontosan hogyan tanulja meg a MAC-címet egy másik VNI-től. Ez az EVPN route-type 2 (MAC / IP) segítségével is megtörténik.
Az alábbiakban egy másik VNI-ben található előtagról szóló útvonal terjesztésének folyamata látható:
Vagyis a VNI 20000-től kapott címeknek két RT-je van.
Hadd emlékeztesselek arra, hogy az Update-től kapott útvonalak a VRF beállításaiban megadott Route-target-tel a BGP táblába esnek (a folyamat némileg bonyolultabb, de ebbe a cikkbe nem térünk ki).
Magát az RT-t a következő képlet alkotja: AS:VNI (ha automatikus módot használunk).
Példa az RT kialakítására automatikus és kézi üzemmódban:
vrf context PROD
address-family ipv4 unicast
route-target import auto - автоматический режим работы
route-target export 65001:20000 - ручной режим формирования RTEnnek eredményeként fent látható, hogy egy másik VNI előtagjainak két RT értéke van.
Az egyik 65001:99000 egy további L3 VNI. Mivel ez a VNI minden Leaf-en ugyanaz, és a VRF beállításokban az importálási szabályaink alá esik, az előtag bekerül a BGP táblába, ami a kimenetből látható:
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 iHa jobban megnézzük a kapott frissítést, láthatjuk, hogy ennek az előtagnak két RT-je van:
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
<......>A Leaf-1 útválasztási táblázatában a 192.168.20.20/32 előtag is látható:
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 99000Észreveszi a hiányzó 192.168.20.0/24 elsődleges előtagot az útválasztási táblázatban?
Így van, nincs ott. Vagyis a távoli levelek csak a hálózaton lévő gazdagépekről kapnak információkat. És ez a helyes viselkedés. Fent minden frissítésnél láthatja, hogy az információ a MAC / IP tartalmával érkezik. Nincs szó előtagról.
Ez a Host Mobility Manager (HMM) protokoll, amely kitölti azt az ARP táblát, amelyből a BGP tábla is kitöltésre kerül (a cikk keretein belül ezt a folyamatot kihagyjuk). A HMM-től kapott információk alapján 2-es útvonaltípusú EVPN-k jönnek létre (amelyeket MAC / IP továbbít).
De mi van akkor, ha információt kell átadni egy előtagról?
Az ilyen típusú információkhoz létezik az EVPN route-type 5 - ez lehetővé teszi az előtagok elküldését a address-family l2vpn evpn segítségével (ez az útvonal az írás idején csak a vázlatos verzióban található , emiatt a különböző gyártók eltérően viselkedhetnek ezen az útvonalon)
Az előtagok átviteléhez előtagokat kell hozzáadni a BGP-folyamathoz a VRF-hez, amelyet hirdetünk:
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 5Ennek eredményeként a frissítés a következő lesz:
Nézzük a BGP táblázatot. A 2,3-as EVPN-útvonal-típus mellett megjelentek az 5-ös típusú útvonalak, amelyek a hálózat számáról tartalmaznak információkat:
<......>
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
<.......> Az előtag az útválasztási táblázatban is megjelent:
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, hmmEzzel zárul a VxLAN EVPN-ről szóló cikksorozat második része. A következő részben megvizsgáljuk a VRF-ek közötti útválasztás különféle lehetőségeit.
Forrás: will.com