Fabryka VxLAN. Część 3

Witaj, Habr. Kończę serię artykułów, poświęcony uruchomieniu kursu "Inżynier sieci" przez OTUS, wykorzystując technologię VxLAN EVPN do routingu w obrębie sieci szkieletowej i wykorzystując zaporę sieciową do ograniczania dostępu pomiędzy usługami wewnętrznymi

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

• 1 część cyklu - łączność L2 między serwerami
• Część 2 serii - Trasowanie pomiędzy VNI
• Część 2.5 z cyklu - Dygresja teoretyczna

Dzisiaj będziemy kontynuować badanie logiki routingu w strukturze VxLAN. W poprzedniej części przyjrzeliśmy się routingowi wewnątrz sieci szkieletowej w ramach jednego VRF. Jednakże w sieci może znajdować się ogromna liczba usług klienckich i wszystkie z nich muszą być rozdzielone na różne VRF, aby zróżnicować dostęp między nimi. Oprócz separacji sieci firma może wymagać podłączenia zapory sieciowej, aby ograniczyć dostęp między tymi usługami. Tak, tego nie można nazwać najlepszym rozwiązaniem, ale współczesne realia wymagają „nowoczesnych rozwiązań”.

Rozważmy dwie opcje routingu pomiędzy urządzeniami VRF:

1. Routowanie bez opuszczania struktury VxLAN;
2. Routing na sprzęcie zewnętrznym.

Zacznijmy od logiki routingu pomiędzy urządzeniami VRF. Istnieje pewna liczba VRF. Aby trasować pomiędzy VRF-ami należy wybrać w sieci urządzenie, które będzie wiedziało o wszystkich VRF-ach (lub częściach pomiędzy którymi potrzebny jest routing).Takim urządzeniem może być np. jeden z przełączników Leaf (lub wszystkie na raz). . Topologia ta będzie wyglądać następująco:

Jakie są wady tej topologii?

Zgadza się, każdy Leaf musi wiedzieć o wszystkich VRF (i wszystkich informacjach, które się w nich znajdują) w sieci, co prowadzi do utraty pamięci i zwiększonego obciążenia sieci. W końcu dość często każdy przełącznik Leaf nie musi wiedzieć o wszystkim, co jest w sieci.

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

W tym miejscu możesz mieć pytanie, jak przesyłać informacje z VRF do VRF, ponieważ celem tej technologii jest właśnie ograniczenie rozpowszechniania informacji.

Odpowiedź kryje się w funkcjach takich jak eksport i import informacji o routingu (opracowanie tej technologii rozważano m.in drugi części cyklu). Powtórzę krótko:

Ustawiając VRF w AF, musisz określić route-target w celu uzyskania informacji o trasach importu i eksportu. Możesz określić to automatycznie. Następnie wartość będzie zawierać ASN BGP i L3 VNI powiązane z VRF. Jest to wygodne, jeśli w fabryce masz 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 posiadasz więcej niż jeden ASN i musisz przesyłać trasy pomiędzy nimi, wówczas ręczna konfiguracja będzie wygodniejszą i skalowalną opcją route-target. Rekomendacją do konfiguracji ręcznej jest pierwszy numer, użyj takiego, który jest dla Ciebie wygodny, np. 9999.
Drugi powinien być ustawiony na równy VNI dla tego 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 tablicy 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 - przez sprzęt zewnętrzny, na przykład zaporę sieciową.

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

1. Urządzenie wie co to jest VxLAN i możemy to dodać do części tkaniny;
2. Urządzenie nie wie nic o VxLAN.

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

Rozważmy drugą opcję, gdy nasz Firewall nic nie wie o VxLAN (teraz oczywiście pojawia się sprzęt z obsługą VxLAN. Przykładowo Checkpoint ogłosił swoje wsparcie w wersji R81. Można o tym przeczytać tutaj, jednak to wszystko jest na etapie testów i nie ma pewności co do stabilności działania).

Podłączając urządzenie zewnętrzne otrzymujemy następujący schemat:

Jak widać na diagramie, na interfejsie z Zaporą sieciową pojawia się wąskie gardło. Należy to wziąć pod uwagę w przyszłości podczas planowania sieci i optymalizacji ruchu sieciowego.

Wróćmy jednak do pierwotnego problemu routingu pomiędzy urządzeniami VRF. W wyniku dodania Firewalla dochodzimy do wniosku, że Firewall musi wiedzieć o wszystkich VRF-ach. Aby to zrobić, wszystkie VRF muszą być również skonfigurowane na granicznych liściach, a Firewall musi być podłączony do każdego VRF osobnym łączem.

W rezultacie schemat z zaporą sieciową:

Oznacza to, że na zaporze musisz skonfigurować interfejs dla każdego VRF znajdującego się w sieci. Ogólnie logika nie wygląda na skomplikowaną i jedyne co mi się tutaj nie podoba to ogromna ilość interfejsów na Firewallu, ale tutaj czas pomyśleć o automatyzacji.

Cienki. Podłączyliśmy Firewall i dodaliśmy go do wszystkich VRF. Ale jak możemy teraz zmusić ruch z każdego liścia do przejścia przez tę zaporę sieciową?

Na Leafie podłączonym do Firewalla nie pojawią się żadne problemy, 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 odległymi Leafami? Jak przekazać im domyślną trasę zewnętrzną?

Zgadza się, poprzez trasę EVPN typu 5, jak każdy inny prefiks w sieci szkieletowej VxLAN. Nie jest to jednak takie proste (jeśli mówimy o Cisco, bo nie sprawdzałem u innych dostawców)

Trasa domyślna musi być ogłaszana z poziomu Leafa, do którego podłączony jest Firewall. Aby jednak przesłać trasę, Leaf musi sam ją znać. I tu pojawia się pewien problem (być może tylko u mnie), trasa musi być zarejestrowana statycznie w VRF gdzie chcesz reklamować taką trasę:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

Następnie w konfiguracji BGP ustaw tę trasę w AF IPv4:

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

Jednak to nie wszystko. W ten sposób trasa domyślna nie zostanie uwzględniona w rodzinie l2vpn evpn. Oprócz tego musisz skonfigurować redystrybucję:

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

Wskazujemy, które prefiksy trafią do 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 przedrostek 0.0.0.0/0 należy do trasy EVPN typu 5 i jest przesyłany 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ż obserwować wynikowy typ trasy 5 z trasą domyślną 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

Na tym kończy się seria artykułów poświęconych EVPN. W przyszłości postaram się rozważyć działanie VxLAN w połączeniu z Multicastem, gdyż ta metoda jest uważana za bardziej skalowalną (w tej chwili stwierdzenie kontrowersyjne)

Jeśli nadal masz pytania/sugestie na ten temat, rozważ dowolną funkcjonalność EVPN - napisz, rozważymy to szczegółowo.

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