SZAKDOLGOZAT. Dobos Gábor

Átírás

1 SZAKDOLGOZAT Dobos Gábor Debrecen 2013

2 Debreceni Egyetem Informatikai Kar Border Gateway Protocol elméletben és gyakorlatban Témavezető: Dr. Almási Béla egyetemi docens Készítette: Dobos Gábor mérnök informatikus (BSc)

3 Tartalomjegyzék 1. Bevezetés BGP alapok BGP bemutatása, jellemzői Az internet felé BGP-vel vagy nélküle Szimpla egykapcsolatú modell Többes egykapcsolatú modell Szimpla többkapcsolatú modell Többes többkapcsolatú modell BGP működési elve Szomszédsági viszony kialakítása Útvonal hirdetés és tárolása Döntési folyamat BGP üzenettípusok BGP konfigurálása és bemutatása gyakorlati példákon ebgp szomszédság létrehozás Multihop a rendundanciáért Injektálás BGP-be Network parancs Redistribute parancs ibgp szükségessége BGP táblái és szomszédságok ellenőrzése BGP Backdoor Útvonal attribútumok A legjobb útvonal algoritmus Attribútumok fajtái és rövid bemutatásuk NEXT-HOP attribútum AS_PATH attribútum ORIGIN attribútum LOC_PREF attribútum ATOMIC_AGGREGATE attribútum... 33

4 AGGREGATOR attribútum COMMUNITY attribútum MED attribútum Összefoglalás Irodalomjegyzék Függelék Köszönetnyilvánítás... 51

5 1. Bevezetés Kezdetben az internetet csak kutatási célok érdekében használták, viszont napjainkra, annyira elterjedt, hogy már rengeteg ember használja, leggyakrabban webböngészés, elektronikus levelezés vagy különböző fájlok átvitele szempontjából. Ahhoz, hogy otthonról a világhálón keresztül csupán egy -t tudjunk küldeni valamelyik ismerősünknek, forgalomirányítás szükséges. Maga a forgalomirányítás történhet statikusan vagy dinamikusan, azaz forgalomirányító protokollok segítségével. Utóbbinak előnye, hogy ha hálózaton történik valamilyen változás, akkor nem szükséges emberi beavatkozás a tökéletes működéshez. Egyetemi tanulmányaim során részletes betekintést nyertem a Bevezetés a Cisco eszközök programozása 1-2 tárgy keretein belül a belső forgalomirányítási protokollok ismereteibe. A tananyag részét nem tartalmazta részletesen valamelyik külső forgalomirányítási protokoll elméleti vagy gyakorlati szinten sem. Felkeltette viszont az érdeklődésem, hogy hogyan is működik egy ilyen külső átjáró protokoll vagyis, miként megy végbe a csomagok irányítása a hálózatok hálózatán, az interneten. A BGP a legelterjedtebb ilyen protokoll manapság, ezért választottam szakdolgozatom témájaként ennek elméleti és gyakorlati bemutatását. Munkám első és utolsó fejezete a Border Gateway Protocoll bemutatásának elméleti része. Az első fejezet elején bemutatom, mi is az a BGP és miben más, mint egy belső forgalomirányítási protokoll, mik a jellemzői és milyen kapcsolódási formában érdemes használni. Aztán leírom, hogyan állítja fel szomszédságát, hol tárolja útvonalait, valamint mely útvonalakat terjeszt, és milyen üzenettípusai vannak. Ezután lévő fejezetben a gyakorlati rész leírása következik, melyhez nagy segítséget nyújtottak a Cisco Press könyvek és tananyagok. GNS3 szoftver segítségével alkottam egy 11 forgalomirányítóból álló topológiát, amely összességében nézve saját ötlet volt, viszont a környezet kisebb részeit, hogy, hogyan is kell felkonfigurálni helyesen ezt a protokollt, milyen problémák adódhatnak, mily módon lehet belső forgalomirányítási protokollokkal összhangba hozni vagy, hogy miként tudjuk ellenőrizni működését, a CCNP Route című könyvből merítettem. Ezekhez a dolgozatom áttekinthetőségére törekedve, a nagy topológiából mindig kiemeltem egy részt, és ábráját igyekeztem közel elhelyezni a leírtakhoz. 5

6 A teljes topológia a fejezet elején a 9. ábrán látható. A forgalomirányítók running-config-jait a függelékben csatoltam Szakdolgozatom utolsó fejezete szintén egy elméleti rész. Leírom, hogy választja ki a BGP a legjobb útvonal algoritmusát és ismertetem, milyen attribútum fajták vannak példákkal, rövid leírással. Munkám megértéséhez egy bizonyos szintű hálózati tudás szükséges. Célom, hogy bemutassam a BGP elméleti jellemzőit, és hogy megvalósítsam a saját topológiámban a Cisco anyagok által leírt alapvető konfigurációkat és problémák megoldásait. 6

7 2. BGP alapok 2.1. BGP bemutatása, jellemzői A Border Gateway Protocoll első verziója 1989 júniusában jelent meg (RFC1105), a második 1990-ben (RFC1163), a harmadik 1991-ben (RFC1267). Ez a harmadik verzió működött az Interneten 1991-től 1994-ig. A BGP negyedik verziója 1995 márciusában készült el, melyet a 1771-es számú RFC dokumentummal adtak közre. Napjainkban, az Interneten ez a 4-es verzió van használatban. [8] A BGP bemutatásakor ismerni kell az autonóm rendszerek fogalmát. Az autonóm rendszer (Autonomous System, későbbiekben AS) közös belső forgalomirányítási stratégiát használó és ugyanazon felügyelet alá tartozó hálózatok összessége. Leggyakrabban egy AS egy internetszolgáltatót (Internet Service Provider, továbbiakban ISP) takar. Minden autonóm rendszert egy egyedi számmal azonosítanak: Autonomous System Number (ASN). Egy AS tartományon belül minden hálózati eszközhöz ez az autonóm rendszer azonosítószám tartozik. Egy AS-en belül a forgalomirányítást a belső átjáró protokollok biztosítják. Ilyen protokollok például: RIPv1, RIPv2, OSPF vagy az EIGRP. Ezeket együttesen belső forgalomirányítási protokolloknak vagy belső átjáró protokolloknak (Interior Gateway Protocoll, későbbiekben IGP) nevezzük. A világháló viszont sok ilyen AS-ből tevődik össze, így szükség van olyan protokollokra is, amely az autonóm rendszerek között képesek a forgalomirányítási információk cseréjére. Ezeket hívjuk külső forgalomirányítási protokolloknak vagy külső átjáró protokolloknak (Exterior Gateway Protocoll, EGP). Mivel az AS-ek különböző felügyelet alá tartoznak, így különböző belső átjáró protokollt futtathatnak, ezért úgy is fogalmazhatunk, hogy egy EGP egyfajta fordítási feladatot lát el, hogy a forgalomirányítási információk megfelelően értelmezve jussanak el minden AS belső hálózatához. Ezek a külső átjáró protokollok általában egy AS határán elhelyezkedő forgalomirányítókon futnak. Napjaink legelterjedtebb külső forgalomirányítási protokollja a Border Gateway Protocoll (BGP). [1] A BGP feladata tehát, hogy hálózatelérési információkat cseréljen, ezáltal megtalálja a legjobb utat az interneten, az adott célállomás felé. Ez a protokoll eltér a fentebb említett belső forgalomirányítási protokolloktól sebességben és megbízhatóságban is. Lassabb, viszont stabilabb az IGP-knél. Lassabb, mert nem reagál azonnal minden változásra. Hatalmas 7

8 forgalomirányítási táblái lehetnek, ezért ha minden változást rögtön figyelembe venne egy akkora hálózaton, mint az internet nagy káoszt okozna. Stabilitása abban rejlik, hogy TCP-t használ a kapcsolat létrehozásához, erről későbbiekben a szomszédsági viszony kialakítása című fejezetben szeretnék részletes tájékoztatást adni. A BGP protokoll házirend alapú, ezáltal képes a kapcsolatok korlátozására. Attribútumai által finoman hangolható, ahogy semelyik más forgalomirányítási protokoll. Egy távolság vektor alapú protokoll és egyben útvonal (vektor) protokoll is. Amikor hirdet egy hálózatot, a BGP hirdetményben megtalálható, hogy melyik autonóm rendszerből indult ki, valamint beleteszi a hirdetménybe azokat az AS számokat is, melyeken a BGP üzenet áthaladt. Ezáltal a hirdetményt megkapó router tudja, hogy az adott célállomás melyik AS-ben, milyen útvonalon és hány autonóm rendszeren keresztül érhető el. Ezeknek a hirdetményeknek a cseréjére egy autonóm rendszeren belül is szükség van, amikor több BGP-t futtató router is megtalálható. Ha ezek a routerek nem cserélnének információkat egymás között BGP által tanult útvonalaikról, akkor nem működne tökéletesen a kommunikáció. Erre a problémára a dolgozatom gyakorlati részénél bővebben kitérek. Abban az esetben, ha a BGP-t futtató routerek ugyanabban az autonóm rendszerben helyezkednek el, akkor belső BGP-ről, azaz ibgp-ről (interior Border Gateway Protocol), ha pedig két különböző AS-ben vannak, akkor külső BGP-ről, vagyis ebgp-ről (external Border Gateway Protocol) beszélünk. [2] 2.2. Az internet felé BGP-vel vagy nélküle Ha az internet felé küldünk egy csomagot egy belső hálózatról, ki kell választanunk a legjobb kilépési pontot. Ehhez a vállalatoknál általában alapértelmezett átjárót vagy BGP-t használnak. Az alapértelmezett útvonallal egy ismeretlen IP címet a határ (core) routerek felé irányítunk, majd ezek a forgalomirányítók továbbküldik az internetszolgáltató címére a csomagot, ami szintén az ISP határ útválasztójához fogja küldeni az általunk küldött adatot. Ez sok munkát nem igényel a vállalaton belüli konfigurálásnál, csupán végig kell hirdetni a kijáratot a vállalaton belül. Itt azonban a vállalat publikus címeit bele kell injektálni a BGPbe, hogy megismerjék az interneten. Másik megoldás az, hogy BGP-t futtatunk több forgalomirányítón, ami jelentős memóriát emésztene. BGP használatának akkor van értelme egy vállalaton belül, ha legalább két internet csatlakozásunk van, így bizonyos útvonalak 8

9 előnybe hozhatóak a többi útvonallal szemben. Tekintsük meg a CCNP Route [2] könyv alapján, milyen internet csatlakozásai lehetnek egy vállalatnak az internet felé és hol előnyös BGP-t vagy más módszert alkalmazni Szimpla egykapcsolatú modell (Single homed design) 1. ábra Egy linkkel kapcsolódunk egy internetszolgáltatóhoz (1. ábra). Egyetlen egy lehetséges kilépési pont létezik az internetre szánt forgalom részére. Nem számít a BGP beállítása, mert csak egy interfész van, amivel elérhetjük az internetet. Itt csökkennek a BGP előnyei. Többnyire két opciót használunk forgalomirányításkor. Egyik, hogy alapértelmezett útvonalat állítunk be, másik pedig, hogy használjuk a BGP-t, de csak egy útvonallal a vállalat publikus interfészének címéhez. Itt véleményem szerint a BGP használata nem célszerű Többes egykapcsolatú modell (Dual homed design) 2. ábra 9

10 Itt kettő vagy több kapcsolatunk van az internet felé (2.-4. ábra), de mindegyik egy internet szolgáltatóhoz kapcsolódik, így többféle útvonalon küldhetjük ki a csomagot a világhálóra. Itt is két lehetőségünk van az útvonal beállításoknál. Egyenlő kapcsolatként kezelhetjük az internet-csatlakozásinkat, illetve előnyben is részesíthetjük az egyiket, míg a másik háttér feladatot lát el. Ha az utóbbit választjuk, akkor úgy kell megadnunk a költségeket, hogy mindig csak az egyik forgalomirányító által hirdetett útvonal legyen a jobb költségű. 3. ábra Ha egy vállalati router két kapcsolaton keresztül kapcsolódik ugyanazon internetszolgáltató két routeréhez (3. ábra), akkor két alapértelmezett útvonalat kell megadnunk, ahol az egyik az ISP egyik IP címét, míg a másik, a másik IP címet használja, a parancs végére pedig az előnyben részesítettnél a jobbik mértéket kell meghatároznunk. BGP használata itt sem a legcélszerűbb megoldás. 4. ábra 10

11 Ha kettő vagy több forgalomirányítón keresztül kapcsolódunk két ISP útválasztóhoz (4. ábra), de a célhálózatunk valamelyik ISP router felé közelebb van, akkor előnyös a BGP használata, ehhez viszont egyeztetni kell az internetszolgáltatóval, hogy melyik célállomások, melyik forgalomirányítójához vannak közelebb. Előzőekben említettem, hogy a BGP protokoll elég sok memóriát használ működéséhez. Ha elkerülhetetlen a BGP használata, de csökkenteni akarjuk a teljes BGP táblafrissítés okozta RAM használatot, kétféle módon tehetjük meg. Egyik, hogy csak alapértelmezett útvonalfrissítést kapunk az internetszolgáltatótól BGP-n keresztül, másik pedig a részleges frissítés megkapása. Ez az alapértelmezett útvonal, ill. azon útvonalak hirdetését jelenti ISP által, amelyeket ezen az ISP-n keresztül hamarabb érünk el. Ennek akkor van haszna, ha az internetszolgáltató egyik forgalomirányítójának ténylegesen jobb rálátása van az adott célra. Ez bekerül a BGP táblába, a többi útvonalat pedig az BGP által küldött alapértelmezett átjárón keresztül éri el a hálózat Szimpla többkapcsolatú modell (Single multihomed design) 5. ábra Ennél a típusnál egy kapcsolatunk van, de kettő vagy több internetszolgáltatóhoz. Hasonlít az előző két típushoz, tehát, ha egy (5. ábra) vagy több (6. ábra) forgalomirányítón keresztül kapcsolódunk két különböző ISP útválasztóihoz, de a célhálózatunk valamelyik ISP router felé közelebb van, akkor előnyös a BGP használata, ehhez viszont tudnunk kell, hogy mely célállomások, melyik forgalomirányítóhoz vannak közelebb. 11

12 6. ábra Többes többkapcsolatú modell (Dual multihomed design) 7. ábra Két vagy több ISP-hez kapcsolódunk, internetszolgáltatónként kettő vagy több kapcsolattal (7.-8. ábra). Jóval redundánsabb, mint a többi típus, ezért szerintem a BGP használata ajánlott. 8. ábra 12

13 2.3. BGP működési elve Szomszédsági viszony kialakítása Ha két forgalomirányító BGP információkat cserél egymás között, akkor szomszédoknak (peereknek) nevezzük őket. Más forgalomirányítási protokollokkal szemben BGP nem fedezi fel automatikusan a szomszédjait. Manuális konfiguráció szükséges a szomszédság kialakításához. Az viszont nem szükséges, hogy a két forgalomirányító közvetlenül kapcsolódjon egymáshoz. Két szomszéd közötti BGP kapcsolat a TCP kapcsolat fölött épül ki. A BGP kapcsolatot egy úgynevezett véges állapotú géppel (Finite State Machine, FSM) prezentálnak. Ennek hat különböző állapota van, melyből az első három maga a TCP kapcsolat kialakítása. (lásd: [3] 108. oldal) - Tétlen (Idle) állapot: Ebben az állapotban az erőforrások lefoglalása, BGP kapcsolat kialakításának megkezdése, ezáltal a TCP kapcsolat kiépítésének kísérlete és figyelése történik. Ezután a forgalomirányító átvált Kapcsolt állapotba. Ha az állapot mégis tétlenben maradna, azt a helytelen konfiguráció, ill. a port állapotának zártsága okozhatja. - Kapcsolt (Connect) állapot: Itt kevés időt tartózkodik a forgalomirányító, csak a TCP kapcsolat kiépülésének befejezésére vár. Ha ez a kapcsolat kiépül, a router egy Nyitás üzenetet küld a másik félnek és Nyitás elküldve állapotba kerül. Ha sikertelen a TCP kapcsolat kialakítása, akkor a forgalomirányító Aktív állapotba kerül. - Aktív (Active) állapot: Ebben az állapotban a router TCP kapcsolat kiépülésével próbálkozik. Ha sikerül a kialakítása a forgalomirányító küld egy Nyitás üzenetet a szomszédjának és Nyitás elküldve állapotba vált. - Nyitás elküldve (Open Sent) állapot: Ha ezt az állapotot látjuk akkor a két szomszéd között, akkor a TCP kapcsolat sikeresen kiépült. A forgalomirányító küldött a párjának egy Nyitás üzenetet és ebben az állapotban várja, hogy partnere válaszoljon neki. Ha a válasz egy Nyitás üzenet formájában megérkezik, Életben tartó (Keepalive) üzenetekben megegyeznek a paraméterekről és router Nyitás megerősítve (Open 13

14 Confirm) állapotba kerül. Viszont ha nem tudnak megegyezni Értesítő (Notification) üzenet kerül kiküldésre és a kapcsolat visszaugrik Aktív állapotba. - Nyitás megerősítve (Open Confirm) állapot: Ha az egyik fél helyes Nyitás üzenetet kapott, akkor ebbe az állapotba kerül és várja a másik féltől az életben tartó (Keepalive) üzenetet hogy a kapcsolat létrejöhessen. Ha ez nem történik meg, mert az időzítő lejárt vagy hiba lépett fel akkor a kapcsolat visszaugrik Tétlen állapotba. - Létrejött kapcsolat (Established) állapot: Utolsó állapot, amikor minden rendben van, a BGP kapcsolat létrejött és a felek Frissítő (Update) üzeneteket küldhetnek egymásnak az útvonal információkról. Hiba esetén Értesítő üzenet kerül kiküldésre és a kapcsolat visszaugrik Tétlen állapotba Útvonal hirdetése és tárolása Miután BGP kapcsolat létrejött a két szomszéd között, a felek Frissítő üzenetek formájában útvonal információkat cserélnek egymással. Minden útvonal egy IP cím és egy hálózati maszk, ami attribútumokkal kiegészítve Frissítő üzenet formájában érkezik és tárolódik le az útválasztó memóriájában. Mivel egy cél felé több útvonal is létezhet, a forgalomirányító kiválaszt egy legjobb útvonalat. Csak ezeket a legjobb útvonalakat hirdeti tovább a szomszédjainak, viszont a többi útvonal megmarad a memóriájában, így elérhetetlenség esetén képes lesz kiválasztani egy újabb legjobb útvonalat az adott célállomás felé. A megkapott útvonalakat a router a Routing Information Bases 3 listájában tárolja ([6]): - ADJ-RIB-IN: Itt azok az utak kerülnek tárolásra, amelyet a forgalomirányító a szomszédjaitól kapott. Szomszédos autonóm rendszerenként található egy-egy ilyen lista a RIB-ben (Routing Information Bases). - ADJ-RIB-OUT: Az útválasztó által terjesztett utak listája. Szintén minden szomszédos AS-hez tartozik egy-egy ilyen lista. - LOC-RIB: Ebben a listában azok az útvonalakat találhatóak, melyeket az adott AS használ. 14

15 2.3.3 Döntési folyamat Ha az forgalomirányító megkapta és letárolta az útvonalakat, ki kell választania a legjobb utat az adott cél felé és tovább kell hirdetnie a szomszédok számára. Ezek az utak a BGP forgalomirányítási táblában is eltárolódnak, ha nem egy másik protokoll által megtanult és kisebb adminisztratív távolsággal rendelkező útvonalról van szó. A döntési folyamat, felelős a helyi és szomszédos autonóm rendszerben szereplő BGP partnereknek szánt hirdetésekért, ill. az útvonal összefogásért és információcsökkentésért. Az egész folyamat 3 különböző részre bontható ([7]): - Preferencia érték számítása: Ez a fázis akkor fut le, ha forgalomirányító Frissítő üzenetet kap a szomszédos autonóm rendszerben található partnerétől, amiben a partner új útvonalat, útvonalcserét vagy kivont útvonalat hirdet. Ez idő alatt az ADJ- RIB-IN lista zárolva van a függvény lefutásának végeztéig. Minden új útvonal esetén a BGP partner meghatározza a preferencia értékét. Ha az útvonal helyi AS-ből származik, akkor a preferencia érték vagy egy bizonyos LOC_PREF attribútum értéke lesz vagy kiszámítódik egy előre konfigurált szabályzási információk alapján. Viszont ha az utat egy szomszédos autonóm rendszerből tanulta a forgalomirányító, akkor az érték egy lokális preferencia érték lesz. Ezt követően egy belső frissítő eljárás folyik, hogy a legjobb útvonal kiválasztásra és hirdetésre kerüljön. - Útvonalválasztás: Itt az ADJ-RIB-IN listában szereplő útvonalak vizsgálata következik. Amennyiben a következő ugrás attribútum ismert, de nincs hozzá útvonala a helyi partnernek, az útvonal kizárásra kerül. Egy adott célhoz, amihez létezik útvonal az ADJ-RIB-IN listában a forgalomirányító kiválasztja a legjobb utat, mely több útvonal esetén a legjobb preferencia értékkel rendelkező útvonal lesz. Ezután ez az útvonal belekerül a LOC-RIB be és lecserélődik a többi, ehhez a célhoz vezető útvonallal. - Útvonal terjesztése: Ha egy adott célhoz vezető útvonal megváltozik, netán új BGP kapcsolat épül ki a BGP terjeszti szomszédjai számára. A LOC-RIB ben lévő 15

16 útvonalak feldolgozásra kerülnek és a megfelelő bejegyzések bekerülnek az ADJ-RIB- OUT listába. Fontos viszont, hogy egy útválasztó sosem küld vissza oda útvonalat ahonnan kapta BGP üzenettípusok - Nyitás (Open) üzenet: Legelőször kiküldött üzenettípus. A felek megegyeznek a kapcsolatot felépítő paraméterekről. - Frissítő (Update) üzenet: A BGP partnerek valamilyen útvonal módosulása, megszűnése vagy megjelenése esetén kiküldött üzenetformátum. - Életben tartó (Keepalive) üzenet: A Frissítő üzenet küldésekor a számláló ki fog nullázódni. Viszont ha az útvonalak nem módosulnak a BGP kapcsolatot Életben tartó üzenetek segítségével tartják fenn a szomszédok egymás között. Két Életben tartó üzenet között a leghosszabb intervallum az időzítő egyharmada lehet, viszont egy másodperctől gyakrabban nem küldhetőek. - Értesítő (Notification) üzenet: Ha egy szomszéd hibát észlel, értesítő üzenet kerül kiküldésre. - Teljes frissítés (Route-refresh) üzenet: Az egyik fél megkéri a másik felet a teljes útválasztási tábla átküldésére. Tartalma egy címcsalád-azonosító, egy címcsaládrészazonosító, amelyek IPv4 esetén 1-esek, valamint egy foglalt 0 értékű bájt. [6] 16

17 3. BGP konfigurálása és bemutatása gyakorlati példákon Ebben a fejezetben, először elméleti szinten, majd az általam alkotott topológián (9. ábra) szeretném bemutatni, hogyan kell felkonfigurálni egy BGP hálózatot. Az ehhez kapcsolódó elméleti rész ismertetése után, minden pontnál kiragadtam a topológiából egy részt, hogy azon keresztül bemutassam, hogyan is néz ki ez a gyakorlatban. Minden pontban csak az oda kapcsolódó parancsokat szemléltetem, a teljes konfigurációt a függelékben tettem közé. Továbbá teszteléseket, show parancsok által mutatott kimeneteket is prezentálok. /16-os prefixű hálózatokat választottam a forgalomirányítók közé. 9. ábra 17

18 3.1. ebgp szomszédság létrehozása Dolgozatom elején már említettem, hogy a BGP szomszédok nem fedezik fel automatikusan egymást, mint más protokolloknál, itt a szomszédság létrehozása manuális konfigurációt igényel. Nézzük is meg mihez van szükség egy BGP szomszédság létrejöttéhez: - fel kell konfigurálni a router saját ASN-jét router bgp ASN paranccsal - minden szomszéd IP-jét és ASN-jét a neighbor szomszéd-ip remote-as ASN paranccsal Ahhoz, hogy a kapcsolat megfelelően működjön következő követelményeknek kell teljesülni: - a helyi forgalomirányítón kiadott router bgp ASN parancsban az ASN-nek egyeznie kell a szomszédos routeren kiadott neighbor szomszéd-ip remote-as ASN parancsban lévő ASN-el - a router azonosítónak (RID) egyedinek kell lennie (RID-et router-id x.x.x.x paranccsal konfigurálhatunk) - ha hitelesítés konfigurálva van a forgalomirányítókon, akkor ezen is át kell jutniuk - TCP kapcsolat létrehozására képesnek kell lenniük a feleknek Egy BGP-t futtató forgalomirányító a neighbor szomszéd-ip remote-as ASN parancsban megadott szomszéd-ip címmel próbál meg TCP kapcsolatot kiépíteni. A helyi IP cím majd az a kimenő interfész lesz, ami ezzel az IP-címmel fizikailag is kapcsolatban van. Nézzük meg miért is ez lesz: - a forgalomirányítónk a neighbor szomszéd-ip remote-as ASN parancsban megadott szomszéd-ip címre küldi a BGP üzeneteket 18

19 - útválasztónk belenéz a saját forgalomirányítási táblájába és keres egy útvonalat ehhez a szomszéd-ip címhez - amelyik útvonal, egyezést mutat ezzel a szomszéd-ip címmel, az ott megadott interfészen keresztül fogjuk elérni ezt a címet - helyi IP-címnek a routerünk, az előző pontban meghatározott interfész címét állítja be - a szomszéd forgalomirányítón a neighbor szomszéd-ip remote-as ASN parancsban erre a címre kell majd hivatkoznunk [2] Nézzük is meg egy példán keresztül a felkonfigurálási parancsokat: 10. ábra A topológiából az R1 és R3-mas router közötti részt választottam (10. ábra). Közöttük a s hálózat található. R1 S0/0 interfészének címe , míg R3-é Itt konfigurált parancsok a következőek: R1# R3# router bgp 100 router bgp 300 neighbor remote-as 300 neighbor remote-as

20 3.2. Multihop a redundanciáért Sokszor csak egy egyszerű útvonal létezik két forgalomirányító között. Ha a kapcsolat megszakad a TCP kapcsolat leépül, és a szomszédság megszűnik, mert TCP kapcsolatnál egy IP cím és egy port szám páros kell egy-egy részről a működéshez és ennek az IP címnek működőnek kell lennie. Az egyik megoldás az, ha több kapcsolatunk is van a két szomszéd között, hogy mindegyiket felkonfiguráljuk a neighbor szomszéd-ip remote-as ASN paranccsal. Azonban van egy jobb megoldás is, a loopback címek használata. Itt mindkét forgalomirányító létrehoz egy loopbacket és ezt használják a TCP kapcsolat kiépítésére. Amíg ez két loopback el fogja érni egymást, TCP kapcsolatuk fenn fog állni. Ennek a konfigurálása a következő: - IP címet kell hozzárendelnünk a két szomszédos router loopbackjeihez - a szimpla szomszédság kialakításánál megadott két parancsot kell alkalmaznunk, a router bgp ASN t és a neighbor szomszéd-ip remote-as ASN t. A szomszéd-ip-nél viszont már a szomszéd loopback IP címét kell megadni. - be kell állítani a forgalomirányítónkon, hogy a loopbackeket használják a szomszédság kialakítására a neighbor szomszéd-loopback-ip update-source loopback# paranccsal. - lehetővé kell tenni egymás loopbackjeinek elérését (pl. egy statikus útvonallal) - konfigurálni kell a neighbor szomszéd-ip multihop # parancsot. Itt a multihop után a # egy egész számot jelöl, ami az ugrásszám lesz. Alapértelmezetten, ebgp kapcsolat esetén az ugrásszám 1-re lesz állítva, ami csak direkt csatlakozás esetén lesz elfogadható. Mivel a két szomszéd loopbackjei által kapcsolódik egymáshoz, így minimum 2-re kell állítanunk az ugrásszámot. [2] 20

21 Ehhez a példa a következő: 11. ábra Topológiából az R3-mas és az R4-es router között hoztam létre ilyen konfigurációt (11. ábra). A két forgalomirányító között hálózat van. R3 s0/1 interfészének címe , s0/2-é , míg a Loopback0-é R4-en az s0/1-hez , az s0/2-höz et, míg a Loopback0-hoz et rendeltem. A konfigurációkhoz szükséges parancsok: R3# R4# ip route Serial0/1 ip route Serial0/1 ip route Serial0/2 ip route Serial0/2 R3# R4# router bgp 300 router bgp 400 neighbor remote-as 400 neighbor remote-as 300 neighbor ebgp-multihop 2 neighbor ebgp-multihop 2 neighbor update-source Loopback0 neighbor update-source Loopback0 3.3 Injektálás BGP-be Egy routernek hirdetnie kell a hozzá kapcsolt hálózatot más BGP szomszédok részére. Ha nem hirdetné, nem tudnának róla más forgalomirányítók, így nem tudnák elérni abban a 21

22 hálózatban lévő célokat. Kétféleképpen tudjuk belehirdetni BGP-be a hálózatokat. Az egyik módszer a network, másik a redistribute parancs használata Network parancs A Border Gateway Protocoll a network parancs segítségével először is összehasonlítást végez, hogy a network parancs után megadott hálózati cím benne van-e a forgalomirányítási táblájában (routing table vagy RIB). Ha benne van, csak akkor hirdeti ezt a hálózatot BGP-n keresztül. Arra figyelnünk kell, hogy csak publikus címeket hirdessünk a BGP segítségével. A network parancs a következőképpen néz ki: network publikus-ip hálózati-cím mask maszk. Általában szükséges kiadni ezt a parancsot, de nem minden esetben. [2] Tekintsük is meg ennek használatát egy topológia részleten (12. ábra) keresztül: 12. ábra Már említettem, hogy R1 és R3 között s hálózat, míg R3 és R4 között s hálózat van konfigurálva. R3-nak ezeket a hálózatokat hirdetni kell, mert R1-nek nem lesz tudomása a hálózatról, R4-nek pedig a s hálózatról, ha meg nem kapja más routertől. Konkrét parancsok: R3# network mask network mask

23 Azért ragadtam ki kicsit nagyobb ábrát, mert érdekesség, hogy nem minden esetben muszáj ezt konfigurálni. R5-n például nem hirdettem a hálózatokat. Az a magyarázat, hogy az R5 és R8 közötti hálózatot már R8 hirdeti, másik esetben pedig az R2 és R5 között hálózatot már az R2 hirdeti a hálózatra Redistribute parancs Ha egy autonóm rendszeren belül belső forgalomirányítási protokoll fut, akkor a network parancs helyett használhatjuk a redistribute parancsot. Cél ugyanaz, belehirdetni a BGP-be azt, amit egy IGP tud, viszont itt is figyelni kell, hogy csak publikus címet hirdessünk BGPvel. A parancs egyszerűen csak annyi, hogy a router bgp ASN kiadása után, kiadunk egy redistribute IGP-név parancsot. [2] Példa alapján: 13. ábra Az 600-as autonóm rendszeren belül RIPv2-t futtatok (13. ábra). Az R6 s0/1, s0/2 és s0/3-mas interfészén ebgp szomszédsági viszony van. R6 és R7 között hálózat van beállítva. Ezt a hálózatot network paranccsal nem hirdettem BGP-be. Ahhoz, hogy más forgalomirányítók elérjék az R7-es routert, az R6-on bele kell fordítani BGP-be, a RIPv2-ben található hálózatot. Viszont az R7-es forgalomirányítónak is el kell érni a külvilágot, ezért a RIPv2-be is bele kell injektálni azokat a hálózatokat, amit R6 ismer BGP által. Ezért R6-on az alap BGP illetve RIPv2 konfiguráción kívül, meg kell adni router bgp 600 után a redistribute rip, míg a router rip után a redistribute bgp 600 parancsokat. 23

24 Statikus utakat a redistribute static paranccsal lehet belehirdetni a BGP-be. Topológiámban (9. ábra) erre is létrehoztam egy példát. A R11-es routeren létrehoztam egy discard útvonalat /32-es hálózat felé és ezt redistribute static paranccsal hirdettem BGP-be ibgp szükségessége A BGP alapok című fejezetnél már említettem, hogy ha egy autonóm rendszeren belül két forgalomirányító is kapcsolódik az internethez, akkor a tökéletes működés érdekében szükséges köztük ibgp kapcsolatot létesíteni. Konfigurálni ugyanúgy kell, mint az ebgp-t, csak a neighbor szomszéd-ip remote-as ASN parancsban az ASN a saját autonóm rendszer száma lesz. Különbség még annyi, hogy ha loopbacken akarjuk létrehozni a szomszédságot ibgp-n keresztül, akkor itt már nem szükséges kiadni az ebgp-multihop parancsot, mert a rendszer nem állítja 1-re a TTL értéket ibgp esetén. Tegyük fel tehát, hogy van két forgalomirányítónk egy AS-n belül és mindkettő ebgp-vel kapcsolódik az internethez. Ha az egyik routernek jobb útvonala van az adott célállomás felé, viszont a másik erről nem tud, mert nincs köztük BGP kapcsolat, de csomagot szeretne küldeni erre a célállomásra, akkor a csomag nem a legjobb útvonalon keresztül fog odaérni a címzetthez.[2] Következő példával (14. ábra) szeretném ezt szemléltetni: 14. ábra 24

25 Az R1 forgalomirányító az R8 router s0/0-s interfészére kíván csomagot küldeni. Lefutattam két tesztet, hogy milyen úton is megy a csomag. Először ha R1 és R2 között nincsen ibgp szomszédsági viszony, majd pedig az egyetlen hiányzó parancs kiadásával létrehoztam a viszonyt. Az alábbi kimenetet kaptam (15. ábra): 15. ábra Első traceroute futtatásánál tehát nincs szomszédsági viszony R1 és R2 között. A s hálózat az R1 és R3, a s hálózat az R3 és R4, a s hálózat az R4 és R6, a s hálózat pedig az R6 és R8 forgalomirányítók között található. Látszik, hogy először a csomag, a topológiában felül, három autonóm rendszeren keresztül megy, míg meg nem érkezik a 800-as AS-be. Ezután kiadtam a hiányzó neighbor remote-as 100 parancsot az R1-en. Az ábrán látszik, hogy létrejött a BGP kapcsolat. Ismét teszteltem, hogy merre fog menni a csomag, ha a cél. A legjobb útvonal így már az R1 és R2 közötti s, az R2 és R5 közötti s és az R5 és R8 közötti s hálózaton keresztül vezet majd a célhoz. Ez egy jobb út lesz a cél felé. Egy másik példát is alkottam a topológiám egy részében a szükségességre. A 14. ábrát szándékosan vágtam úgy ki a teljes topológiából, hogy látszódjon az R8, R9 és R10-es forgalomirányító. R8 itt egy internetes router, amely ebgp kapcsolatban áll R5-el és R6-al is, míg az R10-el ibgp szomszédok, csak úgy, mint R10 az R9-el. A 800-as AS-en belül nem fut semmiféle belső forgalomirányítási protokoll. Az R10-nek még továbbhirdeti az R8 a kapott 25

26 útjait, viszont ha ő semmilyen kapcsolatban nem áll R9-el, hiába van R10 és R9 között ibgp szomszédsági viszony, R10 nem fogja továbbhirdetni az R8-tól kapott utakat, mert az belső BGP kapcsolaton keresztül kapta. Ezért, hogy R9 elérje a külvilágot, létre kellett hozni ibgp szomszédsági viszonyt R8-al, és egy statikus úttal megadni neki, hogy hogyan éri el R8 s0/1- es interfészét, hogy kommunikálhasson a külvilággal BGP táblái és szomszédságok ellenőrzése Eddig bemutattam szimpla ebgp, multihopos ebgp szomszédságokat és az ibgp szükségességét, ill. azt hogy BGP-n is hirdetni kell az adott forgalomirányító által elért hálózatokat. Sok esetben ellenőriznünk is kell, hogy fenn áll-e a szomszédsági viszony és hogy látják-e az autonóm rendszeren kívüli hálózatokat az útválasztók. Legáltalánosabb parancs a BGP szomszédsági állapot ellenőrzésére a show ip bgp summary parancs. Ez a szomszédsági táblát is fogja nekünk mutatni. Topológiámból tekintsük meg a legtöbb szomszéddal rendelkező R8-as forgalomirányító szomszédság tábláját (16. ábra): 16. ábra Visszautalnék a 14. ábrára, melyen megtekinthető az ide tartozó topológia részlet. Az az R5 forgalomirányító s0/0 interfészének címe, a az R6 s0/1-é, a az R10 s0/1-é, míg a az R9 s0/0-é. A 16. ábrán ezeket a szomszédságokat tekinthetjük meg. Fontos még az AS oszlop, amely azt mutatja, hogy a szomszéd melyik autonóm rendszerben található. Legfontosabb viszont a State/PfxRcd, amiben számokat látunk, ami arra utal, hogy a BGP kapcsolat Létrejött (Established) állapotba került, az előtte lévő oszlopban látható idő óta. Ha a szomszédság létrejött, a BGP tábla kulcsszerepet játszik a tanulási és irányítási információk folyamatában. A show ip bgp paranccsal megtekinthetjük a BGP tábla tartalmát. Topológiából az R1 routeren futtattam le a parancsot (17. ábra): 26

27 17. ábra A kimenet első sorában megtekinthetjük a BGP tábla verziószámát és a már többször is említett Router ID-t is. Ha a táblázatra ugrunk, akkor láthatjuk, hogy a network oszlop előtt sok sorban > jel van. Ezek a legjobb útvonalat jelzik. Nézzük meg például az s hálózat sorát. Láthatjuk, hogy az s hálózat két irányba is elérhető. A második oszlopban azt láthatjuk, hogy melyik a következő ugrás, az adott irányba s hálózatban az egyik a , ami az R3-mas router s0/0-s interfészének címe, a másik pedig a es cím, vagyis az R5 s0/1-es interfésze. Utóbbi azért ez egyébként, mert az R2-es router innen tanulta meg az s hálózat felé az irányt és ibgp-n adta tovább R1- nek a következő ugrás címén nem változtatva. Az attribútumok beállításain nem változtattam, így a topológiában (9. ábra) és a traceroute kimenetben (15. ábra) is látszik, hogy a jobbik útvonal az R2-es routeren át vezet. Érdekesség még, hogy a Next Hop oszlopban valamelyik cím Ez annyit jelöl, hogy a hozzá tartozó Network oszlopban lévő hálózat közvetlenül kapcsolódik a forgalomirányító valamelyik interfészéhez. Értelemszerűen akkor ezelőtt lesz a > jel. [4] 27

28 3.6. BGP Backdoor A BGP jellemzésénél és gyakorlatias bemutatásánál sem írtam még Border Gateway Protocoll adminisztratív távolságáról. A külső (external) BGP adminisztratív távolsága (AD) 20, míg a belső (internal) és a helyi (local) BGP adminisztratív távolsága 200. Ha az ebgp-t vesszük figyelembe, akkor ez a 20-as szám jobb, mint egy belső EIGRP 90-es, egy OSPF 110-es vagy egy RIP 120-as AD-ja. Ez forgalomirányítási problémát fog okozni, tekintsük csak meg a topológiám egy részét (18. ábra): 18. ábra Az R4 és R6 között ebgp-t futtatok, csak úgy, mint az R6 és R11 között. Az R4-es és R11-es forgalomirányító között viszont EIGRP működik. R3 és R4 között , R4 és R6 között , R4 és R11 között , míg R6 és R11 között azonosítójú hálózat működik. Fentebb leírtam, hogy az ebgp adminisztratív távolsága 20, ami jobb, mint az belső EIGRP 90-es AD-ja. R11-en konfiguráltam egy logikai interfészt es címmel, amit network parancs segítségével belehirdettem mind az EIGRP-be, mind pedig a BGP protokollba. Ha erre a hálózatra mondjuk az R3 elkezdene csomagot küldeni és ez a csomag az R4-re érkezne, akkor az R4 s0/3-mas interfészén távozna. Magyarázat az, hogy a es hálózatot az R4 megkapja EIGRP-n 90-es adminisztratív távolsággal, de ebgp az R6-os forgalomirányítótól csak 20-as távolsággal látja azt az útvonalat. Egyik megoldás az, hogy a distance bgp external-ad internal-ad local-ad paranccsal megváltoztatjuk az adminisztratív távolságokat, viszont van egy jobb megoldás is erre, a BGP Backdoor. [9] Ez az IGP-t előnyben fogja részesíteni. A parancs csak annyi, hogy a network parancs és a 28

29 szükséges paraméterei után írunk egy backdoor szót. A fentebb leírt dolgokat alapul véve, a topológiám egy részében (18. ábra) ezt is megalkottam. Először lefuttam backdoor nékül a felvázolt folyamatot, majd az R4-en kiadtam a network mask backdoor parancsot. A 19. ábrán megtekinthető az eredmény és egyben a backdoor előnye. 19. ábra 29

30 4. Útvonal attribútumok Már szó volt róla, hogy a Border Gateway Protocol a legjobb útvonal kiválasztásakor nem veszi figyelembe az ugrásszámot, sávszélességet vagy a késleltetést. Ehelyett útvonal attribútumokat használ, amiket egymással összehasonlít, és ezek alapján választja ki a legjobb útvonalat az adott cél felé. Mindegyik attribútum más tényt határoz meg egy adott útvonalról A legjobb útvonal algoritmus Nézzük meg, milyen sorrendben dolgozza fel a BGP az attribútumokat az útvonal választás tekintetében, és dönti el, melyik legyen a legjobb útvonalunk egy adott cél felé ([10]) lépés: Megvizsgálja, hogy a WEIGHT attribútum melyik irányba nagyobb. Ez az útvonal előnyt élvez. Ez Cisco specifikus, így nem minden implementáció használja lépés: LOC_PREF attribútumnál vizsgálata. Itt is a nagyobb érték van előnyben részesítve lépés: LOCALLY INJECTED ROUTES attribútum vizsgálata, azaz honnan tanulta a forgalomirányító az útvonalat. Network paranccsal tanult útvonal előnyösebb a redistribute paranccsal tanult útvonalnál lépés: Mennyi az AS_PATH attribútum, azaz hány autonóm rendszeren keresztül halad a csomagunk lépés: ORIGIN attribútum vizsgálata. ibgp-n, ebgp-n vagy nem meghatározott módon tanulta meg az útválasztó az utat. Prioritási sorrend megegyezik a felsorolási sorrenddel lépés: MED vizsgálata. Egy router hirdeti saját AS-ében, befolyásolva a szomszédos AS-ekbe történő irányítást. 30

31 - 7. lépés: NEIGHBOR TYPE attribútum vizsgálata. Az ebgp szomszédtól tanult útvonal erősebb, mint az ibgp szomszédtól tanult lépés: IGP mérték a NEXT-HOP-hoz. Közvetlen csatlakozásúak vagy valamilyen IGP alapján tanulta meg a forgalomirányító a következő ugrást lépés: A legrégebb óta ismert ebgp útvonal előnyben részesül lépés: Legalacsonyabb Router Azonosítójú (RID) BGP szomszéd előnyben részesül lépés: Legalacsonyabb IP című szomszéd szintén előnyösebb Attribútumok fajtái és rövid bemutatásuk A BGP attribútumait két nagy csoportba sorolhatjuk. Vannak úgynevezett well known, azaz közismert attribútumok, amelyeket elismeri az összes BGP implementáció, valamint vannak az optinal, vagyis az opcionális attribútumok, amelyeket nem minden implementáció fogad el. A közismert attribútumokat is kétféle csoportba oszthatjuk, vannak a mandatory, az-az a kötelező, valamint a discretionary, magyarul tetszés vagy megítélés szerinti attribútumok. Az előbbiek kötelezően szerepelnek, míg az utóbbiak csak lehetségesek a frissítési üzenetekben. A mandatory well-known, vagyis a kötelező közismert attribútumokból három van: NEXT-HOP, AS-PATH és az ORIGIN attribútum. A discretionary well-known, azaz az opcionális közismert attribútumok a LOCAL_PREFERENCE és az ATOMIC_AGGREGATE. Az attribútumok másik nagy csoportját az optinal, vagyis opcionális attribútumokat is két csoportra bonthatjuk. Vannak transitive optional, vagyis továbbítandó opcionális és nontransitive optional, azaz nem továbbítandó opcionális attribútumok. Előfordulhat, hogy az előbbit tartalmazó frissítési üzenetet kap a forgalomirányító és nem ismeri ezt az attribútumot, akkor ugyanúgy kötelező továbbítania, viszont beállít egy bitet a fejben, hogy ő ezt nem tudta feldolgozni. A nem továbbítandó attribútum esetében ilyenkor szimplán eldobás 31

32 következik. Opcionális, továbbítandó attribútum az AGGREGATOR és a COMMUNITY, opcionális, nem továbbítandó pedig a MULTI-EXIT DISCRIMINATOR (röviden: MED). (lásd, néhány példával: [5]) NEXT-HOP attribútum Kötelező, közismert attribútum. Meghatározza, hogy elvileg mely forgalomirányító lesz a következő állomás az adott útvonalon. Azért csak elvileg, mert tegyük fel, hogy van egy B routerünk, amely kap egy hirdetményt A forgalomirányítótól, aminek NEXT_HOP-jában az A forgalomirányító B -hez legközelebb eső interfészének címe fog szerepelni. Ezt a hirdetményt továbbküldi C -nek, ami nem kapcsolódik közvetlenül A -hoz, akkor a NEXT- HOP-ban alapesetben még mindig az A útválasztó interfészének címe lesz. Fontos, hogy az adott útvonal NEXT-HOP-jában szereplő címhez is legyen útvonala annak a forgalomirányítónak, amely az adott útvonalat akarja használni. [9] AS_PATH attribútum Kötelező, közismert attribútum. AS_PATH hossza azon autonóm rendszerek száma, amelyen az útvonal áthalad. Amikor az útvonal hirdetése megkezdődik ez az attribútum üres. Ahogy halad át az AS-eken, az autonóm rendszerek külső forgalomirányítói teszik bele az ASNjüket, ezáltal nyomon követhető, hogy az útvonal mely autonóm rendszereken keresztül halad az adott cél felé. Befolyásolása route-map-pel a set as-path prepend ASN parancs segítségével lehetséges. Ezzel hozzáadhatunk még ASN-eket az attribútumhoz. Bejövő és kimenő útvonalak befolyásolására is alkalmazható egyébként. 32

33 ORIGIN attribútum Kötelező, közismert attribútum. Az útvonal-információ eredetének tárolása a feladata. Ha értéke i, akkor a hálózat az AS-en belül van, ami a legjobb érték az ORIGIN attribútum esetén. Az e érték azt jelenti, hogy a hálózatot külső forgalomirányító protokoll által lett tanulva, ami a második legjobb érték. Ha az ORIGIN attribútum jelzése?, akkor nincs meghatározva forrás, ahonnan az útválasztó tanulta az útvonalat vagy statikus útvonal injektálással jutott el hozzá LOC_PREF attribútum Opcionális, közismert attribútum. Local Preference, azaz lokális preferencia. Nevéből adódóan rájöhetünk, hogy egy autonóm rendszeren belül terjed, vagyis csak ibgp szomszédoknak hirdetődik. Egy AS-n belül meghatározható vele a legjobb kilépési pont egy adott hálózat irányába. Alapértelmezett értéke 100, és a nagyobb érték a jobb ATOMIC_AGGREGATE Opcionális, közismert attribútum. Ahonnan ez származik, ott útvonal összevonás történt, ezért információvesztés keletkezett AGGREGATOR Továbbítandó, opcionális attribútum. Az összevonást elvégzett forgalomirányítóhoz tartozó IP cím és AS szám COMMUNITY Továbbítandóm, opcionális attribútum. A célok között csoportosítást végez, valamilyen közös információ alapján, valamint irányítási döntéseket hozhatóak, ezen csoportokra való 33

34 tekintettel. Irányítási döntések: engedélyezés, előnyben részesítés és injektálás. Néhány előre definiált jól ismert közösség: - no-export: itt nem hirdetünk ebgp szomszédnak, tehát az adott útvonal AS-en belül marad - no-advertise: nem hirdet útvonalat senkinek. - internet: az internet közösség számára hirdeti az útvonalat - local-as: az útvonal nem vihető át a helyi AS-n kívülre [9] MULTI-EXIT DISCRIMINATOR (röviden: MED) Opcionális, nem továbbítandó attribútum. Ha egy autonóm rendszer egy másikkal több ponton kapcsolódik, meghatározza, hogy melyik pontot kell előnyben részesíteni. 34

35 5. Összefoglalás Dolgozatom célja a Border Gateway Protocol bemutatás volt elméleti szinten, valamint gyakorlatban egy általam tervezett topológiában prezentálni az alapvető konfigurálási parancsokat, jellemzőket és hibákat. Elméleti szinten két fejezetben foglalkoztam a BGP-vel. Bemutattam jellemzőit, működési mechanizmusát, üzenettípusait, attribútumait és legjobb útvonal algoritmusát. Ez nem követelt annyira nagy figyelmet, mint a dolgozatom gyakorlati része. Igaz, hogy csak egy fejezetben vázoltam fel a gyakorlati dolgokat, de több koncentrációt igényelt, mint a két elméleti rész. A Cisco-s könyvekben és internetes anyagokban általában egy kis topológián próbálják bemutatni a konfigurálási parancsokat, hibákat, jellemzőket. Én úgy gondoltam munkámban megpróbálkozom egy nagyobb topológián prezentálni több konfigurálási feladatot, hibát. Mivel szakdolgozatom elkészítése előtt nem találkoztam a BGP-vel gyakorlatban, elméleti szinten is csak megemlítés szempontjából és GNS3-mat sem használtam, így örülök, hogy sikerült célkitűzésem teljesíteni, azaz egy 11 útválasztóból álló topológiát működőképesen BGP-vel felkonfiguráli és tapasztalataimat leírni. Összefoglalva az egészet megtapasztaltam, hogy bonyolultabb a Border Gateway Protocol, mint az eddig tanult belső forgalomirányítási protokollok, viszont sokkal jobban finomhangolható, valamint azt (visszaugorva egy kicsit az elméleti részre), hogy a BGP nélkülözhetetlen az internet számára. 35

36 6. Irodalomjegyzék Könyvek: [1] Wendell Odom: CCENT/CCNA ICND1, Official Exam Certification Guide, Second Edition, Cisco Press, 2008 [2] Wendell Odom: CCNP ROUTE , Official Certification Guide, Cisco Press, 2010 [3] Sam Halabi with Danny McPherson: INTERNET ROUTING ARCHITECTURES, Second Edition, Cisco Press, 2000 [4] Kevin Wallace: CCNP TSHOOT , Official Certification Guide, Cisco Press, 2010 [5] Cisco System Learning: Configuring BGP on Cisco Routers, Volume 1, Student Guide, Cisco System, 2005 RFC dokumentumok: [6] Y. Rekhter, T. Li: A Border Gateway Protocol (BGP-4), RFC1771, [7] Y. Rekhter, T. Li, S Hares: A Border Gateway Protocol (BGP-4), RFC4271, Internetes források: [8] Border Gateway Protocol (BGP) [9] BGP Case Study [10] IP Routing, BGP Best Path Selection Algorithm

37 7. Függelék #R1: version 12.4 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption hostname R1 boot-start-marker boot-end-marker no aaa new-model memory-size iomem 5 ip cef no ip domain lookup ip domain name lab.local ip auth-proxy max-nodata-conns 3 ip admission max-nodata-conns 3 interface Serial0/0 ip address interface Serial0/1 no ip address shutdown interface Serial0/2 ip address interface Serial0/3 no ip address shutdown router bgp 100 no synchronization bgp log-neighbor-changes network mask network mask neighbor remote-as 100 neighbor remote-as 300 no auto-summary no ip http server no ip http secure-server ip forward-protocol nd control-plane 37

38 line con 0 exec-timeout 0 0 privilege level 15 logging synchronous line aux 0 exec-timeout 0 0 privilege level 15 logging synchronous line vty 0 4 login end #R2: version 12.4 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption hostname R2 boot-start-marker boot-end-marker no aaa new-model memory-size iomem 5 ip cef no ip domain lookup ip domain name lab.local ip auth-proxy max-nodata-conns 3 ip admission max-nodata-conns 3 interface Serial0/0 no ip address shutdown interface Serial0/1 ip address interface Serial0/2 ip address interface Serial0/3 no ip address shutdown router bgp 100 no synchronization bgp log-neighbor-changes 38

39 network mask network mask neighbor remote-as 100 neighbor remote-as 500 no auto-summary no ip http server no ip http secure-server ip forward-protocol nd control-plane line con 0 exec-timeout 0 0 privilege level 15 logging synchronous line aux 0 exec-timeout 0 0 privilege level 15 logging synchronous line vty 0 4 login end #R3: version 12.4 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption hostname R3 boot-start-marker boot-end-marker no aaa new-model memory-size iomem 5 ip cef no ip domain lookup ip domain name lab.local ip auth-proxy max-nodata-conns 3 ip admission max-nodata-conns 3 interface Loopback0 ip address interface Serial0/0 ip address

40 interface Serial0/1 ip address interface Serial0/2 ip address interface Serial0/3 no ip address shutdown router bgp 300 no synchronization bgp log-neighbor-changes network mask network mask neighbor remote-as 400 neighbor ebgp-multihop 2 neighbor update-source Loopback0 neighbor remote-as 100 no auto-summary no ip http server no ip http secure-server ip forward-protocol nd ip route Serial0/1 ip route Serial0/2 control-plane line con 0 exec-timeout 0 0 privilege level 15 logging synchronous line aux 0 exec-timeout 0 0 privilege level 15 logging synchronous line vty 0 4 login end #R4: version 12.4 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption hostname R4 boot-start-marker boot-end-marker 40

41 no aaa new-model memory-size iomem 5 ip cef no ip domain lookup ip domain name lab.local ip auth-proxy max-nodata-conns 3 ip admission max-nodata-conns 3 interface Loopback0 ip address interface Serial0/0 ip address interface Serial0/1 ip address interface Serial0/2 ip address interface Serial0/3 ip address router eigrp 1000 network no auto-summary router bgp 400 no synchronization bgp log-neighbor-changes network mask backdoor network mask network mask neighbor remote-as 300 neighbor ebgp-multihop 2 neighbor update-source Loopback0 neighbor remote-as 600 no auto-summary no ip http server no ip http secure-server ip forward-protocol nd ip route Serial0/1 ip route Serial0/2 control-plane line con 0 exec-timeout 0 0 privilege level 15 logging synchronous 41

42 line aux 0 exec-timeout 0 0 privilege level 15 logging synchronous line vty 0 4 login end #R5: version 12.4 service timestamps debug datetime msec service timestamps log datetime msec no service password-encryption hostname R5 boot-start-marker boot-end-marker no aaa new-model memory-size iomem 5 ip cef no ip domain lookup ip domain name lab.local ip auth-proxy max-nodata-conns 3 ip admission max-nodata-conns 3 interface Serial0/0 ip address interface Serial0/1 ip address interface Serial0/2 no ip address shutdown interface Serial0/3 no ip address shutdown router bgp 500 no synchronization bgp log-neighbor-changes neighbor remote-as 100 neighbor remote-as 800 no auto-summary no ip http server no ip http secure-server 42