VxLAN – przyczyny powstania i zasada działania

W dzisiejszym materiale porozmawiamy o technologii, która jakiś czas temu weszła przebojem na rynek sieciowy i teraz jest integralną częścią wielu wyrafinowanych i naprawdę potężnych produktów, z NSX-em od VMware i Cisco ACI na czele. Technologia ta to VxLAN. W tym materiale odpowiem na pytanie dlaczego potrzebne było powstanie tego protokołu i jaka jest zasada jego działania. Aby ta publikacja miała rozsądną długość, szczegóły techniczne oraz konfiguracja będą przedstawione w osobnym materiale.

Retrospektywa – jak było kiedyś?

Nasze rozważania na temat VxLAN’ów zacznę od retrospektywy, która pozwoli Ci lepiej zrozumieć dlaczego w ogóle taka technologia powstała. W świecie sieci komputerowych jest tak, że mamy do czynienia z bardzo szerokim zbiorem różnych technologii zwanych też protokołami. Każdy protokół jest tak naprawdę odpowiedzią na konkretny problem. Tak było np. w przypadku protokołu STP, który powstał jako odpowiedź na problem zapętlania się ruchu we wczesnych odsłonach sieci Ethernet.

STP rozwiązuje problem blokując nadmiarowe łącza:

STP w bardzo uproszczonej formie
STP w bardzo uproszczonej formie

Więcej o niuansach powstania STP i jego mechanizmach przeczytasz w książce Interconnections Second Edition Radii Perlman, będącej zresztą autorką STP. Fascynująca i bardzo ciekawa lektura, którą gorąco polecam.

Wróćmy tymczasem do naszej retrospektywy. Aby zrozumieć dlaczego powstała technologia VxLAN i jaki problem ona rozwiązuje przyjrzyjmy się szybko temu w jaki sposób ewoluowały sieci na przestrzeni ostatnich lat. Do dziś jest bardzo powszechne sztywne trzymanie się hierarchicznego, trzypoziomowego modelu sieci spopularyzowanego przez Cisco. Zgodnie z tym modelem sieć dzielimy na trzy warstwy: Core, Distribution oraz Access, a urządzenia sieciowe w każdej z tych warstw pełnią inne role i posiadają różne specyfikacje:

Trzypoziomowy model sieci. Linki L2 niebieskie, linki L3 pomarańczowe
Trzypoziomowy model sieci. Linki L2 niebieskie, linki L3 pomarańczowe

W mniejszych sieciach możemy scalić warstwy Core oraz Distribution w jedną i uzyskać tzw. Collapsed Core:

Collapsed core
Collapsed core

Pierwszą odsłoną sieci opartych o tego typu topologie są sieci z segmentacją ruchu na poziomie VLANów. Każdy VLAN stanowi osobną domenę rozgłoszeniową i tradycyjnie jest mapowany jeden do jednego z dedykowaną mu podsiecią. Możemy mieć na przykład więc do czynienia z VLANem 20 dla pracowników działu finansowego, mapowanym na podsieć 192.168.20.0/24. Jeżeli pracownicy tegoż działu znajdują się w różnych fizycznych lokalizacjach to naturalną koleją rzeczy jest rozciąganie VLANów pomiędzy poszczególnymi przełącznikami warstwy dostępowej:

Rozciąganie VLANów między przełącznikami dostępowymi
Rozciąganie VLANów między przełącznikami dostępowymi

Takie VLANy rozciągają się rzecz jasna przez przełączniki dystrybucyjne pełniące rolę bramy domyślnej. Wykorzystujemy również dodatkowe protokoły takie jak STP, VRRP lub HSRP. Problem jaki niesie ze sobą taki design jest następujący: usterka w jednej części sieci jest propagowana na wiele urządzeń ponieważ rozciągnęliśmy domeny rozgłoszeniowe.

Rozległe domeny rozgłoszeniowe powodują szeroką propagację usterek
Rozległe domeny rozgłoszeniowe powodują szeroką propagację usterek

Kolejnym problemem jaki można tu zaobserwować jest zwiększona ilość ruchu północ-południe, który nie jest czymś pożądanym. Szacuje się, że w sieciach kampusowych, a już zwłaszcza w sieciach typu data centre, około 80% ruchu to ruch relacji wschód-zachód (komunikacja między klientami, serwer do serwera, replikacje danych, migracje wirtualnych maszyn z użyciem VMotion itp). Trójpoziomowa topologia sieci wymusza dużą ilość dodatkowego ruchu północ-południe dla komunikacji oryginalnie będących ruchem wschód-zachód.

Ruch północ-południe i wschód-zachód w sieci
Ruch północ-południe i wschód-zachód w sieci

Ostatnim problemem z jakim mamy tu do czynienia jest obecność STP, którego generalnie czym mniej w sieci tym lepiej.

Retrospektywa – jak było wczoraj?

Problemy wymienione w poprzednim rozdziale następnie rozwiązano oferując kilka usprawnień. Największym z nich było rozciągniecie warstwy trzeciej aż do warstwy dostępowej topologii i wprowadzenie protokołów routingu w miejsce przestarzałego i problematycznego STP:

Trzypoziomowy model sieci. Linki L3 pomarańczowe
Trzypoziomowy model sieci. Linki L3 pomarańczowe

Zachowany nadal został trzypoziomowy model sieci, zwiększyła się natomiast konwergencja takiej sieci. Zmiana niosła za sobą konieczność przesunięcia bram domyślnych z warstwy dystrybucyjnej do warstwy dostępowej. Ponadto, koniecznością stało się stosowanie lokalnych VLANów, nie wykraczających swoim zasięgiem poza pojedynczy przełącznik warstwy dostępowej.

Rozwiązało to problem nazbyt propagujących się awarii i generalnie okazało się być znakomitym rozwiązaniem w znacznej części przypadków – wszakże mając cztery piętra w budynku i na każdym z nich pracowników działu finansowego, możemy stworzyć cztery osobne VLANy powiązane z czterema osobnymi podsieciami. Ruch pomiędzy tymi segmentami następnie możemy kontrolować za pomocą zapory sieciowej.

I wszystko byłoby pięknie gdyby nie to, że nadal mamy często do czynienia z aplikacjami/serwerami/technologiami, które wymagają możliwości komunikacji po warstwie drugiej w celu poprawnego działania. Topologia oparta w pełni o warstwę trzecią jest oczywistym pogwałceniem tego wymogu i w pewnym momencie staje się to bardzo problematyczne. Skala problemu staje się jeszcze bardziej wyraźna w środowisku Data Center gdzie przenoszenie wirtualnych maszyn z użyciem VMotion wymaga rozpinania warstwy drugiej pomiędzy różnymi urządzeniami sieciowymi. A co gdy mamy do czynienia z dostawcą usług internetowych, który dodatkowo musi jeszcze odseparować poszczególnych klientów? W tym momencie robi się już naprawdę trudno. No i nadal nie rozwiązaliśmy problemu dużej ilości ruchu północ-południe.

Stan obecny – jak jest dzisiaj?

Jak widać w poprzednich dwóch rozdziałach, rozwiązanie jednego problemu bardzo często rodzi kolejny i działa to niczym miecz obosieczny. Wprowadzając warstwę trzecią w niemalże całej topologii i eliminując STP uzyskano pozytywny rezultat jeśli chodzi o konwergencję i wydajność sieci. Straciła ona jednak na funkcjonalności. Zanim przejdziemy już do VxLANów, spójrzmy jeszcze na szybko na problem nadmiarowego ruchu północ-południe. Cisco rozwiązało ten problem cofając się aż do lat 50-tych XX wieku, kiedy to zaproponowano w sieciach telefonicznych topologię zwaną clos. Odchodzimy w tym momencie od trzypoziomowej hierarchii sieci na rzecz struktury dwupoziomowej. Składa się ona z przełączników spine oraz leaf, tworzących między sobą pełną siatkę połączeń warstwy trzeciej.

Topologia clos
Topologia clos

Warto zwrócić uwagę, że takich połączeń nie ma pomiędzy poszczególnymi spine’ami oraz leaf’ami. Urządzenia końcowe podłączamy do leaf’ów, tam też umieszczamy wszelkie połączenia na zewnątrz sieci, urządzenia typu IPS, zapory sieciowe itp.

Przełączniki spine pełnią natomiast rolę wysokoprzepustowego szkieletu sieci nazywanego fabryką (ang. fabric) [edycja: trzymajmy się nazywania wspomnianego szkieletu sieci jego angielskojęzycznym terminem – czyli fabric. Jak się okazuje polski termin „fabryka” jest dość kontrowersyjny. Więcej szczegółów na ten temat w komentarzach pod artykułem.]

Warto zwrócić uwagę na to, że naturalną konsekwencją takiego designu jest posiadanie tylko jednego przeskoku (ang. hop) w trakcie routowania ruchu pomiędzy poszczególnymi urządzeniami końcowymi. W ten oto sposób rozwiązano m.in. problem dużej ilości ruchu północ południe.

Dzięki topologii clos między hostami jest tylko jeden skok
Dzięki topologii clos między hostami jest tylko jeden skok

Co jednak z tą nieszczęsną i wszechobecną warstwą trzecią wchodzącą nam niejako klinem w wymóg rozpinania warstwy drugiej między różnymi przełącznikami (w przypadku sieci clos między leaf’ami)?

Tutaj właśnie wkracza do akcji VxLAN!

Czym jest VxLAN i jaki problem rozwiązuje?

VxLAN, czyli z angielskiego Virtual eXtensible Local Area Network jest protokołem stworzonym przez Cisco we współpracy z VMware oraz Aristą. Jest on dziś powszechnie implementowany w rozwiązaniach różnych vendor’ów, a to za sprawą standaryzacji (RFC 7348).

Gdybym miał określić złożoność tej technologii i odnieść ją do świata certyfikacji to bym powiedział, że zrozumienie zasady działania VxLAN jest zagadnieniem na poziomie CCNP. Pełne zrozumienie działania tego protokołu wymaga jednak wejścia przynajmniej całą jedną nogą i palcami drugiej w zagadnienia na poziomie CCIE. Głowa może zaboleć o czym się zresztą zaraz przekonamy.

VxLAN rozwiązuje problem konieczności rozpinania warstwy drugiej pomiędzy odległymi od siebie hostami. W zasadzie jest to dokładnie to co VxLAN robi – rozpina warstwę drugą pomiędzy hostami, wykorzystując do tego istniejącą sieć opartą głównie o warstwę trzecią. Brzmi skomplikowanie? Zaraz się wyjaśni nieco więcej.

Zacznijmy od przyjrzenia się sieci podkładowej (ang. underlay), czyli naszemu szkieletowi na bazie którego będziemy wdrażać VxLAN. Można również wymiennie stosować nazwę “sieć transportowa”. Underlay jest tak naprawdę bardzo prostą siecią, złożoną z urządzeń połączonych linkami warstwy trzeciej, a najczęściej spotykaną topologią jest opisany wcześniej clos. Do routingu w tej sieci wykorzystać możemy dobrze znane protokoły takie jak OSPF, EIGRP czy też IS-IS. Głównym zadaniem sieci podkładowej jest zapewnienie pełnej łączności między poszczególnymi przełącznikami dostępowymi / leaf’ami w topologii. W tak zaprojektowanej sieci zyskamy również na wykorzystaniu ECMP (Equal Cost Multi Path).