Hej habr. Jeg er i øjeblikket kursusleder for "Netværksingeniør" på OTUS.
I forventning om start af ny tilmelding til kurset , Jeg har udarbejdet en række artikler om VxLAN EVPN-teknologi.
Der er en enorm mængde materiale om driften af VxLAN EVPN, så jeg ønsker at samle forskellige opgaver og praksisser til at løse problemer i et moderne datacenter.
I den første del af VxLAN EVPN-teknologicyklussen vil jeg overveje en måde at organisere L2-forbindelse mellem værter oven på en netværksfabrik.
Alle eksempler vil blive udført på Cisco Nexus 9000v, samlet i Spine-Leaf-topologien. Vi vil ikke dvæle ved opsætning af Underlay-netværket i denne artikel.
- underlagsnetværk
- BGP peering for adresse-familie l2vpn evpn
- NVE opsætning
- Undertrykke-arp
underlagsnetværk
Den anvendte topologi er som følger:
Lad os indstille adressering på alle enheder:
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.20Lad os kontrollere, at der er IP-forbindelse mellem alle enheder:
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, intraLad os kontrollere, at VPC-domænet er blevet oprettet, og at begge switches har bestået konsistenskontrollen, og indstillingerne på begge noder 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 1BGP peering
Endelig kan vi gå videre til at konfigurere Overlay-netværket.
Som en del af artiklen er det nødvendigt at organisere et netværk mellem værter, som vist i diagrammet nedenfor:
For at konfigurere et Overlay-netværk skal du aktivere BGP på Spine og Leaf-switcherne med understøttelse af l2vpn evpn-familien:
feature bgp
nv overlay evpnDernæst skal du konfigurere BGP-peering mellem Leaf og Spine. For at forenkle konfigurationen og optimere distributionen af ruteinformation, konfigurerer vi Spine som en Route-Reflector-server. Vi vil skrive alle Leaf i konfigurationen gennem skabeloner for at optimere indstillingen.
Så indstillingerne på Spine ser sådan ud:
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 LEAFOpsætningen på Leaf-kontakten ser ens ud:
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 SPINEPå Spine skal du kontrollere peering med alle Leaf-kontakter:
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 0Som du kan se, var der ingen problemer med BGP. Lad os gå videre til opsætning af VxLAN. Yderligere konfiguration udføres kun på siden af Leaf-kontakterne. Spine fungerer kun som kernen i netværket og er kun involveret i transmissionen af trafik. Alt arbejde med indkapsling og stidefinition foregår kun på Leaf switches.
NVE opsætning
NVE - virtuel netværksgrænseflade
Før du starter opsætningen, lad os introducere noget terminologi:
VTEP - Vitual Tunnel End Point, den enhed, hvorpå VxLAN-tunnelen begynder eller slutter. VTEP er ikke nødvendigvis en hvilken som helst netværksenhed. En server, der understøtter VxLAN-teknologi, kan også fungere. I vores topologi er alle Leaf-switche VTEP'er.
VNI - Virtual Network Index - netværksidentifikator i VxLAN. Du kan tegne en analogi med VLAN. Der er dog nogle forskelle. Når du bruger et stof, bliver VLAN'er kun unikke inden for én Leaf-switch og transmitteres ikke over netværket. Men hvert VLAN kan associeres med et VNI-nummer, der allerede er transmitteret over netværket. Hvordan det ser ud, og hvordan det kan bruges, vil blive diskuteret nedenfor.
Aktiver funktionen, så VxLAN-teknologien fungerer, og muligheden for at knytte VLAN-numre til et VNI-nummer:
feature nv overlay
feature vn-segment-vlan-basedLad os konfigurere NVE-grænsefladen, som er ansvarlig for driften af VxLAN. Denne grænseflade er ansvarlig for at indkapsle rammer i VxLAN-headere. Du kan tegne en analogi med Tunnel-grænsefladen til GRE:
interface nve1
no shutdown
host-reachability protocol bgp ! используем BGP для передачи маршрутной информации
source-interface loopback0 ! интерфейс с которого отправляем пакеты loopback0På Leaf-21 switchen er alt skabt uden problemer. Men hvis vi tjekker udgangen af kommandoen show nve peers, så er den tom. Her skal du tilbage til VPC-opsætningen. Vi ser, at Leaf-11 og Leaf-12 er parret og forenet af et VPC-domæne. Dette resulterer i følgende situation:
Host-2 sender en frame til Leaf-21 for at blive transmitteret over netværket til Host-1. Leaf-21 ser dog, at Host-1's MAC-adresse er tilgængelig via to VTEP'er på én gang. Hvad skal Leaf-21 gøre i dette tilfælde? Det betyder jo, at der kan opstå en løkke i netværket.
For at løse denne situation skal Leaf-11 og Leaf-12 også fungere som én enhed på fabrikken. Det er løst ganske enkelt. Tilføj den sekundære adresse på Loopback-grænsefladen, hvorfra vi bygger tunnelen. Sekundær adresse skal være den samme på begge VTEP'er.
interface loopback0
ip add 10.255.1.10/32 secondaryFra andre VTEP'ers synspunkt får vi således følgende topologi:
Det vil sige, nu vil tunnelen blive bygget mellem IP-adressen på Leaf-21 og den virtuelle IP mellem to Leaf-11 og Leaf-12. Nu vil der ikke være problemer med at lære MAC-adressen fra to enheder, og trafik kan overføres fra en VTEP til en anden. Hvilken af de to VTEP'er, der skal behandle trafikken, afgøres ved hjælp af routingtabellen 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, intraSom du kan se ovenfor, er adressen 10.255.1.10 tilgængelig med det samme gennem to Next-hops.
På dette tidspunkt fandt vi ud af den grundlæggende forbindelse. Lad os gå videre til opsætning af NVE-grænsefladen:
Vi vil straks aktivere Vlan 10 og knytte det til VNI 10000 på hvert blad for værter. Opsæt en L2-tunnel mellem værterne
vlan 10 ! Включаем VLAN на всех VTEP подключенных к необходимым хостам
vn-segment 10000 ! Ассоциируем VLAN с номер VNI
interface nve1
member vni 10000 ! Добавляем VNI 10000 для работы через интерфейс NVE. для инкапсуляции в VxLAN
ingress-replication protocol bgp ! указываем, что для распространения информации о хосте используем BGPLad os nu tjekke nve peers og tabel 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 iOvenfor ser vi kun ruter EVPN rute-type 3. Denne type ruter taler om peer (Leaf), men hvor er vores værter?
Og sagen er, at information om MAC-værter transmitteres via EVPN-rutetype 2
For at se vores værter skal du konfigurere EVPN-rutetype 2:
evpn
vni 10000 l2
route-target import auto ! в рамках данной статьи используем автоматический номер для route-target
route-target export autoLad os 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 msOg nedenfor kan vi se, at rute-type 2 dukkede op i BGP-tabellen med MAC-adressen på værterne - 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 iDernæst kan du se detaljerede oplysninger om Update, hvor du modtog information om MAC Host. Nedenfor er ikke hele outputtet af kommandoen
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
<........>Lad os se, hvordan rammerne ser ud, når de føres gennem fabrikken:
Undertryk-ARP
Fantastisk, vi har en L2-forbindelse mellem værter, og det kan være enden på det. Dog ikke alt så enkelt. Så længe vi har få værter, vil der ikke være problemer. Men lad os forestille os situationer, hvor vi har hundreder og tusinder af værter. Hvilket problem kan vi stå over for?
Dette problem er BUM-trafik (Broadcast, Unknown Unicast, Multicast). Inden for rammerne af denne artikel vil vi overveje muligheden for at bekæmpe broadcast-trafik.
Den vigtigste Broadcast-generator i Ethernet-netværk er værterne selv via ARP-protokollen.
Nexus implementerer følgende mekanisme til håndtering af ARP-anmodninger - suppress-arp.
Denne funktion fungerer således:
- Host-1 sender en APR-anmodning til broadcast-adressen på sit netværk.
- Forespørgslen når Leaf-kontakten og i stedet for at sende denne anmodning videre til fabrikken mod Host-2, svarer Leaf sig selv og angiver den ønskede IP og MAC.
Broadcast-anmodningen gik således ikke til fabrikken. Men hvordan kan dette fungere, hvis Leaf kun kender MAC-adressen?
Alt er ret simpelt, EVPN-rutetype 2 kan udover MAC-adressen overføre en MAC / IP-pakke. For at gøre dette skal Leaf være konfigureret med en IP-adresse i VLAN. Spørgsmålet opstår, hvilken IP skal man spørge? På nexus er det muligt at oprette en distribueret (samme) adresse på alle switches:
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 macFra værternes synspunkt vil netværket således se sådan ud:
Tjek 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 outputtet af kommandoen kan det ses, at i EVPN rute-type 2, udover MAC, ser vi nu også IP-adressen på værten.
Lad os vende tilbage til suppress-arp indstillingen. Denne indstilling er aktiveret for hver VNI separat:
interface nve1
member vni 10000
suppress-arpSå er der lidt vanskeligheder:
- Denne funktion kræver plads i TCAM-hukommelsen. Jeg vil give et eksempel på indstilling for suppress-arp:
hardware access-list tcam region arp-ether 256Denne opsætning kræver dobbelt-wide. Det vil sige, at hvis du indstiller 256, så skal 512 frigives i TCAM. Opsætning af TCAM ligger uden for rammerne af denne artikel, da opsætning af TCAM kun afhænger af den opgave, der er tildelt dig og kan variere fra et netværk til et andet.
- Implementeringen af suppress-arp skal ske på alle Leaf switches. Der kan dog opstå kompleksitet ved konfiguration på Leaf-par placeret i et VPC-domæne. Når du ændrer TCAM, vil konsistensen mellem parrene blive brudt, og en node kan tages ud af drift. Derudover kan det være nødvendigt at genstarte enheden for at anvende TCAM-ændringsindstillingen.
Som et resultat bør du nøje overveje, om det er værd at implementere denne indstilling på en fungerende fabrik i din situation.
Dette afslutter den første del af cyklussen. I den næste del vil vi overveje at dirigere gennem en VxLAN-fabrik med netværksadskillelse på tværs af forskellige VRF'er.
Og nu inviterer jeg alle til det , hvor jeg vil fortælle detaljeret om forløbet. De første 20 deltagere, der tilmelder sig dette webinar, vil modtage et Rabatbevis på e-mail inden for 1-2 dage efter udsendelsen.
Kilde: www.habr.com