Technologie počítačových sítí - ZS 2015/2016 Kombinované studium. Případová studie zadání a popis požadavků

Transkript

1 Technologie počítačových sítí - ZS 2015/2016 Kombinované studium Případová studie zadání a popis požadavků Petr Grygárek Úvod Případová studie je rozdělena na 2 části, které dohromady tvoří ucelenou síťovou konfiguraci. První část reprezentuje konfiguraci MPLS infrastruktury, VRF lite a L3 MPLS/VPN jako jedné z nejpodstatnějších partií předmětu, druhá je realizací některé z probíraných tunelovacích technologií. Parametry zadání pro obě části a volbu konkrétní technologie pro druhou část řešení přidělí specificky jednotlivým studentům tutor. Požadavky na jednotlivé části jsou specifikovány v náčrtech topologií v souboru TPS-CaseStudy- 1516L-KOMBIN.pdf a upřesněny zde 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řistup k prostředí Virtlu a i práce s ním jsou popsány na webových stránkách (Wiki) předmětu, detaily osvětlí tutor. Případová studie je koncipována tak, aby bylo možné probírané technologie prakticky odzkoušet na minimálním počtu zařízení. Proto implementovaná konfigurace nemusí odrážet design, který by byl volen v reálných nasazeních. Zejména není ve většíně případů realizována redundance, která je v praxi zpravidla zásadním požadavkem. Termíny odevzdání jednotlivých částí i způsob hodnocení a podmínky udělení zápočtu sdělí tutor. Součástí vypracování každé části je dokumentace obsahující veškeré konfigurace a schemata a zpracování požadavků řešení uvedených k jednotlivým částem zadání níže. Při hodnocení bude kladen důraz na funkčnost konfigurace příslušné technologie, případné detaily ošetření specifického chování složitějších případů směrování jsou pro náš předmět méně relevantní a budou hodnoceny s větší mírou tolerance. Poznámka: realizovatelnost všech částí a variant zadání byla v prostředí Cisco Virl předem prakticky ověřena. Organizace práce Síťová topologie ve Virlu je předpřipravena a částečně předkonfigurována (předkonfigurace budou také umístěny na Wiki předmětu). Rozvrhnutí časových oken pro práci jednotlivých studentů sděli tutor.

2 Náčrtky topologií a schemat pro případovou studii najdete v jednotlivých záložkách (stránkách) souboru TPS-CaseStudy-1516L-KOMBIN.pdf (dále odkazovány jen názvy záložek, resp. stran). Čísla VLAN a adresní schema jsou voleny tak, aby šlo v budoucnu realizovat společnou práci více studentů na sdíleném SPcore a WANcore, pročež jsou adresní prostory i čísla VLAN unikátní (v praxi by se čísla VLAN i adresní rozsahy, které se vzájemně nesetkávají, mohly opakovat). Na předkonfigurované síťové prvky (ve schematech topologií vyznačených šedou barvou) můžete přistupovat přes konzoli stejně jako na vaše vlastní zařízení. V dokumentu TPS-CS-1516L-IOS-PRIKLADY.pdf najdete příklady syntaktických konstruktů Cisco IOS pro jednotlivé kroky konfigurace případové studie. V dokumentu TPS-CS-1516L-popis-KOMBIN-TEST.pdf je uvedena ukázka doporučeného otestování jednotlivých kroků konfigurace všetně očekávaných výsledků viz jednotlivé Test Points odkazované i v tomto textu. Pokud vám v zadání není cokoli jasné, ptejte se bez odkladu tutora nebo přednášejícího. Popis konfigurovaného prostředí Logická struktura sítě pro obě části zadání je znázorněna v záložce Overview/str.2. Principiálně 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 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é pobočce je mezi PE směrovačem Rgx a CE směrovačem RSgx zapojena 802.1q trunk linka s vyhrazenými VLAN propojujícími VRF A, B a globální adresní prostor obou zařízení (záložka Branch Office Infra/str.4). Na RSgx je konfigurován VRF Lite, na Rgx je realizována MPLS/VPN jako primární konektivita pro VRF A a VRF B v jednotlivých pobočkách (část 1). Záložní konektivita pro VRF A nebo VRF B a/nebo internetová konektivita je realizována v části 2 individuálně přidělenou tunelovací technologií. Kombinace zadání pro část 1 (IPv4/IPv6 MPLS/VPN) a pro část 2 (záloha pro příslušný transportní protokol) jsou tutorem voleny tak, aby na sebe logicky navazovaly. 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ým studentům. 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 prostudujte v sekci Informace a doporučení k jednotlivým částem řešení. Obecná praktická doporučení k řešení

3 Fyzickou topologii i vaši variantu topologií logických je vhodné si vytisknout. Při konfiruaci každé síťové zařízení nejprve pojmenujte (hostname SOME_DEVICE), aby se vám nepletla 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 IP adresování ke směrování a dalším funkcionalitám. 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ý proces restartovat. Jasně definovaným RouterID získáte 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 database, směrovacích tabulek, BGP tabulek), 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 předem v CLI na 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 odvědčil systém zvláštního souboru pro každé zařízení). Dále doporučujeme dělat si konfigurační checkpointy uschování ověřené funkční konfigurace po jednotlivých fázích řešení (alespoň po dokončení části 1),, 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. Pro laboratorní použití vyhoví manuální nastavení (příkaz clock set v privilegovaném exec režimu). 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.

4 Při redistribuci mezi směrovacími protokoly 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 (typicky RIP) bez tohoto nefungují. Oproti případnému očekávání příkaz sh ip rip database vrf B 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. v našem případě nebyly přebity cestami od protokolu BGP). 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 source IP/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 spojovací lince, která není do směrovacího protokolu propagována a tudíž příjemci ping zprávy neznáma). Dále si je dobré 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 navíc komplikováno potřebou správně nastavit volbu ttl-propagation). 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. 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 zcela bez problému, potíže by mohly nastat u TCP aplikací). Informace a doporučení k jednotlivým částem řešení Část 1 Část 1: Infrastruktura SPCore a WANCore (IGP, BGP a MPLS) Nejprve zprovozněte infrastrukturní konektivitu, zvlášť v mracích SPCore a WANCore, vždy s ohledem na vám přidělený IGP protokol v každém z těchto mraků (Test Point 1). Adresování najdete v záložce Physical Topology/str 3. Protokol IGP1 a IGP2 v SPCore a WANCore přidělí pro vaše konkrétní zadání tutor. U OSPF/ISIS/BGP vždy nejprve konfigurujte router-id. Pokud router-id nastavíte/změníte později, musíte resetovat přísušný proces (clear ip ospf process, ). Do hodnoty NET pro ISIS směrovače je vhodné pro přehlednost zabudovat IP adresu loopbacku interface v příslušné směrovací doméně. Všechny vazby mezi ISIS směrovači budou typu L1. Loopback1 všech zařízení MPLS mraku propagujte do IGP. Všimněte si, že loopback 789 směrovače PEnet simulující Internet do IGP propagován není. 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. Po dokonfigurování směrovacích protokolů pečlivě zkontrolujte směrovací tabulky všechy směrovačů

5 (viditelnost všech loopback rozhraní i spojovacích linek), než přikročíte k dalším krokům. 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. Pokračujte IBGP konektivitou pro vaše PE zařízení na route reflector Pwan a pokud to vaše varianta zadání vyžaduje, tak i EBGP se směrovačem Peinet v SPCore (Test Point 2). Cisco IOS dovoluje umístit směrovač jen do jednoho AS. Aby bylo možné použít route reflectoru pro IBGP ve WANCore, jsou směrovače Rg1-Rg2 umístěny do privátního AS WANCore (65001) a v SPCore provozují EBGP. Předkonfigurovaný směrovač Pwan v AS bude sloužit jako route reflector (RR) pro vaše PE směrovače. Transportní BGP session (TCP/179) mezi PE routery a RR bude vždy nad IPv4. Na směrovačích Rg1-Rg2 (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á nese Route Target(s)). Dále ve WANCore zprovozněte MPLS (na všech vnitřních fyzických rozhraních) a LDP (propagace pouze loopback rozhraní), v případě potřeby pro vaši variantu zadání také v SPCore (Test Point 3). Do LDP propagujte pouze loopback rozhraní směrovačů v příslušném MPLS mraku. Směrovače Rg1-Rg2 se účastní obou MPLS mraků a provozují LDP na rozhraních do obou z nich. Mezi SPCore a WANCore však nikdy nevede MPLS tunel a propagace prefixů loopback rozhraní nehraničních zařízení mezi mraky SPCore a WANCore je na směrovačích Rg1-Rg2 manuálně znemožněna (příkaz no mpls ldp advertiselabels následovaný mpls ldp advertise-labels for <ACL#>). Pokud si správností konfigurace filtrace LDP mezi MPLS mraky nejste jisti, konzultujte tutorem špatná filtrace může způsobit nesprávné chování konfigurací v dalších krocích. Zkontrolujte i LDP vazby a obsahy LIB tabulek.

6 Část 1: Základní L2 a L3 struktura pobočky, VRF Lite, PE-CE routing Následně implementujte VRF A a B na PE routerech Rg[1-2] a CE routerech RSg[1-2], spojovací linky a směrování mezi PE-CE v obou VRF podle schematu pro L3 MPLS/VPN (viz záložka Branch Office Infra) - zatím pouze v rámci jednotlivých poboček. Dejte pozor na fakt, že bez konfigurace Route Distinguisher každé VRF není VRF funkční. Také Route Targets konfigurujte již teď podle obrázku, 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 zadání Části 2, 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 nemusí být pro takovýto čistě lokální import/export specifikován žá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) z a do BGP. V procesu OSPF CE routerů je nutné 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 nakonfigurujte vhodnou adresu z příslušného subnetu a default gateway. V případě varianty zadání MPLS/VPN pro IPv6 realizujte transportní session pro BGP mezi PE-CE nad IPv6. Část 1 - L3 MPLS/VPN (IPv4 / IPv6) Nyní realizuje L3 MPLS/VPN přes WANCore mezi VRF A a VRF B v jednotlivých pobočkách, dle vaší varianty zadání pro transportní protokol IPv4 nebo IPv6 (6vPE). RD a RT atributy byly konfigurovány již v předchozích krocích (záložka IPv4 L3 MPLS/VPN / 6VPE). Při redistribuci BGP->OSPF na PE směrovačích pro IPv4 nezapomeňte na klíčové slovo subnets. Zajistěte také konektivitu do předkonfigurované pobočky simulované směrovačem PEx. Ověření funkčnosti by mělo odpovídat výpisům z Test Point 4.

7 Část 2 Varianta zadání - BGP-free Core / 6PE (záložka BGP-free core vrf A / 6PE) Pomocí technologie BGP-free core (resp. 6PE pro IPv6) přes SPCore realizujte přístup všech poboček na Internet simulovaný loopbackem AS789 předkonfigurovaného směrovače PEinet. Pobočky mezi sebou se vzájemně tímto mechanismem nevidí (jsou všechny ve stejném AS a v našem případě realizujeme BGP-free core/6pe přes EBGP, které předávání cest přes AS 789 zpět do AS zabrání). Do EBGP propagujte spojovací linku mezi Rgx a RSgx v globálním adresním prostoru) a také serverový segment ve VRF A připojený k RSgx. Nezapomeňte na příkaz send-label směrem k BGP sousedovi PEinet. Pro správnou funkci MPLS tunelů konfigurujte BGP vazby (v AS 789 i 65001) vždy z loopback1 rozhraní vašeho směrovače na rozhraní loopback1 směrovače protějšího (takto jsou i připraveny na předkonfigurovaných směrovačích). V případě EBGP je za tohoto uspořádání nutno použít funkci EBGP multihop (nastavení iniciálního IP TTL pro transportní relaci BGP má jinak hodnotu 1). Na RSgX realizujte lokální přemostění mezi globáním adresním prostorem (interface g0/1.gr0) a serverovým segmentem ve VRF A (g0/2) pomocí statických cest: ip route vrf A <nexthop-in-globlal-routing> global ip route <vrfa-server-segment> g0/2 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 A.

8 Varianta zadání - Záložní konektivita přes systém AToM pseudowires (záložka AToM VRF A, resp. AToM VRF A i/e) Pro VRF A zprovozněte záložní konektivitu přes SPCore pomocí pseudowire (AtoM) propojující VRF A v jednotlivých pobočkách, resp. transportní VRF T, které mají import/export vždy s VRF A v každé pobočce (viz záložka AToM VRF A / AToM VRF A i/e variantu zadání přidělí cvičící). Přes pseudowire zprovozněte protokol RIPv2/RIPNG, do kterého propagujte jednak IP (v4/v6) segmenty jednotlivých pseudowires a jednak serverový segment VRF A. Návaznosti na L3 MPLS/VPN jsou na schematech zopakovány jen pro lepší uvědomění situace a případné potřeby nastavení AD směrovacího protokolu přes AToM, aby bylo dosaženo preference konektivity přes MPLS/VPN ve WANCore. Uvědomte si způsob přenosu směrovací informace od IGP protokolů mezi VRF. Zatímco u import/export je zachována netranzitivita přenosu cest mezi VRF (principiálně jde o standardní chování protokolu IBGP, žádný dodatečný mechanismus doplněný specificky pro MPLS/VPN), cesty naučené od IGP a EBGP se při i/e přenášeji (pokud není redistribuce explicitně omezena filtrací). Pečlivě zkontrolujte směrovací tabulky na Rgx i RSgx a to ve standardním stavu i ve stavu simulace výpadku interface 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 WAN bude instalována do směrovací tabulky Rgx/RSgx cesta 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 není bez dalšího vylaďování časovačů není ustálení směrovacích tabulek při simulaci výpadku deaktivací interface okamžité, počkejte cca 1 minutu (souvislost s defautl BGP scan intervalem). Pozorování ukázalo, že při konfiguraci příkazu distance ve směrovacím protokolu může trvat několik minut, než směrovač vezme konfiguraci v potaz a směrovací tabulku ve smyslu preference příslušného směrovacího protokolu upraví. 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. V PE-CE nasazení protokolu OSPF je na CE nutná capability vrf-lite. Subvarianta přímého propojení AToM do VRF A: Opatření proti směrovacím smyčkám při přímém napojení pseudowire do VRF A nejsou nutné, protože není konfigurována žádná redistribuce serverové segmenty VRF A jsou pouze propagovány paralelně do dvou různých směrovacích protokolů (přes MPLS/VPN ve WANCore (OSPF/IBGP) a přes AToM v ISPCore (RIP)). Na RSgx se přechod na záložní (AToM) konektivitu projeví tak, že cesta do segmentu VRF A druhé pobočky nebude viditelná z OSPF, ale z RIP. Všimněte si, že cesty známé od RIP přes ATOM nebudou ve směrovací tabulce VRF viditelné, dokud existuje primární konektivita. Ověřit příchod cesty od RIP je možné buďto příkazem debug ip rip, nebo

9 dočasným zlepšením (snížením) AD protokolu RIP oproti WANCore PE-CE IGP zde OSPF (příkaz distance v příslušné address-family konfigurace protokolu RIP). Při testováni backup scénáře s rozpojením portu Rgx do WANCore není nepřítomnost cest do VRF A druhé pobočky na směrovači Rgx chybou pseudowires vedou přímo do VRF A v RSgx a redistribuce z RIP na AToM pseudowire do CE-PE OSPF transportujícím CE cesty k PE do VRF A konfigurována není. Pokud jste blíže neomezili redistribuci OSPF->BGP, budou u VRF A na RSx viditelné i adresy spojovacích linek PE-CE z cizí pobočky a to jako OSPF inter-area cesty (O IA) na tomto je dobře vidět princip chování OSPF superbackbone (jednotlivé pobočky jsou samostatné OSPF oblasti). Všimněte si nastavení Down bitu u příslušných LSA 3 (sh ip ospf database summary) (text Downward ). Ověření funkčnosti viz Test Point B. Subvarianta propojení do AToM přes VRF T: Ve variantě s mezilehlou VRF T 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. Na RSgx 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 RSgx pod hodnotu 20. Při propagaci serverového subnetu z VRF T do pseudowire je nutné chápat, že tento segment je získán přes i/e a ve směrovací tabulce má tedy původ od protokolu BGP. Nelze jej tedy do RIPu propagovat příkazem network v sekci router rip, ale pouze redistribucí. 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ě výsledek výpočtu SPF algoritmu). Konfiguraci možno otestovat podle postupu Test Point C. Varianta zadání - záložní konektivita přes Service Provider Core (IPSec / GRE) (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 ESP a tunelový mód. Tunely realizujte pomocí tunnel interface s IPSec profile (příkaz tunnel protection). Přes tunel zprovozněte protokol RIPv2/RIPNG (volitelně po dohodě se tutorem můžete použít EIGRP). Aby i v případě výpadku linky z Rgx do WANCore byla zachována konektivita ve VRF B mezi RSgx, je nutná obousrměrná redistribuce RIP<->(E)BGP. Bez dalších opatření by však toto vedlo k zacyklování

10 směrovací informace přes RR, k rozkmitání routingu a ke směrovacím smyčkám. Jedna z možností ošetření této situace je následující: 1. Na Rgx z EBGP od RSgx redistribuujte do RIPv2 na IPSec tunelu pouze serverový subnet vlastní pobočky (a pouze ten): ip prefix-list PLTORIP permit <server subnet> route-map TORIP permit 1 match ip address prefix-list PLTORIP router rip address-family ipv4 vrf B redistribute bgp route-map TORIP (metric MM) 2. Při redistribuci RIP->BGP na Rgx si redistribuované cesty značkujte, např takto: route-map RMTOBGP permit 10 set community 65001:999 router bgp address-family ipv4 vrf B redistribute RIP route-map RMTOBGP 3. Abyste zabránili cyklování, nedovolte šíření prefixů redistribuovaných z RIP do BGP k route reflectoru, odkud by byly propagovány do ostatních poboček jako vlastní segmenty konfigurované pobočky (do EBGP k RSgx je samozřejmě šířit musíme). K tomů využijeme dřívějšího označkování redistribuovaných prefixů zvolenou hodnotou community: ip community-list 1 permit 65001:999 route-map TORR deny 10 match community 1 route-map TORR permit 20 router bgp address-family vpnv4 neighbor rr.rr.rr.rr route-map TORR out 4. Nakonec musíme na Rgx zajistit, aby redistribuované cesty z RIPu do BGP nepřevládly nad cestami od RR mají totiž díky redistribuci statut lokálně generovaných cest a maji tudíž i lepší (default) Weight (a ještě k tomu prázdný AS-Path). Proto musíme na cesty od RR aplikovat atribut Weight s lepší hodnotou: route-map FROMRR permit 10 set weight 40000

11 router bgp address-family vpnv4 neighbor rr.rr.rr.rr route-map FROMRR in (pozor, toto ovlivní všechny VRF zvažte případné důsledky pro vrf A) Obdobnou konfiguraci lze použít pro IPv6, resp. address family vpnv6. Stabilitu směrování lze zkontrolovat příkazem debug ip routing. Na Rgx se ujistěte, že primární konektivita mezi pobočkami ve VRF B vede přes MPLS VPN. Pokud tomu tak není, uvažujte nad relativními preferencemi (administrative distance) směrovacího protokolu BGP a RIP. Zálohu ověřte dočasnou deaktivací interface z Rgx 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čů (RIP update timer, BGP Scan interval) může překlopení cca 1-2 minuty trvat. Pozorování: V některých verzích IOS za jistých okolnosti na dodatečné nastavení AD pod address-family příslušné VRF protokolu RIP router nereaguje, nebo reaguje s extrémním zpožěním. Pak je třeba konfiguraci protokolu RIP kompletně odebrat (no router rip) a vložit znovu, tentokrát s příkazem distance již na začátku sekce příslušné AF. Před konfiguraci IPSec mechanismů je nutné na zúčastněných routerech zajistit synchronizaci času. Test Point D ukazuje výsledky ověření pro variantu IPSec; Internetovou konektivitu pro transportní protokol vašeho zadání (IPv4/IPv6) realizujte pomocí GRE tunelů mezi směrovači Rgx a PEinet se statickým směrováním. Internetová konektivita přes GRE je ověřitelné pomocí postupu Test Point E. Varianta zadání - Záložní IPv6 konektivita pro VRF B a Internet konektivita přes SPCore pomocí 6to4/ISATAP (záložka 6to4/ISATAP over SPCore) Mezi směrovači PEinet, Rg1 a Rg2 ve VRF B realizujte IPv6 konektivitu přes IPv4 mrak SPCore pomocí technologie 6to4, resp. ISATAP (záložka 6to4/ISATAP over SPCore ). Aby bylo možné zachovat původní IPv6 adresování serverových segmentů poboček, 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 gateway routeru. Jako koncový bod dynamických tunelů vždy použijte loopback1 příslušného směrovače. Aby měla 6to4/ISATAP konektivita charakter zálohy primární

12 cesty mezi VRF B jednotlivých poboček přes MPLS/VPN, konfigurujte příslušné statické cesty s horším AD než AD cest od protokolu BGP pro MPLS/VPN (principiálně jde o floating static routes). Distribuci informace o záložní cestě z Rgx na RSgx můžete nejjednodušeji realizovat pomocí propagace default route z RgX na RSgx tato cesta bude na RSgx použita pouze v případě, že aktuálně nebude ve směrovací tabulce VRF B cesta s delší shodou prefixu (od MPLS/VPN IBGP). Pro 6to4 transport přes SPCore použijte subnet cccc. Pro ISATAP tunnel interfaces použijte site prefix 2001:EEEE/32. Internetovou konektivitu pro transportní protokol vašeho zadání (IPv4/IPv6) realizujte statickou default cestou přes nexthop loopback1 směrovače PEinet na tunelové rozhraní 6to4/ISATAP. Ověření funkčnosti 6to4 je doporučeno podle Test Point F, ISATAP dle postupu Test Point G.