Szia habr. Jelenleg a "Hálózatmérnök" tanfolyam vezetője vagyok az OTUS-nál.
A tanfolyamra való új beiratkozás kezdetére számítva , Cikksorozatot készítettem a VxLAN EVPN technológiáról.
A VxLAN EVPN működéséről hatalmas mennyiségű anyag áll rendelkezésre, ezért szeretnék összegyűjteni különféle feladatokat és gyakorlatokat a problémák megoldásához egy modern adatközpontban.
A VxLAN EVPN technológiai ciklus első részében egy módot szeretnék megvizsgálni az L2 kapcsolat megszervezésére a gazdagépek között a hálózati gyár tetején.
Az összes példát a Spine-Leaf topológiában összeállított Cisco Nexus 9000v készüléken hajtjuk végre. Ebben a cikkben nem foglalkozunk az Underlay hálózat beállításával.
- alátéthálózat
- BGP társviszony-létesítés a címcsaládhoz l2vpn evpn
- NVE beállítás
- Elnyom-arp
alátéthálózat
A használt topológia a következő:
Állítsuk be a címzést minden 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 ! Leaf-11 доступен чеерз два Spine
*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 ! Leaf-12 доступен чеерз два Spine
*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 létrejött-e a VPC tartomány, és mindkét kapcsoló átment-e a konzisztenciaellenőrzésen, és a beállítások mindkét csomóponton azonosak:
Leaf11# show vpc
vPC domain id : 1
Peer status : peer adjacency formed ok
vPC keep-alive status : peer is alive
Configuration consistency status : success
Per-vlan consistency status : success
Type-2 consistency status : success
vPC role : primary
Number of vPCs configured : 0
Peer Gateway : Disabled
Dual-active excluded VLANs : -
Graceful Consistency Check : Enabled
Auto-recovery status : Disabled
Delay-restore status : Timer is off.(timeout = 30s)
Delay-restore SVI status : Timer is off.(timeout = 10s)
Operational Layer3 Peer-router : Disabled
vPC status
----------------------------------------------------------------------------
Id Port Status Consistency Reason Active vlans
-- ------------ ------ ----------- ------ ---------------
5 Po5 up success success 1BGP peering
Végül továbbléphetünk az Overlay hálózat konfigurálására.
A cikk részeként hálózatot kell szervezni a gazdagépek között, az alábbi diagram szerint:
Overlay hálózat konfigurálásához engedélyeznie kell a BGP-t a Spine és Leaf kapcsolókon az l2vpn evpn család támogatásával:
feature bgp
nv overlay evpnEzután be kell állítania a BGP peeringet a Leaf és a Spine között. A konfiguráció egyszerűsítése és az útválasztási információk elosztásának optimalizálása érdekében a Spine-t Route-Reflector szerverként konfiguráljuk. A konfiguráció optimalizálása érdekében sablonokon keresztül beírjuk az összes Leaf-et a konfigurációba.
Tehát a Spine beállításai így néznek 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 kapcsoló beállítása hasonlóan 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-n ellenőrizze a társviszony-létesítést az összes Leaf kapcsolóval:
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 0Amint látja, nem volt probléma a BGP-vel. Térjünk át a VxLAN beállítására. A további konfigurálás csak a Leaf kapcsolók oldalán történik. A gerinc csak a hálózat magjaként működik, és csak a forgalom továbbításában vesz részt. A tokozással és az útvonal meghatározásával kapcsolatos minden munka csak a Leaf kapcsolókon történik.
NVE beállítás
NVE - hálózati virtuális interfész
A beállítás megkezdése előtt mutassunk be néhány terminológiát:
VTEP – Vitual Tunnel End Point, az az eszköz, amelyen a VxLAN alagút kezdődik vagy véget ér. A VTEP nem feltétlenül bármilyen hálózati eszköz. A VxLAN technológiát támogató szerver is működhet. Topológiánkban minden Leaf kapcsoló VTEP.
VNI – Virtual Network Index – hálózati azonosító a VxLAN-on belül. Hasonló analógiát vonhatunk a VLAN-nal. Van azonban néhány eltérés. Szöveg használatakor a VLAN-ok csak egy Leaf switchen belül válnak egyedivé, és nem továbbítják őket a hálózaton. De minden VLAN társítható egy VNI-számhoz, amelyet már továbbítottak a hálózaton. Hogy néz ki és hogyan használható, az alábbiakban lesz szó.
Engedélyezze a funkciót a VxLAN technológia működéséhez és a VLAN-számok VNI-számokhoz való társításának lehetőségét:
feature nv overlay
feature vn-segment-vlan-basedÁllítsuk be az NVE interfészt, amely a VxLAN működéséért felel. Ez az interfész felelős a keretek VxLAN-fejlécekbe való beágyazásáért. Analógiát vonhat a GRE Tunnel interfészével:
interface nve1
no shutdown
host-reachability protocol bgp ! используем BGP для передачи маршрутной информации
source-interface loopback0 ! интерфейс с которого отправляем пакеты loopback0A Leaf-21 kapcsolón minden probléma nélkül létrejön. Ha azonban ellenőrizzük a parancs kimenetét show nve peers, akkor üres lesz. Itt vissza kell térnie a VPC beállításához. Látjuk, hogy a Leaf-11 és a Leaf-12 egy VPC tartomány párosítja és egyesíti. Ez a következő helyzetet eredményezi:
A Host-2 egy keretet küld a Leaf-21-nek, hogy a hálózaton keresztül elküldje a Host-1-nek. A Leaf-21 azonban úgy látja, hogy a Host-1 MAC-címe egyszerre két VTEP-n keresztül elérhető. Mit tegyen a Leaf-21 ebben az esetben? Végül is ez azt jelenti, hogy egy hurok jelenhet meg a hálózatban.
A helyzet megoldásához szükséges, hogy a Leaf-11 és a Leaf-12 egy eszközként működjenek a gyáron belül. Egész egyszerűen megoldódik. A Loopback felületen, amelyből az alagutat építjük, adja hozzá a másodlagos címet. A másodlagos címnek azonosnak kell lennie mindkét VTEP-n.
interface loopback0
ip add 10.255.1.10/32 secondaryÍgy a többi VTEP szempontjából a következő topológiát kapjuk:
Vagyis 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 között épül fel. Most már nem lesz probléma a MAC-cím megtanulásával két eszközről, és a forgalom átvihető egyik VTEP-ről a másikra. A két VTEP közül melyik fogja feldolgozni a forgalmat, a Spine útválasztási táblázata alapján dönthető el:
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, intraMint fentebb látható, a 10.255.1.10 cím azonnal elérhető két Next-hop-on keresztül.
Ebben a szakaszban kitaláltuk az alapvető csatlakozást. Térjünk át az NVE interfész beállítására:
Azonnal engedélyezzük a Vlan 10-et, és társítjuk a VNI 10000-hez minden Leaf-en a gazdagépek számára. Hozzon létre egy L2 alagutat a gazdagépek között
vlan 10 ! Включаем VLAN на всех VTEP подключенных к необходимым хостам
vn-segment 10000 ! Ассоциируем VLAN с номер VNI
interface nve1
member vni 10000 ! Добавляем VNI 10000 для работы через интерфейс NVE. для инкапсуляции в VxLAN
ingress-replication protocol bgp ! указываем, что для распространения информации о хосте используем BGPMost nézzük meg a BGP EVPN nve társait és táblázatát:
Leaf21# sh nve peers
Interface Peer-IP State LearnType Uptime Router-Mac
--------- --------------- ----- --------- -------- -----------------
nve1 10.255.1.10 Up CP 00:00:41 n/a ! Видим что peer доступен с secondary адреса
Leaf11# sh bgp l2vpn evpn
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.255.1.11:32777 (L2VNI 10000) ! От кого именно пришел этот l2VNI
*>l[3]:[0]:[32]:[10.255.1.10]/88 ! EVPN route-type 3 - показывает нашего соседа, который так же знает об l2VNI10000
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 útvonal-típusú 3-as útvonalakat látjuk. Az ilyen típusú útvonalak peer-ről beszélnek (Leaf), de hol vannak a házigazdáink?
És a helyzet az, hogy a MAC-állomásokról szóló információkat a 2-es EVPN-útvonalon keresztül továbbítják
A gazdagépeink megtekintéséhez konfigurálnia kell a 2-es EVPN útvonaltípust:
evpn
vni 10000 l2
route-target import auto ! в рамках данной статьи используем автоматический номер для route-target
route-target export autoPingeljü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 msÉs lent láthatjuk, hogy a BGP táblázatban megjelent a 2. útvonaltípus a gazdagépek MAC-címével - 5001.0007.0007 és 5001.0008.0007.
Leaf11# 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 ! evpn route-type 2 и mac адрес хоста 1
10.255.1.10 100 32768 i
*>i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216 ! evpn route-type 2 и mac адрес хоста 2
* i 10.255.1.20 100 0 i
*>l[3]:[0]:[32]:[10.255.1.10]/88
10.255.1.10 100 32768 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 iEzután részletes információkat láthat a Frissítésről, amelyben információkat kapott a MAC gazdagépről. Az alábbiakban nem látható a parancs teljes kimenete
Leaf21# sh bgp l2vpn evpn 5001.0007.0007
BGP routing table information for VRF default, address family L2VPN EVPN
Route Distinguisher: 10.255.1.11:32777 ! отправил Update с MAC Host. Не виртуальный адрес VPC, а адрес Leaf
BGP routing table entry for [2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]/216,
version 1507
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 labe
led nexthop
AS-Path: NONE, path sourced internal to AS
10.255.1.10 (metric 81) from 10.255.1.102 (10.255.1.102) ! с кем именно строим VxLAN тоннель
Origin IGP, MED not set, localpref 100, weight 0
Received label 10000 ! Номер VNI, который ассоциирован с VLAN, в котором находится Host
Extcommunity: RT:65001:10000 SOO:10.255.1.10:0 ENCAP:8 ! Тут видно, что RT сформировался автоматически на основе номеров AS и VNI
Originator: 10.255.1.11 Cluster list: 10.255.1.102
<........>Nézzük meg, hogyan néznek ki a keretek, amikor áthaladnak a gyáron:
Suppress-ARP
Remek, van egy L2 kapcsolatunk a gazdagépek között, és ez lehet a vége. Azonban nem minden olyan egyszerű. Amíg kevés vendéglátónk lesz, addig nem lesz gond. De képzeljünk el olyan helyzeteket, hogy több száz és ezer vendéglátónk van. Milyen problémával szembesülhetünk?
Ez a probléma a BUM (Broadcast, Unknown Unicast, Multicast) forgalom. E cikk keretében megvizsgáljuk a sugárzott forgalom elleni küzdelem lehetőségét.
Az Ethernet hálózatok fő Broadcast generátora maguk a gazdagépek az ARP protokollon keresztül.
A Nexus a következő mechanizmust valósítja meg az ARP-kérések kezelésére - suppress-arp.
Ez a funkció a következőképpen működik:
- A Host-1 APR kérést küld a hálózatának Broadcast címére.
- A kérés eléri a Leaf kapcsolót, és ahelyett, hogy továbbadná ezt a kérést a gyárnak a Host-2 felé, a Leaf önmagának válaszol, és jelzi a kívánt IP-t és MAC-t.
Így a Broadcast kérés nem ment a gyárba. De hogyan működhet ez, ha a Leaf csak a MAC-címet tudja?
Minden nagyon egyszerű, az EVPN route-type 2 a MAC-címen kívül MAC / IP-köteget is tud továbbítani. Ehhez a Leaf-et IP-címmel kell konfigurálni a VLAN-ban. Felmerül a kérdés, hogy milyen IP-t kérdezzek? Nexuson lehetőség van elosztott (ugyanolyan) cím létrehozására az összes kapcsolón:
feature interface-vlan
fabric forwarding anycast-gateway-mac 0001.0001.0001 ! задаем virtual mac для создания распределенного шлюза между всеми коммутаторами
interface Vlan10
no shutdown
ip address 192.168.10.254/24 ! на всех Leaf задаем одинаковый IP
fabric forwarding mode anycast-gateway ! говорим использовать Virtual macÍgy a gazdagépek szempontjából a hálózat így fog kinézni:
Ellenőrizze a BGP l2route evpn-t
Leaf11# 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.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 i
<......>A parancs kimenetéből látható, hogy az EVPN route-type 2-ben a MAC mellett most már a gazdagép IP címét is látjuk.
Térjünk vissza a supress-arp beállításhoz. Ez a beállítás minden VNI-hez külön engedélyezve van:
interface nve1
member vni 10000
suppress-arpAztán van némi nehézség:
- Ez a funkció helyet igényel a TCAM memóriában. Mondok egy példát a supress-arp beállítására:
hardware access-list tcam region arp-ether 256Ez a beállítás dupla szélességet igényel. Vagyis ha a 256-ot állítja be, akkor a TCAM-ban fel kell szabadítani az 512-t. A TCAM beállítása nem tartozik ennek a cikknek a körébe, mivel a TCAM beállítása csak az Önhöz rendelt feladattól függ, és hálózatonként eltérő lehet.
- A supress-arp megvalósítását minden Leaf kapcsolón el kell végezni. Bonyolultság merülhet fel azonban, ha VPC tartományban található Leaf párokon konfigurál. A TCAM megváltoztatásakor a párok közötti konzisztencia megszakad, és az egyik csomópont kikerülhet a szolgálatból. Ezenkívül a TCAM-módosítási beállítás alkalmazásához az eszköz újraindítására lehet szükség.
Ennek eredményeként alaposan meg kell fontolnia, hogy az Ön helyzetében megéri-e ezt a beállítást egy működő gyárban alkalmazni.
Ezzel lezárult a ciklus első része. A következő részben megfontoljuk a VxLAN gyáron keresztül történő útválasztást, a különböző VRF-ek közötti hálózati szétválasztással.
És most mindenkit meghívok erre , amelyben részletesen szólok a tanfolyamról. Az első 20 résztvevő, aki regisztrál erre a webináriumra, a közvetítést követő 1-2 napon belül e-mailben kedvezményes igazolást kap.
Forrás: will.com