Testy kompatibility BGP a OSPF mezi Cisco a Mikrotik

Transkript

1 Testy kompatibility BGP a OSPF mezi Cisco a Mikrotik Marcel Staniek Abstrakt: Tento semestrální projekt se zabývá interoperabilitou směrovacích protokolů OSPF a BGP mezi směrovači společností Cisco a Mikrotik. V části věnované protokolu OSPF je popsán postup při vytváření oblastí, virtuální linky mezi oblastmi, propagování výchozí brány a autentizace směrovací informace. Část věnovaná protokolu BGP se pak zabývá konfiguraci atributů multi exit discriminator, local preference, filtrováním vybraných směrovacích informací a autentizací směrovací informace. Klíčová slova: Cisco, Mikrotik, OSPF, BGP, kompatibilita 1 Úvod Teoretický úvod k protokolům OSPF a BGP Ověření kompatibility protokolu OSPF Konfigurace směrovačů Cisco Konfigurace směrovačů Mikrotik Ověření kompatibility Ověření kompatibility protokolu BGP Konfigurace směrovačů Cisco Konfigurace směrovače Mikrotik Ověření kompatibility Závěr Literatura Přílohy Použité konfigurace...10 květen /12

2 1 Úvod Cílem toho semestrálního projektu je ověřit interoperabilitu směrovacích protokolů OSPF a BGP mezi směrovači výrobců Cisco a Mikrotik. V části věnované protokolu OSPF je popsán postup pro vytváření oblastí, virtuální linky mezi oblastmi, propagování výchozí brány a autentizace směrovací informace. Část věnovaná protokolu BGP se pak zabývá konfiguraci atributů multi exit discriminator, local preference, filtrováním vybraných směrovacích informací a autentizaci směrovací informace. Praktická část projektu byla odzkoušena na tomto hardwaru: 2x Cisco 2801 IOS 12.4; 1x Cisco 1851 IOS 12.2; 2x Mikrotik RouterBoard 133C RouterOS Teoretický úvod k protokolům OSPF a BGP Open Shortest Path First (OSPF) je směrovací protokol patřící do skupiny Interior Gateway routing (IGP) protokolů, jeho použití je tudíž výlučně uvnitř autonomního systému (AS). V současnosti se nejčastěji setkáme s druhou verzí tohoto protokolu z roku 1998, která byla standardizována v RFC Protokol OSPF patří do skupiny směrovacích protokolů stavů linek (link-state). K výpočtu nejkratších cest využívají směrovače pracující s tímto protokolem Dijkstrův algoritmus, někdy také označovaný jako Shortest Path First (SPF) algoritmus. Pomocí SPF algoritmu si každý směrovač vytváří SPF strom nejkratších cest, pomocí kterého je pak naplňována směrovací tabulka. K výpočtu SPF stromu využívá Dijkstrův algoritmus databázi označovanou jako Link-State DataBase (LSDB). Tato databáze je postupně naplňována, pomocí paketů označovaných jako Link-State Update (LSU). Uvnitř těchto LSU je pak přenášen jeden nebo více Link-State Advertisement (LSA), které obsahují informace o cenách linek, OSPF sousedech apod. Pokud směrovač příjme LSA, okamžitě posílá tuto informaci i dalším OSPF sousedům, čímž je dosaženo rychlé konvergence směrovacích tabulek. Sítě využívající protokolu OSPF jsou dobře škálovatelné díky tomu, že celou síť lze rozdělit do tzv. oblastí. Tyto oblasti jsou označovány buď jako běžné číslo, např. area 51, nebo ve formátu IP adresy, např. area Pokud je síť rozdělena na oblasti, LSU pak nejsou šířeny ke všem směrovačům v síti ale pouze k těm, které patří do stejné oblasti. Není tak nutné, aby při každé změně v síti docházelo k přepočítávání Dijkstrova algoritmu na všech směrovačích. Díky této vlastnosti protokolu OSPF je pak možné použít levnější směrovače, které by jinak měly problémy s velkými LSDB. Při vytváření OSPF oblastí je pak třeba počítat s tím, že je nutné zvolit jednu oblast jako páteřní, často označovanou jako area 0. K této páteřní oblasti jsou pak připojeny ostatní oblasti skrze Area Border Router (ABR), který má tolik LSDB, kolik oblastí propojuje. Pokud některá z oblastí nemůže být připojena přímo k páteřní oblasti je potřeba vytvořit tzv. virtual-link skrze některou z nepáteřních oblastí. Podrobnější informace o protokolu OSPF ze nalézt například v [1]. Na rozdíl od protokolu OSPF je protokol Border Gateway Protocol (BGP) zástupcem skupiny Exterior Gateway Protocol (EGP). V současnosti je BGP jediným používaným směrovacím protokolem mezi autonomními systémy a jedná se tudíž o jeden z nejdůležitějších protokolů Internetu, pomocí kterého si jednotliví Internet Service Providers (ISP) vyměňují směrovací informace o svých sítích. BGP oproti ostatním směrovacím protokolům nevyužívá metriku ale jeho proces rozhodování o směrování je závislý na vektoru cest skrze autonomní systémy (tzv. AS path) a na síťové politice definované jednotlivými ISP pomocí tzv. atributů. Současná čtvrtá verze protokolu BGP byla standardizována roku 2006 v RFC Mezi dvěma směrovači využívající protokol BGP se navazují sousedské vazby pomocí protokolu TCP. Tyto sousedské vazby se ovšem nenavazují automaticky tak jak je tomu u směrovacích protokolů ze skupiny IGP ale je nutné, aby je ručně nakonfiguroval síťový administrátor. Protože v jednom autonomním systému může být více hraničních směrovačů využívajících protokolu BGP pro spojení s různými AS, je nutné aby i mezi směrovači ve stejném AS byly navazovány sousedské vazby. V takovém případě mluvíme o interním BGP (IBGP), zatímco v případě kdy jsou sousedské vztahy navazovány mezi směrovači z různých AS, mluvíme o externím BGP (EBGP). U IBGP není nutné aby směrovače byly přímými sousedy ale jejich vazba může být pouze logická. V této semestrální práci se zaměřím pouze na dva BGP atributy. První z nich bude atribut Multi-Exit Discriminator (MED), který bývá někdy označován jako metrika (nemá nic společného s metrikou známou z květen /12

3 IGP). Pomocí tohoto atributu může být externímu AS navrhována preferovaná cesta do AS, který MED propaguje. Cesta s nižší hodnotou MED je vybrána jako preferovaná. V některých případech však cesta s nižším MED nemusí být externím AS vybrána, protože tento AS může využívat i jiné BGP atributy k výběru cesty s vyšší prioritou při porovnávání cest do AS (např. weight). Dalším odzkoušeným BGP atributem v této semestrální práci bude local preference, ten oproti MED je přenášen pouze uvnitř AS pomocí IBGP. Pokud existuje několik výstupních bodů z AS, je možné využít atribut local preference k vybrání příslušného výstupního bodu pro určitou cestu. Výstupní bod s vyšší hodnotou local preference bude vybrán jako brána do sousedního AS. Detailnější popis BGP atributů, včetně postupu porovnávání jednotlivých atributů při výběru cesty, lze nalézt například v [2]. 2 Ověření kompatibility protokolu OSPF Na obrázku 1 je zobrazena topologie sítě, kterou jsem si vybral pro ověření kompatibility protokolu OSPF. Topologie byla zvolena tak, aby ji bylo možné dále použít jako jeden z autonomních systémů při ověřování protokolu BGP. Pro tuto síť jsem si zvolil adresní prostor /16, který jsem dále pomocí VLSM rozdělil na menší podsítě. Dále jsem jednotlivé rozhraní na směrovačích přiřadil do OSPF oblastí, tak aby bylo možné vyzkoušet tzv. virtuální linku. Pro autentizaci směrovací informace obě platformy podporují jak plain-text tak i hashovací algoritmus MD5. Pro ověření jsem si vybral autentizaci s MD5, protože je mnohem bezpečnější než plain-text. Obrázek 1: Topologie sítě pro ověření protokolu OSPF V následujících dvou podkapitolách jsou uvedeny zkrácené konfigurace použité pro nastavení OSPF na obou platformách. Kompletní konfigurace na všech prvcích jsou pak z důvodu přehlednosti přesunuty do příloh. 2.1 Konfigurace směrovačů Cisco Detailní popis všech konfiguračních příkazů pro směrovací protokol OSPF na směrovačích Cisco lze nálézt například v [3]. Spuštění procesu OSPF, přidání požadovaných sítí k propagaci a nastavení autentizace na směrovači RO: router ospf 1 network area 0 network area 0 květen /12

4 area 0 authentication message-digest Poté je nutné přiřadit každému rozhraní, na kterém chceme používat autentizaci směrovací informace, zvolené heslo: int fa 0/1 ip ospf message-digest-key 1 md5 Heslo Konfigurace na směrovači RN: router ospf 1 network area 1 network area 1 network area 1 area 1 authentication message-digest Přidání hesla pro autentizaci na příslušná rozhraní: int fa 0 ip ospf message-digest-key 1 md5 Heslo int fa 1 ip ospf message-digest-key 1 md5 Heslo Pro úplnost ještě doplním, že pro simulaci sítí /24 a /25 jsem využil virtuální rozhraní loopback. Pokud chceme, aby se tyto sítě správně propagovaly do OSPF je třeba použít příkaz ip ospf network point-to-point v konfiguračním režimu loopback rozhraní, viz kapitola 6. V opačném případě by se sítě propagovaly s prefixem / Konfigurace směrovačů Mikrotik Detailní popis všech konfiguračních příkazů pro směrovací protokol OSPF na směrovačích Mikrotik lze nalézt například v [4]. Protože směrovač označený jako μtik1 bude do OSPF propagovat výchozí cestu, je potřeba nejdříve tuto cestu vytvořit a poté ji do OSPF procesu přiřadit: /ip route add gateway= /routing ospf set distribute-default=if-installed-as-type-2 router-id= Poté je již možné přistoupit k vytvoření oblasti 1 (oblast 0 je již implicitně vytvořena jako backbone) a přidání sítí do OSPF procesu: /routing ospf area add area-id= name=area_1 /routing ospf network add network= /30 area=area_1 /routing ospf network add network= /30 area=backbone Nyní již zbývá pouze přidání autentizace a virtuální linky: /routing ospf area set area_1 authentication=md5 /routing ospf area set backbone authentication=md5 /routing ospf interface add interface=ether1 authentication=md5 authentication-key=heslo /routing ospf virtual-link add neighbor-id= transit-area=area_1 authentication=md5 authentication-key=heslo Konfigurace na μtik2: květen /12

5 /routing ospf set router-id= /routing ospf area add area-id= name=area_1 /routing ospf area add area-id= name=area_2 /routing ospf network add area=area_1 network= /30 /routing ospf network add area=area_2 network= /25 /routing ospf area set area_1 authentication=md5 /routing ospf area set area_2 authentication=md5 /routing ospf interface add interface=ether1 authentication=md5 authentication-key=heslo /routing ospf virtual-link add neighbor-id= transit-area=area_1 authentication=md5 authentication-key=heslo 2.3 Ověření kompatibility Pro ověření správné funkce jsem si vybral směrovač RO, na kterém jsem si zobrazil všechny naučené cesty z protokolu OPSF: RO#sh ip route ospf /8 is variably subnetted, 8 subnets, 4 masks O IA /25 [110/21] via , 00:07:26, FastEthernet0/1 O IA /30 [110/20] via , 00:07:26, FastEthernet0/1 O IA /30 [110/30] via , 00:07:26, FastEthernet0/1 O IA /25 [110/40] via , 00:07:26, FastEthernet0/1 O*E /0 [110/1] via , 00:07:26, FastEthernet0/1 Ze směrovací tabulky jde vidět že směrovač RO se správně naučil cesty do všech sítí připojených k ostatním směrovačům a to včetně sítě /25 z oblasti 2, která byla připojena pomocí tzv. virtuální linky. V posledním řádku směrovací tabulky je uvedena výchozí cesta, kterou se RO naučil od směrovače μtik1. Z této tabulky jde tedy vidět že všechny směrovače spolu navázaly sousedské vztahy a došlo k výměně všech potřebných směrovacích informací. 3 Ověření kompatibility protokolu BGP Na obrázku 2 je zobrazena topologie sítě, kterou jsem si vybral pro ověření kompatibility protokolu BGP. AS100 vychází z předchozí kapitoly, s tím rozdílem že oba hraniční směrovače autonomního systému (μtik1 a RO) budou sloužit k propagování sítí z AS100 do AS200, pomocí externího BGP. Oba hraniční směrovače budou blokovat propagování sítí s prefixem /30. Díky atributu local preference budou oba směrovače dosahovat cílů v AS200 pouze pomocí horní linky /30. Díky atributu MED pak bude směrovač RL dosahovat cílu v síti /24 pomocí spodní linky /30, zatímco cílů v supernetu /24 pomocí linky /30. Obrázek 2: Topologie sítě pro ověření protokolu BGP květen /12

6 3.1 Konfigurace směrovačů Cisco Detailní popis všech konfiguračních příkazů pro směrovací protokol BGP na směrovačích Cisco lze nalézt například v [5]. Nejdříve na směrovači RO spustíme BGP proces, přiřadíme jednotlivé sousedy a redistribuujeme všechny naučené cesty z protokolu OSPF do BGP: router bgp 100 neighbor remote-as 200 neighbor remote-as 100 redistribute ospf 1 Protože směrovač RO bere síť /24 jako přímo připojenou a ne jako síť naučenou z protokolu OSPF, je třeba ji přidat ručně : network mask Nyní již můžeme přistoupit k filtrování směrovacích informací. Pomocí prefix-listu budeme upravovat výstupní informace tak aby byly propagovány pouze sítě s prefixem v rozmezí 8 až 29 bitů a pomocí routemap budeme manipulovat v BGP atributy: neighbor prefix-list reject_/30 out neighbor route-map set_med out neighbor route-map set_local-pref in Protože směrovač RO uvádí ve směrovacích informacích vysílaných do IGBP jako další skok IP adresu , ke které ostatní směrovače cestu neznají, je nutné aby RO do IBGP propagoval jako další skok svou IP adresu: neighbor next-hop-self Nakonec ještě přidáme jednotlivým sousedům heslo pro autentizaci: neighbor password Heslo neighbor password Heslo Nyní již v konfiguračním režimu můžeme nastavit rozsah sítí, které chceme propagovat do EBGP: ip prefix-list reject_/30 seq 10 permit /0 ge 8 le 29 Posledním krokem bude definování route-map a access-listů, které budou sloužit route-mapám k prohledávání směrovacích informací a v případě že do access-listu některá cesta zapadne dojde k nastavení příslušného BGP atributu: route-map set_local-pref permit 10 match ip address 1 set local-preference 50 route-map set_local-pref permit 20 set local-preference 100 route-map set_med permit 10 match ip address 2 set metric 5 route-map set_med permit 20 set metric 130 květen /12

7 access-list 1 permit access-list 2 permit Na směrovači RL je konfigurace podstatně jednodušší: router bgp 200 neighbor remote-as 100 neighbor remote-as 100 neighbor password Heslo neighbor password Heslo network mask Konfigurace směrovače Mikrotik Detailní popis všech konfiguračních příkazů pro směrovací protokol BGP na směrovačích Mikrotik lze nalézt například v [6]. Popis filtrování směrovacích informací je pak popsán v [7]. Při konfiguraci protokolu BGP na směrovači μtik1 nejdříve nastavíme číslo AS, router ID a redistribuci všech naučených cest z protokolu OSPF do BGP: /routing bgp instance set default as=100 router-id= redistribute-ospf=yes Poté již můžeme přidávat jednotlivé sousedy a přiřazovat k nim hesla pro autentizaci a vstupní/výstupní filtry pro nastavování BGP atributů: /routing bgp peer add remote-address= remote-as=200 instance=default addressfamilies=ip in-filter=set-local-pref out-filter=set-med-and-reject-/30 tcp-md5-key=heslo /routing bgp peer add remote-address= remote-as=100 instance=default addressfamilies=ip nexthop-choice=force-self tcp-md5-key=heslo /routing bgp network add instance=default network= /30 Pro správnou funkci směrování je ještě nutné definovat směrovací filtry, ve kterých můžeme manipulovat s příchozími, resp. odchozími směrovacími informacemi a měnit tak atributy protokolu BGP. V našem případě konfigurace na μtik1 vypadá následovně: /routing filter add chain=set-local-pref prefix= /16 set-bgp-local-pref=200 action=accept /routing filter add chain=set-local-pref prefix= /16 invert-match=yes set-bgp-localpref=100 action=accept /routing filter add chain=set-med-and-reject-/30 prefix= /16 prefix-length=30-32 action=reject /routing filter add chain=set-med-and-reject-/30 prefix= /24 prefix-length=24-29 set-bgp med=5 action=accept /routing filter add chain=set-med-and-reject-/30 prefix= /24 prefix-length=24-29 invertmatch=yes set-bgp-med=130 action=accept 3.3 Ověření kompatibility Pro ověření funkčnosti atributu MED můžeme použít směrovač RL a nechat si zobrazit všechny cesty které, se od svých sousedů naučil, včetně hodnoty MED (Metric) pro tyto cesty: květen /12

8 RL#sh ip bgp BGP table version is 24, local router ID is Status codes: s suppressed, d damped, h history, * valid, > best, i - internal Origin codes: i - IGP, e - EGP,? - incomplete Network Next hop Metric LocPrf Weight Path *> / i * ? *> / i * ? * / i *> i *> / i Z výstupu jde vidět, že hodnoty MED byly pomocí EBGP vyměněny správně což nám také může potvrdit směrovací tabulka na směrovači RL: RL#sh ip route bgp /8 is variably subnetted, 6 subnets, 4 masks B /25 [20/5] via , 00:16:35 B /24 [20/5] via , 00:36:19 B /25 [20/5] via , 00:16:23 Z této tabulky jde vidět, že z AS 200 se bude provoz do sítě /24 směrovat na spodní linku, kdežto provoz do sítí /25 a /25 se bude směrovat na horní linku. K ověření toho zda došlo k výměně atributu local preference můžeme využít například směrovač RO: RO#sh ip bgp BGP table version is 43, local router ID is Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale Origin codes: i - IGP, e - EGP,? - incomplete Network Next Hop Metric LocPrf Weight Path *> / ? *> / ? * i i *> / ? * i i *> / ? * i i *> / ? * i i * i / i *> i *>i / i * i květen /12

9 Z výstupu jde vidět že směrovač μtik1 skutečně napropagoval do IGBP všechny cesty které zná z protokolu OSPF a že atribut local preference byl vyměněn správně, což nám může také potvrdit směrovací tabulka: RO#sh ip route bgp /8 is variably subnetted, 8 subnets, 4 masks B /16 [200/0] via , 00:08:06 Z této tabulky pak jde vidět že směrovač RO bude cíle v AS 200 (síť /16) dosahovat pomocí horní linky, prostřednictvím směrovače μtik1. 4 Závěr V části věnované protokolu OSPF jsem na případové studii předvedl že směrovače společností Cisco a Mikrotik bez jakýchkoliv problémů dokázali spolupracovat na výměně směrovacích informací a to i v případě kdy je nutné použít tzv. virtual-link a autentizaci pomocí MD5 algoritmu. V druhé části věnované protokolu BGP jsem pak ověřil správnou výměnu atributu local preference pomocí interního BGP a atributu MED, jehož výměna probíhá pomocí externího BGP. I v tomto případě došlo ke správné propagaci směrovací informace a síť zkonvergovala do předpokládané podoby. Bez problému proběhla i autentizace sousedských spojení mezi směrovači. Největší problém který nastal při řešení projektu byl způsoben nedokončenou dokumentací ke směrovačům společnosti Mikrotik. Přestože směrovače obsahovaly operační systém RoterOS verze 3.6, na internetových stránkách společnosti Mikrotik existuje dokumentace pouze pro verzi 2.9. To pak způsobilo například problém s parametrem address-families u protokolu BGP, kdy dokumentace se o tomto parametru vůbec nezmiňovala a implicitně nebyla nastavena žádná hodnota. Z tohoto důvodu pak nedošlo k navázání sousedského vztahu mezi směrovači a velice špatně se hledala příčina, když podle dokumentace mělo být vše v pořádku. 5 Literatura [1] GRYGÁREK, Jiří. Směrovací protokol OSPF [online]. [2008] [cit ]. Dostupný z WWW: < [2] Border Gateway Protocol [online]. c [cit ]. Dostupný z WWW: < [3] OSPF commands [online]. c [cit ]. Dostupný z WWW: < [4] OSPF [online]. c [cit ]. Dostupný z WWW: < [5] BGP commands [online]. c [cit ]. Dostupný z WWW: < [6] BGP Command Reference [online]. c [cit ]. Dostupný z WWW: < [7] BGP Routing Filters [online]. c [cit ]. Dostupný z WWW: < květen /12

10 6 Přílohy 6.1 Použité konfigurace V této poslední kapitole jsou uvedeny kompletní konfigurační soubory, které jsem použil na jednotlivých směrovačích. Schéma sítě, včetně adresního plánu, je uvdeno na obrázku 2. Směrovač RO: hostname RO interface Loopback0 ip address ip ospf network point-to-point interface FastEthernet0/1 ip address ip ospf message-digest-key 1 md5 Heslo interface Serial0/1/0 ip address clock rate router ospf 1 area 0 authentication message-digest network area 0 network area 0 router bgp 100 network mask redistribute ospf 1 neighbor remote-as 200 neighbor password Heslo neighbor prefix-list reject_/30 out neighbor route-map set_local-pref in neighbor route-map set_med out neighbor remote-as 100 neighbor password Heslo neighbor next-hop-self no auto-summary ip prefix-list reject_/30 seq 10 permit /0 ge 8 le 29 access-list 1 permit access-list 2 permit route-map set_med permit 10 match ip address 2 set metric 5 route-map set_med permit 20 set metric 130 route-map set_local-pref permit 10 match ip address 1 set local-preference 50 květen /12

11 route-map set_local-pref permit 20 set local-preference 100 end Směrovač RL: hostname RL interface Loopback0 ip address ip ospf network point-to-point interface Ethernet0 ip address interface Serial0 ip address router bgp 200 bgp log-neighbor-changes network mask neighbor remote-as 100 neighbor password Heslo neighbor remote-as 100 neighbor password Heslo no auto-summary end Směrovač RN: hostname RN interface Loopback0 ip address ip ospf network point-to-point interface FastEthernet0/0 ip address ip ospf message-digest-key 1 md5 Heslo interface FastEthernet0/1 ip address ip ospf message-digest-key 1 md5 Heslo router ospf 1 area 1 authentication message-digest network area 1 network area 1 network area 1 end květen /12

12 Směrovač μtik1: ip address add address= /30 interface=ether1 ip address add address= /30 interface=ether1 ip address add address= /30 interface=ether1 /ip route add gateway= /routing ospf set router-id= distribute-default=if-installed-as-type-2 /routing ospf area add area-id= name=area_1 /routing ospf network add area=area_1 network= /30 /routing ospf network add area=backbone network= /30 /routing ospf area set area_1 authentication=md5 /routing ospf area set backbone authentication=md5 /routing ospf interface add interface=ether1 authentication=md5 authentication-key=heslo /routing ospf virtual-link add neighbor-id= transit-area=area_1 authentication=md5 authentication-key=heslo /routing bgp instance set default as=100 router-id= redistribute-ospf=yes /routing bgp peer add remote-address= remote-as=200 instance=default addressfamilies=ip in-filter=set-local-pref out-filter=set-med-and-reject-/30 tcp-md5-key=heslo /routing bgp peer add remote-address= remote-as=100 instance=default addressfamilies=ip nexthop-choice=force-self tcp-md5-key=heslo /routing bgp network add instance=default network= /30 /routing filter add chain=set-local-pref prefix= /16 set-bgp-local-pref=200 action=accept /routing filter add chain=set-local-pref prefix= /16 invert-match=yes set-bgp-localpref=100 action=accept /routing filter add chain=set-med-and-reject-/30 prefix= /16 prefix-length=30-32 action=reject /routing filter add chain=set-med-and-reject-/30 prefix= /24 prefix-length=24-29 set-bgpmed=5 action=accept /routing filter add chain=set-med-and-reject-/30 prefix= /24 prefix-length=24-29 invertmatch=yes set-bgp-med=130 action=accept Směrovač μtik2: ip address add address= /30 interface=ether1 ip address add address= /25 interface=ether1 /routing ospf set router-id= /routing ospf area add area-id= name=area_1 /routing ospf area add area-id= name=area_2 /routing ospf network add area=area_1 network= /30 /routing ospf network add area=area_2 network= /25 /routing ospf area set area_1 authentication=md5 /routing ospf area set area_2 authentication=md5 /routing ospf interface add interface=ether1 authentication=md5 authentication-key=heslo /routing ospf virtual-link add neighbor-id= transit-area=area_1 authentication=md5 authentication-key=heslo květen /12