Sveiki, habr. Pašlaik esmu OTUS tīkla inženieru kursa kursu vadītājs.
Gaidot jaunas uzņemšanas sākumu kursā , Esmu sagatavojis rakstu sēriju par VxLAN EVPN tehnoloģiju.
Materiālu par VxLAN EVPN darbību ir milzīgs daudzums, tāpēc vēlos apkopot dažādus uzdevumus un praksi problēmu risināšanai modernā datu centrā.
Sērijas pirmajā daļā par VxLAN EVPN tehnoloģiju es vēlos apskatīt veidu, kā organizēt L2 savienojumu starp saimniekdatoriem uz tīkla auduma.
Visi piemēri tiks veikti ar Cisco Nexus 9000v, kas samontēts Spine-Leaf topoloģijā. Šajā rakstā mēs neapspriedīsim apakšklāja tīkla izveidi.
- Apakšklājuma tīkls
- BGP peering adrešu saimei l2vpn evpn
- Notiek NVE iestatīšana
- Apspiest-arp
Apakšklājuma tīkls
Izmantotā topoloģija ir šāda:
Iestatīsim adresāciju visās ierīcēs:
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.20Pārbaudīsim, vai starp visām ierīcēm ir IP savienojums:
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, intraPārbaudīsim, vai ir izveidots VPC domēns un abi slēdži ir izturējuši konsekvences pārbaudi un abu mezglu iestatījumi ir identiski:
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
Visbeidzot, varat pāriet uz pārklājuma tīkla iestatīšanu.
Kā daļa no raksta ir jāorganizē tīkls starp saimniekiem, kā parādīts zemāk esošajā diagrammā:
Lai konfigurētu pārklājuma tīklu, ir jāiespējo BGP slēdžos Spine un Leaf ar atbalstu l2vpn evpn saimei:
feature bgp
nv overlay evpnPēc tam jums ir jākonfigurē BGP peering starp Leaf un Spine. Lai vienkāršotu iestatīšanu un optimizētu maršrutēšanas informācijas izplatīšanu, mēs konfigurējam Spine kā Route-Reflector serveri. Mēs ierakstīsim visas lapas konfigurācijā, izmantojot veidnes, lai optimizētu iestatījumu.
Tātad Spine iestatījumi izskatās šādi:
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 LEAFSlēdža Leaf iestatījums izskatās līdzīgi:
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 SPINEProgrammā Spine pārbaudīsim peering ar visiem Leaf slēdžiem:
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 0Kā redzat, ar BGP nebija nekādu problēmu. Pāriesim pie VxLAN iestatīšanas. Turpmāka konfigurēšana tiks veikta tikai slēdžu lapas pusē. Spine darbojas tikai kā tīkla kodols un ir iesaistīts tikai trafika pārsūtīšanā. Visi iekapsulēšanas un ceļa noteikšanas darbi notiek tikai uz Leaf slēdžiem.
Notiek NVE iestatīšana
NVE - tīkla virtuālais interfeiss
Pirms iestatīšanas sāksim dažus terminus:
VTEP — Vitual Tunnel End Point, ierīce, kurā sākas vai beidzas VxLAN tunelis. VTEP ne vienmēr ir jebkura tīkla ierīce. Serveris, kas atbalsta VxLAN tehnoloģiju, var darboties arī kā serveris. Mūsu topoloģijā visi Leaf slēdži ir VTEP.
VNI — virtuālā tīkla indekss — tīkla identifikators VxLAN. Var vilkt analoģiju ar VLAN. Tomēr ir dažas atšķirības. Izmantojot audumu, VLAN kļūst unikāli tikai vienā Leaf slēdžā un netiek pārraidīti tīklā. Bet katram VLAN var būt piesaistīts VNI numurs, kas jau tiek pārsūtīts tīklā. Kā tas izskatās un kā to var izmantot, tiks apspriests tālāk.
Iespējosim VxLAN tehnoloģijas funkciju un iespēju saistīt VLAN numurus ar VNI numuru:
feature nv overlay
feature vn-segment-vlan-basedKonfigurēsim NVE interfeisu, kas atbild par VxLAN darbību. Šī saskarne ir atbildīga par kadru iekapsulēšanu VxLAN galvenēs. Varat izdarīt analoģiju ar tuneļa saskarni GRE:
interface nve1
no shutdown
host-reachability protocol bgp ! используем BGP для передачи маршрутной информации
source-interface loopback0 ! интерфейс с которого отправляем пакеты loopback0Uz Leaf-21 slēdža viss tiek izveidots bez problēmām. Tomēr, ja mēs pārbaudām komandas izvadi show nve peers, tad tas būs tukšs. Šeit jums jāatgriežas pie VPC konfigurācijas. Mēs redzam, ka Leaf-11 un Leaf-12 darbojas pa pāriem un tos vieno VPC domēns. Tas mums rada šādu situāciju:
Host-2 nosūta vienu kadru uz Leaf-21, lai tas pārraidītu to tīklā uz Host-1. Tomēr Leaf-21 redz, ka resursdatora-1 MAC adrese ir pieejama, izmantojot divus VTEP vienlaikus. Kas šajā gadījumā būtu jādara Leaf-21? Galu galā tas nozīmē, ka tīklā varētu parādīties cilpa.
Lai atrisinātu šo situāciju, mums ir nepieciešams, lai Leaf-11 un Leaf-12 arī darbotos kā viena ierīce rūpnīcā. Risinājums ir pavisam vienkāršs. Loopback saskarnē, no kuras mēs veidojam tuneli, pievienojiet sekundāro adresi. Sekundārajai adresei ir jābūt vienādai abos VTEP.
interface loopback0
ip add 10.255.1.10/32 secondaryTādējādi no citu VTEP viedokļa mēs iegūstam šādu topoloģiju:
Tas ir, tagad tunelis tiks būvēts starp Leaf-21 IP adresi un virtuālo IP starp divām Leaf-11 un Leaf-12. Tagad nebūs problēmu iemācīties MAC adresi no divām ierīcēm, un satiksme var pārvietoties no viena VTEP uz citu. Kurš no diviem VTEP apstrādās trafiku, tiek izlemts, izmantojot Spine maršrutēšanas tabulu:
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, intraKā redzat iepriekš, adrese 10.255.1.10 ir pieejama uzreiz, izmantojot divus Next-hops.
Šajā posmā mēs esam tikuši galā ar pamata savienojamību. Pāriesim pie NVE interfeisa iestatīšanas:
Nekavējoties iespējosim Vlan 10 un saistīsim to ar VNI 10000 katrā saimniekiem paredzētajā lapā. Izveidosim L2 tuneli starp saimniekiem
vlan 10 ! Включаем VLAN на всех VTEP подключенных к необходимым хостам
vn-segment 10000 ! Ассоциируем VLAN с номер VNI
interface nve1
member vni 10000 ! Добавляем VNI 10000 для работы через интерфейс NVE. для инкапсуляции в VxLAN
ingress-replication protocol bgp ! указываем, что для распространения информации о хосте используем BGPTagad pārbaudīsim nve vienaudžus un BGP EVPN tabulu:
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 iAugšpusē redzami tikai EVPN maršruta tipa 3 maršruti. Šis maršruta veids runā par peer(Leaf), bet kur ir mūsu saimnieki?
Lieta ir tāda, ka informācija par MAC saimniekiem tiek pārsūtīta, izmantojot EVPN maršruta tipu 2
Lai redzētu mūsu saimniekus, jums ir jākonfigurē EVPN maršruta veids 2:
evpn
vni 10000 l2
route-target import auto ! в рамках данной статьи используем автоматический номер для route-target
route-target export autoSūtīsim ping no Host-2 uz 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 msUn zemāk redzams, ka BGP tabulā parādījās maršruta tips 2 ar resursdatora MAC adresi - 5001.0007.0007 un 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 iTālāk varat skatīt detalizētu informāciju par atjauninājumu, kurā saņēmāt informāciju par MAC resursdatoru. Tālāk ir norādīta ne visa komandas izvade.
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
<........>Apskatīsim, kā izskatās rāmji, kad tie tiek izvadīti cauri rūpnīcai:
Apspiest-ARP
Lieliski, mums tagad ir L2 komunikācija starp saimniekiem, un mēs varētu tur pabeigt. Tomēr ne viss ir tik vienkārši. Kamēr mums būs maz saimnieku, problēmu nebūs. Bet iedomāsimies situāciju, kad mums ir simtiem un tūkstošiem saimnieku. Ar kādu problēmu mēs varam saskarties?
Šī problēma ir BUM (Broadcast, Unknown Unicast, Multicast) trafika. Šajā rakstā mēs apsvērsim iespēju risināt apraides trafiku.
Galvenais apraides ģenerators Ethernet tīklos ir paši saimnieki, izmantojot ARP protokolu.
Nexus ievieš šādu mehānismu, lai cīnītos pret ARP pieprasījumiem - suppress-arp.
Šī funkcija darbojas šādi:
- Host-1 nosūta APR pieprasījumu uz sava tīkla apraides adresi.
- Pieprasījums sasniedz Leaf slēdzi un tā vietā, lai nosūtītu šo pieprasījumu tālāk uz audumu uz Host-2, Leaf atbild pats un norāda nepieciešamo IP un MAC.
Tādējādi Broadcast pieprasījums uz rūpnīcu nenonāca. Bet kā tas var darboties, ja Leaf zina tikai MAC adresi?
Viss ir pavisam vienkārši, EVPN maršruta tips 2 papildus MAC adresei var pārsūtīt MAC/IP kombināciju. Lai to izdarītu, lapā VLAN ir jākonfigurē IP adrese. Rodas jautājums, kādu IP man vajadzētu iestatīt? Nexus ir iespējams izveidot izplatītu (vienu un to pašu) adresi visos slēdžos:
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 macTādējādi no saimnieku viedokļa tīkls izskatīsies šādi:
Pārbaudīsim 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
<......>No komandas izvades varat redzēt, ka EVPN maršruta 2. veidā papildus MAC mēs tagad redzam arī resursdatora IP adresi.
Atgriezīsimies pie supress-arp iestatīšanas. Šis iestatījums ir iespējots katram VNI atsevišķi:
interface nve1
member vni 10000
suppress-arpTad rodas zināma sarežģītība:
- Lai šī funkcija darbotos, ir nepieciešama vieta TCAM atmiņā. Tālāk ir sniegts apspiešanas arp iestatījumu piemērs.
hardware access-list tcam region arp-ether 256Šim iestatījumam būs nepieciešams dubultplatums. Tas ir, ja iestatāt 256, TCAM ir jāatbrīvo 512. TCAM iestatīšana neietilpst šī raksta darbības jomā, jo TCAM iestatīšana ir atkarīga tikai no jums piešķirtā uzdevuma un dažādos tīklos var atšķirties.
- Suppress-arp ieviešana jāveic visos Leaf slēdžos. Tomēr sarežģītība var rasties, konfigurējot lapu pārus, kas atrodas VPC domēnā. Ja TCAM tiek mainīts, konsekvence starp pāriem tiks pārtraukta un viens mezgls var tikt pārtraukts. Turklāt, lai lietotu TCAM izmaiņu iestatījumu, var būt nepieciešama ierīces atsāknēšana.
Rezultātā jums rūpīgi jāapsver, vai jūsu situācijā ir vērts ieviest šo iestatījumu strādājošā rūpnīcā.
Ar to tiek noslēgta sērijas pirmā daļa. Nākamajā daļā mēs apskatīsim maršrutēšanu caur VxLAN tīklu, sadalot tīklus dažādos VRF.
Un tagad es aicinu visus , kuras ietvaros sīkāk pastāstīšu par kursu. Pirmie 20 dalībnieki, kas reģistrējas šim vebināram, 1-2 dienu laikā pēc pārraides saņems atlaižu sertifikātu pa e-pastu.
Avots: www.habr.com