Pod trochu zavádějící zkratkou LISP (nikoli ten funkcionální programovací jazyk plný závorkového šilenství) neboli Locator/ID Split Protocol, se skrývá zapouzdřovací protokol, který se rozhodl podívat se alternativním způsobem na IP adresování zařízení připojených k Internetu. V tomto díle se podíváme na některé zajímavé případy použití LISPu, které vychází z jeho designu, a existující implementace LISP control-plane.
Případy použití
Následující příklady použití vycházejí z existujících scénářů, jak byl LISP s úspěchem nasazen některými ze zákazníků firmy Cisco.
LISP jako tranzitní mechanismus
IPv6 je dnes často skloňovaným pojmem a v zákaznických sítích již běžně přítomným elementem. Problematikou koexistence obou protokolů se zabývali mí kolegové a jistě je potěší, že do toho všeho se dá naroubovat i LISP. Jak víme z prvního dílu, tak map-and-encap princip, jež LISP využívá, umožňuje libovolné IPv4/IPv6 kombinování vnitřních a vnějších hlaviček. Díky tomu můžeme LISP použít k přenosu:
- IPv6 provozu přes IPv4 – kombinace IPv6 vnitřní a IPv4 vnější;
- IPv4 provozu přes IPv6 – kombinace IPv4 vnitřní a IPv6 vnější;
Řešení skrz LISP se vyznačuje minimální přidanou konfigurací na straně aktivních síťových prvků. Navíc oproti jiným tranzitním mechanismů je zcela transparentní z pohledu koncových stanic, které nemusí měnit zhola nic.
Následující příklad využil v roce 2010 FaceBook, kde úkol zněl jasně: „Umožněte přístup k Facebooku klientům připojeným jen skrz IPv6“ (což byla v té době situace u některých asijských operátorů, kteří neměli k dispozici žádné zbývající IPv4 adresy). V té době se o IPv6 Day stále ještě jen šuškalo a FaceBook byl službou běžící čistě na IPv4. Pro webové klienty na IPv6 tak byla tato služba přístupná ledatak skrz NAT-PT, NAT64 či jiná řešení s „vynikající“ responsibilitou.
Tehdejší topologii Facebooku, aspoň podle dostupných kusých informací, si můžeme představit jako několik po světě rozesetých datacenter (zkráceně DC) s nezávislými clustery představujícimi web Facebooku, kde v rámci clusteru je služba rozprostřena mezi více duplicitních virtuálních serverů s tím, že load-balancer dělá DNATování a vybírá, kterému serveru se požadavek zrovna pošle. Topologie těžící z LISPu, jakožto tranzitního mechanismu propojujícího IPv6 ostrůvky skrz IPv4 jádro sítě může vypadat v reále třeba jako na následujícím obrázku. Topologie se skládá z: IPv6 Host jako klient s exkluzivním IPv6 přístupem k Internetu; veřejně provozovaný map resolver a map server MR/MS; tatkéž veřejně provozované PxTR jakožto duální PITR a PETR; a v neposlední řadě cluster Facebooku. Popis obrázku následuje hned za ním:
Cluster je zde složen z hraničního routeru xTR, který zastává duální funkci jak ITR (map-and-encap), tak ETR (registrace EID). K němu jsou připojeny dva rozkládače zátěže (IPv4/6 Load Balancer – zkráceně IPv4/6 LB), kteréžto NATují globálně dostupnou adresu webového serveru (pro IPv4 je to v DNS 173.252.110.27 a pro IPv6 LISPovský EID 2610:db8:face::9) na interní adresu virtuálního počítače clusteru (IP 192.168.3.[7–9]). Jediné místo v síti, kde se v Clusteru vyskytuje a směruje skrz IPv6 je spojnice mezi xTR a IPv6 LB, která je vlastně LISP lokalitou s EID. K tomuto EID pak xTR propaguje jeden dostupný RLOC, a to 10.0.0.1.
Popišme si nyní trochu detailněji případ, kdy IPv6 Host zahájí komunikaci s FaceBookovým serverem (na obrázku žlutá šipka). Internetový prohlížeč přeloží adresu www6.facebook.com na patřičnou IPv6 adresu a odešle paket se zdrojovou adresou hosta (2001:db8:a::1) a cílovou serveru (2610:db8:face::9). PxTR zařízení, jež zastává funkci PITR a PETR, provede zapouzdření paketu z původně neLISP světa do LISP světa, což znamená, že mu přidá LISP hlavičku a dále pak patřičnou IPv4 vnější hlavičku. V ní je jako zdrojová adresa použito rozhraní PxTR (20.0.0.1) a jako cílová pak adresa xTR (10.0.0.1). Paket pak putuje skrz IPv4, přičemž díky LISPu se v něm nese IPv6 – právě toto je místo, kde se LISP projevuje jako možný tranzitní mechanismus! Na xTR pak dojde k odpouzdření a paket se pošle tak jak ho vygeneroval IPv6 Host vstříc IPv6 LB (což je IP adresa serveru Facebooku pro Internet). Na IPv6 LB pak dojde ke DNATnutí (od 192.168.1.1 pro 192.168.3.7), což především zahrnuje i záměnu verze IP protokolu, a paket se pošle opravdovému webovému serveru. Díky LISPu se tak k tehdejšímu IPv4 Facebooku mohli připojit uživatelé s jen IPv6 konektivitou, a to zcela transparentně bez změn na straně webového serveru či koncových klientů – hezké čistě síťové řešení.
Pokud by nás zajímalo, tak modrá šipka ukazuje komunikaci s klientem z IPv4 světa, který přistupuje k webovému serveru. DNS mu v tomto případě vrací IPv4 adresu. Směrování paketu se zdrojovou adresou 100.0.0.99 a cílovou 173.252.110.27 skrz síť je zde bez větších překvapení. Skrz IPv4 Internet do xTR, odtud je přesměrován na IPv4 LB, který provede DNATnutí až na virtuální server (192.168.3.8).
LISP pro mobilitu virtuálních strojů
Představme si nyní, že zákazník má dvě datacentra v různých lokalitách. Našim cílem je nyní snadno přesunout/zmigrovat (anglicky „roam“) virtuální stroj (zkráceně VM) z jednoho DC do druhého bez toho, aniž by se mu musela měnit IP adresa.
LISP zvládá migraci VM mezi více DC, a to:
- buď mezi LISP lokalitami, to když má každé DC separátní podsíť, kde každá představuje různé EID prostory;
- nebo v rámci jedné LISP lokality, to když jsou všechny DC v jedné podsíti/L2 doméně, což lze např. díky technologii Overlay Transport Virtualization (OTV).
Rozdíl mezi těmito dvěma způsoby migrace je v přístupu detekce mobility samotné; dále si však detailněji rozebereme jen první z nich. Komunikace v topologii před migrací VM tak může vypadat třeba následovně, pokud uvažujeme ten příklad, kdy se jedná o migraci mezi IP podsítěmi:
Proveďme nyní migraci stroje VM-Alfa 1 z DC-A do DC-B (na dalším obrázku znázorněno jako světle modrá čerchovaná dvojšipka). Z pohledu LISPu celý fígl spočívá v tom, že se změní lokátor k dané EID adrese. Síť pak na tuto změnu bude korektně reagovat směrováním provozu vstříc nové lokalitě.
Nyní podrobněji k tomu, jak je technicky řešená samotná mobilita. xTR v lokalitě DC-A detekují živost přítomných VM s EID adresami, pomocí pravidelného opingávání. Když dojde k migraci, tak VM přestane odpovídat na pingy a xTR odstraní případně dynamicky mapované EID (mají hostovskou masku /32) ze své map-cache. Mezitím se VM-Alfa 1 usídlí v DC-B a přijetím prvního datového paketu xTR v této lokalitě detekují, že se jim na síťovém segmentu objevilo zařízení pocházející z jiné podsítě. Vytvoří pro něj záznam o dynamickém EID (10.10.0.1/32) do své map-cache a upraví patřičně směrovací tabulku. Na zodpovědnosti DC-Beta xTR-1 a DC-Beta xTR-2 pak je informovat LISP mapovací systém pomocí LISP Map-Register zpráv, že EID 10.10.0.1 nyní používá nové RLOCy (a to 5.20.0.1 a 5.20.0.2).
LISP pro podporu multihomingu
Zákazník touží po redundanci připojení na svých pobočkách. Mezi pobočkami a centrálou nejsou velké datové objemy, takže rychlost není kamenem úrazu. Zákazníkovi jde ale o peníze, a tak místo drahého vytáčeného T1 volí variantu mobilního 3G spojení skrz dva operátory. Výsledná topologie tak může vypadat například následně:
Pobočky (Remote Site A,B,C) jsou připojeny redundantně skrz dva mobilní operátory pomocí 3G. Bezdrátová rozhraní pobočkových hraničních směrovačů tak mají RLOCy ze sítě konkrétního operátora (u xTR-B je to pro prvního operátora 1.2.0.1, pro druhého pak 2.2.0.1). Hraniční prvky (MR/MS/xTR-1 a MR/MS/xTR-2) na centrále zastávají pro LISP funkcí map resolvera, map serveru pro zákazníkovi LISP lokality a xTR pro EID reprezentující lokalitu centrály (síť 10.0.0.0/24 s RLOCy 5.0.0.1 a 5.0.0.2). V závislosti na konfigurace může být dvojice WAN připojení na pobočkách k operátorům využívána buď ve formě redundance Active/Backup, či ještě lépe jako Active/Active řešení, kdy data mohou proudit skrz obě rozhraní a efektivně rozkládají zátěž mezi dostupné WAN linky. Vyblité žluté šipky na obrázku pak představují potenciální komunikační cesty s vyznačeným obsahem vnějších a vnitřních hlaviček v případě komunikace pobočkových klientů (IP 10.2.0.98 a 10.0.2.99) a serveru na centrále (IP 10.0.0.9). S problematikou multihomingu je úzce spojená i následující vlastnost/podkapitola LISPu…
LISP jako náhrada BGP politik
V současném světě autonomních systémů je jedinou možností, jak ovlivnit směrování do / skrz váš autonomní systém protokol BGP. Můžete strávit hodiny cizelováním politik, které se aplikují tu vůči jednom, tu zase jinému BGP peerovi, popřípadě jít až na úroveň jednotlivých zpracovávaných prefixů. Problémem je, že v jiném AS se místní síťový správci mohou rozmyslet a všechny vámi vytříbená pravidla přepíší svými, veškerá vaše práce je tak ztracena a vy s tím nemůžete nic dělat, neb aktuální systém je o důvěře a je na svobodné volbě kohokoli vám vlastně nedůvěřovat.
Pokud však používáte LISP, máte pod kontrolu zcela manipulaci se vstupním provozem (ingress traffic engineering). Povinností každé implementace LISPu je totiž rigidně dodržovat a řídit se atributy priority a váhy, která je součástí každého záznamů v mapovací cache a jež jsou aktualizovány skrz LISP Map-Reply zprávy. Pro zopakování platí, že čím nižší je priorita, tím je daný RLOC k EID preferovanější, a navíc pokud dvě či více mapování sdílejí tu samou prioritu, tak se mezi nimi rovnoměrně přepíná dle procentuálního parametru váhy.
Existující implementace
Jedněmi z velkých advokátů LISPu jsou Dino Farinaci (spolupodílel se na např. na vývoji CDP, GRE, MPLS) a David Mayer (spolupodílel se na např. na GRE, BGP komunitách, MSDP a věcí souvisejících s multicastem), kteřížto jako zaměstnanci Cisco přišli s LISPem. Ovšem ač počáteční nápady okolu LISPu pochází z této korporace, tak si Cisco na LISP neklade žádná autorská či vlastnická práva, což umožňuje snadnější a rychlejší adopci této technologie. Spekuluje se, že i proto oba v roce 2012 po dlouhých letech opustili firmu Cisco, aby nebyl vývoj LISPu s touto firmou spojován. Formálně LISP zastřešuje IETF, v rámci jejíž pracovní skupiny také vznikají experimentální a informační standardy popisující strukturu a chování protokolu. Zajímavé informace se lze dočíst i v diskuzích v oficiálních skupinách LISPu na Facebooku či LinkedInu, nehledě na to, že je to zároveň nejsnazší cesta, jak se dočkat odpovědi od samotných strůjců. I díky tomu je k dispozici celá řada implementací LISPu, a to jak do aktivních síťových prvků (překvapivě od Cisco), tak i softwarová řešení určená jak pro operační systémy postavené založené na UNIXu. Následující podkapitoly ke každé implementací předkládají ty nejzákladnější informace
Cisco IOS / IOS-XE / IOS-XR / NX-OS
Operační systém ve směrovačích či některých L3 přepínačích od firmy Cisco obsahoval jednu z prvních dostupných implementací LISPu. Zároveň tato proprietární implementace patří k těm nejaktuálnějším, jež adaptuje nejnovější věci z draftů. Seznam všech platforem spolu s prvními verzemi, od kterých je na nich LISP podporován, je uveden níže:
| Operační systém | Verze | Platformy |
| IOS | 15.1 | Cat6000, C81×, C88×, C89×, C1941, C29×x, C39×x, C720× |
| IOS-XE | 3.3 | ASR100× |
| IOS-XR | 4.3 | ASR9000 |
| NX-OS | 5.2 | Nexus 7000 |
OpenLISP
Jedná se o první dostupnou open-sourcovou implementaci pro Unixové systémy, jmenovitě pro FreeBSD 7.x a 8.x. Naneštěstí prvotní nadšení autora Luigiho Iannoneho opadlo a poslední aktualizace LISP control-plane xTR zařízení je z října 2011, takže v ní chybí řada vlastností, které jsou dnes u LISPu samozřejmostí (např. RLOC probing mechanismus, perzistentní cache). Sám autor zůstává ale aktivní komunitě a má na svědomí pár zajímavých vědeckých článků stejně jako experimentální draft k metodologii přidělování EID adres.
LISPmob
Open-sourcový projekt LISPmob se zabývá jak implementací control-plane xTR zařízení, tak i LISP mobilního uzlu, což je de facto koncové zařízení jako např. smartphone, jež může benefitovat s provozování LISPu. Projekt si klade za cíl multiplatformnost, a tak jsou k dispozici zdrojové kódy pro Linux, Android, ale i OpenWRT; pokryto je tedy celé spektrum síťových prvků – od koncových stanic, přes mezilehlé aktivní prvky až pro případné servery.
Kam dál?
Začátkem roku 2013 slavil LISP po několika letech urputného snažení úspěch v rámci standardizačních tendencí skrz IETF. V lednu onoho roku tak byly úspěšně posvěceny následující dokumenty formou experimentálního RFC s vlastním číslem. Tyto dokumenty stejně jako související aktivní drafty jsou asi nejvhodnějším a referenčním zdrojem informací pro studium struktury LISPu a jeho fungování použít. Hvězdičkou * jsou označeny odkazy více relevantní k tomuto dílu seriálu.
Odkazy na implementace:
- * Cisco LISP
- * OpenLISP
- * LISPmob
GoogleTech prezentace:
- LISP Part 1 – Problem Statement, Architecture and Protocol Description
- LISP Part 2 – Mapping Database Infrastructure and Interworking
- * LISP Part 3 – Deployed Network and Use-Cases
Další odkazy:
