Bună, Habr. În prezent, sunt coordonatorul cursului "Inginer de rețea" în OTUS.
Înainte de începerea unui nou grup pentru curs , am pregătit un ciclu de articole despre tehnologia VxLAN EVPN.
Există o mulțime de materiale despre utilizarea VxLAN EVPN, așa că vreau să adun diverse probleme și soluții practice în centrele de date moderne.
În prima parte a ciclului despre tehnologia VxLAN EVPN vreau să discut despre modalitatea de organizare a conectivității L2 între gazde deasupra fabricii de rețea.
Toate exemplele vor fi efectuate pe Cisco Nexus 9000v, configurate într-o topologie Spine-Leaf. Nu ne vom opri la configurarea rețelei Underlay în cadrul acestui articol.
- Rețea Underlay
- Piring BGP pentru address-family l2vpn evpn
- Configurarea NVE
- Supress-arp
Rețea Underlay
Topologia utilizată arată astfel:
Vom seta adresele pe toate dispozitivele:
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.20Să verificăm că există conectivitate IP între toate dispozitivele:
Leaf21# sh ip route
10.255.1.11/32, ubest/mbest: 2/0 ! Leaf-11 este accesibil prin două 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 este accesibil prin două 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, intraSă verificăm că domeniul VPC a fost creat și ambele switch-uri au trecut testul de consistență iar setările de pe ambele noduri sunt identice:
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 1Piring BGP
În cele din urmă, putem trece la configurarea rețelei Overlay.
În cadrul articolului, este necesar să se organizeze rețeaua între gazde, așa cum este prezentată în schema de mai jos:
Pentru a configura rețeaua Overlay, este necesar să activăm BGP cu suport pentru familia l2vpn evpn pe comutatoarele Spine și Leaf:
feature bgp
nv overlay evpnApoi, este necesar să configurăm piruirea BGP între Leaf și Spine. Pentru a simplifica configurația și a optimiza răspândirea informațiilor de rutare, configurăm Spine ca server Route-Reflector. Vom lista toate Leaf în configurație prin șabloane, pentru a optimiza setările.
Astfel, configurațiile de pe Spine arată astfel:
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 LEAFConfigurația pe comutatorul Leaf arată 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 SPINEPe Spine, vom verifica piruirea cu toate comutatoarele Leaf:
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 0După cum vedem, nu au apărut probleme cu BGP. Să trecem la configurația VxLAN. Configurarea ulterioară va fi realizată doar pe partea comutatoarelor Leaf. Spine funcționează doar ca nucleul rețelei și se ocupă doar cu transmiterea traficului. Toată activitatea de encapsulare și determinarea căii are loc doar pe comutatoarele Leaf.
Configurarea NVE
NVE — interfață virtuală de rețea
Înainte de a începe configurația, să introducem puțină terminologie:
VTEP — Vitual Tunnel End Point, un dispozitiv pe care începe sau se termină tunelul VxLAN. VTEP nu trebuie să fie neapărat un dispozitiv de rețea. Poate fi, de asemenea, un server cu suport pentru tehnologia VxLAN. În topologia noastră, toate comutatoarele Leaf sunt VTEP.
VNI — Indexul rețelei virtuale — identificatorul rețelei în cadrul VxLAN. Se poate face o analogie cu VLAN. Cu toate acestea, există unele diferențe. Atunci când se utilizează fabrica, VLAN-urile devin unice doar în cadrul unui singur comutator Leaf și nu sunt transmise prin rețea. Dar fiecărui VLAN îi poate fi asociat un număr de VNI, care este deja transmis prin rețea. Cum arată aceasta și cum poate fi utilizată va fi discutat mai departe.
Activăm funcția pentru tehnologii VxLAN și posibilitatea de a asocia numere VLAN cu numărul VNI:
funcția nv overlay
funcția vn-segment-vlan-basedVom configura interfața NVE, care este responsabilă pentru funcționarea VxLAN. Această interfață este responsabilă pentru encapsularea cadrelor în antetele VxLAN. Se poate face o analogie cu interfața Tunnel pentru funcționarea GRE:
interfață nve1
nu închide
protocol de accesibilitate a gazdelor bgp ! folosim BGP pentru a transmite informații de rutare
interfață-sursă loopback0 ! interfața de pe care trimitem pachete loopback0Pe comutatorul Leaf-21, totul se creează fără probleme. Cu toate acestea, dacă verificăm ieșirea comenzii show nve peers, aceasta va fi goală. Este necesar să ne întoarcem la configurarea VPC. Vedem că Leaf-11 și Leaf-12 operează împreună și sunt unite printr-un domeniu VPC. Din aici rezultă următoarea situație:
Host-2 trimite un cadru către Leaf-21, pentru a-l transmite prin rețea către Host-1. Cu toate acestea, Leaf-21 observă că adresa MAC a Host-1 este disponibilă prin două VTEP. Cum ar trebui să procedeze Leaf-21 în acest caz? Aceasta înseamnă că în rețea ar putea apărea o buclă.
Pentru a rezolva această situație, este necesar ca Leaf-11 și Leaf-12 să acționeze ca un singur dispozitiv în cadrul fabricii. Acest lucru se rezolvă foarte simplu. Pe interfața Loopback de pe care construim tunelul, adăugăm o adresă secundară. Adresa secundară trebuie să fie aceeași pe ambele VTEP.
interfață loopback0
ip add 10.255.1.10/32 secundarAstfel, din perspectiva altor VTEP, obținem următoarea topologie:
Asta înseamnă că acum tunelul va fi construit între adresa IP a Leaf-21 și IP-ul virtual între cele două Leaf-11 și Leaf-12. Acum nu vor exista probleme în identificarea adresei MAC de la cele două dispozitive, iar traficul poate trece de la un VTEP la altul. Cine anume din cele două VTEP va gestiona traficul este decis prin tabela de rutare pe 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, intraDupă cum se poate observa mai sus, adresa 10.255.1.10 este disponibilă prin două Next-hop.
În această etapă ne-am ocupat de conectivitatea de bază. Să trecem la configurarea interfeței NVE:
Imediat vom activa VLAN 10 și îl vom asocia cu VNI 10000 pe fiecare Leaf pentru gazde. Vom configura un tunel L2 între gazde.
vlan 10 ! Activăm VLAN pe toate VTEP-urile conectate la gazdele necesare
vn-segment 10000 ! Asociem VLAN cu numărul VNI
interface nve1
member vni 10000 ! Adăugăm VNI 10000 pentru a funcționa prin interfața NVE, pentru încapsularea în VxLAN
ingress-replication protocol bgp ! specificăm că pentru răspândirea informațiilor despre gazdă folosim BGPAcum să verificăm peer-urile nve și tabela pentru 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 ! Vedem că peer-ul este accesibil de pe adresa secundară
Leaf11# sh bgp l2vpn evpn
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.255.1.11:32777 (L2VNI 10000) ! De unde a venit acest l2VNI
*>l[3]:[0]:[32]:[10.255.1.10]/88 ! Tipul de rută EVPN 3 - arată vecinul nostru, care de asemenea știe despre 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 iMai sus vedem rutele doar de tip EVPN 3. Acest tip de rute oferă informații despre peer (Leaf), dar unde sunt gazdele noastre?
Problema este că informațiile despre MAC-urile gazdelor sunt transmise prin rutele de tip EVPN 2
Pentru a vedea gazdele noastre, trebuie să configurăm EVPN route-type 2:
evpn
vni 10000 l2
route-target import auto ! în cadrul acestui articol folosim un număr automat pentru route-target
route-target export autoSă facem un ping de la Host-2 la Host-1:
Firewall2# ping 192.168.10.1
PING 192.168.10.1 (192.168.10.1): 56 data bytes
36 bytes de la 192.168.10.2: Host de destinație inaccesibil
Request 0 a expirat
64 bytes de la 192.168.10.1: icmp_seq=1 ttl=254 time=215.555 ms
64 bytes de la 192.168.10.1: icmp_seq=2 ttl=254 time=38.756 ms
64 bytes de la 192.168.10.1: icmp_seq=3 ttl=254 time=42.484 ms
64 bytes de la 192.168.10.1: icmp_seq=4 ttl=254 time=40.983 msIar mai jos, putem vedea că în tabela BGP au apărut route-type 2 cu adresele MAC ale gazdelor — 5001.0007.0007 și 5001.0008.0007
Leaf11# sh bgp l2vpn evpn
Rețea Nnext Hop Metric LocPrf Weight Path
Distincția rutei: 10.255.1.11:32777 (L2VNI 10000)
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]\/216 ! tip de rutare evpn 2 și adresa MAC a gazdei 1
10.255.1.10 100 32768 i
*>i[2]:[0]:[0]:[48]:[5001.0008.0007]:[0]:[0.0.0.0]\/216 ! tip de rutare evpn 2 și adresa MAC a gazdei 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
Distincția rutei: 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 iAici puteți vedea informații detaliate despre Update, în care am obținut informații despre MAC Host. Mai jos este prezentat rezultatul complet al comenzii
Leaf21# sh bgp l2vpn evpn 5001.0007.0007
Informații din tabelul de rutare BGP pentru VRF default, familia de adresă L2VPN EVPN
Distincția rutei: 10.255.1.11:32777 ! a trimis Update cu MAC Host. Nu este o adresă virtuală VPC, ci adresa Leaf
Intrare în tabelul de rutare BGP pentru [2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]\/216,
versiune 1507
Cărți: (2 disponibile, cea mai bună #2)
Steaguri: (0x000202) (high32 00000000) pe lista de transmisie, nu este în l2rib\/evpn, nu este în HW
Tipul de cale: intern, calea este valabilă, nu cea mai bună motiv: adresa vecinului, fără etichete nexthop
AS-Path: NIMIC, calea provine din intern către AS
10.255.1.10 (metrica 81) de la 10.255.1.102 (10.255.1.102) ! cu cine construim tunelul VxLAN
Origine IGP, MED nu este setat, localpref 100, greutate 0
Eticheta primită 10000 ! Numărul VNI asociat VLAN-ului în care se află gazda
Comunitate extinsă: RT:65001:10000 SOO:10.255.1.10:0 ENCAP:8 ! Aici putem vedea că RT s-a format automat pe baza numărului AS și VNI
Originator: 10.255.1.11 Lista clusterelor: 10.255.1.102Să vedem cum arată cadrele atunci când sunt transmise prin fabrică:
Suppress-ARP
Excelent, conexiunea L2 între gazde a fost realizată și aici s-ar putea încheia. Totuși, lucrurile nu sunt atât de simple. Deocamdată, având puține gazde, nu vor apărea probleme. Dar să ne imaginăm o situație în care avem sute sau mii de gazde. Ce problemă am putea întâlni?
Această problemă este traficul BUM (Broadcast, Unknown Unicast, Multicast). În acest articol vom analiza o variantă de combatere a traficului de broadcast.
Generatorul principal de Broadcast în rețelele Ethernet sunt gazdele prin protocolul ARP.
Pe nexus este implementat următorul mecanism pentru a combate solicitările ARP — suppress-arp.
Funcționarea acestei caracteristici este următoarea:
- Host-1 trimite o solicitare APR la adresa Broadcast a rețelei sale.
- Solicitarea ajunge la comutatorul Leaf și, în loc să transmită această solicitare mai departe în fabrică, spre gazda Host-2, Leaf răspunde singur și indică IP-ul și MAC-ul necesar.
Astfel, cererea Broadcast nu a ajuns la fabrică. Dar cum poate funcționa asta, dacă Leaf cunoaște doar adresa MAC?
Totul este destul de simplu, tipul de rută EVPN 2, pe lângă adresa MAC, poate transmite o asociere MAC/IP. Pentru aceasta, este necesar să configurăm o adresă IP în VLAN pe Leaf. Rămâne întrebarea: ce adresă IP să alegem? Pe Nexus există posibilitatea de a crea o adresă distribuită (identică) pe toate comutatoarele:
feature interface-vlan
fabric forwarding anycast-gateway-mac 0001.0001.0001 ! setăm MAC virtual pentru a crea un gateway distribuit între toate comutatoarele
interface Vlan10
no shutdown
ip address 192.168.10.254/24 ! setăm aceeași adresă IP pe toate Leaf
fabric forwarding mode anycast-gateway ! specificăm utilizarea MAC virtualAstfel, din perspectiva gazdelor, rețeaua va arăta astfel:
Să verificăm 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 iDin ieșirea comenzii, observăm că în tipul de rută EVPN 2, pe lângă MAC, vedem acum și adresa IP a gazdei.
Revenim la configurarea suppress-arp. Această setare se activează pentru fiecare VNI în parte:
interface nve1
member vni 10000
suppress-arpMai departe, apare o anumită complexitate:
- Pentru a funcționa această caracteristică, este necesar un spațiu în memoria TCAM. Voi da un exemplu de configurare pentru suppress-arp:
hardware access-list tcam region arp-ether 256Pentru această configurare va fi nevoie de double-wide. Adică, dacă specificați 256, atunci în TCAM trebuie să eliberați 512. Configurarea TCAM depășește limitele acestui articol, deoarece configurarea TCAM depinde doar de sarcina care vi s-a dat și poate varia de la o rețea la alta.
- Implementarea suppress-arp trebuie efectuată pe toate switch-urile Leaf. Totuși, complexitatea poate apărea la configurarea pe perechile Leaf care se află în domeniul VPC. Atunci când se schimbă TCAM, consistența între perechi va fi întreruptă, iar un nod poate fi scos din funcțiune. În plus, pentru aplicarea configurației în cazul modificării TCAM, poate fi necesară repornirea dispozitivului.
Prin urmare, este bine să te gândești cu atenție dacă, în situația ta, merită să implementezi această configurație pe o fabrică în funcțiune.
Aici încheiem prima parte a ciclului. În partea următoare, vom aborda rutarea prin fabrică VxLAN, cu separarea rețelelor pe diferite VRF.
Și acum invit pe toți la , în cadrul căruia voi explica detaliat despre curs. Primele 20 de apariții care se vor înregistra la acest webinar vor primi un certificat de discount pe e-mail în termen de 1-2 zile după transmisiune.
Sursa: habr.com
