Podkast 22T48 VXLAN i GENEVE – Sieci Nakładkowe

WERSJA TEKSTOWA

Cześć. Witam Cię w dzisiejszym odcinku mojego podkastu. Temat to VXLAN i GENEVE, czyli stary i nowe protokoły enkapsulacji danych. O co tutaj chodzi? Przede wszystkim jeżeli chodzi o nowoczesne sieci w rozumieniu głównie ośrodków przetwarzania danych (ale nie tylko bo SD-WAN jest takim przykładem sieci rozległych) generalnie nowoczesne sieci idą w stronę sieci nakładkowych. Po co? Po to, żeby się oderwać od ograniczeń sprzętowych i móc nowoczesne, programowe funkcje realizować w kontekście różnych programowych aplikacji, które realizują konkretną funkcjonalność np. bezpieczeństwa, analizowania pakietów przepływających przez sieć. Innym elementem jest optymalizacja realizacji ścieżki przepływu. Albo wielościeżkowości. Inny przykład to badanie jakości połączenia (w kontekście SD-WANu i wykorzystywanie aplikacji, która kieruje ruchem w kontekście aktualnej sytuacji jakości łącza. Czyli idziemy jeżeli chodzi o taki długofalowy horyzont w stronę sieci programowalnych w różnych obszarach.

Jeżeli chodzi o programowalne sieci to, żeby móc łatwiej współpracować z istniejącą infrastrukturą i nie być ograniczonym to stosuje się enkapsulację, czyli pakiet w pakiecie się zamyka i wysyła przez sieć. Jak to wygląda w praktyce jeśli chodzi o enkapsulację? Najczęściej wykorzystuje się protokół UDP w obu wymienionych protokołach, które wspomniałem. Jest to protokół bezpołączeniowy. Wykorzystuje się też najczęściej nagłówek IP, czyli idziemy w adresacji standardowej IPv4 albo IPv6. Chodzi o to, że budujemy sobie albo już mamy istniejącą infrastrukturę IP. Niezależnie od tego jaka to jest technologia, producent i jaką architekturę wybraliśmy, to mamy jakąś strukturę IP. Na tą strukturę możemy nałożyć tunele. Działa to w taki sposób, że mamy oczywiście jak to przy tunelach dwa punkty: wejście do tunelu i wyjście z tunelu. Gdy mówimy o przykładzie VXLAN to punkt wejścia może być dwojaki. Albo to jest po prostu system software czyli w ramach oprogramowania już na danym serwerze mamy wejście do tego tunelu VXLAN bądź opcja druga czyli VTEP – taka brama sprzętowa, która podłącza nam różne inne urządzenia sieciowe, hosty końcowe przez po prostu fizyczne podłączenie dla serwerów, które nie są zwirtualizowane. Są fizycznym serwerem i kablem łączymy ten fizyczny serwer z jakimś gatewayem VXLAN’owym. VTEP jest właśnie do tego, żeby terminować takie fizyczne serwery, na których nie mamy możliwości programowo stworzyć takiego wejścia do tunelu.

Następnie jak mamy te tunele to możemy wtedy tą zaawansowaną logikę zastosować. Możemy powiedzieć jaki host z jakim hostem może się łączyć, możemy to dynamicznie modyfikować. Możemy kreować ścieżki przepływu w zależności od tego jaką mamy potrzebę i jaką mamy politykę. Nie dotyka to w zupełności tej warstwy sprzętowej. Jeśli chodzi o drugi protokół GENEVE, czyli kolejna generacja protokołu enkapsulowania, to jest protokół, który został zaproponowany do zastosowań przede wszystkim chmurowych. Czyli jeśli patrzymy dzisiaj na dostępność protokołu VXLAN to mamy możliwość na wielu urządzeniach różnych producentów skonfigurować sobie taki interfejs. Możemy najczęściej skonfigurować sobie jeśli chcemy tylko do zastosowań laboratoryjnych i zrobić to po prostu manualnie konfigurując dane urządzenie sieciowe od strony wejścia do tunelu i wyjścia z tunelu. Największa wartość jest w dynamicznym sterowaniu tworzenia, usuwania tuneli i przekierowywania ruchu w zależności od naszej polityki.

Problem się pojawił taki: jeśli popatrzymy sobie na przykład konkretnej implementacji w Ośrodku Przetwarzania danych, czyli weźmy sobie tutaj NSX jako taki typowy przykład popularny dzisiaj na rynku implementacji sieci nakładkowych po to, żeby móc w tym naszym środowisku serwerowym dynamicznie kreować sobie takie środowisko, którym możemy zarządzać aplikacyjnie. Pierwotnie ten pomysł opierał się na vSphere czyli na wirtualizatorze WMRa, który był od lat dostępny i do tego dodano wykorzystanie protokołu VXLAN czyli możliwość kreowania tego typu środowisk.

Potem się okazało, że jest pewne ograniczenie w miejscach, gdzie tego vSphere nie ma. Czyli możemy sobie wykupić jakieś usługi w AWSie, w chmurze Google, w AZURE i tam nie będziemy mieli możliwości zainstalowania klasycznego vSphere, jakiego do tej pory mogliśmy używać w naszej serwerowni, jeśli kontrolowaliśmy całe środowisko. Tutaj pojawił się problem, że ten WxLAN ma pewne ograniczenia w takich środowiskach no i w związku z tym w takiej nowej wersji NSXa czyli NSX-T VMware stworzył to rozwiązanie bazujące na nowym typie tunelowania, czyli GENEVE.

Czym się różnie VXLAN od GENEVE i jak możemy te protokoły porównać? Pierwszym podstawowym założeniem nowego protokołu było danie możliwości rozszerzania tego protokołu o nowe opcje. Jeśli chodzi o VXLAN to tutaj mamy 24 bity identyfikatora naszego tunelu i jeżeli się okaże, że w przyszłości będzie potrzebnych więcej tych tuneli albo trzeba będzie inną opcję zastosować, żeby móc nowy protokół dostosować do tego co potrzebujemy, to VXLAN takiej możliwości nie da. Po prostu został on wymyślony jak większość protokołów na sztywno i tak został zaimplementowany.

W nowym protokole GENEVE jest inna koncepcja. Tak jak w BGP mamy możliwość zastosowania różnych opcji tego protokołu a dzięki temu wykorzystując szeroko zaimplementowany protokół możemy dodawać nowe funkcje, nowe sposoby działania do tego protokołu. Protokół enkapsulacji GENEVE ma możliwość robienia właśnie tego. Czyli mamy możliwość zadefiniowania długości informacji o opcji. Nie jest to pole na sztywno zdefiniowane tylko jak popatrzysz sobie na nagłówek to tam jest takie pole, które określa jaki długie będzie pole związane z opcjami. Oznacza to, że w przyszłości będzie można dodawać nowe opcje i rozwijać w oparciu o ten protokół i o ten schemat kolejne nowe funkcjonalności. Z tego powodu WMware stwierdził w nowym produkcie NSXT, że zdecyduje się na nowy protokół enkapsulacji żeby mieć większą elastyczność pracowania w przyszłości z tym protokołem. Jak wiadomo, jeśli zostanie szeroko wdrożony, tak samo jak protokoły routingu, wspomniany BGP, to jest to w zasadzie bardzo trudna sytuacja do zmiany.

Taka sama sytuacja jest z IPV4. Protokół na stałe zafiksowany jeśli chodzi o identyfikatory, zakres. Nie da się go zmienić. Trzeba emigrować na IPV6. A jeśli szeroko zaimplementowany to jest to po prostu bardzo trudne. Dziś tyle chciałem Ci opowiedzieć o tych dwóch protokołach. Bez wątpienia nowy protokół jest warty uwagi. Sprawdzałem ostatnio zakres implementacji na innych urządzeniach, takich producentów sprzętowych i narazie jest ta implementacja niewielka więc pewnie trzeba jeszcze trochę poczeka. Na Open vswitchu nowa enkapsulacja GENEVE powinna już być dostępna. Widziałem, że już od 2014 roku są wzmianki na ten temat w związku z tym tam już zapewne to działa całkiem nieźle.

Ponieważ założenie jest takie, że będziemy tutaj bazować tylko na software’oych gatewayach to w zasadzie nie ma żadnego powodu, żeby był jakoś bardzo mocno implementowany na sprzętowych routerach czy przełącznikach. Z resztą nawet widać w NSX-V czyli w tym obecnym NSXie, który jest najszerzej dzisiaj zaimplementowany mamy proponowane gatewaye software’owe (oprócz sprzętowych). Są one wystarczająco wydajne. Wydajność rzędu powyżej 20gb/sek. jest możliwa pod jeden taki gateway. To oznacza, że można to środowisko lepiej skalować i że jeśli będziemy implementować w chmurze tego typu rozwiązania to nie mamy ograniczenia sprzętowego. Tak to niewątpliwe będzie wyglądało, jest tylko pytanie w jakim czasie.

W przypadku polskiego rynku mamy tą adopcję dużo wolniejszą. Jeśli chodzi o chmurę a tym samym sieci programowalne w związku z tym będziemy pewnie przyglądać się temu w dłuższym okresie czasu. Natomiast warto się tym interesować bo niewątpliwie to przyjdzie tutaj i co do tego nie mam żadnej wątpliwości. Są pytania oczywiście, który protokół zwycięży, jakie implementacje będą dominowały rynek ale już dziś widać, że sieci programowalne w Data Center to VMware jest tutaj liderem. Jeśli chodzi o sieci SDWAN, czyli WANowe sieci programowalne silny jest także VMware. Widzę też innych graczy w rynku.

Ten rynek jeszcze nie jest mocno ugruntowany ani skonsolidowany, to się pewnie dopiero będzie działo. Natomiast jest bez wątpienia graczem czołowym i warto się mu przyglądać pod kontem tego typu rozwiązań. Jest oczywiście też rozwiązanie SD-WAN’owe w CISCO, SD-WAN’owe w ARUBIE, takie rozwiązanie w Fortinate. Jest ich całkiem sporo, różnią się one. Może kiedyś będę więcej na ten temat opowiadał, zobaczymy jeśli będzie takie zainteresowanie. Daj znać w komentarzu czy interesuje to Ciebie. Wtedy zastanowię się nad opowiadaniem i porównywaniem tych produktów SD-WANowych. Tyczy to się wszystkich obszarów. Jeśli mówimy o Software-defined perimeter czyli SDP, jeżeli mówimy o sieciach zabezpieczanych, czyli np. o rozwiązaniach NACowych czy Zero Trust Access. Wszędzie ten software się pojawia bo chodzi o to, żeby automatyzować i ułatwiać sobie prace. Jednak aby automatyzować trzeba rozumieć jak działa dane rozwiązanie. Więc jeśli potrzebujesz więcej informacji z tego zakresu to oczywiście daj znać. Na dziś to tyle, do usłyszenia za tydzień.