Helló, Habr. Folytatom a VxLAN EVPN technológia cikksorozatot, amelyeket kifejezetten a tanfolyam elindításához írtak az OTUS-tól. Ma pedig egy érdekes feladatot vizsgálunk meg — a routing-ot. Bár ez talán banálisan hangzik, a hálózati gyár működése során minden nem is olyan egyszerű.
A múlt részben elértünk egy széleskörű domain-t, amely a Nexus 9000v hálózati gyárra épült. Azonban ez messze nem az összes olyan feladat, amelyet a Data Center hálózatában meg kell oldani. Ma a következő feladatot vizsgáljuk — routing a hálózatok vagy a VNI-k között.
Emlékeztetőül, a Spine-Leaf topológiát használjuk:
Először nézzük meg, hogyan történik a routing, és milyen sajátosságai vannak.
A megértés érdekében leegyszerűsítjük a logikai séma, és hozzáadunk egy VNI 20000-t a Host-2-hez. Így néz ki:
Hogyan lehet ilyen esetben a forgalmat az egyik Hosztról a másikra továbbítani?
Két lehetőség van:
- Minden Leaf kapcsolón tárolni az összes VNI információt, akkor minden routing a hálózat első Leaf-ján történik;
- Külön dedikált — L3 VNI használata
Az első módszer egyszerű és kényelmes. Csak annyit kell tenni, hogy az összes VNI-t bevezetjük az összes Leaf kapcsolóra. Azonban több száz vagy ezer VNI bevezetése az összes Leaf-re már nem tűnik annyira egyszerű feladatnak. Ezért a gyakorlatban elég ritkán alkalmazzák.
Nézzük meg a második módszert, ami érdekesebb és egy kicsit bonyolultabb, de nagyobb rugalmasságot ad a gyár beállításában.
Adjunk hozzá a topológiához egy VRF "PROD"-ot. Ehhez hozzáadjuk az interface vlan 10-et a Leaf-11/12 páron, és az interface VLAN 20-at a Leaf-21-re. A VLAN 20-at a VNI 20000-hoz társítjuk.
vrf context PROD
rd auto ! A Route Distinguisher nem kritikus, ezért automatikusan létrehozottat használhatunk
address-family ipv4 unicast
route-target both auto ! Megadjuk a Route-target, amellyel a prefixek importálására és exportálására kerül sor a VRF-be
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-gatewayAhhoz, hogy az L3VNI-t használni tudjuk, új VLAN-t kell létrehoznunk, és társítani kell az új VNI-vel. Az új VNI-nak az összes Leaf-en azonosnak kell lennie, amely érdeklődik a VLAN 10 és 20 információ iránt.
vlan 99
vn-segment 99000
interface nve1
member vni 99000 associate-vrf ! L3 VNI-t hozunk létre
vrf context PROD
vni 99000 ! Az L3 VNI-t egy adott VRF-hez rendeljükEnnek eredményeként a séma így fog kinézni:
Már csak egy kicsi van hátra — hozzá kell adni egy új interfészt — interface vlan 99 a VRF PROD-hoz.
interface Vlan99
no shutdown
vrf member PROD
ip forward ! Az interfészen nem lehet IP. Csak csomagok átkonvertálására használják a Leaf között.Ennek eredményeként a keret logikája a Host-1-től a Host-2-ig a következő:
- A Host-1 által küldött keret a Leaf-re érkezik a VLAN 10-en, amely a VNI 10000-hez van társítva;
- A Leaf ellenőrzi, hogy hol található a célelőfizető, és megtalálja azt az L3 VNI-n keresztül a második Leaf kapcsolón;
- Amint megtalálta a célelőfizetőhöz vezető útvonalat, a Leaf becsomagolja a keretet a szükséges L3VNI 99000 fejlécébe — és elküldi a második Leaf irányába;
- A második Leaf kapcsoló az L3VNI 99000-ből érkező adatokat kapja. Kiveszi az eredeti keretet, és átkonvertálja a szükséges L2VNI 20000-be, majd a VLAN 20-ba.
Egy ilyen munkafolyamat eredménye, hogy az L3VNI eltávolítja a szükségességét, hogy az összes Leaf kapcsolón információt tartsanak minden VNI-ről, amely a hálózatban van.
Emiatt, amikor forgalmat küldünk a Host-1-től a Host-2-ig, a csomag egy új VNI — 99000 — VxLAN-ba lesz becsomagolva:
Meg kell értenünk, hogyan tudja a Leaf-1 a MAC címet egy másik VNI-ből. Ez is az EVPN route-type 2 (MAC/IP) segítségével történik.
Alább látható a másik VNI-ben található prefixről szóló útvonal terjesztésének folyamata:
Ezért a VNI 20000-ből származó címeknek két RT-je van.
Emlékeztetlek, hogy a frissítésekből származó útvonalak a VRF beállításában megadott Route-target mellett a BGP táblába kerülnek (a folyamat kicsit bonyolultabb, de az adott cikk keretein belül nem fogunk mélyebben belemerülni).
A RT önmaga a következő képlettel készül: AS:VNI (ha automatikus üzemmódot használnak).
Példa a RT automatikus és manuális módon történő kialakítására:
vrf context PROD
address-family ipv4 unicast
route-target import auto - automatikus üzemmód
route-target export 65001:20000 - manuális RT kialakítási módAz előbbiekből látható, hogy a másik VNI-ből származó prefixeknek két RT értékük van.
Az egyik 65001:99000 — egy kiegészítő L3 VNI. Mivel ez a VNI minden Leaf-en azonos, és megfelel a VRF beállításaink import szabályainak — a prefix átkerül a BGP táblába, amit a kimenetre is láthatunk:
sh bgp l2vpn evpn
Hálózat Következő ugrás Méret LocPrf Súly Útvonal
Útvonal megkülönböztető: 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
Útvonal megkülönböztető: 10.255.1.21:32787
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.20]\/272 ! Prefix a VNI 20000-ból
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 iHa közelebbről megvizsgáljuk a kapott frissítést, látható, hogy ennek a prefixnek két RT-je van:
Leaf11# sh bgp l2vpn evpn 5001.0008.0007
BGP routing táblázat információk a VRF default, címcsoport L2VPN EVPN
Útvonal megkülönböztető: 10.255.1.21:32787
BGP routing táblázat bejegyzés [2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.20]\/272, verzió 5164
Útvonalak: (2 elérhető, legjobb #2)
Flag: (0x000202) (high32 00000000) xmit-listen, nem található l2rib/evpn-ben, nem HW-ben
Útvonal típusa: belső, az útvonal érvényes, nem legjobb ok: Szomszéd cím, nincs címkével ellátott következő ugrás
AS-Útvonal: NINCS, az útvonal belsőre származik AS-ból
10.255.1.20 (mérték 81) 10.255.1.102-től (10.255.1.102)
Eredet IGP, MED nincs beállítva, helyi pref. 100, súly 0
Kapott címke 20000 99000 ! Két címke a VxLAN működéséhez
Kiterjesztett közösség: RT:65001:20000 RT:65001:99000 SOO:10.255.1.20:0 ENCAP:8 ! Két Route-target, amely alapján ezt a prefixet hozzáadtuk
Router MAC:5001.0005.0007
Eredeti: 10.255.1.21 Csoportlista: 10.255.1.102A Leaf-1 routing táblájában is megfigyelhetjük a 192.168.20.20\/32 prefixet:
Leaf11# sh ip route vrf PROD
192.168.10.0\/24, ubest\/mbest: 1\/0, csatlakoztatva
*192.168.10.1-en, Vlan10, [0\/0], 01:29:28, direkt
192.168.10.1\/32, ubest\/mbest: 1\/0, csatlakoztatva
*192.168.10.1-en, Vlan10, [0\/0], 01:29:28, helyi
192.168.10.10\/32, ubest\/mbest: 1\/0, csatlakoztatva
*192.168.10.10-en, Vlan10, [190\/0], 01:27:22, hmm
192.168.20.20\/32, ubest\/mbest: 1\/0 ! Host-2 címe
*10.255.1.20fault-en, [200\/0], 01:20:20, bgp-65001, belső, címke 65001 ! Leaf-2-n keresztül elérhető
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN ! VNI 99000-on keresztülÉszrevettük a fő prefix, 192.168.20.0\/24 hiányát a routing táblázatban?
Igen, ott tényleg nincs. Ezért az eltávolított Leaf csak az Ön hálózatában található hosztok információit kapja. Ez helyes viselkedés. Ahogy az korábban a frissítésekben látható, a MAC\/IP tartalmú információ érkezik. Semmiféle prefixről nincs szó.
Ez a Host Mobility Manager (HMM) protokoll működik, amely kitölti az ARP táblázatot, amelyből a BGP táblázat is kitöltődik (ebben a cikkben ezt a folyamatot kihagyjuk). Az HMM-ből származó információk alapján EVPN route-típus 2 jön létre (AMAC\/IP továbbítva).
De mi a teendő, ha szükséges egy adott prefix információt továbbítani?
Az ilyen típusú információkhoz létezik az EVPN route-type 5 — lehetővé teszi a prefixek továbbítását az address-family l2vpn evpn-en keresztül (ez a route-típus jelenleg csak tervezetben található). , emiatt a különböző gyártóknál eltérhet ennek a route-típusnak a működése.
A prefixek továbbításához a BGP folyamat során a VRF-hez hozzá kell adni a hirdetett prefixeket:
router bgp 65001
vrf PROD
address-family ipv4 unicast
redistribute direct route-map VNI20000 ! Ebben az esetben a prefixeket a Leaf-hez való közvetlen csatlakozáskor hirdetjük VNI 20000-ben.
route-map VNI20000 permit 10
match ip address prefix-list VNI20000_OUT ! Megadjuk, hogy melyik prefix-listet használjuk.
ip prefix-list VNI20000_OUT seq 5 permit 192.168.20.0/24 ! Megadjuk, hogy mely hálózatok kerülnek be az EVPN route-type 5-be.Ennek eredményeként az Update így fog kinézni:
Nézzük meg a BGP táblázatot. A 2, 3-as EVPN route-type-ok mellett megjelentek az 5-ös típustartalmú route-ok is, amelyek tartalmazzák a hálózat számát:
Hálózat Következő Hop Metrika LocPrf Súly Útvonal
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 prefix számmal.
10.255.1.10 0 100 0 ?
* i A routing táblázatban a prefix szintén megjelent:
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, belső, címke 65001 ! Távoli prefix, amely elérhető a Leaf1/2-n (Következő hop címe = virtuális IP a VPC pár között)
(evpn) segid: 99000 tunnelid: 0xaff010a encap: VXLAN ! A prefix elérhető az L3VNI 99000-en keresztül.
192.168.10.10/32, ubest/mbest: 1/0
*via 10.255.1.10fault, [200/0], 02:33:40, bgp-65001, belső, címke 65001
(evpn) segid: 99000 tunnelid: 0xaff010a encap: VXLAN
192.168.20.0/24, ubest/mbest: 1/0, csatlakoztatott
*via 192.168.20.1, Vlan20, [0/0], 02:39:44, közvetlen
192.168.20.1/32, ubest/mbest: 1/0, csatlakoztatott
*via 192.168.20.1, Vlan20, [0/0], 02:39:44, helyi
192.168.20.20/32, ubest/mbest: 1/0, csatlakoztatott
*via 192.168.20.20, Vlan20, [190/0], 02:35:46, hmmEzzel befejezzük a VxLAN EVPN ciklus második részét. A következő részben a VRF-ek közötti különböző forgalmi útvonalakat fogjuk megvizsgálni.
Forrás: habr.com
