Bună, Habr. Continuăm ciclul de articole despre tehnologia VxLAN EVPN, care au fost scrise special pentru lansarea cursului de la OTUS. Și astăzi vom analiza o parte interesantă a problemelor — rutarea. Cât de banal ar suna, totuși, în cadrul funcționării unei fabrici de rețea, totul poate fi mai complicat decât pare.
În partea anterioară, am obținut un domeniu de broadcast construit pe o fabrică de rețea pe Nexus 9000v. Totuși, aceasta nu este întreaga gamă de probleme care trebuie rezolvate în rețeaua centrului de date. Astăzi vom examina următoarea problemă — rutarea între rețele sau între VNI.
Reamintesc că se folosește topologia Spine-Leaf:
Mai întâi, să analizăm cum se desfășoară rutarea și ce caracteristici există.
Pentru a înțelege, vom simplifica schema logică și vom adăuga un alt VNI 20000 pentru Host-2. Rezultatul va fi:
Cum se poate transmite traficul de la un Host la altul în acest caz?
Există două opțiuni:
- Pe toate switch-urile Leaf să păstreze informații despre toate VNI, astfel încât toată rutarea să aibă loc la primul Leaf din rețea;
- Să folosim un VNI L3 dedicat
Prima opțiune este simplă și convenabilă. Deoarece este nevoie doar să introducem toate VNI pe toate switch-urile Leaf. Totuși, să introducem câteva sute sau mii de VNI pe toate Leaf-uri nu mai pare o sarcină simplă. Prin urmare, în practică, aceasta este utilizată destul de rar.
Vom analiza a doua opțiune, care este mai interesantă și puțin mai complicată, dar oferă o flexibilitate mai mare în configurarea fabricii.
Vom adăuga în topologie VRF "PROD". În aceasta vom adăuga interface vlan 10 pe perechea Leaf-11/12 și interface VLAN 20 pe Leaf-21. VLAN 20 este asociat cu VNI 20000
vrf context PROD
rd auto ! Route Distinguisher nu este esențial și putem folosi unul generat automat
address-family ipv4 unicast
route-target both auto ! specificăm Route-target cu care vor fi importate și exportate prefixele din/in VRF
vlan 20
vn-segment 20000
interface nve 1
member vni 20000
ingress-replication protocol bgp
interface Vlan10
no shutdown
vrf member PROD
ip address 192.168.20.1/24
fabric forwarding mode anycast-gatewayPentru a folosi L3VNI, este necesar să creăm un VLAN nou, asociindu-l cu un nou VNI. Noua VNI trebuie să fie identică pe toate Leaf-urile care sunt interesate de informațiile despre VLAN 10 și 20
vlan 99
vn-segment 99000
interface nve1
member vni 99000 associate-vrf ! Creăm L3 VNI
vrf context PROD
vni 99000 ! Legăm L3 VNI de un anumit VRFÎn rezultat, schema va fi prezentată astfel:
A mai este puțin de lucrat — adaugă o interfață suplimentară — interface vlan 99 în VRF PROD
interface Vlan99
no shutdown
vrf member PROD
ip forward ! Interfața nu ar trebui să aibă IP. Este folosită doar pentru transportul pachetelor între LeafÎn concluzie, logica de trecere a cadrelor de la Host-1 la Host-2 este următoarea:
- Cadrele trimise de Host-1 ajung la Leaf în VLAN 10, care este asociat cu VNI 10000;
- Leaf verifică unde se află adresa destinației și o găsește prin L3 VNI pe cel de-al doilea switch Leaf;
- Odată ce rutele către adresa destinației sunt găsite, Leaf împachetează cadrul în antet cu necesarul L3VNI 99000 — și îl trimite spre al doilea Leaf;
- Cel de-al doilea switch Leaf primește datele din L3VNI 99000. Extrage cadrul inițial și îl mută în necesarul L2VNI 20000 și mai departe în VLAN 20.
Rezultatul unei astfel de funcționări L3VNI elimină necesitatea de a păstra informații despre toate VNI-urile pe toate switch-urile Leaf.
În concluzie, atunci când trimitem trafic de la Host-1 la Host-2, pachetul este împachetat în VxLAN cu un nou VNI — 99000:
Rămâne să înțelegem cum anume Leaf-1 află despre adresa MAC din alt VNI. Acest lucru se întâmplă tot cu ajutorul EVPN route-type 2 (MAC/IP).
Mai jos este prezentat procesul de răspândire a rutei pentru prefixul aflat într-un alt VNI:
Adică adresele obținute din VNI 20000 au două RT.
Reamintesc că rutele obținute din Update ajung în tabela BGP cu Route-target, specificat în setările VRF (procesul este puțin mai complex, dar în cadrul acestui articol nu ne vom aprofunda).
RT-ul se formează conform formulei: AS:VNI (dacă se folosește modul automat).
Exemplu de formare a RT în mod automat și manual:
vrf context PROD
address-family ipv4 unicast
route-target import auto - modul automat de funcționare
route-target export 65001:20000 - modul manual de formare RTAstfel, este evident că prefixele din alt VNI au două valori RT.
Una dintre ele este 65001:99000 — un L3 VNI suplimentar. Deoarece acest VNI este identic pe toate Leaf și se încadrează în regulile noastre de import în setările VRF — prefixul ajunge în tabela BGP, lucru pe care îl putem observa din ieșirea:
sh bgp l2vpn evpn
Rețea Next Hop Metric LocPrf Weight Path
Identificator Ruta: 10.255.1.11:32777 (L2VNI 10000)
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[0]:[0.0.0.0]\/216
10.255.1.10 100 32768 i
*>l[2]:[0]:[0]:[48]:[5001.0007.0007]:[32]:[192.168.10.10]\/272
10.255.1.10 100 32768 i
*>l[3]:[0]:[32]:[10.255.1.10]\/88
10.255.1.10 100 32768 i
Identificator Ruta: 10.255.1.21:32787
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.20]\/272 ! Prefix obținut din VNI 20000
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 iDacă ne uităm mai atent la update-ul obținut, observăm că acest prefix are două RT:
Leaf11# sh bgp l2vpn evpn 5001.0008.0007
Informații despre tabelul de rutare BGP pentru VRF default, familie de adrese L2VPN EVPN
Identificator Ruta: 10.255.1.21:32787
Intrare în tabelul de rutare BGP pentru [2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.20]\/272, versiune 5164
Cărți: (2 disponibile, cel mai bun #2)
Flăcări: (0x000202) (high32 00000000) pe lista xmit, nu este în l2rib\/evpn, nu este în HW
Tipul căii: intern, calea este validă, nu cea mai bună motiv: Adresa vecinului, fără nexthop etichetat
AS-Path: NIMIC, calea provine intern din AS
10.255.1.20 (metric 81) de la 10.255.1.102 (10.255.1.102)
Origine IGP, MED nesetată, localpref 100, weight 0
Etichetă primită 20000 99000 ! Două etichete pentru funcționarea VxLAN
Extcommunity: RT:65001:20000 RT:65001:99000 SOO:10.255.1.20:0 ENCAP:8 ! Două valori Route-target, pe baza cărora s-a adăugat acest prefix
Router MAC:5001.0005.0007
Originator: 10.255.1.21 Lista cluster: 10.255.1.102În tabela de rutare de pe Leaf-1 se poate observa și prefixul 192.168.20.20\/32:
Leaf11# sh ip route vrf PROD
192.168.10.0/24, ubest/mbest: 1/0, attached
*via 192.168.10.1, Vlan10, [0/0], 01:29:28, direct
192.168.10.1/32, ubest/mbest: 1/0, attached
*via 192.168.10.1, Vlan10, [0/0], 01:29:28, local
192.168.10.10/32, ubest/mbest: 1/0, attached
*via 192.168.10.10, Vlan10, [190/0], 01:27:22, hmm
192.168.20.20/32, ubest/mbest: 1/0 ! Adresa Host-2
*via 10.255.1.20fault, [200/0], 01:20:20, bgp-65001, internal, tag 65001 ! Accesibil prin Leaf-2
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN ! Prin VNI 99000Ați observat absența principalului prefix 192.168.20.0\/24 în tabela de rutare?
Exact, nu este acolo. Aceasta înseamnă că foile îndepărtate primesc informații doar despre gazdele care există în reteaua dvs. Și acesta este un comportament corect. În toate update-urile de mai sus se poate observa că informațiile vin cu conținut MAC\/IP. Nu se discută despre niciun prefix.
Funcționează protocolul Host Mobility Manager (HMM), care completează tabela ARP din care ulterior se completează tabela BGP (în cadrul acestui articol vom sări acest proces). Pe baza informațiilor obținute din HMM se formează rutele EVPN de tip 2 (se transmite MAC\/IP).
Cu toate acestea, ce este de făcut dacă există nevoie să transmitem informații despre un anumit prefix?
Pentru acest tip de informație există tipul de rutare EVPN 5 — permite transmiterea prefixelor prin address-family l2vpn evpn (acest tip de rute este, în momentul scrierii acestui articol, doar în versiune draft , din această cauză comportamentul acestui tip de rută poate varia între diferiți producători)
Pentru a transmite prefixe, este necesar să adăugăm prefixele care vor fi anunțate în procesul BGP pentru VRF:
router bgp 65001
vrf PROD
address-family ipv4 unicast
redistribute direct route-map VNI20000 ! În acest caz, anunțăm prefixele conectării direct la Leaf în VNI 20000
route-map VNI20000 permit 10
match ip address prefix-list VNI20000_OUT ! Specificăm ce prefix-list să folosim
ip prefix-list VNI20000_OUT seq 5 permit 192.168.20.0/24 ! Specificăm ce rețele vor fi incluse în EVPN route-type 5În concluzie, în Update va fi:
Să ne uităm la tabela BGP. Pe lângă rutele EVPN de tip 2,3 au apărut și rute de tip 5, care conțin informații despre numărul rețelei:
Network Next Hop Metric LocPrf Weight Path
Route Distinguisher: 10.255.1.11:3
* i[5]:[0]:[0]:[24]:[192.168.10.0]/224
10.255.1.10 0 100 0 ?
*>i 10.255.1.10 0 100 0 ?
Route Distinguisher: 10.255.1.11:32777
* i[2]:[0]:[0]:[48]:[5001.0007.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.0007.0007]:[32]:[192.168.10.10]/272
10.255.1.10 100 0 i
*>i 10.255.1.10 100 0 i
* i[3]:[0]:[32]:[10.255.1.10]/88
10.255.1.10 100 0 i
*>i 10.255.1.10 100 0 i
Route Distinguisher: 10.255.1.12:3
*>i[5]:[0]:[0]:[24]:[192.168.10.0]/224 ! EVPN route-type 5 cu numărul prefixului
10.255.1.10 0 100 0 ?
* i În tabela de rutare, prefixul a apărut de asemenea:
Leaf21# sh ip ro vrf PROD
192.168.10.0/24, ubest/mbest: 1/0
*via 10.255.1.10fault, [200/0], 00:14:32, bgp-65001, internal, tag 65001 ! Prefix îndepărtat disponibil prin Leaf1/2 (adresa Next-hop = IP virtual între perechea VPC)
(evpn) segid: 99000 tunnelid: 0xaff010a encap: VXLAN ! Prefix disponibil prin L3VNI 99000
192.168.10.10/32, ubest/mbest: 1/0
*via 10.255.1.10fault, [200/0], 02:33:40, bgp-65001, internal, tag 65001
(evpn) segid: 99000 tunnelid: 0xaff010a encap: VXLAN
192.168.20.0/24, ubest/mbest: 1/0, attached
*via 192.168.20.1, Vlan20, [0/0], 02:39:44, direct
192.168.20.1/32, ubest/mbest: 1/0, attached
*via 192.168.20.1, Vlan20, [0/0], 02:39:44, local
192.168.20.20/32, ubest/mbest: 1/0, attached
*via 192.168.20.20, Vlan20, [190/0], 02:35:46, hmmAici încheiem a doua parte a ciclului de articole despre VxLAN EVPN. În următoarea parte vom analiza diferite opțiuni de rutare între VRF.
Sursa: habr.com
