VxLAN factory. Část 3

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

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

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

Dnes budeme pokračovat ve studiu logiky routování uvnitř fabriky VxLAN. V předchozí části jsme zkoumali routování uvnitř fabriky v rámci jednoho VRF. Nicméně v síti může být obrovské množství klientských služeb, které je třeba rozdělit do různých VRF pro rozlišení přístupu mezi nimi. Kromě síťového rozlišení může mít firma potřebu připojit firewall pro omezení přístupu mezi těmito službami. Ano, nelze to označit za nejlepší řešení, nicméně současné podmínky vyžadují "moderní řešení".

Podíváme se na dvě varianty routování mezi VRF:

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

Začněme s logikou routování mezi VRF. Existuje určité množství VRF. Aby bylo možné routovat mezi VRF, je nutné vyčlenit zařízení v síti, které bude vědět o všech VRF (nebo alespoň části, mezi kterými potřebujeme routování). Tímto zařízením může být například jeden z Leaf switchů (nebo všechny najednou). Tato topologie bude vypadat takto:

Jaké nevýhody má tato 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 ke ztrátě paměti a zvýšení zátěže na síť. Vždyť často každému Leaf switchi není potřeba znát vše, co v síti existuje.

Pojďme se však na tuto metodu podívat podrobněji, protože pro malé sítě je tento variant zcela adekvátní (pokud neexistují nějaké specifické obchodní požadavky).

V tuto chvíli se vám může objevit otázka, jak přenášet informace z VRF do VRF, neboť smyslem této technologie je omezit šíření informací.

A odpověď spočívá v takových funkcích jako export a import informačních tras (nastavení této technologie bylo zkoumáno ve druhé části cyklu). Stručně zopakuji:

Při zadávání VRF v AF je nutné uvést route-target pro import a export trasportních informací. Lze jej zadat automaticky. Potom se do hodnoty dostane ASN BGP a L3 VNI navázané na VRF. To je pohodlné, když ve vaší továrně používáte pouze jedno ASN:

vrf kontext PROD20
  adresní rodina ipv4 unicast
    route-target export auto      ! V automatickém režimu se exportuje RT-65001:99000
    route-target import auto

Pokud však máte více než jedno ASN a je potřeba převádět trasy mezi nimi, bude pohodlnější a škálovatelnější variantou ruční nastavení route-target. Doporučení pro ruční nastavení — číslo, které považujete za vhodné, například, 9999.
Druhé by mělo být rovno VNI pro tento VRF.

Nastavíme následujícím způsobem:

vrf kontext PROD10
  adresní rodina ipv4 unicast
    route-target export 9999:99000          
    route-target import 9999:99000
    route-target import 9999:77000         ! Příklad 1 import z jiného VRF
    route-target import 9999:88000         ! Příklad 2 import z jiného VRF

Jak to vypadá v tabulce směrování:

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, internal, tag 65001
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN ! prefix je dostupný přes L3VNI 99000

Zvážíme druhou variantu směrování mezi VRF — přes externí zařízení, například Firewall.

Lze předpokládat několik variant fungování přes externí zařízení:

1. Zařízení ví, co je VxLAN, a můžeme jej přidat do části továrny;
2. Zařízení nic neví o VxLAN.

Na první variantě se zastavovat nebudeme, protože logika bude prakticky stejná jako výše — přivedeme všechna VRF k Firewallu a na něm nastavíme směrování mezi VRF.

Zvážíme druhou variantu, kdy náš Firewall nic neví o VxLAN (v současné době samozřejmě přichází zařízení s podporou VxLAN. Například Checkpoint oznámil jeho podporu ve verzi R81. O tom si můžete přečíst tady, avšak to je všechno v testovací fázi a není jistota ve stabilitě práce).

Při připojení externího zařízení dostáváme následující schéma:

Jak je z schématu zřejmé — objevuje se úzké místo na rozhraní s Firewall. Je nutné to zohlednit při dalším plánování sítě a optimalizaci síťového provozu.

Nicméně, vraťme se k původnímu úkolu směrování mezi VRF. V důsledku přidání Firewall přicházíme k tomu, že Firewall musí vědět o všech VRF. Pro to musí být na hraničních Vinech rovněž nakonfigurovány všechny VRF, a Firewall připojujeme do každého VRF zvláštním linkem.

V důsledku toho schéma s Firewallem:

To znamená, že na Firewalu je třeba nastavit rozhraní v každém VRF, který se nachází v síti. Celkově logika vypadá jednoduše a jediná věc, která by se mohla nelíbit, je obrovské množství rozhraní na Firewalu, ale zde je na místě přemýšlet o automatizaci.

Dobře. Připojili jsme Firewall, přidali ho do všech VRF. Jak nyní donutit provoz z každého Leafu, aby šel přes tento Firewall?

Na Leafu připojeném k Firewalu nebudou žádné problémy, protože všechny trasy jsou lokální:

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.254.13.55, [1/0], 6w5d, statické       ! výchozí trasa přes Firewall

Ale co s vzdálenými Leafy? Jak jim předat externí výchozí trasu?

Správně, přes EVPN route-type 5, stejně jako jakýkoli jiný prefix ve VxLAN fabrice. Nicméně to není tak jednoduché (pokud mluvíme o Cisco, tak u jiných výrobců jsem to neověřoval)

Annoncovat výchozí trasu je nutné z Leafu, ke kterému je připojen Firewall. Nicméně, abychom trasu předali, musí ji Leaf sám znát. A zde vzniká jistý problém (možná jen u mě), trasu je třeba zapsat staticky v tom VRF, kde chcete takovou trasu anoncovat:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

Dále v nastavení BGP je třeba nastavit tuto trasu v AF IPv4:

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

Tím to ale nekončí. Tímto způsobem výchozí trasa nenajde cestu do rodiny l2vpn evpn. K tomu je navíc potřeba nastavit redistribuci:

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

Uvedeme, které přesně prefixy projdou do BGP přes redistribuci

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

Nyní prefix 0.0.0.0/0 prochází do EVPN route-type 5 a je předáván ostatním Leafům:

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ální adresa Leaf (protože Leaf fungují jako pár VPS), ke kterému je připojen Firewall

V tabulce BGP můžeme také vidět získaný route-type 5 s výchozí trasou přes 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ánků věnovaných EVPN. V budoucnu se pokusím prozkoumat fungování VxLAN ve spojení s Multicastem, protože tento způsob se považuje za více škálovatelný (v tuto chvíli je to sporné tvrzení).

Pokud máte nějaké otázky nebo návrhy na téma, jakýkoli funkce EVPN – napište, prozkoumáme to podrobněji.

Zdroj: habr.com