ProHoster > Blogg > Administrasjon > VxLAN fabrikk. Del 1

VxLAN fabrikk. Del 1

Hei, Habr. For tiden er jeg kursleder for "NettverksingeniĂžr" ved OTUS.
I forkant av oppstarten av det nye kurset "NettverksingeniĂžr", har jeg forberedt en artikkelserie om VxLAN EVPN-teknologi.

Det finnes et stort antall materialer om VxLAN EVPN, sÄ jeg Þnsker Ä samle ulike oppgaver og lÞsninger pÄ oppgaver i et moderne datasenter.

VxLAN fabrikk. Del 1

I den fÞrste delen av artikkelserien om VxLAN EVPN-teknologi vil jeg se pÄ hvordan man organiserer L2-kobling mellom verter pÄ tvers av nettverksfabrikken.

Alle eksempler vil bli utfÞrt pÄ Cisco Nexus 9000v, sammenkoblet i en Spine-Leaf-topologi. Vi vil ikke stoppe opp for Ä konfigurere Underlay-nettet i denne artikkelen.

  1. Underlay-nett
  2. BGP-peering for address-family l2vpn evpn
  3. Konfigurasjon av NVE
  4. Supress-arp

Underlay-nett

Den brukte topologien ser slik ut:

VxLAN fabrikk. Del 1

Vi setter adresseringen pÄ alle enhetene:

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

Vi kontrollerer at det er IP-kobling mellom alle enheter:

Leaf21# sh ip route

10.255.1.11/32, ubest/mbest: 2/0                      ! Leaf-11 tilgjengelig via to 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 tilgjengelig via to 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

Vi kontrollerer at VPC-domenet er opprettet, og at begge svitsjene har bestÄtt konsistenskontrollen og at innstillingene pÄ begge nodene er identiske:

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

Endelig kan vi gÄ videre til konfigurasjonen av Overlay-nettet.

I denne artikkelen mÄ vi organisere et nettverk mellom vertene, som vist i diagrammet nedenfor:

VxLAN fabrikk. Del 1

For Ä konfigurere Overlay-nettverket, mÄ vi aktivere BGP med stÞtte for l2vpn evpn-familien pÄ Spine- og Leaf-switchene:

feature bgp
nv overlay evpn

Videre mÄ vi sette opp BGP-peering mellom Leaf og Spine. For Ä forenkle konfigurasjonen og optimalisere distribusjonen av ruteinformasjon, setter vi opp Spine som Route-Reflector-server. Alle Leaf-enheter vil bli registrert i konfigurasjonen via maler for Ä optimalisere oppsettet.

Slik ser konfigurasjonen pÄ Spine ut:

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

Konfigurasjonen pÄ Leaf-switchen ser dermed liknende ut:

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

PĂ„ Spine vil vi sjekke peering med alle Leaf-switchene:

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

Som vi ser, var det ingen problemer med BGP. La oss gÄ videre til konfigurasjonen av VxLAN. Videre konfigurasjon vil kun bli utfÞrt pÄ siden av Leaf-switchene. Spine fungerer kun som kjernen i nettverket og bare hÄndterer trafikkoverfÞring. All arbeid med inkapsling og ruteidentifikasjon finner sted utelukkende pÄ Leaf-switchene.

Konfigurasjon av NVE

NVE — nettverksvirtualgrensesnitt

FĂžr vi begynner konfigurasjonen, la oss innfĂžre litt terminologi:

VTEP — Virtuell Tunnel Endepunkt, en enhet der VxLAN-tunnelen begynner eller slutter. VTEP trenger ikke vĂŠre en nettverksenhet. Det kan ogsĂ„ vĂŠre en server som stĂžtter VxLAN-teknologi. I vĂ„r topologi fungerer alle Leaf-switcher som VTEP.

VNI — Virtuell Nettverksindeks — nettverksidentifikator i VxLAN. Dette kan sammenlignes med VLAN. Men det er noen forskjeller. NĂ„r man bruker fabrikk, blir VLAN unike kun innenfor en Leaf-switch og overfĂžres ikke over nettverket. Men hver VLAN kan assosieres med et VNI-nummer, som da overfĂžres over nettverket. Hvordan dette ser ut og hvordan det kan brukes, vil bli behandlet senere.

Vi vil aktivere funksjonaliteten for VxLAN-teknologi og muligheten til Ă„ assosiere VLAN-numre med VNI-nummeret:

funksjonalitet nv overlay
funksjonalitet vn-segment-vlan-basert

Vi skal konfigurere NVE-grensesnittet, som er ansvarlig for VxLAN-operasjonen. Dette grensesnittet hÄndterer innkapsling av rammer i VxLAN-headere. Man kan trekke en parallell til Tunnel-grensesnittet for GRE:

grensesnitt nve1
  ingen nedslÄing
  vert-reachability-protokoll bgp ! bruker BGP for Ă„ overfĂžre rutingsinformasjon
  kilde-grensesnitt loopback0    ! grensesnittet som vi sender pakker fra loopback0

PÄ Leaf-21-bryteren opprettes alt uten problemer. Men hvis vi sjekker utdataene fra kommandoen vis nve peers, vil de vÊre tomme. Her mÄ vi gÄ tilbake til VPC-konfigurasjonen. Vi ser at Leaf-11 og Leaf-12 fungerer sammen og er koblet til VPC-domenet. Dette gir oss fÞlgende situasjon:

Host-2 sender en ramme mot Leaf-21, slik at den kan overfÞre den over nettverket til Host-1. Imidlertid ser Leaf-21 at MAC-adressen til Host-1 er tilgjengelig via to VTEP-er. Hva bÞr Leaf-21 gjÞre i dette tilfellet? Dette betyr at det kan ha oppstÄtt en lÞkke i nettverket.

For Ä lÞse denne situasjonen mÄ vi sÞrge for at Leaf-11 og Leaf-12 i forbindelse med fabrikkene ogsÄ fungerer som én enhet. Dette lÞses ganske enkelt. PÄ Loopback-grensesnittet som tunnel bygges fra, legger vi til en sekundÊr adresse. SekundÊradressen mÄ vÊre identisk pÄ begge VTEP-ene.

grensesnitt loopback0
 ip add 10.255.1.10/32 sekundĂŠr

Dermed fÄr vi fÞlgende topologi sett fra andre VTEP-er:

VxLAN fabrikk. Del 1

Det vil si at tunnelen nÄ bygges mellom IP-adressen Leaf-21 og den virtuelle IP-en mellom de to Leaf-11 og Leaf-12. NÄ vil det ikke oppstÄ problemer med Ä oppdage MAC-adressen fra de to enhetene, og trafikken kan gÄ fra én VTEP til en annen. Hvem av de to VTEP-ene som hÄndterer trafikken, avgjÞres ved hjelp av rutetabellen pÄ 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

Som vist ovenfor er adressen 10.255.1.10 tilgjengelig via to Next-hop.

PÄ dette stadiet har vi forstÄtt grunnleggende tilkobling. La oss gÄ videre til konfigurasjonen av NVE-grensesnittet:
Vi aktiverer straks VLAN 10 og assosierer det med VNI 10000 pÄ hver Leaf for vertsene. Vi konfigurerer L2-tunnelen mellom vertene.

vlan 10                 ! Aktiver VLAN pÄ alle VTEP tilknyttede nÞdvendige verter
  vn-segment 10000      ! Knytte VLAN til VNI nummeret 

interface nve1
  member vni 10000      ! Legger til VNI 10000 for Ă„ fungere gjennom NVE-grensesnittet for innkapsling i VxLAN
    ingress-replication protocol bgp    ! Angir at vi bruker BGP for Ă„ spre informasjon om verten

La oss nÄ sjekke nve peers og tabellen for 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                 ! Vi ser at peer er tilgjengelig med sekundĂŠr adresse

Leaf11# sh bgp l2vpn evpn

   Network            Next Hop            Metric     LocPrf     Weight Path
Route Distinguisher: 10.255.1.11:32777    (L2VNI 10000)        ! Hvem denne l2VNI kom fra
*>l[3]:[0]:[32]:[10.255.1.10]\/88                                   ! EVPN rute-type 3 - viser vÄr nabo som ogsÄ kjenner til 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

Ovenfor ser vi bare ruter av EVPN rute-type 3. Denne typen ruter forteller om peer (Leaf), men hvor er vÄre verter?
Årsaken er at informasjon om MAC-adressene til vertene sendes via EVPN rute-type 2

For Ä se vÄre verter mÄ vi konfigurere EVPN rute-type 2:

evpn
  vni 10000 l2
    route-target import auto   ! I denne artikkelen bruker vi automatisk nummer for route-target
    route-target export auto

La oss pinge fra Host-2 til 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

Og nedenfor kan vi se at ruter-type 2 med MAC-adressen til vertene - 5001.0007.0007 og 5001.0008.0007 har dukket opp i BGP-tabellen

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 og mac-adressen til vert 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 og mac-adressen til vert 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

Videre kan vi se detaljert informasjon om oppdateringen, der vi fikk informasjon om MAC-vert. Nedenfor er ikke hele utdataene fra kommandoen.

Leaf21# sh bgp l2vpn evpn 5001.0007.0007

BGP rutetabellinformasjon for VRF standard, adressefamilie L2VPN EVPN
Route Distinguisher: 10.255.1.11:32777        !  sendte oppdatering med MAC-vert. Ikke den virtuelle adressen til VPC, men adressen til Leaf
BGP rutetabelloppfĂžring for [2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]\/216,
 versjon 1507
Stier: (2 tilgjengelige, beste #2)
Flagg: (0x000202) (high32 00000000) pÄ xmit-lista, finnes ikke i l2rib\/evpn, finnes ikke i HW

  Stitype: intern, stien er gyldig, ikke beste grunn: Naboadresse, ingen merket nexthop
  AS-Path: INGEN, sti kilder internt til AS
    10.255.1.10 (metrisk 81) fra 10.255.1.102 (10.255.1.102)    ! med hvem vi faktisk bygger VxLAN tunnelen
      Opprinnelse IGP, MED ikke satt, lokalpref 100, vekt 0
      Mottatt etikett 10000         ! Nummeret pÄ VNI som er assosiert med VLAN der verten befinner seg
      Extcommunity: RT:65001:10000 SOO:10.255.1.10:0 ENCAP:8        ! Her kan vi se at RT ble dannet automatisk basert pÄ AS- og VNI-numre
      Opprinnelse: 10.255.1.11 Klynge liste: 10.255.1.102

La oss se hvordan pakkene ser ut nÄr de sendes gjennom fabrikken:

VxLAN fabrikk. Del 1

Suppress-ARP

Flott, vi har nÄ fÄtt L2-forbindelse mellom vertene, og vi kunne ha avsluttet her. Men alt er ikke sÄ enkelt. SÄ lenge vi har fÄ verter, vil det ikke oppstÄ problemer. Men la oss forestille oss en situasjon der vi har hundrevis eller tusenvis av verter. Hvilket problem kan vi stÞte pÄ?

Dette problemet er BUM (Broadcast, Unknown Unicast, Multicast) trafikk. I denne artikkelen vil vi se pÄ hvordan vi kan hÄndtere broadcast-trafikk.
Den primĂŠre generatoren av Broadcast i Ethernet-nettverk er selve vertene via ARP-protokollen.

PĂ„ Nexus er det implementert fĂžlgende mekanisme for Ă„ hĂ„ndtere ARP-forespĂžrslene — suppress-arp.
Denne funksjonen fungerer som fĂžlger:

  1. Vert-1 sender en ARP-forespÞrsel til broadcast-adressen pÄ sitt nettverk.
  2. ForespÞrselen nÄr Leaf-svitsjeren, og i stedet for Ä sende forespÞrselen videre til fabrikken mot Vert-2, svarer Leaf selv og angir Þnsket IP og MAC.

Dermed ble Broadcast-forespÞrselen ikke sendt til fabrikken. Men hvordan kan dette fungere nÄr Leaf bare kjenner til MAC-adressen?

Alt er ganske enkelt, EVPN route-type 2 kan i tillegg til MAC-adressen sende en kombinasjon av MAC/IP. For dette mÄ Leaf ha en IP-adresse konfigurert i VLAN. SpÞrsmÄlet blir, hvilken IP skal vi bruke? PÄ Nexus er det mulig Ä opprette en distribuert (identisk) adresse pÄ alle svitsjene:

feature interface-vlan

fabric forwarding anycast-gateway-mac 0001.0001.0001    ! Sett den virtuelle MAC-en for Ă„ opprette en distribuert gateway mellom alle svitsjene

interface Vlan10
  no shutdown
  ip address 192.168.10.254/24          ! Sett identisk IP pÄ alle Leaf
  fabric forwarding mode anycast-gateway    ! Vi sier at vi skal bruke Virtual MAC

Dermed vil nettverket fra vertens synspunkt se slik ut:

VxLAN fabrikk. Del 1

La oss sjekke BGP l2route evpn

Leaf11# sh bgp l2vpn evpn


   Nettverk            Neste hopp            Metrikk     LocPrf     Vekt Sti
Rute 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



Rute 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

Ut fra utskriften av kommandoen ser vi at i EVPN route-type 2, i tillegg til MAC, nÄ ogsÄ ser IP-adressen til verten.

Vi gÄr tilbake til innstillingen for suppress-arp. Denne innstillingen aktiveres for hver VNI individuelt:

interface nve1
  member vni 10000   
    suppress-arp

Videre oppstÄr det en viss kompleksitet:

  • For at denne funksjonen skal fungere, er det nĂždvendig med plass i TCAM-minnet. Jeg vil gi et eksempel pĂ„ innstilling for suppress-arp:

hardware access-list tcam region arp-ether 256

For denne innstillingen vil det kreves double-wide. Det vil si at hvis du setter 256, mÄ du frigjÞre 512 i TCAM. Innstilling av TCAM gÄr utover rammen av denne artikkelen, da TCAM-innstillingen avhenger utelukkende av oppgaven som er gitt deg og kan variere fra nettverk til nettverk.

  • Implementering av suppress-arp mĂ„ gjĂžres pĂ„ alle Leaf-svitsjer. Imidlertid kan det oppstĂ„ utfordringer ved konfigurasjon pĂ„ par av Leaf-svitsjer som befinner seg i VPC-domenet. Ved endring av TCAM vil konsistensen mellom parene bli brutt, og en node kan bli tatt offline. I tillegg kan en omstart av enheten vĂŠre nĂždvendig for Ă„ bruke konfigurasjonen ved endring av TCAM.

Som et resultat mÄ man nÞye vurdere om det i din situasjon er fornuftig Ä implementere denne innstillingen pÄ en aktiv fabrikk.

Vi avslutter nÄ fÞrste del av syklusen. I neste del vil vi se pÄ ruting gjennom VxLAN-fabrikken, med nettverksdeling pÄ forskjellige VRF-er.

Og nÄ inviterer jeg alle til gratis webinar, hvor jeg vil gÄ i detalj om kurset. De fÞrste 20 deltakerne som registrerer seg pÄ dette webinaret, vil motta et sertifikat med rabatt via e-post innen 1-2 dager etter sendingen.

Kilde: habr.com

KjĂžp pĂ„litelig hosting for nettsteder med DDoS-beskyttelse, VPS VDS-servere đŸ”„ KjĂžp pĂ„litelig hosting for nettsteder med DDoS-beskyttelse, VPS VDS-servere | ProHoster