VxLAN továreň. Časť 3

Ahoj, Habr. Končím cyklus článků, věnovaných spuštění kurzu "Síťový inženýr" od OTUS, o technologii VxLAN EVPN pro směrování uvnitř fabriky a použití Firewallu pro omezení přístupu mezi interními službami

Předchozí části cyklu lze nalézt na odkazech:

• 1. část cyklu — L2 konektivita mezi servery
• 2. část cyklu — Směrování mezi VNI
• 2.5. část cyklu — Teoretické odbočení

Dnes pokračujeme ve studiu logiky směrování uvnitř fabriky VxLAN. V předchozí části jsme zkoumali směrování uvnitř fabriky v rámci jedné VRF. Avšak v síti může být obrovské množství klientských služeb a všechny je třeba rozdělit do různých VRF, aby se omezil přístup mezi nimi. Kromě síťového rozdělení může mít podnik potřebu připojit Firewall pro omezení přístupu mezi těmito službami. Ano, nelze to nazvat nejlepším řešením, avšak moderní realita vyžaduje "moderní řešení".

Zvážíme dvě varianty směrování mezi VRF:

1. Směrování, aniž bychom opustili VxLAN fabriku;
2. Směrování na externím zařízení.

Začneme s logikou směrování mezi VRF. Existuje určité množství VRF. Aby bylo možné směrovat mezi VRF, je nutné vyčlenit zařízení v síti, které bude znát všechny VRF (nebo alespoň části, mezi kterými je potřeba směrování). Tímto zařízením se může stát například jeden z Leaf switchů (nebo všechny najednou). Tato topologie by vypadala následovně:

Jaké jsou nedostatky této topologie?

Správně, každý Leaf musí znát všechny VRF (a všechny informace, které v nich jsou) v síti, což vede k ztrátě paměti a zvyšování zátěže na síť. Vždyť docela často každý Leaf switch nemusí vědět o všem, co je v síti.

Pojďme však tuto metodu prozkoumat podrobněji, protože pro malé sítě je tato varianta zcela vyhovující (pokud nejsou nějaké specifické požadavky podnikání).

V tuto chvíli se vám může objevit otázka, jak přenášet informace z VRF do VRF, protože smysl této technologie spočívá právě v tom, že šíření informací by mělo být omezeno.

A odpověď se skrývá v takových funkcích jako export a import směrovacích informací (nastavení této technologie bylo probráno ve druhý části cyklu). Stručně opakuji:

Při zadávání VRF v AF je nutné uvést route-target pre import a export trasových informácií. Je možné ho uviesť v automatickom režime. Potom sa do hodnoty dostane ASN BGP a L3 VNI priradený k VRF. Je to pohodlné, keď vo vašej fabrike používate len jednu ASN:

vrf kontext PROD20
  adresa-rodina ipv4 unicast
    route-target export auto      ! V automatickom režime sa exportuje RT-65001:99000
    route-target import auto

Avšak, ak máte viac ako jednu ASN a je potrebné prenášať trasy medzi nimi, pohodlnejšou a škálovateľnejšou možnosťou bude manuálne nastavenie route-target. Odporúčanie pri manuálnom nastavení — prvé číslo, použite to, čo vám vyhovuje, napríklad, 9999.
Druhé by malo byť rovné VNI pre tento VRF.

Nastavíme nasledujúcim spôsobom:

vrf kontext PROD10
  adresa-rodina ipv4 unicast
    route-target export 9999:99000          
    route-target import 9999:99000
    route-target import 9999:77000         ! Príklad 1 import z iného VRF
    route-target import 9999:88000         ! Príklad 2 import z iného VRF

Ako to vyzerá v tabuľke smerovania:

Leaf11# sh ip route vrf prod

192.168.20.0/24, ubest/mbest: 1/0
 *via 10.255.1.20fault, [200/0], 00:24:45, bgp-65001, interný, tag 65001
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN ! prefix je dostupný cez L3VNI 99000

Pozrime sa na druhú možnosť smerovania medzi VRF — cez vonkajšie zariadenie, napríklad Firewall.

Môžeme predpokladať niekoľko variantov fungovania cez vonkajšie zariadenie:

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

Na prvý variant sa nezastavíme, pretože logika bude prakticky rovnaká, ako bolo uvedené vyššie — dovedieme všetky VRF k Firewall a na ňom nastavíme smerovanie medzi VRF.

Pozrime sa na druhý variant, keď náš Firewall nič nevie o VxLAN (dnes už, samozrejme, prichádzajú zariadenia s podporou VxLAN. Napríklad, Checkpoint oznámil jeho podporu vo verzii R81. O tomto sa dá prečítať tu, avšak to je všetko v testovacej fáze a nie je istota v stabilite práce).

Pri pripojení vonkajšieho zariadenia získavame nasledujúcu schému:

Ako je vidieť na schéme — objavuje sa úzke miesto na styku s Firewall. Je potrebné na to pamätať pri plánovaní siete a optimalizácii sieťovej dopravy.

Avšak, vráťme sa k pôvodnej úlohe smerovania medzi VRF. V dôsledku pridania Firewall prichádzame k tomu, že Firewall by mal vedieť o všetkých VRF. Na tento účel by na hraničných Leaf mali byť nastavené všetky VRF, a Firewall pripojiť do každého VRF samostatným linkom.

Výsledkom je schéma s firewallom:

To znamená, že na firewallu je potrebné nastaviť rozhranie pre každý VRF v sieti. Celkovo logika vyzerá byť jednoduchá a jediné, čo môže niektorým prekážať, je obrovské množstvo rozhraní na firewalle, ale tu je čas zamyslieť sa nad automatizáciou.

Dobre. Pripojili sme firewall, pridali sme ho do všetkých VRF. Ale ako teraz presmerovať prenos z každého Leaf 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, statický ! predvolená trasa cez firewall

Avšak, ako sa to má robiť s vzdialenými Leaf? Ako im poslať vonkajšiu predvolenú trasu?

Správne, cez EVPN route-type 5, rovnako ako akýkoľvek iný prefix v VxLAN fabrike. Avšak, nie je to také jednoduché (ak hovoríme o cisco, u iných dodávateľov som to nekontroloval)

Annoncovať predvolenú trasu je potrebné z Leaf, ktorý je pripojený k firewallu. Avšak, aby sa trasa preniesla, Leaf ju musí poznať sám. A tu vzniká istý problém (možno len u mňa), trasu je potrebné zadať staticky v tom VRF, kde chcete túto trasu oznámiť:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

Ďalej v nastavení BGP zadajte túto trasu v AF IPv4:

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

Avšak, to nie je všetko. Týmto spôsobom sa predvolená trasa nedostane do rodiny l2vpn evpn. Okrem toho je potrebné nastaviť redistribúciu:

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

Uvedieme, ktoré prefixy sa dostanú do BGP prostredníctvom redistribúcie

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 prefix 0.0.0.0/0 sa dostáva do EVPN route-type 5 a prenáša sa ostatným Leaf:

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 - Virtuálna adresa Leaf (keďže Leaf fungujú ako VPS pár), ku ktorému je pripojený firewall

V tabuľke BGP môžeme takisto pozorovať prijatý route-type 5 s predvolenou trasou 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 ukončujeme cyklus článkov venovaných EVPN. V budúcnosti sa pokúsim preskúmať fungovanie VxLAN v spojení s Multicast, pretože tento spôsob sa považuje za škálovateľnejší (v súčasnosti je to sporné tvrdenie).

Ak máte otázky alebo návrhy týkajúce sa toho, aby sme preskúmali nejakú funkciu EVPN – napíšte, prehodnotíme to podrobnejšie.

Zdroj: habr.com