MPLS ve VRF Bc. Pavel Pustowka PUS0017, Bc. Radim Holek HOL0123 Abstrakt: Tento projekt navrhuje možnost řešení VPN sítí v MPLS, za použití virtuálních směrovacích tabulek. Součástí tohoto projektu je návrh a otestování topologie, která by mohla být navržena v praxi. Otestování bylo provedeno v laboratorních podmínkách na směrovačích značky CISCO. Klíčová slova: MPLS, VRF, Cisco 1 Úvod... 2 2 MPLS... 2 2.1 Výhody MPLS... 2 2.2 MPLS rámec... 3 2.3 Protokoly pro výměnu značek... 3 2.4 MPLS VPN... 3 2.5 VRF... 4 3 Návrh topologie... 4 3.1 Výběr VRF procesu na základě IP adresy... 4 3.2 Analýza provozu... 5 4 Závěr... 9 5 Citovaná literatura... 9 6 Přílohy... 10 6.1 Konfigurace jednotlivých prvků... 10 12. ledna 2015 1/14
1 Úvod V současné době vysokorychlostních sítí je snaha ze strany poskytovatelů internetu směrovat provoz efektivněji, minimálně co se v rámci své sítě týče. Jedna z možností je využít protokol ležící mezi druhou a třetí vrstvou OSI modelu, protokol MPLS. V následujících odstavcích bude tato technologie rozebrána podrobněji. V praxi se stává, že poskytovatel internetu nabízí zákazníkovi určitou IP adresu, pod kterou zákazník vystupuje. Může nastat situace, kdy jiný zákazník bude požadovat stejnou adresu jako předchozí zákazník. Obecně nastane konflikt, ale v dnešní době, kde zákazník je náš pán, se nabízí technologie VRF, která tuto problematiku může řešit. V tomto projektu je problém tohoto charakteru rozebrán a je zde navrhnuto jedno z řešení, jak by se tento problém mohl řešit. 2 MPLS MPLS (Multiprotocol Label Switching) je síťová technologie, která umožňuje přenos paketů, které jsou pro tento účel vybaveny značkou (návěstím) anglicky label. Data jsou tedy sítí přenášena ne na základě cílových IP adres, ale pomocí těchto značek. Informace o používaných značkách jsou vyměňovány mezi směrovači tak, aby se všechny směrovače dozvěděly o způsobu mapování značek v dané síti MPLS. Ve směrovačích dochází k tzv. přepínání paketů ze vstupu na výstup na základě hodnoty značky (label switching). Hodnota značky se po každém průchodu směrovačem mění. Podobným způsobem funguje přenos rámců na základě DLCI (Digital Link Connection Identifier) adres u technologie Frame Relay a přenos ATM buněk podle VPI/VCI (Virtual Path Identifier/Virtual Channel Identifier) adres u technologie ATM (Asynchronous Transfer Mode). Technologie MPLS se používá především v páteřních sítích WAN (Wide Area Network). [1] 2.1 Výhody MPLS Jednou z výhod je zrychlení přenosu dat v sítí. To se děje na základě přepínání značek, které je jednodušší, než na základě přepínání podle IP adres vyžadující prohledání směrovací tabulky, kdy je nutné nejprve z cílové IP adresy paketu a síťové masky vypočítat síťovou adresu a pak provést porovnání výsledné hodnoty s příslušným záznamem ve směrovací tabulce. IP adresy jsou také delší než MPLS značky (32 bitu IP adresa, 20 bitů MPLS značka). V současnosti tato vlastnost není podstatná, neboť díky ASIC (Application Specific Integrated Circuits) se dokáží pakety směrovat velkou rychlostí. Mezi další nesporné výhody patří: [1] Schopnost přenášet různé typy rámců - AToM (Any Transport over MPLS). Integrace IP a ATM ISP uvnitř vlastní sítě nemusí používat IGP protokol pro získávání cest do externích sítí, ale namísto toho se použije OSPF. Další možností je použití MPLS VPN technologie umožnuje bezpečnou výměnu směrovacích informací mezi vzdálenými zákaznickými sítěmi bez použití složitých paketových filtrů. MPLS umožňuje díky využití informací ze směrovacích tabulek použití optimálních cest pro přenos dat Traffic Engineering - cesta tak může být odlišná od cesty vybrané směrovacím protokolem. Zatímco technologie MPLS dokáže přepínat jednotlivé pakety, technologie GMPLS (Generalized Multiprotocol Label Switching) dokáže přepínat i jiné objekty, především jednotlivá optická vlákna a optické signály na základě jejich vlnové délky. 12. ledna 2015 2/14
2.2 MPLS rámec Obrázek 1: MPLS Frame Label (značka, návěstí) má funkci adresy. Může mít hodnotu 0 až 220 1 (1 048 575). Hodnoty 0 až 15 jsou rezervované pro speciální účely. [1] CoS (Class of Service)/Experimental původně nemělo toto pole žádný speciální účel, v současnosti se používá ke specifikaci třídy provozu, což umožňuje poskytnout požadovanou kvalitu služby (QoS) přenášeným datům. [1] S (Stack, Bottom of Stack) Pokud má hodnotu 1, je dané záhlaví posledním záhlavím v řadě. Díky tomu je možné, aby bylo k paketu při přenosu sítí MPLS přidáno více záhlaví. [1] TTL (Time To Live) Má podobný význam jako v záhlaví IP paketu. Při každém průchodu směrovačem se jeho hodnota sníží o jedna. Když dosáhne nuly, je celý paket zahozen. Brání se tím vzniku směrovací smyčky. [1] 2.3 Protokoly pro výměnu značek Aby MPLS mohl značky přepínat, musí se naučit, v kterém úseku se značky mají používat. Pro výměnu informací o použitých značkách pro jednotlivé LSP lze použít již existující směrovací protokoly. Pro směrování mezi externími AS se používá upravený protokol BGP, MP-BGP. [1] TDP (Tag Distribution Protocol) starší protokol vytvořený firmou Cisco, který se již nepoužívá, LDP (Label Distribution Protocol) standardizovaný protokol pro výměnu značek uvnitř autonomních systémů, RSVP (Resource Reservation Protocol) se používá pro potřeby MPLS Traffic Engineering. 2.4 MPLS VPN MPLS VPN (Multiprotocol Label Switching Virtual Private Network) je v současnosti nejoblíbenější aplikací postavenou na základě technologie MPLS. Tato technologie nahradila starší VPN sítě, kde je oddělení provozu z různých privátních sítí uvnitř sítě poskytovatele síťové služby realizováno pomocí virtuálních kanálů technologie Frame Relay nebo ATM. MPLS VPN vychází z modelu peer to peer sítí. Další výhodou technologie MPLS VPN je, že v sítích různých zákazníků se mohou používat stejné IP adresy např. privátní adresy. MPLS VPN síť obsahuje následující komponenty: [1] Customer edge (CE) router směrovač na okraji sítě zákazníka. Provider edge (PE) router směrovač na okraji sítě poskytovatele síťové služby. Mezi zařízeními CE a PE je přímá vazba na síťové vrstvě a probíhá mezi nimi výměna směrovacích informací (proto také mluvíme o peer to peer modelu). Customer (C) router směrovač uvnitř sítě zákazníka. Nemá žádnou vazbu na síť poskytovatele síťové služby. Provider (P) router směrovač uvnitř sítě poskytovatele síťové služby. Nemá žádnou vazbu na síť zákazníka. 12. ledna 2015 3/14
Pro odlišení síťových prefixů z různých sítí VPN se využívá speciální identifikátor RD (Route Distinguisher). MP BGP pak přenáší kombinaci RD a prefixu IPv4 tzv. prefix VPNv4. RD má 64 bitů a zapisuje se nejčastěji ve formátu číslo autonomního systému: číslo identifikující VRF (např.: 1:1). Celý prefix VPNv4 pak má 96 bitů a může vypadat takto 1:1:10.1.1.0/24. [1] 2.5 VRF VRF (Virtual Routing and Forwading) je IP sítích metoda sloužící k oddělení sítí na úrovní směrovacích tabulek a to způsobem umožňující vytvořit více virtuálních směrovacích tabulek nezávislých na sobě. Je tím zvýšena bezpečnost a funkcionalita, umožňující používat např. technologii MPLS VPN. Na každou směrovací instanci je tady FIB (forwarding infromation base), což je v podstatě směrovací tabulka. Je tedy jasné, že přibývajícími sítěmi se zvyšuje počet FIB, a tím se zvyšuje utilizace procesoru ve směrovači. VRF lze konfigurovat ve dvou režimech, simple a full. VRF Lite (Simple) použití VPN sítí bez MPLS funkce IPVPN (Full) použití MPLS, standardní MPLS VPN sítě. 3 Návrh topologie Pro účely testování jsme zvolili níže zobrazenou topologii. Sít je rozdělena na část providera, kde běží MPLS a pomocný MP-BGP. Na krajích této sítě jsou dva různí klienti. Cílem bylo zprovoznit sít tak, aby klienti napravo využívající stejné adresy byly logicky oddělené. K tomu pomohl VRF proces. Hlavním prvkem sítě je směrovač RA, který rozděluje sít na dvě logické části. Klienti se v levé části sítě mezi sebou nevidí, i když jsou na jednom subnetu, ale každý z nich se přes MPLS CORE domluví se svým protějškem na druhé straně. Řešení je konfigurováno přes ROUTE mapy a ACCESS listy, které jsou definovány na RA směrovači. Lo0 10.0.0.21/32 Z1-1 192.168.1.0/24 Z2-1 192.168.2.0/24 Zákazníci 192.168.0.0/16 Lo0 10.0.0.20/32 Fa 0/1.1/16 Lo2 10.0.2.1/32 RA VRF Fa 0/0.1/30 Fa 0/0 MPLS + MP-BGP 10.0.0.24 12. ledna 2015 4/14.2/30 RD - P Fa 0/1.10/30 s 0/1/0.13/30 Fa 0/1.9/30.14/30 s 0/1/0 RB RC Fa 0/0 Fa 0/0 Lo0 10.0.2.2/32 Z1-2 1.1.1.1 Z2-2 1.1.1.1 3.1 Výběr VRF procesu na základě IP adresy Na ukázkové technologii jsou v segmentu Zákazníci 2 uživatelé, přičemž oba mohou komunikovat mezi sebou, ale vždy jen s jednou vzdálenou sítí. Může se například jednat o vzdálené pracoviště dvou firem, které spolupracují na nějakém projektu. Je třeba tedy zajistit komunikaci v rámci tohoto vzdáleného pracoviště, ale zároveň oddělit přístup k centrále obou firem (včetně možnosti překrývaní rozsahu IP adres mezi centrálami). 3.1.1 Oddělením provozu Jednou z možností jak docílit požadovaného výsledku je fyzickým oddělením provozu. Do všech stanic můžeme nainstalovat více síťových karet. Tato úvaha, ale neodpovídá navrhované topologii, protože by potřebovala více fyzických rozhraní na RA. Pokud by směrovač RA podporoval rozdělení fyzického rozhraní na logické podle VLAN, pak by bylo možné docílit oddělení provozu na navrhované topologii pomocí VLAN. 3.1.2 Využitím Cisco nástroje Podle dokumentace Cisco je možné nakonfigurovat směrovač k výběru VRF na základě zdrojové adresy [2]. Tato možnost byla prozkoumána, ale nebylo možné ji otestovat, protože žádný z dostupných směrovačů tuto technologii nepodporoval. Tuto funkcionalitu podporují směrovače nejvyšší řady - 12000. V simulačním
programu GNS 3 jsme měli možnost nahlédnout do image z řady 7000, tam však funkcionalita nebyla dostupná. Zjistili jsme, že tato funkcionalita je podporována pouze v Service provider imagech a je potřeba, aby směrovač podporoval řadu dalších funkcionalit. Navíc je tuto funkcionalitu možno použít pouze ze zákaznické IP sítě do MPLS sítě. 3.1.3 Využitím Route-map a Access-listů Další možností, jak provést výběr VRF na základě zdrojové adresy je tzv. Policy based routing (PBR). Tedy směrování podle jiných pravidel, než klasické směrování. Tato možnost byla implementována a otestována. Pravidla PBR se nejčastěji definují pomocí Route-map a Access-listů. Mají mnoho využití a jedním z nich je nastavení VRF procesu. Route-mapa je sada pravidel, které se vykonávají v předem určeném pořadí. Každé pravidlo se typicky skládá z podmínky a akce. Pokud testovaný paket projde podmínkou, pak se provede daná akce. Pokud neprojde, tak se pokračuje dalším záznamem. Akcí může být nastavení NEXT-HOPu, VRF, atd. Nejjednodušší podmínkou je nejspíše Access-list, což je sada pravidel, která můžou paket, buď přijmout, nebo zavrhnout. Každé pravidlo (řádek) Access-listu obsahuje zdrojovou a cílovou adresu a tzv. wildcarty (obrácené masky). Zároveň s (kromě) Access-listů lze pro podmínku použít např. velikost paketu, protokol, atd. Pro implementaci této možnosti se k rozhraní směřující do segmentu Zákazníci se přiřadí nová Routemapa rm. (config-if)#ip policy route-map rm Pro přidání zákazníka se pak pouze vytvoří nový Access-list, který filtruje adresy daného zákazníka. (config)#access-list 101 permit ip 192.168.1.0 0.0.0.255 any (config)#access-list 101 deny ip any any Tento Access-list se přidá jako nový záznam do Route-mapy s nastavením požadovaného VRF procesu. (config)#route-map rm permit 10 (config-rtm)#match ip address 101 (config-rtm)#set vrf z1 Pro obousměrný provoz je ještě nutné propagovat adresy do segmentu Zákazníci. (config-if)#ip vrf receive z1 3.1.4 Použitím tunelů Další možností by bylo vytvoření virtuálního tunelu v rámci směrovače RA. Jeden konec tunelu by byl v požadovaném VRF procesu a druhý by byl volný. Pak by se provedlo směrování paketů do zadaného tunelu. Problém by ale nastal, při směrování do tunelu, které by bylo založené na základě zdrojové adresy. Nejjednodušším řešením by bylo PBR. Nicméně řešení pomocí PBR uvedené výše by bylo efektivnější. Dalším problémem by byla implementace tunelů na daném zařízení. Ne všechna musí podporovat tunel v rámci jednoho směrovače. 3.2 Analýza provozu V této kapitole se zaměříme na analýzu provozu testovací konfigurace na všech směrovačích, především pak na směrovač RA, který zpracovává a odděluje jednotlivé zákazníky. Testování probíhalo za pomocí pingu na cíl 1.1.1.1, zatímco jsme na trase přerušovali konexi k cílovým směrovačům a sledovali chování jak na úrovní MP-BGP zpráv tak MPLS VPN. 3.2.1 Analýza provozu na úrovni protokolu MP-BGP V zapojené sítí jsme pomocí nástroje PING testovali konektivitu k cíli. V určitých intervalech si směrovače RA a RB vyměňovali KEEPALIVE zprávy, což jsou oznámení o tom, že jsou v síti aktivní. V další fázi jsme rozpojili trasu mezi RD a RB. MP-BGP na to zareagoval zprávou UPDATE, v které byla informace o rozpojení 12. ledna 2015 5/14
sítě k RB. Zpráva UPDATE nese dvě důležité informace, PATH ATRIBUTE MP_UNREACH_NLRI informace o nedostupném spojení a parametr WITHDRAWN ROUTES, který říká, o jaký cíl se jedná. Dále pak parametr ROUTE DISTINGUISHER, který specifikuje přesně cíl. RD=200:3 je v našem případě směrovač RB. Zpráva byla vygenerována směrovačem RA, který po vypršení KEEPALIVE intervalu zjistil rozpadnutí trasy směrem k RB Obrázek 2: Obsah BGP zprávy - UPDATE Následujícím krokem bylo vypojení RC. Na to protokol BGP odpověděl opět zprávou UPDATE. Než k tomu došlo, vyměňovali si směrovače KEEPALIVE zprávy o stavu sítě. Ty obsahovaly také MPLS záznam, který bude rozebrán v kapitole níže. Za pozornost zde stojí opět parametr ROUTE DISTINGUISHER: 200:2, který určuje nedostupnost sítě k RC. Tuto zprávu zjistil po uplynutí KEEPALIVE časovače RA směrem k RC. Obrázek 3: Obsah BGP zprávy UPDATE V dalším kroku jsme opět obnovili prvně spojení k RB a poté k RC. Zpráva UPDATE tentokrát obsahovala o mnoho více parametru vztahující se k sestavení spojení v BGP. Analýza těchto parametrů by byla vhodnější v projektu o BGP atributech mezi AS. V našem případě se opět zaměříme na cílový parametr RD a informaci o sestavení spojení. Tentokrát oznámil svou cestu směrovač RB a RA se o ní dozvěděl. 12. ledna 2015 6/14
Obrázek 4: BGP zpráva UPDATE obsahující parametry při sestavování spojení V posledním kroku jsme zapojili dalšího zákazníka a čekali jsme na zaslání zprávy UPDATE od směrovače připojující dalšího zákazníka. Obrázek 5: BGP zpráva UPDATE vygenerována směrovačem RC 3.2.2 Analýza protokolu MPLS Zprávy MPLS protokolu jsme mohli vidět jak použití ICMP protokolu, tak i v BGP zprávě KEEPALIVE. Testování probíhalo za pomocí nástroje PING. Na dalším obrázku vidíme PING z IP adresy 192.168.2.1 na 1.1.1.1. Také si můžeme všimnout dvojitého zabalení na úrovni MPLS, což je princip funkce MPLS VPN. Vidíme to také proto, že jsme tyto data monitorovali mezi směrovači RA a RD, kde probíhá dvojité zabalení do MPLS. Za směrovačem P bychom viděli pouze jedinou hlavičku MPLS při odchozí zprávě. 12. ledna 2015 7/14
Obrázek 6: MPLS značky při ICMP requestu na adresu 1.1.1.1 Další obrázek zachytává hlavičku MPLS v protokolu ICMP při opačném směru reply. Zde právě vidíme už jen jed hlavičku MPLS, neboť směrovač RD provádí odstraňování jedné ze značek a nechává druhou pro identifikaci cíle - zákazníka. Obrázek 7: MPLS značka při ICMP reply na adresu 192.168.2.1 V dalším kroku jsme odpojili i druhého zákazníka a ICMP zprávy přestaly chodit. Zpráva ICMP postupovala od zákazníka Z2 z levé části sítě, k zákazníkovi Z2 na pravé straně topologie a jelikož jsme odpojili prvně zákazníka Z1, ICMP zprávy stále postupovaly sítí. Až v tomto kroku, kdy došlo k odpojení i Z2 ICMP zprávy přestaly chodit. Z programu WIRESHARK můžeme analyzovat v tomto čase pouze BGP protokol, který zaznamenal rozpad spojení. Dále pak pokračuje zapojení linky směrem k Z2 a poté Z1, z ICMP a BGP můžeme vidět navázání spojení. Pro odchozí směr vidíme opět dvakrát MPLS hlavičku a pro příchozí hlavičku jednu. Tímto jsme otestovali správnou funkčnost MPLS VPN k jednotlivým zákazníkům a ověřili jsme jejich správné propojení, tj. Z2-Z2 a Z1-Z1. 12. ledna 2015 8/14
4 Závěr Cílem této práce bylo prověřit možnost použití MPLS jako technologie pro oddělení provozu. V rámci práce byla navržena topologie, kde se ověřovala možnost oddělení provozu. MPLS by měl teoreticky zvyšovat i rychlost sítí, ale ta ověřována nebyla. Oddělení provozu bylo provedeno pomocí MPLS VPN. Oddělení se prokázalo jako dostačující. Pakety nebylo možné zaměnit. Další částí práce bylo nalezení možnosti volby VRF procesu (a tedy i VPN) v rámci jednoho segmentu na základě zdrojové IP adresy. Byla nalezena řada možných řešení, z nichž nejproveditelnější bylo implementováno a ověřeno. Řešení bylo funkční. 5 Citovaná literatura [1] MACHNÍK, P. Širokopásmové sítě pro integrovanou výuku VUT a VŠB TUO.. Ostrava: Vysoká škola báňská Technická univerzita Ostrava, 2014. 978 80 248 3630 0. [2] CISCO. MPLS VPN VRF Selection Based on Source IP Address. Cisco Systems, Inc. Dostupné také z: http://www.cisco.com/c/en/us/td/docs/ios/12_0s/feature/guide/vrfselec.html 12. ledna 2015 9/14
6 Přílohy 6.1 Konfigurace jednotlivých prvků V této kapitole nalezneme důležité konfigurační nastavení pro jednotlivé směrovače v naší topologii. Na všech směrovačích byl zapnutý proces MPLS. mpls label protocol ldp 6.1.1 Směrovač RA VRF ip vrf selection ip vrf z1 rd 200:1 route-target export 200:3 route-target import 200:3 ip vrf z2 rd 200:2 route-target export 200:2 route-target import 200:2 interface Loopback0 ip address 10.0.0.20 255.255.255.255 interface Loopback2 ip address 10.0.2.1 255.255.255.255 interface FastEthernet0/0 ip address 10.0.0.1 255.255.255.252 duplex auto speed auto mpls ip interface FastEthernet0/1 ip vrf receive z1 ip vrf receive z2 ip address 192.168.0.1 255.255.0.0 ip policy route-map rm 12. ledna 2015 10/14
duplex auto speed auto router ospf 1 router bgp 200 bgp log-neighbor-changes redistribute static neighbor 10.0.0.21 remote-as 200 neighbor 10.0.0.21 update-source Loopback0 neighbor 10.0.2.2 remote-as 200 neighbor 10.0.2.2 update-source Loopback2 no auto-summary address-family vpnv4 neighbor 10.0.0.21 activate neighbor 10.0.0.21 send-community both neighbor 10.0.2.2 activate neighbor 10.0.2.2 send-community both exit-address-family address-family ipv4 vrf z1 redistribute connected redistribute static neighbor 10.0.0.21 remote-as 200 neighbor 10.0.0.21 update-source Loopback0 neighbor 10.0.0.21 activate exit-address-family address-family ipv4 vrf z2 redistribute connected neighbor 10.0.2.2 remote-as 200 neighbor 10.0.2.2 update-source Loopback2 neighbor 10.0.2.2 activate exit-address-family ip forward-protocol nd no ip http server no ip http secure-server 12. ledna 2015 11/14
logging esm config access-list 101 permit ip 192.168.1.0 0.0.0.255 any access-list 101 deny ip any any access-list 102 permit ip 192.168.2.0 0.0.0.255 any access-list 102 deny ip any any route-map rm permit 10 match ip address 101 set vrf z1 route-map rm permit 20 match ip address 102 set vrf z2 6.1.2 Směrovač RD P interface GigabitEthernet0/0 ip address 10.0.0.2 255.255.255.252 duplex auto speed auto mpls ip interface GigabitEthernet0/1 ip address 10.0.0.10 255.255.255.252 duplex auto speed auto mpls ip interface Serial0/1/0 ip address 10.0.0.13 255.255.255.252 mpls ip router ospf 1 6.1.3 Směrovač RC ip vrf z2 rd 200:2 route-target export 200:2 12. ledna 2015 12/14
route-target import 200:2 interface Loopback0 ip address 10.0.2.2 255.255.255.255 interface FastEthernet0/0 ip vrf forwarding z2 ip address 1.1.1.1 255.255.255.0 interface Serial0/1/0 ip address 10.0.0.14 255.255.255.252 mpls ip clock rate 125000 router ospf 1 router bgp 200 bgp log-neighbor-changes redistribute static neighbor 10.0.2.1 remote-as 200 neighbor 10.0.2.1 update-source Loopback0 no auto-summary address-family vpnv4 neighbor 10.0.2.1 activate neighbor 10.0.2.1 send-community both address-family ipv4 vrf z2 redistribute connected neighbor 10.0.2.1 remote-as 200 neighbor 10.0.2.1 update-source Loopback0 neighbor 10.0.2.1 activate 6.1.4 Směrovač RB ip vrf zakaznik1 rd 200:3 route-target export 200:3 12. ledna 2015 13/14
route-target import 200:3 interface Loopback0 ip address 10.0.0.21 255.255.255.255 interface FastEthernet0/0 ip vrf forwarding zakaznik1 ip address 1.1.1.1 255.255.255.0 interface FastEthernet0/1 ip address 10.0.0.9 255.255.255.252 mpls ip router ospf 1 network 10.0.0.8 0.0.0.3 area 0 router bgp 200 bgp log-neighbor-changes neighbor 10.0.0.20 remote-as 200 neighbor 10.0.0.20 update-source Loopback0 address-family ipv4 no neighbor 10.0.0.20 activate no auto-summary address-family vpnv4 neighbor 10.0.0.20 activate neighbor 10.0.0.20 send-community both address-family ipv4 vrf zakaznik1 redistribute connected neighbor 10.0.0.20 remote-as 200 neighbor 10.0.0.20 update-source Loopback0 neighbor 10.0.0.20 activate 12. ledna 2015 14/14