Route reflektory protokolu BGP

Transkript

1 SMĚROVANÉ A PŘEPÍNANÉ SÍTĚ Route reflektory protokolu BGP Jakub WAGNER Michal BODANSKÝ Abstrakt: Tato práce se zabývá testováním technologie route reflektorů na přístrojích firmy Cisco při dodržení podmínek redundance. Dokument obsahuje jak seznámení s teorii a schematickými návrhy, tak výpisy konfigurace routerů a sebrané poznatky a závěry. Klíčová slova: Route reflektor, BGP, ibgp, cluster, redundance. Zadání: Route reflektory protokolu BGP. Zajištění redundance route reflektorů. 1. Teorie Topologie sítě Konfigurace routerů Testování redudance I Testovani redudance II květen /12

2 BGP: 1. TEORIE Protokol BGP (Border Gateway Protocol) je páteřní směrovací protokol, určený především pro k výměně směrovacích informací mezi autonomními systémy, které používají navzájem nezávislé vnitřní směrovací protokoly, například protokol RIP či protokol OSPF. Jako jiné směrovací protokoly zabezpečuje především údržbu směrovacích tabulek, aktualizaci směrů a na základě definované metriky vyhodnocuje dostupnost cílových sítí. Přenos směrovacích informací je umožněn TCP spojením BGP routerů. Dále se tento protokol stará o propagaci optimální cesty s identifikátory autonomních systémů v naplánované cestě. Hlavní atributy cesty přitom jsou: zdrojový router, cesta a následující router. Dělí se dále na ibgp (interní BGP), protokol jenž je určený k výměně informací v rámci jednoho autonomního systému a ebgp (externí BGP), protokol jenž je určený k výměně informací mezi několika autonomními systémy. ROUTE REFLECTOR: Tento router propaguje routy naučené z ibgp (ale i z ebgp jako každý jiný ibgp router) do ostatních ibgp, snižuje množství potřebných BGP sousedských vazeb v autonomním systému (AS), tedy není třeba full mesh - mají sousedství pouze s reflektorem a ne každý s každým. Sousedé RR reflektorů se dělí na klienty a nonklienty. Klienti jsou sousedi, kterí patří do stejného clusteru jako RR, tedy u nich není zapotřebí full mesh (full mesh ibgp vazeb se simuluje), kdežto non-klientů jsou mimo cluster RR, tedy full mesh je nutnost. RR pak příjíma cesty od klientů i non-klientů, kdy cestu od klientů pak vysílá klientům i non-klientům a cestu od non-klintů vysílá jen klientům. Sít může být rozdělena na clustery (ty by mely obsahovat jeden route reflector a klienty, pokud obsahuje více RR musí mít všechny stejné cluster ID) REDUDANCE: Obecně je redundance důležitá jako prostředek ke zvyšování spolehlivosti a odolnosti proti chybám. Pokud má být daná sít redudandní, je nutno zajistit, že v případě kdy jeden router vypadne, je provoz veden přes druhý a nedojde k výpadku sítě, maximálně ke zpomalení předávání informací. Redudance se obvykle neřeší, jsou-li zařízení v přístupové vrstvě, kdy při selhání linky je odříznuto pouze připojené zařízení, ale stabilita zbylé sítě není ovlivněna. V našem případě redudanci tedy zajistíme tím, že každý klient bude mít BGP vazbu na oba reflektory. květen /12

3 květen /12

4 2. TOPOLOGIE SÍTĚ Fyzický model sítě: K zapojení jednoduchého redudandního schématu jsme použili 4 routery firmy Cisco a jeden Cisco switch, kdy routery RR1 a RR2 slouží jako router reflectory a routery R2 a R3 budou klienti route reflectorů. Konfigurace fyzické sítě můžeme najít v kapitole 3. Obr.1 Logický model sítě: K logickému propojení routerů jsme použili komunikace skrze tunely. Aby byla sít postavená redundantně, bylo nutné, aby každý route reflektor byl propojen s oběma klienty v jejich clusteru a také aby byly spojeny oba route reflektory mezi sebou. Oba route reflektory musí být v clusteru se stejným cluster ID. Na obrázku 2 jsou vyznačeny červeně tunelové propojení a jejich jednotlivé adresy a modře jsou označeny jednotlivé interfacy tunelů. Konfigurace tunelů můžeme najít v kapitole 3. Obr.2 květen /12

5 Logický model sítě II: V tomto modelu jsou zaznačeny logické sítě tvořené tunely, jak je popsáno na obrázku 2 a také další dvě sítě (jedná se o fyzické sítě) mezi klienty a pracovními stanicemi. Na všech routerech je nutno nakonfigurovat ibgp (tedy všechny sítě daného routeru, sousedy kam se bude BGP propagovat, nastaveni route reflectorů a jejich klientů) což můžeme najít v kapitole 3. Celá konfigurace pak bude vždy v rámci jednoho autonomního systému. Obr.3 PROBLÉMY: Dle RFC 4456 jsme pochopili, že když se klienti RR považují za součást daného clusteru je nutno na nich konfigurovat cluster ID, je to však omyl, na klientech se žádné cluster ID nenastavuje, route reflektory pak nic nereflektují. ZÁVĚR: Jak můžeme vidět v 3. kapitole v části e) a f), kde jsou zobrazeny příkladné výpisy z BGP tabulek, BGP se nám šíří do všech routerů. To samé lze vidět i na protějších routerech RR2 a R3. Routovací tabulka v 3. kapitole v části g) je taktéž v pořádku, sítě s WS1 a WS2 se napropagovaly správně. květen /12

6 3. KONFIGURACE ROUTERŮ a) Konfigurace reflective routeru RR1: Konfigurace FastEthernetu: interface FastEthernet0/0 ip address b) Konfigurace reflective routeru RR2: Konfigurace FastEthernetu: interface FastEthernet0/0 ip address Konfigurace tunnelu: interface Tunnel0 ip address tunnel destination interface Tunnel1 ip address tunnel destination interface Tunnel2 ip address tunnel destination Konfigurace BGP: router bgp no synchronization bgp cluster-id 1 bgp log-neighbor-changes network mask network mask network mask neighbor remote-as neighbor remote-as neighbor route-reflector-client neighbor remote-as neighbor route-reflector-client no auto-summary Konfigurace tunnelu: interface Tunnel0 ip address tunnel destination interface Tunnel1 ip address tunnel destination interface Tunnel2 ip address tunnel destination Konfigurace BGP: router bgp no synchronization bgp cluster-id 1 bgp log-neighbor-changes network mask network mask network mask neighbor remote-as neighbor remote-as neighbor route-reflector-client neighbor remote-as neighbor route-reflector-client no auto-summary květen /12

7 c) Konfigurace routeru R3: Konfigurace FastEthernetu: interface FastEthernet0/0 ip address interface FastEthernet0/1 ip address Konfigurace tunnelu: interface Tunnel0 ip address tunnel destination interface Tunnel1 ip address tunnel destination Konfigurace BGP: router bgp no synchronization bgp log-neighbor-changes network mask network mask network mask neighbor remote-as neighbor remote-as no auto-summary d) Konfigurace routeru R4: Konfigurace FastEthernetu: interface FastEthernet0/0 ip address interface FastEthernet0/1 ip address Konfigurace tunnelu: interface Tunnel0 ip address tunnel destination interface Tunnel1 ip address tunnel destination Konfigurace BGP: router bgp no synchronization bgp log-neighbor-changes network mask network mask network mask neighbor remote-as neighbor remote-as no auto-summary e) Příkladový výpis BGP tabulky na routeru RR1 : BGP table version is 11, local router ID is Network Next Hop Metric LocPrf Weight Path * i / i * i / i * i / i *>i i * i / i * i / i *>i i *>i / i *>i / i květen /12

8 Příkladový výpis BGP tabulky na routeru R2 : BGP table version is 13, local router ID is Network Next Hop Metric LocPrf Weight Path * i / i *>i i * i / i * i i * i / i * i i * i / i *>i i *>i / i * i i *> / i * i / i *>i i f) Příkladový výpis routovací tabulky na routeru RR1 : /24 is subnetted, 1 subnets C is directly connected, FastEthernet0/ /24 is subnetted, 7 subnets C is directly connected, Tunnel2 B [200/0] via , 00:11:07 C is directly connected, Tunnel0 B [200/0] via , 00:07:12 B [200/0] via , 00:05:39 C is directly connected, Tunnel1 B [200/0] via , 00:11:07 květen /12

9 4. TESTOVANI REDUDANCE I. Abychom otestovali, jestli se jedná opravdu o redundantní model, vyzkoušeli jsme nyní fyzicky odpojit jeden z route reflektorů jak můžeme vidět na obrázku 4. Obr.4 Po odpojení nastala jednominutová odmlka, než bylo detekováno přerušení. Nyní je možno model popsat tak, jak to vidíme na obrázku 5. Obr.5 Při trasovaní cesty mezi WS1 a WS2 před přerušením se pakety z WS2 posílaly zvolenou nejlepší cestou přes R4 do RR2, z něj pak do R3 a nakonec do WS1. Po přerušení a tedy eliminace RR2 se správně začaly pakety přeposílat z R4 do RR1, z něj do R3 a následovně do stanice WS1. květen /12

10 Příkladové zobrazení BGP tabulky a routovací tabulky na routeru R3: BGP table version is 17, local router ID is Network Next Hop Metric LocPrf Weight Path *>i / i *> / i * i / i *>i / i *>i / i *> / i *>i / i /24 is subnetted, 1 subnets C is directly connected, FastEthernet0/ /24 is subnetted, 7 subnets C is directly connected, Tunnel0 C is directly connected, Tunnel1 B [200/0] via , 00:03:26 C is directly connected, FastEthernet0/1 B [200/0] via , 00:03:26 B [200/0] via , 00:03:26 B [200/0] via , 00:27:00 PROBLÉMY: S žádnými většími problémy jsme se nesetkali. ZÁVĚR: Jak můžeme vidět výše, kde jsou zobrazeny příkladové výpisy z BGP tabulek, BGP se nám správně šíří do ostatních routerů a sítě s WS1 a WS2 se nám správně napropagovaly. Routovací tabulka je taky správně pozměněná dle nové situace. květen /12

11 5. TESTOVANI REDUDANCE II. Pro druhý test redundance jsme se rozhodli narušit síť tak, abychom otestovali reflektování mezi reflektory RR1 a RR2, tedy jsme uměle zrušili tunel mezi RR2 a R3 a také tunel mezi RR1 a R4 jak můžeme vidět na obrázku 6. Obr.6 Bohužel jsme zjistili, že reflektor RR1 nereflektuje sít na reflektor RR2 a naopak reflektor RR2 nereflektuje síť na reflektor RR1, hledali jsme tedy příčinu problému. Tabulka BGP na routeru RR1, kde můžeme vidět,že se nám nenašířila síť BGP table version is 21, local router ID is Network Next Hop Metric LocPrf Weight Path * i / i * i / i *>i / i *> / i *>i / i *>i / i květen /12

12 Jak jsme se dočetli v RVC 4456 a dalších dokumentech, není doporučeno konfigurovat více RR na shodné cluster ID, předpokládali jsme tedy, že je chyba právě tady. Zkusili jsme přidat ještě jeden route reflektor, ale nastavili jsme mu cluster ID 2. Fyzicky jsme jej připojili do switche a vytvořili jsme 2 tunely, které jej spojují s RR1 a RR2. Na něj jsme pak ještě přidali router, který bude sloužit jako klient RR5. Myšlenkou bylo nasimulovat reflektování mezi dvěma route reflektory ale nyní s rozdílným cluster ID. Obr.7 Zde můžeme vidět BGP tabulku z RR1. BGP table version is 21, local router ID is Network Next Hop Metric LocPrf Weight Path * i / i * i / i *>i / i *> / i *>i / i *>i / i * i / i *>i / i * i i *>i / i květen /12

13 Výpis z BGP tabulky z route reflektoru RR5: BGP table version is 19, local router ID is Network Next Hop Metric LocPrf Weight Path * i / i *>i i *>i / i *>i / i *>i / i *>i / i *>i / i *>i / i * i / i * i / i * i / i PROBLÉMY: Jak lze vidět na výpisu BGP tabulky na route reflektoru RR1, route reflektor RR2 nám nešíří informace o síti a naopak. ZÁVĚR: Když si porovnáme výpisy BGP tabulek na route reflektoru RR1 před přidáním RR5 a R6 a po přidání těchto routerů, můžeme zjistit, že BGP tabulka se mezi route reflektory s jiným cluster ID šíří správně (route reflektor RR5 má v BGP tabulce správně všechny sítě). Tedy jsme došli k závěru, že pravděpodobně je problém v tom, když dva route reflektory jsou ve stejném clusteru, pak si mezi sebou nešíří správně BGP tabulky. Ve většině publikací o route reflektorech se uvádí, že se nedoporučuje nastavovat stejné cluster ID na více route reflektorech (nicméně v případě zajištění redundance je to nutností), ale nikdy nebylo zdůrazněno, proč? Chybné síření sítí, tak jak jsme se s ním zde setkali, by mohlo být jednou z odpovědí. květen /12