🥇VxLAN tehas. Osa 1

Tere, Habr. Praegu olen ma OTUSis kursuse "Võrgutehnik" juhataja.
Uue kursuse alguse eelõhtul "Võrgutehnik", 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.20

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

Kontrollime, 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               1

BGP 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 evpn

Seejä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 LEAF

Leafi 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 SPINE

Spines 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 0

Kuidas 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-based

Seame ü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 loopback0

Leaf-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 sekundaarne

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

Kuidas 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-d

Nüü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 auto

Teeme 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 ms

Ja 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 i

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

Let'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 mac

Seega 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 i

Kä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-arp

Seejä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 256

Selle 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 which is taking place today at 20:00. During the webinar, we will discuss how to build an efficient and scalable data processing system for a small company or startup with minimal costs. As a part of the practice, we will get to know Google Cloud data processing tools. See you there!, 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