Fabrika VxLAN. Część 3

Cześć, Habr. Kończę cykl artykułów, poświęconych uruchomieniu kursu "Inżynier sieciowy" od OTUS, dotyczącego technologii VxLAN EVPN w zakresie routingu wewnątrz fabryki oraz wykorzystania zapory ogniowej do ograniczania dostępu między wewnętrznymi usługami

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

• Część 1 cyklu — Łączność L2 między serwerami
• Część 2 cyklu — Routing między VNI
• Część 2.5 cyklu — Teoretyczne odstępstwo

Dziś kontynuujemy badanie logiki routingu wewnątrz fabryki VxLAN. W poprzedniej części omawialiśmy routing wewnątrz fabryki w ramach jednego VRF. Jednak w sieci może być ogromna liczba klientów-usług i trzeba je rozdzielić w różne VRF, aby ograniczyć dostęp między nimi. Dodatkowo, biznes może potrzebować podłączyć zaporę ogniową, aby ograniczyć dostęp między tymi usługami. Tak, nie można tego nazwać najlepszym rozwiązaniem, jednak współczesne realia wymagają "nowoczesnych rozwiązań".

Rozważmy dwa warianty routingu między VRF:

1. Routing, nie wychodząc z fabryki VxLAN;
2. Routing na zewnętrznym sprzęcie.

Zacznijmy od logiki routingu między VRF. Istnieje określona liczba VRF. Aby przeprowadzić routing między VRF, należy wyznaczyć urządzenie w sieci, które będzie wiedziało o wszystkich VRF (lub części, między którymi potrzebny jest routing). Takim urządzeniem może być na przykład jeden z przełączników Leaf (lub wszystkie naraz). Taka topologia będzie wyglądać następująco:

Jakie są wady takiej topologii?

Dokładnie, każdy Leaf musi znać wszystkie VRF (i wszystkie informacje, jakie się w nich znajdują) w sieci, co prowadzi do utraty pamięci i zwiększenia obciążenia sieci. Bowiem dość często każdy przełącznik Leaf nie musi wiedzieć o wszystkim, co jest w sieci.

Jednak rozważmy ten sposób dokładniej, ponieważ dla małych sieci ten wariant jest całkiem odpowiedni (jeśli nie ma specyficznych wymagań biznesowych)

W tym momencie może się pojawić pytanie, jak przekazywać informacje z VRF do VRF, ponieważ sens tej technologii polega na tym, że rozpowszechnianie informacji powinno być ograniczone.

A odpowiedź leży w takich funkcjach jak eksport i import informacji o trasach (ustawienia tej technologii omawialiśmy w drugi części cyklu). Krótko przypomnę:

Przy wyznaczaniu VRF w AF należy wskazać route-target do importu i eksportu informacji o trasach. Można go wskazać w trybie automatycznym. Wtedy wartością będzie ASN BGP i L3 VNI związany z VRF. Jest to wygodne, gdy w twojej fabryce używasz tylko jednego ASN:

vrf context PROD20
  address-family ipv4 unicast
    route-target export auto      ! W trybie automatycznym eksportowany jest RT-65001:99000
    route-target import auto

Jednakże, jeśli masz więcej niż jeden ASN i musisz przekazywać trasy między nimi, to bardziej wygodnym i skalowalnym rozwiązaniem będzie ręczna konfiguracja route-target. Rekomendacja dotycząca ręcznej konfiguracji — pierwsza liczba, użyj wygodnej dla siebie, na przykład, 9999.
Drugą należy ustawić równą VNI dla tego VRF.

Skonfigurujmy 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         ! Przykład 1 import z innego VRF
    route-target import 9999:88000         ! Przykład 2 import z innego 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.20fault, [200/0], 00:24:45, bgp-65001, internal, tag 65001
(evpn) segid: 99000 tunnelid: 0xaff0114 encap: VXLAN ! prefix available through L3VNI 99000

Rozważmy drugi wariant routingu między VRF — przez zewnętrzne urządzenia, na przykład Zapora.

Można założyć kilka wariantów pracy przez zewnętrzne urządzenie:

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

Nie zatrzymujemy się na pierwszym wariancie, ponieważ logika będzie praktycznie taka sama, jak pokazano powyżej — doprowadzamy wszystkie VRF do Zapory i na niej konfigurujemy routing między VRF.

Rozważmy drugi wariant, kiedy nasza Zapora nic nie wie o VxLAN (obecnie, oczywiście, pojawiają się urządzenia z obsługą VxLAN. Na przykład, Checkpoint ogłosił wsparcie w wersji R81. Można o tym poczytać tutaj, jednak to wszystko jest na etapie testów i nie ma pewności co do stabilności pracy).

Przy podłączeniu zewnętrznego urządzenia otrzymujemy następujący schemat:

Jak widać na schemacie — pojawia się wąskie miejsce na styku z Zapora. Należy to uwzględnić w dalszym planowaniu sieci i optymalizacji ruchu sieciowego.

Jednak wróćmy do pierwotnego zadania routingu między VRF. W wyniku dodania Zapory dochodzimy do sytuacji, w której Zapora musi wiedzieć o wszystkich VRF. W tym celu na brzegowych Leaf muszą być również skonfigurowane wszystkie VRF, a Zapora musi być podłączona do każdego VRF osobnym łączem.

W rezultacie schemat z zaporą ogniową:

To znaczy, na zaporze ogniowej należy skonfigurować interfejs w każdej VRF w sieci. Ogólnie rzecz biorąc, logika wydaje się nie skomplikowana, a jedyną rzeczą, która może budzić wątpliwości, jest ogromna liczba interfejsów na zaporze ogniowej, ale warto pomyśleć o automatyzacji.

Dobrze. Podłączyliśmy zaporę ogniową, dodaliśmy ją do wszystkich VRF. Ale jak teraz sprawić, aby ruch z każdego Leaf przechodził przez tę zaporę ogniową?

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

0.0.0.0/0, ubest/mbest: 1/0
    *via 10.254.13.55, [1/0], 6w5d, statyczny       ! domyślna trasa przez zaporę ogniową

Jednak jak rozwiązać problem zdalnych Leaf? Jak przekazać im zewnętrzną domyślną trasę?

Dokładnie, przez EVPN route-type 5, tak jak każdy inny prefiks w fabryce VxLAN. Jednak nie wszystko jest takie proste (jeśli mówimy o Cisco, bo nie sprawdzałem u innych dostawców)

Ogłoszenie domyślnej trasy musi być z Leaf, do którego jest podłączona zapora ogniowa. Jednak aby przekazać trasę, Leaf musi ją sam znać. I tutaj pojawia się pewien problem (może tylko u mnie), trasę trzeba zapisać statycznie w tym VRF, w którym chcesz ogłosić taką trasę:

vrf context PROD10
    ip route 0.0.0.0/0 10.254.13.55

Następnie w konfiguracji BGP przypisz 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 domyślna trasa nie trafi do rodziny l2vpn evpn. Oprócz tego należy skonfigurować redystrybucję:

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 trafią do BGP przez 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 przechodzi do EVPN route-type 5 i jest przekazywany innym 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 - Virtual address Leaf (as Leaves act as VPS pairs), connected to the Firewall

W tabeli BGP również możemy zobaczyć otrzymaną trasę type 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

Kończymy cykl artykułów poświęconych EVPN. W przyszłości postaram się omówić działanie VxLAN w połączeniu z Multicast, ponieważ ten sposób uważa się za bardziej skalowalny (obecnie jest to kontrowersyjne stwierdzenie).

Jeśli jednak masz pytania lub propozycje dotyczące rozważenia jakiejkolwiek funkcjonalności EVPN — napisz, omówimy to dodatkowo.

Źródło: habr.com