Üdvözlöm, Habr. Jelenleg az OTUS "Hálózati mérnök" kurzusának vezetője vagyok.
Az új kurzus indítása előtt , elkészítettem egy cikksorozatot a VxLAN EVPN technológiáról.
Rengeteg anyag áll rendelkezésre a VxLAN EVPN használatáról, ezért szeretném összegyűjteni a különböző feladatokat és azok megoldásait a modern adatközpontban.
A VxLAN EVPN technológiáról szóló cikksorozat első részében az L2 kapcsolat létrehozásának módját vizsgálom a hosztok között a hálózati gyár felett.
Minden példát Cisco Nexus 9000v eszközökön hajtunk végre, amelyeket Spine-Leaf topológiába állítunk. E cikk keretein belül nem fogunk foglalkozni az Underlay hálózat beállításával.
- Underlay hálózat
- BGP peering az address-family l2vpn evpn-hez
- NVE beállítása
- Supress-arp
Underlay hálózat
A használt topológia a következőképpen néz ki:
Állítsuk be a címzést az összes eszközön:
Spine-1 - 10.255.1.101
Spine-2 - 10.255.1.102
Leaf-11 - 10.255.1.11
Leaf-12 - 10.255.1.12
Leaf-21 - 10.255.1.21
Host-1 - 192.168.10.10
Host-2 - 192.168.10.20Ellenőrizzük, hogy van-e IP kapcsolat az összes eszköz között:
Leaf21# sh ip route
10.255.1.11/32, ubest/mbest: 2/0 ! A Leaf-11 elérhető két Spine-on keresztül
*via 10.255.1.101, Eth1/4, [110/81], 00:00:03, ospf-UNDERLAY, intra
*via 10.255.1.102, Eth1/3, [110/81], 00:00:03, ospf-UNDERLAY, intra
10.255.1.12/32, ubest/mbest: 2/0 ! A Leaf-12 elérhető két Spine-on keresztül
*via 10.255.1.101, Eth1/4, [110/81], 00:00:03, ospf-UNDERLAY, intra
*via 10.255.1.102, Eth1/3, [110/81], 00:00:03, ospf-UNDERLAY, intra
10.255.1.21/32, ubest/mbest: 2/0, attached
*via 10.255.1.22, Lo0, [0/0], 00:02:20, local
*via 10.255.1.22, Lo0, [0/0], 00:02:20, direct
10.255.1.101/32, ubest/mbest: 1/0
*via 10.255.1.101, Eth1/4, [110/41], 00:00:06, ospf-UNDERLAY, intra
10.255.1.102/32, ubest/mbest: 1/0
*via 10.255.1.102, Eth1/3, [110/41], 00:00:03, ospf-UNDERLAY, intraEllenőrizzük, hogy a VPC domain létrejött-e, és hogy mindkét switch átesett-e a konzisztencia-ellenőrzésen, és hogy a beállítások azonosak-e mindkét noden:
Leaf11# show vpc
vPC domain id : 1
Peer status : a peer kapcsolata rendben van
vPC keep-alive status : a peer él
Configuration consistency status : siker
Per-vlan consistency status : siker
Type-2 consistency status : siker
vPC role : elsődleges
Number of vPCs configured : 0
Peer Gateway : Kikapcsolva
Dual-active excluded VLANs : -
Graceful Consistency Check : Engedélyezve
Auto-recovery status : Kikapcsolva
Delay-restore status : Az időzítő ki van kapcsolva. (timeout = 30s)
Delay-restore SVI status : Az időzítő ki van kapcsolva. (timeout = 10s)
Operational Layer3 Peer-router : Kikapcsolva
vPC állapot
----------------------------------------------------------------------------
Id Port Status Consistency Reason Active vlans
-- ------------ ------ ----------- ------ ---------------
5 Po5 fenn siker siker 1BGP peering
Végre áttérhetünk az Overlay hálózat beállítására.
A cikk keretein belül hálózatot kell szerveznünk a hosztok között, ahogy az alábbi ábrán látható:
Az Overlay hálózat konfigurálásához a Spine és Leaf switch-eken BGP-t kell engedélyezni az l2vpn evpn családdal:
feature bgp
nv overlay evpnEzután BGP peeringet kell konfigurálni a Leaf és Spine között. A beállítás egyszerűsítése és a routing információk terjesztésének optimalizálása érdekében a Spine-t Route-Reflector server-ként állítjuk be. Minden Leaf-et sablonokon keresztül írunk be a konfigurációba, hogy optimalizáljuk a beállítást.
Így a beállítás a Spine-en így néz ki:
router bgp 65001
template peer LEAF
remote-as 65001
update-source loopback0
address-family l2vpn evpn
send-community
send-community extended
route-reflector-client
neighbor 10.255.1.11
inherit peer LEAF
neighbor 10.255.1.12
inherit peer LEAF
neighbor 10.255.1.21
inherit peer LEAFA Leaf switch beállítása hasonlóképpen néz ki:
router bgp 65001
template peer SPINE
remote-as 65001
update-source loopback0
address-family l2vpn evpn
send-community
send-community extended
neighbor 10.255.1.101
inherit peer SPINE
neighbor 10.255.1.102
inherit peer SPINEA Spine-en ellenőrizzük a peeringet az összes Leaf switch-el:
Spine1# sh bgp l2vpn evpn summary
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd
10.255.1.11 4 65001 7 8 6 0 0 00:01:45 0
10.255.1.12 4 65001 7 7 6 0 0 00:01:16 0
10.255.1.21 4 65001 7 7 6 0 0 00:01:01 0Ahogy látjuk, a BGP-vel nem voltak problémák. Most áttérünk a VxLAN beállítására. A további beállításokat kizárólag a Leaf switch-ek oldalán végezzük. A Spine csak a hálózat magjaként működik, és csak a forgalom átadásával foglalkozik. Az összes kapszulázás és útvonalmeghatározás kizárólag a Leaf switch-eken történik.
NVE beállítása
NVE — hálózati virtuális interfész
A beállítás előtt néhány terminológiát kell bevezetnünk:
VTEP — Virtual Tunnel End Point, az a készülék, ahol a VxLAN alagút kezdődik vagy végződik. A VTEP nem feltétlenül valamely hálózati eszköz. Szolgáltató szerver is lehet VxLAN technológia támogatásával. A topológiánkban minden Leaf switch VTEP-ként működik.
VNI — Virtual Network Index — a hálózat azonosítója a VxLAN keretein belül. Analógiát vonhatunk a VLAN-nal. Azonban vannak eltérések. A gyár használatával a VLAN-ok csak egy Leaf switchen belül válnak egyedivé, és nem terjednek el a hálózaton. De minden VLAN-hoz hozzárendelhető egy VNI szám, ami már átmegy a hálózaton. Az, hogy ez hogyan néz ki és hogyan használható, a későbbiekben lesz bemutatva.
Bekapcsoljuk a VxLAN technológia működéséhez szükséges funkciót, és lehetővé tesszük a VLAN számok VNI számokkal való társítását:
funkció nv overlay
funkció vn-szakasz-vlan-alapúBeállítjuk az NVE interfészt, amely a VxLAN működéséért felelős. Ez az interfész éppen a keretek VxLAN fejlécekkel való encapsulálásáért felel. Analógiát vonhatunk a GRE alagút interfészéhez:
interfész nve1
no shutdown
host-reachability protokoll bgp ! BGP-t használunk az útvonal-információk továbbítására
source-interface loopback0 ! az interfész, ahonnan a loopback0 csomagokat küldjükA Leaf-21 switch-en minden problémamentesen létrejön. Ha azonban ellenőrizzük a következő parancs kimenetét: show nve peers, az üresen marad. Vissza kell térni a VPC beállításához. Látjuk, hogy a Leaf-11 és Leaf-12 egy párban működik, és egy VPC domainba kapcsolódik. Így a következő helyzet áll elő:
A Host-2 egy keretet küld a Leaf-21 felé, hogy az továbbítja a hálózaton a Host-1 felé. A Leaf-21 azonban látja, hogy a Host-1 MAC címe két VTEP-en keresztül is elérhető. Hogyan kell eljárni a Leaf-21-nek? Ez azt jelenti, hogy a hálózaton hurok keletkezhetett.
A helyzet megoldásához szükség van arra, hogy a Leaf-11 és Leaf-12 a gyár keretein belül egyetlen eszközként működjön. Ezt viszonylag egyszerűen megoldhatjuk. Az alagút építéséhez használt Loopback interfészen másodlagos címet adunk hozzá. A másodlagos címnek mindkét VTEP-en azonosnak kell lennie.
interfész loopback0
ip add 10.255.1.10/32 secondaryÍgy a többi VTEP szempontjából a következő topológiát kapjuk:
Tehát most az alagút a Leaf-21 IP címe és a két Leaf-11 és Leaf-12 közötti virtuális IP cím között fog felépülni. Mostantól nem lesz probléma a MAC címek tanulmányozásával a két eszköz között, és a forgalom átmehet az egyik VTEP-ről a másikra. Hogy melyik VTEP kezeli a forgalmat, azt a Spine útvonal-táblája döntése alapján állapítjuk meg:
Spine1# sh ip route
10.255.1.10/32, ubest/mbest: 2/0
*via 10.255.1.11, Eth1/1, [110/41], 1d01h, ospf-UNDERLAY, intra
*via 10.255.1.12, Eth1/2, [110/41], 1d01h, ospf-UNDERLAY, intra
10.255.1.11/32, ubest/mbest: 1/0
*via 10.255.1.11, Eth1/1, [110/41], 1d22h, ospf-UNDERLAY, intra
10.255.1.12/32, ubest/mbest: 1/0
*via 10.255.1.12, Eth1/2, [110/41], 1d01h, ospf-UNDERLAY, intraAmint látható, a 10.255.1.10 cím azonnal két Next-hop-on keresztül elérhető.
Ezen a szinten a alapvető összekapcsoltságot tisztáztuk. Térjünk át az NVE interfész beállítására:
Azonnal aktiváljuk a 10-es VLAN-t, és társítjuk a 10000-es VNI-hez minden Leaf esetében a hostok számára. Létrehozunk egy L2 alagutat a hosztok között.
vlan 10 ! Engedélyezzük a VLAN-t minden VTEP-hez csatlakoztatott szükséges hoszton
vn-segment 10000 ! A VLAN-t a VNI számával társítjuk
interface nve1
member vni 10000 ! 10000-es VNI hozzáadása a NVE interfészen keresztüli működéshez, VxLAN-bekapcsolódás érdekében
ingress-replication protocol bgp ! Megadjuk, hogy a hosztinformációk terjesztéséhez BGP-t használunkMost ellenőrizzük az nve peers-t és a BGP EVPN táblázatot:
Leaf21# sh nve peers
Interface Peer-IP State LearnType Uptime Router-Mac
--------- --------------- ----- --------- -------- -----------------
nve1 10.255.1.10 Up CP 00:00:41 n/a ! Látjuk, hogy a peer elérhető a másodlagos címen
Leaf11# sh bgp l2vpn evpn
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.255.1.11:32777 (L2VNI 10000) ! Kitől érkezett ez az l2VNI
*>l[3]:[0]:[32]:[10.255.1.10]\/88 ! EVPN route-type 3 - megmutatja a szomszédunkat, aki szintén ismeri az l2VNI10000-et
10.255.1.10 100 32768 i
*>i[3]:[0]:[32]:[10.255.1.20]\/88
10.255.1.20 100 0 i
* i 10.255.1.20 100 0 i
Route Distinguisher: 10.255.1.21:32777
* i[3]:[0]:[32]:[10.255.1.20]\/88
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 iFent csak az EVPN route-type 3 útvonalakat látjuk. Ez a típusa a peer (Leaf) információit tartalmazza, de hol vannak a hosztjaink?
A dolog lényege, hogy a hosztok MAC információja az EVPN route-type 2-n keresztül kerül átadásra.
Ahhoz, hogy láthassuk a hosztjainkat, be kell állítanunk az EVPN route-type 2-t:
evpn
vni 10000 l2
route-target import auto ! A cikk keretein belül automatikus számot használunk a route-target számára
route-target export autoPingelünk a Host-2-ről a Host-1-re:
Firewall2# ping 192.168.10.1
PING 192.168.10.1 (192.168.10.1): 56 data bytes
36 bytes from 192.168.10.2: Destination Host Unreachable
Request 0 timed out
64 bytes from 192.168.10.1: icmp_seq=1 ttl=254 time=215.555 ms
64 bytes from 192.168.10.1: icmp_seq=2 ttl=254 time=38.756 ms
64 bytes from 192.168.10.1: icmp_seq=3 ttl=254 time=42.484 ms
64 bytes from 192.168.10.1: icmp_seq=4 ttl=254 time=40.983 msAlul látható, hogy a BGP táblázatban megjelentek a route-type 2 MAC címmel rendelkező hosztok — 5001.0007.0007 és 5001.0008.0007
Leaf11# sh bgp l2vpn evpn
Hálózat Következő ugrás Mérték LocPrf Súly Útvonal
Útválasztó 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 ! evpn útvonal-típus 2 és a 1. hoszt MAC címe
10.255.1.10 100 32768 i
*>i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]\/216 ! evpn útvonal-típus 2 és a 2. hoszt MAC címe
* i 10.255.1.20 100 0 i
*>l[3]:[0]:[32]:[10.255.1.10]\/88
10.255.1.10 100 32768 i
Útválasztó megkülönböztető: 10.255.1.21:32777
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]\/216
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 iEzután megtekinthetjük a frissítés részletes információit, amelyben információt kaptunk a MAC hostról. Az alábbiakban nem az összes parancs kimenete látható
Leaf21# sh bgp l2vpn evpn 5001.0007.0007
A BGP útválasztási táblainformáció a VRF alapértelmezett, L2VPN EVPN címzési család számára
Útválasztó megkülönböztető: 10.255.1.11:32777 ! frissítést küldött a MAC hostról. Nem virtuális VPC cím, hanem Leaf cím
A BGP útválasztási táblabejegyzés a [2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]\/216,
verzió 1507
Útvonalak: (2 elérhető, legjobb #2)
Jelek: (0x000202) (high32 00000000) xmit-listán, nem szerepel az l2rib\/evpn-ben, nem HW
Útvonal típus: belső, az útvonal érvényes, nem legjobb ok: szomszédi cím, nincs címkézett következő ugrás
AS-Útvonal: NINCS, az útvonal belső forrású az AS-en belül
10.255.1.10 (meter 81) a 10.255.1.102-től (10.255.1.102) ! kivel építjük fel a VxLAN alagutat
Eredete IGP, MED nincs beállítva, helyi preferencia 100, súly 0
Megkapott címke 10000 ! A VNI száma, amely a VLAN-nal van társítva, amelyben a hoszt található
Extcommunity: RT:65001:10000 SOO:10.255.1.10:0 ENCAP:8 ! Itt látható, hogy a RT automatikusan a számok alapján alakult ki AS és VNI
Eredet: 10.255.1.11 Kluster lista: 10.255.1.102
<........>Nézzük meg, hogyan néznek ki a keretek, amikor ezek áthaladnak a gyár üzerinden:
Suppress-ARP
Kiváló, az L2 kapcsolat a hostok között rendelkezésünkre áll, és itt befejezhetnénk. Azonban nem ilyen egyszerű. Amíg kevés hostunk van, nem adódik probléma. De képzeljük el a helyzetet, hogy több száz vagy ezer hostunk van. Mivel a problémával találkozhatunk?
Ez a probléma — BUM (Broadcast, Unknown Unicast, Multicast) forgalom. A cikk keretein belül a broadcast forgalom elleni küzdelem lehetőségét tárgyaljuk.
A fő Broadcast generátor az Ethernet hálózatokban maguk a hosztok az ARP protokollon keresztül.
A Nexus esetében a következő mechanizmus van implementálva az ARP kérések elleni küzdelemre — suppress-arp.
A funkció munkája a következőképpen néz ki:
- A Host-1 Broadcast címre küld ARP kérést az ő hálózatában.
- A kérés eljut a Leaf switch-hez, és ahelyett, hogy továbbítaná ezt a kérést a gyár felé a Host-2 irányába — a Leaf maga válaszol, és megadja a szükséges IP-t és MAC-t.
Így a Broadcast kérés nem került a gyárba. De hogyan működhet ez, ha a Leaf csak a MAC címet ismeri?
Minden meglehetősen egyszerű, az EVPN route-type 2 a MAC cím mellett el tudja küldeni a MAC/IP párost is. Ehhez a Leaf-en IP címet kell beállítani a VLAN-ban. Felmerül a kérdés, milyen IP-t adjunk meg? A Nexuson lehetőség van arra, hogy egy elosztott (azonos) címet hozzunk létre az összes kapcsolón:
feature interface-vlan
fabric forwarding anycast-gateway-mac 0001.0001.0001 ! beállítjuk a virtuális mac-et az elosztott átjáró létrehozásához az összes kapcsolón
interface Vlan10
no shutdown
ip address 192.168.10.254/24 ! az összes Leaf-en azonos IP-t állítunk be
fabric forwarding mode anycast-gateway ! mondjuk, hogy használjuk a virtuális mac-etÍgy a hosztok szempontjából a hálózat a következőképpen fog kinézni:
Ellenőrizzük a BGP l2route evpn-t
Leaf11# sh bgp l2vpn evpn
Hálózat Következő ugrás Metrika LocPrf Súly Út
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.21 100 32768 i
*>i[2]:[0]:[0]:[48]:[5001.0008.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.0008.0007]:[32]:[192.168.10.20]/248
10.255.1.10 100 0 i
*>i 10.255.1.10 100 0 i
Route Distinguisher: 10.255.1.21:32777
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 i
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.10.20]/248
*>i 10.255.1.20 100 0 iA parancs kimenetéből látható, hogy az EVPN route-type 2-ben a MAC mellett most már a hoszt IP címe is látható.
Visszatérve a suppress-arp beállításra. Ezt a beállítást minden VNI-nél külön kell engedélyezni:
interface nve1
member vni 10000
suppress-arpEzután némi nehézség merül fel:
- E funkció működéséhez szükség van helyre a TCAM memóriában. Példát mutatok a suppress-arp beállítására:
hardware access-list tcam region arp-ether 256Ehhez a beállításhoz double-wide szükséges. Tehát ha 256-ot állít be, akkor a TCAM-ban 512-t kell felszabadítania. A TCAM beállítása túlnyúlik ezen a cikken, mivel a TCAM beállítása csak az Ön által felállított feladattól függ, és eltérhet egyik hálózatról a másikra.
- A suppress-arp bevezetését minden Leaf switch-en el kell végezni. Azonban nehézségek merülhetnek fel a VPC tartományban lévő Leaf párok beállításánál. A TCAM módosítása esetén a párok közötti konzisztencia megszakadhat, és az egyik node működésképtelenné válhat. A TCAM beállításának alkalmazásához esetleg szükség lehet az eszköz újraindítására.
Ennek eredményeként érdemes jól átgondolni, hogy a jelen helyzetben érdemes-e ezt a beállítást egy működő gyárban bevezetni.
Ezzel befejezzük a ciklus első részét. A következő részben a VxLAN gyárakon keresztüli routolást fogjuk megvizsgálni, különböző VRF-ekkel elkülönített hálózatokkal.
Most pedig mindenkit meghívlak a , amely keretében részletesen beszámolok a tanfolyamról. Az első 20 résztvevő, akik regisztrálnak erre a webináriumra, elektronikus úton 1-2 napon belül kedvezményről szóló bizonyítványt kapnak.
Forrás: habr.com
