Merheba, habr. Ez niha serokê qursê ji bo qursa Endezyarê Torê li OTUS me.
Li hêviya destpêkirina qeydek nû ya ji bo qursê , Min li ser teknolojiya VxLAN EVPN rêze gotar amade kirine.
Li ser ka VxLAN EVPN çawa dixebite pir materyal heye, ji ber vê yekê ez dixwazim ji bo çareserkirina pirsgirêkan di navendek daneya nûjen de kar û pratîkên cihêreng kom bikim.
Di beşa yekem a rêzefîlmê de li ser teknolojiya VxLAN EVPN, ez dixwazim li rêyek binerim ku pêwendiya L2 di navbera mêvandaran de li ser tevnek torê organîze bike.
Hemî nimûne dê li ser Cisco Nexus 9000v, ku di topolojiya Spine-Leaf de hatî berhev kirin, bêne kirin. Em ê di vê gotarê de li ser sazkirina torgilokek Underlay nesekinin.
- Tora binavê
- BGP peering ji bo navnîşan-malbata l2vpn evpn
- Sazkirina NVE
- Suppress-arp
Tora binavê
Topolojiya ku tê bikar anîn wiha ye:
Ka em navnîşan li ser hemî cîhazan saz bikin:
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.20Ka em kontrol bikin ku di navbera hemî cîhazan de girêdana IP-yê heye:
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, intraKa em kontrol bikin ka domaina VPC hatiye afirandin û her du guhêrbar ji kontrolkirina hevgirtinê derbas bûne û mîhengên li ser her du girêkan yek in:
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
Di dawiyê de, hûn dikarin biçin sazkirina tora Overlay.
Wekî beşek gotarê, pêdivî ye ku meriv torgilokek di navbera mêvandaran de organîze bike, wekî ku di diagrama jêrîn de tê xuyang kirin:
Ji bo mîhengkirina torgilokek Overlay, hûn hewce ne ku BGP-ê li ser guheztinên Spine û Pelê bi piştgirîya malbata l2vpn evpn çalak bikin:
feature bgp
nv overlay evpnDûv re, hûn hewce ne ku peering BGP di navbera Leaf û Spine de mîheng bikin. Ji bo hêsankirina sazkirinê û xweşbînkirina belavkirina agahdariya rêwîtiyê, em Spine wekî serverek Route-Reflector mîheng dikin. Em ê hemî Leaf-ê di mîhengê de bi karanîna şablonan binivîsin da ku sazkirinê xweştir bikin.
Ji ber vê yekê mîhengên li ser Spine wiha xuya dikin:
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 LEAFSazkirina li ser Guhestina Pelê bi vî rengî xuya dike:
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 SPINELi ser Spine, werin em peering bi hemî guhezên Pelê re kontrol bikin:
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 0Wekî ku hûn dibînin, bi BGP-ê re pirsgirêk tune bûn. Werin em biçin sazkirina VxLAN. Veavakirina din dê tenê li aliyê Pelê guhezkan were kirin. Spine tenê wekî bingeha torê tevdigere û tenê di veguhestina seyrûseferê de beşdar e. Hemî xebata encapsulasyon û destnîşankirina rê tenê li ser guheztina pelan pêk tê.
Sazkirina NVE
NVE - pêwendiya virtual ya torê
Berî destpêkirina sazkirinê, em çend termînolojiyê bidin nasîn:
VTEP - Xala Dawî ya Tunelê ya Vîtual, cîhaza ku tunela VxLAN dest pê dike an diqede. VTEP ne hewce ye ku amûrek torê ye. Serverek ku teknolojiya VxLAN piştgirî dike dikare wekî serverek jî tevbigere. Di topolojiya me de, hemî guheztinên Pelê VTEP in.
VNI - Indeksa Tora Virtual - Nasnameya torê di nav VxLAN de. Analojiyek dikare bi VLAN re were kişandin. Lêbelê, hinek cudahî hene. Dema ku fabrîkek bikar tînin, VLAN tenê di nav yek Guhestina Pelê de yekta dibin û li seranserê torê nayên şandin. Lê her VLAN dikare jimareyek VNI bi wê re têkildar be, ku berê li ser torê tê veguheztin. Ew çawa xuya dike û çawa dikare were bikar anîn dê bêtir were nîqaş kirin.
Ka em taybetmendiya teknolojiya VxLAN-ê bixebitin û kapasîteya girêdana hejmarên VLAN bi hejmarek VNI re çalak bikin:
feature nv overlay
feature vn-segment-vlan-basedWerin em pêveka NVE, ku ji xebata VxLAN berpirsiyar e, mîheng bikin. Ev navbeynkar ji bo vegirtina çarçoveyên di sernavên VxLAN de berpirsiyar e. Hûn dikarin ji bo GRE-ê bi navbeynkariya Tunnelê re analojiyek derxînin:
interface nve1
no shutdown
host-reachability protocol bgp ! используем BGP для передачи маршрутной информации
source-interface loopback0 ! интерфейс с которого отправляем пакеты loopback0Li ser veguherîna Leaf-21 her tişt bê pirsgirêk têne afirandin. Lêbelê, heke em hilberîna fermanê kontrol bikin show nve peers, wê demê wê vala bibe. Li vir hûn hewce ne ku vegerin veavakirina VPC. Em dibînin ku Leaf-11 û Leaf-12 bi cotan dixebitin û ji hêla domainek VPC ve têne yek kirin. Ev rewşa jêrîn dide me:
Host-2 çarçoveyek ber bi Leaf-21 ve dişîne da ku ew li ser torê ber bi Host-1 ve bişîne. Lêbelê, Leaf-21 dibîne ku navnîşana MAC-ê ya Host-1 bi yek carî bi du VTEP-an ve tê gihîştin. Divê Leaf-21 di vê rewşê de çi bike? Beriya her tiştî, ev tê vê wateyê ku pêlekek dikare di torê de xuya bibe.
Ji bo çareserkirina vê rewşê, em hewce ne ku Leaf-11 û Leaf-12 jî wekî yek amûrek di nav kargehê de tevbigerin. Çareserî pir hêsan e. Li ser pêwendiya Loopback ya ku em tunelê lê ava dikin, navnîşek duyemîn lê zêde bikin. Divê navnîşana Duyemîn li ser her du VTEP-an yek be.
interface loopback0
ip add 10.255.1.10/32 secondaryBi vî rengî, ji nêrîna VTEP-ên din, em topolojiya jêrîn digirin:
Ango, naha dê tunel di navbera navnîşana IP-ya Leaf-21 û IP-ya virtual di navbera du Leaf-11 û Leaf-12 de were çêkirin. Naha dê ti pirsgirêk tunebin ku navnîşana MAC-ê ji du cîhazan fêr bibin û seyrûsefer dikare ji yek VTEP derbasî ya din bibe. Kîjan ji du VTEP-ê dê seyrûseferê bişopîne bi karanîna tabloya rêvekirinê ya li ser Spine tê biryar:
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, intraWekî ku hûn li jor jî dibînin, navnîşana 10.255.1.10 tavilê di nav du Next-hops de peyda dibe.
Di vê qonaxê de, me bi girêdana bingehîn re mijûl kir. Ka em biçin sazkirina pêwendiya NVE:
Ka em tavilê Vlan 10 çalak bikin û li ser her Pelê ji bo mêvandaran wê bi VNI 10000 re têkildar bikin. Ka em di navbera mêvandaran de tunelek L2 saz bikin
vlan 10 ! Включаем VLAN на всех VTEP подключенных к необходимым хостам
vn-segment 10000 ! Ассоциируем VLAN с номер VNI
interface nve1
member vni 10000 ! Добавляем VNI 10000 для работы через интерфейс NVE. для инкапсуляции в VxLAN
ingress-replication protocol bgp ! указываем, что для распространения информации о хосте используем BGPNaha em nve peers û tabloya BGP EVPN kontrol bikin:
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 iLi jor em tenê rêgezên EVPN-ya-type 3 dibînin. Ev celeb rê li ser peer (Pel) diaxive, lê mêvandarên me li ku ne?
Tişt ev e ku agahdariya li ser mêvandarên MAC-ê bi riya EVPN-type 2 ve tê veguheztin
Ji bo ku hûn mêvandarên me bibînin, hûn hewce ne ku EVPN route-type 2 mîheng bikin:
evpn
vni 10000 l2
route-target import auto ! в рамках данной статьи используем автоматический номер для route-target
route-target export autoKa em ji Host-2 berbi Host-1 ping bikin:
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Û li jêr em dikarin bibînin ku route-type 2 bi navnîşana MAC-ya mêvandar di tabloya BGP de xuya bû - 5001.0007.0007 û 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 iDûv re, hûn dikarin agahdariya berfireh li ser Nûvekirinê bibînin, ku tê de we agahdariya li ser MAC Host wergirtiye. Li jêr ne hemî hilberîna fermanê ye.
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
<........>Ka em bibînin ka çarçeweyên ku di nav kargehê re derbas dibin çawa xuya dikin:
Suppress-ARP
Mezin, me naha pêwendiya L2 di navbera mêvandaran de heye û em dikarin li wir biqedînin. Lêbelê, hemî ne ewqas hêsan e. Heya ku hindik mêvandarên me hebin dê ti pirsgirêk dernekevin. Lê em rewşekê bifikirin ku bi sed û hezaran mêvandarên me hene. Dibe ku em bi kîjan pirsgirêkê re rû bi rû bimînin?
Ev pirsgirêk seyrûsefera BUM (Badcast, Unicast Unknown, Multicast) ye. Di vê gotarê de, em ê vebijarka mijûlbûna bi seyrûsefera weşanê re bifikirin.
Di torên Ethernet de hilberînerê sereke yê Broadcast-ê bi protokola ARP-ê mêvandar bixwe ne.
Nexus mekanîzmaya jêrîn bicîh tîne da ku li dijî daxwazên ARP şer bike - suppress-arp.
Ev taybetmendî bi vî rengî dixebite:
- Host-1 daxwaznameyek APR ji navnîşana Broadcast ya tora xwe re dişîne.
- Daxwaz digihîje guheztina Pelê û li şûna ku vê daxwazê ji tevneyê ber bi Host-2 ve derbas bike, Leaf bixwe bersivê dide û IP û MAC-a hewce destnîşan dike.
Bi vî awayî, daxwaza Weşanê neçû fabrîkê. Lê heke Leaf tenê navnîşana MAC-ê dizane ev çawa dikare bixebite?
Her tişt pir hêsan e, EVPN route-type 2, ji bilî navnîşana MAC-ê, dikare tevliheviyek MAC / IP veguhezîne. Ji bo vê yekê, hûn hewce ne ku navnîşek IP-ê di VLAN-a li ser Leaf-ê de mîheng bikin. Pirs derdikeve holê, divê ez çi IP-ê saz bikim? Li ser nexus gengaz e ku meriv navnîşek belavkirî (eynî) li ser hemî guhêrkan biafirîne:
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 macBi vî rengî, ji nêrîna mêvandaran, torê dê bi vî rengî xuya bike:
Ka em BGP l2route evpn kontrol bikin
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
<......>Ji derketina fermanê hûn dikarin bibînin ku di EVPN route-type 2 de, ji bilî MAC, em naha navnîşana IP-ya mêvandar jî dibînin.
Ka em vegerin ser sazkirina suppress-arp. Ev mîheng ji bo her VNI ji hev veqetandî ye:
interface nve1
member vni 10000
suppress-arpDûv re hin tevlihevî derdikeve holê:
- Ji bo ku ev taybetmendî bixebite, cîh di bîra TCAM de hewce ye. Li vir mînakek mîhengên ji bo suppress-arp heye:
hardware access-list tcam region arp-ether 256Ev mîheng dê du-berfireh hewce bike. Ango, heke hûn 256 saz bikin, wê hingê hûn hewce ne ku di TCAM-ê de 512 azad bikin. Sazkirina TCAM derveyî çarçoweya vê gotarê ye, ji ber ku sazkirina TCAM tenê bi peywira ku ji we re hatî peywirdar kirin ve girêdayî ye û dibe ku ji yek torê heya torek din cûda bibe.
- Pêkanîna suppress-arp divê li ser hemî guhezên Pelê were kirin. Lêbelê, tevlihevî dikare dema ku li ser cotên Pelên ku di domînek VPC-yê de rûdinin mîheng bikin. Ger TCAM were guheztin, hevrêziya di navbera cotan de dê têk bibe û dibe ku yek nodek ji xebatê were derxistin. Wekî din, ji bo sepandina mîhenga guhartina TCAM-ê dibe ku ji nû ve destpêkirina cîhazê hewce be.
Wekî encamek, hûn hewce ne ku bi baldarî bifikirin ka gelo, di rewşa we de, hêja ye ku vê mîhengê di kargehek xebitandinê de bicîh bikin.
Ev beşa yekem a rêzefîlmê bi dawî dike. Di beşa paşîn de em ê bi veqetandina toran di nav VRF-yên cihêreng de li rêveçûna tevnek VxLAN-ê binêrin.
Û niha ez her kesî vedixwînim , ku di hundurê wê de ez ê di derheqê qursê de bi berfirehî ji we re vebêjim. 20 beşdarên yekem ên ku ji bo vê webinarê qeyd bikin dê di nav 1-2 rojan de piştî weşanê bi e-nameyê Sertîfîkayek Tenzîlatê bistînin.
Source: www.habr.com