Përshëndetje, habr. Aktualisht jam drejtuese e kursit për kursin e Inxhinierit të Rrjetit në OTUS.
Në pritje të fillimit të një regjistrimi të ri për kursin , Unë kam përgatitur një seri artikujsh mbi teknologjinë VxLAN EVPN.
Ekziston një sasi e madhe materialesh se si funksionon VxLAN EVPN, kështu që unë dua të mbledh detyra dhe praktika të ndryshme për zgjidhjen e problemeve në një qendër moderne të të dhënave.
Në pjesën e parë të serisë për teknologjinë VxLAN EVPN, dua të shikoj një mënyrë për të organizuar lidhjen L2 midis hosteve në krye të një rrjeti.
Të gjithë shembujt do të kryhen në një Cisco Nexus 9000v, të montuar në topologjinë Spine-Leaf. Ne nuk do të ndalemi në ngritjen e një rrjeti Underlay në këtë artikull.
- Rrjeti i nënshtresës
- BGP peering për adresën e familjes l2vpn evpn
- Vendosja e NVE
- Suppress-arp
Rrjeti i nënshtresës
Topologjia e përdorur është si më poshtë:
Le të vendosim adresimin në të gjitha pajisjet:
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.20Le të kontrollojmë nëse ka lidhje IP midis të gjitha pajisjeve:
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, intraLe të kontrollojmë që domeni VPC është krijuar dhe të dy çelësat kanë kaluar kontrollin e konsistencës dhe cilësimet në të dy nyjet janë identike:
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
Më në fund, mund të vazhdoni te konfigurimi i rrjetit Overlay.
Si pjesë e artikullit, është e nevojshme të organizoni një rrjet midis hosteve, siç tregohet në diagramin më poshtë:
Për të konfiguruar një rrjet Overlay, duhet të aktivizoni BGP në çelsat Spine dhe Leaf me mbështetje për familjen l2vpn evpn:
feature bgp
nv overlay evpnMë pas, ju duhet të konfiguroni BGP peering midis Leaf dhe Spine. Për të thjeshtuar konfigurimin dhe optimizuar shpërndarjen e informacionit të rrugëzimit, ne konfigurojmë Spine si një server Route-Reflector. Ne do t'i shkruajmë të gjitha Leaf në konfigurim duke përdorur shabllone për të optimizuar konfigurimin.
Pra, cilësimet në Spine duken kështu:
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 LEAFKonfigurimi në çelësin e gjetheve duket i ngjashëm:
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 SPINENë Spine, le të kontrollojmë shikimin me të gjithë çelësat e fletës:
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 0Siç mund ta shihni, nuk kishte probleme me BGP. Le të kalojmë në konfigurimin e VxLAN. Konfigurimi i mëtejshëm do të bëhet vetëm në anën e gjetheve të çelsave. Spine vepron vetëm si thelbi i rrjetit dhe është i përfshirë vetëm në transmetimin e trafikut. E gjithë puna e kapsulimit dhe përcaktimit të rrugës ndodh vetëm në çelësat e gjetheve.
Vendosja e NVE
NVE - ndërfaqe virtuale e rrjetit
Para fillimit të konfigurimit, le të prezantojmë disa terminologji:
VTEP - Vitual Tunnel End Point, pajisja në të cilën fillon ose përfundon tuneli VxLAN. VTEP nuk është domosdoshmërisht ndonjë pajisje rrjeti. Një server që mbështet teknologjinë VxLAN mund të veprojë gjithashtu si server. Në topologjinë tonë, të gjithë ndërprerësit Leaf janë VTEP.
VNI - Virtual Network Index - identifikuesi i rrjetit brenda VxLAN. Një analogji mund të nxirret me VLAN. Megjithatë, ka disa dallime. Kur përdorni një strukturë, VLAN-et bëhen unike vetëm brenda një ndërprerës Leaf dhe nuk transmetohen nëpër rrjet. Por çdo VLAN mund të ketë një numër VNI të lidhur me të, i cili tashmë transmetohet përmes rrjetit. Si duket dhe si mund të përdoret do të diskutohet më tej.
Le të aktivizojmë funksionin e teknologjisë VxLAN dhe aftësinë për të lidhur numrat VLAN me një numër VNI:
feature nv overlay
feature vn-segment-vlan-basedLe të konfigurojmë ndërfaqen NVE, e cila është përgjegjëse për funksionimin e VxLAN. Kjo ndërfaqe është përgjegjëse për kapsulimin e kornizave në kokat e VxLAN. Ju mund të vizatoni një analogji me ndërfaqen e tunelit për GRE:
interface nve1
no shutdown
host-reachability protocol bgp ! используем BGP для передачи маршрутной информации
source-interface loopback0 ! интерфейс с которого отправляем пакеты loopback0Në çelësin Leaf-21 gjithçka krijohet pa probleme. Megjithatë, nëse kontrollojmë daljen e komandës show nve peers, atëherë do të jetë bosh. Këtu ju duhet të ktheheni në konfigurimin VPC. Ne shohim se Leaf-11 dhe Leaf-12 punojnë në çifte dhe janë të bashkuara nga një domen VPC. Kjo na jep situatën e mëposhtme:
Host-2 dërgon një kornizë drejt Leaf-21 në mënyrë që ta transmetojë atë përmes rrjetit drejt Host-1. Sidoqoftë, Leaf-21 sheh që adresa MAC e Host-1 është e aksesueshme përmes dy VTEP-ve njëherësh. Çfarë duhet të bëjë Leaf-21 në këtë rast? Në fund të fundit, kjo do të thotë që një lak mund të shfaqet në rrjet.
Për të zgjidhur këtë situatë, ne kemi nevojë që Leaf-11 dhe Leaf-12 të veprojnë gjithashtu si një pajisje brenda fabrikës. Zgjidhja është mjaft e thjeshtë. Në ndërfaqen Loopback nga e cila ndërtojmë tunelin, shtoni një adresë dytësore. Adresa dytësore duhet të jetë e njëjtë në të dy VTEP-të.
interface loopback0
ip add 10.255.1.10/32 secondaryKështu, nga këndvështrimi i VTEP-ve të tjera, marrim topologjinë e mëposhtme:
Kjo do të thotë, tani tuneli do të ndërtohet midis adresës IP të Leaf-21 dhe IP-së virtuale midis dy Leaf-11 dhe Leaf-12. Tani nuk do të ketë probleme për të mësuar adresën MAC nga dy pajisje dhe trafiku mund të lëvizë nga një VTEP në tjetrin. Cili nga dy VTEP-të do të përpunojë trafikun vendoset duke përdorur tabelën e kursit në 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, intraSiç mund ta shihni më lart, adresa 10.255.1.10 është e disponueshme menjëherë përmes dy hop-eve Next.
Në këtë fazë, ne jemi marrë me lidhjen bazë. Le të kalojmë në konfigurimin e ndërfaqes NVE:
Le të aktivizojmë menjëherë Vlan 10 dhe ta lidhim atë me VNI 10000 në çdo fletë për hostet. Le të vendosim një tunel L2 midis hosteve
vlan 10 ! Включаем VLAN на всех VTEP подключенных к необходимым хостам
vn-segment 10000 ! Ассоциируем VLAN с номер VNI
interface nve1
member vni 10000 ! Добавляем VNI 10000 для работы через интерфейс NVE. для инкапсуляции в VxLAN
ingress-replication protocol bgp ! указываем, что для распространения информации о хосте используем BGPTani le të kontrollojmë kolegët nve dhe tabelën për 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 iMë sipër ne shohim vetëm itinerare EVPN të tipit 3. Ky lloj itinerari flet për peer(Leaf), por ku janë pritësit tanë?
Gjë është se informacioni në lidhje me hostet MAC transmetohet përmes rrugës EVPN të tipit 2
Për të parë hostet tanë, duhet të konfiguroni tipin 2 të rrugës EVPN:
evpn
vni 10000 l2
route-target import auto ! в рамках данной статьи используем автоматический номер для route-target
route-target export autoLe të bëjmë ping nga Host-2 në 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 msDhe më poshtë mund të shohim se tipi i rrugës 2 me adresën MAC pritës u shfaq në tabelën BGP - 5001.0007.0007 dhe 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 iMë pas, mund të shihni informacione të detajuara mbi Përditësimin, në të cilin keni marrë informacion në lidhje me hostin MAC. Më poshtë nuk është i gjithë prodhimi i komandës.
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
<........>Le të shohim se si duken kornizat kur kalohen nëpër fabrikë:
Suppress-ARP
E shkëlqyeshme, ne tani kemi komunikim L2 midis nikoqirëve dhe mund të përfundojmë atje. Megjithatë, jo gjithçka kaq e thjeshtë. Për sa kohë që kemi pak mikpritës, nuk do të ketë probleme. Por le të imagjinojmë një situatë ku kemi qindra e mijëra mikpritës. Çfarë problemi mund të përballemi?
Ky problem është trafiku BUM (Transmetim, Unicast Unknown, Multicast). Në këtë artikull, ne do të shqyrtojmë mundësinë e trajtimit të trafikut të transmetimit.
Gjeneruesi kryesor i transmetimit në rrjetet Ethernet janë vetë hostet përmes protokollit ARP.
Nexus zbaton mekanizmin e mëposhtëm për të luftuar kërkesat ARP - suppress-arp.
Kjo veçori funksionon si më poshtë:
- Host-1 dërgon një kërkesë APR në adresën e transmetimit të rrjetit të tij.
- Kërkesa arrin në çelësin Leaf dhe në vend që ta kalojë këtë kërkesë më tej tek pëlhura drejt Host-2, Leaf përgjigjet vetë dhe tregon IP-në dhe MAC-në e kërkuar.
Kështu, kërkesa për Transmetim nuk shkoi në fabrikë. Por si mund të funksionojë kjo nëse Leaf di vetëm adresën MAC?
Gjithçka është mjaft e thjeshtë, EVPN route-type 2, përveç adresës MAC, mund të transmetojë një kombinim MAC/IP. Për ta bërë këtë, duhet të konfiguroni një adresë IP në VLAN në Leaf. Lind pyetja, çfarë IP duhet të vendos? Në nexus është e mundur të krijohet një adresë e shpërndarë (e njëjtë) në të gjithë çelësat:
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 macKështu, nga këndvështrimi i pritësve, rrjeti do të duket si ky:
Le të kontrollojmë 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
<......>Nga dalja e komandës mund të shihni se në EVPN route-type 2, përveç MAC, ne tani shohim edhe adresën IP të hostit.
Le të kthehemi te konfigurimi suppress-arp. Ky cilësim aktivizohet për çdo VNI veç e veç:
interface nve1
member vni 10000
suppress-arpPastaj lind një kompleksitet:
- Që kjo veçori të funksionojë, kërkohet hapësirë në kujtesën TCAM. Këtu është një shembull i cilësimeve për suppress-arp:
hardware access-list tcam region arp-ether 256Ky cilësim do të kërkojë dyfish të gjerë. Kjo do të thotë, nëse vendosni 256, atëherë duhet të lironi 512 në TCAM. Vendosja e TCAM është përtej qëllimit të këtij neni, pasi konfigurimi i TCAM varet vetëm nga detyra që ju është caktuar dhe mund të ndryshojë nga një rrjet në tjetrin.
- Zbatimi i suppress-arp duhet të bëhet në të gjithë çelësat Leaf. Sidoqoftë, kompleksiteti mund të lindë kur konfiguroni çiftet e gjetheve që banojnë në një domen VPC. Nëse TCAM ndryshohet, konsistenca midis çifteve do të prishet dhe një nyje mund të hiqet jashtë funksionit. Për më tepër, mund të kërkohet një rindezje e pajisjes për të aplikuar cilësimin e ndryshimit të TCAM.
Si rezultat, duhet të konsideroni me kujdes nëse, në situatën tuaj, ia vlen ta zbatoni këtë cilësim në një fabrikë që funksionon.
Kështu përfundon pjesa e parë e serisë. Në pjesën tjetër do të shikojmë drejtimin përmes një pëlhure VxLAN me ndarjen e rrjeteve në VRF të ndryshme.
Dhe tani i ftoj të gjithë , në kuadër të së cilës do t'ju tregoj në detaje për kursin. 20 pjesëmarrësit e parë që do të regjistrohen në këtë webinar do të marrin një Certifikatë Zbritje përmes emailit brenda 1-2 ditëve pas transmetimit.
Burimi: www.habr.com