ProHoster > Blog > Uprava > Tovarna VxLAN. 3. del

Tovarna VxLAN. 3. del

Pozdravljeni, Habr. Končujem serijo člankov, posvečen uvedbi tečaja "Omrežni inženir" od OTUS, z uporabo tehnologije VxLAN EVPN za usmerjanje znotraj tkanine in uporabo požarnega zidu za omejevanje dostopa med notranjimi storitvami

Tovarna VxLAN. 3. del

Prejšnje dele serije lahko najdete na naslednjih povezavah:

Danes bomo nadaljevali s preučevanjem usmerjevalne logike znotraj strukture VxLAN. V prejšnjem delu smo si ogledali usmerjanje znotraj sklopa znotraj enega VRF. Vendar pa je lahko v omrežju ogromno odjemalskih storitev in vse morajo biti porazdeljene v različne VRF-je, da se med njimi razlikuje dostop. Poleg ločevanja omrežja bo podjetje morda moralo povezati požarni zid, da omeji dostop med temi storitvami. Da, tega ne moremo imenovati najboljša rešitev, vendar sodobne realnosti zahtevajo "sodobne rešitve".

Razmislimo o dveh možnostih za usmerjanje med VRF-ji:

  1. Usmerjanje brez zapuščanja strukture VxLAN;
  2. Usmerjanje na zunanji opremi.

Začnimo z logiko usmerjanja med VRF-ji. Obstaja določeno število VRF. Za usmerjanje med VRF-ji morate v omrežju izbrati napravo, ki bo poznala vse VRF-je (ali dele, med katerimi je potrebno usmerjanje). Takšna naprava je lahko na primer eno od stikal Leaf (ali vsa naenkrat) . Ta topologija bo videti takole:

Tovarna VxLAN. 3. del

Kakšne so slabosti te topologije?

Tako je, vsak Leaf mora vedeti za vse VRF-je (in vse informacije, ki so v njih) v omrežju, kar vodi do izgube pomnilnika in povečane obremenitve omrežja. Navsezadnje pogosto vsakemu stikalu Leaf ni treba vedeti o vsem, kar je v omrežju.

Vendar pa razmislimo o tej metodi podrobneje, saj je za majhna omrežja ta možnost zelo primerna (če ni posebnih poslovnih zahtev)

Na tej točki se lahko pojavi vprašanje, kako prenesti informacije iz VRF v VRF, saj je smisel te tehnologije ravno v tem, da mora biti razširjanje informacij omejeno.

In odgovor je v funkcijah, kot sta izvoz in uvoz informacij o usmerjanju (nastavitev te tehnologije je bila obravnavana v 2. deli cikla). Naj na kratko ponovim:

Ko nastavljate VRF v AF, morate določiti route-target za informacije o poti uvoza in izvoza. Določite ga lahko samodejno. Potem bo vrednost vključevala ASN BGP in L3 VNI, povezana z VRF. To je priročno, če imate v tovarni samo en ASN: 

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

Vendar, če imate več kot en ASN in morate prenašati poti med njimi, bo ročna konfiguracija bolj priročna in razširljiva možnost route-target. Priporočilo za ročno nastavitev je prva številka, uporabite tisto, ki vam ustreza, npr. 9999.
Drugi mora biti nastavljen tako, da je enak VNI za ta VRF.

Konfigurirajmo ga na naslednji 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 je videti v usmerjevalni tabeli:

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

Razmislimo o drugi možnosti za usmerjanje med VRF - prek zunanje opreme, na primer požarnega zidu.

Obstaja več možnosti za delo prek zunanje naprave:

  1. Naprava ve, kaj je VxLAN, in jo lahko dodamo v del tkanine;
  2. Naprava ne ve ničesar o VxLAN.

Ne bomo se zadrževali pri prvi možnosti, saj bo logika skoraj enaka kot je prikazana zgoraj - vse VRF-je pripeljemo na požarni zid in na njem konfiguriramo usmerjanje med VRF-ji.

Razmislimo o drugi možnosti, ko naš požarni zid ne ve ničesar o VxLAN (zdaj se seveda pojavlja oprema s podporo za VxLAN. Na primer, Checkpoint je svojo podporo napovedal v različici R81. O tem lahko preberete tukaj, vendar je to vse v fazi testiranja in ni zaupanja v stabilnost delovanja).

Pri priključitvi zunanje naprave dobimo naslednji diagram:

Tovarna VxLAN. 3. del

Kot je razvidno iz diagrama, se pojavi ozko grlo na vmesniku s požarnim zidom. To je treba v prihodnje upoštevati pri načrtovanju omrežja in optimizaciji omrežnega prometa.

Vendar se vrnimo k prvotnemu problemu usmerjanja med VRF-ji. Kot rezultat dodajanja požarnega zidu pridemo do zaključka, da mora požarni zid poznati vse VRF-je. Če želite to narediti, morajo biti vsi VRF-ji konfigurirani tudi na mejnih listih, požarni zid pa mora biti povezan z vsakim VRF-jem z ločeno povezavo.

Kot rezultat, shema s požarnim zidom:

Tovarna VxLAN. 3. del

To pomeni, da morate na požarnem zidu konfigurirati vmesnik za vsak VRF, ki se nahaja v omrežju. Na splošno se logika ne zdi zapletena in edina stvar, ki mi tukaj ni všeč, je ogromno število vmesnikov na požarnem zidu, vendar je tukaj čas, da razmislimo o avtomatizaciji.

Globa. Povezali smo požarni zid in ga dodali vsem VRF-jem. Toda kako lahko zdaj prisilimo promet iz vsakega lista skozi ta požarni zid?

Na Leafu, povezanem s požarnim zidom, ne bo 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       ! маршрут по-умолчанию через Firewall

Kaj pa oddaljeni Leafs? Kako jim posredovati privzeto zunanjo pot?

Tako je, prek EVPN route-type 5, kot katera koli druga predpona preko mreže VxLAN. Vendar to ni tako preprosto (če govorimo o Ciscu, saj nisem preverjal pri drugih prodajalcih)

Privzeta pot mora biti objavljena iz lista, s katerim je povezan požarni zid. Za prenos poti pa jo mora Leaf poznati sam. In tu se pojavi določen problem (mogoče samo pri meni), pot mora biti statično prijavljena v VRF, kjer želite takšno pot oglaševati:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

Nato v konfiguraciji BGP nastavite 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 vključena v družino l2vpn evpn. Poleg tega morate konfigurirati prerazporeditev:

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

Navedemo, katere predpone bodo prišle v BGP s prerazporeditvijo

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 pa predpona 0.0.0.0/0 spada v EVPN route-type 5 in se prenese na preostali list:

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

V tabeli BGP lahko opazimo tudi nastalo pot tipa 5 s privzeto potjo prek 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

S tem zaključujemo serijo člankov, posvečenih EVPN. V prihodnosti bom poskušal razmisliti o delovanju VxLAN v povezavi z Multicastom, saj ta metoda velja za bolj razširljivo (trenutno sporna izjava)

Če imate še vedno vprašanja / predloge na to temo, razmislite o kateri koli funkcionalnosti EVPN - pišite, razmislili bomo še naprej.

Tovarna VxLAN. 3. del

Vir: www.habr.com

Dodaj komentar