Obsługa BUM w ACI
Taha Yusuf
Ruch BUM składa się z:
- Broadcast – pakiety wysyłane do wszystkich hostów w tej samej domenie warstwy 2
- Unknown Unicast – pakiety przesyłane do nieznanych adresów MAC
- Multicast – pakiety wysyłane do wybranych, a nie wszystkich hostów
Tradycyjne mechanizmy obsługi tego rodzaju ruchu nie działałyby w architekturze VXLAN, dlatego ACI korzysta z dwóch specyficznych metod replikacji ruchu BUM.
Replikacja multicastowa
Replikacja multicastowa wykorzystuje protokół PIM (Protocol Independent Multicast) oraz MP-BGP EVPN do dostarczania ruchu BUM. Zastosowana jest ona głównie w warstwie 3 (podwarstwie).
Przepływ ruchu:
- Przełączniki (spine i leaf) używają protokołu PIM w trybie źródłowym (PIM-SM)
- Adresy grup multicastowych dla VTEP są przydzielane dynamicznie. Ruch BUM jest wysyłany do członków danej grupy.
- Gdy maszyna wirtualna (endpoint) wysyła ruch BUM, przełącznik leaf, do którego jest podłączona, enkapsuluje VXLAN i przesyła do grupy multicastowej.
- Przełączniki spine działają jako reflektory tras (route reflector) oraz punkty ześrodkowania (Rendezvous Point) dla grup multicastowych. Przełączniki leaf subskrybują odpowiednie grupy multicastowe na podstawie rekordów EVPN.
Replikacja ingress (Headend)
Replikacja ingress, nazywana także "na głowicy", nie wykorzystuje w ogóle multicastu, a działa na warstwie nakładki VXLAN. Przełącznik źródłowy (ingress leaf) przesyła osobną kopię pakietu BUM, otoczoną w kapsułkę VXLAN, bezpośrednio do każdego przełącznika odbiorczego.
Przepływ ruchu:
- Gdy punkt końcowy wysyła ruch BUM, przełącznik źródłowy sprawdza tabelę mapowania VXLAN.
- Przełącznik tworzy wiele kopii tego samego pakietu i przesyła każdą z nich w osobnej kapsułce unicastowej VXLAN do przełącznika odbiorczego.
- Przełączniki odbiorcze dekapsulują pakiet VXLAN i przesyłają go do odpowiedniego lokalnego punktu końcowego.
Kluczową kwestią jest zapewnienie, aby ruch warstwy 2 był poprawnie dystrybuowany w sieci warstwy 3. Replikacja BUM pozwala na dostarczanie pakietów adresatom w ACI, tak jakby znajdowali się w tej samej domenie.
Komunikacja między węzłami w sieci - IP vs CLNP
Zarówno TCP/IP, jak i CLNP wykorzystują podobny mechanizm komunikacji z sąsiednimi węzłami, polegający na mapowaniu adresów protokołu sieciowego na adresy MAC warstwy łącza danych.
W świecie TCP/IP odbywa się to za pośrednictwem zapytań ARP (Address Resolution Protocol) dla IPv4 lub sąsiedzkich wyszukiwań ND (Neighbor Discovery) dla IPv6. Natomiast w CLNP wykorzystywany jest protokół ES-IS (End System - Intermediate System), który umożliwia wzajemne wykrywanie węzłów końcowych i routerów w ramach podsieci.
Prawdziwe wyzwanie pojawia się, gdy dwa węzły chcą komunikować się pomimo przynależności do różnych podsieci. W takim przypadku wymagana jest obecność routera mogącego przesyłać pakiety między podsieciami. I tutaj właśnie zaczynają się różnice między stosami TCP/IP a CLNP.
Podejście TCP/IP
W świecie TCP/IP odnajdywanie routera odpowiedzialnego za komunikację między podsieciami nie było łatwe. Protokół IPv4 nie przewidywał żadnego standardowego mechanizmu do tego celu. Zazwyczaj hosty posiadały statycznie skonfigurowaną trasę domyślną wskazującą na adres IP routera jako następnego przeskoku.
W późniejszym okresie zaimplementowano możliwość konfiguracji routera domyślnego przez serwer DHCP, ale rozwiązanie to wciąż wymagało konfiguracji statycznej. Dodatkowo pojawiały się problemy w przypadku wielu routerów współdzielących adres IP jako trasę domyślną. Producenci, tacy jak Cisco, musieli opracować własne protokoły (np. HSRP, GLBP) do obsługi tego scenariusza, choć wciąż utrudnione było zrównoważone wykorzystanie wszystkich routerów.
Dopiero protokół VRRP (Virtual Router Redundancy Protocol) wprowadził standaryzację i obsługę redundancji dla IPv4 i IPv6. Jednak nawet VRRP nie rozwiązuje całkowicie problemu przejściowych przerw w łączności podczas przełączania routerów.
Podejście CLNP
Protokół CLNP z modelu OSI nie borykał się z tymi problemami. Routery okresowo wysyłały komunikaty ISH (Intermediate System Hello), informując węzły końcowe o swojej obecności. Węzły gromadziły te informacje w pamięci podręcznej i po stwierdzeniu, że dany węzeł jest spoza podsieci, po prostu przesyłały do niego pakiety za pośrednictwem najbliższego routera.
W świecie CLNP hosty mogły swobodnie wybierać spośród wielu dostępnych routerów, a równoważenie obciążenia między nimi było naturalnym procesem. Co więcej, protokół IPv6 zaczerpnął wiele z tych rozwiązań, implementując komunikaty Router Advertisement (RA), będące odpowiednikiem ISH z CLNP.
(Nieoficjalny) podręcznik do CCNP-SP
Ten przewodnik po SP przypomina bardziej zeszyt ćwiczeń niż tradycyjny podręcznik. Artykuły zaczynają się od podstawowych informacji i teorii, a następnie przechodzą do sekcji "Laboratorium", gdzie znajdziesz diagram topologii oraz kod konfiguracyjny, który umożliwia szybkie zbudowanie własnego laboratorium.
Zestawienie firewalli Fortigate
Yuri Slobodyanyuk
Strona zajmuje się gromadzeniem danych na temat różnych modeli Fortigate poprzez polecenie get hardware stat. Jeśli posiadasz model, który nie jest wymieniony, zachęcamy do przesłania wyników na adres yuri@yurisk.info, co przyniesie korzyści całej społeczności. Zauważ, że różne rewizje tego samego modelu mogą mieć różne specyfikacje, jak np. pamięć RAM. Dzięki tym informacjom możesz lepiej porównać różne modele i ich parametry, co ułatwi podjęcie decyzji przy wyborze odpowiedniego urządzenia.
Dlaczego Cilium jest #1 CNI dla K8S?
Przeczytaj całą historię
Zarejestruj się teraz, aby przeczytać całą historię i uzyskać dostęp do wszystkich postów za tylko dla płacących subskrybentów.
Subskrybuj