Sveiki, habr. Šiuo metu esu OTUS tinklo inžinieriaus kurso vedėjas.
Laukiant naujos registracijos į kursą pradžios , parengiau straipsnių ciklą apie VxLAN EVPN technologiją.
Yra labai daug medžiagos apie tai, kaip veikia VxLAN EVPN, todėl noriu surinkti įvairias užduotis ir praktiką, kaip spręsti problemas šiuolaikiniame duomenų centre.
Pirmoje serijos apie VxLAN EVPN technologiją dalyje noriu pažvelgti į būdą, kaip organizuoti L2 ryšį tarp pagrindinių kompiuterių tinklo audinio viršuje.
Visi pavyzdžiai bus atlikti naudojant „Cisco Nexus 9000v“, surinktą pagal „Spine-Leaf“ topologiją. Šiame straipsnyje mes nenagrinėsime apatinio sluoksnio tinklo nustatymo.
- Pakloto tinklas
- BGP susiejimas su adresų šeima l2vpn evpn
- NVE nustatymas
- Slopinti-arp
Pakloto tinklas
Naudojama tokia topologija:
Nustatykime adresą visuose įrenginiuose:
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.20Patikrinkite, ar tarp visų įrenginių yra IP ryšys:
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, intraPatikrinkite, ar buvo sukurtas VPC domenas ir abu jungikliai išlaikė nuoseklumo patikrinimą, o nustatymai abiejuose mazguose yra identiški:
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 žiūrėjimas
Galiausiai galite pereiti prie perdangos tinklo nustatymo.
Kaip straipsnio dalį būtina organizuoti tinklą tarp pagrindinių kompiuterių, kaip parodyta toliau pateiktoje diagramoje:
Norėdami sukonfigūruoti perdangos tinklą, turite įjungti BGP jungikliuose Spine ir Leaf su l2vpn evpn šeimos palaikymu:
feature bgp
nv overlay evpnTada turite sukonfigūruoti BGP tarpusavio ryšį tarp Leaf ir Spine. Norėdami supaprastinti sąranką ir optimizuoti maršruto informacijos paskirstymą, sukonfigūruojame „Spine“ kaip maršruto atspindžio serverį. Norėdami optimizuoti sąranką, į konfigūraciją įrašysime visus lapus naudodami šablonus.
Taigi Spine nustatymai atrodo taip:
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 LEAF„Leaf“ jungiklio sąranka atrodo panašiai:
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 SPINE„Spine“ patikrinkime ryšį su visais „Leaf“ jungikliais:
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 0Kaip matote, su BGP problemų nebuvo. Pereikime prie VxLAN nustatymo. Tolesnė konfigūracija bus atliekama tik jungiklių lapų pusėje. Spine veikia tik kaip tinklo šerdis ir dalyvauja tik perduodant srautą. Visi inkapsuliavimo ir kelio nustatymo darbai atliekami tik ant Leaf jungiklių.
NVE nustatymas
NVE – tinklo virtuali sąsaja
Prieš pradėdami sąranką, pristatykime keletą terminų:
VTEP – Vitual Tunnel End Point, įrenginys, kuriame VxLAN tunelis prasideda arba baigiasi. VTEP nebūtinai yra bet koks tinklo įrenginys. Serveris, palaikantis VxLAN technologiją, taip pat gali veikti kaip serveris. Mūsų topologijoje visi Leaf jungikliai yra VTEP.
VNI – virtualaus tinklo indeksas – tinklo identifikatorius VxLAN. Analogiją galima nubrėžti su VLAN. Tačiau yra tam tikrų skirtumų. Naudojant audinį, VLAN tampa unikalūs tik viename Leaf jungiklyje ir neperduodami per tinklą. Bet kiekvienas VLAN gali turėti su juo susietą VNI numerį, kuris jau perduodamas tinklu. Kaip jis atrodo ir kaip jį galima naudoti, bus aptarta toliau.
Įgalinkime VxLAN technologijos funkciją ir galimybę susieti VLAN numerius su VNI numeriu:
feature nv overlay
feature vn-segment-vlan-basedSukonfigūruokime NVE sąsają, kuri yra atsakinga už VxLAN veikimą. Ši sąsaja yra atsakinga už kadrų įtraukimą į VxLAN antraštes. Galite padaryti analogiją su GRE tunelio sąsaja:
interface nve1
no shutdown
host-reachability protocol bgp ! используем BGP для передачи маршрутной информации
source-interface loopback0 ! интерфейс с которого отправляем пакеты loopback0Ant Leaf-21 jungiklio viskas sukurta be problemų. Tačiau jei patikrinsime komandos išvestį show nve peers, tada jis bus tuščias. Čia reikia grįžti prie VPC konfigūracijos. Matome, kad Leaf-11 ir Leaf-12 veikia poromis ir juos vienija VPC domenas. Tai suteikia mums tokią situaciją:
„Host-2“ siunčia vieną kadrą link „Leaf-21“, kad jis per tinklą perduotų jį prie pagrindinio kompiuterio-1. Tačiau „Leaf-21“ mato, kad „Host-1“ MAC adresas yra pasiekiamas per du VTEP vienu metu. Ką tokiu atveju turėtų daryti Leaf-21? Juk tai reiškia, kad tinkle gali atsirasti kilpa.
Norėdami išspręsti šią situaciją, mums reikia, kad Leaf-11 ir Leaf-12 taip pat veiktų kaip vienas įrenginys gamykloje. Sprendimas gana paprastas. „Loopback“ sąsajoje, iš kurios statome tunelį, pridėkite antrinį adresą. Antrinis adresas turi būti vienodas abiejuose VTEP.
interface loopback0
ip add 10.255.1.10/32 secondaryTaigi, kitų VTEP požiūriu, gauname tokią topologiją:
Tai reiškia, kad dabar tunelis bus pastatytas tarp Leaf-21 IP adreso ir virtualaus IP tarp dviejų Leaf-11 ir Leaf-12. Dabar nebus jokių problemų išmokti MAC adresą iš dviejų įrenginių, o srautas gali judėti iš vieno VTEP į kitą. Kuris iš dviejų VTEP apdoros srautą, sprendžiama naudojant „Spine“ maršruto parinkimo lentelę:
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, intraKaip matote aukščiau, adresas 10.255.1.10 pasiekiamas iš karto per du „Next-hops“.
Šiame etape mes sprendėme pagrindinį ryšį. Pereikime prie NVE sąsajos nustatymo:
Iš karto įgalinkime Vlan 10 ir susiekime jį su VNI 10000 kiekviename šeimininkų lape. Sukurkime L2 tunelį tarp kompiuterių
vlan 10 ! Включаем VLAN на всех VTEP подключенных к необходимым хостам
vn-segment 10000 ! Ассоциируем VLAN с номер VNI
interface nve1
member vni 10000 ! Добавляем VNI 10000 для работы через интерфейс NVE. для инкапсуляции в VxLAN
ingress-replication protocol bgp ! указываем, что для распространения информации о хосте используем BGPDabar patikrinkime nve bendraamžių ir BGP EVPN lentelę:
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 iViršuje matome tik EVPN maršruto tipo 3 maršrutus. Šio tipo maršrute kalbama apie peer(Leaf), bet kur mūsų šeimininkai?
Reikalas tas, kad informacija apie MAC pagrindinius kompiuterius perduodama per 2 tipo EVPN maršrutą
Norėdami pamatyti mūsų prieglobas, turite sukonfigūruoti 2 tipo EVPN maršrutą:
evpn
vni 10000 l2
route-target import auto ! в рамках данной статьи используем автоматический номер для route-target
route-target export autoSiųskime ping nuo Host-2 į 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 msIr žemiau matome, kad BGP lentelėje pasirodė maršruto tipas 2 su pagrindinio kompiuterio MAC adresu - 5001.0007.0007 ir 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 iToliau galite pamatyti išsamią informaciją apie atnaujinimą, kuriame gavote informaciją apie MAC pagrindinį kompiuterį. Žemiau pateikiama ne visa komandos išvestis.
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
<........>Pažiūrėkime, kaip atrodo rėmeliai, kai jie praeina per gamyklą:
Slopinti-ARP
Puiku, dabar turime L2 ryšį tarp šeimininkų ir galime baigti ten. Tačiau ne viskas taip paprasta. Kol turėsime mažai šeimininkų, problemų nebus. Bet įsivaizduokime situaciją, kai turime šimtus ir tūkstančius šeimininkų. Su kokia problema galime susidurti?
Ši problema yra BUM (Broadcast, Unknown Unicast, Multicast) srautas. Šiame straipsnyje mes apsvarstysime galimybę tvarkyti transliacijos srautą.
Pagrindinis transliacijos generatorius Ethernet tinkluose yra patys pagrindiniai kompiuteriai per ARP protokolą.
„Nexus“ įgyvendina šį mechanizmą, skirtą kovoti su ARP užklausomis – suppress-arp.
Ši funkcija veikia taip:
- „Host-1“ siunčia APR užklausą savo tinklo transliacijos adresu.
- Užklausa pasiekia Leaf jungiklį ir užuot perdavusi šią užklausą toliau į audinį Host-2, Leaf atsako pats ir nurodo reikiamą IP ir MAC.
Taigi, Transliacijos prašymas į gamyklą nenukeliavo. Bet kaip tai gali veikti, jei Leaf žino tik MAC adresą?
Viskas gana paprasta, EVPN route-type 2, be MAC adreso, gali perduoti MAC/IP derinį. Norėdami tai padaryti, turite sukonfigūruoti IP adresą VLAN lape. Kyla klausimas, kokį IP turėčiau nustatyti? „Nexus“ visuose jungikliuose galima sukurti paskirstytą (tą patį) adresą:
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 macTaigi, šeimininkų požiūriu, tinklas atrodys taip:
Patikrinkime 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
<......>Iš komandos išvesties matote, kad 2 tipo EVPN maršrute, be MAC, dabar matome ir pagrindinio kompiuterio IP adresą.
Grįžkime prie slopinimo arp nustatymo. Šis nustatymas įgalinamas kiekvienam VNI atskirai:
interface nve1
member vni 10000
suppress-arpTada atsiranda tam tikras sudėtingumas:
- Kad ši funkcija veiktų, reikia vietos TCAM atmintyje. Čia yra slopinimo arp nustatymų pavyzdys:
hardware access-list tcam region arp-ether 256Šiam nustatymui reikės dvigubo pločio. Tai yra, jei nustatote 256, TCAM turite atlaisvinti 512. TCAM nustatymas nepatenka į šio straipsnio taikymo sritį, nes TCAM nustatymas priklauso tik nuo jums priskirtos užduoties ir gali skirtis priklausomai nuo tinklo.
- Suppress-arp diegimas turi būti atliktas visuose Leaf jungikliuose. Tačiau konfigūruojant lapų poras, esančias VPC domene, gali kilti sudėtingumo. Pakeitus TCAM, porų nuoseklumas bus pažeistas ir vienas mazgas gali būti išjungtas. Be to, norint pritaikyti TCAM pakeitimo nustatymą, gali reikėti iš naujo paleisti įrenginį.
Todėl turite atidžiai apsvarstyti, ar jūsų situacijoje verta įdiegti šį nustatymą veikiančioje gamykloje.
Tuo baigiama pirmoji serijos dalis. Kitoje dalyje apžvelgsime maršruto parinkimą per VxLAN audinį su tinklų atskyrimu į skirtingus VRF.
O dabar kviečiu visus , kuriame išsamiai papasakosiu apie kursą. Pirmieji 20 dalyvių, užsiregistravusių į šį internetinį seminarą, per 1-2 dienas po transliacijos gaus nuolaidos sertifikatą el. paštu.
Šaltinis: www.habr.com