🥇VxLAN fabrika. 1. zatia

Kaixo, habr. Gaur egun OTUSeko Sare Ingeniarien ikastaroaren arduraduna naiz.
Ikastarorako matrikula berri baten hasieraren esperoan "Sare ingeniaria", VxLAN EVPN teknologiari buruzko artikulu sorta bat prestatu dut.

VxLAN EVPN-k nola funtzionatzen duen jakiteko material kopuru handia dago, beraz, datu-zentro moderno batean arazoak konpontzeko hainbat zeregin eta praktika bildu nahi ditut.

VxLAN EVPN teknologiari buruzko seriearen lehen zatian, sare-ehun baten gainean ostalarien arteko L2 konektibitatea antolatzeko modu bat aztertu nahi dut.

Adibide guztiak Cisco Nexus 9000v batean egingo dira, Spine-Leaf topologian muntatuta. Artikulu honetan ez dugu azpimarratzeko sare bat konfiguratzen.

Azpiko sarea
BGP peering helbide-familia l2vpn evpn
NVE konfiguratzea
Zapaldu-arp

Azpiko sarea

Erabilitako topologia hau da:

Ezar dezagun helbidea gailu guztietan:

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.20

Egiaztatu dezagun gailu guztien artean IP konexioa dagoela:

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, intra

Egiaztatu dezagun VPC domeinua sortu dela eta bi etengailuek koherentzia egiaztatzea gainditu dutela eta bi nodoetako ezarpenak berdinak direla:

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               1

BGP parekatzea

Azkenik, Overlay sarea konfiguratzera pasa zaitezke.

Artikuluaren zati gisa, beharrezkoa da ostalarien arteko sarea antolatzea, beheko diagraman erakusten den moduan:

Overlay sare bat konfiguratzeko, BGP gaitu behar duzu Spine eta Leaf etengailuetan l2vpn evpn familiarako laguntzarekin:

feature bgp
nv overlay evpn

Ondoren, BGP peering-a Leaf eta Spine artean konfiguratu behar duzu. Konfigurazioa errazteko eta bideratze-informazioaren banaketa optimizatzeko, Spine Route-Reflector zerbitzari gisa konfiguratzen dugu. Leaf guztiak konfigurazioan idatziko ditugu txantiloiak erabiliz konfigurazioa optimizatzeko.

Beraz, Spine-n ezarpenak honelakoak dira:

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 etengailuaren konfigurazioa antzekoa da:

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-n, egiazta dezagun Leaf etengailu guztiekin parekatzea:

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 0

Ikus dezakezunez, BGPrekin ez zen arazorik izan. Goazen VxLAN konfiguratzera. Konfigurazio gehiago etengailuen Leaf aldean bakarrik egingo da. Bizkarrezurra sarearen muin gisa soilik jokatzen du eta trafikoa transmititzean bakarrik parte hartzen du. Kapsulatze- eta bide-zehaztapen-lan guztiak Leaf etengailuetan bakarrik gertatzen dira.

NVE konfiguratzea

NVE - sareko interfaze birtuala

Konfigurazioari ekin aurretik, sartu ditzagun terminologia batzuk:

VTEP - Vitual Tunnel End Point, VxLAN tunela hasten edo amaitzen den gailua. VTEP ez da zertan sareko edozein gailu. VxLAN teknologia onartzen duen zerbitzari batek zerbitzari gisa ere jardun dezake. Gure topologian, Leaf etengailu guztiak VTEP dira.

VNI - Virtual Network Index - sare-identifikatzailea VxLAN barruan. VLANarekin analogia bat egin daiteke. Hala ere, badira desberdintasun batzuk. Ehun bat erabiltzean, VLANak bakarra bihurtzen dira Leaf switch baten barruan eta ez dira sarean zehar transmititzen. Baina VLAN bakoitzak VNI zenbaki bat izan dezake lotuta, sarean dagoeneko transmititzen dena. Nolakoa den eta nola erabil daitekeen gehiago eztabaidatuko da.

Gaitu dezagun VxLAN teknologiak funtziona dezan eta VLAN zenbakiak VNI zenbaki batekin lotzeko gaitasuna:

feature nv overlay
feature vn-segment-vlan-based

Konfigura dezagun NVE interfazea, VxLANen funtzionamenduaz arduratzen dena. Interfaze hau VxLAN goiburuetan fotogramak kapsulatzeaz arduratzen da. GRErako Tunnel interfazearekin analogia bat marraz dezakezu:

interface nve1
  no shutdown
  host-reachability protocol bgp ! используем BGP для передачи маршрутной информации
  source-interface loopback0    ! интерфейс  с которого отправляем пакеты loopback0

Leaf-21 etengailuan dena arazorik gabe sortzen da. Hala ere, komandoaren irteera egiaztatzen badugu show nve peers, orduan hutsik egongo da. Hemen VPC konfiguraziora itzuli behar duzu. Leaf-11 eta Leaf-12 binaka funtzionatzen dutela eta VPC domeinu batek elkartzen dituela ikusten dugu. Honek egoera hau ematen digu:

Host-2-k fotograma bat bidaltzen du Leaf-21-era, beraz, sarearen bidez igortzen du Host-1-era. Hala ere, Leaf-21-ek ikusten du Host-1-ren MAC helbidea bi VTEPren bidez eskura daitekeela aldi berean. Zer egin beharko luke Leaf-21ek kasu honetan? Azken finean, horrek esan nahi du sarean begizta bat ager daitekeela.

Egoera hau konpontzeko, Leaf-11 eta Leaf-12 behar ditugu fabrikan gailu gisa ere jarduteko. Irtenbidea nahiko erraza da. Tunela eraikitzen dugun Loopback interfazean, gehitu bigarren mailako helbide bat. Bigarren mailako helbideak berdina izan behar du bi VTEPetan.

interface loopback0
 ip add 10.255.1.10/32 secondary

Horrela, beste VTEP batzuen ikuspuntutik, honako topologia hau lortzen dugu:

Hau da, orain tunela Leaf-21-ren IP helbidearen eta bi Leaf-11 eta Leaf-12ren arteko IP birtualaren artean eraikiko da. Orain ez da arazorik izango bi gailutatik MAC helbidea ikasteko eta trafikoa VTEP batetik bestera joan daiteke. Bi VTEPetatik zeinek prozesatuko duen trafikoa Spine-ko bideratze-taula erabiliz erabakitzen da:

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, intra

Goian ikus dezakezun bezala, 10.255.1.10 helbidea berehala eskuragarri dago bi Next-hop bidez.

Etapa honetan, oinarrizko konektibitateaz aritu gara. Goazen NVE interfazea konfiguratzera:
Gaitu dezagun berehala Vlan 10 eta lotu dezagun VNI 10000-rekin ostalarientzako Hosto bakoitzean. Konfigura dezagun L2 tunel bat ostalarien artean

vlan 10                 ! Включаем VLAN на всех VTEP подключенных к необходимым хостам
  vn-segment 10000      ! Ассоциируем VLAN с номер VNI 

interface nve1
  member vni 10000      ! Добавляем VNI 10000 для работы через интерфейс NVE. для инкапсуляции в VxLAN
    ingress-replication protocol bgp    ! указываем, что для распространения информации о хосте используем BGP

Orain ikus ditzagun nve peers eta BGP EVPNren taula:

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 i

Goian EVPN ibilbide motako 3. ibilbideak bakarrik ikusten ditugu. Ibilbide mota honek parekoari buruz hitz egiten du (Hostoa), baina non daude gure ostalariak?
Gauza da MAC ostalariei buruzko informazioa EVPN bide-mota 2 bidez transmititzen dela

Gure ostalariak ikusteko, EVPN ibilbide mota 2 konfiguratu behar duzu:

evpn
  vni 10000 l2
    route-target import auto   ! в рамках данной статьи используем автоматический номер для route-target
    route-target export auto

Egin dezagun ping-a Host-2tik Host-1era:

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 ms

Eta azpian ikus dezakegu BGP taulan ostalariaren MAC helbidea duen ibilbide mota 2 agertu zela - 5001.0007.0007 eta 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 i

Ondoren, eguneraketari buruzko informazio zehatza ikus dezakezu, eta bertan MAC Host-ari buruzko informazioa jaso duzu. Jarraian ez dago komandoen irteera guztia.

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
<........>

Ikus dezagun nolakoak diren markoak fabrikatik pasatzen direnean:

Ezabatu-ARP

Bikaina, orain L2 komunikazioa dugu ostalarien artean eta hor amaitu genezake. Hala ere, dena ez da hain sinplea. Ostalari gutxi ditugun bitartean ez da arazorik izango. Baina imajina dezagun ehunka eta milaka ostalari ditugun egoera. Zein arazo izan genezake?

Arazo hau BUM (Broadcast, Unknown Unicast, Multicast) trafikoa da. Artikulu honetan, igorpen trafikoari aurre egiteko aukera aztertuko dugu.
Ethernet sareetako Broadcast sorgailu nagusia ostalariak beraiek dira ARP protokoloaren bidez.

Nexus-ek honako mekanismo hau inplementatzen du ARP eskaerei aurre egiteko - suppress-arp.
Ezaugarri honek honela funtzionatzen du:

Host-1ek APR eskaera bat bidaltzen du bere sareko Broadcast helbidera.
Eskaera Leaf-en etengailura iristen da eta eskaera hori ehunera gehiago pasatu ordez Host-2 aldera, Leaf-ek berak erantzuten du eta beharrezko IP eta MAC adierazten ditu.

Hala, Broadcast eskaera ez zen fabrikara joan. Baina nola funtziona dezake honek Leaf-ek MAC helbidea bakarrik ezagutzen badu?

Dena nahiko erraza da, EVPN ibilbide mota 2, MAC helbideaz gain, MAC/IP konbinazio bat transmititu dezake. Horretarako, IP helbide bat konfiguratu behar duzu Leaf-eko VLANean. Galdera sortzen da, zein IP ezarri behar dut? Nexus-en etengailu guztietan helbide banatua (berdina) sortzea posible da:

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 mac

Horrela, ostalarien ikuspuntutik, sarea honela izango da:

Ikus dezagun 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

<......>

Komandoaren irteeratik ikus dezakezu EVPN ibilbide mota 2-n, MACaz gain, ostalariaren IP helbidea ere ikusten dugula.

Itzuli gaitezen suppress-arp ezarpenera. Ezarpen hau VNI bakoitzean gaituta dago bereizita:

interface nve1
  member vni 10000   
    suppress-arp

Orduan konplexutasun bat sortzen da:

Ezaugarri honek funtziona dezan, TCAM memorian tokia behar da. Hona hemen suppress-arp-en ezarpenen adibide bat:

hardware access-list tcam region arp-ether 256

Ezarpen honek zabalera bikoitza eskatuko du. Hau da, 256 ezartzen baduzu, TCAM-en 512 askatu behar duzu. TCAM konfiguratzea artikulu honen esparrutik kanpo dago, TCAM konfiguratzea esleitutako zereginaren araberakoa baita eta sare batetik bestera desberdina izan daitekeelako.

Suppress-arp inplementatzea Leaf etengailu guztietan egin behar da. Hala ere, konplexutasuna sor daiteke VPC domeinu batean bizi diren Leaf bikoteetan konfiguratzean. TCAM aldatzen bada, bikoteen arteko koherentzia hautsi egingo da eta nodo bat funtzionamendutik kanpo utziko da. Gainera, baliteke gailua berrabiarazi behar izatea TCAM aldaketa ezarpena aplikatzeko.

Ondorioz, arretaz aztertu behar duzu zure egoeran ezarpen hau martxan dagoen fabrika batean ezartzea merezi duen ala ez.

Honekin amaitzen da seriearen lehen zatia. Hurrengo zatian VxLAN ehun baten bidez bideratzea aztertuko dugu sareak VRF ezberdinetan banatuta.

Eta orain denak gonbidatzen ditut doako webinarra, horren barruan ikastaroaren berri zehatz-mehatz emango dizut. Webinar honetan izena ematen duten lehen 20 parte-hartzaileek Deskontu Ziurtagiria jasoko dute posta elektroniko bidez, igorpenaren ondorengo 1-2 egunetan.

Iturria: www.habr.com

VxLAN fabrika. 1. zatia

Azpiko sarea

BGP parekatzea

NVE konfiguratzea

Ezabatu-ARP

Gehitu iruzkin berria Idatzi