ProHoster > Blog > Administrácia > Továreň VxLAN. Časť 3

Továreň VxLAN. Časť 3

Ahoj Habr. Dokončujem sériu článkov, venovaný spusteniu kurzu "Sieťový inžinier" spoločnosťou OTUSpomocou technológie VxLAN EVPN na smerovanie v rámci štruktúry a pomocou brány firewall na obmedzenie prístupu medzi internými službami

Továreň VxLAN. Časť 3

Predchádzajúce časti seriálu nájdete na nasledujúcich odkazoch:

Dnes budeme pokračovať v štúdiu logiky smerovania vo vnútri štruktúry VxLAN. V predchádzajúcej časti sme sa pozreli na vnútrofabricové smerovanie v rámci jedného VRF. V sieti však môže byť obrovské množstvo klientskych služieb a všetky musia byť distribuované do rôznych VRF, aby sa medzi nimi rozlíšil prístup. Okrem oddelenia siete môže podnik potrebovať pripojenie brány firewall na obmedzenie prístupu medzi týmito službami. Áno, toto sa nedá nazvať najlepším riešením, ale moderná realita si vyžaduje „moderné riešenia“.

Zvážme dve možnosti smerovania medzi VRF:

  1. Smerovanie bez opustenia štruktúry VxLAN;
  2. Smerovanie na externom zariadení.

Začnime s logikou smerovania medzi VRF. Existuje určitý počet VRF. Pre smerovanie medzi VRF je potrebné vybrať zariadenie v sieti, ktoré bude vedieť o všetkých VRF (alebo častiach, medzi ktorými je potrebné smerovanie).Takýmto zariadením môže byť napríklad niektorý z Leaf switchov (alebo všetky naraz) . Táto topológia bude vyzerať takto:

Továreň VxLAN. Časť 3

Aké sú nevýhody tejto topológie?

Je to tak, každý Leaf potrebuje vedieť o všetkých VRF (a všetkých informáciách, ktoré sa v nich nachádzajú) v sieti, čo vedie k strate pamäte a zvýšenému zaťaženiu siete. Koniec koncov, každý prepínač Leaf často nemusí vedieť o všetkom, čo je v sieti.

Pozrime sa však na túto metódu podrobnejšie, pretože pre malé siete je táto možnosť celkom vhodná (ak neexistujú žiadne špecifické obchodné požiadavky)

V tomto bode môžete mať otázku, ako preniesť informácie z VRF do VRF, pretože zmyslom tejto technológie je práve to, že šírenie informácií by malo byť obmedzené.

A odpoveď spočíva vo funkciách, ako je export a import smerovacích informácií (s nastavením tejto technológie sa uvažovalo v druhý časti cyklu). Stručne zopakujem:

Pri nastavovaní VRF v AF musíte špecifikovať route-target pre informácie o smerovaní importu a exportu. Môžete to určiť automaticky. Potom bude hodnota zahŕňať ASN BGP a L3 VNI spojené s VRF. Je to výhodné, keď máte vo svojej továrni iba jedno ASN: 

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

Ak však máte viac ako jedno ASN a potrebujete medzi nimi prenášať trasy, manuálna konfigurácia bude pohodlnejšou a škálovateľnejšou možnosťou route-target. Odporúčanie pre manuálne nastavenie je prvé číslo, použite také, ktoré vám vyhovuje, napr. 9999.
Druhý by mal byť nastavený tak, aby sa rovnal VNI pre daný VRF.

Nakonfigurujme to nasledovne:

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

Ako to vyzerá v smerovacej tabuľke:

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

Uvažujme o druhej možnosti smerovania medzi VRF - cez externé zariadenia, napríklad Firewall.

Existuje niekoľko možností pre prácu cez externé zariadenie:

  1. Zariadenie vie, čo je VxLAN a môžeme ho pridať do časti látky;
  2. Zariadenie nevie nič o VxLAN.

Nebudeme sa zaoberať prvou možnosťou, pretože logika bude takmer rovnaká, ako je uvedené vyššie - privedieme všetky VRF do Firewallu a nakonfigurujeme na ňom smerovanie medzi VRF.

Zvážme druhú možnosť, keď náš Firewall o VxLAN nič nevie (teraz sa už samozrejme objavuje výbava s podporou VxLAN. Napríklad Checkpoint ohlásil podporu vo verzii R81. Môžete si o nej prečítať tuToto je však všetko v štádiu testovania a neexistuje žiadna dôvera v stabilitu prevádzky).

Pri pripájaní externého zariadenia dostaneme nasledujúci diagram:

Továreň VxLAN. Časť 3

Ako môžete vidieť z diagramu, na rozhraní s bránou firewall sa objavuje úzke miesto. S tým treba v budúcnosti počítať pri plánovaní siete a optimalizácii sieťovej prevádzky.

Vráťme sa však k pôvodnému problému smerovania medzi VRF. V dôsledku pridania Firewallu prichádzame k záveru, že Firewall musí vedieť o všetkých VRF. Na tento účel musia byť všetky VRF nakonfigurované aj na hraničných listoch a Firewall musí byť pripojený ku každému VRF samostatným prepojením.

Výsledkom je, že schéma s bránou firewall:

Továreň VxLAN. Časť 3

To znamená, že na bráne Firewall musíte nakonfigurovať rozhranie pre každý VRF umiestnený v sieti. Vo všeobecnosti logika nevyzerá komplikovane a jediná vec, ktorá sa mi tu nepáči, je obrovské množstvo rozhraní na bráne firewall, ale tu je čas premýšľať o automatizácii.

Dobre. Pripojili sme Firewall a pridali sme ho do všetkých VRF. Ale ako môžeme teraz prinútiť premávku z každého listu, aby prechádzala cez tento firewall?

Na Leaf pripojenom k ​​Firewallu nevzniknú žiadne problémy, pretože všetky trasy sú lokálne:

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

Čo však vzdialené Leafs? Ako im odovzdať predvolenú externú cestu?

To je pravda, cez EVPN typ trasy 5, ako každá iná predpona cez štruktúru VxLAN. To však nie je také jednoduché (ak hovoríme o Cisco, pretože som to neoveril u iných predajcov)

Predvolená trasa musí byť inzerovaná z listu, ku ktorému je pripojený firewall. Na prenos trasy ju však musí Leaf poznať sám. A tu nastáva istý problém (možno len u mňa), trasa musí byť staticky zaregistrovaná vo VRF, kde chcete takúto trasu inzerovať:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

Ďalej v konfigurácii BGP nastavte túto trasu v AF IPv4:

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

To však nie je všetko. Týmto spôsobom nebude predvolená trasa zahrnutá do rodiny l2vpn evpn. Okrem toho musíte nakonfigurovať redistribúciu:

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

Uvádzame, ktoré prefixy sa do BGP dostanú redistribúciou

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

Teraz predpona 0.0.0.0/0 spadá do trasy EVPN typu 5 a prenáša sa do zvyšku listu:

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 tabuľke BGP môžeme tiež pozorovať výslednú trasu typu 5 s predvolenou cestou cez 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

Týmto sa uzatvára séria článkov venovaných EVPN. V budúcnosti sa pokúsim zvážiť fungovanie VxLAN v spojení s Multicastom, pretože táto metóda sa považuje za škálovateľnejšiu (v súčasnosti kontroverzné vyhlásenie)

Ak máte ešte otázky/návrhy k téme, zvážte akúkoľvek funkčnosť EVPN – napíšte, budeme to ďalej zvažovať.

Továreň VxLAN. Časť 3

Zdroj: hab.com

Pridať komentár