Tere, Habr. Praegu olen ma OTUSis kursuse "Võrgutehnik" juhataja.
Uue kursuse alguse eelõhtul , olen valmistanud ette artiklite seeria VxLAN EVPN tehnoloogiast.
VxLAN EVPN töö osas on olemas tohutult materjale ning tahan kokku koguda erinevaid ülesandeid ja praktikaid nende lahendamiseks kaasaegses andmekeskuses.
Seeria esimeses osas VxLAN EVPN tehnoloogia kohta tahan kaaluda L2 ühenduse korraldamise viisi hostide vahel võrgu tehase kohal.
Kõik näited teeme Cisco Nexus 9000v seadmetel, mis on üles ehitatud Spine-Leaf topoloogias. Me ei pea peatuma Underlay võrgu seadistamisele selle artikli raames.
- Underlay võrk
- BGP peering address-family l2vpn evpn jaoks
- NVE seadistus
- Supress-arp
Underlay võrk
Kasutatav topoloogia on järgmine:
Seame aadressid kõikidele 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, et kõigi seadmete vahel on IP ühendus:
Leaf21# sh ip route
10.255.1.11/32, ubest/mbest: 2/0 ! Leaf-11 on kergelt kergesti kättesaadav 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 kergelt kergesti kättesaadav 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õlemad lülitid on läbinud järjepidevuse kontrolli ning seadistused mõlemal node'il on identsed:
Leaf11# show vpc
vPC domeeni ID : 1
Peer staatus : peer adjacency formed ok
vPC keep-alive staatus : peer is alive
Seadistuse järjepidevuse staatus : success
Per-vlan järjepidevuse staatus : success
Type-2 järjepidevuse staatus : success
vPC roll : primary
Konfigureeritud vPC-de arv : 0
Peer Gateway : Disabled
Dual-active excluded VLANs : -
Graceful Consistency Check : Enabled
Auto-recovery staatus : Disabled
Delay-restore staatus : Timer is off.(timeout = 30s)
Delay-restore SVI staatus : Timer is off.(timeout = 10s)
Operational Layer3 Peer-router : Disabled
vPC staatus
----------------------------------------------------------------------------
Id Port Staatus Järjepidevuse Põhjus Aktiivsed vlans
-- ------------ ------ ----------- ------ ---------------
5 Po5 up success success 1BGP peering
Lõpuks saab minna Overlay võrgu seadistamise juurde.
Artiklis tuleb korraldada võrk hostide vahel, nagu on näidatud alloleval skeemil:
Overlay-võrgu seadistamiseks tuleb Spine'i ja Leafi lülitites aktiveerida BGP koos l2vpn evpn pereliigi toega:
feature bgp
nv overlay evpnSeejärel tuleb seadistada BGP peerimine Leafi ja Spine'i vahel. Seadistuse lihtsustamiseks ja marsruutimise teabe leviku optimeerimiseks seadistame Spine'i Route-Reflector serverina. Kõik Leafid määrame konfiguratsioonis mallide kaudu, et optimeerida seadistust.
Seega näeb Spine'i seadistus välja selline:
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 LEAFLeafi 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 SPINESpines kontrollime peerimist kõigi Leafi lülititega:
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 0Kuidas näeme, BGP-ga ei esinenud mingeid probleeme. Jätkame VxLAN seadistamisega. Edasi liikuv seadistus toimub ainult Leafi lülitites. Spine toimib ainult võrgu südames ja tegeleb ainult liikluse edastamisega. Kõik kapseldamise ja marsruudi määramise töö toimub ainult Leafi lülitites.
NVE seadistus
NVE — võrgu virtuaalne liides
Seadistamise alguses tutvume mõningate terminitega:
VTEP — Virtuaalne Tunnelite Lõpp Punkt, seade, kus VxLAN tunnel algab või lõpeb. VTEP ei pea olema tingimata mõni võrgu seade. Võib olla ka server, mis toetab VxLAN tehnoloogiat. Meie topoloogias on kõik Leafi lülitid VTEP.
VNI — Virtuaalne Võrgu Indeks — võrgus oleva identifikaator VxLAN-s. Seda võib võrrelda VLAN-iga. Kuid on mõned erinevused. Fabriku kasutamisel on VLAN-id unikaalsed ainult ühe Leafi lüliti raames ega edastata võrgus. Iga VLAN-iga võib olla seotud VNI number, mis edastatakse juba võrgus. Kuidas see välja näeb ja kuidas seda kasutada, arutatakse hiljem.
Lülitame sisse funktsiooni VxLAN tehnoloogia töö jaoks ja võimaluse assotsieerida VLAN numbrid VNI numbriga:
funktsioon nv overlay
funktsioon vn-segment-vlan-basedSeame üles NVE liidese, mis vastutab VxLAN töö eest. See liides vastutab just kaadrite kapseldamise eest VxLAN pealdistes. Võib teha analoogia GRE tunneliliideste tööga:
liides nve1
ei suleta
host-ülatusprotokoll bgp ! kasutame BGP-d marsruutide teabe edastamiseks
source-interface loopback0 ! liides, mille kaudu saadame pakette loopback0Leaf-21 lülitil luuakse kõik ilma probleemideta. Kui me kontrollime käsku show nve peers, siis see osutub tühjaks. Siin on vajalik naasta VPC seadistuse juurde. Näeme, et Leaf-11 ja Leaf-12 töötavad paaris ja on ühendatud VPC domeeniga. Sellest tuleneb järgmine olukord:
Host-2 saadab ühe kaadri Leaf-21 suunas, et see edastaks selle võrku Host-1 suunas. Kuid Leaf-21 näeb, et MAC-aadress Host-1 on kergesti kätte saadav kahe VTEP kaudu. Kuidas peaks Leaf-21 sellisel juhul toimima? See tähendab, et võrgus võib olla ilmnenud silmus.
Selle olukorra lahendamiseks on meil vaja, et Leaf-11 ja Leaf-12 tegutseksid tehase raames ühtse seadmena. See lahendatakse üsna lihtsalt. Loopback liidese kaudu, millest me tunnelit ehitame, lisame sekundaarse aadressi. Sekundaarne aadress peab olema mõlemal VTEP-il sama.
liides loopback0
ip add 10.255.1.10/32 sekundaarneNii saame teiste VTEP-de vaatepunktist järgmise topoloogia:
Seega ehitatakse nüüd tunnel IP-aadressi Leaf-21 ja virtuaalse IP vahel kahe Leaf-11 ja Leaf-12 vahel. Nüüd ei teki probleeme kahe seadme MAC-aadressi tuvastamisega ning liiklus võib liikuda ühelt VTEP-ilt teisele. Kes täpselt kahest VTEP-ist liiklust käsitleb, otsustatakse Spine'i marsruuditabeli 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, intraKuidas eespool nähtud, on aadress 10.255.1.10 kohe saadaval kahe Next-hop kaudu.
Sellel etapil oleme selgitanud põhikontakti. Liigume edasi NVE liidese seadistamise juurde:
Lülitame kohe sisse VLAN 10 ja assotsieerime selle VNI 10000 igas Leafis hostide jaoks. Seame üles L2 tunnelite vahel hostide vahel.
vlan 10 ! Lülitame VLAN-i sisse kõigil VTEP-del, mis on ühendatud vajalike hostidega
vn-segment 10000 ! Seome VLAN-i numbriga VNI
interface nve1
member vni 10000 ! Lisame VNI 10000, et töötada NVE liidese kaudu VxLAN-i kapseldamiseks
ingress-replication protocol bgp ! Osutame, et hosti teabe edastamiseks kasutame BGP-dNüüd kontrollime nve peers ja BGP EVPN'i tabelit:
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 saadaval sekundaarse aadressi kaudu
Leaf11# sh bgp l2vpn evpn
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.255.1.11:32777 (L2VNI 10000) ! Kes täpselt saatis selle l2VNI
*>l[3]:[0]:[32]:[10.255.1.10]\/88 ! EVPN marsruut-tüüp 3 - näitab meie naabrit, kes teab ka 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 marsruut-tüübi 3. See marsruut-tüüp räägib peer-ist (Leaf), kuid kus on meie hostid?
Asi on selles, et MAC aadresside teave edastatakse läbi EVPN marsruut-tüübi 2.
Kuna tahame näha meie hoste, peame seadistama EVPN marsruut-tüübi 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-le:
Firewall2# ping 192.168.10.1
PING 192.168.10.1 (192.168.10.1): 56 andmebytes
36 bytes from 192.168.10.2: Sihtkoht Host Ühendamatuks
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 msJa allpool näeme, et BGP tabelis on ilmunud marsruut-tüüp 2 koos hostide MAC aadressidega — 5001.0007.0007 ja 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 and mac address of host 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 and mac address of host 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 iSee below for detailed information on the Update that provided information about the MAC Host. The output of the command is not fully represented below.
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 ! sent an Update with MAC Host. Not a virtual address of VPC, but the address of 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 in HW
Path type: internal, path is valid, not best reason: Neighbor Address, no labeled nexthop
AS-Path: NONE, path sourced internal to AS
10.255.1.10 (metric 81) from 10.255.1.102 (10.255.1.102) ! with whom exactly we are building the VxLAN tunnel
Origin IGP, MED not set, localpref 100, weight 0
Received label 10000 ! The VNI number associated with the VLAN in which the Host is located
Extcommunity: RT:65001:10000 SOO:10.255.1.10:0 ENCAP:8 ! Here we can see that the RT was generated automatically based on AS and VNI numbers
Originator: 10.255.1.11 Cluster list: 10.255.1.102Let's take a look at how the frames look when they are transmitted through the fabric:
Suppress-ARP
Great, we have established L2 connectivity between hosts and this could have been the end of it. However, it’s not that simple. While we have few hosts, there won't be any issues. But let's imagine a situation where we have hundreds or thousands of hosts. What problems can we face?
This problem is BUM (Broadcast, Unknown Unicast, Multicast) traffic. In this article, we will discuss the approach to combating broadcast traffic.
The main generator of Broadcast in Ethernet networks are the hosts themselves via the ARP protocol.
Nexus implements the following mechanism to combat ARP requests — suppress-arp.
The functioning of this feature looks as follows:
- Host-1 sends an ARP request to the Broadcast address of its network.
- The request reaches the Leaf switch and instead of passing this request further into the fabric towards Host-2, the Leaf responds itself, providing the required IP and MAC.
Seega Broadcast-päring ei läinud tehasesse. Kuid kuidas see saab toimida, kui Leaf teab vaid MAC-aadressi?
Kõik on üsna lihtne, EVPN route-type 2 võib MAC-aadressi kõrval edastada ka MAC/IP paari. Selleks on Leafil vajalik VLAN-is IP-aadress seadistada. Tekib küsimus, millise IP peame seadistama? Nexusel on võimalik luua jaotatud (ühtlane) aadress kõigis lülitites:
feature interface-vlan
fabric forwarding anycast-gateway-mac 0001.0001.0001 ! seadistame virtual mac jaotatud värava loomiseks kõikide lülitite vahel
interface Vlan10
no shutdown
ip address 192.168.10.254/24 ! kõikidel Leafidel seadistame sama IP
fabric forwarding mode anycast-gateway ! määrame kasutama Virtual macSeega hostide vaatepunktist näeb võrk välja järgmiselt:
Kontrollime BGP l2route evpn
Leaf11# sh bgp l2vpn evpn
Võrk Järgmine hüpik Meetri LocPrf Kaal Rada
Teerajaja eristaja: 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
Teerajaja 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 i
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.10.20]/248
*>i 10.255.1.20 100 0 iKäsku vaadates on näha, et EVPN route-type 2 tõttu MAC-i kõrval näeme nüüd ka hosti IP-aadressi.
Naaseme suppress-arp seadistuse juurde. See seade aktiveeritakse iga VNI jaoks eraldi:
interface nve1
member vni 10000
suppress-arpSeejärel tekib teatav keerukus:
- Selle funktsiooni tööks on vajalik ruumi TCAM-mälus. Toon näite suppress-arp seadistusest:
hardware access-list tcam region arp-ether 256Selle seadistuse jaoks on vajalik double-wide. Seega, kui seadistate 256, tuleb TCAM-is vabastada 512. TCAM-i seadistamine ületab selle artikli piire, kuna TCAM-i seadistamine sõltub ainult esitatud ülesandest ja võib varieeruda ühe võrgu ja teise vahel.
- Suppress-arp rakendamine peab toimuma kõigis Leaf lülitites. Siiski võib keerukus tekkida kahe Leaf'i seadme seadistamisel, mis asuvad VPC domeenis. TCAM'i muutmise korral võib paaride vahel tekkida ebakõla ja üks node võib töölt langeda. Lisaks võib TCAM'i seadistuse rakendamiseks olla vajalik seadme taaskäivitamine.
Seetõttu tuleks hoolikalt kaaluda, kas teie olukorras on mõistlik rakendada seda seadistust töötavale tehasele.
Sellega lõpetame tsükli esimese osa. Järgmises osas vaatleme marsruutimist VxLAN tehase kaudu, jagades võrke erinevate VRF-ide vahel.
Ja praegu kutsun kõiki osalema , mille raames räägin ma põhjalikult kursusest. Esimesed 20 osalejat, kes registreeruvad sellele veebinarile, saavad sertifikaadi soodustuse oma e-posti aadressile 1-2 päeva pärast ülekannet.
Allikas: habr.com
