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 konkrétní scénář a s ním související konfigurační kroky pro Cisco zařízení. Na následující demonstrační úloze si představíme nejpodstatnější konfigurační kroky k nasazení LISPu v síti, a to jak na straně zákaznické, tak poskytovatelské.
Demonstrační úloha
Topologie
Adresní plán
Použité IP adresy jsou zcela fiktivní, i když pro EID byly záměrně vybrány bloky z prostoru IPv4/IPv6 rezervované pro LISP. Na obrázku topologie jsou uvedeny jen adresy podstatné z hlediska LISPu, sítě propojující jednotlivé poskytovatele (sériové spoje) byly pro jednoduchost vynechány. Pro jistotu však platí určité konvence – spojnice mezi ISP jsou vždy ze sítě 10.0.NM.0/30, kde N představuje nižší a M vyšší z pořadových identifikátorů operátorů (např. 10.0.12.0/30 je spojnice mezi ISP1 a ISP2). Tak jako tak je celý adresní plán shrnutý v následující tabulce:
| Hostname | Rozhraní | Adresa |
| xTR-A1 | FastEthernet1/0 | 1.0.0.1/30 |
| FastEthernet1/1 | 153.16.10.1/24 2610:D0:AAAA::1/64 |
|
| xTR-A2 | FastEthernet1/0 | 2.0.0.1/30 |
| FastEthernet1/1 | 153.16.10.2/24 2610:D0:AAAA::2/64 |
|
| xTR-B1 | FastEthernet1/0 | 3.0.0.1/30 |
| FastEthernet1/1 | 153.16.20.1/24 2610:D0:BBBB::1/64 |
|
| xTR-B2 | FastEthernet1/0 | 4.0.0.1/30 |
| FastEthernet1/1 | 153.16.20.2/24 2610:D0:BBBB::2/64 |
|
| xTR-B3 | FastEthernet1/0 | 5.0.0.1/30 |
| FastEthernet1/1 | 153.16.20.3/24 2610:D0:BBBB::3/64 |
|
| MRMS1 | FastEthernet1/0 | 2.0.0.255/31 |
| FastEthernet1/1 | 192.0.2.1/30 | |
| Tunnel0 | 192.168.0.1/30 | |
| MRMS2 | FastEthernet1/0 | 5.0.0.255/31 |
| FastEthernet1/1 | 192.0.2.2/30 | |
| Tunnel0 | 192.168.0.2/30 |
| Hostname | Rozhraní | Adresa |
| ISP1 | FastEthernet0/0 | 1.0.0.2/30 |
| Serial0/0 | 10.0.13.1/30 | |
| Serial0/1 | 10.0.12.1/30 | |
| Serial0/2 | 10.0.14.1/30 | |
| Serial0/3 | 10.0.15.1/30 | |
| ISP2 | FastEthernet0/0 | 2.0.0.2/30 |
| FastEthernet0/1 | 2.0.0.254/31 | |
| Serial0/0 | 10.0.12.2/30 | |
| Serial0/1 | 10.0.25.1/30 | |
| Serial0/2 | 10.0.24.1/30 | |
| ISP3 | FastEthernet0/0 | 3.0.0.2/30 |
| Serial0/0 | 10.0.13.2/30 | |
| Serial0/1 | 10.0.34.1/30 | |
| ISP4 | FastEthernet0/0 | 4.0.0.2/30 |
| Serial0/0 | 10.0.24.2/30 | |
| Serial0/1 | 10.0.14.2/30 | |
| Serial0/2 | 10.0.34.2/30 | |
| Serial0/3 | 10.0.45.1/30 | |
| ISP5 | FastEthernet0/0 | 5.0.0.2/30 |
| FastEthernet0/1 | 5.0.0.254/31 | |
| Serial0/0 | 10.0.25.2/30 | |
| Serial0/1 | 10.0.45.2/30 | |
| Serial0/2 | 10.0.15.2/30 |
Scénář
V této síti existují dvě LISP lokality – Site A (ve které se používají IPv4 EID 153.16.10.0/24 a IPv6 EID 2610:D0:AAAA::/64 s RLOCy 1.0.0.1 a 2.0.0.1) a Site B (s IPv4 EID 153.16.20.0/24 a s IPv6 EID 2610:D0:BBBB::/64 s RLOCy 3.0.0.1, 4.0.0.1 a 5.0.0.1). Funkci xTR směrovačů pro lokalitu Site A plní xTR-A1 a xTR-A2, v rámci lokality Site B je to pak xTR-B1, xTR-B2 a xTR-B3. V topologii dále existují dvě zařízení důležitá pro mapovací systém, a to MRMS1, které plní funkci map resolveru a map serveru pro lokalitu Site A, a MRMS2, jež činí to samé pro Site B. MRMS1 a MRMS2 si předávají LISP směrovací informace pomocí LISP-ALT (skrz GRE tunel se sítí 192.168.0.0/30). Sítě poskytovatelů Internetu, ve kterých mohou být adresy rozlišovány jako PoA substituují směrovače ISP1, ISP2, ISP3, ISP4 a ISP5. V případě IPv6 konektivity bude LISP používán jako tranzitní mechanismus, a to proto, že jádro (sítě jednotlivých ISP) je čistě na IPv4. Pro Site A by mělo být nakonfigurované rozkládání zátěže 50:50 mezi xTR-A1 a xTR-A2; pro Site B by pak mělo platit, že primárním přístupovým bodem je xTR-B2, v případě jeho nedostupnosti pak rovnoměrné rozkládání zátěže mezi xTR-B1 a xTR-B3.
Konfigurační kuchařka
Našim cílem je probrat jednotlivé kroky vztahující se ke konfiguraci demonstrační úlohy. Některé zmíníme jen lehce (základní zapojení), jiné probereme hlouběji (nastavení týkající se LISPu).
Všechny níže uvedené příkazy jsou platné pro ty platformy Cisco zařízení, které podporují LISP a provozují IOS verze 15.1 či vyšší. Na konci kapitoly jsou pak k dispozici ke stažení separátní konfigurační soubory jednotlivých zařízení a dokonce i zdrojové soubory k virtualizaci demonstrační úlohy pro balík nástrojů Dynamips/Dynagen/GNS3. Všechny LISP směrovače ve virtuálním GNS3 labu jsou provozovány na IOSu c7200-advipservicesk9-mz.151–4.M, ISP směrovače pak na IOSu c2600-j1s3-mz.123–26.image. V reálných podmínkách byla demonstrační úloha úspěšně otestována na Cisco 2911 s IOSem c2900-universalk9-mz.SPA.153–1.T. Je nad rámec tohoto seriálu vysvětlovat čtenáři práci s Cisco IOSem, implicitně se tato znalost předpokládá (dostudovat aspoň částečně se dá např. z tohoto pěkného webu).
Základní konektivita
Všechny sériové spoje mají rychlost 2 MB. Na páteři (tzn. mezi jednotlivými ISP) je zajištěna pomocí směrovacího protokolu EIGRP, který je nakonfigurován tak, aby nesumarizoval předávané sítě, ale především aby zajistil end-to-end konektivitu napříč všemi existujícími sítěmi. IPv6 je zapnutá jen pro EID sítě, zbytek je propojen čistě skrz IPv4. Kromě toho xTR-*1 směrovače fungují jako IPv4 DHCP servery pro koncové stanice v EID sítích lokalit Site A i B.
Povolení xTR rolí
LISP jako instance se podporuje v globálním konfiguračním menu velice podobně, jako jiné směrovací protokoly, a to pomocí:
(conf)# router lisp instance
Kde identifikátor instance je z rozsahu 0 až 15, pokud je prázdný, tak se implicitně chápe 0.
Povolení role xTR se pak dělá z konfiguračního submenu samotného LISPu, přičemž se dá oddělit role ITR od ETR a stejně tak, zda-li je to pro IPv4 či IPv6. V případě, že chceme povolit xTR pro obě varianty IP protokolu, nastavíme na xTR-A* a xTR-B* následující:
(config-router-lisp)# ipv4 itr (config-router-lisp)# ipv4 etr (config-router-lisp)# ipv6 itr (config-router-lisp)# ipv6 etr
Vytvoření mapování u ETR
Pokud směrovač zastává ETR roli, je potřeba nakonfigurovat, o jaké EID je zodpovědný a jaké k nim bude ohlašovat RLOCy. Toto se dělá pomocí příkazu:
(config-router-lisp)# database-mapping EID-adresa RLOC-adresa priority {0-255} weight {0-100}
Zde parametr EID-adresa je EID síť (zapsaná včetně masky) a RLOC-adresa k ní přislušející RLOC s danou prioritou (parametr priority) a váhou (parametr weight).
Více RLOCů k jednomu EID se nakonfiguruje jednoduše duplikací příkazu se stejným EID-address. Např. v případě xTR-A1 se tak v jeho konfiguraci nachází následující. Zaprvé se registrují k EIDům 153.16.10.0/24 a 2610:D0:AAAA::/64 RLOCy 1.0.0.1 a 2.0.0.1. Zadruhé jsou těmto RLOCům nastaveny priorita a váha tak, aby byl zaručen 50:50 ingress TE pro rozkládání provozu právě mezi xTR-A1 a xTR-A2:
database-mapping 153.16.10.0/24 1.0.0.1 priority 1 weight 50 database-mapping 153.16.10.0/24 2.0.0.1 priority 1 weight 50 database-mapping 2610:D0:AAAA::/64 1.0.0.1 priority 1 weight 50 database-mapping 2610:D0:AAAA::/64 2.0.0.1 priority 1 weight 50
Nastavení MR a MS pro xTR
Máme nastavenou funkcionalitu xTR a ETR se snaží registrovat své EID. Nyní je potřeba specifikovat vůči jakému map serveru. Opět lze příkaz duálně použít jak pro IPv4 EID, tak pro IPv6 EID.
(config-router-lisp)# {ipv4|ipv6} map-server adresa key pass
Parametrem adresa je míněna skutečně adresa dosažitelného map serveru, přičemž pro ochranu control-plane serveru před falešnými registrátory musí být jako parametr pass uvedeno heslo, které je sdíleno ETR a jeho map serverem.
Analogické je pak nastavení, koho se má ITR ptát na mapování, v případě že neví. Jinak řečeno tedy konfigurace patřičného map resolveru. Příkaz je opět duální jak pro IPv4, tak pro IPv6:
(config-router-lisp)# {ipv4|ipv6} map-resolver adresa
Obdobně jako u výše je adresa dosažitelná adresa nějakého map resolveru, podobně jak kdybychom na koncové stanici konfigurovali DNS server.
Na závěr příklad, aneb jak je to v naší demonstrační úloze třeba pro xTR-B1, jehož map serverem a map resolverem zároveň je MRMS2 (s adresou 5.0.0.255):
ipv4 itr map-resolver 5.0.0.255 ipv4 etr map-server 5.0.0.255 key HesloB ipv6 itr map-resolver 5.0.0.255 ipv6 etr map-server 5.0.0.255 key HesloB
Tento krok završuje konfigurační úsilí na straně xTR zařízení.
Povolení MR a MS rolí
Podobně jako v případě xTR je i u map-serverů a map-resolverů potřeba povolit, aby control-plane daného směrovače plnila i tyto funkce. Dělá se to opět v konfiguračním submenu LISPu, a to pomocí opět duálních příkazů pro IPv4 a IPv6 :
(config-router-lisp)# {ipv4|ipv6} map-resolver
(config-router-lisp)# {ipv4|ipv6} map-server
Akceptace mapování na MS
Aby MS akceptoval registrace od ETR, je potřeba rozdělit mapování do oblastí. De facto na MS nastavit, v jaké lokalitě očekávat jaké EIDy. Nejzákladnější konfigurace se sestává ze tří příkazů:
(config-router-lisp)# site jmeno (config-router-lisp-site)# authentication-key pass (config-router-lisp-site)# eid-prefix EID-adresa
Prvním příkazem se vytváří lokalita pojmenovaná atributem jmeno. Příkazem authentication se pak specifikuje sdílené heslo pass mezi MS a ETR v dané lokalitě. Příkaz eid-prefix pak specifikuje síť EID (parametrizovanou pomocí EID-adresa) patřící k dané lokalitě; tento příkaz se může vyskytovat vícekrát.
Příkladem budiž výňatek z konfigurace MRMS2, na kterém je definována lokalita B, se sdíleným heslem „HesloB“ a EID 153.16.20.0/24 a 2610:D0:BBBB::/64.
router lisp
site B
authentication-key HesloB
eid-prefix 153.16.20.0/24
eid-prefix 2610:D0:BBBB::/64
Konfigurace LISP-ALT na MS
Cílem tohoto kroku je propojit map servery vzájemně, aby si předávali směrovací informace o LISPu. Protože na Internetu mohou být (a typicky i jsou) dva MS od sebe fyzicky značně vzdálené, tak se technicky toto propojení řeší pomocí GRE tunelů, ve kterých se nese směrovací informace pomocí BGP skrz redistribuci z LISPu.
Nejprve je nutné vytvořit speciální VRF, která bude obsahovat LISPovské směrovací informace a rozhodnout se pro jaké verze IP protokolu je bude přenášet (které address-family budou povoleny). Vytvoření VRF se jménem VRF-jmeno pro IPv4 a IPv6 se tak dělá následující sérií příkazů:
(config)# vrf upgrade-cli multi-af-mode (config)# vrf definition VRF-jmeno (config-vrf)# address-family ipv4 (config-vrf)# address-family ipv6
V naší demonstrařní úloze tak budeme chtít propojit MRMS1 a MRMS2 GRE tunelem s adresami 192.168.0.1 a 192.168.0.2 skrz jedinou síť 192.0.2.0/30. Pro tento účel se sestává Cisco konfigurace GRE z následujícího minima příkazů:
(config)# interface tunnel id
(config-interface)# ip address adresa maska
(config-interface)# tunnel source {interface|src-adresa}
(config-interface)# tunnel destination dst-adresa
(config-interface)# vrf forwarding VRF-jmeno
Tunel máme ustavený, VRF vytvořenou, nyní se vrhneme na redistribuci LISPu do BGP. Následující přkazy jsou holé minimum proto, aby se na směrovači v autonomním systému local-ASN BGP pro danou address-family aktivovalo a rozběhlo vůči sousedovi s IP adresa v AS remote-ASN, s tím že je do něj LISP redistribuován:
(config)# router bgp local-ASN
(config-router)# address-family {ipv4|ipv6}
(config-af)# neighbor adresa remote-as remote-ASN
(config-af)# neighbor adresa activate
(config-af)# redistribute lisp
Jako poslední krok je potřeba specifikovat na MS, která VRF (specifikována atributem VRF-jmeno) má být použita LISP-ALTem pro výměnu IPv4 a IPv6 směrovacích informací. Toho se dosahuje pomocí duální příkazu:
(config-router-lisp)# {ipv4|ipv6} alt-vrf VRF-jmeno
A jen pro jistotu všechny tyto konfigurační kroky demonstrované na reálném příkladě jako výňatek z konfigurace MRMS2, kde jako specializovaná VRF slouží ta se jménem „LISPvrf“, přičemž se přenášejí skrz BGP jen IPv4 informace o lokátorech:
vrf definition LISPvrf
rd 65100:1
address-family ipv4
exit-address-family
address-family ipv6
exit-address-family
interface Tunnel0
vrf forwarding LISPvrf
ip address 192.168.0.1 255.255.255.252
tunnel source FastEthernet1/1
tunnel destination 192.0.2.2
router lisp
ipv4 alt-vrf LISPvrf
ipv6 alt-vrf LISPvrf
router bgp 65100
address-family ipv4 vrf LISPvrf
redistribute lisp
neighbor 192.168.0.2 remote-as 65200
neighbor 192.168.0.2 activate
exit-address-family
address-family ipv6 vrf LISPvrf
exit-address-family
Pozorování
Pokud bychom si sestavili demonstrační úlohu, pak následující věci bychom v ní mohli zřetelně pozorovat za použití správných příkazů pro zobrazení stavu na Cisco směrovačích.
Kontrola funkčnosti LISPu
Dejme tomu, že bychom chtěli na xTR-A1 ověřit stav LISPu, pak použijeme příkaz show {ip|ipv6} lisp, který nám vylistuje jaké role tento směrovač zastává, jaké MR a MS používá, zda-li má nakonfigurované nějaké PxTR, jaký je stav perzistentní map cache a další provozní údaje:
xTR_A1# show ip lisp Router-lisp ID: 0 Locator table: default EID table: default ITR Solicit Map Request (SMR): accept and process Max SMRs per map-cache entry: 8 more specifics Multiple SMR suppression time: 60 secs ETR accept mapping data: disabled, verify disabled ETR map-cache TTL: 1d00h Locator Status Algorithms: RLOC-probe algorithm: enabled Static mappings configured: 0 Map-cache size/limit: 1/1000 Map-cache activity check period: 60 secs Map-database size/limit: 1/1000 Persistent map-cache: interval 01:00:00 Earliest next store: 00:54:42 Location: NONE
Kontrola stavu mapování EID k RLOCům
Příkazem show {ip|ipv6} lisp database si můžeme nechat vypsat, jaké všechny RLOCy se xTR-A1 snaží registrovat:
xTR_A1# show ip lisp database LISP ETR IPv4 Mapping Database for EID-table default (IID 0), LSBs: 0x3, 1 entries Locator Pri/Wgt Source State xTR_A1# show ipv6 lisp database LISP ETR IPv6 Mapping Database for EID-table default (IID 0), LSBs: 0x3, 1 entries Locator Pri/Wgt Source State
Nu a na MRMS1 se pak pomocí příkazu show lisp site podívat, jaký je stav registrací na MS:
MRMS1# show lisp site
LISP Site Registration Information
Site Name Last Up Who Last Inst EID Prefix
Register Registered ID
K dotazu nad LISP mapovacím systémem lze použít program LIG (LISP Internet Groper), který se aktivně dotáže na RLOCy k EID, jež mu dáváme jako vstupní argument. Na Cisco zařízeních lze tento program použít formou příkazu lig, kdy mu místo adresy zadáme slovíčko self, čímž dojde ke zjištění toho, jaké RLOCy jsou k dispozici k našim EID. Ukázka je ze spuštění tohoto programu na xTR-A2:
xTR_A2#lig self ipv4 Mapping information for EID 153.16.10.0 from 2.0.0.1 with RTT 132 msecs Locator Uptime State Pri/Wgt xTR_A2#lig self ipv6 Mapping information for EID 2610:D0:AAAA:: from 1.0.0.1 with RTT 248 msecs Locator Uptime State Pri/Wgt
Kontrola LISP-ALTu
Funkčnost LISP-ALTu začíná nejprve kontrolou konektivity GRE tunelu a navázání BGP peeringu. Pokud je zde vše bez problému, pak by měli být na MRMS* směrovačích být vidětelné patřičné routy (EID sítě) ve směrovací tabulce pro VRF LISPvrf:
MRMS1# show ip route vrf LISPvrf
Routing Table: LISPvrf
Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route, H - NHRP, l - LISP
+ - replicated route, % - next hop override
Gateway of last resort is not set
153.16.0.0/24 is subnetted, 2 subnets
192.168.0.0/24 is variably subnetted, 2 subnets, 2 masks
C 192.168.0.0/30 is directly connected, Tunnel0
L 192.168.0.1/32 is directly connected, Tunnel0
Kontrola ITR map cache
Vylistování aktuálního obsahu map-cache se dělá pomocí příkazu show ip lisp map-cache. Pokud bychom toto udělali v čerstvě spuštené laboratoři, pak by výpis zel prázdnotou:
xTR_A1# show ip lisp map-cache LISP IPv4 Mapping Cache for EID-table default (IID 0), 1 entries 0.0.0.0/0, uptime: 00:26:13, expires: never, via static send map-request Negative cache entry, action: send-map-request
Spusťme nyní ping z 153.16.10.1 na 153.16.20.1 na xTR-A1 a sledujme, co se stane. ITR nezná RLOCy k danému EID, pošlete tedy LISP Map-Request zprávu, která se dostane na MRMS1, odtud LISP-ALTem až na MRMS2, který jej deleguje na xTR-B1. xTR-B1 odpoví pomocí LISP Map-Reply zprávy. xTR-A1 se tak naučí dostupné RLOCy (3.0.0.1, 4.0.0.1 a 5.0.0.1), přičemž následně xTR-A1 provede ještě kontrolu živosti RLOCů výměnou dalších LISP Map-Request/Response zpráv s patřičnými xTR-B*. Mezitím jeden až dva pingy vytimeoutují. Nicméně ihned, jak xTR-A1 zjistí alespoň jeden živý RLOC, začne již komunikace mezi hraničními xTR s nejlepší prioritou (v našem případě xTR-A1 a xTR-B2) chodit bez problému a v map cache xTR-A1 se vytvoří nový záznam. Celé to ilustruje následující kontrolní výpis:
xTR_A1# ping 153.16.20.1 source 153.16.10.1 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 153.16.20.1, : Packet sent with a source address of 153.16.10.1 , round-trip min/avg/max = 84/108/124 ms xTR_A1# show ip lisp map-cache LISP IPv4 Mapping Cache for EID-table default (IID 0), 0.0.0.0/0, uptime: 00:26:13, expires: never, via static send map-request Negative cache entry, action: send-map-request
Předchozí slova i popsané chování lze snadno ověřit, pokud bychom si na rozhraní FastEthernet1/0 xTR-A1 spustili zachytávání paketů do PCAP souboru a následně si provoz prohlédli např. pomocí WireSharku, tak jak již bez dalšího komentáře ukazuje následující screenshot:
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:
- RFC 6830: The Locator/ID Separation Protocol (LISP)
- RFC 6831: The Locator/ID Separation Protocol (LISP) for Multicast Environments
- RFC 6832: Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites
- RFC 6833: Locator/ID Separation Protocol (LISP) Map-Server Interface
- RFC 6834: Locator/ID Separation Protocol (LISP) Map-Versioning
- * RFC 6835: The Locator/ID Separation Protocol Internet Groper (LIG)
- * RFC 6836: Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)
- RFCDraft-DDT: LISP Delegated Database Tree
- LISP Charter: Přehled publikovaných dokumentů
Konfigurační white-papery:
- LISP v IP Journalu
- * LISP Command Reference
- * LISP Virutal Machine Mobility Solution
- * LISP Virtualization Guide
- LISP Q&A
- Pattincon Blog – LISP Papers
Demonstrační úloha:
- * GNS3 NET soubor s laboratoří
- * Finální konfigurace xTR-A1
- * Finální konfigurace xTR-A2
- * Finální konfigurace xTR-B1
- * Finální konfigurace xTR-B2
- * Finální konfigurace xTR-B3
- * Finální konfigurace MRMS1
- * Finální konfigurace MRMS2
- * Finální konfigurace ISP1
- * Finální konfigurace ISP2
- * Finální konfigurace ISP3
- * Finální konfigurace ISP4
- * Finální konfigurace ISP5
- * Odposlechnutý provoz na xTR-A1
ČLÁNKY DO MAILU