skalowanie sieci IP część 3 – LISP

w poprzednim odcinku serii zajęliśmy się optymalizacją projektu sieciowego przez agregację adresów przy wykorzystaniu mechanizmów routingu dynamicznego. rozwiązanie może być doskonałe (i co wielokrotnie zweryfikowano w praktyce, przy dobrze zaprojektowanej adresacji wręcz zbawienne), ale nie zawsze daje się je zastosować efektywnie.

w tej części zajmiemy się innym podejściem do skalowania sieci IP – sieci nakładkowej.

LISP

LISP, czyli Locator/ID Separation Protocol, to koncepcja opakowania ruchu pomiędzy lokalizacjami w sieci IP. żeby nie wprowadzać nowej semantyki adresacji i zmieniać już wdrożonych sieci (w szczególności – urządzeń rozumiejących działanie protokołu IP) twórcy LISPa założyli, że adres IP w znanej, 32 lub 128-bitowej formie może mieć logicznie dwa różne znaczenia:

  • RLOC czyli lokalizacje routingu (ang. routing locators), określające gdzie pakiet powinien dotrzeć – RLOC stanowiący cześć przestrzeni adresowej IPv4 czy IPv6 jest zatem analogiczny do całego adresu “normalnego” adresu IPv4 czy IPv6;
  • EID czyli identyfikatory punktów końcowych (ang. endpoint identifiers), określa do którego konkretnie hosta (lub aplikacji, usługi) miałby ruch dotrzeć; adresy EID są schowane za nagłówkiem zawierającym adresy RLOC a zatem nie powodują problemów z obsługą ruchu w tranzycie – w szczególności, pakiet IPv4 może transportować ruch pomiędzy EID dla IPv6 lub odwrotnie;

Widać tu pewne podobieństwa np. do MPLS – przy czym zamiast zupełnie nowego formatu pakietów (z etykietą MPLS) mamy znany i dziedziczący wszystkie zalety działania w internecie – nagłówek IP.

Rzućmy okiem na poniższy rysunek:

Przykładowa sieć LISP

Przykładowa sieć LISP

Na pierwszy rzut oka widzimy dwie osobne przestrzenie adresowe IPv4 – czerwoną (zawierającą adresy RLOC, czyli lokalizacje pomiędzy którymi wykonujemy routing LISP) oraz niebieską (zawierającą adresację naszych hostów). Równie dobrze możemy narysować taki schemat dla dowolnego zestawu protokołów – IPv4 ponad IPv4 (jak na rysunku), IPv4 ponad IPv6, IPv6 ponad IPv6 oraz IPv6 ponad IPv4.

Ta elastyczność to dodatkowy punkt dla LISP – możemy dzięki niej bardzo prosto budować wyspy IPv6 ponad siecią IPv4

LISP transportując ruch pomiędzy specjalnymi bramami, nazywanymi ITR (ang. Ingress Tunnel Router, czyli router wejściowy dla domeny LISP) oraz ETR (ang. Egress Tunnel Router, czyli router wyjściowy dla tej domeny) opakowuje ruch użytkownika w nagłówek IP/UDP.

ITRy i ETRy praktycznie w każdej topologii używane są równocześnie i stanowią ten sam węzeł, dlatego nazywa się je dla uproszczenia xTRami – i taką konwencję będę stosował dalej żeby uniknąć zamieszania.

xTR na podstawie sprawdzenia adresu docelowego w pakiecie otrzymanym z domeny LISP (np. od naszego hosta w sieci domowej), w oparciu o zewnętrzną usługę (o tym za chwilę) podejmuje decyzję o opakowaniu pakietu (dla danego adresu docelowego istnieje mapowanie wskazujące na węzły xTR) lub routingu bez dodawania dodatkowych nagłówków (jeśli takiego mapowania nie ma, lub upłynie czas jego rozwiązania). W przypadku znalezienia mapowania, ruch kierowany jest według stworzonej przez docelowy RLOC polityki routingu do jednego lub większej ilości xTRów do tego RLOCa.

Warto zwrócić uwagę, że zewnętrzne systemy autonomiczne posługują się tylko adresacją RLOC (adresy 11.x oraz 12.x) nie dostrzegając i nie wnikając w ogóle w wyższe warstwy transportowane w pakietach LISP.

Mechanizm sprawdzania mapowań, analogiczny nieco do usługi DNS, jest kluczowy w skalowalności LISP – pozwala dynamicznie budować polityki routingu, ale również rozgłaszać nowe dostępne sieci RLOC/EID oraz wygaszać już nieużywane lub nieaktualne. W najgorszym wypadku – ruch z EID zostanie wysłany bezpośrednio do Internetu bez żadnego dodatkowego nagłówka – w tym przypadku od twórcy systemu zależy, czy takie rozwiązanie będzie akceptowalne czy nie.

Zatem gdzie tu optymalizacja?

Warto zwrócić uwagę, że zewnętrzne w stosunku do naszego, systemy autonomiczne nie realizują routingu dla sieci z identyfikatorami EID. O ich dostępność i odpowiednią politykę routingu dba usługa katalogowa, zewnętrzna w stosunku do protokołu routingu. Czy to oznacza lepszą skalowalność? Cóż, system DNS przechowuje zdecydowanie więcej wpisów (zarówno objętościowo jak i ilościowo) niż nawet najbardziej rozbudowana tablica BGP, prawda?

LISP jest najlepszy?

LISP jest doskonałym narzędziem np. do:

  • agregacji informacji routingowej dzięki RLOCom – w zależności od możliwego planu adresacji
  • obsługi routingu do i od wielu operatorów, włącznie z bardzo zaawansowaną inżynierią tras, niedostępną za pomocą tradycyjnych mechanizmów BGP
  • uproszczenia realizacji routingu dla węzłów/systemów autonomicznych posiadających bardzo dużo styków z innymi sieciami
  • wsparcia migrację z protokołu IPv4 do IPv6, ale i współistnienie tych protokołów

Oczywiście, dzisiejszy Internet w całości nie przeszedł jeszcze na używanie LISPa, choć nie ma takiej potrzeby – korzystać mogą z niego prywatne firmy do zapewnienia komunikacji na własne potrzeby, choć jak łatwo sprawdzić, LISPa używa również Google, Facebook i parę innych firm. Jest to związane z elastycznością budowy polityk routingu (w tym inżynierii ruchowej). LISP jako protokół nakładkowy ma jednak również pewne wady:

  • wymaga uruchomienia systemu rozwiązywania RLOC lub stworzenia takich mapowań statycznie na wszystkich xTRach – nie ma dzisiaj jednej, uniwersalnej usługi o którą można się oprzeć; testowa usługa ALT utrzymywana przez Cisco i instytucje badawcze jest jak sama nazwa wskazuje – testowa;
  • LISP oznacza dodatkowy nagłówek, czyli narzut; co więcej, nagłówek ten może prowadzić do polaryzacji ruchu sieciowego, choć przedsięwzięto odpowiednie kroki, by tego uniknąć (m. in. przez losowanie hashy dla portów źródłowych w nagłówku UDP pakietu pomiędzy węzłami xTR)
  • to dodatkowy control-plane, który może zawieść – gdzie wtedy skończą Twoje pakiety?

To co dalej z tym LISPem?

LISP nie jest problematyczny we wdrożeniu, jeśli mamy dostęp do obsługującego go sprzętu czy oprogramowania i chęć przyjrzenia się mu w praktyce. Cisco wydzieliło z własnej przestrzeni adresowej prefiks IPv4 do eksperymentów z LISPem. Dzięki temu i niżej podpisany miał okazję uruchomić LISP we własnej sieci, a demonstracyjne wdrożenie LISPa odbyło się również w trakcie jednego z PLNOGów.

W kolejnej części artykułu opiszę szczegóły testowego wdrożenia LISPa na PLNOG #5. Zajmiemy się w nim detalami działania usługi rozwiązywania EID na RLOCi, konfiguracją sprzętu oraz zmierzymy z praktycznymi obserwacjami z działania takiej sieci.

Linki

Facebooktwittergoogle_plusredditpinterestlinkedinmail

7 thoughts on “skalowanie sieci IP część 3 – LISP

  • 1) Jeszcze bym dodal ze LISP dobrze sprawdza sie w migracjach hot i cold. Przy czym w hot wymagane jest L2 miedzy xTR.
    2) Nie wspomniales o PTR ktory zapewnia symetryczny ruch w przypadku migracji hosta

  • To jak już lecimy… :)
    “dla danego adresu docelowego istnieje mapowanie wskazujące na węzły ETR”
    “do jednego lub większej ilości ETRów do tego RLOCa”
    ” dodatkowy control-plane, który może zawieść” – zawieźć też może, ale nie o to chyba szło :)
    Generalnie I z E pozamieniałeś często-gęsto. Obrazek jest git, z niego wszystko widać (PTRy* bym dorzucił co prawda, i może MAPy – obecnie zwane DDTami, ALT odchodzi w niepamięć pomału), jak w slajd 18.

    * ja wiem, PxTR, ale kaman.

    PS. I możesz śmiało te komenty wykasować, one raczej stylistyczne.

  • A, i to ITR (a nie ETR jak w tekście) decyduje czy enkapsułować czy nie. “Opakowanie” dziwnie brzmi (jak i te “sieci nakładkowe” i “IP4 ponad IP4”).
    Wot, nienawykłym do spolszczania.

Komentarze są niedostępne