Hej, Habr. Jeg er i øjeblikket kursusleder for "Netværksingeniør" ved OTUS.
I forklaringen af den nye optagelse til kurset , jeg har forberedt en række artikler om VxLAN EVPN teknologi.
Der er et væld af materialer om arbejdet med VxLAN EVPN, så jeg ønsker at samle forskellige opgaver og metoder til løsning af problemer i moderne datacentre.
I den første del af cyklussen om VxLAN EVPN teknologi, vil jeg se på, hvordan man organiserer L2 forbindelse mellem værter over netværksfabrikken.
Alle eksempler vil blive udført på Cisco Nexus 9000v, bygget op i en Spine-Leaf topologi. Vi vil ikke fokusere på konfigurationen af Underlay-netværket i denne artikel.
- Underlay-netværk
- BGP-peering for address-family l2vpn evpn
- Konfiguration af NVE
- Supress-arp
Underlay-netværk
Den anvendte topologi ser således ud:
Lad os indstille adresserne 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 tjekke, at der er IP-forbindelse mellem alle enheder:
Leaf21# sh ip route
10.255.1.11/32, ubest/mbest: 2/0 ! Leaf-11 tilgængelig 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 tilgængelig 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, intraLad os tjekke, om VPC-domenet er oprettet, og begge switche har bestået konsistenskontrollen, og indstillingerne på begge noder er identiske:
Leaf11# show vpc
vPC domæne ID : 1
Peer status : peer adjacency formed ok
vPC keep-alive status : peer is alive
Konfigurationskonsistens status : success
Per-vlan konsistens status : success
Type-2 konsistens status : success
vPC rolle : primary
Antal konfigurerede vPC'er : 0
Peer Gateway : Deaktiveret
Dual-active excluded VLANs : -
Graceful Consistency Check : Aktiveret
Auto-recovery status : Deaktiveret
Delay-restore status : Timer er off.(timeout = 30s)
Delay-restore SVI status : Timer er off.(timeout = 10s)
Operational Layer3 Peer-router : Deaktiveret
vPC status
----------------------------------------------------------------------------
Id Port Status Konsistens Årsag Aktive vlans
-- ------------ ------ ----------- ------ ---------------
5 Po5 op success success 1BGP peering
Endelig kan vi overgå til konfigurationen af Overlay-netværket.
I denne artikel skal der organiseres et netværk mellem værterne, som vist i diagrammet nedenfor:
For configuring the Overlay network, it is necessary to enable BGP with support for the l2vpn evpn address family on the Spine and Leaf switches:
feature bgp
nv overlay evpnNext, configure BGP peering between Leaf and Spine. To simplify configuration and optimize the propagation of routing information, we set up Spine as a Route-Reflector server. We will define all Leaf switches in the config using templates to optimize the setup.
Thus, the configuration on Spine looks like this:
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 LEAFThe configuration on the Leaf switch looks similar:
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 SPINEOn Spine, we will check the peering with all Leaf switches:
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 0As we can see, there are no problems with BGP. Let’s move on to configuring VxLAN. Further configuration will only be done on the Leaf switches. Spine acts only as the core of the network and only handles traffic forwarding. All encapsulation and path determination work occurs solely on the Leaf switches.
Konfiguration af NVE
NVE — network virtual interface
Before we start the configuration, let’s introduce some terminology:
VTEP — Virtual Tunnel End Point, a device where the VxLAN tunnel begins or ends. A VTEP does not necessarily have to be a network device. A server with support for VxLAN technology can also serve this purpose. In our topology, all Leaf switches are VTEPs.
VNI — Virtual Network Index — an identifier for the network within VxLAN. It can be compared to VLANs. However, there are some differences. When using a factory, VLANs become unique only within a single Leaf switch and are not propagated over the network. But each VLAN can be associated with a VNI number, which is indeed propagated over the network. How this looks and how it can be used will be discussed later.
We will enable the feature for the VxLAN technology to allow associating VLAN numbers with VNI numbers:
feature nv overlay
feature vn-segment-vlan-basedVi opsætter NVE-grænsefladen, der håndterer VxLAN. Denne grænseflade er ansvarlig for indkapslingen af rammer i VxLAN-headerne. Man kan lave en sammenligning med Tunnel-grænsefladen til brug for GRE:
interface nve1
no shutdown
host-reachability protocol bgp ! vi bruger BGP til at overføre ruteinformation
source-interface loopback0 ! grænseflade, fra hvilken vi sender pakker loopback0På Leaf-21-switchen skabes alt uden problemer. Men hvis vi tjekker output fra kommandoen show nve peers, viser det sig at være tomt. Her er det nødvendigt at vende tilbage til indstillingen af VPC. Vi kan se, at Leaf-11 og Leaf-12 arbejder i par og er forenet i VPC-domænet. Heraf opstår følgende situation:
Host-2 sender en ramme mod Leaf-21, så den kan sende den videre i netværket mod Host-1. Men Leaf-21 ser, at MAC-adressen til Host-1 er tilgængelig gennem to VTEP. Hvordan skal Leaf-21 håndtere dette tilfælde? Det betyder, at der kunne være opstået en loop i netværket.
For at løse denne situation er det nødvendigt, at Leaf-11 og Leaf-12 inden for fabrikken også fungerer som én enhed. Dette kan løses relativt nemt. På Loopback-grænsefladen, hvor vi bygger tunnelen, tilføjer vi en sekundær adresse. Den sekundære adresse skal være den samme på begge VTEP.
interface loopback0
ip add 10.255.1.10/32 secondaryDermed får vi følgende topologi set fra de andre VTEP:
Det betyder, at tunnelen nu vil blive bygget mellem IP-adressen Leaf-21 og den virtuelle IP mellem de to Leaf-11 og Leaf-12. Nu vil der ikke opstå problemer med at lære MAC-adressen fra de to enheder, og trafikken kan flytte fra ét VTEP til et andet. Hvem af de to VTEP, der vil håndtere trafikken, afgøres ved hjælp af en routingtabel 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 det fremgår ovenfor, er adressen 10.255.1.10 tilgængelig gennem to Next-hop.
På dette stadie har vi forstået den grundlæggende sammenhæng. Lad os gå videre til opsætningen af NVE-grænsefladen:
Vi aktiverer straks VLAN 10 og associaterer det med VNI 10000 på hver Leaf for værterne. Vi opsætter en L2 tunnel mellem værterne.
vlan 10 ! Aktiver VLAN på alle VTEP-forbindelser til de nødvendige værter
vn-segment 10000 ! Associerer VLAN med VNI-nummeret
interface nve1
member vni 10000 ! Tilføjer VNI 10000 til brug gennem NVE-interface til indkapsling i VxLAN
ingress-replication protocol bgp ! Angiver, at vi bruger BGP til at sprede information om værtenLad os nu kontrollere 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 ! Ser, at peer er tilgængelig fra sekundær adresse
Leaf11# sh bgp l2vpn evpn
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.255.1.11:32777 (L2VNI 10000) ! Fra hvem denne l2VNI kom
*>l[3]:[0]:[32]:[10.255.1.10] /88 ! EVPN route-type 3 - viser vores nabo, som også kender 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 iOvenfor ser vi ruter kun EVPN route-type 3. Denne type ruter informerer om peer (Leaf), men hvor er vores værter?
Det er, fordi informationen om MAC-adresserne for værterne sendes via EVPN route-type 2
For at se vores værter skal vi konfigurere EVPN route-type 2:
evpn
vni 10000 l2
route-target import auto ! I denne artikel bruger vi automatisk nummer for route-target
route-target export autoLad os lave ping 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 der i BGP-tabellen er dukket route-type 2 op med MAC-adresserne for værterne — 5001.0007.0007 og 5001.0008.0007
Leaf11# sh bgp l2vpn evpn
Netværk Næste Hop Metric LocPrf Vægt Sti
Rute Distinguisher: 10.255.1.11:32777 (L2VNI 10000)
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]\/216 ! evpn rute-type 2 og mac adresse for host 1
10.255.1.10 100 32768 i
*>i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]\/216 ! evpn rute-type 2 og mac adresse for 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
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 iDu kan nu se detaljerede oplysninger om opdateringen, hvor vi fik oplysninger om MAC Host. Nedenfor er ikke hele output fra kommandoen
Leaf21# sh bgp l2vpn evpn 5001.0007.0007
BGP routingtabelinformation for VRF standard, adressefamilie L2VPN EVPN
Rute Distinguisher: 10.255.1.11:32777 ! sendte opdatering med MAC Host. Ikke den virtuelle adresse VPC, men adressen til Leaf
BGP routingtabelpost for [2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]\/216,
version 1507
Stier: (2 tilgængelige, bedst #2)
Flags: (0x000202) (high32 00000000) på xmit-listen, er ikke i l2rib\/evpn, er ikke i HW
Sti type: intern, stien er gyldig, ikke bedste grund: Naboadresse, ingen mærket næstehops
AS-Path: INGEN, stien er kildet intern til AS
10.255.1.10 (metric 81) fra 10.255.1.102 (10.255.1.102) ! hvem bygger vi VxLAN tunnel med
Oprindelse IGP, MED ikke indstillet, localpref 100, vægt 0
Modtaget label 10000 ! Nummer VNI, der er tilknyttet VLAN, hvor Host er
Extcommunity: RT:65001:10000 SOO:10.255.1.10:0 ENCAP:8 ! Her kan man se, at RT blev dannet automatisk baseret på nummerne AS og VNI
Oprinderen: 10.255.1.11 Klynge liste: 10.255.1.102Lad os se, hvordan rammerne ser ud, når de sendes gennem fabrikken:
Suppress-ARP
Fantastisk, L2-forbindelse mellem værter er nu oprettet, og vi kunne have afsluttet her. Dog er det ikke så simpelt. Indtil nu har vi få værter, så der opstår ingen problemer. Men lad os forestille os en situation, hvor vi har hundreder eller tusinder af værter. Hvilket problem kan vi stå overfor?
Dette problem er BUM (Broadcast, Unknown Unicast, Multicast) trafik. I denne artikel vil vi se på, hvordan man bekæmper broadcast trafik.
Den primære generator af broadcast i Ethernet netværk er selve værterne via ARP protokollen.
På Nexus er der implementeret følgende mekanisme til at bekæmpe ARP forespørgsler — suppress-arp.
Funktionen fungerer som følger:
- Host-1 sender en ARP forespørgsel til broadcastadressen for sit netværk.
- Forespørgslen når Leaf-switchen, og i stedet for at overføre forespørgslen videre til fabrikken mod Host-2 — svarer Leaf selv og angiver den nødvendige IP og MAC.
Dermed er Broadcast-anmodningen ikke sendt til fabrikken. Men hvordan kan dette fungere, når Leaf kun kender MAC-adressen?
Det hele er ret simpelt, EVPN route-type 2 kan, ud over MAC-adressen, også sende en kombination af MAC/IP. For dette skal der konfigureres en IP-adresse i VLAN på Leaf. Spørgsmålet opstår: hvilken IP skal angives? På Nexus er det muligt at oprette en distribueret (identisk) adresse på alle switches:
feature interface-vlan
fabric forwarding anycast-gateway-mac 0001.0001.0001 ! vi angiver en virtuel mac for at oprette et distribueret gateway mellem alle switches
interface Vlan10
no shutdown
ip address 192.168.10.254/24 ! vi angiver den samme IP på alle Leaf-enheder
fabric forwarding mode anycast-gateway ! vi indikerer, at Virtual mac skal brugesDermed vil netværket set fra værterne se således ud:
Lad os kontrollere BGP l2route evpn
Leaf11# sh bgp l2vpn evpn
Netværk Næste hop Metode LocPrf Vægt 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 iFra outputtet af kommandoen kan vi se, at vi nu, ud over MAC, også ser IP-adressen for værten i EVPN route-type 2.
Vi vender tilbage til konfigurationen af suppress-arp. Denne indstilling aktiveres for hver VNI individuelt:
interface nve1
medlem vni 10000
suppress-arpDer opstår dernæst en vis kompleksitet:
- For at denne funktion skal fungere, kræves der plads i TCAM-hukommelsen. Her er et eksempel på konfiguration for suppress-arp:
hardware access-list tcam region arp-ether 256For denne indstilling kræves der double-wide. Det vil sige, at hvis du angiver 256, skal du frigøre 512 i TCAM. Indstillingerne for TCAM overstiger rammerne for denne artikel, da TCAM-konfigurationen kun afhænger af opgaven, du har fået, og kan variere fra netværk til netværk.
- Implementeringen af suppress-arp skal udføres på alle Leaf-switches. Der kan dog opstå kompleksitet ved konfigurationen af par af Leaf, der befinder sig i VPC-domenet. Ved ændringer i TCAM vil konsistensen mellem parrene blive brudt, og en node kan blive deaktiveret. Derudover kan det kræve en genstart af enheden for at anvende indstillingen ved ændringer i TCAM.
Som resultat skal man overveje, om det i ens situation er hensigtsmæssigt at implementere denne indstilling på en fungerende fabrik.
Vi afslutter den første del af cyklen her. I den næste del vil vi se på routing gennem VxLAN-fabrikken med opdeling af netværkene i forskellige VRF.
Og nu inviterer jeg alle til , hvor jeg grundigt vil fortælle om kurset. De første 20 deltagere, der registrerer sig til dette webinar, vil modtage et certifikat med rabat på deres e-mail inden for 1-2 dage efter livestreamen.
Kilde: habr.com
