ProHoster > Блог > Administracija > VxLAN fabrika. Dio 3

VxLAN fabrika. Dio 3

Zdravo, Habr. Završavam seriju članaka, posvećen pokretanju kursa "mrežni inženjer" od OTUS, koristeći VxLAN EVPN tehnologiju za rutiranje unutar strukture i korištenje Firewall-a za ograničavanje pristupa između internih usluga

VxLAN fabrika. Dio 3

Prethodne dijelove serijala možete pronaći na sljedećim linkovima:

Danas ćemo nastaviti da proučavamo logiku rutiranja unutar VxLAN tkanine. U prethodnom dijelu, pogledali smo intra-fabric rutiranje unutar jednog VRF-a. Međutim, može postojati ogroman broj klijentskih usluga u mreži i svi oni moraju biti raspoređeni u različite VRF-ove kako bi se razlikovao pristup između njih. Pored razdvajanja mreže, preduzeće će možda morati da poveže zaštitni zid da ograniči pristup između ovih usluga. Da, ovo se ne može nazvati najboljim rješenjem, ali moderna realnost zahtijeva „moderna rješenja“.

Razmotrimo dvije opcije za rutiranje između VRF-ova:

  1. Rutiranje bez napuštanja VxLAN tkanine;
  2. Rutiranje na vanjskoj opremi.

Počnimo s logikom rutiranja između VRF-ova. Postoji određeni broj VRF-ova. Za rutiranje između VRF-ova potrebno je odabrati uređaj u mreži koji će znati za sve VRF-ove (ili dijelove između kojih je potrebno rutiranje). Takav uređaj može biti, na primjer, jedan od Leaf prekidača (ili sve odjednom) . Ova topologija će izgledati ovako:

VxLAN fabrika. Dio 3

Koji su nedostaci ove topologije?

Tako je, svaki Leaf mora znati o svim VRF-ovima (i svim informacijama koje se nalaze u njima) na mreži, što dovodi do gubitka memorije i povećanog opterećenja mreže. Uostalom, često svaki Leaf prekidač ne mora znati o svemu što je na mreži.

Međutim, razmotrimo ovu metodu detaljnije, jer je za male mreže ova opcija sasvim prikladna (ako nema posebnih poslovnih zahtjeva)

U ovom trenutku možete imati pitanje kako prenijeti informacije sa VRF na VRF, jer je poenta ove tehnologije upravo u tome da se širenje informacija ograniči.

A odgovor leži u funkcijama kao što su izvoz i uvoz informacija o rutiranju (podešavanje ove tehnologije je razmatrano u drugi dijelovi ciklusa). Dozvolite mi da ukratko ponovim:

Kada postavljate VRF u AF, morate odrediti route-target za informacije o rutiranju uvoza i izvoza. Možete ga odrediti automatski. Tada će vrijednost uključivati ​​ASN BGP i L3 VNI pridružene VRF-u. Ovo je zgodno kada imate samo jedan ASN u svojoj fabrici: 

vrf context PROD20
  address-family ipv4 unicast
    route-target export auto      ! В автоматическом режиме экспортируется RT-65001:99000
    route-target import auto

Međutim, ako imate više od jednog ASN-a i trebate prenijeti rute između njih, tada će ručna konfiguracija biti praktičnija i skalabilnija opcija route-target. Preporuka za ručno podešavanje je prvi broj, koristite onaj koji vam odgovara, npr. 9999.
Drugi bi trebao biti postavljen na jednak VNI za taj VRF.

Konfigurirajmo ga na sljedeći način:

vrf context PROD10
  address-family ipv4 unicast
    route-target export 9999:99000          
    route-target import 9999:99000
    route-target import 9999:77000         ! Пример 1 import из другого VRF
    route-target import 9999:88000         ! Пример 2 import из другого VRF

Kako to izgleda u tabeli rutiranja:

Leaf11# sh ip route vrf prod
<.....>
192.168.20.0/24, ubest/mbest: 1/0
    *via 10.255.1.20%default, [200/0], 00:24:45, bgp-65001, internal, tag 65001
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN          ! префикс доступен через L3VNI 99000

Razmotrimo drugu opciju za rutiranje između VRF-ova - preko vanjske opreme, na primjer Firewall-a.

Postoji nekoliko opcija za rad preko vanjskog uređaja:

  1. Uređaj zna šta je VxLAN i možemo ga dodati u deo tkanine;
  2. Uređaj ne zna ništa o VxLAN-u.

Nećemo se zadržavati na prvoj opciji, budući da će logika biti skoro ista kao što je prikazano gore - dovodimo sve VRF-ove u Firewall i na njemu konfiguriramo rutiranje između VRF-ova.

Razmotrimo drugu opciju, kada naš Firewall ne zna ništa o VxLAN-u (sada se, naravno, pojavljuje oprema sa VxLAN podrškom. Na primjer, Checkpoint je najavio svoju podršku u verziji R81. O tome možete pročitati ovdje, međutim, sve je to u fazi testiranja i nema povjerenja u stabilnost rada).

Prilikom povezivanja eksternog uređaja dobijamo sljedeći dijagram:

VxLAN fabrika. Dio 3

Kao što možete vidjeti iz dijagrama, usko grlo se pojavljuje na interfejsu sa zaštitnim zidom. Ovo se mora uzeti u obzir u budućnosti prilikom planiranja mreže i optimizacije mrežnog saobraćaja.

Međutim, vratimo se izvornom problemu rutiranja između VRF-ova. Kao rezultat dodavanja Firewall-a, dolazimo do zaključka da Firewall mora znati za sve VRF-ove. Da biste to učinili, svi VRF-ovi također moraju biti konfigurirani na graničnim listovima, a zaštitni zid mora biti povezan sa svakim VRF-om sa zasebnom vezom.

Kao rezultat, shema sa Firewall-om:

VxLAN fabrika. Dio 3

To jest, na Firewall-u morate konfigurirati interfejs za svaki VRF koji se nalazi na mreži. Općenito, logika ne izgleda komplikovano i jedino što mi se ovdje ne sviđa je ogroman broj interfejsa na Firewall-u, ali ovdje je vrijeme da razmislite o automatizaciji.

U redu. Povezali smo zaštitni zid i dodali ga svim VRF-ovima. Ali kako sada možemo natjerati promet sa svakog lista da prođe kroz ovaj zaštitni zid?

Na Leaf-u spojenom na Firewall neće se pojaviti nikakvi problemi, jer su sve rute lokalne:

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.254.13.55, [1/0], 6w5d, static       ! маршрут по-умолчанию через Firewall

Međutim, šta je sa udaljenim Leafsima? Kako im proći zadanu eksternu rutu?

Tako je, preko EVPN rute tipa 5, kao i svaki drugi prefiks preko VxLAN tkanine. Međutim, to nije tako jednostavno (ako govorimo o Cisco-u, jer nisam provjerio kod drugih dobavljača)

Zadana ruta mora biti oglašena sa lista na koji je povezan zaštitni zid. Međutim, da bi prenio rutu, Leaf je mora sam znati. I tu nastaje određeni problem (možda samo za mene), ruta mora biti statički registrirana u VRF-u gdje želite reklamirati takvu rutu:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

Zatim, u BGP konfiguraciji, postavite ovu rutu u AF IPv4:

router bgp 65001
    vrf prod
        address-family ipv4 unicast
            network 0.0.0.0/0

Međutim, to nije sve. Na ovaj način zadana ruta neće biti uključena u porodicu l2vpn evpn. Pored ovoga, potrebno je konfigurirati redistribuciju:

router bgp 65001
    vrf prod
        address-family ipv4 unicast
            network 0.0.0.0/0
            redistribute static route-map COMMON_OUT

Naznačavamo koji će prefiksi ući u BGP putem redistribucije

route-map COMMON_OUT permit 10
  match ip address prefix-list COMMON_OUT

ip prefix-list COMMON_OUT seq 10 permit 0.0.0.0/0

Sada prefiks 0.0.0.0/0 spada u EVPN rutu tipa 5 i prenosi se na ostatak Leaf-a:

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.255.1.5%default, [200/0], 5w6d, bgp-65001, internal, tag 65001, segid: 99000 tunnelid: 0xaff0105 encap: VXLAN
    ! 10.255.1.5 - Виртуальный адрес Leaf(так как Leaf выступают в качестве VPС пары), к которому подключен Firewall

U BGP tabeli takođe možemo posmatrati rezultujuću rutu tipa 5 sa podrazumevanom rutom preko 10.255.1.5:

* i[5]:[0]:[0]:[0]:[0.0.0.0]/224
                      10.255.1.5                        100          0 i
*>i                   10.255.1.5                        100          0 i

Ovim je završena serija članaka posvećenih EVPN-u. U budućnosti ću pokušati da razmotrim rad VxLAN-a u kombinaciji sa Multicast-om, jer se ovaj metod smatra skalabilnijim (trenutno kontroverzna izjava)

Ako i dalje imate pitanja/sugestija o ovoj temi, razmotrite bilo koju funkcionalnost EVPN-a - pišite, mi ćemo to dalje razmotriti.

VxLAN fabrika. Dio 3

izvor: www.habr.com

Dodajte komentar