ProHoster > Log > administrasjon > VxLAN fabrikk. Del 1

VxLAN fabrikk. Del 1

Hei, habr. Jeg er for tiden kursleder for Nettverksingeniør-kurset ved OTUS.
I påvente av oppstart av ny påmelding til kurset "Nettverksingeniør", Jeg har utarbeidet en serie artikler om VxLAN EVPN-teknologi.

Det er en enorm mengde materiale om hvordan VxLAN EVPN fungerer, så jeg ønsker å samle ulike oppgaver og praksiser for å løse problemer i et moderne datasenter.

VxLAN fabrikk. Del 1

I den første delen av serien om VxLAN EVPN-teknologi vil jeg se på en måte å organisere L2-tilkobling mellom verter på toppen av et nettverksstoff.

Alle eksemplene vil bli utført på en Cisco Nexus 9000v, satt sammen i Spine-Leaf-topologien. Vi vil ikke dvele ved å sette opp et Underlay-nettverk i denne artikkelen.

  1. Underlagsnettverk
  2. BGP-peering for adresse-familie l2vpn evpn
  3. Setter opp NVE
  4. Undertrykk-arp

Underlagsnettverk

Topologien som brukes er som følger:

VxLAN fabrikk. Del 1

La oss angi adressering på alle enheter:

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

La oss sjekke at det er IP-tilkobling mellom alle enheter:

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

La oss sjekke at VPC-domenet er opprettet og at begge bryterne 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

Til slutt kan du gå videre til å sette opp Overlay-nettverket.

Som en del av artikkelen er det nødvendig å organisere et nettverk mellom verter, som vist i diagrammet nedenfor:

VxLAN fabrikk. Del 1

For å konfigurere et overleggsnettverk, må du aktivere BGP på Spine og Leaf-svitsjene med støtte for l2vpn evpn-familien:

feature bgp
nv overlay evpn

Deretter må du konfigurere BGP-peering mellom Leaf og Spine. For å forenkle oppsettet og optimalisere distribusjonen av ruteinformasjon, konfigurerer vi Spine som en Route-Reflector-server. Vi vil skrive alle Leaf i konfigurasjonen ved å bruke maler for å optimalisere oppsettet.

Så innstillingene på Spine ser slik 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

Oppsettet på Leaf-bryteren ser lignende 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, la oss sjekke peering med alle Leaf-bryterne:

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 du kan se var det ingen problemer med BGP. La oss gå videre til å sette opp VxLAN. Ytterligere konfigurasjon vil kun gjøres på bladsiden av bryterne. Spine fungerer bare som kjernen i nettverket og er kun involvert i overføring av trafikk. Alt arbeid med innkapsling og veibestemmelse skjer kun på bladbrytere.

Setter opp NVE

NVE - virtuelt nettverksgrensesnitt

Før du starter oppsettet, la oss introdusere litt terminologi:

VTEP - Vitual Tunnel End Point, enheten som VxLAN-tunnelen begynner eller slutter på. VTEP er ikke nødvendigvis en hvilken som helst nettverksenhet. En server som støtter VxLAN-teknologi kan også fungere som en server. I vår topologi er alle Leaf-brytere VTEP.

VNI - Virtual Network Index - nettverksidentifikator innenfor VxLAN. En analogi kan tegnes med VLAN. Det er imidlertid noen forskjeller. Når du bruker et stoff, blir VLAN unike bare innenfor én Leaf-svitsj og overføres ikke over nettverket. Men hvert VLAN kan ha et VNI-nummer knyttet til seg, som allerede er overført over nettverket. Hvordan det ser ut og hvordan det kan brukes vil bli diskutert videre.

La oss aktivere funksjonen for at VxLAN-teknologi skal fungere og muligheten til å knytte VLAN-numre til et VNI-nummer:

feature nv overlay
feature vn-segment-vlan-based

La oss konfigurere NVE-grensesnittet, som er ansvarlig for driften av VxLAN. Dette grensesnittet er ansvarlig for innkapsling av rammer i VxLAN-overskrifter. Du kan tegne en analogi med Tunnel-grensesnittet for GRE:

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

På Leaf-21-bryteren lages alt uten problemer. Men hvis vi sjekker utgangen av kommandoen show nve peers, da blir det tomt. Her må du gå tilbake til VPC-konfigurasjonen. Vi ser at Leaf-11 og Leaf-12 fungerer i par og er forent av et VPC-domene. Dette gir oss følgende situasjon:

Host-2 sender en ramme mot Leaf-21 slik at den overfører den over nettverket mot Host-1. Leaf-21 ser imidlertid at MAC-adressen til Host-1 er tilgjengelig gjennom to VTEP-er samtidig. Hva bør Leaf-21 gjøre i dette tilfellet? Tross alt betyr dette at en løkke kan dukke opp i nettverket.

For å løse denne situasjonen må Leaf-11 og Leaf-12 også fungere som én enhet på fabrikken. Løsningen er ganske enkel. På Loopback-grensesnittet som vi bygger tunnelen fra, legg til en sekundær adresse. Sekundæradressen må være den samme på begge VTEP-ene.

interface loopback0
 ip add 10.255.1.10/32 secondary

Fra andre VTEPs synspunkt får vi følgende topologi:

VxLAN fabrikk. Del 1

Det vil si at nå skal tunnelen bygges mellom IP-adressen til Leaf-21 og den virtuelle IP-en mellom to Leaf-11 og Leaf-12. Nå vil det ikke være noen problemer med å lære MAC-adressen fra to enheter, og trafikken kan flytte fra en VTEP til en annen. Hvilken av de to VTEP-ene som skal behandle trafikken avgjøres ved å bruke 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 du kan se ovenfor, er adressen 10.255.1.10 tilgjengelig umiddelbart gjennom to Next-hops.

På dette stadiet har vi behandlet den grunnleggende tilkoblingen. La oss gå videre til å sette opp NVE-grensesnittet:
La oss umiddelbart aktivere Vlan 10 og knytte den til VNI 10000 på hvert blad for vertene. La oss sette opp en L2-tunnel mellom verter

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

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

La oss nå sjekke nve jevnaldrende 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                 ! Видим что 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

Ovenfor ser vi bare ruter av typen EVPN rutetype 3. Denne rutetypen snakker om peer(Leaf), men hvor er vertene våre?
Saken er at informasjon om MAC-vertene overføres via EVPN-rutetype 2

For å se vertene våre må du konfigurere EVPN-rutetype 2:

evpn
  vni 10000 l2
    route-target import auto   ! в рамках данной статьи используем автоматический номер для 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 rutetype 2 med verts MAC-adresse dukket opp i BGP-tabellen - 5001.0007.0007 og 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

Deretter kan du se detaljert informasjon om Update, der du mottok informasjon om MAC Host. Nedenfor er ikke all kommandoutgang.

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

La oss se hvordan rammer ser ut når de føres gjennom fabrikken:

VxLAN fabrikk. Del 1

Undertrykk-ARP

Flott, vi har nå L2-kommunikasjon mellom vertene og vi kunne fullføre der. Imidlertid er ikke alt så enkelt. Så lenge vi har få verter vil det ikke være noen problemer. Men la oss forestille oss en situasjon der vi har hundrevis og tusenvis av verter. Hvilket problem kan vi møte?

Dette problemet er BUM-trafikk (Broadcast, Unknown Unicast, Multicast). I denne artikkelen vil vi vurdere muligheten for å håndtere kringkastingstrafikk.
Hovedkringkastingsgeneratoren i Ethernet-nettverk er vertene selv via ARP-protokollen.

Nexus implementerer følgende mekanisme for å bekjempe ARP-forespørsler - suppress-arp.
Denne funksjonen fungerer som følger:

  1. Host-1 sender en APR-forespørsel til kringkastingsadressen til nettverket sitt.
  2. Forespørselen når Leaf-bryteren og i stedet for å sende denne forespørselen videre til stoffet mot Host-2, svarer Leaf selv og indikerer nødvendig IP og MAC.

Dermed gikk ikke Broadcast-forespørselen til fabrikken. Men hvordan kan dette fungere hvis Leaf bare kjenner MAC-adressen?

Alt er ganske enkelt, EVPN rute-type 2, i tillegg til MAC-adressen, kan overføre en MAC/IP-kombinasjon. For å gjøre dette må du konfigurere en IP-adresse i VLAN on Leaf. Spørsmålet oppstår, hvilken IP bør jeg angi? På nexus er det mulig å opprette en distribuert (samme) adresse på alle brytere:

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

Dermed, fra vertens synspunkt, vil nettverket se slik ut:

VxLAN fabrikk. Del 1

La oss sjekke 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

<......>

Fra kommandoutgangen kan du se at i EVPN rute-type 2, i tillegg til MAC, ser vi nå også vertens IP-adresse.

La oss gå tilbake til å sette suppress-arp. Denne innstillingen er aktivert for hver VNI separat:

interface nve1
  member vni 10000   
    suppress-arp

Da oppstår noe kompleksitet:

  • For at denne funksjonen skal fungere, kreves det plass i TCAM-minnet. Her er et eksempel på innstillinger for suppress-arp:

hardware access-list tcam region arp-ether 256

Denne innstillingen krever dobbel bredde. Det vil si at hvis du setter 256, må du frigjøre 512 i TCAM. Oppsett av TCAM er utenfor rammen av denne artikkelen, siden oppsett av TCAM bare avhenger av oppgaven som er tildelt deg og kan variere fra nettverk til nettverk.

  • Implementering av suppress-arp må gjøres på alle Leaf-brytere. Det kan imidlertid oppstå kompleksitet når du konfigurerer på Leaf-par som ligger i et VPC-domene. Hvis TCAM endres, vil konsistensen mellom parene bli brutt og en node kan tas ut av drift. I tillegg kan det være nødvendig med omstart av enheten for å bruke TCAM-endringsinnstillingen.

Som et resultat må du nøye vurdere om det i din situasjon er verdt å implementere denne innstillingen i en løpende fabrikk.

Dette avslutter første del av serien. I neste del skal vi se på ruting gjennom et VxLAN-stoff med separasjon av nettverk i forskjellige VRF-er.

Og nå inviterer jeg alle til gratis webinar, der jeg vil fortelle deg i detalj om kurset. De første 20 deltakerne som registrerer seg for dette webinaret vil motta et rabattbevis via e-post innen 1-2 dager etter sendingen.

Kilde: www.habr.com

Legg til en kommentar