Halló, habr. Ég er sem stendur námskeiðsstjóri fyrir netverkfræðinganámskeiðið hjá OTUS.
Í aðdraganda nýrrar innritunar á námskeiðið
Það er mikið magn af efni um hvernig VxLAN EVPN virkar, svo ég vil safna ýmsum verkefnum og aðferðum til að leysa vandamál í nútíma gagnaveri.
Í fyrsta hluta seríunnar um VxLAN EVPN tækni vil ég skoða leið til að skipuleggja L2 tengingu milli gestgjafa ofan á netkerfi.
Öll dæmin verða sýnd á Cisco Nexus 9000v, sett saman í Spine-Leaf svæðisfræðinni. Við munum ekki dvelja við að setja upp undirlagsnet í þessari grein.
- Undirlagsnet
- BGP peering fyrir heimilisfang-fjölskyldu l2vpn evpn
- Uppsetning NVE
- Bæla-arp
Undirlagsnet
Staðfræðin sem notuð er er sem hér segir:
Við skulum stilla veffang á öllum tækjum:
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.20
Við skulum athuga hvort það sé IP-tenging á milli allra tækja:
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, intra
Við skulum athuga hvort VPC lénið hafi verið búið til og báðir rofarnir hafi staðist samræmisskoðunina og stillingarnar á báðum hnútum eru eins:
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 1
BGP skygging
Að lokum geturðu haldið áfram að setja upp yfirborðsnetið.
Sem hluti af greininni er nauðsynlegt að skipuleggja net milli gestgjafa, eins og sýnt er á skýringarmyndinni hér að neðan:
Til að stilla Overlay net þarftu að virkja BGP á Spine og Leaf rofanum með stuðningi fyrir l2vpn evpn fjölskylduna:
feature bgp
nv overlay evpn
Næst þarftu að stilla BGP peering á milli laufs og hryggs. Til að einfalda uppsetningu og hámarka dreifingu leiðarupplýsinga stillum við Spine sem Route-Reflector miðlara. Við munum skrifa allt Leaf í stillingunni með því að nota sniðmát til að fínstilla uppsetninguna.
Þannig að stillingarnar á Spine líta svona út:
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 LEAF
Uppsetningin á Leaf rofanum lítur svipað út:
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 SPINE
Á Spine skulum við athuga peering með öllum Leaf rofum:
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 0
Eins og þú sérð voru engin vandamál með BGP. Við skulum halda áfram að setja upp VxLAN. Frekari stillingar verða aðeins gerðar á blaðhlið rofana. Hryggurinn virkar aðeins sem kjarni netsins og tekur aðeins þátt í að senda umferð. Öll umgerð og brautarákvörðunarvinna fer aðeins fram á laufrofum.
Uppsetning NVE
NVE - net sýndarviðmót
Áður en uppsetningin hefst skulum við kynna nokkur hugtök:
VTEP - Vitual Tunnel End Point, tækið sem VxLAN göngin byrja eða endar á. VTEP er ekki endilega hvaða nettæki sem er. Miðlari sem styður VxLAN tækni getur einnig virkað sem þjónn. Í staðfræði okkar eru allir Leaf rofar VTEP.
VNI - Virtual Network Index - netauðkenni innan VxLAN. Hægt er að draga upp hliðstæðu með VLAN. Hins vegar er nokkur munur. Þegar efni er notað verða VLAN aðeins einstök innan eins blaðrofa og eru ekki send um netið. En hvert VLAN getur haft VNI númer tengt því, sem er þegar sent um netið. Nánar verður fjallað um hvernig það lítur út og hvernig hægt er að nota það.
Við skulum virkja eiginleikann fyrir VxLAN tækni til að virka og getu til að tengja VLAN númer við VNI númer:
feature nv overlay
feature vn-segment-vlan-based
Við skulum stilla NVE viðmótið, sem ber ábyrgð á rekstri VxLAN. Þetta viðmót er ábyrgt fyrir því að umlykja ramma í VxLAN hausum. Þú getur dregið upp hliðstæðu við Tunnel tengi fyrir GRE:
interface nve1
no shutdown
host-reachability protocol bgp ! используем BGP для передачи маршрутной информации
source-interface loopback0 ! интерфейс с которого отправляем пакеты loopback0
Á Leaf-21 rofanum er allt búið til án vandræða. Hins vegar, ef við athugum úttak skipunarinnar show nve peers
, þá verður það tómt. Hér þarftu að fara aftur í VPC stillingar. Við sjáum að Leaf-11 og Leaf-12 vinna í pörum og eru sameinuð af VPC léni. Þetta gefur okkur eftirfarandi aðstæður:
Host-2 sendir einn ramma í átt að Leaf-21 þannig að hann sendir hann yfir netið í átt að Host-1. Hins vegar sér Leaf-21 að MAC vistfang Host-1 er aðgengilegt í gegnum tvö VTEP í einu. Hvað ætti Leaf-21 að gera í þessu tilfelli? Eftir allt saman þýðir þetta að lykkja gæti birst í netinu.
Til að leysa þessa stöðu þurfum við Leaf-11 og Leaf-12 til að virka líka sem eitt tæki innan verksmiðjunnar. Lausnin er frekar einföld. Á Loopback viðmótinu sem við byggjum göngin úr skaltu bæta við auka heimilisfangi. Auka heimilisfangið verður að vera það sama á báðum VTEP.
interface loopback0
ip add 10.255.1.10/32 secondary
Þannig, frá sjónarhóli annarra VTEPs, fáum við eftirfarandi staðfræði:
Það er, nú verða göngin byggð á milli IP tölu Leaf-21 og sýndar-IP milli tveggja Leaf-11 og Leaf-12. Nú verða engin vandamál að læra MAC vistfangið úr tveimur tækjum og umferð getur færst frá einum VTEP til annars. Hvaða af tveimur VTEPs mun vinna úr umferðinni er ákveðið með því að nota leiðartöfluna á Spine:
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, intra
Eins og þú sérð hér að ofan er heimilisfangið 10.255.1.10 fáanlegt strax í gegnum tvær Next-hops.
Á þessu stigi höfum við tekist á við grunntenginguna. Við skulum halda áfram að setja upp NVE viðmótið:
Kveikjum strax á Vlan 10 og tengjum það við VNI 10000 á hverju blaði fyrir gestgjafana. Við skulum setja upp L2 göng á milli gestgjafa
vlan 10 ! Включаем VLAN на всех VTEP подключенных к необходимым хостам
vn-segment 10000 ! Ассоциируем VLAN с номер VNI
interface nve1
member vni 10000 ! Добавляем VNI 10000 для работы через интерфейс NVE. для инкапсуляции в VxLAN
ingress-replication protocol bgp ! указываем, что для распространения информации о хосте используем BGP
Nú skulum við athuga nve jafningja og töfluna fyrir BGP EVPN:
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 i
Hér að ofan sjáum við aðeins EVPN leið-gerð 3. Þessi leið talar um jafningja(Leaf), en hvar eru gestgjafar okkar?
Málið er að upplýsingar um MAC vélarnar eru sendar í gegnum EVPN leið-gerð 2
Til þess að sjá gestgjafana okkar þarftu að stilla EVPN leið-gerð 2:
evpn
vni 10000 l2
route-target import auto ! в рамках данной статьи используем автоматический номер для route-target
route-target export auto
Við skulum smella frá Host-2 til Host-1:
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
Og hér að neðan getum við séð að leiðartegund 2 með MAC vistfangi gestgjafa birtist í BGP töflunni - 5001.0007.0007 og 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 i
Næst geturðu séð nákvæmar upplýsingar um Update, þar sem þú fékkst upplýsingar um MAC Host. Hér að neðan er ekki allt skipanaúttakið.
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
<........>
Við skulum sjá hvernig rammar líta út þegar þeir fara í gegnum verksmiðjuna:
Bældu-ARP
Frábært, við erum núna með L2 samskipti á milli gestgjafanna og gætum klárað þar. Hins vegar er ekki allt svo einfalt. Svo lengi sem við höfum fáa gestgjafa verða engin vandamál. En við skulum ímynda okkur aðstæður þar sem við höfum hundruð og þúsundir gestgjafa. Hvaða vandamál gætum við staðið frammi fyrir?
Þetta vandamál er BUM (Broadcast, Unknown Unicast, Multicast) umferð. Í þessari grein munum við íhuga möguleikann á að takast á við útsendingarumferð.
Helsti útsendingarrafallinn í Ethernet netkerfum eru gestgjafarnir sjálfir í gegnum ARP samskiptareglur.
Nexus innleiðir eftirfarandi kerfi til að berjast gegn ARP beiðnum - bæla-arp.
Þessi eiginleiki virkar sem hér segir:
- Host-1 sendir APR beiðni á útsendingarnetfang netsins.
- Beiðnin nær til Leaf rofans og í stað þess að senda þessa beiðni lengra í efnið í átt að Host-2, svarar Leaf sjálft og gefur til kynna nauðsynlega IP og MAC.
Þannig barst útvarpsbeiðnin ekki til verksmiðjunnar. En hvernig getur þetta virkað ef Leaf veit aðeins MAC vistfangið?
Allt er frekar einfalt, EVPN leið-gerð 2, auk MAC vistfangsins, getur sent MAC/IP samsetningu. Til að gera þetta þarftu að stilla IP tölu í VLAN á Leaf. Spurningin vaknar, hvaða IP ætti ég að stilla? Á nexus er hægt að búa til dreift (sama) heimilisfang á öllum rofum:
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
Þannig, frá sjónarhóli gestgjafanna, mun netið líta svona út:
Við skulum athuga BGP l2route evpn
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
<......>
Frá skipunarúttakinu geturðu séð að í EVPN leið-gerð 2, auk MAC, sjáum við nú einnig IP tölu gestgjafans.
Snúum okkur aftur að því að stilla suppress-arp. Þessi stilling er virkjuð fyrir hvert VNI fyrir sig:
interface nve1
member vni 10000
suppress-arp
Þá kemur upp smá flókið:
- Til að þessi eiginleiki virki þarf pláss í TCAM minni. Hér er dæmi um stillingar fyrir suppress-arp:
hardware access-list tcam region arp-ether 256
Þessi stilling mun krefjast tvöfaldrar breiddar. Það er, ef þú stillir 256, þá þarftu að losa 512 í TCAM. Uppsetning TCAM er utan gildissviðs þessarar greinar, þar sem uppsetning TCAM fer aðeins eftir því verkefni sem þér er úthlutað og getur verið mismunandi frá einu neti til annars.
- Innleiðing suppress-arp verður að fara fram á öllum Leaf rofum. Hins vegar getur flókið komið upp þegar stillt er á Leaf pör sem búa á VPC léni. Ef TCAM er breytt mun samkvæmni milli para rofna og einn hnút gæti verið tekinn úr notkun. Að auki gæti þurft að endurræsa tækið til að beita TCAM-breytingastillingunni.
Þess vegna þarftu að íhuga vandlega hvort, í þínum aðstæðum, sé þess virði að innleiða þessa stillingu í starfandi verksmiðju.
Þar með lýkur fyrsta hluta seríunnar. Í næsta hluta munum við skoða leið í gegnum VxLAN efni með aðskilnaði netkerfa í mismunandi VRF.
Og nú býð ég öllum til
Heimild: www.habr.com