Mi az a LISP?

Nemrégen jelent meg a Cisco Nexus 7000-es adatközponti switch termékcsalád új, 5.2-es NXOS szoftver verziója, melyben többek között az egyik újdonság a LISP támogatás. Nem … nem a List Processing (Lisp) programozási nyelv alkalmazására válik lehetőség hálózati környezetben, hanem mint azt már megszokhattuk rohanó világunk nem túl determinisztikus rövidítési lázában, ez esetben is a LISP rövidítés egy teljesen új jelentést kapott.

A LISP (Locator/Identity Separation Protocol), mint azt a mozaikszavak is sugallják, olyan protokollcsalád, mely segítségével külön lehet választani egy hálózati végpont (pl. egy szerver) azonosítóját (IP címét) a lokációjától (az IP címet tartalmazó alhálózattól).

De miért jó ez nekünk?

Ha most megkérdezném, hogy milyen problémával szembesülünk manapság az Interneten robbanásszerűen elszaporodó aktív végpontok következtében, gondolkodás nélkül mindenki mondaná is a választ: “Elfogynak az IPv4-es címek, át kell térni IPv6-ra …”, ami természetesen igaz, de van egy másik, kevésbé közismert probléma is, nevezetesen az internetes routerek routing táblájának, az aktív végpontokkal arányos növekedése.

Nemrégen láttam egy előadást, mely arról szólt, hogy korunk közúti közlekedése milyen problémákkal küzd, illetve hogyan fog majd megfelelni a szintén robbanásszerűen növekvő autók számával, hiszen az utak szélesítése, illetve az új autók számával arányosan új utak kialakítása nem mehet a végtelenségig. Anélkül, hogy lelőném a poént azok elől akik esetleg megnéznék a linkelt előadást, a megoldást egy (az Internethez nagyon hasonló) kommunikációs rendszer kialakításában látják, mely rendszernek minden közlekedési eszköz szerves része és a döntések  meghozatala immár nem az egyének, hanem a rendszer szemszögéből történik.  

Játszunk el a gondolattal, hogy az Internet nem más, mint Budapest közlekedési hálózata, feladatunk pedig nem kevesebb, mint autóval bejutni a munkahelyünkre oly módon, hogy kitöröljük a fejünkből a jól bevált útvonalat, ráragasztjuk a szélvédőre a célcímét, mely alapján, a kereszteződésekben lévő rendőröktől (router), személyre szóló utasításokat kapunk a követendő útvonalat illetően.
Egy átlagos kereszteződésben mondjuk három lehetőségünk van útvonalunk folytatására, ugyanakkor az autók szélvédőjén lévő (egymástól különböző) címek száma ennél lényegesen több. Rendőrünk nagyon lelkes, címlistáját (routing tábla) sűrűn lapozgatva, szorgalmasan irányítja az autókat jobbra, balra, előre, jobbra, balra, előre … Estére jól elfárad, de annyira nem, hogy ne tudná összegezni az aznapi tanulságokat és elgondolkodni valamilyen folyamat optimalizáláson. Másnapra kitalál egy újítást. A sűrűn előforduló címeket a lista elejére teszi (route cache), ezáltal lényegesen kevesebbet kell lapozgatnia. Jobbra, balra, előre … jobbra, balra, előre és eltelik ez a nap is. Harmadnapra egy újabb ötlettel áll elő. Készít egy rövidített listát Budapest 22 kerületéről (1-3,11-12 balra, 4, 13 előre stb.), melyek esetén nem vizsgálja többé az utcát, hanem megelégszik a kerülettel, majd a megmaradt kerület esetén (melyben ő is van) utcaszintű eligazítást végez. Bingo!!! Aznap, a korábbi napokkal ellentétben még csúcsidőben sem alakult ki sor a kereszteződésében. Nem maradt más hátra, mint elújságolni a további kereszteződésekben ügyködő sorstársainak a módszer lényegét és rendszer szinten alkalmazni az egész városban.

De a viccet félretéve, a LISP segítségével lényegesen le lehet redukálni a routing táblák méretét, azáltal, hogy a végpont azonosítókat (EID – End Point Identifier, példánkban utcanév, házszám)  nem tároljuk, hanem csak a lokációkat (RLOC – Routing Locator, példánkban kerület), illetve szükségünk van még egy dinamikus adatbázisra MS/MR (MS – Map Server, MR – Map Resolver), mely tárolja a EIDRLOC hozzárendeléseket.

lisp1

Mint az ábrán is látható, az RLOC nem más mint a LISP router gerinchálózat irányába mutató interfésze (ezek a prefixek szerepelnek a gerinchálózat routing táblájában), az EID pedig a LAN oldali, de EID az egyes szerverek IP címe is. Mivel az EID-ek nincsenek route-olva a gerinchálózaton, két különböző LISP telephelyen lévő EID egymás között a LISP routerek (xTR, ITR – Ingress Tunnel Router és ETR – Egress Tunnel Router gyűjtőneve) között kiépülő tunnelen keresztül képes kommunikálni.

Nézzük (nagyon leegyszerűsítve), hogyan kommunikál két végpont (EID) egymással?

Az “A” telephelyen lévő végpont (EID) kapcsolódást kezdeményez a “B” telephelyen lévő 10.0.0.1-es IP című szerverhez. Az “A” telephely LISP routere beregisztrálja az adatbázisba (DynDNS-hez hasonló módon) a forrás IP-t (EID), majd mivel a cél IP nincs a routing táblájában, lekéri az adatbázisból a cél EID helyét (RLOC), majd az RLOC birtokában kiépít egy tunnelt a két telephely között, melyen keresztül a forrás EID által küldött csomag eljut a cél EID-hez. A válaszcsomag hatására a “B” telephely LISP routere lekéri az adatbázisból a kapcsolatot kezdeményező EID helyét (amennyiben nem szerepel a lokális cache-ben) és a kiépített tunnelen keresztül eljuttatja a válaszcsomagot a kezdeményező EID-hez.

Bár a LISP kifejlesztésének elsődleges mozgatórugója az Internetes routerek routing táblájának skálázhatósági kérdéseire történő megoldás megtalálása volt, mellékhatásként a végpontok mobilitásának biztosítása is említésre méltó.

A LISP segítségével bármely végpont helyet változtathat, anélkül, hogy meg kellene változtatni az identitását (IP címét). Gondoljunk csak bele mekkora segítséget jelenthet napjaink, fizikai béklyóitól felszabadult virtuális szerverei számára, melyek ezáltal könnyedén vándorolhatnak az elsődleges és a DR telephely között, anélkül, hogy ennek bármilyen kihatása lenne a szerverek által folytatott kommunikációra.

  

lisp2

De nézzük mi történik, ha a  “B” telephelyen lévő 10.0.0.1-es szerver “átköltözik” a “B” telephelyre?

A forgalom hatására a “C” telephely LISP routere észleli, hogy egy olyan végpont kommunikál az adott LAN-on, mely IP beállításai nem erre a lokációra vonatkoznak. Amennyiben ezen IP cím benne van a migrációra engedélyezett IP tartományok listájában, beregisztrálja az adatbázisba a változást, illetve értesíti a többi LISP routert az adott EID lokális cache-ből való törlésére. Ezek után a kommunikáció a korábban leírtak szerint történik. A migrált szerver honos hálózatával történő kommunikációja Proxy-ARP segítségével valósul meg.

Az NXOS 5.2-es szoftver verzióban a LISP VM-Mobility  két különböző módon is támogatott:

  • VM mobilitás kiterjesztett LAN kapcsolat esetén:
    ebben estben a VM (Virtual Machine) migráció LISP nélkül is megvalósítható a kiterjesztett LAN kapcsolatot két oldalán lévő telephelyek között, ugyanakkor LISP nélkül a mobil végpont irányába történő útvonal nem az optimális útvonalon történik.

Kép forrása: www.cisco.comScreenHunter_03 Aug. 14 20.56

  • VM mobilitás különböző IP tartományok között:
    a korábban már leírt példához hasonlóan Proxy-ARP segítségével.

Meglátások:

Mivel a LISP jelenleg az IETF munkacsoport gondozásában “draft”-ként szerepel, az Internetes routing táblák csökkentésére való globális implementációja még a jövő zenéje. Jelenleg kísérleti jelleggel működnek LISP szigetek az Interneten, többen között az alábbi weboldalak is ezen keresztül érhetőek el:

A VM mobilitás támogatásával kapcsolatosan bizakodó vagyok, egyrészt, mert a Cisco implementációjában már elérhető a funkcionalitás biztosítása a Nexus 7000-es adatközponti switchekben és ígéretek vannak a támogatás kiterjesztésére a Nexus 5000-es, valamint a Nexus 1000V, Vmware vSphere 4.x virtualizációs rendszerbe való szoftveres disztributált switchekre, másrészt, mert az Internettel ellentétben az  adatközpontok közötti VM mobilitás biztosítása érdekében nem szükséges globális kiterjedésű LISP támogatás, elegendő néhány eszköz.

Tagged , ,

Szabó Péter Posted 2011. augusztus 16. at 12:52 | Permalink

  • A végére persze elvesztettem a fonalat, de a közlekedési hasonlat nagyon jó volt, most megértettem valamit az eredetileg mérnök, bár mostanra szinte teljesen elértékesítősödött fejemmel. Köszi!

Csiszér Ákos Posted 2011. szeptember 4. at 08:32 | Permalink

  • Nagyon tetszett a poszt elején a forgalomirányítós hasonlat, ezzel szerintem a LISP lényegét, és az alap problémát is nagyon jól megvilágítottad!

Papp Jenő Posted 2011. szeptember 6. at 13:43 | Permalink

  • Szerintem tanár lehet a blog írója, annyira jó a cikk.
    Még sok ilyet kérünk “tollából”!

Megyer Balázs Posted 2011. október 1. at 14:09 | Permalink

  • Nice, nekem ez igy elso blikkre mpls v2.0-nak tunik, bar sem az mplshez nem ertek, sem a lisphez :)
    Tetszik maga a blog is, jol megfer egymas mellett a kemeny bitvadaszat es a marketing-prospektus…

Orbán Attila Posted 2012. augusztus 5. at 10:49 | Permalink

  • Köszönöm mindenkinek a biztatást :)

Post a Comment

You must be logged in to post a comment.