ProHoster > Blog > Administracija > VxLAN tovarna. Del 1

VxLAN tovarna. Del 1

Pozdravljeni, Habr. Trenutno sem vodja tečaja "Omrežni inženir" na OTUS-u.
Uoči početka novog upisa na kurs "Omrežni inženir", pripravil sem cikel člankov o tehnologiji VxLAN EVPN.

Obstaja ogromno podatkov o delu z VxLAN EVPN, zato želim zbrati različne naloge in prakse reševanja nalog v sodobnem podatkovnem središču.

VxLAN tovarna. Del 1

V prvem delu cikla o tehnologiji VxLAN EVPN želim raziskati način organizacije L2 povezljivosti med gostitelji preko omrežne fabrike.

Vse primere bomo izvajali na Cisco Nexus 9000v, zgrajenih v topologijo Spine-Leaf. Na konfiguracijo Underlay omrežja se v okviru tega članka ne bomo osredotočili.

  1. Underlay omrežje
  2. BGP povezovanje za address-family l2vpn evpn
  3. Konfiguracija NVE
  4. Supress-arp

Underlay omrežje

Uporabljena topologija izgleda takole:

VxLAN tovarna. Del 1

Določimo naslove na vseh napravah:

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

Preverimo, ali obstaja IP povezljivost med vsemi napravami:

Leaf21# sh ip route

10.255.1.11/32, ubest/mbest: 2/0                      ! Leaf-11 je dostopen preko dveh 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 je dostopen preko dveh 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

Preverimo, ali je bil VPC domen ustvarjen in sta oba stikala prestala preverjanje skladnosti ter se nastavitve na obeh nodah ujemajo:

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 povezovanje

Nazadnje se lahko premaknemo k konfiguraciji Overlay omrežja.

V okviru tega članka je potrebno organizirati omrežje med gostitelji, kot je prikazano na spodnjem diagramu:

VxLAN tovarna. Del 1

Za nastavitev Overlay omrežja je potrebno na Spine in Leaf stikalah vklopiti BGP s podporo za družino l2vpn evpn:

feature bgp
nv overlay evpn

Nato je potrebno nastaviti BGP povezovanje med Leaf in Spine. Za poenostavitev nastavitve ter optimizacijo širjenja informacij o poteh nastavimo Spine kot Route-Reflector strežnik. Vse Leaf bomo v konfiguraciji zapisali preko predlog, da optimiziramo nastavitev.

Tako nastavitve na Spine izgledajo tako:

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

Nastavitev na Leaf stikali izgleda podobno:

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

Na Spine bomo preverili povezavo z vsemi Leaf stikali:

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

Kot vidimo, z BGP ni prišlo do nobenih težav. Preidimo na nastavitve VxLAN. Nadaljnje nastavitve bodo potekale samo na strani Leaf stikal. Spine deluje le kot jedro omrežja in se ukvarja le s prenosom prometa. Vse delo glede enkapsulacije in določanja poti poteka izključno na Leaf stikalah.

Konfiguracija NVE

NVE — omrežni virtualni vmesnik

Pred začetkom nastavitve vnesimo nekaj terminologije:

VTEP — Vitual Tunnel End Point, naprava, na kateri se začne ali konča VxLAN tunel. VTEP ni nujno katera koli mrežna naprava. Lahko je tudi strežnik, ki podpira tehnologijo VxLAN. V naši topologiji so vsi Leaf stikali VTEP.

VNI — Virtual Network Index — identifikator omrežja v okviru VxLAN. Lahko naredimo analogijo z VLAN. Kljub temu obstajajo nekatere razlike. Pri uporabi fabrik so VLAN edinstveni le v okviru enega Leaf stikali in se ne prenašajo prek omrežja. Vsak VLAN pa se lahko poveže s številko VNI, ki se prenaša po omrežju. Kako to zgleda in kako bi se to lahko uporabilo, bo obravnavano naprej.

Vklopimo feature za delovanje tehnologije VxLAN in možnost povezovanja števil VLAN s številom VNI:

feature nv overlay
feature vn-segment-vlan-based

Nastavimo NVE vmesnik, ki je odgovoren za delovanje VxLAN. Ta vmesnik je tisti, ki skrbi za enkapsulacijo okvirov v VxLAN naslove. Lahko naredimo analogijo z Tunnel vmesnikom za delovanje GRE:

vmesnik nve1
  no shutdown
  protokol dosegljivosti gostiteljev bgp ! uporabljamo BGP za prenos podatkov o poteh
  izvorni-vmesnik loopback0    ! vmesnik, s katerega pošiljamo pakete loopback0

Na preklopniku Leaf-21 je vse enostavno. Vendar, če preverimo izhod ukaza show nve peers, bo ta prazen. Tukaj se moramo vrniti k nastavitvi VPC. Vidimo, da sta Leaf-11 in Leaf-12 v paru in povezana z VPC domeno. Tako dobimo naslednjo situacijo:

Host-2 pošilja en okvir v smeri Leaf-21, da ga ta pošlje preko omrežja v smeri Host-1. Vendar Leaf-21 vidi, da je MAC naslov Host-1 dostopen takoj preko dveh VTEP. Kako se v tem primeru naj ravna Leaf-21? To namreč pomeni, da bi se lahko pojavila zanka v omrežju.

Za rešitev te situacije moramo poskrbeti, da sta Leaf-11 in Leaf-12 v tovarni tudi enota. To se reši precej preprosto. Na vmesniku Loopback, s katerega gradimo tunel, dodamo sekundarni naslov. Sekundarni naslov mora biti enak na obeh VTEP.

vmesnik loopback0
 ip naslov 10.255.1.10/32 sekundarni

Tako gledano z vidika drugih VTEP, dobimo naslednjo topologijo:

VxLAN tovarna. Del 1

Torej, zdaj se bo tunel gradil med IP naslovom Leaf-21 in virtualnim IP med dvema Leaf-11 in Leaf-12. Zdaj ne bo več težav pri iskanju MAC naslova z obeh naprav in promet se lahko prenese iz enega VTEP na drugega. Kdo točno iz dveh VTEP bo obdelal promet, se odloči s pomočjo usmerjevalne tabele na Spine:

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

Kot je razvidno zgoraj, je naslov 10.255.1.10 dostopen takoj preko dveh Next-hop.

V tej fazi smo se lotili osnovne povezanosti. Preidimo k nastavitvi NVE vmesnika:
Takoj omogočimo Vlan 10 in ga povežemo z VNI 10000 na vsakem Leaf za gostitelje. Nastavimo L2 tunel med gostitelji.

vlan 10                 ! Vključujemo VLAN na vseh VTEP, povezanih z zahtevani gostiteljem
  vn-segment 10000      ! Povezujemo VLAN z VNI številko

interface nve1
  member vni 10000      ! Dodajamo VNI 10000 za delovanje preko NVE vmesnika, za enkapsulacijo v VxLAN
    ingress-replication protocol bgp    ! Določamo, da za širjenje informacij o gostitelju uporabljamo BGP

Sedaj bomo preverili nve peers in tablico za BGP EVPN:

Leaf21# sh nve peers
Interface Peer-IP          State LearnType Uptime   Router-Mac
--------- ---------------  ----- --------- -------- -----------------
nve1      10.255.1.10      Up    CP        00:00:41 n/a                 ! Vidimo, da je peer dostopen z sekundarne naslov

Leaf11# sh bgp l2vpn evpn

   Network            Next Hop            Metric     LocPrf     Weight Path
Route Distinguisher: 10.255.1.11:32777    (L2VNI 10000)        ! Od koga natančno je prišel ta l2VNI
*>l[3]:[0]:[32]:[10.255.1.10]\/88                                   ! EVPN route-type 3 - prikazuje našega soseda, ki tudi pozna 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

Zgornaj vidimo poti samo EVPN route-type 3. Ta tip poti govori o peer(Leaf), vendar kje so naši gostitelji?
Vse je v tem, da se informacije o MAC gostiteljih prenašajo preko EVPN route-type 2

Da bi videli naše gostitelje, je potrebno nastaviti EVPN route-type 2:

evpn
  vni 10000 l2
    route-target import auto   ! V okviru tega članka uporabljamo samodejno številko za route-target
    route-target export auto

Izvedimo ping z Host-2 na 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 ms

In spodaj lahko vidimo, da so v tabeli BGP pojavili route-type 2 z MAC naslovi gostiteljev — 5001.0007.0007 in 5001.0008.0007

Leaf11# sh bgp l2vpn evpn


   Mreža            Sljedeći Hops            Metrika     LocPrf     Težina Putanja
Razlikovnik Rute: 10.255.1.11:32777    (L2VNI 10000)
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]\/216                      !  evpn tip rute 2 i mac adresa hosta 1
                      10.255.1.10                       100      32768 i
*>i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]\/216                      ! evpn tip rute 2 i mac adresa hosta 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
Razlikovnik Rute: 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

Zatim možemo pogledati detaljne informacije o Update-u, u kojem smo dobili informacije o MAC Hostu. Ispod je prikazan ne celi izlaz komande

Leaf21# sh bgp l2vpn evpn 5001.0007.0007

Informacije o BGP rutama za VRF default, adresa porodica L2VPN EVPN
Razlikovnik Rute: 10.255.1.11:32777        !  poslao Update s MAC Host. Nije virtuelna adresa VPC, već adresa Leaf
BGP ulazna tabela za [2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]\/216,
 verzija 1507
Putanje: (2 dostupne, najbolja #2)
Zastavice: (0x000202) (high32 00000000) na xmit-list, nije u l2rib\/evpn, nije u HW

  Tip putanje: interno, putanja je validna, nije najbolja razlog: Adresa suseda, bez labelele sledeće tačke
  AS-Path: NEMA, putanja izvorna interna za AS
    10.255.1.10 (metriks 81) od 10.255.1.102 (10.255.1.102)    ! s kim tačno gradimo VxLAN tunel
      Izvor IGP, MED nije postavljen, lokalni preferencijal 100, težina 0
      Primljena labela 10000         ! Broj VNI koji je povezan s VLAN-om u kojem se nalazi Host
      Ekstergemalija: RT:65001:10000 SOO:10.255.1.10:0 ENCAP:8        ! Ovdje se vidi da je RT automatski formiran na osnovu brojeva AS i VNI
      Izvorište: 10.255.1.11 Lista klastera: 10.255.1.102
<........>

Pogledajmo kako izgledaju okviri kada se prenose kroz fabriku:

VxLAN tovarna. Del 1

Suppress-ARP

Odlično, L2 veza između hostova se uspostavila i na tome bismo mogli završiti. Međutim, nije sve tako jednostavno. Dok imamo malo hostova, problemi se neće pojaviti. Ali hajde da zamislimo situaciju u kojoj imamo stotine ili hiljade hostova. S kojim problemom se možemo suočiti?

Ovaj problem je BUM (Broadcast, Unknown Unicast, Multicast) saobraćaj. U okviru ovog članka razmotrićemo način borbe protiv broadcast saobraćaja.
Glavni generator Broadcast u Ethernet mrežama su sami hostovi putem ARP protokola.

Na nexus-u je implementiran sledeći mehanizam za borbu protiv ARP zahteva — suppress-arp.
Rad ove funkcionalnosti izgleda ovako:

  1. Host-1 šalje APR zahtev na Broadcast adresu svoje mreže.
  2. Zahtev dolazi do Leaf switcha i umesto da prosledi ovaj zahtev dalje u fabriku prema Host-2 — Leaf odgovara sam i ukazuje na potrebni IP i MAC.

Tako Broadcast zahtevek se ni poslal v tovarno. Kako pa lahko to deluje, če Leaf pozna le MAC naslov?

Vse je precej preprosto, EVPN route-type 2 poleg MAC naslova lahko prenaša tudi vezavo MAC/IP. Za to je potrebno na Leaf nastaviti IP naslov v VLAN-u. Pojavi se vprašanje, kateri IP naslov nastaviti? Na Nexus-u je možno ustvariti porazdeljen (enak) naslov na vseh st Switch-ih:

feature interface-vlan

fabric forwarding anycast-gateway-mac 0001.0001.0001    ! nastavite virtualni mac za ustvarjanje porazdeljenega prehoda med vsemi st Switch-i

interface Vlan10
  no shutdown
  ip address 192.168.10.254/24          ! na vseh Leaf postavimo enak IP
  fabric forwarding mode anycast-gateway    ! povejmo, da uporabljamo Virtual mac

Tako bo z vidika gostiteljev omrežje izgledalo takole:

VxLAN tovarna. Del 1

Preverimo BGP l2route evpn

Leaf11# sh bgp l2vpn evpn


   Mreža            Naslednji Hop            Metrična vrednost     LocPrf     Teža Pot
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

Iz izpisa ukaza je razvidno, da v EVPN route-type 2 poleg MAC zdaj vidimo tudi IP naslov gostitelja.

Vrnimo se k nastavitvi suppress-arp. Ta nastavitev se vključi za vsak VNI posebej:

interface nve1
  član vni 10000   
    suppress-arp

Nato nastane neka težava:

  • Za delovanje te funkcije potrebujemo prostor v TCAM spominu. Tukaj je primer nastavitve za suppress-arp:

hardware access-list tcam region arp-ether 256

Za to nastavitev bo potreben double-wide. To pomeni, da če nastavite 256, potem je potrebno v TCAM osvoboditi 512. Nastavitev TCAM presega okvir tega članka, saj je nastavitev TCAM odvisna le od naloge, ki jo imate pred seboj, in se lahko razlikuje od enega omrežja do drugega.

  • Implementacija suppress-arp mora potekati na vseh Leaf stikalih. Vendar pa lahko pride do težav pri nastavitvi parov Leaf, ki se nahajajo znotraj VPC domene. Pri spremembi TCAM se bo doslednost med pari prekinila, kar lahko povzroči, da ena vozlišča preneha delovati. Dodatno bo za uporabo nastavitve pri spremembi TCAM morda potrebna ponovni zagon naprave.

Zato je potrebno dobro premisliti, ali v vaši situaciji vpeljati to nastavitev na delavni tovarni.

S tem zaključujemo prvi del cikla. V naslednjem delu bomo obravnavali usmerjanje skozi VxLAN tovarno z razdelitvijo omrežij po različnih VRF.

Sedaj pa vabim vse na brezplačni spletni seminar, na katerem podrobno predstavim tečaj. Prvih 20 udeležencev, ki se bodo prijavili na ta webinar, bo prejelo certifikat za popust na e-pošto v roku 1-2 dni po prenosu.

Izvor: habr.com

Kupite zanesljivo gostovanje za spletne strani z zaščito pred DDoS, VPS VDS strežniki 🔥 Kupite zanesljivo gostovanje za spletne strani z zaščito pred DDoS, VPS VDS strežniki | ProHoster