Tere habr. Olen praegu OTUSes "Võrguinsener" kursuse juht.
Kursusele uue registreerimise ootuses , olen koostanud artiklite sarja VxLAN EVPN-tehnoloogia kohta.
VxLAN EVPN-i töö kohta on tohutult palju materjale, seega tahan koguda erinevaid ülesandeid ja tavasid probleemide lahendamiseks kaasaegses andmekeskuses.
VxLAN EVPN-i tehnoloogiatsükli esimeses osas tahan kaaluda võimalust korraldada L2-ühenduvus hostide vahel võrgutehase peal.
Kõik näited tehakse Cisco Nexus 9000v-ga, mis on kokku pandud Spine-Leaf topoloogias. Selles artiklis me aluskatte võrgu seadistamisel ei peatu.
- aluskatte võrk
- BGP-ühendus aadress-perekonna l2vpn evpn jaoks
- NVE seadistamine
- Supress-arp
aluskatte võrk
Kasutatav topoloogia on järgmine:
Määrame aadressi kõikides seadmetes:
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õigi seadmete vahel on IP-ühendus:
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, intraKontrollime, kas VPC domeen on loodud ja mõlemad lülitid on läbinud järjepidevuse kontrolli ning mõlema sõlme sätted on identsed:
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
Lõpuks saame liikuda ülekattevõrgu konfigureerimise juurde.
Artikli osana on vaja korraldada hostide vaheline võrk, nagu on näidatud alloleval diagrammil:
Overlay võrgu konfigureerimiseks peate lülitites Spine ja Leaf lubama BGP, mis toetab perekonda l2vpn evpn:
feature bgp
nv overlay evpnJärgmisena peate konfigureerima BGP-ühenduse Leaf ja Spine vahel. Konfigureerimise lihtsustamiseks ja marsruutimisteabe jaotamise optimeerimiseks konfigureerime Spine'i Route-Reflektori serveriks. Seadistuse optimeerimiseks kirjutame kõik Leafi konfiguratsioonis mallide kaudu.
Nii et Spine'i seaded näevad välja järgmised:
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 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 SPINESpine'is kontrollige suhtlust kõigi Leaf 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 0Nagu näha, siis BGP-ga probleeme polnud. Liigume edasi VxLAN-i seadistamise juurde. Edasine seadistamine toimub ainult Leaf lülitite küljel. Spine toimib ainult võrgu tuumana ja osaleb ainult liikluse edastamises. Kogu kapseldamise ja tee määratlemisega seotud töö toimub ainult Leaf lülitites.
NVE seadistamine
NVE - võrgu virtuaalne liides
Enne seadistamise alustamist tutvustame mõnda terminoloogiat:
VTEP – Vitual Tunnel End Point, seade, millel VxLAN tunnel algab või lõpeb. VTEP ei pruugi olla mis tahes võrguseade. Samuti võib toimida VxLAN-tehnoloogiat toetav server. Meie topoloogias on kõik Leafi lülitid VTEP-id.
VNI – Virtual Network Index – võrgu identifikaator VxLAN-is. Saate tuua analoogia VLAN-iga. Siiski on mõningaid erinevusi. Kanga kasutamisel muutuvad VLAN-id ainulaadseks ainult ühe Leaf-lüliti piires ja neid ei edastata üle võrgu. Kuid iga VLAN-i saab seostada VNI-numbriga, mis on juba võrgu kaudu edastatud. Kuidas see välja näeb ja kuidas seda kasutada saab, arutatakse allpool.
Lubage VxLAN-tehnoloogia toimimiseks funktsioon ja VLAN-i numbrite VNI-numbriga seostamise võimalus.
feature nv overlay
feature vn-segment-vlan-basedSeadistame NVE liidese, mis vastutab VxLANi töö eest. See liides vastutab kaadrite kapseldamise eest VxLAN-i päistesse. Saate tuua analoogia GRE tunneli liidesega:
interface nve1
no shutdown
host-reachability protocol bgp ! используем BGP для передачи маршрутной информации
source-interface loopback0 ! интерфейс с которого отправляем пакеты loopback0Leaf-21 lülitil luuakse kõik probleemideta. Kui aga kontrollime käsu väljundit show nve peers, siis jääb see tühjaks. Siin peate naasma VPC seadistusse. Näeme, et Leaf-11 ja Leaf-12 on seotud ja ühendatud VPC domeeniga. Selle tulemuseks on järgmine olukord:
Host-2 saadab ühe kaadri Leaf-21-le, et see saata võrgu kaudu Host-1-le. Kuid Leaf-21 näeb, et Host-1 MAC-aadress on saadaval kahe VTEP kaudu korraga. Mida peaks Leaf-21 sel juhul tegema? See tähendab ju, et võrku võib tekkida silmus.
Selle olukorra lahendamiseks vajame, et Leaf-11 ja Leaf-12 toimiksid tehases ühe seadmena. See lahendatakse üsna lihtsalt. Loopback-liidesele, millest tunnelit ehitame, lisage teisene aadress. Teisene aadress peab mõlemas VTEP-s olema sama.
interface loopback0
ip add 10.255.1.10/32 secondarySeega saame teiste VTEP-de vaatepunktist järgmise topoloogia:
See tähendab, et nüüd ehitatakse tunnel Leaf-21 IP-aadressi ja kahe Leaf-11 ja Leaf-12 vahelise virtuaalse IP-aadressi vahele. Nüüd pole probleeme MAC-aadressi õppimisega kahest seadmest ja liiklust saab ühest VTEP-ist teise üle kanda. Milline kahest VTEP-st liiklust töötleb, 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 ülalt näha, on aadress 10.255.1.10 kohe saadaval kahe Next-hopi kaudu.
Selles etapis selgitasime välja põhiühenduvuse. Liigume edasi NVE liidese seadistamise juurde:
Lubame kohe Vlan 10 ja seostame selle hostide jaoks igal lehel VNI 10000-ga. Seadistage hostide vahel L2 tunnel
vlan 10 ! Включаем VLAN на всех VTEP подключенных к необходимым хостам
vn-segment 10000 ! Ассоциируем VLAN с номер VNI
interface nve1
member vni 10000 ! Добавляем VNI 10000 для работы через интерфейс NVE. для инкапсуляции в VxLAN
ingress-replication protocol bgp ! указываем, что для распространения информации о хосте используем BGPNüüd kontrollime BGP EVPN-i jaoks nve eakaaslaste ja 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 ! Видим что 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 iEespool näeme marsruute ainult EVPN-i marsruuditüüp 3. Seda tüüpi marsruudid räägivad kaaslastest (Leaf), kuid kus on meie hostid?
Ja asi on selles, et teavet MAC-i hostide kohta edastatakse EVPN-i marsruudi tüüp 2 kaudu
Meie hostide nägemiseks peate konfigureerima EVPN-i marsruudi tüüp 2:
evpn
vni 10000 l2
route-target import auto ! в рамках данной статьи используем автоматический номер для route-target
route-target export autoPingime host-2-lt host-1-le:
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 msJa allpool näeme, et marsruudi tüüp 2 ilmus BGP tabelisse 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 и 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 iJärgmisena näete üksikasjalikku teavet värskenduse kohta, milles saite teavet MAC-i hosti kohta. Allpool pole kogu käsu väljundit
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
<........>Vaatame, kuidas raamid tehasest läbides välja näevad:
Supress-ARP
Suurepärane, meil on hostide vahel L2-ühendus ja sellega võib asi lõppeda. Siiski pole kõik nii lihtne. Kuni meil on vähe võõrustajaid, pole probleeme. Kuid kujutame ette olukordi, kus meil on sadu ja tuhandeid võõrustajaid. Millise probleemiga saame silmitsi seista?
See probleem on BUM (Broadcast, Unknown Unicast, Multicast) liiklus. Selle artikli raames kaalume võimalust võidelda ringhäälinguliiklusega.
Etherneti võrkude peamine leviedastusgeneraator on ARP-protokolli kaudu hostid ise.
Nexus rakendab ARP-päringute käsitlemiseks järgmist mehhanismi – suppress-arp.
See funktsioon töötab järgmiselt:
- Host-1 saadab APR päringu oma võrgu leviedastusaadressile.
- Päring jõuab Leaf lülitini ja selle asemel, et see päring edasi tehasele Host-2 poole edastada, vastab Leaf ise ja näitab soovitud IP-d ja MAC-i.
Seega Broadcasti palve tehasesse ei läinud. Aga kuidas see toimib, kui Leaf teab ainult MAC-aadressi?
Kõik on üsna lihtne, EVPN-i marsruudi tüüp 2 saab lisaks MAC-aadressile edastada ka MAC / IP-paketti. Selleks tuleb Leaf konfigureerida VLAN-is IP-aadressiga. Tekib küsimus, millist IP-d küsida? Nexuses on võimalik luua hajutatud (sama) aadress kõikidele lülititele:
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 macSeega näeb võrk hostide seisukohast välja selline:
Kontrollige 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
<......>Käsu väljundist on näha, et EVPN route-type 2-s näeme nüüd lisaks MAC-ile ka hosti IP-aadressi.
Pöördume tagasi supress-arp seadistusse. See säte on lubatud iga VNI jaoks eraldi:
interface nve1
member vni 10000
suppress-arpSiis on raskusi:
- See funktsioon nõuab TCAM-mälus ruumi. Toon näite supress-arp seadistamisest:
hardware access-list tcam region arp-ether 256See seadistus nõuab topeltlaiust. See tähendab, et kui määrate 256, tuleb TCAM-is vabastada 512. TCAM-i seadistamine ei kuulu selle artikli reguleerimisalasse, kuna TCAM-i seadistamine sõltub ainult teile määratud ülesandest ja võib võrkudeti erineda.
- Supress-arp rakendamine peab toimuma kõigil Leaf lülititel. VPC-domeenis asuvate Leafi paaride konfigureerimisel võib aga tekkida keerukus. TCAM-i muutmisel katkeb paaride vaheline järjepidevus ja üks sõlm võidakse teenistusest välja lülitada. Lisaks võib TCAM-i muutmise sätte rakendamiseks olla vajalik seadme taaskäivitamine.
Seetõttu peaksite hoolikalt kaaluma, kas seda seadet tasub teie olukorras toimivas tehases rakendada.
See lõpetab tsükli esimese osa. Järgmises osas käsitleme marsruutimist läbi VxLAN-i tehase võrgu eraldamisega erinevate VRF-ide vahel.
Ja nüüd kutsun kõiki üles , milles räägin üksikasjalikult kursusest. Esimesed 20 osalejat, kes registreeruvad sellele veebiseminarile, saavad 1-2 päeva jooksul pärast ülekande toimumist meili teel allahindlustunnistuse.
Allikas: www.habr.com