Šifrování MPLS provozu: Realizace MPLS nad Cisco DM-VPN

Transkript

1 Šifrování MPLS provozu: Realizace MPLS nad Cisco DM-VPN Bc. Michal Tabaček (tab0012), Bc. Jan Bonczek (bon0010) Abstrakt:Cílem projektu je provést šifrování MPLS provozu. Realizace šifrování bude provedena nad Cisco DM-VPN (Dynamické VPN). Ověření funkčnosti, šifrování a zachycení komunikace bude řešeno nad navrhnutou topologií sítě. Pro projekt budou použity směrovače společnosti Cisco (Cisco 2801, 2811 a Cisco 2901) postavené na platformě IOS. Klíčová slova: MPLS, DM-VPN, Cisco, BGP, EIGRP, IOS, směrovač, Wireshark, značka (label), NHRP. 1 Úvod Teoretický rozbor Dynamické VPN sítě (DM-VPN) Technologie MPLS Použitá zařízení pro testování Realizace dynamické VPN sítě Konfigurace Ověření funkčnosti Zavedení MPLS Konfigurace Ověření funkčnosti Návrh řešení na platformě IOS-XR Závěr Použitá literatura Přílohy prosinec /29

2 1 Úvod Cílem projektu je provést šifrování MPLS provozu, provoz MPLS bude realizován nad Cisco DM-VPN. Projekt se tedy zabývá problematikou konfigurace Dynamické Multipoint VPN sítě v prostředí Cisco směrovačů a nasazení MPLS technologie. Na úvod budou teoreticky ve stručnosti popsány dynamické VPN sítě a také technologie MPLS. Následně se budeme věnovat zapojení testovací topologie pomocí směrovačů Cisco, jejich konfiguraci, nastavení parametrů, šifrování a odchyt komunikace mezi směrovači pomocí software- Wireshark. 2 Teoretický rozbor 2.1 Dynamické VPN sítě (DM-VPN) Virtuální privátní sítě (VPN) slouží k vybudování zabezpečeného spojení například mezi dvěma sítěmi přes veřejnou či nezabezpečenou síť. VPN umožňuje vytvořit zabezpečený šifrovaný tunel, ve kterém můžeme provozovat například VoIP telefonii. V jednoduchém případě se bude jednat o zabezpečený tunel mezi dvěma pobočkami jedné firmy. Jestliže bychom, ale měli poboček více a měly by jednotlivé pobočky mezi sebou komunikovat zabezpečenou cestou, bylo by nutné vytvořit tunely každý s každým. Vytváření tunelů touto cestou by bylo konfiguračně náročné a usnadňuje ji možnost použití DM-VPN. DM-VPN je technologie, která umožňuje vytvářet VPN dynamicky na vyžádání. U této technologie se vyskytují tzv. HUB směrovače a směrovače v roli SPOKE. Obvykle bývá HUB směrovač umístěn v hlavní pobočce (centrále) a ostatní vzdálené pobočky mají SPOKE směrovače. Na vyžádání jsou poté vytvářeny tunely mezi HUB a SPOKE směrovači nebo i mezi SPOKE a SPOKE směrovači. Jestliže bychom měli vysvětlit využití DM-VPN na praktickém příkladu, lze představit firmu s hlavní centrálou a několika dalšími malými pobočkami. Typicky může nastat situace, kdy budou chtít všechny pobočky komunikovat s hlavní centrálou přes zabezpečený VPN tunel nebo také i situace, kdy budou chtít mezi sebou komunikovat zabezpečenou cestou i jednotlivé pobočky mezi sebou. V případě použití klasické VPN by musela mít každá pobočka nakonfigurovaný VPN tunel do centrály a také s ostatními pobočkami. Díky použití DM-VPN je v centrální pobočce umístěn HUB směrovač na kterém není v případě přidaní dalšího SPOKE směrovače (pobočky) třeba měnit konfiguraci a stačí pouze nakonfigurovat SPOKE směrovač na kterém je nastavena statická cesta k HUB směrovači. V případě, že vznikne požadavek na zabezpečenou komunikaci mezi HUB a SPOKE nebo SPOKE a SPOKE je díky DM-VPN a dalších autentizacích mechanismu a protokolu NHRP vytvořen dynamicky VPN tunel. Výhodou DM-VPN je, že bez změny konfigurace na HUB směrovači umožňuje snadno připojit další SPOKE směrovače a také usnadňuje konfiguraci, jelikož není nutné ručně konfigurovat mesh topologii. DM-VPN ke své činnosti využívá i jiné protokoly jako jsou: IPsec mgre Dynamické směrovací protokoly NHRP Více teoretického popisu bude zmíněno v praktickém zapojení, které bylo cílem této práce, a také bych odkázal na [1]. prosinec /29

3 2.2 Technologie MPLS Technologie MPLS (MultiProtocol Label Switching) se používá pro urychlení cesty paketů sítí na principu přepínání značek. Je založený na důsledném oddělení procesu směrování (routing) od vlastního předávání paketů (forwarding). MPLS kombinuje techniku virtuálních kanálů s funkcemi z protokolového modelu TCP/IP. Toho je možné dosáhnout, protože jedno zařízení, označované jako LSR (Label Switch Router), hraje současně roli klasického IP směrovače a přepínače virtuálních kanálů. MPLS dokáže spolupracovat nejen s protokoly TCP/IP, ale i s protokoly z jiných modelů (např. IPX/SPX), také používá směrovací protokoly k zjištění topologie sítě. Směrovač na okraji sítě s podporou MPLS se označuje jako LER (Label Edge Router). LER příchozímu paketu přidělí značku, která se pak dále používá pro jeho předávání mezi směrovači uvnitř MPLS sítě. LSR v síti pak mohou datagram předávat dál výhradně na základě svých individuálních jednoduchých tabulek se značkami, aniž by musely zkoumat své směrovací tabulky. Přepínací tabulky LSR směrovačů se vytvářejí pomocí signalizačního protokolu LDP (Label Distribution Protocol). Pomocí přepínacích tabulek LSR směrovačů LDP protokol vytváří virtuální cestu LSP (Label Switch Path). LSP je jednosměrný virtuální kanál. Pro přenos mezi dvěma LER směrovači je potřeba vytvořit alespoň dvě LSP, jednu pro každý směr. Jako u jiných technologií s virtuálními kanály má značka jen lokální význam. Když je paket přeposlán ze vstupního portu na výstupní, změní se hodnota jeho značky. Výstupní LER odebere značku a pošle IP paket do další sítě obvyklým způsobem. [3] [4] 3 Použitá zařízení pro testování Pro testování a ověření vzájemné spolupráce byly použity směrovače od firmy Cisco. Konkrétně typy Cisco 2801, Cisco 2811 a Cisco V tabulce č. 2 můžeme vidět souhrn použitých směrovačů a verze jejich systémů. Typ směrovače Verze systému IOS Cisco 2801 Cisco 2811 Cisco 2901 Verze 15.1(3)T4 Verze 15.1(3)T4 Verze 15.3(2)T Tabulka č. 1: Použitá zařízeni pro testování prosinec /29

4 4 Realizace dynamické VPN sítě Nyní se budeme věnovat realizaci (konfiguraci) dynamické VPN sítě nad níže navrženou topologií, která nám bude sloužit pro testování projektu, viz obrázek č. 1. Na topologii můžeme vidět prostřední část sítě, jedná se o veřejnou síť (například Internet). V celé této částí sítě je zprovozněn směrovací protokol BGP s autonomním systémem AS 200. Pomocí směrovacího protokolu BGP jsou propagovány všechny spoje (sítě) mezi směrovači v této části. Využili jsme zde konfigurace směrovačů R9 a R10 jako route reflector. Po konfiguraci jsme ověřili dostupnost v celé této síti. Mezi směrovači R9 a R10 jsme umístili hub a PC pro odchyt komunikace pomocí software Wireshark. Ve firemní sítí je zprovozněn proprietární Cisco směrovací protokol EIGRP. Nahoře v levé části je znázorněna centrální firemní síť, PE směrovač R2 je zde v roli HUB směrovače, od tohoto směrovače vedou dynamické tunely do vzdálených firemních poboček 1, 2 a 3. Směrovače R4, R5 a R7 jsou nakonfigurovány v roli SPOKE. Tyto vzdálené pobočky poté přes nakonfigurované tunely navážou EIGRP sousedství a následně mohou komunikovat s centrální firemní sítí, ale také vzájemně mezi sebou (přes HUB). Nakonec se dostáváme k závěru a požadavku tohoto projektu, v tunelech bude zapnuta technologie MPLS a tunely budou šifrovány pomoci vytvořeného IPSec profilu. Veškerá komunikace (EI- GRP zprávy, datový přenos, MPLS) mezi částmi firemní sítě pomocí DM-VPN bude tedy šifrována pomocí IPSec. Obrázek č. 1: Topologie sítě pro testování DM-VPN 4.1 Konfigurace V následující podkapitole je popsána základní konfigurace a postup pro zprovoznění naší DM-VPN sítě na navrhnuté topologii z obrázku č. 1. Veškeré konfigurace všech směrovačů a následně také kontrolní výpisy lze nalézt v přílohách na konci dokumentu, na které se bude v průběhu odkazovat. Pro zprovoznění počítáme se základní znalostí konfigurace Cisco směrovačů a znalostí směrovacích protokolů BGP a EIGRP. Pro zopakování zde ale uvádíme základní konfiguraci BGP a EIGRP, která byla použita v naší topologii. prosinec /29

5 Základní konfigurace rozhraní směrovačů a další zde nejsou uvedeny, veškeré příkazy všech směrovačů lze nalézt v příloze A. Nyní popíšeme konfiguraci směrovacích protokolů BGP a EIGRP. Konfigurace BGP a EIGRP Níže lze vidět příkazy pro konfiguraci směrovacího protokolu BGP na směrovači R2. Prvním příkazem se dostaneme do konfigurace BGP s AS 200, dále zde přidáme síť, kterou chceme propagovat a posledním příkazem udáváme, s kým navážeme vazbu (sousedství) pro výměnu informací. Další směrovače R4, R5 a R7 se konfigurují stejným způsobem s jinými adresami. R2(config)#router bgp 200 R2(config-router)#network mask R2(config-router)#neighbor remote-as 200 Následně je zde uvedena konfigurace BGP pro směrovač R9. V našem autonomním systému pro správnou funkci šíření informací by musela být vytvořena full mesh síť, neboli navázat vztah sousedství každý s každým. Využili jsme možnost konfigurace route reflektoru, tento směrovač propaguje záznamy naučené u ibgp (ale i z ebgp jako každý jiný ibgp router) do ostatních ibgp. Pomocí route reflektoru snižujeme množství sousedských vazeb v našem AS, vytváříme pouze vazby s route reflektorem. Konfiguraci takovéhoto route reflektoru můžeme vidět níže. Další směrovač je poté nakonfigurován klasicky, naváže vazbu na route reflektor. V naší topologii jsme konfigurovali dva route reflektory R9 a R10. Při testování v laboratoři jsme navazovali vazby na fyzická rozhraní, lepší řešení a také v praxi používané je navazovat sousedství pomocí loopback rozhraní. R9(config)#router bgp 200 R9(config-router)#network mask R9(config-router)#network mask R9(config-router)#network mask R9(config-router)#neighbor remote-as 200 R9(config-router)#neighbor route-reflector-client R9(config-router)#neighbor remote-as 200 R9(config-router)#neighbor route-reflector-client R9(config-router)#neighbor remote-as 200 R9(config-router)#neighbor route-reflector-client Níže je uvedena konfigurace směrovacího protokolu EIGRP s autonomním systémem 100, vidíme přidané konkrétní sítě, také je zde přidán náš vytvořený loopback. Ostatní směrovače se konfigurují podobným způsobem, nemůžeme také zapomenout na krajních směrovačích PE, například R2 přidat také síť (rozsah) pro náš vytvářený tunel. Dále nastavíme, že směrovač nemá provádět automatickou sumarizaci. U konfigurace EIGRP protokolu na SPOKE směrovačích můžeme zahrnout konfiguraci tzv. stub směrovače. Stub směrovač poté nebude zaměstnáván dotazy na cestu do neznámých sítí. Další konfigurace lze nalézt v příloze A. [2] R1(config)#router eigrp 100 R1(config-router)#network R1(config-router)#network R1(config-router)#no auto-summary Konfigurace IPSec Z důvodu zabezpečení VPN spojení bude na směrovačích HUB a SPOKE provedena konfigurace IPSec s využitím IKE. Pro vzájemnou autentizaci směrovačů v rámci IPSec bude využito předem sdíleného hesla. Konfigurace IPSec bude obsahovat ověření autentičnosti pomocí esp-sha-hmac a zabezpečení provozu pomocí šifrování aes. prosinec /29

6 Níže lze vidět konfiguraci IPSec. Při vytváření IPSec je nejdříve nutné definovat ISAKMP politiku, definovat tedy způsob autentizace a šifrování přenášených dat. Tato politika musí být stejná na obou koncích tunelu. Dále definujeme naše heslo (KEY), které je sdíleno všemi směrovači a použito k vzájemné autentizaci. Také je nutné uvést IP adresu konce tunelu nebo, povolit autentizaci s daným heslem vůči všem ostatním směrovačům (address ). Pro vytvoření IPSec tunelu je potřeba definovat druh zapouzdření, všechny údaje musí být opět stejné na obou stranách. Jedná se o příkaz transform-set. V rozšířené konfiguraci transform-set je také dobré nastavit mód činnosti na transportní, protože tunel mezi směrovači vytvoří GRE protokol a tunelovací mód IPSec protokolu by jen zbytečně přidával další IP záhlaví, nebude tedy docházet k opakované enkapsulaci. Příkaz pro tento mód je mode transport. Nakonec předposledním příkazem vytvoříme IPSec profil IPSEC_PROFILE, který potom použijeme v konfiguraci tunelu. R2(config)#crypto isakmp policy 1 R2(config-isakmp)#authentication pre-share R2(config-isakmp)#encryption aes R2(config-isakmp)#group 5 R2(config)#crypto isakmp key KLIC address R2(config)#crypto ipsec transform-set AES-SHA esp-aes esp-sha-hmac R2(config)#crypto ipsec profile IPSEC_PROFILE R2(ipsec-profile)#set transform-set AES-SHA Konfigurace multipoint GRE tunelu Při vytváření zabezpečeného VPN tunelu mezi lokalitami využijeme možnost konfigurace multipoint GRE tunelů. Oproti point-to-point tunelu se zde při konfiguraci uvádí pouze zdrojové rozhraní. Adresa pro cíl bude zprostředkována pomocí NHRP protokolu. Při konfiguraci tunelu konfigurujeme jakoby virtuální tunelovací rozhraní, které ponese vlastní IP adresu (konce virtuálního spojení). Dále zde zadáme typ použité enkapsulace (gre multipoint), způsob zabezpečení procházejícího provozu pomocí vytvořeného IPSec profilu a také tunnel key (ID key tunelu), který identifikuje kdo je součástí stejného multipoint GRE. Vhodné je také upravit hodnotu MTU (Maximum Transfer Unit) na 1400 B, aby se předešlo problémům s nežádoucí fragmentací rámců z důvodu jejich zvětšení po přidání nových záhlaví. Níže můžeme vidět minimální konfiguraci tunelu pro jeho funkčnost na směrovači R4, který je v roli SPOKE. R4(config)#interface tunnel 0 R4(config-if)#ip address R4(config-if)#tunnel key R4(config-if)#tunnel source serial 0/1/0 R4(config-if)#tunnel mode gre multipoint R4(config-if)#tunnel protection ipsec profile IPSEC_PROFILE R4(config-if)#ip nhrp network-id 99 R4(config-if)#ip nhrp nhs R4(config-if)#ip nhrp map R4(config-if)#ip nhrp map multicast Nyní si popíšeme konfiguraci NHRP protokolu. Protokol NHRP se bude využívat primárně k mapování VPN IP adres na IP adresy páteřní sítě. Konfigurace se trochu liší v závislosti na roli daného prvku v topologii. Na směrovači R4, tedy SPOKE směrovači konfigurace zajišťuje registraci reálné IP adresy odchozího rozhraní tunelu a IP adresy samotného tunnel rozhraní na HUB směrovač. Nastavíme zde tedy network-id, které má lokální význam pro odlišení různých NHRP procesů. Nakonfigurujeme IP adresu Next Hop Serveru. Dále využijeme dvou statických map mezi VPN a páteřní IP adresou. Nakonfigurování statických map nám umožní zasílat multicast provoz a také nám definuje mapování mezi VPN a IP adresou NHRP serveru. Ostatní SPOKE směrovače se konfigurují podobným způsobem, konfigurace v příloze A. [1] Konfigurace NHRP protokolu na směrovači, který je v roli HUB je trochu rozdílná. Nekonfiguruje se zde statické mapování a IP adresa Next Hop Serveru. Statické mapování (mapa) je zde nahrazeno dynamickým mapováním, které pomocí NHRP protokolu bude automaticky budováno. Dále musíme na směrovači R2 na jeho rozhraní tunelu provést konfiguraci pro vynucení vypnutí funkce split-horizon pro směrovací protokol prosinec /29

7 EIGRP (v případě OSPF by se příkaz nemusel používat). Důvod pro tento příkaz je jasný, stejným rozhraním, jímž bude směrovací informace od ostatních SPOKE směrovačů přijímaná, musí být také odeslána ostatním směrovačům. Tím je dokončena konfigurace tunelů na SPOKE směrovačích a HUB směrovači. Konfiguraci pro zapnutí MPLS technologii se věnuji v další kapitole. Při použití této konfigurace bude veškerá komunikace probíhat přes směrovač R2, komunikace hub-to-spoke. V naší topologii a návrhu nám tato komunikace (veškerá přes Hub směrovač) vyhovuje, neboť návrh je takový, že vzdálené firemní pobočky se připojují do centrální firemní sítě pro potřebné informace atd. Komunikace mezi vzdálenými pobočkami tedy není častá a bude probíhat přes HUB směrovač. R2(config)#interface tunnel 0 R2(config-if)#ip address R2(config-if)#ip nhrp network-id 99 R2(config-if)#tunnel key R2(config-if)#ip nhrp map multicast dynamic R2(config-if)#tunnel source fastethernet 0/1 R2(config-if)#tunnel mode gre multipoint R2(config-if)#no ip split-horizon eigrp 100 R2(config-if)#tunnel protection ipsec profile IPSEC_PROFILE V případě že bychom chtěli umožnit komunikaci přímo mezi SPOKE směrovači pomocí tunelů, kdy se této konfigurace v praxi také využívá. Musíme na HUB směrovači přidat následující příkaz do konfigurace tunelu, díky kterému zajistíme dynamické přímé tunely mezi SPOKE směrovači při použití EIGRP protokolu. Jak jsme se mohli dočíst v teoretické části, prvotní komunikace proběhne vždy přes HUB směrovač, který následně zajistí pomocí NHRP protokolu, přímou komunikaci mezi SPOKE směrovači. [1] R2(config-if)#no ip next-hop-self eigrp 100 Veškeré nastavené IP adresy virtuálních tunelů končí číslem aktuálního směrovače, tedy pro směrovač R2 to je pro R atd. Veškeré příkazy pro konfiguraci všech směrovačů lze nalézt v příloze A. Nyní se v další kapitole budeme věnovat ověření funkčnosti, popisu zachycené komunikace a výpisům ze směrovačů. 4.2 Ověření funkčnosti Pro ověření funkčnosti byla použita již zmiňovaná navrhnutá topologie. Funkčnost jsme ověřovali již během postupu konfigurace pomocí výpisů ze směrovačů a zachycené komunikace ze softwaru Wireshark. Na obrázku č. 2 lze vidět zachycenou komunikaci z rozbočovače mezi směrovači R9 a R10, jedná se o zasílané zprávy EIGRP pomocí vytvořených tunelů. V tomto kroku nebylo v konfiguraci DM-VPN ještě zapnuto (zabezpečení) šifrování pomocí IPSec profilu, abychom mohli odchytávat probíhající komunikaci. Na obrázku č. 2 lze tedy vidět zasílání hello zpráv EIGRP ze směrovačů. Všimněme si, že zdrojové IP adresy jsou VPN adresy konce tunelů (IP adresy konců virtuálního spojení). prosinec /29

8 Obrázek č.2: Zachycená komunikace z Wireshark Při správném nakonfigurování a zprovoznění DM-VPN jsme mohli na směrovačích ihned jako první věc vidět zprávy o navázání právě nových EIGRP vazeb s odlehlými firemními sítěmi (sousedy) přes vytvořené tunely. Níže můžeme vidět ze směrovače R2 (HUB) výpis příkazu show ip eigrp neighbors. Lze vidět, že navázané vazby se sousedy R4, R5 a R7 proběhly přes vytvořené rozhraní tunel 0. R2#show ip eigrp neighbors EIGRP-IPv4 Neighbors for AS(100) H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num Tu :19: Tu :23: Tu :24: Fa0/ :10: V dalším kroku si dostupnost připojení odlehlých firemních poboček pomocí DM-VPN můžeme otestovat pomocí pingu na loopbacky v těchto sítích. Dále si zobrazíme pomocí příkazu show ip route směrovací tabulku se záznamy, kterou lze vidět níže. Jedná se o zkrácený výpis směrovací tabulky, kompletní výpis lze nalézt v příloze B včetně výpisů z ostatních směrovačů. Ve směrovací tabulce lze vidět, že sítě odlehlých firemních poboček včetně loopback rozhraní dorazili a směrovač R2 tedy nemá problém navázat komunikaci do těchto sítí. R2#show ip route /24 is variably subnetted, 2 subnets, 2 masks C /24 is directly connected, Tunnel0 L /32 is directly connected, Tunnel /32 is subnetted, 1 subnets D [90/156160] via , 01:44:47, FastEth0/ /32 is subnetted, 1 subnets D [90/ ] via , 00:18:49, Tunnel /32 is subnetted, 1 subnets D [90/ ] via , 00:23:54, Tunnel /32 is subnetted, 1 subnets D [90/ ] via , 00:22:18, Tunnel /24 is variably subnetted, 2 subnets, 2 masks C /24 is directly connected, FastEthernet0/0 L /32 is directly connected, FastEthernet0/0 D /24 [90/ ] via , 00:18:48, Tunnel0 D /24 [90/ ] via , 00:23:54, Tunnel0 D /24 [90/ ] via , 00:22:18, Tunnel0 Nyní se podíváme na výpis o informacích DM-VPN pomocí příkazu show dmvpn. Můžeme zde vidět použité rozhraní tunel 0, že se jedná o směrovač typu HUB a celkový počet NHRP sousedů (peers). U každého souseda lze vidět status UP, který značí, že je vazba (tunel) aktivní a také čas jak dlouho. Dále je zde uveden atribut D (dynamic), což znamená, že se jedná o dynamické spojení. Také jsou zde samozřejmě vidět IP adresy neboli VPN adresy konce tunelů a také IP adresy NBMA. Pro detailnější výpis lze použít příkaz show dmvpn detail, kde ve výpisu můžeme například vidět typ zabezpečení (ipsec profil), použitý protokol pro tunel (mgre) a další. Tyto výpisy i z dalších směrovačů lze nalézt v příloze B. R2#show dmvpn Interface: Tunnel0, IPv4 NHRP Details Type:Hub, NHRP Peers:3, # Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb UP 00:54:07 D prosinec /29

9 UP 00:53:48 D UP 00:54:17 D Další z užitečných příkazů je show ip nhrp. Na tomto výpisu můžeme vidět NHRP informace od navázaných vztahů (tunelů) přes rozhraní tunel 0. Lze zde vidět, kdy bylo spojení vytvořeno, kdy vyprší a důležitou informací kterou je zde vidět je vazba (mapování pomocí NHRP) mezi IP adresami konci tunelů a NBMA adresami, například IP adresa na směrovači R4, je k dosažení pod fyzickou adresou Dále také typ spojení, v tomto případě se jedná o dynamické navázání. U směrovačů typu SPOKE bude tento atribut statické (static), taktéž v minulém výpisu by bylo místo atributu D (dynamic) označení S (static). R2#show ip nhrp /32 via Tunnel0 created 00:52:49, expire 01:45:20 Type: dynamic, Flags: unique registered NBMA address: /32 via Tunnel0 created 00:52:30, expire 01:43:54 Type: dynamic, Flags: unique registered NBMA address: /32 via Tunnel0 created 00:52:59, expire 01:45:02 Type: dynamic, Flags: unique registered NBMA address: Další výpisy ze všech směrovačů lze nalézt v příloze B, kde se nachází například výpisy pro IPSec a další. Nyní se budeme věnovat v naší topologii zprovoznění technologie MPLS. 5 Zavedení MPLS Po nakonfigurování a ověření funkčnosti DM-VPN jsme se pustili do dalšího cíle projektu. Samotný MPLS provoz není šifrovaný, úkolem je tedy tento provoz šifrovat a to realizací právě nad DM-VPN. MPLS provoz bude tedy zabezpečen (šifrován) pomocí našeho vytvořeného IPSec profilu, který jsme popsali v podkapitole 4.1. Tento IPSec profil nám zabezpečí tunely vytvořené v rámci DM-VPN. MPLS poté zprovozníme a zapneme na rozhraní tunelů směrovače HUB a všech směrovačů SPOKE. MPLS provoz tedy poběží v těchto tunelech. 5.1 Konfigurace Co se týče konfigurace, jedná se pouze o to, abychom na rozhraní tunelu zapnuli MPLS technologii příkazem mpls ip. Toto provedeme na všech SPOKE směrovačích a HUB směrovači. Ostatní konfigurace pro MPLS jsme neprováděli a vše nechali defaultně nastavené. R2(config)#interface tunnel 0 R2(config-if)#mpls ip 5.2 Ověření funkčnosti Po zapnutí technologie MPLS na rozhraní tunelů všech směrovačů, můžeme ověřit pomocí výpisů a zachycené komunikace funkčnost. Jako první se podíváme na výpis pomocí příkazu show mpls ldp neighbor. Pomocí toho výpisu můžeme vidět, zda byla navázána nějaká ldp vazba se sousedem. Níže na další stránce můžeme vidět tento výpis ze směrovače R7. Na výpisu lze vidět LDP identitu souseda, v tomto případě (směrovač R2 HUB). Naší lokální identitu, která je , dále také čas jak dlouho je spojení aktivní, zdrojové rozhraní a identifikaci přes které byl LDP soused nalezen a také jaké IP adresy jsou vázané na tohoto souseda. Výpis ze směrovače R2 HUB by obsahoval sousedy tři (všechny SPOKE směrovače). prosinec /29

10 R7#show mpls ldp neighbor Peer LDP Ident: :0; Local LDP Ident :0 TCP connection: State: Oper; Msgs sent/rcvd: 18/18; Downstream Up time: 00:04:40 LDP discovery sources: Tunnel0, Src IP addr: Addresses bound to peer LDP Ident: Nyní se můžeme podívat na výpis příkazu show mpls forwarding-table, díky kterému vidíme směrovací tabulku pro MPLS, která se používá pro směrování dle značek (label). Níže lze tedy vidět značky (labely) pro všechny dostupné sítě, jak lokální značky, tak odchozí značky těchto sítí. Vidíme zde také odchozí rozhraní což je tunel 0 a next hop, který je v tomto případě směrovač R2 s virtuální IP adresou konce tunelu R7#show mpls forwarding-table Local Outgoing Prefix Bytes Label Outgoing Next Hop Label Label or Tunnel Id Switched interface /32 0 Tu /32 0 Tu No Label / Fa0/ Pop Label /24 0 Tu /24 0 Tu /24 0 Tu /32 0 Tu Nyní se podíváme na zachycenou komunikaci, když probíhal ping ze směrovače R8 na směrovač R1. Níže na obrázku č. 3 můžeme vidět požadavek a odpověď protokolu ICMP. Vidíme zde zdrojovou IP adresu ze směrovače R8 a cílovou adresu směrovače R1. Obrázek č. 3: Zachycený ping z R8 na R1 Níže na obrázku č. 4 vidíme obsah zachycené zprávy ICMP požadavku ze směrovače R8. Vidíme, že MPLS technologie je aktivní a došlo k označení zprávy. Můžeme vidět zachycenou značku s číslem 16. V případě porovnání s výpisem show mpls forwarding-table ze směrovače R7, můžeme vidět, že pro dosažení adresy na kterou byl proveden ping, odpovídá značka 16. Značka z výpisu a zachycené komunikace se shoduje. Obrázek č. 4: Zachycený obsah zprávy (požadavek) prosinec /29

11 Na obrázku č. 5 vidíme obsah zachycené odpovědi ICMP ze směrovače R1. Vidíme, že zde již žádná MPLS značka není definována. Je to způsobeno tím, že směrovač R7 vyslal požadavek na odstranění značky (implicit-null) a směrovač R2 již značku odstranil. Kdyby značka nebyla odstraněna měla by hodnotu 18, kterou můžeme dle výpisu show mpls forwarding-table na směrovači R2 zjistit. Odchozí značku pro tuto adresu má R2 jako značku 18. Více ve výpisech v příloze C. Obrázek č. 5: Zachycený obsah zprávy (odpověď) Jako další ukázku funkčnosti MPLS lze zmínit ping ze směrovače R8 na směrovač R6, která názorně ukazuje komunikaci a označkování pomocí MPLS. Komunikace tedy probíhá mezi dvěma vzdálenými pobočkami. Ovšem komunikace vždy proběhne mezi těmito sítěmi (SPOKE) přes směrovač R2 v roli HUB (viz kapitole konfigurace DM-VPN). Na obrázku č. 6 lze vidět zdrojové a cílové IP adresy při průběhu tohoto pingu. Požadavek musel jít nejprve na směrovač R2, z toho směrovače požadavek na směrovač R6 a odpověď zpět stejným způsobem. V dalších krocích je rozebrána jednotlivá zpráva z obrázku č. 6 samostatně. Obrázek č. 6: Zachycený ping z R8 na R6 Na obrázku č. 7 lze vidět zdrojovou IP adresu směrovače R7 a jako cílovou IP adresu směrovače R , co se týká fyzických IP adres v NBMA síti. Značka byla přiřazena s hodnotou 17, která odpovídá adrese a lze ji také vidět ve výpisu ze směrovače R7 na předchozí straně. Obrázek č. 7: Zpráva požadavek na R2 Níže na obrázku č. 8 můžeme vidět zprávu ze směrovače R2 na R7 ( ). Značka je zde opět s hodnotou 17, neboť směrovač R2 má pro adresu takto značku přiřazenu. V příloze C se lze podívat na výpis show mpls forwarding-table přiřazených značek prosinec /29

12 Obrázek č. 8: Zpráva- požadavek na R6 Ze směrovače R5 na směrovač R2 se vrací odpověď se značkou 20, kterou má směrovač R5 pro síť přidělenu. Vše lze vidět níže na obrázku č. 9. V příloze C se lze podívat na výpis show mpls forwarding-table na příslušných směrovacích. Obrázek č. 9: Zpráva- odpověď na R2 Na obrázku č. 10 lze vidět již odpověď ze směrovače R2 na směrovač R7. Zde již není přiřazena MPLS značka. Směrovač totiž zaslal požadavek (implicit-null) na R2, aby již značku ze záhlaví odstranil. Obrázek č. 10: Zpráva- odpověď na R7 To byla konfigurace a ověření funkčnosti technologie MPLS. Při sledování a zachytávání provozu nebylo zabezpečení (šifrování) pomocí IPSec profilu zapnuto. Na obrázku č. 11 lze vidět již šifrovanou komunikaci, při použitém zabezpečení na tunelech pomocí vytvořeného IPSec profilu. Jsou zde vidět pouze zdrojové a cílové adresy uvnitř NBMA sítě neboli koncové fyzické adresy směrovačů ve veřejné síti. A nakonec také ESP protokol, nevidíme, o jaké typy zpráv se jedná (procházející data, zprávy směrovacích protokolu atd.) pouze zmíněné IP adresy. Obrázek č. 11: Zachycená šifrovaná komunikace Důležité je ještě připomenout, již zmíněnou věc během konfigurace DM-VPN. A to že veškerá komunikace probíhá přes směrovač R2 v roli HUB směrovače. Jak již bylo popsáno, tato konfigurace nám vyhovuje, neboť vzdálené pobočky se připojují do centrální firemní sítě pomocí DM-VPN. V této konfiguraci bylo vše funkční včetně správné funkce technologie MPLS. Pokud jsme změnili konfiguraci tak, že vzdálené pobočky (SPOKE) mohli komunikovat přímo mezi sebou (prvotní komunikace je navázána přes R2 HUB). Tak se v tomto případě při přímé komunikaci mezi SPOKE technologie MPLS nevyužila a směrovalo se pomocí IP. Důvodem je to že tyto nově vytvořené dynamické tunely mezi SPOKE nemají v sobě nakonfigurováno MPLS a ani se nenaváže žádná ldp sousedská vazba. Technologie MPLS je zapnuta na tunelech při konfiguraci, kdy probíhá veškerá komunikace přes směrovač v roli HUB. prosinec /29

13 6 Návrh řešení na platformě IOS-XR V následující kapitole je teoretický popsána ukázka řešení na platformě IOS-XR. Je zde popsán postup konfigurace rozhraní, BGP a EIGRP směrovacích protokolů. Mezi platformou IOS a IOS-XR jsou v některých konfiguracích jisté rozdíly, ovšem jsou zde i totožné příkazy. Asi základní rozdíl je zde v potvrzení změněné konfigurace pomocí příkazu commit (tento příkaz není v postupu konfigurací zmiňován). Níže lze vidět základní konfiguraci IP adresy na rozhraní. R1(config)#interface fastethernet0/0 R1(config-if)#ipv4 address R1(config-if)# Konfigurace EIGRP a BGP Následně lze vidět základní konfiguraci směrovacího protokolu EIGRP. Kdy si vytvoříme eigrp 100. posledním příkazem přiřadíme rozhraní do EIGRP instance neboli na jakém rozhraní bude EIGRP aktivní. R1(config)#router eigrp 100 R1(confi-eigrp)#adress-family ipv4 R1(config-eigrp-af)#interface fastethernet0/0 Následně lze vidět základní konfiguraci směrovacího protokolu EIGRP. Kdy si vytvoříme eigrp 100. posledním příkazem přiřadíme rozhraní do eigrp instance neboli na jakém rozhraní bude EIGRP aktivní. R1(config)#router eigrp 100 R1(confi-eigrp)#adress-family ipv4 R1(config-eigrp-af)#interface fastethernet0/0 Způsob konfigurace protokolu BGP na Cisco IOS-XR se trochu odlišuje od konfigurace na IOS. Níže je uvedena ukázka konfigurace BGP protokolu v roli route reflector. Jedná se o konfiguraci s jedním sousedem, v případě více sousedů pouze opakujeme postup od řádku dva. R10(config)# router bgp 200 R10(config-bgp)# neighbor R10(config-bgp-nbr)# remote-as 200 R10(config-bgp-nbr)# address-family ipv4 unicast R10(config-bgp-nbr-af)# network /24 R10(config-bgp-nbr-af)# route-reflector-client V případě, že nechceme, aby směrovač vystupoval v roli route reflector pouze vynecháme patřičný (poslední) řádek z konfigurace. Níže lze vidět způsob této konfigurace. R7(config)# router bgp 200 R7(config-bgp)# neighbor R7(config-bgp-nbr)# remote-as 200 R7(config-bgp-nbr)# address-family ipv4 unicast R7(config-bgp-nbr-af)# network /24 Výše popsané konfigurace se analogicky aplikují na ostatní směrovače dle potřeby. Více o konfiguraci na jednotlivé směrovače dle původního postupu v projektu se zaměněním těchto konfiguračních příkazů. [5] [6] [7] prosinec /29

14 Konfigurace IPSec Konfigurace IPSec politiky je oproti IOS platformě již rozdílná více. Konfigurace je více členěna do konfiguračních úrovní (podmenu). Jako první je potřeba povolit isakmp v konfiguračním režimu. R2(config)# crypto isakmp R2(config)# commit Následně vytvoříme crypto isakmp politiku, s požadovanými parametry. R2(config)# crypto isakmp policy 1 R2(config-isakmp)# description PSK_SHA_AES R2(config-isakmp)# authentication pre-share R2(config-isakmp)# hash sha R2(config-isakmp)# group 5 R2(config-isakmp)# encryption aes Dále definujeme naše heslo (KEY), které je sdíleno všemi směrovači a použito k vzájemné autentizaci. Také je nutné uvést IP adresu konce tunelu nebo, povolit autentizaci s daným heslem vůči všem ostatním směrovačům (address ). R2(config)# crypto keyring KEY vrf default R2(config-keyring)# pre-shared-key address key KLIC R2(config-keyring)# commit Nakonec vytvoříme IPSec profil IPSEC PROFILE, který se použije při konfiguraci zabezpečení tunelu. V konfiguraci IPSec profilu provedeme provázání s transform-set. R2(config)# crypto ipsec transform-set AES-SHA R2(config-transform-set AES-SHA)# transform esp-aes esp-sha-hmac R2(config)# crypto ipsec profile IPSECPROFILE R2(config-IPSECPROFILE)# set transform-set AES-SHA Konfigurace multipoint GRE tunelu Konfigurace DM-VPN při které je využito multipoint GRE (mgre) tunelu a protokolu NHRP jako na platformě IOS, se zde na IOS-XR nenachází. Ve veškeré dokumentaci Cisco na platformu IOS-XR není žádná konfigurace v této podobě a je zmiňovaná pouze konfigurace GRE tunelu point-to-point. Dokumentace s konfiguračními příkazy zde [7] [8] [9]. Níže lze vidět konfiguraci GRE tunelu point-to-point. R2(config)# interface tunnel-ip 10 R2(config-if)# ipv4 address R2(config-if)# tunnel source fastethernet 0/1 R2(config-if)# tunnel destination R2(config-if)# profile IPSECPROFILE prosinec /29

15 7 Závěr Cílem projektu bylo zprovoznit DM-VPN na směrovačích nad navrhnutou topologií sítě a do této topologie také začlenit a šifrovat pomocí DM-VPN provoz MPLS. Ověření vzájemné funkčnosti jsme provedli v laboratoři pomocí směrovačů Cisco 2801, 2811 a Veškerá konfigurace a odchycená komunikace je podrobně pospána v průběhu projektu. Již z úvodu vyplývá, že výhodou DM-VPN je jednoduší přidání vzdálené pobočky (SPOKE směrovače) bez nutnosti zásahu do konfigurace na HUB směrovači a tunely se poté vytvoří dynamicky. Během testování byla zjištěna správná funkčnost projektu - navázaní DM-VPN, spojení poboček přes tyto tunely a zapnutí technologie MPLS, pouze na konci kapitoly 5 je popsán poznatek (problém) při přímé komunikaci spoke-to-spoke, při kterém není zapnuta (funkční) technologie MPLS. Tato veškerá probíhající komunikace byla následně úspěšně šifrována pomocí IPSec. Podrobný popis konfigurace a testování je popsán v kapitolách 4 a 5. prosinec /29

16 8 Použitá literatura [1]CISCO SYSTEMS, INC. Dynamic Multipoint VPN. Dynamic Multipoint VPN Configuration Guide, Cisco IOS XE Release 3S (ASR 1000) [online] [cit ]. Dostupné z: conn-dmvpn-xe-3s-asr1000-book/sec-conn-dmvpn-dmvpn.html#guid-b543b933-18ce-44fb-9c53- D5D3C0BBC195 [2]BENJAMIN, Henry. CCNP Practical Studies: Routing: Configuring Route Reflectors. INFORMIT. Informit: CCNP Practical Studies: Routing [online]. [cit ]. Dostupné z: [3] CISCO SYSTEMS, INC. Multiprotocol Label Switching (MPLS). [online]. [cit ]. Dostupné z: [4] WIKIPEDIA. Multiprotocol Label Switching. [online]. [cit ]. Dostupné z: [5] CISCO SYSTEMS, INC. Implementing IPSec Network Security. [online]. [cit ]. Dostupné z: [6] FRY, Jeffrey. CISCO IOS XR. [online]. [cit ]. Dostupné z: [7] CISCO SYSTEMS, INC. Configuration Guides. [online]. [cit ]. Dostupné z: [8] CISCO SYSTEMS, INC. Implementing Generic Routing Encapsulation. [online]. [cit ]. Dostupné z: [9] CISCO SYSTEMS, INC. Cisco IOS XR Virtual Private Network Configuration Guide for the Cisco CRS Router, Release 5.2.x. [online]. [cit ]. Dostupné z: prosinec /29

17 9 Přílohy Příloha A: Konfigurace jednotlivých směrovačů IPSEC: crypto isakmp policy 1 authentication pre-share encryption aes group 5 crypto isakmp key KLIC address crypto ipsec transform-set AES-SHA esp-aes esp-sha-hmac crypto ipsec profile IPSEC_PROFILE set transform-set AES-SHA R2 (HUB): line console 0 logging synchronous exit hostname R2 interface fastethernet 0/0 ip address interface fastethernet 0/1 ip address interface tunnel 0 ip address ip nhrp network-id 99 tunnel key ip nhrp map multicast dynamic tunnel source fastethernet 0/1 tunnel mode gre multipoint no ip split-horizon eigrp 100 no ip next-hop-self eigrp 100 tunnel protection ipsec profile IPSEC_PROFILE router eigrp 100 network network no auto-summary router bgp 200 network mask neighbor remote-as 200 prosinec /29

18 SPOKE: R4: line console 0 logging synchronous exit hostname R4 interface fastethernet 0/0 ip address interface serial 0/1/0 ip address clock rate interface tunnel 0 ip address ip nhrp network-id 99 tunnel key ip nhrp nhs ip nhrp map ip nhrp map multicast tunnel source serial 0/1/0 tunnel mode gre multipoint tunnel protection ipsec profile IPSEC_PROFILE router eigrp 100 network network no auto-summary router bgp 200 network mask neighbor remote-as 200 R5: line console 0 logging synchronous exit hostname R5 interface GigabitEthernet 0/0 ip address interface GigabitEthernet 0/1 ip address interface tunnel 0 ip address ip nhrp network-id 99 tunnel key ip nhrp nhs ip nhrp map ip nhrp map multicast tunnel source fastethernet 0/1 tunnel mode gre multipoint tunnel protection ipsec profile IPSEC_PROFILE prosinec /29

19 router eigrp 100 network network no auto-summary router bgp 200 network mask neighbor remote-as 200 R7: line console 0 logging synchronous exit hostname R7 interface fastethernet 0/0 ip address interface serial 0/1/0 ip address clock rate interface tunnel 0 ip address ip nhrp network-id 99 tunnel key ip nhrp nhs ip nhrp map ip nhrp map multicast tunnel source serial 0/1/0 tunnel mode gre multipoint tunnel protection ipsec profile IPSEC_PROFILE router eigrp 100 network network no auto-summary router bgp 200 network mask neighbor remote-as 200 CE: R1: line console 0 logging synchronous exit hostname R1 interface fastethernet 0/0 ip address interface loopback 0 ip address router eigrp 100 prosinec /29

20 network network no auto-summary R3: line console 0 logging synchronous exit hostname R3 interface fastethernet 0/0 ip address interface loopback 0 ip address router eigrp 100 network network no auto-summary R6: line console 0 logging synchronous exit hostname R6 interface GigabitEthernet 0/0 ip address interface loopback 0 ip address router eigrp 100 network network no auto-summary R8: line console 0 logging synchronous exit hostname R8 interface fastethernet 0/0 ip address interface loopback 0 ip address router eigrp 100 network network no auto-summary prosinec /29

21 R9(Reflector): line console 0 logging synchronous exit hostname R9 interface fastethernet 0/0 ip address interface fastethernet 0/1 ip address interface serial 0/1/0 ip address clock rate router bgp 200 network mask network mask network mask neighbor remote-as 200 neighbor route-reflector-client neighbor remote-as 200 neighbor route-reflector-client neighbor remote-as 200 neighbor route-reflector-client R10(reflector): line console 0 logging synchronous exit hostname R10 interface GigabitEthernet 0/0 ip address interface GigabitEthernet 0/1 ip address interface serial 0/1/0 ip address clock rate router bgp 200 network mask network mask network mask neighbor remote-as 200 neighbor route-reflector-client neighbor remote-as 200 neighbor route-reflector-client neighbor remote-as 200 neighbor route-reflector-client prosinec /29

22 Příloha B: Kontrolní výpisy ze směrovačů R2#sh ip route /24 is variably subnetted, 2 subnets, 2 masks C /24 is directly connected, Tunnel0 L /32 is directly connected, Tunnel /32 is subnetted, 1 subnets D [90/156160] via , 01:44:47, FastEth0/ /32 is subnetted, 1 subnets D [90/ ] via , 00:18:49, Tunnel /32 is subnetted, 1 subnets D [90/ ] via , 00:23:54, Tunnel /32 is subnetted, 1 subnets D [90/ ] via , 00:22:18, Tunnel /24 is variably subnetted, 2 subnets, 2 masks C /24 is directly connected, FastEthernet0/0 L /32 is directly connected, FastEthernet0/0 D /24 [90/ ] via , 00:18:48, Tunnel0 D /24 [90/ ] via , 00:23:54, Tunnel0 D /24 [90/ ] via , 00:22:18, Tunnel /24 is variably subnetted, 2 subnets, 2 masks C /24 is directly connected, FastEthernet0/1 L /32 is directly connected, FastEthernet0/1 B /24 [200/0] via , 01:42:59 B /24 [200/0] via , 01:05:39 B /24 [200/0] via , 01:05:39 B /24 [200/0] via , 01:41:20 R2#sh crypto isakmp sa IPv4 Crypto ISAKMP SA dst src state conn-id status QM_IDLE 1001 ACTIVE QM_IDLE 1002 ACTIVE QM_IDLE 1003 ACTIVE R2#show dmvpn detail Legend: Attrb --> S - Static, D - Dynamic, I - Incomplete N - NATed, L - Local, X - No Socket # Ent --> Number of NHRP entries with same NBMA peer NHS Status:E->Expecting Replies,R--> Responding, W --> Waiting UpDn Time --> Up or Down Time for a Tunnel ======================================================================== Interface Tunnel0 is up/up, Addr. is , VRF "" Tunnel Src./Dest. addr: /MGRE, Tunnel VRF "" Protocol/Transport: "multi-gre/ip", Protect "IPSEC_PROFILE" Interface State Control: Disabled Type:Hub, Total NBMA Peers (v4/v6): 3 # Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb Target Network UP 00:54:20 D / UP 00:54:01 D / UP 00:54:29 D /32 prosinec /29

23 R3#sh ip route D /24 [90/ ] via , 00:13:31, GigabitEth0/ /32 is subnetted, 1 subnets D [90/ ] via , 00:13:30, GigabitEth0/ /32 is subnetted, 1 subnets C is directly connected, Loopback /32 is subnetted, 1 subnets D [90/ ] via , 00:13:30, GigabitEth0/ /32 is subnetted, 1 subnets D [90/ ] via , 00:13:30, GigabitEth0/0 D /24 [90/ ] via , 00:13:30, GigabitEth0/ /24 is variably subnetted, 2 subnets, 2 masks C /24 is directly connected, GigabitEthernet0/0 L /32 is directly connected, GigabitEthernet0/0 D /24 [90/ ] via , 00:13:30, GigabitEth0/0 D /24 [90/ ] via , 00:13:30, GigabitEth0/0 R3#sh ip eigrp neighbors EIGRP-IPv4 Neighbors for AS(100) H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num Gi0/ :14: R4#sh ip route /24 is variably subnetted, 2 subnets, 2 masks C /24 is directly connected, Tunnel0 L /32 is directly connected, Tunnel /32 is subnetted, 1 subnets D [90/ ] via , 00:18:21, Tunnel /32 is subnetted, 1 subnets D [90/130816] via , 00:18:21, GigabitEthernet0/ /32 is subnetted, 1 subnets D [90/ ] via , 00:18:21, Tunnel /32 is subnetted, 1 subnets D [90/ ] via , 00:18:21, Tunnel0 D /24 [90/ ] via , 00:18:21, Tunnel /24 is variably subnetted, 2 subnets, 2 masks C /24 is directly connected, GigabitEthernet0/0 L /32 is directly connected, GigabitEthernet0/0 D /24 [90/ ] via , 00:18:21, Tunnel0 D /24 [90/ ] via , 00:18:21, Tunnel0 B /24 [200/0] via , 01:43: /24 is variably subnetted, 2 subnets, 2 masks C /24 is directly connected, Serial0/1/0 L /32 is directly connected, Serial0/1/0 B /24 [200/0] via , 01:05:10 B /24 [200/0] via , 01:05:10 B /24 [200/0] via , 01:40:51 prosinec /29

24 R4#show ip eigrp neighbors EIGRP-IPv4 Neighbors for AS(100) H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num Gi0/ :18: Tu :18: R4#show ip nhrp /32 via Tunnel0 created 00:54:40, never expire Type: static, Flags: used NBMA address: R4#show crypto isakmp sa IPv4 Crypto ISAKMP SA dst src state conn-id status QM_IDLE 1001 ACTIVE R4#show dmvpn detail Interface Tunnel0 is up/up, Addr. is , VRF "" Tunnel Src./Dest. addr: /MGRE, Tunnel VRF "" Protocol/Transport: "multi-gre/ip", Protect "IPSEC_PROFILE" Interface State Control: Disabled nhrp event-publisher : Disabled IPv4 NHS: RE priority = 0 cluster = 0 Type:Spoke, Total NBMA Peers (v4/v6): 2 # Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb Target Network UP 00:54:33 S /32 R5#sh ip route /24 is variably subnetted, 2 subnets, 2 masks C /24 is directly connected, Tunnel0 L /32 is directly connected, Tunnel /32 is subnetted, 1 subnets D [90/ ] via , 00:27:54, Tunnel /32 is subnetted, 1 subnets D [90/ ] via , 00:22:48, Tunnel /32 is subnetted, 1 subnets D [90/156160] via , 00:27:53, FastEth0/ /32 is subnetted, 1 subnets D [90/ ] via , 00:26:17, Tunnel0 D /24 [90/ ] via , 00:27:54, Tunnel0 D /24 [90/ ] via , 00:22:47, Tunnel /24 is variably subnetted, 2 subnets, 2 masks C /24 is directly connected, FastEthernet0/0 L /32 is directly connected, FastEthernet0/0 D /24 [90/ ] via , 00:26:17, Tunnel0 B /24 [200/0] via , 01:09:33 B /24 [200/0] via , 01:09: /24 is variably subnetted, 2 subnets, 2 masks C /24 is directly connected, FastEthernet0/1 L /32 is directly connected, FastEthernet0/1 B /24 [200/0] via , 01:09:38 B /24 [200/0] via , 01:09:38 prosinec /29

25 R5#sh ip eigrp neighbors EIGRP-IPv4 Neighbors for AS(100) H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num Tu :28: Fa0/ :42: R5#sh ip nhrp /32 via Tunnel0 created 01:00:50, never expire Type: static, Flags: used NBMA address: R5#show crypto isakmp sa IPv4 Crypto ISAKMP SA dst src state conn-id status QM_IDLE 1001 ACTIVE R5#show dmvpn detail Interface Tunnel0 is up/up, Addr. is , VRF "" Tunnel Src./Dest. addr: /MGRE, Tunnel VRF "" Protocol/Transport: "multi-gre/ip", Protect "IPSEC_PROFILE" Interface State Control: Disabled IPv4 NHS: RE priority = 0 cluster = 0 Type:Spoke, Total NBMA Peers (v4/v6): 1 # Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb Target Network UP 00:59:13 S /32 R6#sh ip eigrp neighbors EIGRP-IPv4 Neighbors for AS(100) H Address Interface Hold Uptime SRTT RTO Q Seq (sec) (ms) Cnt Num Fa0/ :52: R6#sh ip route D /24 [90/ ] via , 00:39:26, FastEth0/ /32 is subnetted, 1 subnets D [90/ ] via , 00:39:26, FastEth0/ /32 is subnetted, 1 subnets D [90/ ] via , 00:34:21, FastEth0/ /32 is subnetted, 1 subnets C is directly connected, Loopback /32 is subnetted, 1 subnets D [90/ ] via , 00:37:49, FastEth0/0 D /24 [90/ ] via , 00:39:26, FastEthernet0/0 D /24 [90/ ] via , 00:34:20, FastEthernet0/ /24 is variably subnetted, 2 subnets, 2 masks C /24 is directly connected, FastEthernet0/0 L /32 is directly connected, FastEthernet0/0 D /24 [90/ ] via , 00:37:49, FastEthernet0/0 prosinec /29