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

Transkript

1 Technologie počítačových sítí - ZS 2015/2016 Případová studie zadání a popis požadavků Petr Grygárek Úvod Případová studie je rozdělena na několik částí, které dohromady tvoří ucelenou síťovou konfiguraci. Každá část je zaměřena na praktické procvičení jedné z technologií určité probírané technologické oblasti. Parametry zadání (volbu konkrétní technologie pro každou část řešení) přidělí specificky jednotlivým skupinám vedoucí cvičení. Požadavky na jednotlivé části jsou specifikovány v náčrtech topologií a také dále v sekci Požadavky řešení. Případová studie je koncipována tak, aby bylo možné procvičit maximum probíraných technologií na minimálním počtu laboratorních zařízení (s respektováním technických omezení konkrétních laboratorních platforem). Proto implementovaná konfigurace neodráží 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. Největším omezením možnosti zadání je v našem případě absence podpory IPv6 ve VRF na L3 přepínači Cisco Catalyst Konfigurace je rozdělena do částí takto: Část 1 - Základní L2 a L3 struktura pobočky, VRF Lite Část 2 - BGP-free Core (IPv4), statické směrování provozu mezi VRF a globálním adresním prostorem Část 3 IPv4 L3 MPLS/VPN s částečným překryvem a dynamickým směrováním PE-CE Část 4 Záložní konektivita přes soustavu AToM pseudowires Část 5 Záložní konektivita přes (IPSec/GRE / DMVPN) Část 6 Implementace IPv6 (6PE/6VPE/6to4/ISATAP/) Termíny odevzdání jednotlivých částí stanoví cvičící. Jednotlivé části budou hodnoceny v rozsahu 0-6 bodů, dalšími 0-6 body bude hodnocena souhrnná dokumentace sítě obsahující veškeré konfigurace a schemata a zpracování požadavků řešení uvedených k jednotlivým částem níže. Při odevzdání příslušné části po termínu (nejpozději však do konce zápočtového týdne) může být přiznáno nejvýše 50% bodů. 3 body navíc může přidělit cvičící za aktivní účast na cvičeních. Ze všech částí je nutné souhrnně získat alespoň 20 bodů. Při hodnocení bude kladen důraz na funkčnost konfigurace příslušné technologie, 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.

2 Poznámka: realizovatelnost všech částí a variant zadání byla předem prakticky ověřena na těchto platformách: Cisco Catalyst 3560, IOS image c3560-ipservicesk9-mz se2.bin Cisco 2801, IOS image c2801-advipservicesk9-mz t1.bin (lze použít také modely 2811, 2901 a 2911) Organizace práce Případovou studii realizují vždy společně trojčlenné skupiny studentů (trojčlenné týmy byly zvoleny z důvodu možnosti implementace společných multipoint komunikačních technologií). Ve výjimečných případech může cvičící sestavit dvojčlennou skupinu a odpovídajícím způsobem pro ni vhodně zvolit parametry zadání. Všechny skupiny pracují nad společnou, částečně předkonfigurovanou infrastrukturou, proto je nutné respektovat předepsané adresní schema (viz obrázky topologií). Pro lepší přehlednost jsou předepsána i čísla VLAN, unikátní v rámci všech skupin. Každý za členů skupiny konfiguruje jednu pobočku síťové infrastruktury firmy připojené na sdílené mraky Service Provider Core a Corporate WAN Core. Náčrtky topologií a schemat pro případovou studii najdete v jednotlivých záložkách (stránkách) souboru TPS-CaseStudy-1516L.pdf. Čísla VLAN a adresní schema jsou voleny tak, aby se nepřekývaly při práci až 3 skupin studentů v jednom cvičení (skupiny označeny g), z nichž každá skupina konfiguruje 3 směrovače a 3 L3 přepínače (označeny Rgr, resp. RSgr, kde g = 1..3 a r=1..3 ). 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) je k dispozici R/O přístup (přes adresu kteréhokoli rozhraní dostupnou v routingu). Použijte uživatelské jméno student,heslo student. 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ě konfigurované jednotlivými skupinami je znázorněna v záložce Overview/str.1 (z ní je rovněž patrné dělení prostředí na jednotlivé skupiny studentů). Principiálně se (v rámci každé skupiny) jedná o model firmy o 3 pobočkách, 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 směrovačem Rgx a L3 přepínač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í. Na RSgx je konfigurován VRF Lite, na Rgx je realizována MPLS/VPN jako primární konektivita pro VRF A a VRF B a IPv6 segmenty v jednotlivých pobočkách. Záložní konektivita pro VRF A je realizována formou pseudowires přes SPCore, pro VRF B formou statických, resp. dynamických IPSec tunelů. Z globálního

3 adresního prostoru každého přepínače RSgx (a z lokální VRF A přemostěné do globálního adresního prostoru) se lze prostřednictvím BGP-free core dostat na Internet. IPv6 je implementován pouze v globálním adresním prostoru RSgx jednotlivých poboček, přivedeném pomocí IC VLAN do VRF V6 na příslušných PE routerech. IPv6 komunikace mezi pobočkami je realizována (dle varianty vašehp zadání) buďto přes WANCore pomocí IPv6 L3 MPLS/VPN, přes SPCore technologií 6to4 nebo ISATAP (zde je konfigurována také IPv6 internetová konektivita) nebo má každá z poboček pouze Inernetovou konektivitu pomocí 6PE přes SPCore (bez možnosti přímé vzájemné IPv6 komunikace mezi pobočkami). V záložce Physical Topology je znázorněna společná topologie vždy pro celý jeden termín cvičení (3 skupiny po 3 studentech). Další záložky popisují zadání jednotlivých částí případové studie, resp. jejich varianty přidělené jednotlivým skupinám. Pro lepší přehlednost jsou v některých případech detaily zadání znázorněny jen pro jeden ze směrovačů skupiny, pro zbývající 2 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í Než začnete cokoli konfigurovat, pouze kreslete. Udělejte si globální náčrt fyzické topologie s určením konkrétnách použitých fyzických zařízení a popisem konkrétních rozhraní, kterými zařízení budete propojovat a tohoto způsobu propojení se stále držte. Pokud je to možné, volte fyzická rozhraní pro propojení prvků logicky, symetricky, aby se dobře pamatovala. Na rozhraní není od věci konfigurovat popisek (příkaz description) na které sousední zařízení a jeho port vede. Na schema fyzické topologie se budete při práci neustále odkazovat, mějte jej při práci stále k dispozici a chraňte si je před znepřehledněním. Dále si dělejte náčrtky logických topologií s příslušnými parametry zvlášť pro jednotlivé části funkcionality. Nesnažte se dostat do jednoho obrázku všechno, nebude přehledný. Každé fyzický síťový prvek 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 vty 0 4! konfigurace Telnet přístupu password c! bez hesla vzdálený přístup Telnetem nefunguje exec-timeout 0! Telnet spojení na CLI management se nebude při vypršení idle timeoutu uzavírat login enable password c! bez hesla pro přístupu do privilegovaného režimu se nelze při připojení Telnetem! do tohoto režimu přepnout! line con 0 exec-timeout 0! konzola nebude při vypršení idle timeoutu vyžadovat opětovné přihlášení

4 login Konzola zařízení je pomalá. Zejména při cut&paste delšího textu může ztrácet znaky. Zprovozněte si co nejdříve inband management přístup na zařízení přes Telent nebo SSH. Nakonfigurujte si nekonečný idle timeout, aby se vám spojení během chvilkové neaktivity nezavirala. Před začátkem konfigurace zařízení se ujistěte, že jeho konfigurace je prázdná (resp. obsahuje default nastavení). Pokud ne, konfiguraci vymažte (erase startup-config) a zařízení rebootujte do stavu s prázdnou konfigurací (reload). U sériových linek nezpomeňte na příkaz clock rate xxx, bez udání taktu linky sériový spoj nepracuje. Technicky se taktovací frekvence zadává jen na straně DCE (dle fyzického otočení kabelu), pokud se však pokusíte zadat taktovací frekvenci na obě strany, není to ke škodě na straně DTE se pouze vypíše varování o ignorování tohoto příkazu. Po zapojení fyzické topologie a povolení portů (no shutdown) je vhodné fyzické zapojení vždy ověřit pomocí CDP nebo LLDP (cdp enable, show cdp neighbors). S konfigurací vždy postupujte po vrstvách, od fyzické vrstvy přes konfiguraci VLAN/MPLS a 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ý process 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, směrovacích 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 (Telnet je rychlejší než sériová konzole, u které může u rozsáhlejších textů přetékat vlivem pomalého odběru znaků vstupní buffer). 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 nejlépe zapnutím logování vašeho terminálu do lokálního souboru (např. na vaši vlastní USB Flash) a příkazy term len 0 (čímž zabráníte stránkování) a show running-config. Technicky lze uložit konfiguraci také do souboru na FLASH příslušného síťového zařízení, nespoléhejte se však, že ji do příštího cvičení ze zařízení někdo nesmaže. Dělejte si konfigurační checkpointy uschování konfigurace v různých fázích řešení, vždy po úspěšném zprovoznění určité funkcionality, abyste se případně mohli vrátit o krok zpět, pokud byste se při konfiguraci vydali zcela špatnou cestou. Pro správnou negociaci parametrů IPSec (resp. DMVPN) je nutné, aby směrovače měly synchronizovaný čas. Kromě manuálního nastavení (clock set ) je možné čas synchronizovat přes protokol NTP:

5 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 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). Rovněž si je dobré uvědomit, že úspěšná odezva na ping ještě neznamená, že paket prochází požadovanou trasou (ze může alespoň částečně pomoci traceroute, v prostředí s MPLS v návaznosti na správné nastavení ttl-propagation na hraničním MPLS routeru).

6 Informace a doporučení k jednotlivým částem řešení Část 1 - Základní L2 a L3 struktura pobočky, VRF Lite Implementujte VLANy a VRF A a B na zařízeních Rg[1-3] a RSg[1-3] a směrování mezi nimi podle schematu pro L3 MPLS/VPN (viz záložka Branch Office Infra) - zatím pouze v rámci jednotlivých poboček skupiny, konektivita mezi pobočkami bude konfigurována v dalších fázích. Do každé ze serverových VLAN VLAN umístěte 3 fyzické porty přepínače RSg[1-3] (jako access port) a volbu portů zdokumentujte. Na L3 přepínači Catalyst nezapomeňte zapnout ip routing a pro podější části případové studie i ipv6 unicast-routing (pro zapnutí IPv6 routingu bude nutný příkaz sdm prefer dual-ipv4-and-ipv6 default a reload) - vypněte Cisco proprietární protokol VTP pro distribuci VLAN: vtp mode off. - pro správnou funkci OSPF harmonizujte default MTU se směrovačem C2800/C2900, možnosti viz zde: - V procesu OSPF je nutné pro ignorování Down bitu nastavovaného při redistribuci BGP-> OSPF konfigurovat capability vrf-lite. Import/export cest mezi VRF vyžaduje konfiguraci BGP procesu i v případě VRF Lite (tj. konfigurace bez přímé návaznosti na MPLS mrak). V tomto případě BGP technicky slouží jako implementační prostředek přenosu informace mezi směrovacími tabulkami příslušných VRF. V konfiguraci BGP nemusí být specifikován žádný skutečný BGP soused, musí však být konfigurovány adresní rodiny pro VRF zúčastněné na i/e a příslušné redistribuce (statických/přímo připojených/igp cest) z a do BGP. Route Targets konfigurujte již teď podle obrázku, budete je využívat v dalších částech případové studie. Aby se serverový subnet propagoval do směrovacího protokolu, musí být aktivní příslušný VLAN interface (SVI). K tomu je nutné, aby příslušná VLAN byla aktivní alespoň na jednom živém (up) přístupovém portu přepínače. Příprava pro části 2 a 3 - MPLS a IGP v SP Core a WAN Core Adresování pro SPCore a WANCore je uvedeno v záložce Physical Topology. Protokol IGP1 a IGP2 v SPCore a WANCore přidělí pro vaši skupinu cvičící. U OSPF/ISIS/BGP 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, clear ip bgp *) 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. Aby se správně vytvořily LDP tunely, musí korespondovat maska podsítě z OSPF a LDP. Správnou propagaci masky podsítě u loopback rozhraní do

7 protokolu OSPF dosáhnete příkazem ip ospf network point-to-point na příslušném loopback rozhraní (v našem případě je všude použito /32, což odpovídá stanardnímu chování i bez nastavení typu OSPF sítě). Na všech fyzických rozhraních uvnitř obou mraků aktivujte MPLS. Kvůli tunelování IPv6 přes SPCore také na všech rozhraních do SPCore navyšte MTU stejná hodnota jako na předkonfigurovaných směračích SPCore. 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-Rg3 umístěny do privátního AS WANCore (65001) a v SPCore provozují EBGP. Do LDP propagujte pouze loopback rozhraní směrovačů v příslušném MPLS mraku. Směrovače Rg1-Rg3 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í mezi mraky SPCore a WANCore je na směrovačích Rg1-Rg3 manuálně znemožněna (příkaz no mpls ldp advertise-labels následovaný mpls ldp advertise-labels for <ACL#>). Pokud si správností konfigurace filtrace LDP mezi MPLS mraky nejste jisti, konzultujte se cvičícím špatná filtrace může způsobit nesprávné chování konfigurací v dalších krocích. Po dokonfigurování směrovacích protokolů pečlivě zkontrolujte směrovací tabulky všechy směrovačů (viditelnost všech loopback rozhraní i spojovacích linek), než přikročíte k dalším krokům. Ujistěte se, že v underlay směrování (na P a mezi P a PE směrovači) máte pouze spojovací linky a loopback rozhraní. Dále zkontrolujte i LDP vazby a obsahy LIB tabulek. Pro správnou funkci tunelování nesmí být do IGP propagován loopback 789 směrovače PEnet simulující Internet. Část 2 - BGP-free Core Pomocí technologie BGP-free core realizujte přístup všech poboček na Internet simulovaný loopbackem AS789 předkonfigurovaného směrovače přes SPCore (viz záložka BGP-free core (IPv4)). 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 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 Internet GW. 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 TTL pro transportní relaci BGP na hodnotu > 1). Na RSgX realizujte lokální přemostění mezi globáním adresním prostorem (VLAN gr0) a serverovým segmentem ve VRF A (VLAN gr10) pomocí statických cest:

8 ip route vrf A <nexthop-in-globlal-routing> global ip route <vrfa-server-segment> vlan gr10 Část 3 L3 MPLS/VPN s částečným překryvem a specifickým PE-CE směrovacím protokolem Realizuje L3 MPLS/VPN přes WANCore mezi VRF A a VRF B v jednotlivých pobočkách (viz záložka IPv4 L3 MPLS/VPN WAN). RD a RT atributy byly konfigurovány již v předchozích krocích. Všechny skupiny použijí jako IGP protokol VRF A mezi CE a PE směrovačem OSPF. Při redistribuci BGP->OSPF nezapomeňte na klíčové slovo subnets. Předkonfigurovaný směrovač PErr v AS bude sloužit jako route reflector (RR) pro vase PE směrovače, jeho konfigurace vypadá takto: router bgp neighbor x.x.x.x neighbor x.x.x.x route-reflector-client Na směrovačích Rg1-Rg3 (RR klientech) bude konfigurace BGP vazby s RR standardní (v AF vpnv4- unicast, nezapomeňte na povolení přenosu extended community). Na cvičícím určeném směrovači Rgx realizujte překryv mezi segment VRF A a B dané pobočky, ověřte konektivitu mezi příslušnými VLAN přímo připojenými do obou VRF na příslušném přepínači RSgx. Poznámka: Jako route reflector by technicky mohl sloužit i směrovač Pwan. Pro lepší pochopení oddělení funkcí control plane a data plane však byla tato funkcionalita umístěna na vyhrazený směrovač PErr

9 Část 4 Záložní konektivita přes systém AToM pseudowires Pro VRF A zprovozněte záložní konektivitu pomocí trojúhelníkové topologie pseudowires (AtoM) propojující příslušné VRF 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žky AToM VRF A nebo AToM VRF A i/e VRF T - variantu zadámí přidělí cvičící). 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. Na trojúhelníku pseudowires zprovozněte protokol RIPv2, do kterého propagujte jednak IP segmenty jednotlivých pseudowires a jednak serverový segment VRF A. 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 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í. V souvislosti s použitím protokolu STP/PVST+ (Cisco default na Catalyst 3560) a s různými čísly VLAN na přípojných linkách do společného AToM pseudowire vzniká problém nekonzistence přemostěných BPDU (Cisco nese v PVST BPDU číslo VLAN formou dodatečného TLV). Pokud Cisco přepínače tento stav ve VLAN detekují, zablokují příslušný port (viz sh spanning-tree vlan gr5/gr6 -> text *PVID_Inc znamená, že VLAN ID TLV je nekonzistentní). Řešením by byla filtrace BPDU vstupujících do AtoM na Rgx (viz např. ale tato možnost není na naší laboratorní platformě podporována. Je proto nutno sáhnout buďto k vypnutí STP na příslušných VLAN (smyčka zde nehrozí), nebo k aplikaci BPDU filtru na (trunk) spoji mezi Rgx a RSgx v naši aplikaci, kde mimo přmosťování do AToM je RgX L3 zařízení, si to lze dovolit. Poznámka: Za přítomnosti konfigurace redistribuce a bez dalšího vylaďování časovačů ustálení směrovacích tabulek při simulaci výpadku deaktivací interface není 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.

10 Varianta přímého propojení AToM do VRF A: Opatření proti směrovacím smyčkám ve VRF A nejsou (oproti záloze konektivity pro vrf B, viz dále) nutné, protože není konfigurována žádná redistribuce segementy 3.g.1.1/24 jsou prostě pouze propagovány paralelně do dvou různých směrovacích protokolů (přes MPLS/VPN ve WANCore a přes strukturu AToM v ISPCore). Na RSgx se přechod na záložní (AToM) konektivitu projeví tak, že cesty do segmentů VRF A ostatních poboček nebudou 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 dočasným zlepšením (snížením) AD protokolu RIP oproti WANCore PE-CE IGP (příkaz distance v příslušné AF konfigurace protokolu RIP). (V případě, že byste provozovali RIPv2 i na PE-CE spoji do WANCore, je nutné depriorizovat backup konektivitu zhoršením AD jen pro konkrétní RIPv2 sousedy.) Při testováni backup scénáře s rozpojením portu Rgx do WANCore není nepřítomnost cest do ostatních poboček VRF A na směrovači Rgx chybou pseudowires vedou přímo do VRF A v RSgx a redistribuce z RIP na záložním trojúhelníku AToM spojů do CE-PE OSPF transportujícím CE cesty na PE do VRF A konfigurována není. Dále na první pohled podivné chování, že se na Rgx, kde je konfigurován i/e mezi VRF a VRF B, při deaktivaci interface do WANCore objeví i cesty do sítí 4.x.x.x, je způsobeno faktem, že v tomto stavu jsou cesty do VRF B přijímány od RIPu přes tunely přes SPCore a ne přes i/e z WANCore ( i/e je netranzitivní) vztahuje se na ně tedy redistribuce z protokolu RIP. Pokud jste blíže neomezili redistribuci OSPF->BGP, budou u VRF A na RSx viditelné i spojovací linky PE- CE (33.x.x.x), navíc jako OSPF inter-area cesty (O IA) na tomto je dobře vidět princip chování OSPF superbackbone. Všimněte si u příslušných LSA 3 (sh ip ospf database summary) nastavení Down bitu (text Downward ). Varianta propojení do AToM přes VRF T: Ve variantě s mezilehlou VRF T vzniká na RSgx v použité verzi IOS navíc 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 VRF T a AToM 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 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í výsledek výpočtu SPF algoritmu (tj. cesty od OSPF kandidující na umístění do směrovací tabulky).

11 Část 5 záložní konektivita přes Service Provider Core (IPSec/GRE / DMVPN) Dle zadání pro vaši skupinu implementujte záložní konektivitu pro VRF B jednou z (non-mpls) VPN technologií přidělené vaší skupině (full mesh IPSec nebo GRE tunelů, resp. DMVPN). Zálohu zkontrolujte 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. Před konfiguraci IPSec mechanismů si nejprve na síťových prvcích (alespoň na směrovačích ukončujících IPSec tunely) zajistěte synchronizovaný čas příkazem clock set v privilegovaném exec režimu. Alternatině můžete konfigurovat NTP. Při vzájemné redistribuci mezi směrovacími protokoly je třeba zamezit cyklení směrovací informace viz návrh u podčástí 5a, případně implementujte vlastní řešení. U každého řešení je doporučováno na závěr stabilitu směrování zkontrolovat příkazem debug ip routing. Část 5a IPSec nebo GRE Záložní konektivitu VRF B konfigurujte pomocí fullmesh 3 statických VPN tunelů, jejich parametry viz schema topologie (záložka IPv4 IPSec/GRE VRF B). Tunely realizujte pomocí tunnel interface s případným odkazem na IPSec profile (příkaz tunnel protection). Přes soustavu tunelů zprovozněte protokol RIPv2 (volitelně po dohodě se cvičícím můžete použít EIGRP). Na Rgx se ujistět, ž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 IBGP a RIP. Pozorování: V některých verzích na dodatečné nastavení AD pod address-family příslušné VRF protokolu RIP nereaguje, nebo reaguje s extrémním zpožěním. Pak je nutné 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. Aby i v případě výpadku linky z Rgx fo WANCore byla zachována konektivita ve VRF B mezi RSgx, je nutná oboustměrná redistribuce RIP<->BGP. Bez dalších opatření by však toto vedlo k zacyklování směrovací informace přes RR, k rozkmitání routing a ke směrovacím smyčkám. Jedna z možností ošetření je následující: 1. Na Rgx z (E)BGP redistribuujte do RIPv2 pouze serverový subnet vlastní pobočky (a pouze ten): ip prefix-list PLTORIP permit <LOCAL_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 M

12 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 (do EBGP k RSgx je šířit musíme). K tomů využijeme filtraci podle 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é z RIPu do BGP nepřevládly nad cestami od RR - jsou totiž lokálne generované a maji tudíž i lepší (default) Weight (a jeste 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 router bgp address-family vpnv4 neighbor rr.rr.rr.rr route-map FROMRR in! pozor, toto ovlivní všechny VRF zvažte, zda to něčemu vadí Pozor: 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). Část 5b DMVPN Záložní konektivitu VRF B konfigurujte pomocí DMVPN dynamické tunely mezi rozhraními loopback1 v ServiceProvider Core. Jedna z poboček (Rg2) bude sloužit jako DMVPN/NHRP hub, ostatní jsou spokes viz záložka IPv4 DMVPN VRF B. Přes DMVPN zprovozněte protokol RIPv2 (volitelně po dohodě se

13 cvičícím můžete použít EIGRP). 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ů viz schema topologie. Ochranu proti cyklení u DMVPN můžete řešit např. podobně jako v části 5a. Část 6 implementace IPv6 (6PE / 6VPE / 6to4/ISATAP] Podle zadání pro vaši skupinu realizujte IPv6 konektivitu mezi pobočkami, resp. s IPv6 Internetem viz záložky 6PE, 6VPE over WANCore, 6to4 over SPCore a ISATAP over SPCore. Na RSgX nelze provozovat IPv6 ve VRF, proto jsou zde serverový segment IPv6 i spojovací linka k Rgx implementována v globálním adresním prostoru. Na straně Rgx je příslušná spojovací linka zakončena ve vrf V6 (viz také záložka Branch Office Infra). Pro aktivaci podpory IPv6 v hardware Cisco Catalyst 3560 použijte příkaz sdm prefer dual-ipv4-and-ipv6 default, po němž musí následovat reload zařízení, vedoucí ke změně struktury použití TCAM. Dále se již toto nastavení udrží. Část 6a - 6PE Realizuje 6PE konektivitu přes SPCore mezi vašimi pobočkami (VRF V6) a předkonfigurovaným směrovačem PEinet. U BGP souseda PEinet nezapomeňte konfigurovat parametr send-label (pakety s jediným labelem v důsledku PHB na penultimate hopu odhalí IPv6 záhlaví, které tento P router neumí zpracovat). Cílem je dosáhnout pouze IPv6 konektivity poboček (VLAN gr30 na RSgx) na simulovaný Internet - vzhledem ke standardnímu mechanismu ochrany proti cyklení směrovací informace v EBGP se informace mezi pobočkami ve stejném AS nepřenese. Směrování mezi PE a CE je statické. Část 6b - 6VPE Pomocí technologie 6VPE realizujte přes WANCore IPv6 MPLS/VPN konektivitu mezi vašimi pobočkami. Směrování PE-CE bude statické, PE router redistribuje statickou cestu do CE segmentu k RR ve WANCore (AF vpnv6). Část 6c/d 6to4 / ISATAP Mezi směrovači PEinet a RgX ve VRF V6 realizujte IPv6 konektivitu pro IPv6 serverové subnety za RSgx přes SPCore pomocí technologie 6to4, resp. ISATAP. 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 dle konvence příslušné technologie. Jako koncový bod dynamických tunelů vždy použijte loopback1 příslušného směrovače. Pro 6to4 transport přes SPCore použijte subnet cccc. Pro ISATAP tunnel interfaces použijte site prefix 2001:EEEE/32. Internetovou konektivitu realizujte statickou default cestou přes nexthop na tunelové rozhraní 6to4/ISATAP směrovače PEinet.