Helo habr. Ar hyn o bryd fi yw'r arweinydd cwrs ar gyfer "Network Engineer" yn OTUS.
Gan ragweld dechrau ymrestriad newydd ar gyfer y cwrs , Rwyf wedi paratoi cyfres o erthyglau ar dechnoleg VxLAN EVPN.
Mae llawer iawn o ddeunydd ar weithrediad VxLAN EVPN, felly rwyf am gasglu gwahanol dasgau ac arferion ar gyfer datrys problemau mewn canolfan ddata fodern.
Yn rhan gyntaf cylch technoleg VxLAN EVPN, rwyf am ystyried ffordd i drefnu cysylltedd L2 rhwng gwesteiwyr ar ben ffatri rhwydwaith.
Bydd pob enghraifft yn cael ei berfformio ar Cisco Nexus 9000v, wedi'i ymgynnull yn y topoleg Spine-Leaf. Ni fyddwn yn canolbwyntio ar sefydlu'r rhwydwaith Underlay yn yr erthygl hon.
- rhwydwaith underlay
- BGP yn sbecian am gyfeiriad-teulu l2vpn evpn
- Gosodiad NVE
- Attal-arp
rhwydwaith underlay
Mae'r topoleg a ddefnyddir fel a ganlyn:
Gadewch i ni osod cyfeiriadau ar bob dyfais:
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.20Gadewch i ni wirio bod cysylltedd IP rhwng pob dyfais:
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, intraGadewch i ni wirio bod y parth VPC wedi'i greu a bod y ddau switsh wedi pasio'r gwiriad cysondeb a bod y gosodiadau ar y ddau nod yn union yr un fath:
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 yn sbecian
Yn olaf, gallwn symud ymlaen i ffurfweddu'r rhwydwaith Overlay.
Fel rhan o'r erthygl, mae angen trefnu rhwydwaith rhwng gwesteiwyr, fel y dangosir yn y diagram isod:
I ffurfweddu rhwydwaith Troshaen, mae angen i chi alluogi BGP ar y switshis Asgwrn Cefn a Leaf gyda chefnogaeth i'r teulu l2vpn evpn:
feature bgp
nv overlay evpnNesaf, mae angen i chi ffurfweddu sbecian BGP rhwng Leaf a Spine. Er mwyn symleiddio'r ffurfweddiad a gwneud y gorau o ddosbarthu gwybodaeth llwybro, rydym yn ffurfweddu Spine fel gweinydd Route-Reflector. Byddwn yn ysgrifennu pob Leaf yn y ffurfweddiad trwy dempledi er mwyn gwneud y gorau o'r gosodiad.
Felly mae'r gosodiadau ar Spine yn edrych fel hyn:
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 LEAFMae'r gosodiad ar y switsh Leaf yn edrych yn debyg:
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 SPINEAr Asgwrn Cefn, gwiriwch edrych ar yr holl switshis 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 0Fel y gwelwch, nid oedd unrhyw broblemau gyda BGP. Gadewch i ni symud ymlaen i sefydlu VxLAN. Bydd cyfluniad pellach yn cael ei berfformio ar ochr y switshis Leaf yn unig. Mae asgwrn cefn yn gweithredu fel craidd y rhwydwaith yn unig ac mae'n ymwneud â throsglwyddo traffig yn unig. Mae'r holl waith ar amgáu a diffinio llwybr yn digwydd ar switshis Leaf yn unig.
Gosodiad NVE
NVE - rhyngwyneb rhithwir rhwydwaith
Cyn dechrau ar y gosodiad, gadewch i ni gyflwyno rhywfaint o derminoleg:
VTEP - Pwynt Diwedd y Twnnel Hanfodol, y ddyfais y mae twnnel VxLAN yn dechrau neu'n gorffen arni. Nid yw VTEP o reidrwydd yn unrhyw ddyfais rhwydwaith. Gall gweinydd sy'n cefnogi technoleg VxLAN weithredu hefyd. Yn ein topoleg, mae pob switsh Leaf yn VTEPs.
VNI - Mynegai Rhwydwaith Rhithwir - dynodwr rhwydwaith o fewn VxLAN. Gallwch chi dynnu cyfatebiaeth â VLAN. Fodd bynnag, mae rhai gwahaniaethau. Wrth ddefnyddio ffabrig, mae VLANs yn dod yn unigryw o fewn un switsh Leaf yn unig ac nid ydynt yn cael eu trosglwyddo dros y rhwydwaith. Ond gall pob VLAN fod yn gysylltiedig â rhif VNI sydd eisoes yn cael ei drosglwyddo dros y rhwydwaith. Bydd sut olwg sydd arno a sut y gellir ei ddefnyddio yn cael eu trafod isod.
Galluogi'r nodwedd i dechnoleg VxLAN weithio a'r gallu i gysylltu rhifau VLAN â rhif VNI:
feature nv overlay
feature vn-segment-vlan-basedGadewch i ni ffurfweddu'r rhyngwyneb NVE, sy'n gyfrifol am weithrediad VxLAN. Mae'r rhyngwyneb hwn yn gyfrifol am amgáu fframiau ym mhenawdau VxLAN. Gallwch chi dynnu cyfatebiaeth â rhyngwyneb y Twnnel ar gyfer GRE:
interface nve1
no shutdown
host-reachability protocol bgp ! используем BGP для передачи маршрутной информации
source-interface loopback0 ! интерфейс с которого отправляем пакеты loopback0Ar y switsh Leaf-21, mae popeth yn cael ei greu heb broblemau. Fodd bynnag, os ydym yn gwirio allbwn y gorchymyn show nve peers, yna bydd yn wag. Yma mae angen i chi ddychwelyd i'r gosodiad VPC. Gwelwn fod Leaf-11 a Leaf-12 yn cael eu paru a'u huno gan barth VPC. Mae hyn yn arwain at y sefyllfa ganlynol:
Mae Host-2 yn anfon un ffrâm i Leaf-21 i'w drosglwyddo dros y rhwydwaith i Host-1. Fodd bynnag, mae Leaf-21 yn gweld bod cyfeiriad MAC Host-1 ar gael trwy ddau VTEP ar unwaith. Beth ddylai Leaf-21 ei wneud yn yr achos hwn? Wedi'r cyfan, mae hyn yn golygu y gallai dolen ymddangos yn y rhwydwaith.
I ddatrys y sefyllfa hon, mae angen i Leaf-11 a Leaf-12 hefyd weithredu fel un ddyfais yn y ffatri. Mae'n cael ei datrys yn eithaf syml. Ar y rhyngwyneb Loopback yr ydym yn adeiladu'r twnnel ohono, ychwanegwch y cyfeiriad eilaidd. Rhaid i'r cyfeiriad eilaidd fod yr un peth ar y ddau VCEP.
interface loopback0
ip add 10.255.1.10/32 secondaryFelly, o safbwynt VTEPs eraill, rydym yn cael y topoleg ganlynol:
Hynny yw, nawr bydd y twnnel yn cael ei adeiladu rhwng cyfeiriad IP Leaf-21 a'r IP rhithwir rhwng dwy Leaf-11 a Leaf-12. Nawr ni fydd unrhyw broblemau gyda dysgu'r cyfeiriad MAC o ddwy ddyfais, a gellir trosglwyddo traffig o un VTEP i'r llall. Penderfynir pa un o'r ddau VTEP fydd yn prosesu'r traffig gan ddefnyddio'r tabl llwybro ar Asgwrn Cefn:
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, intraFel y gwelwch uchod, mae'r cyfeiriad 10.255.1.10 ar gael ar unwaith trwy ddau Next-hop.
Ar y cam hwn, gwnaethom gyfrifo'r cysylltedd sylfaenol. Gadewch i ni symud ymlaen i sefydlu'r rhyngwyneb NVE:
Byddwn yn galluogi Vlan 10 ar unwaith ac yn ei gysylltu â VNI 10000 ar bob Dail ar gyfer gwesteiwyr. Gosodwch dwnnel L2 rhwng y gwesteiwyr
vlan 10 ! Включаем VLAN на всех VTEP подключенных к необходимым хостам
vn-segment 10000 ! Ассоциируем VLAN с номер VNI
interface nve1
member vni 10000 ! Добавляем VNI 10000 для работы через интерфейс NVE. для инкапсуляции в VxLAN
ingress-replication protocol bgp ! указываем, что для распространения информации о хосте используем BGPNawr, gadewch i ni wirio nve cyfoedion a bwrdd ar gyfer 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 iUchod gwelwn lwybrau yn unig EVPN llwybr math 3. Mae'r math hwn o lwybrau yn sôn am gymheiriaid (Leaf), ond ble mae ein gwesteiwyr?
A'r peth yw bod gwybodaeth am westeion MAC yn cael ei throsglwyddo trwy fath llwybr EVPN 2
Er mwyn gweld ein gwesteiwyr, mae angen i chi ffurfweddu math llwybr EVPN 2:
evpn
vni 10000 l2
route-target import auto ! в рамках данной статьи используем автоматический номер для route-target
route-target export autoGadewch i ni ping o Host-2 i 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 msAc isod gallwn weld bod llwybr math 2 wedi ymddangos yn y tabl BGP gyda chyfeiriad MAC y gwesteiwyr - 5001.0007.0007 a 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 iNesaf, gallwch weld gwybodaeth fanwl am Update, lle cawsoch wybodaeth am y MAC Host. Isod nid yw allbwn cyfan y gorchymyn
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
<........>Gawn ni weld sut olwg sydd ar y fframiau pan gânt eu pasio drwy'r ffatri:
Atal-ARP
Gwych, mae gennym ni gysylltiad L2 rhwng gwesteiwyr a gallai hyn fod yn ddiwedd arni. Fodd bynnag, nid yw pob un mor syml. Cyn belled â bod gennym ychydig o westeion, ni fydd unrhyw broblemau. Ond gadewch i ni ddychmygu sefyllfaoedd y mae gennym gannoedd ar filoedd o westeion. Pa broblem allwn ni ei hwynebu?
Y broblem hon yw traffig BUM (Darlledu, Unknown Unicast, Multicast). Yn fframwaith yr erthygl hon, byddwn yn ystyried yr opsiwn o frwydro yn erbyn traffig darlledu.
Y prif generadur Darlledu mewn rhwydweithiau Ethernet yw'r gwesteiwyr eu hunain trwy'r protocol ARP.
Mae Nexus yn gweithredu'r mecanwaith canlynol ar gyfer delio â cheisiadau ARP - suppress-arp.
Mae'r nodwedd hon yn gweithio fel hyn:
- Mae Host-1 yn anfon cais APR i gyfeiriad Darlledu ei rwydwaith.
- Mae'r cais yn cyrraedd y switsh Leaf ac yn lle pasio'r cais hwn ymhellach i'r ffatri tuag at Host-2, mae'r Leaf yn ateb ei hun ac yn nodi'r IP a MAC a ddymunir.
Felly, ni aeth y cais Darlledu i'r ffatri. Ond sut gall hyn weithio os mai dim ond y cyfeiriad MAC y mae Leaf yn ei wybod?
Mae popeth yn eithaf syml, gall llwybr math 2 EVPN, yn ogystal â'r cyfeiriad MAC, drosglwyddo bwndel MAC / IP. I wneud hyn, mae'n rhaid i'r Leaf gael ei ffurfweddu gyda chyfeiriad IP yn y VLAN. Mae'r cwestiwn yn codi, pa eiddo deallusol i'w ofyn? Ar nexus, mae'n bosibl creu cyfeiriad dosbarthedig (yr un) ar bob switsh:
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 macFelly, o safbwynt gwesteiwyr, bydd y rhwydwaith yn edrych fel hyn:
Gwiriwch 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
<......>O allbwn y gorchymyn, gellir gweld, yn llwybr math 2 EVPN, yn ogystal â'r MAC, ein bod nawr hefyd yn gweld cyfeiriad IP y gwesteiwr.
Gadewch i ni ddychwelyd i'r gosodiad atal-arp. Mae'r gosodiad hwn wedi'i alluogi ar gyfer pob VNI ar wahân:
interface nve1
member vni 10000
suppress-arpYna mae rhywfaint o anhawster:
- Mae'r nodwedd hon yn gofyn am le yng nghof TCAM. Rhoddaf enghraifft o osod ar gyfer atal-arp:
hardware access-list tcam region arp-ether 256Bydd angen lled-dwbl ar gyfer y gosodiad hwn. Hynny yw, os ydych chi'n gosod 256, yna rhaid rhyddhau 512 yn TCAM. Mae sefydlu TCAM y tu hwnt i gwmpas yr erthygl hon, gan fod sefydlu TCAM yn dibynnu ar y dasg a neilltuwyd i chi yn unig a gall fod yn wahanol o un rhwydwaith i'r llall.
- Rhaid gweithredu ataliad arp ar bob switsh Leaf. Fodd bynnag, gall cymhlethdod godi wrth ffurfweddu ar barau Leaf sydd wedi'u lleoli mewn parth VPC. Wrth newid TCAM, bydd y cysondeb rhwng y parau yn cael ei dorri a gellir tynnu un nod allan o wasanaeth. Yn ogystal, efallai y bydd angen ailgychwyn dyfais i gymhwyso'r gosodiad newid TCAM.
O ganlyniad, dylech ystyried yn ofalus a yw'n werth gweithredu'r gosodiad hwn ar ffatri sy'n gweithio yn eich sefyllfa chi.
Mae hyn yn cloi rhan gyntaf y cylch. Yn y rhan nesaf, byddwn yn ystyried llwybro trwy ffatri VxLAN gyda gwahaniad rhwydwaith ar draws gwahanol VRFs.
Ac yn awr yr wyf yn gwahodd pawb i , lle byddaf yn siarad yn fanwl am y cwrs. Bydd yr 20 cyfranogwr cyntaf sy'n cofrestru ar gyfer y weminar hon yn derbyn Tystysgrif Gostyngiad trwy e-bost o fewn 1-2 ddiwrnod ar ôl y darllediad.
Ffynhonnell: hab.com