VxLAN fabrika. Deo 3

Pozdravljen, Habr. Končujem cikel člankov, posvečenih zagonu tečaja "Omrežni inženir" od OTUS, o tehnologiji VxLAN EVPN za usmerjanje znotraj tovarne in uporabi požarnega zidu za omejevanje dostopa med notranjimi storitvami

Prejšnje dele cikla lahko najdete po povezavah:

• 1. del cikla — L2 povezanost med strežniki
• 2. del cikla — Usmerjanje med VNI
• 2.5. del cikla — Teoretično odstopanje

Danes bomo nadaljevali z raziskovanjem logike usmerjanja znotraj tovarne VxLAN. V prejšnjem delu smo obravnavali usmerjanje znotraj tovarne znotraj enega VRF. Vendar pa je v omrežju lahko ogromno storitev-strank, in vse je treba razporediti v različne VRF, da se omeji dostop med njimi. Poleg mrežnega razmejevanja ima lahko podjetje potrebo po povezovanju požarnega zidu, da omeji dostop med temi storitvami. Da, tega ne moremo imenovati najboljša rešitev, toda sodobne realnosti zahtevajo 'sodobne rešitve'.

Oglejmo si dve možnosti usmerjanja med VRF:

1. Usmerjanje, brez izhoda iz tovarne VxLAN;
2. Usmerjanje na zunanjih napravah.

Začnimo z logiko usmerjanja med VRF. Obstaja določeno število VRF. Da bi usmerjali med VRF, je potrebno določiti napravo v omrežju, ki bo poznala vse VRF (ali del, med katerima je potrebno usmerjanje). Takšna naprava je lahko, na primer, enega od Leaf stikal (ali pa vsa hkrati). Takšna topologija bi izgledala tako:

Kakšne pomanjkljivosti ima takšna topologija?

Prav imate, vsak Leaf mora poznati vse VRF (in vse informacije, ki jih vsebujejo) v omrežju, kar vodi do izgube pomnilnika in povečuje obremenitev omrežja. Konec koncev, vsakemu Leaf switchu pogosto ni treba poznati vsega, kar je v omrežju.

Vendar pa si poglejmo to metodo podrobneje, saj je za majhna omrežja ta možnost povsem primerna (če ni posebnih poslovnih zahtev)

Na tem mestu se vam lahko postavi vprašanje, kako prenašati informacije iz VRF v VRF, saj je bistvo te tehnologije prav to, da mora biti širjenje informacij omejeno.

In odgovor se skriva v funkcijah, kot so izvoz in uvoz usmerjalnih informacij (nastavitev te tehnologije smo obravnavali v drugi delu cikla). Na kratko ponovim:

Pri določitvi VRF v AF je potrebno navesti route-target za uvoz i izvoz informacijskih ruta. Može se postaviti u automatskom režimu. Tada će se kao vrednost ući ASN BGP i L3 VNI vezan za VRF. Ovo je zgodno kada imate samo jedan ASN u fabrici:

vrf kontekst PROD20
  adresa-familija ipv4 unicast
    ruta-target izvoz auto      ! U automatskom režimu izvozi se RT-65001:99000
    ruta-target uvoz auto

Međutim, ako imate više od jednog ASN i potrebno je prebacivanje ruta između njih, ručna konfiguracija će biti prikladnija i skalabilnija. route-target. Preporuka za ručnu konfiguraciju — prvo broj, koristite onaj koji vam odgovara, na primer, 9999.
Drugo, treba ga postaviti na VNI za ovaj VRF.

Postavićemo na sledeći način:

vrf kontekst PROD10
  adresa-familija ipv4 unicast
    ruta-target izvoz 9999:99000          
    ruta-target uvoz 9999:99000
    ruta-target uvoz 9999:77000         ! Primer 1 uvoz iz drugog VRF
    ruta-target uvoz 9999:88000         ! Primer 2 uvoz iz drugog VRF

Kako to izgleda u tabeli ruta:

Leaf11# sh ip route vrf prod

192.168.20.0/24, ubest/mbest: 1/0
 *putem 10.255.1.20fault, [200/0], 00:24:45, bgp-65001, interno, oznaka 65001
(evpn) segid: 99000 tunnelid: 0xaff0114 enkapsulacija: VXLAN ! prefiks dostupan kroz L3VNI 99000

Razmotrićemo drugu opciju routiranja između VRF — kroz eksternu opremu, na primer, Firewall.

Može se pretpostaviti nekoliko opcija rada preko spoljnog uređaja:

1. Uređaj zna šta je VxLAN i možemo ga uključiti u deo fabrike;
2. Uređaj ne zna ništa o VxLAN.

Na prvoj opciji nećemo se zaustaviti, jer će logika biti gotovo ista kao što je prikazano gore — dovodimo sve VRF do Firewall-a i na njemu podešavamo rutiranje između VRF.

Razmotrićemo drugu opciju, kada naš Firewall ne zna ništa o VxLAN (Naravno, sada se pojavljuje oprema koja podržava VxLAN. Na primer, Checkpoint je najavio njegovu podršku u verziji R81. O tome možete pročitati tukaj, međutim, sve je to još u fazi testiranja i nema garancije u stabilnost rada).

Kada se poveže eksterni uređaj, dobijamo sledeću shemu:

Kao što se može videti na shemi — pojavljuje se usko mesto na spoju sa Firewall-om. Moramo to uzeti u obzir prilikom planiranja mreže i optimizacije mrežnog saobraćaja.

Međutim, vratimo se na prvobitni zadatak rutiranja između VRF. Kao rezultat dodavanja Firewall-a, dolazimo do toga da Firewall mora znati o svim VRF. Da bi to bilo moguće, na graničnim Leaf-ovima takođe moraju biti podešeni svi VRF, a Firewall povezan u svaki VRF odvojenim linijskim putem.

Zaradi tega shema s požarnim zidom:

To pomeni, da je na požarnem zidu potrebno nastaviti vmesnik v vsak VRF, ki se nahaja v omrežju. Na splošno logika ni zapletena, edina stvar, ki bi lahko bila moteča, je ogromno število vmesnikov na požarnem zidu, vendar je morda sedaj čas za razmislek o avtomatizaciji.

V redu. Povezali smo požarni zid, dodali smo ga v vse VRF. Kaj pa zdaj, kako prisiliti promet z vsakega Leaf-a, da gre preko tega požarnega zida?

Na Leaf-u, povezanem na požarni zid, ne bo nobenih težav, saj so vse poti lokalne:

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.254.13.55, [1/0], 6w5d, static       ! privzeta pot preko požarnega zida

Kako pa z oddaljenimi Leaf-i? Kako jim posredovati zunanjo privzeto pot?

Pravilno, preko EVPN route-type 5, kot vsak drug prefiks po VxLAN tovarni. Vendar pa to ni tako preprosto (če govorimo o cisco, pri drugih dobaviteljih tega nisem preverjal)

Privzeto pot je treba oglasiti z Leaf-om, ki je povezan na požarni zid. Vendar, da bi pot prenesel, mora Leaf to pot poznati. In tukaj nastane nek problem (morda le pri meni), pot je potrebno zapisati statično v tistem VRF, kjer želite oglasiti to pot:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

Nato v nastavitvi BGP določite to pot v AF IPv4:

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

Vendar to še ni vse. Tako privzeta pot ne bo prišla v družino l2vpn evpn. Poleg tega je potrebno nastaviti redistribucijo:

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

Določimo, kateri prefiksi bodo prišli v BGP preko 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

Zdaj prefiks 0.0.0.0/0 pride v EVPN route-type 5 in se posreduje ostalim Leaf-om:

0.0.0.0/0, ubest/mbest: 1/0
 *via 10.255.1.5fault, [200/0], 5w6d, bgp-65001, internal, tag 65001, segid: 99000 tunnelid: 0xaff0105 encap: VXLAN
 ! 10.255.1.5 - Virtualni naslov Leaf-a (ker Leaf-i delujejo kot VPS par), na katerega je povezan požarni zid

V tabeli BGP lahko tudi opazimo prejeti route-type 5 s privzeto potjo 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

Tukaj zaključujemo cikel člankov, posvečenih EVPN. V prihodnje bom skušal obravnavati delovanje VxLAN v povezavi s Multicast, saj se ta način šteje za bolj razširljiv (trenutno sporno trditev).

Če imate še vedno vprašanja/predloge glede funkcionalnosti EVPN, mi pišite, dodatno bomo preučili.

Izvor: habr.com