ProHoster > Blog > podávání > Továrna VxLAN. Část 3

Továrna VxLAN. Část 3

Dobrý den, Habr. Dokončuji sérii článků, věnované zahájení kurzu "Síťový inženýr" od OTUSpomocí technologie VxLAN EVPN pro směrování v rámci struktury a pomocí brány firewall k omezení přístupu mezi interními službami

Továrna VxLAN. Část 3

Předchozí díly seriálu najdete na následujících odkazech:

Dnes budeme pokračovat ve studiu logiky směrování uvnitř struktury VxLAN. V předchozí části jsme se podívali na intra-fabric routing v rámci jednoho VRF. V síti však může být obrovské množství klientských služeb a všechny musí být distribuovány do různých VRF, aby se mezi nimi odlišil přístup. Kromě oddělení sítě může podnik potřebovat připojení brány firewall k omezení přístupu mezi těmito službami. Ano, toto nelze nazvat nejlepším řešením, ale moderní realita vyžaduje „moderní řešení“.

Zvažme dvě možnosti pro směrování mezi VRF:

  1. Směrování bez opuštění struktury VxLAN;
  2. Směrování na externím zařízení.

Začněme logikou směrování mezi VRF. Existuje určitý počet VRF. Pro směrování mezi VRF je potřeba v síti vybrat zařízení, které bude vědět o všech VRF (nebo částech, mezi kterými je směrování potřeba) Takovým zařízením může být například některý z přepínačů Leaf (nebo všechny najednou) . Tato topologie bude vypadat takto:

Továrna VxLAN. Část 3

Jaké jsou nevýhody této topologie?

Je to tak, každý Leaf potřebuje vědět o všech VRF (a všech informacích, které jsou v nich) v síti, což vede ke ztrátě paměti a zvýšené zátěži sítě. Ostatně dost často každý přepínač Leaf nemusí vědět o všem, co je v síti.

Podívejme se však na tuto metodu podrobněji, protože pro malé sítě je tato možnost docela vhodná (pokud neexistují žádné specifické obchodní požadavky)

V tuto chvíli můžete mít otázku, jak přenést informace z VRF do VRF, protože smyslem této technologie je právě to, že šíření informací by mělo být omezeno.

A odpověď spočívá ve funkcích, jako je export a import směrovacích informací (nastavení této technologie bylo zvažováno v druhý části cyklu). Dovolte mi krátce zopakovat:

Při nastavování VRF v AF musíte specifikovat route-target pro informace o směrování importu a exportu. Můžete jej určit automaticky. Potom bude hodnota zahrnovat ASN BGP a L3 VNI spojené s VRF. To je výhodné, když máte ve své továrně pouze jedno ASN: 

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

Pokud však máte více než jedno ASN a potřebujete mezi nimi přenášet trasy, bude ruční konfigurace pohodlnější a škálovatelnější. route-target. Doporučení pro ruční nastavení je první číslo, použijte takové, které vám vyhovuje, např. 9999.
Druhý by měl být nastaven tak, aby se rovnal VNI pro daný VRF.

Nakonfigurujeme to následovně:

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

Jak to vypadá ve směrovací tabulce:

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

Zvažme druhou možnost pro směrování mezi VRF - přes externí zařízení, například Firewall.

Existuje několik možností, jak pracovat prostřednictvím externího zařízení:

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

Nebudeme se zabývat první možností, protože logika bude téměř stejná, jak je uvedeno výše - přivedeme všechny VRF do Firewallu a nakonfigurujeme na něm směrování mezi VRF.

Zvažme druhou možnost, kdy náš Firewall o VxLAN nic neví (nyní se samozřejmě objevuje zařízení s podporou VxLAN. Například Checkpoint oznámil podporu ve verzi R81. Můžete si o tom přečíst zdeto je však vše ve fázi testování a neexistuje žádná důvěra ve stabilitu provozu).

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

Továrna VxLAN. Část 3

Jak můžete vidět z diagramu, na rozhraní s Firewallem se objevuje úzké místo. S tím je třeba v budoucnu počítat při plánování sítě a optimalizaci síťového provozu.

Vraťme se však k původnímu problému směrování mezi VRF. V důsledku přidání Firewallu dojdeme k závěru, že Firewall musí vědět o všech VRF. K tomu musí být všechny VRF také nakonfigurovány na hraničních listech a Firewall musí být připojen ke každému VRF samostatným propojením.

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

Továrna VxLAN. Část 3

To znamená, že na bráně firewall musíte nakonfigurovat rozhraní pro každý VRF umístěný v síti. Obecně platí, že logika nevypadá složitě a jediná věc, která se mi zde nelíbí, je obrovské množství rozhraní na bráně firewall, ale zde je čas přemýšlet o automatizaci.

Pokuta. Připojili jsme bránu firewall a přidali ji do všech VRF. Ale jak můžeme nyní přinutit provoz z každého listu, aby procházel tímto Firewallem?

Na Leaf připojeném k Firewallu nevzniknou žádné problémy, protože všechny trasy jsou místní:

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

Co však vzdálené Leafs? Jak jim předat výchozí externí cestu?

To je pravda, přes EVPN route-type 5, jako každá jiná předpona přes strukturu VxLAN. To však není tak jednoduché (pokud mluvíme o Cisco, protože jsem to nekontroloval u jiných prodejců)

Výchozí trasa musí být inzerována z listu, ke kterému je brána firewall připojena. Aby však mohl přenést trasu, musí ji Leaf znát sám. A zde nastává určitý problém (snad jen pro mě), trasa musí být staticky evidována ve VRF, kde chcete takovou trasu inzerovat:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

Dále v konfiguraci BGP nastavte tuto trasu v AF IPv4:

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

To však není vše. Tímto způsobem nebude výchozí trasa zahrnuta do rodiny l2vpn evpn. Kromě toho musíte nakonfigurovat redistribuci:

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

Uvádíme, které prefixy se do BGP dostanou redistribucí

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í předpona 0.0.0.0/0 spadá do trasy EVPN typu 5 a je přenášena do zbytku Leaf:

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 tabulce BGP můžeme také sledovat výslednou trasu typu 5 s výchozí cestou 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 končí série článků věnovaných EVPN. V budoucnu se pokusím zvážit provoz VxLAN ve spojení s Multicastem, protože tato metoda je považována za škálovatelnější (v tuto chvíli kontroverzní prohlášení)

Pokud máte k tématu ještě dotazy/návrhy, zvažte jakoukoliv funkcionalitu EVPN – napište, budeme to dále zvažovat.

Továrna VxLAN. Část 3

Zdroj: www.habr.com

Přidat komentář