Tere, habr. Olen praegu OTUSes kursuse "Võrgutehnik" juht.
Uue kursuse alguse eelõhtul , olen valmistanud ette artiklite seeria VxLAN EVPN tehnoloogia kohta.
VxLAN EVPNi töötamise kohta on tohutult palju materjale, seega tahan koguda erinevaid ülesandeid ja praktika lahendusi kaasaegses andmekeskuses.
VxLAN EVPNi tehnoloogia esimeses osas tahan vaadata, kuidas korraldada L2 ühenduvust hostide vahel võrgufabriku kohal.
Kõiki näiteid teeme Cisco Nexus 9000v seadmetel, mis on kokku pandud Spine-Leaf topoloogiasse. Artiklis ei peatume aluste võrgu seadistamisel.
- Alusvõrk
- BGP peerimine address-family l2vpn evpn jaoks
- NVE seadistamine
- Supress-arp
Alusvõrk
Kasutatav topoloogia näeb välja järgnev:
Seame aadressid kõigile seadmetele:
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.20Kontrollime, kas kõikide seadmete vahel on IP-ühenduvus:
Leaf21# sh ip route
10.255.1.11/32, ubest/mbest: 2/0 ! Leaf-11 on saadaval kahe Spine'i kaudu
*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 on saadaval kahe Spine'i kaudu
*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, intraKontrollime, et VPC domeen on loodud ja mõlema lülituse seadistused on mõlemas sõlmes võrdsed:
Leaf11# näita vpc
vPC domeeni ID : 1
Peer staatust : peer naabrus loodud ok
vPC keep-alive staatust : peer on elus
Konfiguratsiooni ühtsuse staatus : edu
Per-vlan ühtsuse staatus : edu
Tüüp-2 ühtsuse staatus : edu
vPC roll : põhiosa
Konfigureeritud vPC-de arv : 0
Peer Gateway : keelatud
Kaks aktiivset VLAN-i välistatud : -
Jõhkruse ühtsuse kontroll : lubatud
Automaatne taastumise staatus : keelatud
Viivituse taastumise staatus : Taimer on välja. (aegumine = 30s)
Viivituse taastumise SVI staatus : Taimer on välja. (aegumine = 10s)
Töötav Layer3 Peer-router : keelatud
vPC staatus
----------------------------------------------------------------------------
Id Port Staatus Ühtsus Põhjus Aktiivsed VLAN-id
-- ------------ ------ ----------- ------ ---------------
5 Po5 üles edu edu 1BGP peerimine
Lõpuks saab minna Overlay võrgu seadistamise juurde.
Käesolevas artiklis tuleb korraldada võrk hostide vahel, nagu on näidatud allolevas skeemis:
Overlay võrgu seadistamiseks tuleb Spine'i ja Leaf'i lülitites lubada BGP l2vpn evpn perede toetusega:
feature bgp
nv overlay evpnSeejärel tuleb seadistada BGP peerimine Leaf'i ja Spine'i vahel. Seadistamise lihtsustamiseks ja marsruudi teabe levitamise optimeerimiseks seadistame Spine'i Route-Reflector serverina. Kõik Leaf'id lisame konfiguratsiooni läbi šabloonide, et optimeerida seadistamist.
Nii näevad Spine'i seadistused välja:
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 LEAFLeaf-i lüliti seadistus näeb välja sarnane:
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 SPINEKontrollime Spine'is kõikide Leaf lülitite vahel olekut:
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 0Nagu näeme, ei tekkinud BGP-ga mingeid probleeme. Liigume edasi VxLAN seadistamise juurde. Edasine seadistamine toimub ainult Leaf lülitite küljel. Spine toimib ainult võrgu tuumana ja tegeleb ainult liikluse edastamisega. Kõik kapseldamise ja marsruudi määramise tööd toimuvad ainult Leaf lülitites.
NVE seadistamine
NVE — võrgu virtuaalne liides.
Enne seadistamise alustamist tutvume mõne terminoloogiaga:
VTEP — Virtuaalne Tunnelite Lõpp-punkt, seade, kust algab või lõpeb VxLAN tunnel. VTEP ei pea tingimata olema mingisugune võrguseade. Samuti võib selleks olla ka server, mis toetab VxLAN tehnoloogiat. Meie topoloogias on kõik Leaf lülitid VTEP-d.
VNI — Virtuaalne Võrgumärkeruut — võrguharu identifikaator VxLAN raames. Seda saab võrrelda VLAN-iga. Kuid on ka teatud erinevused. Kasutades tehast, saavad VLAN-id unikaalseks ainult ühes Leaf lülitises ja ei edastata võrgus. Kuid igale VLAN-ile võib olla määratud VNI number, mis edastatakse võrgus. Kuidas see välja näeb ja kuidas seda kasutada, käsitletakse edasi.
Lükkame sisse VxLAN tehnoloogia funktsiooni ja võimaluse seostada VLAN numbrid VNI numbriga:
feature nv overlay
feature vn-segment-vlan-basedKonfigureerime NVE liidese, mis vastutab VxLAN töö eest. See liides vastutabki kaadrite kapseldamise eest VxLAN peadele. Seda võib võrrelda Tunnel liidesega GRE tööks:
interface nve1
no shutdown
host-reachability protocol bgp ! kasutame BGP-d marsruutide teabe edastamiseks
source-interface loopback0 ! liides, millest saadame pakette loopback0Leaf-21 lülitil ei teki probleeme seadistamisega. Kui aga vaatame käsku show nve peers, siis see on tühi. Siin tuleb naasta VPC seadistusse. Näeme, et Leaf-11 ja Leaf-12 töötavad koos ja on ühendatud VPC domeeniga. Seega on olukord järgmine:
Host-2 saadab ühe paketi Leaf-21 suunas, et see edastaks selle võrku Host-1 suunas. Kuid Leaf-21 näeb, et MAC-aadress Host-1 on kergesti ligipääsetav kahe VTEP kaudu. Kuidas peaks Leaf-21 sellises olukorras käituma? See tähendab, et võrgus võib tekkida silmus.
Selle olukorra lahendamiseks peame tagama, et Leaf-11 ja Leaf-12 toimiksid tehases ühe seadmena. See lahendatakse üsna lihtsalt. Loopback liidesel, millelt tunnelit loome, lisame sekundaarse aadressi. Sekundaarne aadress peab olema mõlemal VTEP-l sama.
interface loopback0
ip add 10.255.1.10/32 secondaryNii saame teiste VTEP-de vaatenurgast järgmise topoloogia:
Seega hakatakse tunnelit ehitama Leaf-21 IP-aadressi ja kahe Leaf-11 ja Leaf-12 vahelise virtuaalse IP vahel. Nüüd ei esine probleeme MAC-aadressi õppimisega kahe seadme vahel ning liiklus saab suunduda ühelt VTEP-ilt teisele. Milline kahest VTEP-ist liiklust käsitleb, otsustatakse Spine'i marsruutimistabeli abil:
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, intraNagu ülal näha, on aadress 10.255.1.10 kergesti ligipääsetav läbi kahe Next-hop-i.
Selles etapis oleme saanud aru baasühenduvusest. Liigume edasi NVE liidese seadistamise juurde:
Kohe aktiveerime VLAN 10 ja seome selle VNI 10000-ga igas Leafis, mis on seotud hostidega. Seadistame L2 tunneli hostide vahel.
vlan 10 ! Lülitame VLAN-i sisse kõigil VTEP-del, mis on vajalikud hostide jaoks
vn-segment 10000 ! Seome VLAN-i VNI numbriga
interface nve1
member vni 10000 ! Lisame VNI 10000, et töötada läbi NVE liidese ja kapseldada VxLAN-i
ingress-replication protocol bgp ! Näitame, et hosti teabe levitamiseks kasutame BGPNüüd kontrollime nve peers ja tabelit BGP EVPN jaoks:
Leaf21# sh nve peers
Interface Peer-IP State LearnType Uptime Router-Mac
--------- --------------- ----- --------- -------- -----------------
nve1 10.255.1.10 Up CP 00:00:41 n/a ! Näeme, et peer on kergesti kätte saadav sekundaarse aadressi kaudu
Leaf11# sh bgp l2vpn evpn
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.255.1.11:32777 (L2VNI 10000) ! Kust see l2VNI täpselt tuli
*>l[3]:[0]:[32]:[10.255.1.10]/88 ! EVPN marsruut-tüüp 3 - näitab meie naabrit, kes teab samuti l2VNI10000-st
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 iÜlal näeme ainult EVPN marsruute, mille tüüp on 3. See marsruudi tüüp räägib peerist (Leaf), aga kus on meie hostid?
Põhjus on selles, et MAC aadressi info edastatakse EVPN marsruudi tüübiga 2
Kuna meie hostide nägemiseks peab olema seadistatud EVPN marsruudi tüüp 2:
evpn
vni 10000 l2
route-target import auto ! Käesolevas artiklis kasutame automaatset numbrit route-target jaoks
route-target export autoTeeme ping'i Host-2-st Host-1-ile:
Firewall2# ping 192.168.10.1
PING 192.168.10.1 (192.168.10.1): 56 andmeebaidi
36 baiti 192.168.10.2-st: sihtkoht ei ole kätte saadav
Päring 0 aegus
64 baiti 192.168.10.1-st: icmp_seq=1 ttl=254 aeg=215.555 ms
64 baiti 192.168.10.1-st: icmp_seq=2 ttl=254 aeg=38.756 ms
64 baiti 192.168.10.1-st: icmp_seq=3 ttl=254 aeg=42.484 ms
64 baiti 192.168.10.1-st: icmp_seq=4 ttl=254 aeg=40.983 msJa allpool saame näha, et BGP tabelis on ilmunud route-type 2 koos hostide MAC-aadressidega — 5001.0007.0007 ja 5001.0008.0007
Leaf11# sh bgp l2vpn evpn
Võrk Järgmine Hüppe Meetri LocPrf Kaal Tee
Reisi eristaja: 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 ja hosti mac-aadress 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 ja hosti mac-aadress 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
Reisi eristaja: 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 iEdasi liikudes saab vaadata üksikasjalikku teavet värskenduse kohta, milles saime teavet MAC hosti kohta. Allpool ei ole esitatud kogu käsu väljundit.
Leaf21# sh bgp l2vpn evpn 5001.0007.0007
BGP marsruutimise tabeli info VRF default, aadressi perekonda L2VPN EVPN
Marsruudi eristaja: 10.255.1.11:32777 ! saatis värskenduse MAC Hostiga. Mitte VPC virtuaalne aadress, vaid Leafi aadress
BGP marsruutimise tabeli kanne [2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]/216,
versioon 1507
Teed: (2 saadaval, parim #2)
Lipud: (0x000202) (high32 00000000) xmit-listis, ei ole l2rib/evpn-is, ei ole HW-s
Tee tüüp: sisemine, tee on kehtiv, mitte parim põhjus: Naabri aadress, puudub silte saanud järgmine hüppamine
AS-Path: PUUDUB, tee on seespool AS-i
10.255.1.10 (mõõdik 81) aadressilt 10.255.1.102 (10.255.1.102) ! kellega täpselt ehitame VxLAN tunneli
Origin IGP, MED pole seadistatud, kohalik eelis 100, kaal 0
Vastuvõetud silt 10000 ! VNI number, mis on seotud VLANiga, kus Host asub
Extcommunity: RT:65001:10000 SOO:10.255.1.10:0 ENCAP:8 ! Siit on näha, et RT on automaatselt loodud AS-ide ja VNI numbrite põhjal
Originator: 10.255.1.11 Klasteriluettelo: 10.255.1.102Vaadakem, kuidas kaadrid välja näevad, kui need edastatakse läbi tehase:
Suppress-ARP
Suurepärane, L2 ühendus hostide vahel on meil olemas ja sellega võiksime lõpetada. Kuid asi pole nii lihtne. Seni, kuni meil on vähe hoste, probleeme ei teki. Kuid kujutage ette olukordi, kus hoste on sadu ja tuhandeid. Millise probleemiga võime silmitsi seista?
See probleem on BUM (Broadcast, Unknown Unicast, Multicast) liiklus. Selles artiklis vaatleme, kuidas võidelda broadcast liiklusega.
Etherneti võrkudes on peamine Broadcast generaator ise hostid, kasutades ARP protokolli.
Nexusel on rakendatud järgmine mehhanism ARP päringute vastu — suppress-arp.
Selle funktsiooni töö näeb välja järgmine:
- Host-1 saadab APR päringu oma võrgu Broadcast aadressile.
- Päring jõuab Leaf lülitisse ja selle asemel, et edastada päring edasiseks töödlemiseks tehasesse suunas Host-2 — Leaf vastab ise ja määrab vajaliku IP ja MAC aadressi.
Seega ei läinud Broadcast päring tehasesse. Aga kuidas see võib toimida, kui Leaf teab ainult MAC aadressi?
Kõik on üsna lihtne, EVPN route-type 2 saab edastada lisaks MAC aadressile ka MAC/IP paari. Selleks peab Leafil olema VLAN-is konfigureeritud IP aadress. Tekib küsimus, millise IP-d määrata? Nexusel on võimalus luua jaotatud (ühesugune) aadress kõigil lülititel:
funktsioon interface-vlan
fabric forwarding anycast-gateway-mac 0001.0001.0001 ! määrame virtuaalse maci, et luua jaotatud lüüsi kõikide lülitite vahel
interface Vlan10
no shutdown
ip address 192.168.10.254/24 ! määrame kõigil Leaf'e sama IP
fabric forwarding mode anycast-gateway ! ütleme, et kasutada Virtuaalset maciSeega näeb võrgu vaatepunktist hostide jaoks võrk välja järgmine:
Kontrollime 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 iKäsku käivitades on selgelt näha, et EVPN route-type 2 näitab lisaks MAC-ile nüüd ka hosti IP-aadressi.
Naasume suppress-arp seadistuse juurde. See seade aktiveeritakse iga VNI puhul eraldi:
interface nve1
member vni 10000
suppress-arpEdasi tuleb teatud keerukus:
- Selle funktsiooni tööks on vajalik ruum TCAM mälus. Toon näite suppress-arp seadistusest:
hardware access-list tcam region arp-ether 256Selle seadistuse jaoks on vajalik double-wide. See tähendab, et kui määrate 256, tuleb TCAM-is vabastada 512. TCAM-i seadistamine ületab selle artikli piire, kuna TCAM-i seadistus sõltub ainult teile seatud ülesandest ja võib varieeruda ühe võrgu ja teise vahel.
- Suppress-arp rakendamine on vajalik kõigil Leaf lülititel. Siiski võib ilmnenud raskusi seoses seadistamisega VPC domeenis asuvate Leaf paaride vahel. TCAM-i muutmisel rikutakse paaride vahel konsistentsi ja üks sõlme võib väljuda tööst. Lisaks võib seadistuse muutmiseks TCAM-is vajada seadme taaskäivitamist.
Seetõttu tuleb hoolikalt mõelda, kas teie olukorras on mõistlik rakendada seda seadistust töötavas tehases.
Lõpetame selle tsükli esimese osa. Järgmisel korral vaatame VxLAN tehase kaudu suunamist, jagades võrgud erinevatesse VRF-idesse.
Ja nüüd kutsun kõiki , mille raames räägin ma kursusest põhjalikumalt. Esimesed 20 osalejat, kes registreeruvad sellele veebinarile, saavad 1–2 päeva jooksul pärast edastamist e-posti teel soodustuse sertifikaadi.
Allikas: habr.com
