🥇Fabryka VxLAN. Część 3

Cześć, Habr. Kończę serię artykułów, poświęcony uruchomieniu kursu "Inżynier sieci" przez OTUS, wykorzystując technologię VxLAN EVPN do routingu w fabryce i używając zapory sieciowej do ograniczania dostępu między wewnętrznymi usługami

Poprzednie części serii można znaleźć pod linkami:

Dzisiaj będziemy kontynuować naukę logiki routingu wewnątrz struktury VxLAN. W poprzedniej sekcji przyjrzeliśmy się trasowaniu w ramach struktury pojedynczego systemu VRF. Jednak w sieci może być obecna ogromna liczba usług klienckich i wszystkie z nich muszą zostać rozdzielone na różne systemy VRF, aby ograniczyć dostęp między nimi. Oprócz rozgraniczenia sieci, przedsiębiorstwo może potrzebować włączyć zaporę sieciową, aby ograniczyć dostęp między tymi usługami. Owszem, nie można tego nazwać najlepszym rozwiązaniem, ale współczesne realia wymagają „nowoczesnych rozwiązań”.

Rozważmy dwie opcje routingu pomiędzy systemami VRF:

Trasowanie bez opuszczania struktury VxLAN;
Trasowanie na sprzęcie zewnętrznym.

Zacznijmy od logiki routingu pomiędzy systemami VRF. Istnieje pewna liczba VRF-ów. Aby ustalić trasę między systemami VRF, należy wybrać urządzenie w sieci, które będzie posiadać informacje o wszystkich systemach VRF (lub częściach, między którymi wymagane jest ustalenie trasy). Takim urządzeniem może być np. jeden z przełączników Leaf (lub wszystkie naraz). Topologia ta będzie wyglądać następująco:

Jakie są wady tej topologii?

Rzeczywiście, każdy komputer Leaf musi wiedzieć o wszystkich VRF-ach (i wszystkich zawartych w nich informacjach) w sieci, co prowadzi do utraty pamięci i zwiększonego obciążenia sieci. W końcu często nie każdy przełącznik Leaf musi wiedzieć o wszystkim, co znajduje się w sieci.

Rozważmy jednak tę metodę bardziej szczegółowo, gdyż dla małych sieci ta opcja jest całkiem odpowiednia (jeśli nie ma szczególnych wymagań biznesowych)

W tym momencie możesz mieć pytanie, jak przesłać informacje z VRF do VRF, ponieważ celem tej technologii jest ograniczenie dystrybucji informacji.

Odpowiedź tkwi w takich funkcjach jak eksport i import informacji o trasie (konfiguracja tej technologii została przemyślana w drugi części cyklu). Pozwólcie mi powtórzyć krótko:

Podczas określania VRF w AF należy określić route-target do importu i eksportu informacji o trasach. Można to określić automatycznie. Wówczas wartość będzie obejmować BGP ASN i L3 VNI powiązane z VRF. Jest to przydatne, jeśli w swojej fabryce posiadasz tylko jeden numer ASN:

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

Jeśli jednak masz więcej niż jeden ASN i musisz przekazywać trasy między nimi, ręczna konfiguracja będzie wygodniejszą i bardziej skalowalną opcją. route-target. Zalecane ustawienia ręczne to pierwsza liczba, użyj tej, która jest dla Ciebie najwygodniejsza, np. 9999.
Drugi powinien być równy VNI dla danego VRF.

Skonfigurujmy to w następujący sposób:

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 wygląda w tabeli routingu:

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

Rozważmy drugą opcję routingu między systemami VRF - poprzez urządzenia zewnętrzne, na przykład zaporę sieciową.

Istnieje kilka możliwych opcji pracy za pośrednictwem urządzenia zewnętrznego:

Urządzenie wie, czym jest VxLAN i możemy dodać je do części strukturalnej;
Urządzenie nic nie wie o sieci VxLAN.

Nie będziemy rozwodzić się nad pierwszą opcją, ponieważ logika będzie niemal taka sama, jak pokazano powyżej - przenosimy wszystkie serwery VRF do zapory sieciowej i konfigurujemy na niej routing pomiędzy serwerami VRF.

Rozważmy drugą opcję, kiedy nasza zapora nic nie wie o VxLAN (teraz oczywiście pojawiają się urządzenia z obsługą VxLAN. Na przykład Checkpoint zapowiedział obsługę w wersji R81. Możesz o tym przeczytać tutaj(jednak wszystko to jest na etapie testów i nie ma pewności co do stabilności działania).

Po podłączeniu urządzenia zewnętrznego otrzymujemy poniższy diagram:

Jak widać na schemacie, wąskie gardło powstaje na połączeniu z zaporą sieciową. Należy o tym pamiętać w przyszłości podczas planowania sieci i optymalizacji ruchu sieciowego.

Wróćmy jednak do pierwotnego problemu routingu między systemami VRF. W wyniku dodania zapory doszliśmy do wniosku, że zapora powinna wiedzieć o wszystkich systemach VRF. Aby to zrobić, wszystkie VRF-y muszą być skonfigurowane na routerach granicznych Leaf, a zapora musi być podłączona do każdego VRF-a za pomocą oddzielnego łącza.

W efekcie schemat z Firewallem wygląda następująco:

Oznacza to, że na Zaporze Sieciowej należy skonfigurować interfejs w każdym VRF znajdującym się w sieci. Ogólnie rzecz biorąc, logika nie wydaje się skomplikowana i jedyną rzeczą, która może Ci się tu nie podobać, jest ogromna liczba interfejsów w zaporze, ale czas pomyśleć o automatyzacji.

Cienki. Podłączyliśmy zaporę sieciową i dodaliśmy ją do wszystkich systemów VRF. Ale w jaki sposób możemy teraz zmusić ruch z każdego urządzenia Leaf do przechodzenia przez tę zaporę?

Na komputerze Leaf podłączonym do zapory sieciowej nie będzie żadnych problemów, ponieważ wszystkie trasy są lokalne:

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

A co z usuniętymi Leafs? Jak przekazać im domyślną trasę zewnętrzną?

Dokładnie tak, poprzez trasę EVPN typu 5, jak każdy inny prefiks przez strukturę VxLAN. Jednak nie jest to takie proste (jeśli chodzi o Cisco, nie sprawdzałem tego u innych dostawców)

Domyślna trasa musi zostać ogłoszona z urządzenia Leaf, do którego podłączona jest zapora. Jednak w celu przesłania trasy Leaf musi ją znać. I tutaj pojawia się pewien problem (może to tylko ja tak mam), trasa musi być zapisana jako statyczna w VRF, w którym chcemy taką trasę ogłosić:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

Następnie w konfiguracji BGP należy ustawić tę trasę w AF IPv4:

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

Ale to nie wszystko. W ten sposób trasa domyślna nie zostanie uwzględniona w rodzinie. l2vpn evpn. Oprócz tego konieczne jest skonfigurowanie redystrybucji:

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

Określamy, które prefiksy zostaną uwzględnione w BGP poprzez redystrybucję

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 prefiks 0.0.0.0/0 trafia do trasy EVPN typu 5 i jest przekazywany do reszty 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

W tabeli BGP możemy również zobaczyć otrzymany typ trasy 5 z domyślną trasą przez 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

W ten sposób kończymy serię artykułów poświęconych EVPN. W przyszłości postaram się rozważyć działanie VxLAN w połączeniu z Multicast, ponieważ ta metoda jest uważana za bardziej skalowalną (na razie jest to kontrowersyjne stwierdzenie)

Jeśli masz jakieś pytania/sugestie dotyczące tego tematu, chciałbyś rozważyć jakąś funkcjonalność EVPN - napisz, rozważymy to dalej.

Źródło: www.habr.com