Përshëndetje, Habr. Aktualisht jam drejtori i kursit "Inxhinier Rrjeti" në OTUS.
Me para fillimit të një grupi të ri për kursin , kam përgatitur një cikël artikujsh për teknologjinë VxLAN EVPN.
Ka një mori materialesh mbi funksionimin e VxLAN EVPN, prandaj dua të mbledh disa detyra dhe praktika zgjidhjeje në një QTD moderne.
Në pjesën e parë të ciklit për teknologjinë VxLAN EVPN, dua të shqyrtoj mënyrën e organizimit të lidhshmërisë L2 mes hosteve mbi një fabrikë rrjetore.
Të gjitha shembujt do t’i realizojmë në Cisco Nexus 9000v, të ndërtuar në një topologji Spine-Leaf. Nuk do të ndalojmë në konfigurimin e rrjetit Underlay në kuadër të 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ë:
Të caktojmë adresat 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.20Të kontrollojmë që ka lidhshmëri IP midis të gjitha pajisjeve:
Leaf21# sh ip route
10.255.1.11/32, ubest/mbest: 2/0 ! Leaf-11 i qasshëm përmes dy 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 i qasshëm përmes dy 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, i lidhur
*via 10.255.1.22, Lo0, [0/0], 00:02:20, lokal
*via 10.255.1.22, Lo0, [0/0], 00:02:20, direkt
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, intraTë kontrollojmë që domaini VPC është krijuar dhe të dy switch-at kanë kaluar kontrollin e konsistencës dhe konfigurimi në të dy nodet është identik:
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 peer
Më në fund mund të kalojmë në konfigurimin e rrjetit Overlay.
Në kuadër të këtij artikulli, duhet të organizojmë rrjetin midis hosteve, siç tregohet në diagramin më poshtë:
Për konfigurimin e Overlay rrjetit, është e nevojshme të aktivizoni BGP me mbështetje për familjen l2vpn evpn në switch-ët Spine dhe Leaf:
feature bgp
nv overlay evpnMë pas, duhet të konfiguroni BGP peer-ing ndërmjet Leaf dhe Spine. Për të lehtësuar konfigurimin dhe optimizimin e shpërndarjes së informacionit të ruteve, Spine e konfiguroni si Route-Reflector server. Të gjitha Leaf do t'i shkruajmë në konfiguracion përmes template, për të optimizuar konfigurimin.
Kështu, konfigurimi në Spine duket 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 gjithashtu e 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ë kontrollojmë peer-in me të gjithë switch-et 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ç e shohim, nuk ka pasur asnjë problem me BGP. Të kalojmë në konfigurimin e VxLAN. Konfigurimi më tej do të kryhet vetëm në anën e switch-ëve Leaf. Spine vepron vetëm si bërthama e rrjetit dhe merret vetëm me transmetimin e trafikut. Të gjitha punët në enkapsulimin dhe përcaktimin e rrugës kryhen vetëm në switch-ët Leaf.
Konfigurimi i NVE
NVE — ndërfaqja virtuale e rrjetit
Para fillimit të konfigurimit, le të prezantojmë pak terminologji:
VTEP — Vitual Tunnel End Point, pajisja në të cilën fillon ose përfundon tuneli VxLAN. VTEP nuk është domosdoshmërisht një pajisje rrjeti. Një server që mbështet teknologjinë VxLAN mund të shërbejë gjithashtu. Në topologjinë tonë, të gjithë switch-et Leaf janë VTEP.
VNI — Indeksi i Rrjetit Virtual — identifikuesi i rrjetit brenda VxLAN. Mund të bëhet një analogji me VLAN. Megjithatë, ka disa dallime. Përdorimi i fabrikës bën që VLAN të jenë unike vetëm brenda një switch-i Leaf dhe nuk transmetohen nëpër rrjet. Por, çdo VLAN mund të lidhet me një numër VNI, i cili transmetohet në rrjet. Si duket kjo dhe si mund të përdoret do të shqyrtohet më tej.
Le të aktivizojmë feature për funksionimin e teknologjisë VxLAN dhe mundësinë për të lidhur numrat e VLAN me numrin e VNI:
feature nv overlay
feature vn-segment-vlan-basedNe do ta konfiguroni ndërfaqen NVE, e cila është përgjegjëse për funksionimin e VxLAN. Kjo ndërfaqe është pikërisht ajo që merret me inkapsulimin e kadrove 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 dërgimin e informacionit të rrugëve
source-interface loopback0 ! ndërfaqja nga e cila dërgojmë paketa loopback0Në komandën Leaf-21, gjithçka krijohet pa probleme. Megjithatë, nëse kontrollojmë rezultatin e komandës show nve peers, ai do të jetë bosh. Këtu është e nevojshme të kthehemi në konfigurimin e VPC. Ne shohim se Leaf-11 dhe Leaf-12 punojnë në çift dhe janë të lidhur me domenin VPC. Kjo krijon situatën e mëposhtme:
Host-2 dërgon një kadër në drejtim të Leaf-21, që t'ia transmetojë rrjetit në drejtim të Host-1. Megjithatë, Leaf-21 vëren se adresa MAC e Host-1 është e aksesueshme menjëherë përmes dy VTEP-ve. Si të veprojë Leaf-21 në këtë rast? Kjo do të thotë se në rrjet mund të ketë një cikël.
Për të zgjidhur këtë situatë, ne kemi nevojë që Leaf-11 dhe Leaf-12 brenda fabrikës të funksionojnë si një dispozitiv. Kjo zgjidhet mjaft lehtë. Në ndërfaqen Loopback nga e cila ndërtojmë tunnelin, shtojmë një adresë sekondare. Adresa sekondare duhet të jetë e njëjtë në të dy VTEP-të.
interface loopback0
ip add 10.255.1.10/32 secondaryNë këtë mënyrë, nga këndvështrimi i VTEP-ve të tjerë, ne marrim topologjinë e mëposhtme:
Pra, tani tunneli do të ndërtohet midis adresës IP të Leaf-21 dhe adresës virtuale IP midis dy Leaf-11 dhe Leaf-12. Tani nuk do të ketë probleme me gjetjen e adresës MAC nga dy pajisje dhe trafiku mund të kalojë nga një VTEP në tjetrin. Kush nga dy VTEP-të do të përpunojë trafikun përcaktohet nëpërmjet tabelës së rrugëve 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ë lart, adresa 10.255.1.10 është e disponueshme menjëherë përmes dy Next-hop.
Në këtë hap kemi kuptuar lidhshmërinë bazike. Tani kalojmë në konfigurimin e ndërfaqes NVE:
Menjëherë aktivizojmë VLAN 10 dhe e asociojmë atë me VNI 10000 në çdo Leaf për hostet. Të krijojmë një tunel L2 midis hosteve.
vlan 10 ! Aktivizoni VLAN-in në të gjitha VTEP-et e lidhura me hostet e nevojshëm
vn-segment 10000 ! Asociojmë VLAN-in me numrin VNI
interface nve1
member vni 10000 ! Shtojmë VNI 10000 për funksionimin përmes ndërfaqes NVE. për inkapsulimin në VxLAN
ingress-replication protocol bgp ! tregojmë se për shpërndarjen e informacionit rreth hostit përdorim BGPTani do 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 që peer është i accessible me adresë sekondare
Leaf11# sh bgp l2vpn evpn
Rrjeti Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.255.1.11:32777 (L2VNI 10000) ! Nga kush ka ardhur ky l2VNI
*>l[3]:[0]:[32]:[10.255.1.10]/88 ! Rruga EVPN route-type 3 - tregon fqinjim 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
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ë lart shohim rrugët vetëm EVPN route-type 3. Ky tip rrugësh tregon për peer (Leaf), por ku janë hostet tona?
E gjithë kjo është për shkak se informacioni për MAC-et e hosteve transmetohet përmes EVPN route-type 2
Për të parë hostet tanë, 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 autoTë bëjmë ping nga Host-2 te 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 në tabelën BGP janë shfaqur route-type 2 me adresat MAC të hosteve — 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 dhe adresi mac i hostit 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 dhe adresi mac i 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
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ë shikoni informacione të detajuara mbi Update, në të cilin morëm informacion mbi MAC Host. Më poshtë nuk paraqitet e gjithë dalja e komandës
Leaf21# sh bgp l2vpn evpn 5001.0007.0007
Informacioni mbi tabelën e rrugës BGP për VRF default, familja e adresave L2VPN EVPN
Route Distinguisher: 10.255.1.11:32777 ! dërguar Update me MAC Host. Jo adresa virtuale VPC, por adresa e 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)
Flagat: (0x000202) (high32 00000000) në xmit-list, nuk është në l2rib/evpn, nuk është në HW
Lloji i rrugës: i brendshëm, rruga është valide, nuk është e preferuar arsye: Adresa e Fqinjit, pa nexthop të etiketuar
AS-Path: AS HI, rruga buron e brendshme për AS
10.255.1.10 (metrikë 81) nga 10.255.1.102 (10.255.1.102) ! me kë po ndërtojmë tunnelen VxLAN
Origjina IGP, MED nuk është vendosur, localpref 100, peshë 0
Etiketa e marrë 10000 ! Numri VNI, i cili është i asociuar me VLAN, ku ndodhet Host
Extcommunity: RT:65001:10000 SOO:10.255.1.10:0 ENCAP:8 ! Këtu shihet se RT është formuar automatikisht mbi bazën e numrave AS dhe VNI
Origjinator: 10.255.1.11 Lista e grupeve: 10.255.1.102Le ta shohim si duken kadrot, kur ato transmetohen përmes fabrikës:
Suppress-ARP
Shkëlqyeshëm, lidhja L2 midis hosteve mbahet dhe këtu mund të përfundojmë. Megjithatë, nuk është aq e thjeshtë. Ndërsa kemi pak hoste, nuk do të kemi probleme. Por le të imagjinojmë situata, ku kemi qindra dhe mijëra hoste. Çfarë problemi mund të hasim?
Ky problem është trafiku BUM (Broadcast, Unknown Unicast, Multicast). Në kuadër të këtij artikulli do të shqyrtojmë një variant për luftimin e trafikut broadcast.
Generatori 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 karakteristike duket si më poshtë:
- Host-1 dërgon një kërkesë APR në adresën Broadcast të rrjetit të tij.
- Kërkesa arrin në switch-in Leaf dhe në vend që të kalojë këtë kërkesë më tej në fabrikë drejt Host-2 — Leaf përgjigjet vetë dhe tregon IP-në dhe MAC-në e 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ë, EVPN route-type 2 përveç adresës MAC mund të transmetojë një lidhje MAC/IP. Për këtë, është e nevojshme të konfigurohet një adresë IP në VLAN në Leaf. Shfaqet pyetje, cila IP duhet të caktohet? 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 ! caktojmë virtual mac për të krijuar një gateway të shpërndarë midis të gjitha switch-ëve
interface Vlan10
no shutdown
ip address 192.168.10.254/24 ! në të gjitha Leaf caktojmë të njëjtën IP
fabric forwarding mode anycast-gateway ! themi të përdorim Virtual macKështu, nga pikëpamja e hosteve, rrjeti do të duket si më poshtë:
Të kontrollojmë BGP l2route evpn
Leaf11# sh bgp l2vpn evpn
Rrjeti Hapi i ardhshëm Metrika LocPrf Pesha Rruga
Përjashtuesi 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
<......>
Përjashtuesi 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, mund të shohim se në EVPN route-type 2 përveç MAC tani shohim edhe adresën IP të hostit.
Kthehemi në konfigurimin e suppress-arp. Kjo ndarje aktivizohet për çdo VNI veç e veç:
interface nve1
member vni 10000
suppress-arpPastaj shfaqet një vështirësi e caktuar:
- Për të funksionuar këtë veçori, nevojitet hapësirë në memorjen TCAM. Do të jap një shembull konfigurimi për suppress-arp:
hardware access-list tcam region arp-ether 256Për këtë konfigurim do të kërkohet double-wide. Kështu që, nëse caktoni 256, duhet të lirohet 512 në TCAM. Konfigurimi i TCAM-i tejkalon kufijtë e këtij artikulli, 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ë switch-at Leaf. Megjithatë, mund të ketë vështirësi gjatë konfigurimit në çiftet Leaf që ndodhen në domenin VPC. Kur ndryshohet TCAM, konsistenca ndërmjet çiftave do të dështojë dhe një njësi mund të dalë jashtë përdorimit. Po ashtu, mund të kërkohet ri-farëzimi i pajisjes për të aplikuar ndërrimin e TCAM.
Si rezultat, duhet të mendoni mirë nëse në situatën tuaj ia vlen të zbatoni këtë konfigurim në fabrikën që është në punë.
Këtu e mbyllim pjesën e parë të ciklit. Në pjesën tjetër do të shqyrtojmë rrugëzimin përmes fabrikës VxLAN me ndarjen e rrjeteve në VRF të ndryshme.
Tani ftoj të gjithë në , ku do të flas në detaje për kursin. Të parët 20 pjesëmarrës që regjistrohen në këtë webinar do të marrin një Certifikat për zbritje në email brenda 1-2 ditëve pas transmetimit.
Burimi: habr.com
