Route reflektory protokolu BGP

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 ………………………………………………………………………... 2 

2. Topologie sítě ……………………………………………………………….. 3 

3. Konfigurace routerů …………………………………………………………. 5 

4. Testování redudance I. ………………………………………………………. 8 

5. Testovani redudance II. ……………………………………………………... 10 

květen 2009 1/12

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 2009 2/12

květen 2009 3/12

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 2009 4/12

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 2009 5/12

3. KONFIGURACE ROUTERŮ 

a) Konfigurace reflective routeru RR1: 

Konfigurace FastEthernetu: 

interface FastEthernet0/0 

ip address 172.0.0.1 255.255.255.0 

b) Konfigurace reflective routeru RR2: 



ip address 172.0.0.2 255.255.255.0 

Konfigurace tunnelu: 

interface Tunnel0 

ip address 10.0.1.1 255.255.255.0 

tunnel source FastEthernet0/0 

tunnel destination 172.0.0.2 

! 


ip address 10.0.4.1 255.255.255.0 



! 


ip address 10.0.2.1 255.255.255.0 



Konfigurace BGP: 

router bgp 60055 

no synchronization 

bgp cluster-id 1 

bgp log-neighbor-changes 

network 10.0.1.0 mask 255.255.255.0 

network 10.0.2.0 mask 255.255.255.0 

network 10.0.4.0 mask 255.255.255.0 

neighbor 10.0.1.2 remote-as 60055 


neighbor 10.0.2.2 route-reflector-client 



no auto-summary 



ip address 10.0.1.2 255.255.255.0 



! 


ip address 10.0.3.1 255.255.255.0 



! 


ip address 10.0.5.1 255.255.255.0 






bgp cluster-id 1 


network 10.0.1.0 mask 255.255.255.0 

network 10.0.3.0 mask 255.255.255.0 

network 10.0.5.0 mask 255.255.255.0 







květen 2009 6/12

c) Konfigurace routeru R3: 



ip address 172.0.0.3 255.255.255.0 

! 


ip address 10.0.6.1 255.255.255.0 



ip address 10.0.2.2 255.255.255.0 



! 


ip address 10.0.3.2 255.255.255.0 







network 10.0.2.0 mask 255.255.255.0 

network 10.0.3.0 mask 255.255.255.0 

network 10.0.6.0 mask 255.255.255.0 




d) Konfigurace routeru R4: 



ip address 172.0.0.4 255.255.255.0 

! 


ip address 10.0.7.1 255.255.255.0 



ip address 10.0.5.2 255.255.255.0 



! 


ip address 10.0.4.2 255.255.255.0 







network 10.0.4.0 mask 255.255.255.0 

network 10.0.5.0 mask 255.255.255.0 

network 10.0.7.0 mask 255.255.255.0 




e) Příkladový výpis BGP tabulky na routeru RR1 : 

BGP table version is 11, local router ID is 172.0.0.1 

Network Next Hop Metric LocPrf Weight Path 

* i10.0.1.0/24 10.0.1.2 0 100 0 i 

*> 0.0.0.0 0 32768 i 

* i10.0.2.0/24 10.0.2.2 0 100 0 i 

*> 0.0.0.0 0 32768 i 

* i10.0.3.0/24 10.0.2.2 0 100 0 i 

*>i 10.0.1.2 0 100 0 i 

* i10.0.4.0/24 10.0.4.2 0 100 0 i 

*> 0.0.0.0 0 32768 i 

* i10.0.5.0/24 10.0.4.2 0 100 0 i 

*>i 10.0.1.2 0 100 0 i 

*>i10.0.6.0/24 10.0.2.2 0 100 0 i 

*>i10.0.7.0/24 10.0.4.2 0 100 0 i 

květen 2009 7/12

Příkladový výpis BGP tabulky na routeru R2 : 



* i10.0.1.0/24 10.0.3.1 0 100 0 i 

*>i 10.0.2.1 0 100 0 i 

* i10.0.2.0/24 10.0.1.1 0 100 0 i 

* i 10.0.2.1 0 100 0 i 

*> 0.0.0.0 0 32768 i 

* i10.0.3.0/24 10.0.3.1 0 100 0 i 

* i 10.0.1.2 0 100 0 i 

*> 0.0.0.0 0 32768 i 

* i10.0.4.0/24 10.0.1.1 0 100 0 i 

*>i 10.0.2.1 0 100 0 i 

*>i10.0.5.0/24 10.0.3.1 0 100 0 i 

* i 10.0.1.2 0 100 0 i 

*> 10.0.6.0/24 0.0.0.0 0 32768 i 

* i10.0.7.0/24 10.0.5.2 0 100 0 i 

*>i 10.0.4.2 0 100 0 i 

f) Příkladový výpis routovací tabulky na routeru RR1 : 

172.0.0.0/24 is subnetted, 1 subnets 

C 172.0.0.0 is directly connected, FastEthernet0/0 


C 10.0.2.0 is directly connected, Tunnel2 

B 10.0.3.0 [200/0] via 10.0.1.2, 00:11:07 


B 10.0.6.0 [200/0] via 10.0.2.2, 00:07:12 

B 10.0.7.0 [200/0] via 10.0.4.2, 00:05:39 


B 10.0.5.0 [200/0] via 10.0.1.2, 00:11:07 

květen 2009 8/12

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 2009 9/12

Příkladové zobrazení BGP tabulky a routovací tabulky na routeru R3: 



*>i10.0.1.0/24 10.0.3.1 0 100 0 i 

*> 10.0.2.0/24 0.0.0.0 0 32768 i 

* i10.0.3.0/24 10.0.3.1 0 100 0 i 

*> 0.0.0.0 0 32768 i 

*>i10.0.4.0/24 10.0.5.2 0 100 0 i 

*>i10.0.5.0/24 10.0.3.1 0 100 0 i 

*> 10.0.6.0/24 0.0.0.0 0 32768 i 

*>i10.0.7.0/24 10.0.5.2 0 100 0 i 






B 10.0.1.0 [200/0] via 10.0.3.1, 00:03:26 


B 10.0.7.0 [200/0] via 10.0.5.2, 00:03:26 

B 10.0.4.0 [200/0] via 10.0.5.2, 00:03:26 

B 10.0.5.0 [200/0] via 10.0.3.1, 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 2009 10/12

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 10.0.6.0 na reflektor RR2 a naopak 

reflektor RR2 nereflektuje síť 10.0.7.0 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íť 10.0.7.0 . 



* i10.0.1.0/24 10.0.1.2 0 100 0 i 

*> 0.0.0.0 0 32768 i 

* i10.0.2.0/24 10.0.2.2 0 100 0 i 

*> 0.0.0.0 0 32768 i 

*>i10.0.3.0/24 10.0.1.2 0 100 0 i 

*> 10.0.4.0/24 0.0.0.0 0 32768 i 

*>i10.0.5.0/24 10.0.1.2 0 100 0 i 

*>i10.0.6.0/24 10.0.2.2 0 100 0 i 

květen 2009 11/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. 



* i10.0.1.0/24 10.0.1.2 0 100 0 i 

*> 0.0.0.0 0 32768 i 

* i10.0.2.0/24 10.0.2.2 0 100 0 i 

*> 0.0.0.0 0 32768 i 

*>i10.0.3.0/24 10.0.1.2 0 100 0 i 

*> 10.0.4.0/24 0.0.0.0 0 32768 i 

*>i10.0.5.0/24 10.0.1.2 0 100 0 i 

*>i10.0.6.0/24 10.0.2.2 0 100 0 i 

* i10.0.8.0/24 10.0.8.2 0 100 0 i 

*> 0.0.0.0 0 32768 i 

*>i10.0.9.0/24 10.0.1.2 0 100 0 i 

* i 10.0.8.2 0 100 0 i 

*>i10.0.10.0/24 10.0.8.2 0 100 0 i 

květen 2009 12/12

Výpis z BGP tabulky z route reflektoru RR5: 



* i10.0.1.0/24 10.0.9.1 0 100 0 i 

*>i 10.0.8.1 0 100 0 i 

*>i10.0.2.0/24 10.0.8.1 0 100 0 i 

*>i10.0.3.0/24 10.0.9.1 0 100 0 i 

*>i10.0.4.0/24 10.0.8.1 0 100 0 i 

*>i10.0.5.0/24 10.0.9.1 0 100 0 i 

*>i10.0.6.0/24 10.0.2.2 0 100 0 i 

*>i10.0.7.0/24 10.0.5.2 0 100 0 i 

* i10.0.8.0/24 10.0.8.1 0 100 0 i 

*> 0.0.0.0 0 32768 i 

* i10.0.9.0/24 10.0.9.1 0 100 0 i 

*> 0.0.0.0 0 32768 i 

* i10.0.10.0/24 10.0.10.2 0 100 0 i 

*> 0.0.0.0 0 32768 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 10.0.7.0 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 2009 13/12

Route reflektory protokolu BGP

Create successful ePaper yourself

Delete template?

Save as template?