LISP: nové paradigma ve směrování (3.)

3. 10. 2013

Doba čtení: 8 minut

Líbí se vám článek?
Podpořte redakci

Locator/ID Split Protocol je v posledních letech jedním z diskutovaných řešení, které by mohlo přinést úlevu od bolístek (mobilita, multihoming, adresování) současného internetu. Náš třídílný seriál se vám pokusí nastínit vše podstatné – ideu funkce, strukturu protokolu i konfiguraci na zařízeních.

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 si povíme o tom, jak koexistuje LISPová síť s neLISPovou a co obnáší migrace sítě stávající do LISPu.

Přechod na LISP

Stejně jako u IPv6 je i u LISPu vzhledem k aktuální velikosti Internetu asi pošetilé očekávat, že ze dne na den na něj přejdou všichni. Navíc vždy můžou existovat sítě, ve kterých nasazení LISPu není vhodné, či možné z různých přičin. Krom již existujících zařízení v LISP infrastruktuře je tedy potřeba představit si i ta, která umožní propojení částí světa LISPu se světem, který rozdělení funkcionality lokalizace a identifikace vůbec nerozumí. Je dobré rozdělit komunikaci participantů podle směru, a to na LISP->neLISP a na neLISP->LISP. Obecně řeší dva problémy týkající se práce s adresami:

Varianta neLISP->LISP: Klienti a směrovače v takovýchto oblastech nemají ponětí o rozdělení funkcionality adres. EID považují za směrovatelnou adresu a podle toho ji i nativně routují. Pokud je jako cílová adresa použito EID, kde se pak nachází vstupní směrovač do takovéto „EID sítě“?
Varianta LISP->neLISP: Trable zde má ITR. Zaprvé mu musí někdo sdělit, že daná cílová adresa není žádný EID identifikátor a tudíž k němu neexistují použitelné RLOCy. Za druhé pak, kde se nachází výstupní místo z LISP adresních systémů.

Ve specifikacích byly navrženy dva přístupy – překlad adres a proxy zprostředkování rolí – přičemž detailněji bude rozebrán druhý jmenovaný.

Každopádně ať už se používá jeden či druhý přístup tak platí, že jedním z cílů autorů LISPu byla touha zpřístupnit jeho vlastnosti už v prvním dni jeho nasazení; zkrátka tak, aby se kvalita a funkčnost LISPu neodvíjela od toho, zdali ho mají už i v sousedních sítích, ale abyste z LISPu těžili okamžitě! Toto se díky chytrému návrhu podařilo splnit, přičemž nejmarkantněji se tato vlastnost projevuje u traffic-engineeringu na vstupu. Pomocí priorit a vah u RLOCů má každý ETR pevně v rukou přístupovou politku, kterou vnucuje pro komunikaci se svým svěřeným LISP prostorem – každá LISP implementace musí povinně provádět load-balancing podle výše zmíněných RLOC atributů. Porovnejme toto s obdobným systémem politik BGP, kde však typicky platí, že jejich vynucování je iluzorní, každý AS má právo si totiž politiky přizpůsobit, a tím pádem nerespektovat původní záměry řízení přístupu toho či onoho AS.

LISP-NAT

Principielně podobný klasickému NATu, jen s tím, že xTR provádí překlad adres z EID na globálně routovaný prefix (RLOC) a naopak. Typické použití je pro LISP->neLISP komunikaci, nebo pro komunikaci LISP lokalit, ve kterých se používají překrývající se adresy (např. z privátního IPv4 prostoru). V praxi se však tento přístup moc neprosadil, i když implementačně nebylo nic těžkého ho integrovat do control-plane existujících aktivních prvků (viz. white-paper od Cisco).

Proxy ITR a Proxy ETR

Ideou je vytvoření překlenovacích proxy, které budou zprostředkovávat funkcionalitu ITR a ETR směrovačů zařízením v neLISP světě. Infrastruktura se tak obohacuje o Proxy Ingress Tunnel Router (PITR) a Proxy Egress Tunnel Router (PETR).

PITR má za úkol přijímat provoz ve směru neLISP->LISP a tento pak patřičně zapouzdřovat do LISPu. PITR do neLISP světa šíří pomocích standardních směrovacích prostředků (IGP + BGP) hrubě agregované EID prefixy. Tímto je schopen na sebe „přítáhnout“ a přes sebe směrovat provoz, který je určen k doručení do LISP lokalit. Na výstupním rozhraní mířícím do RLOC adresního systému jsou pak půdovodní data obalena LISPem s patřičně upravenými zdrojovými a cílovými IP adresami ve vnitřní a vnější hlavičce.

PETR zprostředkovávají komunikaci ve směru LISP->neLISP. Prakticky tedy kdykoli, kdy se na mapovací dotaz ITR routeru vráti LISP Negative Map-Reply. Cíl tohoto provozu leží v neLISP světě a pokud mají takové destinaci být doručena data z LISP světa, pak se musí pro přechod mezi světy použít právě PETR. Druhou roli, kterou PETR zastává, je brána pro LISP lokality, které používají RLOCy z různých adresních rodin (např. jedna IPv4 a druhá IPv6 RLOCy). Pokud komunikaci neLISP a LISP zprostředkovávají neduální PITR a PETR (obě funkce pro daný tok nezastává stejné zařízení), tak obvykle dochází k tomu, že data mohou k ETR přicházet ne nutně nejkratší cestou (je tak porušena podmínka uRPF = unicastového Reverse Path Forwardingu ). Při použití PETRu je tato podmínka ignorována a LISP lokality mohou komunikovat s neLISP světem beze strachu z uRPF.

Ukázka komunikace s neLISP světem za použití PITR a PETR

Popišme si nyní příklad komunikace LISP světa s neLISP světem, a to v obou dvou možných směrech. V tomto příkladě začne komunikaci zařízení z neLISP s adresou 9.0.0.99 a cílem je zařízení v Site B, konkrétně s IP 200.0.0.99. Výstupní branou z neLISPu je zařízení jménem PITR, který šíří hrubě agregovaný prefix 200.0.0.0/8, do nějž spadá i EID cílové oblasti (a to 200.0.0.0/24). Vstupní branou do neLISPu je pak PETR, který mají ITR v Site B nakonfigurovaný k použití v případě, že je provoz třeba směrovat jinam než do LISPu.

V neLISP oblasti počítač s adresou 9.0.0.99 odešle datový paket na 200.0.0.99. Pomocí klasického směrování se paket proroutuje až na zařízení PITR, který šíří agregovaný EID prefix.
Na PITRu dojde k zabalení původního datového (proto UDP cílový port 4341) paketu vnější LISP hlavičkou, ve které se jako zdrojová adresa použije odchozí rozhraní PITRu 3.0.0.254 a jako cílová adresa pak RLOC údaj z map-cache, který pro cílové EID 200.0.0.99 má poznamenaný lokátor 3.0.0.1.
Paket se RLOC prostorem dostane až k ETR směrovači xTR-B1, jehož rozhraní má RLOC cílovou adresu ve vnější hlavičce. Na xTR-B1 pak dojde k odstranění vnější LISP hlavičky a paket je přeposlán, tak jak byl původně, do EID prostoru stanici s adresou 200.0.0.99, jež je i koncovým příjemcem.
Komunikace je obousměrná, takže 200.0.0.99 odpoví 9.0.0.99. Díky směrování ve vnitřku Site B, je pak proroutován až na hraniční směrovač xTR-B2.
ITR směrovač xTR-B2 provede vyhledání RLOCu k 9.0.0.99. Ovšem vrátí se mu LISP Negative Map-Reply, čímž zjistí, že nemůže paket směrovat nativně v rámci LISPu. Místo toho paket odešle svému předkonfigurovanému zařízení PETR, které plní roli Proxy ETR, což obnáší obalení paketu vnější LISP hlavičkou se zdrojovou adresou 4.0.0.1.
Po přijetí paketu PETR provede dekapsulaci vnější hlavičky a odešle paket do neLISPového prostoru vstříc koncové stanici 9.0.0.99.

Celosvětové nasazení LISPu

V době uveřejnění tohoto dílu má za sebou LISP už relativně dlouhou dobu, kdy existuje jak teoreticky, tak prakticky. Jedním z prvních projektů, které cíli na rozšíření LISPu po světě, je tzv. LISP BetaNetwork. Za čtyřletou dobu existence se do této LISPové páteře připojilo 200+ organizací z 32+ různých zemí, přičemž mezi jedněmi z prvních byli i takoví hráči jako Google, Facebook, Cisco, Qualcomm, AT&T, Lufthansa, Microsoft, aj. Libovolná instituce plánující nasazení LISPu a komunikaci s dalšími LISP lokalitami, tak aby se naplno projevil potenciál této technologie, má možnost zadarmo zažádat o přidělení globálního EID. Pro IPv4 je vyčleněna síť 153.16.0.0/16 a pro IPv6 prefix 2610:00D0::/32. Zařízení patřící do těchto sítí pak patří do vlastního autonomního systému s ASN 3943. Obratem k žádosti dostanete přidělené všechny důležité parametry nutné k tomu, abyste správně nakonfigurovali aktivní síťové prvky, které mají v LISP BetaNetwork participovat, např. za moji fakultu to je:

fit-xtr:        Device Type     - {IOS/FreeBSD}
                Geographic      - Czech Republic
                DNS Name        - fit-xtr
                EID-Prefix Set  - {153.16.48.112/28, 2610:D0:214D::/48}
                RLOC Set        - {tbd}
                Map-Server(s)   - {RIPE}{l3-london-mr-ms 195.50.116.18  intouch-ams-mr-ms-1 217.8.98.42}
                                - {RIPE}{tdc-mr-ms       193.162.145.50 intouch-ams-mr-ms-2 217.8.98.46}
                Map-Resolver(s) - {RIPE}{l3-london-mr-ms 195.50.116.18 intouch-ams-mr-ms-1 217.8.98.42}
                                - {RIPE}{tdc-mr-ms       193.162.145.50 intouch-ams-mr-ms-2 217.8.98.46}
                PXTR (RIPE)     - {intouch-pxtr-1}{217.8.98.33, 2001:67C:21B4:107::b}

Úspěšnost napojení na LISP BetaNetwork pak lze ověřit několika v zásadě podobnými způsoby:

Libovolnou implementací programu LISP Internet Groper (ve zkratce LIG), který provádí dotazování nad mapovacím systémem a vrací seznam nalezených RLOCů k danému EID, a to tak, že se zeptáte na vlastní bloky EID.
Ověřením, jestli došlo k registraci vašimi ETR routery, např. na sběrné stránce všech LISP lokalit (pro ukázku výsledky pro moji fakulty) či jiným monitorovacím nástrojem (např. LISPmon).

Závěr

V dnešní části jsme si představili tranzitní mechanismy pro komunikaci mezi LISP a neLISP sítěmi. V díle následujícím si povíme o některých zajímavých případech použití LISPu v sítích.

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ěšne 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 funogvání použít. Hvězdičkou * jsou označeny odkazy více relevantní k tomuto dílu seriálu.

IETF materiály:

GoogleTech prezentace:

Další odkazy:

Seriál: LISP: nové paradigma ve směrování

Přečtěte si všechny díly seriálu LISP: nové paradigma ve směrování nebo sledujte jeho RSS

Vstoupit do diskuse (5 názorů)

Sdílet