Përshëndetje, habr. Aktualisht jam drejtori i kursit "Inxhinier Rrjeti" në OTUS.
Në prag të fillimit të një grupi të ri për kursin , kam përgatitur një cikël artikujsh mbi teknologjinë VxLAN EVPN.
Ekziston një sasi e madhe materialesh mbi funksionimin e VxLAN EVPN, prandaj dua të grumbulloj detyra të ndryshme dhe praktika për zgjidhjen e tyre në një Qendër të Të Dhënave moderne.

Në pjesën e parë të ciklit mbi teknologjinë VxLAN EVPN, do të shqyrtoj mënyrën e organizimit të lidhjes L2 midis hosteve mbi fabrikën rrjet.
Të gjitha shembujt do të zbatohen në Cisco Nexus 9000v, të organizuar në një topologji Spine-Leaf. Nuk do të ndalemi në konfigurimin e rrjetit Underlay brenda këtij artikulli.
- Rrjeti Underlay
- BGP peer për address-family l2vpn evpn
- Konfigurimi i NVE
- Supress-arp
Rrjeti Underlay
Topologjia e përdorur duket si më poshtë:

Do të caktojmë 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.20Do të verifikojmë se ka lidhje IP midis të gjitha pajisjeve:
Leaf21# sh ip route
10.255.1.11/32, ubest/mbest: 2/0 ! Leaf-11 i aksesueshëm përmes dy Spine
*përmes 10.255.1.101, Eth1/4, [110/81], 00:00:03, ospf-UNDERLAY, intra
*përmes 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 i aksesueshëm përmes dy Spine
*përmes 10.255.1.101, Eth1/4, [110/81], 00:00:03, ospf-UNDERLAY, intra
*përmes 10.255.1.102, Eth1/3, [110/81], 00:00:03, ospf-UNDERLAY, intra
10.255.1.21/32, ubest/mbest: 2/0, i lidhur
*përmes 10.255.1.22, Lo0, [0/0], 00:02:20, lokal
*përmes 10.255.1.22, Lo0, [0/0], 00:02:20, direkt
10.255.1.101/32, ubest/mbest: 1/0
*përmes 10.255.1.101, Eth1/4, [110/41], 00:00:06, ospf-UNDERLAY, intra
10.255.1.102/32, ubest/mbest: 1/0
*përmes 10.255.1.102, Eth1/3, [110/41], 00:00:03, ospf-UNDERLAY, intraDo të kontrollojmë nëse domeni VPC është krijuar dhe të dy switch-at kanë kaluar verifikimin e konsistencës dhe konfigurimi në të dy nodet është identik:
Leaf11# show vpc
vPC domain id : 1
Peer status : statusi i fqinjit është formuar në rregull
vPC keep-alive status : fqinj është aktiv
Configuration consistency status : sukses
Per-vlan consistency status : sukses
Type-2 consistency status : sukses
vPC role : primar
Number of vPCs configured : 0
Peer Gateway : i Ăaktivizuar
Dual-active excluded VLANs : -
Graceful Consistency Check : Aktivizuar
Auto-recovery status : i Ăaktivizuar
Delay-restore status : Timer është i fikur.(timeout = 30s)
Delay-restore SVI status : Timer është i fikur.(timeout = 10s)
Operational Layer3 Peer-router : i Ăaktivizuar
vPC status
----------------------------------------------------------------------------
Id Port Status Konsistenca Arsye VLAN-t aktivë
-- ------------ ------ ----------- ------ ---------------
5 Po5 up sukses sukses 1BGP peer
Mund të kalojmë në konfigurimin e rrjetit Overlay.
Brenda këtij artikulli duhet të organizohet një rrjet midis hosteve, siç ilustrohet në diagramin më poshtë:

Për të konfiguruar rrjetin Overlay, nevojitet të aktivizojmë BGP me mbështetje për familjen l2vpn evpn në switch-at Spine dhe Leaf:
feature bgp
nv overlay evpnPastaj duhet të konfigurojmë BGP peer midis Leaf dhe Spine. Për të thjeshtuar konfigurimin dhe për të optimizuar përhapjen e informacionit të rrugës, Spine do të konfigurohet si server Route-Reflector. Të gjitha Leaf-t do të shënohen në konfigurim përmes shablloneve, për të optimizuar konfigurimin.
Kështu që konfigurimet në Spine duken si më poshtë:
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ë switch-in Leaf duket në mënyrë të ngjashme:
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 do të verifikojmë lidhjen me të gjitha switch-at Leaf:
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ç po shohim, nuk kishte probleme me BGP. Le të kalojmë në konfigurimin e VxLAN. Konfigurimi në vazhdim do të bëhet vetëm në anën e switch-ave Leaf. Spine vepron vetëm si bërthama e rrjetit dhe merret vetëm me transmetimin e trafikut. Të gjitha operacionet e enkriptimit dhe përcaktimit të rrugës ndodhin vetëm në switch-at Leaf.
Konfigurimi i NVE
NVE â ndĂ«rfaqja virtuale e rrjetit
Para fillimit të konfigurimit, le të prezantojmë pak terminologji:
VTEP â Pika pĂ«rfundimtare e Tunelit Virtual, pajisje nĂ« tĂ« cilĂ«n fillon ose pĂ«rfundon tuneli VxLAN. VTEP nuk Ă«shtĂ« domosdoshmĂ«risht njĂ« pajisje rrjetesh. Po ashtu mund tĂ« jetĂ« njĂ« server qĂ« mbĂ«shtet teknologjinĂ« VxLAN. NĂ« topologjinĂ« tonĂ«, tĂ« gjitha switch-at Leaf janĂ« VTEP.
VNI â Indeksi i Rrjetit Virtual â identifikuesi i rrjetit brenda VxLAN. Mund tĂ« bĂ«het njĂ« krahasim me VLAN-in. MegjithatĂ«, ka disa ndryshime. Kur pĂ«rdoret fabrika, VLAN-t bĂ«hen unike vetĂ«m brenda njĂ« switch-i Leaf dhe nuk transmetohen pĂ«rmes rrjetit. Por secilit VLAN mund t'i asociohet njĂ« numĂ«r VNI, i cili tashmĂ« transmetohet pĂ«rmes rrjetit. Si duket kjo dhe si mund tĂ« pĂ«rdoret, do tĂ« shqyrtohet mĂ« vonĂ«.
Të aktivizojmë funksionin për të mbështetur teknologjinë VxLAN dhe mundësinë e asociimit të numrave VLAN me numrin VNI:
feature nv overlay
feature vn-segment-vlan-basedDo të konfigurojmë ndërfaqen NVE, e cila është përgjegjëse për funksionimin e VxLAN. Kjo ndërfaqe merret me inkapsulimin e cadra në titujt VxLAN. Mund të bëjmë një analogji me ndërfaqen Tunnel për funksionimin GRE:
interface nve1
no shutdown
host-reachability protocol bgp ! përdorim BGP për transmetimin e informacionit për rrugët
source-interface loopback0 ! ndërfaqja nga e cila dërgojmë paketa loopback0Në ndërlidhësin Leaf-21, gjithçka krijohet pa probleme. Megjithatë, nëse ne kontrollojmë daljen e komandës show nve peers, ajo do të jetë bosh. Këtu është e nevojshme të kthehemi në konfigurimin e VPC. Ne shohim se Leaf-11 dhe Leaf-12 funksionojnë në çift dhe janë të bashkuar në domenin VPC. Kështu rezulton situata e mëposhtme:
Host-2 dërgon një cadër drejt Leaf-21, në mënyrë që ai ta transmetojë në rrjet drejt Host-1. Megjithatë, Leaf-21 sheh se adresa MAC e Host-1 është e disponueshme menjëherë përmes dy VTEP. Si duhet të veprojë Leaf-21 në këtë rast? Sepse kjo do të thotë se një cikël mund të jetë shfaqur në rrjet.
Për të zgjidhur këtë situatë, kemi nevojë që Leaf-11 dhe Leaf-12 brenda fabrikës gjithashtu të paraqiten si një pajisje. Kjo zgjidhet mjaft thjesht. Në ndërfaqen Loopback, nga e cila ndërtuam tunelin, shtojmë adresën sekondare. Adresa sekondare duhet të jetë e njëjtë në të dy VTEP.
interface loopback0
ip add 10.255.1.10/32 secondaryKështu, nga këndvështrimi i VTEP të tjerë, ne marrim topologjinë e mëposhtme:

Kështu, tani tuneli do të ndërtohet midis adresës IP të Leaf-21 dhe adresës virtuale IP ndërmjet dy Leaf-11 dhe Leaf-12. Tani, nuk do të ketë probleme me njohjen e adresës MAC nga dy pajisjet, dhe trafiku mund të kalojë nga një VTEP në tjetrin. Kush saktësisht nga dy VTEP do të trajtojë trafikun përcaktohet nga tabela e rrugëtimit 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ç duket më sipër, adresa 10.255.1.10 është e disponueshme përmes dy Next-hop.
Në këtë fazë analizojmë lidhjen bazë. Të kalojmë te konfigurimi i ndërfaqes NVE:
Menjëherë do të aktivizojmë VLAN 10 dhe do ta asociojmë atë me VNI 10000 në çdo Leaf për hostet. Do të krijojmë një tunel L2 midis hosteve
vlan 10 ! Aktivizojmë VLAN në të gjitha VTEP të lidhura me hostet e nevojshme
vn-segment 10000 ! Asociojmë VLAN me numrin VNI
interface nve1
member vni 10000 ! Shtojmë VNI 10000 për funksionimin përmes ndërfaqes NVE, për inkapsulim në VxLAN
ingress-replication protocol bgp ! caktimi i BGP për shpërndarjen e informacionit për hostetTani le të kontrollojmë nve peers 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 ! Shohim se peer është i disponueshëm nga adresa sekondare
Leaf11# sh bgp l2vpn evpn
Rrjeti Next Hop Metric LocPrf Weight Path
Rrugë Distingues: 10.255.1.11:32777 (L2VNI 10000) ! Nga kush ka ardhur ky l2VNI
*>l[3]:[0]:[32]:[10.255.1.10]/88 ! Rruga EVPN type 3 - tregon fqinjën tonë, i cili gjithashtu e njeh 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
Rrugë Distingues: 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 shohim rrugët vetëm EVPN route-type 3. Ky tip rrugësh tregon për peer (Leaf), por ku janë hostet tona?
Arsyeja është se informacioni për MAC-in e hosteve transmetohet përmes EVPN route-type 2.
Për të parë hostet tona, duhet të konfigurojmë EVPN route-type 2:
evpn
vni 10000 l2
route-target import auto ! Në kuadër të këtij artikulli përdorim numrin automatik për route-target
route-target export autoDo 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Ă« ne mund tĂ« shohim se nĂ« tabela BGP janĂ« shfaqur rrugĂ« tĂ« tipit 2 me adresat MAC tĂ« hosteve â 5001.0007.0007 dhe 5001.0008.0007.
Leaf11# sh bgp l2vpn evpn
Rrjeti Next Hop Metric LocPrf Weight Path
Rrugë Distingues: 10.255.1.11:32777 (L2VNI 10000)
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]/216 ! rruga evpn type 2 dhe adresa mac e hostit 1
10.255.1.10 100 32768 i
*>i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]/216 ! rruga evpn type 2 dhe adresa mac e hostit 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
Rrugë Distingues: 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ë shikojmë informacionin e detajuar mbi Update, në të cilin kemi marrë informacionin mbi MAC-in e Host. Më poshtë paraqitet jo e gjithë dalja e komandës.
Leaf21# sh bgp l2vpn evpn 5001.0007
Informacionet e tabelës së ruterit BGP për VRF default, familja e adresave L2VPN EVPN
Distinguesi i Rrugës: 10.255.1.11:32777 ! dërguar Update me MAC Host. Jo adresë virtuale VPC, por adresë Leaf
Shënimi i tabelës BGP për [2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]/216,
version 1507
Rrugët: (2 të disponueshme, më e mira #2)
Flamuj: (0x000202) (high32 00000000) në xmit-list, nuk është në l2rib/evpn, nuk është në HW
Lloji i shkallës: i brendshëm, rruga është e vlefshme, arsyeja nuk është më e mira: Adresa e Fqinjit, asnjë nexthop me etiketë
AS-Path: ASNONE, rruga e burimit është e brendshme për AS
10.255.1.10 (metrikë 81) nga 10.255.1.102 (10.255.1.102) ! me kë po e ndërtojmë tunelin VxLAN
Origjina IGP, MED nuk është vendosur, preferenca lokale 100, pesha 0
Etiketa e pranuar 10000 ! Numri VNI që është asociuar me VLAN-in, ku ndodhet Host
Extcommunity: RT:65001:10000 SOO:10.255.1.10:0 ENCAP:8 ! Këtu duket se RT është formuar automatikisht mbi bazën e numrave AS dhe VNI
Origjinatori: 10.255.1.11 Lista e klasterit: 10.255.1.102Le të shohim si duken kadrat kur ato dërgohen përmes fabrikës:

Suppress-ARP
Shumë mirë, lidhja L2 ndërmjet hosteve tani është krijuar dhe këtu mund ta përfundojmë. Megjithatë, gjërat nuk janë aq të thjeshta. Deri tani, me pak hostë nuk do të ketë probleme. Por le të imagjinojmë situatat kur kemi qindra ose mijëra hostë. Me çfarë problemi mund të ballafaqohemi?
Ky problem është trafiku BUM (Broadcast, Unknown Unicast, Multicast). Në këtë artikull do të shqyrtojmë mënyrat e trajtimit të trafikut broadcast.
Burimi kryesor i Broadcast në rrjetet Ethernet janë vetë hostet përmes protokollit ARP.
NĂ« nexus Ă«shtĂ« implementuar mekanizmi i mĂ«poshtĂ«m pĂ«r tĂ« luftuar kĂ«rkesat ARP â suppress-arp.
Funksionimi i kësaj veçorie duket si më poshtë:
- Host-1 dërgon kërkesën APR në adresën Broadcast të rrjetit të tij.
- KĂ«rkesa arrin nĂ« switch-in Leaf dhe nĂ« vend qĂ« ta dĂ«rgojĂ« mĂ« tej nĂ« fabrikĂ« drejt Host-2 â Leaf pĂ«rgjigjet vetĂ« dhe tregon IP dhe MAC tĂ« nevojshme.
Kështu, kërkesa Broadcast nuk shkoi në fabrikë. Por si mund të funksionojë kjo, nëse Leaf di vetëm adresën MAC?
E gjithë kjo është mjaft e thjeshtë, lloji i rrugës EVPN 2 përveç adresës MAC mund të transmetojë një çift MAC/IP. Për këtë, në Leaf është e nevojshme të konfigurohet një adresë IP në VLAN. Këtu lind pyetja, cila IP duhet të vendoset? Në nexus ekziston mundësia për të krijuar një adresë të shpërndarë (të njëjtë) në të gjitha switch-et:
feature interface-vlan
fabric forwarding anycast-gateway-mac 0001.0001.0001 ! vendosim virtual mac për krijimin e një gateway të shpërndarë midis të gjithë switch-eve
interface Vlan10
no shutdown
ip address 192.168.10.254/24 ! në të gjithë Leaf vendosim IP-në e njëjtë
fabric forwarding mode anycast-gateway ! i themi të përdorë Virtual macKështu, nga pikëpamja e hosteve, rrjeti do të duket si më poshtë:

Le të kontrollojmë BGP l2route evpn
Leaf11# sh bgp l2vpn evpn
Rrjeti Next Hop Metrikë LocPrf Pesha Rruga
Distinguesi i Rrugës: 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
<......>
Distinguesi i Rrugës: 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, është e qartë se në EVPN route-type 2, përveç MAC tani shohim gjithashtu adresën IP të hostit.
Të kthehemi tek konfigurimi i suppress-arp. Ky parametër aktivizohet për çdo VNI veçmas:
interface nve1
member vni 10000
suppress-arpMë pas lind një vështirësi e caktuar:
- Për të funksionuar kjo veçori, është e nevojshme hapësira në memorien TCAM. Do të jap një shembull të konfigurimit për suppress-arp:
hardware access-list tcam region arp-ether 256Për këtë konfigurim do të nevojitet double-wide. Kështu, nëse vendosni 256, në TCAM duhet të lirohet 512. Konfigurimi i TCAM kalon jashtë përmbajtjes së këtij artikulli, pasi konfigurimi i TCAM varet vetëm nga detyra e vendosur dhe mund të ndryshojë nga një rrjet në një tjetër.
- Implementimi i suppress-arp duhet të bëhet në të gjitha switch-et Leaf. Megjithatë, vështirësi mund të lindin në konfigurimin e çifteve Leaf që ndodhen në domenin VPC. Kur ndryshohet TCAM, konsistenca midis çifteve do të prishet dhe një nodë mund të nxirret nga operimi. Përveç kësaj, për zbatimin e konfigurimit, ndonjëherë mund të kërkohet një rindezje e pajisjes.
Si rezultat, duhet të mendoni mirë nëse implementimi i kësaj konfigurimi në fabrikën tuaj aktive është një zgjedhje e mençur.
Me këtë, përfundojmë pjesën e parë të ciklit. Në pjesën tjetër do të shqyrtojmë ruterimin përmes fabrikës VxLAN me ndarjen e rrjeteve sipas VRF-ve të ndryshme.
Tani ju ftoj të gjithë në , në kuadër të cilit do t'ju flas në detaje për kursin. 20 pjesëmarrësit e parë që regjistrohen në këtë webinar do të marrin një Certifikatë për zbritje në email-in e tyre brenda 1-2 ditësh pas transmetimit.
Burimi: habr.com
