Hei Habr. Continui seria de articole despre tehnologia VxLAN EVPN, care au fost scrise special pentru lansarea cursului de OTUS. Și astăzi vom lua în considerare o parte interesantă a sarcinilor - rutarea. Indiferent cât de banal ar suna, totuși, ca parte a muncii unei fabrici de rețea, totul nu poate fi atât de simplu.
În ultima parte, am realizat un domeniu de difuzare construit pe o țesătură de rețea pe un Nexus 9000v. Cu toate acestea, aceasta nu este întreaga gamă de sarcini care trebuie rezolvate în cadrul rețelei centrelor de date. Și astăzi vom lua în considerare următoarea sarcină - rutarea între rețele sau între VNI-uri.
Permiteți-mi să vă reamintesc că se folosește topologia Spine-Leaf:
Pentru început, vom analiza modul în care are loc rutarea și ce caracteristici are.
Pentru înțelegere, să simplificăm diagrama logică și să adăugăm un alt VNI 20000 pentru Host-2. Rezultatul este:
Cum, în acest caz, puteți transfera trafic de la o gazdă la alta?
Există două opțiuni:
- Păstrați informații despre toate VNI-urile pe toate comutatoarele Leaf, apoi toată rutarea va avea loc pe primul Leaf din rețea;
- Utilizați dedicat - L3 VNI
Prima modalitate este simplă și convenabilă. Deoarece trebuie doar să porniți toate VNI-urile pe toate comutatoarele Leaf. Cu toate acestea, rularea a câteva sute sau mii de VNI-uri pe întregul Leaf nu mai pare o sarcină ușoară. Prin urmare, în lucrare este folosit destul de rar.
Vom analiza metoda 2, ca fiind mai interesantă și ceva mai complicată, dar dând mai multă flexibilitate în configurarea fabricii.
Să adăugăm „PROD” la topologia VRF. Să îi adăugăm interfața vlan 10 pe perechea Leaf-11/12 și interfața VLAN 20 pe Leaf-21. VLAN 20 este asociat cu VNI 20000
vrf context PROD
rd auto ! Route Distinguisher не принципиален и можем использовать сформированный автоматически
address-family ipv4 unicast
route-target both auto ! указываем Route-target с которым будут импортироваться и экспортироваться префиксы в/из 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 utiliza L3VNI, trebuie să creați un nou VLAN, să îl asociați cu noul VNI. Noul VNI trebuie să fie același pentru toate Leaf-urile interesate de informațiile VLAN 10 și 20.
vlan 99
vn-segment 99000
interface nve1
member vni 99000 associate-vrf ! Создаем L3 VNI
vrf context PROD
vni 99000 ! Привязываем L3 VNI к определенному VRFCa rezultat, diagrama va arăta astfel:
Rămâne de terminat puțin - mai adaugă o interfață - interfața vlan 99 în VRF PROD
interface Vlan99
no shutdown
vrf member PROD
ip forward ! На интерфейсе не должно быть IP. Используется только для пересылки пакетов между LeafCa rezultat, logica trecerii cadrului de la Host-1 la Host-2 este următoarea:
- Un cadru trimis de Host-1 ajunge pe un Leaf în VLAN 10, care este asociat cu VNI 10000;
- Leaf verifică unde este adresa de destinație și o găsește prin L3 VNI pe al doilea comutator Leaf;
- De îndată ce este găsită ruta către adresa de destinație, Leaf-ul împachetează cadrul într-un antet cu L3VNI 99000 necesar - și îl trimite către a doua Leaf;
- Al doilea comutator Leaf primește date de la L3VNI 99000. Obține cadrul original și îl transferă la L2VNI 20000 necesar și apoi la VLAN 20.
Ca rezultat al acestei lucrări, L3VNI elimină necesitatea de a păstra informații despre toate VNI-urile care se află în rețea pe toate comutatoarele Leaf.
Ca rezultat, atunci când trimitem trafic de la Host-1 la Host-2, pachetul este împachetat în VxLAN cu noul VNI - 99000:
Rămâne de văzut cum exact Leaf-1 învață despre adresa MAC de la un alt VNI. Acest lucru se întâmplă și cu ajutorul rutei EVPN tip 2 (MAC / IP).
Următoarele arată procesul de propagare a unei rute despre un prefix situat într-un alt VNI:
Adică, adresele primite de la VNI 20000 au două RT-uri.
Permiteți-mi să vă reamintesc că rutele primite de la Update se încadrează în tabelul BGP cu Route-target specificat în setările VRF (procesul este ceva mai complicat, dar nu vom intra în acest articol).
RT-ul în sine este format prin formula: AS:VNI (dacă se utilizează modul automat).
Un exemplu de formare a RT în modurile automat și manual:
vrf context PROD
address-family ipv4 unicast
route-target import auto - автоматический режим работы
route-target export 65001:20000 - ручной режим формирования RTCa rezultat, puteți vedea mai sus că prefixele de la un alt VNI au două valori RT.
Unul dintre ele 65001:99000 este un VNI L3 suplimentar. Deoarece acest VNI este același pe toate frunzele și se încadrează în regulile noastre de import în setările VRF, prefixul intră în tabelul BGP, care poate fi văzut din rezultat:
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.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
Route Distinguisher: 10.255.1.21:32787
* i[2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.20]/272 ! Префикс полученный из VNI 20000
10.255.1.20 100 0 i
*>i 10.255.1.20 100 0 iDacă ne uităm mai atent la actualizarea primită, putem vedea că acest prefix are două RT-uri:
Leaf11# sh bgp l2vpn evpn 5001.0008.0007
BGP routing table information for VRF default, address family L2VPN EVPN
Route Distinguisher: 10.255.1.21:32787
BGP routing table entry for [2]:[0]:[0]:[48]:[5001.0008.0007]:[32]:[192.168.20.2
0]/272, version 5164
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 labeled nexthop
AS-Path: NONE, path sourced internal to AS
10.255.1.20 (metric 81) from 10.255.1.102 (10.255.1.102)
Origin IGP, MED not set, localpref 100, weight 0
Received label 20000 99000 ! Два label для работы VxLAN
Extcommunity: RT:65001:20000 RT:65001:99000 SOO:10.255.1.20:0 ENCAP:8 ! Два значения Route-target, на основе, которых добавили данный префикс
Router MAC:5001.0005.0007
Originator: 10.255.1.21 Cluster list: 10.255.1.102
<......>În tabelul de rutare de pe Leaf-1, puteți vedea ș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 ! Адрес Host-2
*via 10.255.1.20%default, [200/0], 01:20:20, bgp-65001, internal, tag 65001 ! Доступный через Leaf-2
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN ! Через VNI 99000Observați prefixul primar lipsă 192.168.20.0/24 din tabelul de rutare?
Așa e, el nu este acolo. Adică, Leaf-urile la distanță primesc informații numai despre gazdele care se află în rețeaua dvs. Și acesta este comportamentul corect. Mai sus, în toate actualizările, puteți vedea că informațiile vin cu conținutul MAC / IP. Nu există prefixe de care să vorbim.
Acesta este protocolul Host Mobility Manager (HMM), care completează tabelul ARP din care este completat în continuare tabelul BGP (vom omite acest proces în cadrul acestui articol). Pe baza informațiilor primite de la HMM, se formează EVPN-uri de tip rută 2 (transmise prin MAC/IP).
Cu toate acestea, ce se întâmplă dacă este nevoie să transmiteți informații despre un prefix?
Pentru acest tip de informații, există EVPN ruta-tip 5 - vă permite să trimiteți prefixe prin adresa-familie l2vpn evpn (acest tip de rută la momentul scrierii acestui articol este doar în versiunea schiță , din această cauză, diferiți producători pot avea un comportament diferit al acestui tip de rută)
Pentru a transfera prefixe, este necesar să adăugați prefixe în procesul BGP pentru VRF, care vor fi anunțate:
router bgp 65001
vrf PROD
address-family ipv4 unicast
redistribute direct route-map VNI20000 ! В данном случае анонсируем префиксы подключение непосредственно к Leaf в VNI 20000
route-map VNI20000 permit 10
match ip address prefix-list VNI20000_OUT ! Указываем какой использовать prefix-list
ip prefix-list VNI20000_OUT seq 5 permit 192.168.20.0/24 ! Указываем какие сети будут попадать в EVPN route-type 5Ca urmare, Actualizarea va fi:
Să ne uităm la tabelul BGP. Pe lângă ruta de tip EVPN 2,3, au apărut rute de tip 5 care conțin informații despre numărul de rețea:
<......>
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 с номером префикса
10.255.1.10 0 100 0 ?
* i
<.......> Prefixul a apărut și în tabelul de rutare:
Leaf21# sh ip ro vrf PROD
192.168.10.0/24, ubest/mbest: 1/0
*via 10.255.1.10%default, [200/0], 00:14:32, bgp-65001, internal, tag 65001 ! Удаленный префикс, доступный через Leaf1/2(адрес Next-hop = virtual IP между парой VPC)
(evpn) segid: 99000 tunnelid: 0xaff010a encap: VXLAN ! Префикс доступен через L3VNI 99000
192.168.10.10/32, ubest/mbest: 1/0
*via 10.255.1.10%default, [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, hmmAceasta se încheie a doua parte a unei serii de articole despre VxLAN EVPN. În partea următoare, vom lua în considerare diferite opțiuni de rutare între VRF-uri.
Sursa: www.habr.com