Technologie počítačových sítí - Případová studie. Zadání a popis požadavků

Transkript

1 Technologie počítačových sítí - Případová studie Zadání a popis požadavků Petr Grygárek Úvod Případová studie je rozdělena na několik částí, které společně tvoří ucelenou síťovou konfiguraci. Každá část je zaměřena na praktické procvičení jedné z technologií určité probírané technologické oblasti: Konfigurace je rozdělena těchto částí: Konfigurace MPLS/LDP mraků WANCore a SPCore Konfigurace podnikové pobočky se dvěma oddělenými VRFs, CE-PE směrování v každé z VRF (implementace dvou poboček) L3 MPLS/VPN v mraku WANCore Záložní konektivita přes SPCore mezi pobočkami, resp. internetová konektivita pomocí tunelové technologie. Záložní konektivita je realizována jinak pro každou z VRF pomocí některé z níže uvedených technologií, konkrétní zadání přidělí cvičící: Záložní konektivita VRF A přes AToM pseudowire Záložní konektivita VRF A přes AToM pseudowire ukončený v separátní lokální VRF Záložní konektivita a internetová konektivita VRF A s využitím mechanismu BGP-free core, resp. 6PE přes SPCore o Záložní a internetová konektivita VRF B přes IPSec a GRE tunely o Záložní a internetová konektivita VRF B přes DMVPN (phase 2 nebo 3) o Záložní a internetová konektivita VRF B přes mechanismus 6to4 (pouze IPv6) o Záložní a internetová konektivita VRF B přes mechanismus ISATAP (pouze IPv6) Náčrtky topologií a schémat pro případovou studii najdete v jednotlivých záložkách (stránkách) souboru TPS-CaseStudy-1617L-v2.pdf (dále odkazovány jen názvy záložek, resp. stran). IPv4 i IPv6 adresaci serverových segmentů a spojovacích linek zvolte sami z privátního nebo veřejného adresního rozsahu. Hodnoty 802.1q VLAN tags označené na obrázcích symbolickými písmeny zvolte rovněž sami. Klaďte důraz na systematičnost a rozšiřitelnost sítě. Logiku a zvolené hodnoty zdokumentujte v obrázcích topologií, které budete odevzdávat.

2 Požadavky na jednotlivé části řešení jsou specifikovány v náčrtech topologií ve zvláštní souboru a dále upřesněny níže v sekci Informace a doporučení k jednotlivým částem řešení. Konfigurace případové studie je realizována na emulátoru Cisco Virl. Přístup k prostředí Virtlu a práce s ním jsou popsány na webových stránkách (Wiki) předmětu. Soubor s definicí síťové topologie případové studie pro Virl je rovněž k dispozici tamtéž. Rozvrhnutí časových oken pro práci na Virlu a přihlašovací údaje sdělí cvičící. Studenti denního studia pracují ve dvojicích a realizují celou konfiguraci současně pro protokoly IPv4 i IPv6 (s výjimkou technologií 6to4 a ISATAP specifických pouze pro IPv6). Studenti kombinovaného studia pracují individuálně a konfigurují vše buďto jen pro IPv4 nebo jen pro IPv6 dle jim přiděleného zadání. Bodové hodnocení jednotlivých částí jsou uvedeny ve zvláštním dokumentu na WWW stránkách předmětu. Termín odevzdání každé části sdělí cvičící/tutor. Při odevzdání po termínu nebude hodnocení příslušné části započítáno. Součástí vypracování každé části je dokumentace obsahující náčrty topologií s adresováním a dalšími zvolenými parametry a úplnou konfiguraci všech síťových prvků (preferovaně oddělně pro jednotlivé konfigurované technologie) a dále údaje dle požadavků řešení uvedených k jednotlivým částem zadání níže. V dokumentu TPS-CS-1617L-v2-IOS-PRIKLADY.pdf najdete příklady syntaktických konstruktů Cisco IOS pro jednotlivé kroky konfigurace případové studie V dokumentu TPS-CS-1617L-v2-TESTPOINTS.pdf je uvedena ukázka doporučeného otestování jednotlivých kroků konfigurace včetně očekávaných výsledků (konkrétní hodnoty vašich adres a dalších parametrů se budou samozřejmě od hodnot uvedených v příkladových výpisech pocházajících z ověřovací implementace lišit) viz jednotlivé Test Points odkazované i v tomto textu. Odpovídající výpisy pro vaše řešení dodejte jako součást odevzdávané dokumentace případové studie. Před odevzdáním každé části vytipujte a zdokumentujte charakteristická místa v síti, mezi nimiž budete ověřovat konektivitu relevantní pro danou část (typicky serverové segmenty VRF A,B, loopback PEinet simulující Internet a dále vhodné infrastrukturní loopback rozhraní). Zdokumentujte a okomentujte příslušné traceroutes. Pokud vám v zadání není cokoli jasné, ptejte se bez odkladu cvičícího nebo přednášejícího. Popis konfigurovaného prostředí Logická struktura sítě pro celé zadání případové studie je znázorněna v záložce Overview/str.2. Principiálně se jedná o model firmy o 2 pobočkách (s předpokladem rozšíření o další pobočky), provozujici vlastní Corporate WAN Core a připojené k Service Provider Core pro účely internetové konektivity a záložního propojení jednotlivých poboček (primární konektivitu poboček poskytuje Corporate WAN Core). Service Provider Core a Corporate WAN Core (dále označované jako SPCore a WANCore) jsou založeny na MPLS/IPv4. V každé z poboček jsou formou VRF A a B implementovány dvě logicky odělené sítě. V síti WANCore jsou dále k dispozici všem zákazníkům sdílené služby (VRF C na směrovači PEwan0), které mají být zpřístupněny oběma VRF ve všech pobočkách. Globání adresní prostor směrovačů je v obrázcích vyznačen zelenou barvou.

3 V záložce Physical Topology/str. 3 je znázorněna fyzická topologie simulovaná v prostředí Virl. Další záložky (strany) popisují zadání jednotlivých částí případové studie, resp. jejich varianty přidělené jednotlivými zadáními. Pro lepší přehlednost jsou v některých případech detaily zadání znázorněny jen pro jednu pobočku, ve druhé pobočce je situace analogická. Zadání jednotlivých částí si detailně prostudujte v sekci Informace a doporučení k jednotlivým částem řešení níže. V každé pobočce je umístěn CE směrovač Rx se dvěma VRF. Mezi CE směrovačem pobočky Rx a PE směrovačem PEwanX je zapojena 802.1q trunk linka s vyhrazenými P2P VLAN pro VRF A a B (záložka Branch CE WAN PE/str.4). Na Rx je konfigurován VRF Lite, na PEwanX je realizována L3 MPLS/VPN jako primární konektivita mezi VRF A a VRF B v jednotlivých pobočkách; obě VRF mají dále konektivitu se společným segmentem ve VRF C na směrovači PEwan0 viz záložka IPv4 L3 MPLS/VPN / 6VPE /str 4. Varianty záložní konektivity pro VRF A a VRF B a internetové konektivity jsou vyobrazeny na dalších záložkách/stránkách souboru s náčrtky topologií. Obecná praktická doporučení k řešení Fyzickou topologii i vaši variantu zadání logických topologií je vhodné si vytisknout. Při konfiguraci každé síťové zařízení nejprve pojmenujte (hostname SOME_DEVICE), aby se vám nepletla paralelně otevřená terminálová okna a vložte do něj iniciální konfiguraci pro praktické zacházaní: no ip domain-lookup! nevyhledávat špatně vložené příkazy v DNS jako jméno cílového počítače pro navázání spojení Telnetem line con 0 exec-timeout 0! konzola nebude při vypršení idle timeoutu vyžadovat opětovné přihlášení Na rozhraní není od věci konfigurovat popisek (příkaz description) na které sousední zařízení a jeho port vede. S konfigurací vždy postupujte po vrstvách, od konfigurace subinterfaces a jejich 802.1q tagů přes IP adresování ke směrování a dalším funkcionalitám (viz také logicky uspořádáné kroky zadání níže). Konfiguraci směrovacích protokolů a LDP vždy zahajte statickým nastavením Router ID, později by již nebylo reflektováno a bylo by třeba příslušný směrovací proces restartovat. Jasně definovaným RouterID získáte take přehlednější výpisy sousedů a např. i daleko lépe čitelnou LSDB databázi. Každou nakonfigurovanou vrstvu a funkcionalitu si nejprve zkontrolujte (kontrola stavů interface, ping v rámci linky, kontrola sousedů směrovacích protokolů a LDP, LSDB databáze, směrovacích tabulek, BGP tabulek viz také doporučené postupy ověření), než se posunete k vyšší funkcionalitě, abyste měli jistotu, že složitější mechanismy stavíte na základech fungujících mechanismů pod nimi. I jen trochu rozsáhlejší konfigurace nevkládejte z CLI ručně připravte si ji předem v textovém editoru (takovém, u kterého víte, že nevkládá žádné podivné (binární) znaky notepad, vim, ). Tím získáte plné možnosti editace, zejména cut&paste. Po dokončení přípravy konfiguraci vložte do zařízení pomocí cut&paste do terminálu. Pokud si nejste jisti syntaxi jednotlivých příkazů, vyzkoušejte ji předem v CLI na

4 zařízení (tabulátor, otazník). Při vkládání konfigurace pomocí cut&paste pečlivě sledujte, zda zařízení nevypsalo žádnou chybovou zprávu (při vkládání větších bloků lze snadno přehlédnout zkontrolujte v historii terminálového okna). Před ukončením části práce si svou konfiguraci uschovejte v případě Virlu patrně nejlépe příkazy term len 0 (čímž zabráníte stránkování) a show running-config a následným cut&paste do lokálního souboru. Nejvíce se osvědčil systém zvláštního souboru pro každé zařízení, snadněji se v nich vyhledává jen v rámci konfigurace konkrétního zařízení. Dále doporučujeme dělat si konfigurační checkpointy uschování zálohy ověřené funkční konfigurace po jednotlivých fázích řešení, abyste se případně mohli snadno vrátit o krok zpět, pokud byste se při konfiguraci vydali zcela špatnou cestou. Pro správnou negociaci parametrů IPSec je nutné, aby směrovače měly synchronizovaný čas (rozdíl max. několik sekund). Pro laboratorní použití vyhoví manuální nastavení (příkaz clock set v privilegovaném exec režimu vložený téměř současně na všechna IPSec zařízení). Protokol BGP je (v základním nastavení) pomalý. Rescan BGP tabulky a výběr cest do směrovací tabulky dělá standardně 1x za minutu. Pokud vám nové nastavení nefunguje ihned po konfiguraci, několik minut počkejte. Při redistribuci mezi směrovacími protokoly (včetně redistribute static ) je vždy dobré v příkazu redistribute explicitně uvádět iniciální metriku některé varianty redistribuce do cílového směrovacího protokolu nemají implicitní hodnoty a bez takovéhoto explicitního určení nefungují. Oproti případnému očekávání příkaz sh ip rip database [vrf X] neukazuje všechny přijaté cesty od RIP, které by následně soutěžily o umístění ve směrovací tabulce, ale pouze ty, které byly skutečně do směrovací tabulky umístěny (tj. nebyly přebity cestami od jiných protokolů). Příchozí cesty je nejlépe kontrolovat sledováním RIP updates (debug ip rip / debug ipv6 rip). Při testovacím ping v protředí s více VRF vždy explicitně uvádějte zdrojovou IP adresu/interface. Pokud ping nefunguje, jedna z možných chyb je, že neexistuje cesta ke zdrojové adrese ve zpětném směru (např. router volí jako zdrojovou adresu pro ping adresu rozhraní na odchozí spojovací lince, která není do směrovacího protokolu propagována a tudíž pro doručení odpovědi na ping neznáma). Dále si je dobré si uvědomit, že úspěšná odpoveď na ping od cílového systému ještě nutně neznamená, že paket prochází právě požadovanou cestou (toto lze ověřit pomocí traceroute; v na hranicích MPLS mraku je navíc toto ovšem komplikováno potřebou správně nastavit volbu ttl-propagation na PE routerech). Pokud odpovědi na ping směrovaný na rozhraní směrovače nedochází, může být někdy výhodné ověřit, zda se ztrácí dotazy nebo odpovědi. Ke sledování příchozích echo requests a generování příslušných odpovědí lze využít příkaz debug ip icmp / debug ipv6 icmp. Při testech záložní konektivity vždy zkontrolujte nejen přechod na záložní cestu při simulaci výpadku cesty primární, ale i návrat na primární cestu při odstranění simulované závady. Vždy zdokumentujte způsob simulace závady, dobu do přechodu na záložní konektivitu a dobu přechodu na primární konektivitu po obnovení simulované závady. Měřte dobu do změny směrovacích tabulek (pomoci může i příkaz debug ip rip) a také počet ztracených odpovědí na ping přes příslušnou datovou cestu.

5 Vzhledem k použití tunelování (MPLS/GRE/IPSec/6to4/ISATAP hlaviček) by v praxi bylo nezbytné na linkách infrastruktury WANCore a SPCore navýšit MTU. V naší případové studii můžeme MTU ponechat na implicitní hodnotě, je však třeba počítat s nemožností transportu paketů s plným MTU (testovací ping s implicitní velikosti datové části bude procházet bez problémů, potíže by mohly nastat u TCP aplikací). Pro kontrolu funkčnosti směrovacího protokolu ISIS mohou být užitečné příkazy show clns interface, show clns neighbor a show clns database klíčové slovo clns zde odkazuje na název ISO transportního nespojovaného protokolu (obdoba IP), pro který byl směrovací protokol ISIS původně navržen. Pokud chceme ověřit, zda provoz skutečně odchází/přichází přes tunelové rozhraní, je možné pozorovat nárůst hodnot v čítačích odchozích/příchozích paketů na příslušném rozhraní tunnelx a generovat vhodný testovací provoz (ping). Informace a doporučení k jednotlivým částem řešení Krok 0 Plán adresování, VLAN tags, Router IDs Rozmyslete si IPv4 a IPv6 adresování serverových segmentů, spojovacích linek, loopbacků, hodnoty Router ID / NET a hodnoty 802.1q tags spojovacích linek v infrastruktuře SPCore, WANCore a v jednotlivých pobočkách (pro globální adresní prostor i VRF A i B, kde je to potřeba). Uvažujte i s ohledem na potenciální možní rozšíření. Schema zdokumentujte. Krok 1 SPCore a WACore Nejprve nakonfigurujte IPv4 adresování spojovacích linek a loopback rozhraní v globálním adresním prostoru SPCore a WANCore. Při vkládání adres se vyplatí pozornost a pečlivost, na správném adresování sítě je závislá správná funkce všech dalších konfigurovaných mechanismů. Následně zprovozněte ve WANCore a SPCore přidělený vnitřní směrovací protokol, do kterého propagujte i infrastrukturní loopback rozhraní všech PE i P směrovačů příslušného síťového mraku. Všimněte si, že loopback789 směrovače PEnet simulující Internet do IGP propagován není. Protokol IGP1 a IGP2 v SPCore a WANCore přidělí pro vaše konkrétní zadání cvičící. U IGP a později i u BGP vždy nejprve konfigurujte router-id, resp. NET. Pokud router-id nastavíte/změníte později, musíte resetovat příslušný proces (clear ip ospf process, ). Do hodnoty NET pro ISIS směrovače je vhodné pro přehlednost zabudovat IP adresu infrastrukturního loopback interface. Všechny vazby mezi ISIS směrovači budou typu L1, také pro OSPF vše konfigurujte v jediné oblasti. Po dokonfigurování směrovacích protokolů pečlivě zkontrolujte směrovací tabulky všech směrovačů (viditelnost všech loopback rozhraní i spojovacích linek. V underlay směrování (na P a mezi P a PE směrovači) budou samozřejmě pouze infrastrukturní spojovací linky a loopback rozhraní, žádné cesty ze zákaznických VRF ani rozhraní PEinet simulující Internet. Způsob ověření ukazuje Test Point 1.

6 Krok 2 MPLS ve WANCore + SPCore Ve WANCore zprovozněte MPLS (na všech vnitřních fyzických rozhraních) a LDP, v případě potřeby pro vaši variantu zadání také v SPCore. Před konfigurací MPLS rozhraní explicitně konfigurujte loopback rozhraní, ze kterého se bude odvozovat jednoznačné LDP router ID. Zkontrolujte LDP vazby a obsahy LIB tabulek viz Test Point 2. Krok 3 Infrastruktura poboček, PE-CE routing Následně implementujte VRF A a B na CE routerech poboček Rx a na PE routerech PEwan1/2 serverové segmenty, spojovací linky a per-vrf dynamické směrování mezi PE-CE v obou VRF podle schematu pro L3 MPLS/VPN (viz záložka Branch CE-WAN PE). Dejte pozor na fakt, že bez konfigurace Route Distinguisher v každé VRF není VRF funkční (nesměruje se). Také Route Targets pro L3 MPLS/VPN zvolte, zdokumentujte a konfigurujte již nyní, budete je využívat v dalších částech případové studie. Všimněte si, že import/export cest mezi VRF i jen v rámci CE směrovače (VRF Lite), který je nutný v některých variantách řešení záložní konektivity (AToM VRF A s i/e přes transportní VRF T), vyžaduje konfiguraci address-family pro příslušné VRF v BGP procesu. V tomto případě BGP technicky slouží jako implementační prostředek přenosu informace mezi směrovacími tabulkami zúčastněných VRF. V konfiguraci BGP pro takovýto čistě lokální import/export nemusí být specifikován v dané VRF žádný skutečný BGP soused, v adresních rodinách příslušných VRF však musí být konfigurovány redistribuce (statických/přímo_připojených/igp cest) do BGP. S ohledem na použití OSPF ve VRF A v návaznosti na superbackbone reprezentovanou MPLS/VPN ve WANCore je nutné v procesu OSPF CE routerů pro ignorování Down bitu nastavovaného při redistribuci BGP-> OSPF konfigurovat capability vrf-lite. Do každého ze serverových segmentů je vložen jeden Linux server sloužící pouze pro testování konektivity konec-konec. Na něm pouze nakonfigurujte vhodnou adresu z příslušného subnetu a default gateway a používejte pro testování. Transportní BGP session PEwanX-Rx pro prefix IPv4 a IPv6 realizujte zvlášť nad IPv4 a IPv6 - zamezíte tím problémům se standardním nastavením hodnoty NEXT-HOP atributu podle transportní adresy zdroje cesty, což by nevyhovovalo druhé z adresních rodin. Kontrolu funkčnosti tohoto kroku proveďte dle Test Point 3. Krok 4 - L3 MPLS/VPN Pokračujte IBGP konektivitou pro vaše PEwanX routery na route reflector Pwan a konfigurací route reflectoru samotného. Transportní IBGP sessions (TCP/179) mezi PE routery a RR budou vždy nad IPv4. Na směrovačích PEwanX (RR klientech) bude konfigurace BGP vazby s RR standardní (s aktivací addressfamily vpnv4 unicast + vpnv6 unicast, nezapomeňte také na povolení přenosu extended community, která jsou nutné pro propagaci Route Targets. V případě full mesh IBGP vazeb by bylo nezbytné na IBGP vazbách mezi PEWanX routery konfigurovat next-hop-self; při použití route reflectoru však dochází v IOSu k přepsání hodnoty atributu NEXT_HOP na adresu loopback interface RR klienta propagujícího příslušný prefix automaticky.

7 Nyní realizuje L3 MPLS/VPN přes WANCore vždy vzájemně mezi VRF A a VRF B v jednotlivých pobočkách, obě VRF pak mají navíc konektivitu s VRF C na PEwan0 (záložka IPv4 L3 MPLS/VPN / 6VPE). RD a RT atributy byly konfigurovány již v předchozích krocích. Při konfigurace redistribuce BGP<->OSPF na PE směrovačích pro IPv4 nezapomeňte na klíčové slovo subnets. Dále v tomto kroku konfigurujte VRF C na PEwan0. Ověření funkčnosti by mělo odpovídat výpisům z Test Point 4. Pomocí vhodného nastavení domain-id OSPF procesů na příslušných směrovačích zajistěte, aby cesty do VRF ve druhé pobočce byly vidět jako inter-area routes, zatímco cesty do VRF C za směrovačem PEWan0 jako cesty externí. Varianty zadání záložní konektivity pro VRF A Varianta zadání - BGP-free Core / 6PE ve VRF A (záložka BGP-free core vrf A / 6PE) Pomocí technologie BGP-free core, resp. 6PE pro IPv6 přes SPCore realizujte přístup VRF A všech poboček na Internet simulovaný loopbackem AS789 směrovače PEinet. Pobočky mezi sebou se vzájemně tímto mechanismem nevidí (příslušné směrovače PEspX jsou všechny ve stejném AS a IBGP vazby jsou konfigurovány pouze mezi PEspX a PEinet, ne vzájemně mezi PEspA a PEspB). Spojovací linky mezi PEspX a Rx budou v globálním adresním prostoru. Do IBGP propagujte spojovací linku mezi PEspX a Rx v globálním adresním prostoru) a serverový segment ve VRF A připojený k Rx. Nezapomeňte na příkaz send-label směrem k BGP sousedovi PEinet (a obdobně na routeru PEinet směrem k PEspX). Pro správnou funkci MPLS tunelů konfigurujte IBGP vazby vždy mezi loopback rozhraními. Na Rx realizujte lokální přemostění mezi globálním adresním prostorem (interface g0/3.vg) a serverovým segmentem ve VRF A (g0/1) pomocí statických cest: ip route vrf A <nexthop-in-globlal-routing> global ip route <vrfa-server-segment> g0/1 ipv6 route vrf A ::/0 <nexthop-in-globlal-routing> nexthop-vrf default ipv6 route vrf default 2001:AAAA:gr00::/64 g0/2 nexthop-vrf A Pro ověření funkčnosti viz Test Point 5. Poznámka: Nevýhodou implementovaného řešení je, že loopback rozhraní směrovačů SPCore nejsou ochráněny před škodlivým provozem generovaných z poboček.. V praxi by byl vhodné implementovat alespoň filtraci pomocí ACL. V dokumentaci případové studie můžete naznačit návrh konkrétního řešení. Varianta zadání - Záložní konektivita VRF A přes AToM pseudowire (záložka AToM VRF A, resp. AToM VRF A i/e VRF T) Pro VRF A zprovozněte záložní konektivitu přes SPCore pomocí pseudowire (AtoM) propojující VRF A v obou pobočkách, resp. transportní VRF T, které mají import/export vždy s VRF A v každé pobočce (viz záložky AToM VRF A a AToM VRF A i/e VRF T) sub-variantu zadání přidělí cvičící. Přes pseudowire realizujte záložní statické směrování IPv4/IPv6 mezi serverovými segmenty VRF A obou poboček.

8 Návaznosti na L3 MPLS/VPN jsou na schematech zopakovány jen pro lepší uvědomění situace pro správnou realizaci preference konektivity přes L3 MPLS/VPN ve WANCore. Po nakonfigurování zkontrolujte směrovací tabulky na Rx a to ve standardním stavu i ve stavu simulace výpadku interface Rx do WANCore a přechodu na záložní konektivitu přes AToM. Ověřte, že při přerušení primární konektivity přes L3 MPLS/VPN ve WANCore bude provoz směrován přes AToM a konektivita serverových segmentů VRF A zůstane zachována. Při testech záložní konektivity vždy testujte nejen přechod na záložní konektivitu, ale i přechod zpět na konektivitu primární. Poznámka: Za přítomnosti konfigurace redistribuce nemusí být bez dalšího vylaďování časovačů ustálení směrovacích tabulek při simulaci výpadku deaktivací interface okamžité, počkejte cca 1 minutu (souvislost s default BGP scan intervalem). Subvarianta přímého propojení AToM PW do VRF A: Ověření funkčnosti viz Test Point 6. Subvarianta propojení do AToM přes VRF T: Pro import/export mezi VRF A a T je třeba v příslušných VRF redistribuovat do BGP přímo připojený serverový segment, resp. statické cesty. Dále je nutné si uvědomit relativní preferenci cest získaných od IGP vůči cestám získaných pomocí import/export mezi VRF (L3 MPLS/VPN]. Na Rx v IOS vzniká na první pohled nečekaný efekt : cesty od i/e jsou kandidáty na vložení do směrovací tabulky s AD 20 (EBGP), nikoli 200 (IBGP). Výsledkem tohoto chování je, že cesty přes i/e s VRF T (AToM PW) budou priorizovány oproti cestám od OSPF (AD110) z MPLS/VPN, což není žádoucí stav. Požadovaného chování lze dosáhnout snížením AD (příkaz distance N ) v konfiguraci procesu OSPF na Rx pod hodnotu 20. Při ladění preferované primární konektivity (výběr z alternativních cest pro přijetí do směrovací tabulky) může být užitečný příkaz show ospf rib [detail], který zobrazí cesty od OSPF kandidující na umístění do směrovací tabulky (principiálně jde o výsledek výpočtu SPF algoritmu). Konfiguraci možno otestovat podle postupu Test Point 7.

9 Varianty zadání záložní konektivity pro VRF B Varianta zadání - záložní konektivita VRF B přes Service Provider Core (IPSec / GRE). Internetová konektivita VRF B přes GRE tunely. (záložka IPSec/GRE VRF B) Záložní konektivitu VRF B poboček konfigurujte pomocí statického tunelu IPSec over GRE. Šifrovací a autentizační algoritmy zvolte sami - pro autentizaci IKE fáze 1 použijte předsdílený klíč, pro fázi 2 volte tunelový mód. Tunel realizujte pomocí tunnel interface s IPSec profile (příkaz tunnel protection). Přes tunel realizujte statické směrování mezi VRF B obou poboček a do Internetu dle obrázku. Směrování konektivity mezi pobočkami pouze v případě výpadku konektivity přes WANCore realizujte konfigurací méně specifické default cesty na Rx VRF B přes PEspX VRF B. Na Rx se ujistěte, že primární konektivita mezi pobočkami ve VRF B vede díky více specifické cestě přes MPLS VPN. Zálohu ověřte dočasnou deaktivací interface z Rx do WANCore a opětovnou aktivací ujistěte se, že po obnovení bezvýpadkového stavu se konektivita překlopí zpět na WANCore MPLS/VPN. Vzhledem k implicitnímu nastavení časovačů (BGP Scan interval) může překlopení cca 1-2 minuty trvat. POZOR: Před konfiguraci IPSec mechanismů je nutné na zúčastněných routerech zajistit synchronizaci času. Internetovou konektivitu pro IPv4 i IPv6 realizujte pomocí GRE tunelů mezi směrovači PEspX a PEinet se statickým směrováním (viz obrázek) a statickou default cestou ze směrovače Rx na PEspX. Internetovou konektivitu i konektivitu mezi pobočkami ověřte dle postupu v Test Point 8. Varianty zadání - Záložní IPv6 konektivita pro VRF B a Internet konektivita přes SPCore pomocí 6to4/ISATAP (záložky 6to4 VRF B / ISATAP VRF B) Mezi směrovači PEsp1, PEsp2 ve VRF B a PEinet v globálním routingu realizujte IPv6 konektivitu přes IPv4 mrak SPCore pomocí technologie 6to4, resp. ISATAP (záložka 6to4 VRF B, resp. ISATAP VRF B ). Aby bylo možné zachovat původní IPv6 adresování serverových segmentů poboček i přes konvence definované pro subnety za 6to4 a ISATAP GW routery, budou na uvedených směrovačích konfigurovány statické cesty s nexthop adresami směřujícími do tunelového rozhraní 6to4/ISATAP a obsahujícími vnější IPv4 adresu příslušného 6to4 nebo ISATAP vzdáleného gateway routeru (6rd by toto nepřípustil, vždy kontroluje zdrojovou adresu datových paketů přijímaných na 6rd GW). Jako koncový bod dynamických tunelů vždy použijte infrastrukturní loopback směrovače připojujícího cílový IPv6 segment. Aby měla 6to4/ISATAP konektivita charakter zálohy primární cesty mezi VRF B jednotlivých poboček přes MPLS/VPN, konfigurujte na R1/R2 pouze méně specifickou statickou cestu; s ohledem na kombinaci s internetovým routingem to zde bude default cesta. Pro 6to4 transport přes SPCore zvolte adresy tunnel interfaces dle schematu 2002:<GW-IP>:pppp::/64 (hodnotu pppp zvolte), pro ISATAP stanovte vhodný společný site prefix 2001:xxxx::/32.

10 Internetovou konektivitu pro IPv6 realizujte statickou default cestou přes nexthop loopback1 směrovače PEinet reprezentovaný svou 6to4/ISATAP adresou za tunelovým rozhraním 6to4/ISATAP. Ověření funkčnosti 6to4 je doporučeno podle Test Point 9, ISATAP dle postupu Test Point 10. Varianty zadání - Záložní IPv6 konektivita pro VRF B a Internet konektivita přes SPCore pomocí DMVPN Phase 2/3 (záložka DMVPN VRF B) Záložní konektivitu poboček a internetovou konektivitu VRF B konfigurujte pomocí DMVPN dynamické tunely mezi infrastrukturními loopback rozhraními PEsp1, PEsp2 a PEinet v SPCore. Směrovač PEinet (v globálním adresním prostoru) bude sloužit jako DMVPN/NHRP hub, ostatní jsou spokes viz záložka DMVPN VRF B. Tunelovaný protokol je IPv4 a/nebo IPv6, transportní vždy IPv4, čímž i konfigurace IPSec profile odpovídá standardní konfiguraci pro tunel nad IPv4. Přes DMVPN zprovozněte protokol RIPv2/RIPNG (volitelně po dohodě se cvičícím můžete použít EIGRP). U protokolu RIP nezapomeňte konfigurovat verzi 2 a vypnout autosumarizaci. Podporu více VRF u protokolu RIPNG je nutno explicitně zapnout příkazem ipv6 rip vrf-mode enable. Na DMVPN tunelech buďto zprovozněte podporu multicastu nebo konfigurujte sousedy směrovacího protokolu staticky. Konfigurujte NHRP pro dynamické vytváření spoke-spoke tunelů. Parametry IPSec ochrany tunelů zvolte sami a zdokumentujte. Podle varianty vašeho zadání (přidělí cvičící) implementujte DMVPN Phase 2 (s přeposíláním plné směrovací informace od hub ke všem spoke routerům), nebo DMVPN Phase 3 (sumarizace směrovací informace ve směru hub->spoke). V obou případech aktivujte možnost přimé komunikace spoke-spoke pomocí NHRP cache. Poznámka: V reálné implementaci by byla z PEinet do IGP na DMVPN tunelech redistribuovaná statická default cesta na upstream ISP směrovač, což by dovolilo jednosměrnou konektivitu z VRF B uživatelských poboček na infrastrukturní loopback rozhraní směrovačů SPCore. V praxi by proto bylo vhodné implementovat alespoň filtraci tohoto nežádoucího provozu pomocí ACL. V dokumentaci případové studie můžete naznačit implementaci konkrétního řešení.