Hlavní navigace

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

17. 10. 2013
Doba čtení: 13 minut

Sdílet

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. Tento seriál se vám pokusí nastínit vše podstatné – ideu funkce, strukturu protokolu i konfiguraci na zařízeních. Dnes poslední díl.

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-A1xTR-A2, v rámci lokality Site B je to pak xTR-B1, xTR-B2xTR-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. MRMS1MRMS2 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, ISP4ISP5. 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 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-B1xTR-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*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/242610: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-A1xTR-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/242610: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 MRMS1MRMS2 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
  Instance ID: 0
  Router-lisp ID: 0
  Locator table: default
  EID table: default
  Ingress Tunnel Router (ITR): enabled
  Egress Tunnel Router (ETR): enabled
  Proxy-ITR Router (PITR): disabled
  Proxy-ETR Router (PETR): disabled
  Map Server (MS): disabled
  Map Resolver (MR): disabled
  Map-Request source: 153.16.10.1
  ITR Map-Resolver(s): 2.0.0.255
  ETR Map-Server(s): 2.0.0.255 (00:00:18)
  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

153.16.10.0/24
Locator  Pri/Wgt  Source    State
1.0.0.1  1/50     cfg-addr  site-self, reachable
2.0.0.1 1/50     cfg-addr  site-other, report-reachable

xTR_A1# show ipv6 lisp database LISP 
ETR IPv6 Mapping Database for EID-table default (IID 0), LSBs: 0x3, 1 entries

2610:D0:AAAA::/64
Locator  Pri/Wgt  Source    State
1.0.0.1  1/50     cfg-addr  site-self, reachable
2.0.0.1  1/50     cfg-addr  site-other, report-reachable

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
A          00:00:10  yes  1.0.0.1           153.16.10.0/24
           00:00:08  yes  1.0.0.1           2610:D0:AAAA::/64

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
153.16.10.0/24, uptime: 00:00:09, expires: 23:59:52, via map-reply, self
  Locator  Uptime    State     Pri/Wgt
  1.0.0.1  00:00:09  up        1/50
  2.0.0.1  00:00:09  up, self  1/50
xTR_A2#lig self ipv6
Mapping information for EID 2610:D0:AAAA:: from 1.0.0.1 with RTT 248 msecs
2610:D0:AAAA::/64, uptime: 00:00:00, expires: 23:59:52, via map-reply, self
  Locator  Uptime    State     Pri/Wgt
  1.0.0.1  00:00:00  up        1/50
  2.0.0.1  00:00:00  up, self  1/50

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
l      153.16.10.0 [10/1] via 0.0.0.0, 00:14:04, Null0
B      153.16.20.0 [20/1] via 192.168.0.2, 00:09:43
    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 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, timeout is 2 seconds:
Packet sent with a source address of 153.16.10.1
..!!!
Success rate is 60 percent (3/5), 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), 2 entries

0.0.0.0/0, uptime: 00:26:13, expires: never, via static send map-request
  Negative cache entry, action: send-map-request
153.16.20.0/24, uptime: 00:00:20, expires: 23:59:33, via map-reply, complete
  Locator  Uptime    State  Pri/Wgt
  3.0.0.1  00:00:20  up     254/50 
  4.0.0.1  00:00:20  up     1/100  
  5.0.0.1  00:00:20  up     254/50 

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:

root_podpora

Konfigurační white-papery:

Demonstrační úloha:

Byl pro vás článek přínosný?