Route reflektory protokolu BGP
Route reflektory protokolu BGP
Route reflektory protokolu BGP
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
SMĚROVANÉ A PŘEPÍNANÉ SÍTĚ<br />
<strong>Route</strong> <strong>reflektory</strong> <strong>protokolu</strong> <strong>BGP</strong><br />
Jakub WAGNER<br />
Michal BODANSKÝ<br />
Abstrakt: Tato práce se zabývá testováním technologie route reflektorů na přístrojích<br />
firmy Cisco při dodržení podmínek redundance. Dokument obsahuje jak seznámení<br />
s teorii a schematickými návrhy, tak výpisy konfigurace routerů a sebrané poznatky a<br />
závěry.<br />
Klíčová slova: <strong>Route</strong> reflektor, <strong>BGP</strong>, i<strong>BGP</strong>, cluster, redundance.<br />
Zadání: <strong>Route</strong> <strong>reflektory</strong> <strong>protokolu</strong> <strong>BGP</strong>. Zajištění redundance route reflektorů.<br />
1. Teorie ………………………………………………………………………... 2<br />
2. Topologie sítě ……………………………………………………………….. 3<br />
3. Konfigurace routerů …………………………………………………………. 5<br />
4. Testování redudance I. ………………………………………………………. 8<br />
5. Testovani redudance II. ……………………………………………………... 10<br />
květen 2009 1/12
<strong>BGP</strong>:<br />
1. TEORIE<br />
Protokol <strong>BGP</strong> (Border Gateway Protocol) je páteřní směrovací protokol, určený především pro<br />
k výměně směrovacích informací mezi autonomními systémy, které používají navzájem<br />
nezávislé vnitřní směrovací protokoly, například protokol RIP či protokol OSPF. Jako jiné<br />
směrovací protokoly zabezpečuje především údržbu směrovacích tabulek, aktualizaci směrů a<br />
na základě definované metriky vyhodnocuje dostupnost cílových sítí. Přenos směrovacích<br />
informací je umožněn TCP spojením <strong>BGP</strong> routerů. Dále se tento protokol stará o propagaci<br />
optimální cesty s identifikátory autonomních systémů v naplánované cestě. Hlavní atributy<br />
cesty přitom jsou: zdrojový router, cesta a následující router.<br />
Dělí se dále na i<strong>BGP</strong> (interní <strong>BGP</strong>), protokol jenž je určený k výměně informací v rámci<br />
jednoho autonomního systému a e<strong>BGP</strong> (externí <strong>BGP</strong>), protokol jenž je určený k výměně<br />
informací mezi několika autonomními systémy.<br />
ROUTE REFLECTOR:<br />
Tento router propaguje routy naučené z i<strong>BGP</strong> (ale i z e<strong>BGP</strong> jako každý jiný i<strong>BGP</strong> router) do<br />
ostatních i<strong>BGP</strong>, snižuje množství potřebných <strong>BGP</strong> sousedských vazeb v autonomním systému<br />
(AS), tedy není třeba full mesh - mají sousedství pouze s reflektorem a ne každý s každým.<br />
Sousedé RR reflektorů se dělí na klienty a nonklienty. Klienti jsou sousedi, kterí patří do<br />
stejného clusteru jako RR, tedy u nich není zapotřebí full mesh (full mesh i<strong>BGP</strong> vazeb se<br />
simuluje), kdežto non-klientů jsou mimo cluster RR, tedy full mesh je nutnost. RR pak příjíma<br />
cesty od klientů i non-klientů, kdy cestu od klientů pak vysílá klientům i non-klientům a cestu<br />
od non-klintů vysílá jen klientům.<br />
Sít může být rozdělena na clustery (ty by mely obsahovat jeden route reflector a klienty,<br />
pokud obsahuje více RR musí mít všechny stejné cluster ID)<br />
REDUDANCE:<br />
Obecně je redundance důležitá jako prostředek ke zvyšování spolehlivosti a odolnosti proti<br />
chybám.<br />
Pokud má být daná sít redudandní, je nutno zajistit, že v případě kdy jeden router vypadne, je<br />
provoz veden přes druhý a nedojde k výpadku sítě, maximálně ke zpomalení předávání<br />
informací. Redudance se obvykle neřeší, jsou-li zařízení v přístupové vrstvě, kdy při selhání<br />
linky je odříznuto pouze připojené zařízení, ale stabilita zbylé sítě není ovlivněna.<br />
V našem případě redudanci tedy zajistíme tím, že každý klient bude mít <strong>BGP</strong> vazbu na oba<br />
<strong>reflektory</strong>.<br />
květen 2009 2/12
květen 2009 3/12
2. TOPOLOGIE SÍTĚ<br />
• Fyzický model sítě:<br />
K zapojení jednoduchého redudandního schématu jsme použili 4 routery firmy Cisco a jeden<br />
Cisco switch, kdy routery RR1 a RR2 slouží jako router reflectory a routery R2 a R3 budou<br />
klienti route reflectorů . Konfigurace fyzické sítě můžeme najít v kapitole 3.<br />
Obr.1<br />
• Logický model sítě:<br />
K logickému propojení routerů jsme použili komunikace skrze tunely. Aby byla sít postavená<br />
redundantně, bylo nutné, aby každý route reflektor byl propojen s oběma klienty v jejich<br />
clusteru a také aby byly spojeny oba route <strong>reflektory</strong> mezi sebou. Oba route <strong>reflektory</strong> musí<br />
být v clusteru se stejným cluster ID.<br />
Na obrázku 2 jsou vyznačeny červeně tunelové propojení a jejich jednotlivé adresy a modře<br />
jsou označeny jednotlivé interfacy tunelů. Konfigurace tunelů můžeme najít v kapitole 3.<br />
Obr.2<br />
květen 2009 4/12
Logický model sítě II:<br />
V tomto modelu jsou zaznačeny logické sítě tvořené tunely, jak je popsáno na obrázku 2 a také<br />
další dvě sítě (jedná se o fyzické sítě) mezi klienty a pracovními stanicemi. Na všech routerech<br />
je nutno nakonfigurovat i<strong>BGP</strong> (tedy všechny sítě daného routeru, sousedy kam se bude <strong>BGP</strong><br />
propagovat, nastaveni route reflectorů a jejich klientů) což můžeme najít v kapitole 3. Celá<br />
konfigurace pak bude vždy v rámci jednoho autonomního systému.<br />
Obr.3<br />
PROBLÉMY:<br />
Dle RFC 4456 jsme pochopili, že když se klienti RR považují za součást daného clusteru je nutno<br />
na nich konfigurovat cluster ID, je to však omyl, na klientech se žádné cluster ID nenastavuje,<br />
route <strong>reflektory</strong> pak nic nereflektují.<br />
ZÁVĚR:<br />
Jak můžeme vidět v 3. kapitole v části e) a f), kde jsou zobrazeny příkladné výpisy z <strong>BGP</strong> tabulek,<br />
<strong>BGP</strong> se nám šíří do všech routerů. To samé lze vidět i na protějších routerech RR2 a R3.<br />
Routovací tabulka v 3. kapitole v části g) je taktéž v pořádku, sítě s WS1 a WS2 se napropagovaly<br />
správně.<br />
květen 2009 5/12
3. KONFIGURACE ROUTERŮ<br />
a) Konfigurace reflective routeru RR1:<br />
Konfigurace FastEthernetu:<br />
interface FastEthernet0/0<br />
ip address 172.0.0.1 255.255.255.0<br />
b) Konfigurace reflective routeru RR2:<br />
Konfigurace FastEthernetu:<br />
interface FastEthernet0/0<br />
ip address 172.0.0.2 255.255.255.0<br />
Konfigurace tunnelu:<br />
interface Tunnel0<br />
ip address 10.0.1.1 255.255.255.0<br />
tunnel source FastEthernet0/0<br />
tunnel destination 172.0.0.2<br />
!<br />
interface Tunnel1<br />
ip address 10.0.4.1 255.255.255.0<br />
tunnel source FastEthernet0/0<br />
tunnel destination 172.0.0.4<br />
!<br />
interface Tunnel2<br />
ip address 10.0.2.1 255.255.255.0<br />
tunnel source FastEthernet0/0<br />
tunnel destination 172.0.0.3<br />
Konfigurace <strong>BGP</strong>:<br />
router bgp 60055<br />
no synchronization<br />
bgp cluster-id 1<br />
bgp log-neighbor-changes<br />
network 10.0.1.0 mask 255.255.255.0<br />
network 10.0.2.0 mask 255.255.255.0<br />
network 10.0.4.0 mask 255.255.255.0<br />
neighbor 10.0.1.2 remote-as 60055<br />
neighbor 10.0.2.2 remote-as 60055<br />
neighbor 10.0.2.2 route-reflector-client<br />
neighbor 10.0.4.2 remote-as 60055<br />
neighbor 10.0.4.2 route-reflector-client<br />
no auto-summary<br />
Konfigurace tunnelu:<br />
interface Tunnel0<br />
ip address 10.0.1.2 255.255.255.0<br />
tunnel source FastEthernet0/0<br />
tunnel destination 172.0.0.1<br />
!<br />
interface Tunnel1<br />
ip address 10.0.3.1 255.255.255.0<br />
tunnel source FastEthernet0/0<br />
tunnel destination 172.0.0.3<br />
!<br />
interface Tunnel2<br />
ip address 10.0.5.1 255.255.255.0<br />
tunnel source FastEthernet0/0<br />
tunnel destination 172.0.0.4<br />
Konfigurace <strong>BGP</strong>:<br />
router bgp 60055<br />
no synchronization<br />
bgp cluster-id 1<br />
bgp log-neighbor-changes<br />
network 10.0.1.0 mask 255.255.255.0<br />
network 10.0.3.0 mask 255.255.255.0<br />
network 10.0.5.0 mask 255.255.255.0<br />
neighbor 10.0.1.1 remote-as 60055<br />
neighbor 10.0.3.2 remote-as 60055<br />
neighbor 10.0.3.2 route-reflector-client<br />
neighbor 10.0.5.2 remote-as 60055<br />
neighbor 10.0.5.2 route-reflector-client<br />
no auto-summary<br />
květen 2009 6/12
c) Konfigurace routeru R3:<br />
Konfigurace FastEthernetu:<br />
interface FastEthernet0/0<br />
ip address 172.0.0.3 255.255.255.0<br />
!<br />
interface FastEthernet0/1<br />
ip address 10.0.6.1 255.255.255.0<br />
Konfigurace tunnelu:<br />
interface Tunnel0<br />
ip address 10.0.2.2 255.255.255.0<br />
tunnel source FastEthernet0/0<br />
tunnel destination 172.0.0.1<br />
!<br />
interface Tunnel1<br />
ip address 10.0.3.2 255.255.255.0<br />
tunnel source FastEthernet0/0<br />
tunnel destination 172.0.0.2<br />
Konfigurace <strong>BGP</strong>:<br />
router bgp 60055<br />
no synchronization<br />
bgp log-neighbor-changes<br />
network 10.0.2.0 mask 255.255.255.0<br />
network 10.0.3.0 mask 255.255.255.0<br />
network 10.0.6.0 mask 255.255.255.0<br />
neighbor 10.0.2.1 remote-as 60055<br />
neighbor 10.0.3.1 remote-as 60055<br />
no auto-summary<br />
d) Konfigurace routeru R4:<br />
Konfigurace FastEthernetu:<br />
interface FastEthernet0/0<br />
ip address 172.0.0.4 255.255.255.0<br />
!<br />
interface FastEthernet0/1<br />
ip address 10.0.7.1 255.255.255.0<br />
Konfigurace tunnelu:<br />
interface Tunnel0<br />
ip address 10.0.5.2 255.255.255.0<br />
tunnel source FastEthernet0/0<br />
tunnel destination 172.0.0.2<br />
!<br />
interface Tunnel1<br />
ip address 10.0.4.2 255.255.255.0<br />
tunnel source FastEthernet0/0<br />
tunnel destination 172.0.0.1<br />
Konfigurace <strong>BGP</strong>:<br />
router bgp 60055<br />
no synchronization<br />
bgp log-neighbor-changes<br />
network 10.0.4.0 mask 255.255.255.0<br />
network 10.0.5.0 mask 255.255.255.0<br />
network 10.0.7.0 mask 255.255.255.0<br />
neighbor 10.0.4.1 remote-as 60055<br />
neighbor 10.0.5.1 remote-as 60055<br />
no auto-summary<br />
e) Příkladový výpis <strong>BGP</strong> tabulky na routeru RR1 :<br />
<strong>BGP</strong> table version is 11, local router ID is 172.0.0.1<br />
Network Next Hop Metric LocPrf Weight Path<br />
* i10.0.1.0/24 10.0.1.2 0 100 0 i<br />
*> 0.0.0.0 0 32768 i<br />
* i10.0.2.0/24 10.0.2.2 0 100 0 i<br />
*> 0.0.0.0 0 32768 i<br />
* i10.0.3.0/24 10.0.2.2 0 100 0 i<br />
*>i 10.0.1.2 0 100 0 i<br />
* i10.0.4.0/24 10.0.4.2 0 100 0 i<br />
*> 0.0.0.0 0 32768 i<br />
* i10.0.5.0/24 10.0.4.2 0 100 0 i<br />
*>i 10.0.1.2 0 100 0 i<br />
*>i10.0.6.0/24 10.0.2.2 0 100 0 i<br />
*>i10.0.7.0/24 10.0.4.2 0 100 0 i<br />
květen 2009 7/12
Příkladový výpis <strong>BGP</strong> tabulky na routeru R2 :<br />
<strong>BGP</strong> table version is 13, local router ID is 172.0.0.3<br />
Network Next Hop Metric LocPrf Weight Path<br />
* i10.0.1.0/24 10.0.3.1 0 100 0 i<br />
*>i 10.0.2.1 0 100 0 i<br />
* i10.0.2.0/24 10.0.1.1 0 100 0 i<br />
* i 10.0.2.1 0 100 0 i<br />
*> 0.0.0.0 0 32768 i<br />
* i10.0.3.0/24 10.0.3.1 0 100 0 i<br />
* i 10.0.1.2 0 100 0 i<br />
*> 0.0.0.0 0 32768 i<br />
* i10.0.4.0/24 10.0.1.1 0 100 0 i<br />
*>i 10.0.2.1 0 100 0 i<br />
*>i10.0.5.0/24 10.0.3.1 0 100 0 i<br />
* i 10.0.1.2 0 100 0 i<br />
*> 10.0.6.0/24 0.0.0.0 0 32768 i<br />
* i10.0.7.0/24 10.0.5.2 0 100 0 i<br />
*>i 10.0.4.2 0 100 0 i<br />
f) Příkladový výpis routovací tabulky na routeru RR1 :<br />
172.0.0.0/24 is subnetted, 1 subnets<br />
C 172.0.0.0 is directly connected, FastEthernet0/0<br />
10.0.0.0/24 is subnetted, 7 subnets<br />
C 10.0.2.0 is directly connected, Tunnel2<br />
B 10.0.3.0 [200/0] via 10.0.1.2, 00:11:07<br />
C 10.0.1.0 is directly connected, Tunnel0<br />
B 10.0.6.0 [200/0] via 10.0.2.2, 00:07:12<br />
B 10.0.7.0 [200/0] via 10.0.4.2, 00:05:39<br />
C 10.0.4.0 is directly connected, Tunnel1<br />
B 10.0.5.0 [200/0] via 10.0.1.2, 00:11:07<br />
květen 2009 8/12
4. TESTOVANI REDUDANCE I.<br />
Abychom otestovali, jestli se jedná opravdu o redundantní model, vyzkoušeli jsme nyní<br />
fyzicky odpojit jeden z route reflektorů jak můžeme vidět na obrázku 4.<br />
Obr.4<br />
Po odpojení nastala jednominutová odmlka, než bylo detekováno přerušení. Nyní je možno<br />
model popsat tak, jak to vidíme na obrázku 5.<br />
Obr.5<br />
Při trasovaní cesty mezi WS1 a WS2 před přerušením se pakety z WS2 posílaly zvolenou<br />
nejlepší cestou přes R4 do RR2, z něj pak do R3 a nakonec do WS1. Po přerušení a tedy<br />
eliminace RR2 se správně začaly pakety přeposílat z R4 do RR1, z něj do R3 a následovně do<br />
stanice WS1.<br />
květen 2009 9/12
Příkladové zobrazení <strong>BGP</strong> tabulky a routovací tabulky na routeru R3:<br />
<strong>BGP</strong> table version is 17, local router ID is 172.0.0.3<br />
Network Next Hop Metric LocPrf Weight Path<br />
*>i10.0.1.0/24 10.0.3.1 0 100 0 i<br />
*> 10.0.2.0/24 0.0.0.0 0 32768 i<br />
* i10.0.3.0/24 10.0.3.1 0 100 0 i<br />
*> 0.0.0.0 0 32768 i<br />
*>i10.0.4.0/24 10.0.5.2 0 100 0 i<br />
*>i10.0.5.0/24 10.0.3.1 0 100 0 i<br />
*> 10.0.6.0/24 0.0.0.0 0 32768 i<br />
*>i10.0.7.0/24 10.0.5.2 0 100 0 i<br />
172.0.0.0/24 is subnetted, 1 subnets<br />
C 172.0.0.0 is directly connected, FastEthernet0/0<br />
10.0.0.0/24 is subnetted, 7 subnets<br />
C 10.0.2.0 is directly connected, Tunnel0<br />
C 10.0.3.0 is directly connected, Tunnel1<br />
B 10.0.1.0 [200/0] via 10.0.3.1, 00:03:26<br />
C 10.0.6.0 is directly connected, FastEthernet0/1<br />
B 10.0.7.0 [200/0] via 10.0.5.2, 00:03:26<br />
B 10.0.4.0 [200/0] via 10.0.5.2, 00:03:26<br />
B 10.0.5.0 [200/0] via 10.0.3.1, 00:27:00<br />
PROBLÉMY:<br />
S žádnými většími problémy jsme se nesetkali.<br />
ZÁVĚR:<br />
Jak můžeme vidět výše, kde jsou zobrazeny příkladové výpisy z <strong>BGP</strong> tabulek, <strong>BGP</strong> se nám<br />
správně šíří do ostatních routerů a sítě s WS1 a WS2 se nám správně napropagovaly.<br />
Routovací tabulka je taky správně pozměněná dle nové situace.<br />
květen 2009 10/12
5. TESTOVANI REDUDANCE II.<br />
Pro druhý test redundance jsme se rozhodli narušit síť tak, abychom otestovali<br />
reflektování mezi <strong>reflektory</strong> RR1 a RR2, tedy jsme uměle zrušili tunel mezi RR2 a R3 a<br />
také tunel mezi RR1 a R4 jak můžeme vidět na obrázku 6.<br />
Obr.6<br />
Bohužel jsme zjistili, že reflektor RR1 nereflektuje sít 10.0.6.0 na reflektor RR2 a naopak<br />
reflektor RR2 nereflektuje síť 10.0.7.0 na reflektor RR1, hledali jsme tedy příčinu problému.<br />
Tabulka <strong>BGP</strong> na routeru RR1, kde můžeme vidět,že se nám nenašířila síť 10.0.7.0 .<br />
<strong>BGP</strong> table version is 21, local router ID is 172.0.0.1<br />
Network Next Hop Metric LocPrf Weight Path<br />
* i10.0.1.0/24 10.0.1.2 0 100 0 i<br />
*> 0.0.0.0 0 32768 i<br />
* i10.0.2.0/24 10.0.2.2 0 100 0 i<br />
*> 0.0.0.0 0 32768 i<br />
*>i10.0.3.0/24 10.0.1.2 0 100 0 i<br />
*> 10.0.4.0/24 0.0.0.0 0 32768 i<br />
*>i10.0.5.0/24 10.0.1.2 0 100 0 i<br />
*>i10.0.6.0/24 10.0.2.2 0 100 0 i<br />
květen 2009 11/12
Jak jsme se dočetli v RVC 4456 a dalších dokumentech, není doporučeno konfigurovat více<br />
RR na shodné cluster ID, předpokládali jsme tedy, že je chyba právě tady. Zkusili jsme přidat<br />
ještě jeden route reflektor, ale nastavili jsme mu cluster ID 2. Fyzicky jsme jej připojili do<br />
switche a vytvořili jsme 2 tunely, které jej spojují s RR1 a RR2. Na něj jsme pak ještě přidali<br />
router, který bude sloužit jako klient RR5. Myšlenkou bylo nasimulovat reflektování mezi<br />
dvěma route <strong>reflektory</strong> ale nyní s rozdílným cluster ID.<br />
Obr.7<br />
Zde můžeme vidět <strong>BGP</strong> tabulku z RR1.<br />
<strong>BGP</strong> table version is 21, local router ID is 172.0.0.1<br />
Network Next Hop Metric LocPrf Weight Path<br />
* i10.0.1.0/24 10.0.1.2 0 100 0 i<br />
*> 0.0.0.0 0 32768 i<br />
* i10.0.2.0/24 10.0.2.2 0 100 0 i<br />
*> 0.0.0.0 0 32768 i<br />
*>i10.0.3.0/24 10.0.1.2 0 100 0 i<br />
*> 10.0.4.0/24 0.0.0.0 0 32768 i<br />
*>i10.0.5.0/24 10.0.1.2 0 100 0 i<br />
*>i10.0.6.0/24 10.0.2.2 0 100 0 i<br />
* i10.0.8.0/24 10.0.8.2 0 100 0 i<br />
*> 0.0.0.0 0 32768 i<br />
*>i10.0.9.0/24 10.0.1.2 0 100 0 i<br />
* i 10.0.8.2 0 100 0 i<br />
*>i10.0.10.0/24 10.0.8.2 0 100 0 i<br />
květen 2009 12/12
Výpis z <strong>BGP</strong> tabulky z route reflektoru RR5:<br />
<strong>BGP</strong> table version is 19, local router ID is 172.0.0.5<br />
Network Next Hop Metric LocPrf Weight Path<br />
* i10.0.1.0/24 10.0.9.1 0 100 0 i<br />
*>i 10.0.8.1 0 100 0 i<br />
*>i10.0.2.0/24 10.0.8.1 0 100 0 i<br />
*>i10.0.3.0/24 10.0.9.1 0 100 0 i<br />
*>i10.0.4.0/24 10.0.8.1 0 100 0 i<br />
*>i10.0.5.0/24 10.0.9.1 0 100 0 i<br />
*>i10.0.6.0/24 10.0.2.2 0 100 0 i<br />
*>i10.0.7.0/24 10.0.5.2 0 100 0 i<br />
* i10.0.8.0/24 10.0.8.1 0 100 0 i<br />
*> 0.0.0.0 0 32768 i<br />
* i10.0.9.0/24 10.0.9.1 0 100 0 i<br />
*> 0.0.0.0 0 32768 i<br />
* i10.0.10.0/24 10.0.10.2 0 100 0 i<br />
*> 0.0.0.0 0 32768 i<br />
PROBLÉMY:<br />
Jak lze vidět na výpisu <strong>BGP</strong> tabulky na route reflektoru RR1, route reflektor RR2 nám nešíří<br />
informace o síti 10.0.7.0 a naopak.<br />
ZÁVĚR:<br />
Když si porovnáme výpisy <strong>BGP</strong> tabulek na route reflektoru RR1 před přidáním RR5 a R6 a<br />
po přidání těchto routerů, můžeme zjistit, že <strong>BGP</strong> tabulka se mezi route <strong>reflektory</strong> s jiným<br />
cluster ID šíří správně (route reflektor RR5 má v <strong>BGP</strong> tabulce správně všechny sítě). Tedy<br />
jsme došli k závěru, že pravděpodobně je problém v tom, když dva route <strong>reflektory</strong> jsou ve<br />
stejném clusteru, pak si mezi sebou nešíří správně <strong>BGP</strong> tabulky. Ve většině publikací o route<br />
reflektorech se uvádí, že se nedoporučuje nastavovat stejné cluster ID na více route<br />
reflektorech (nicméně v případě zajištění redundance je to nutností), ale nikdy nebylo<br />
zdůrazněno, proč? Chybné síření sítí, tak jak jsme se s ním zde setkali, by mohlo být jednou<br />
z odpovědí.<br />
květen 2009 13/12