SZAKDOLGOZAT. Dobos Gábor

SZAKDOLGOZAT

Dobos Gábor

Debrecen 2013

Debreceni Egyetem Informatikai Kar

Border Gateway Protocol elméletben és gyakorlatban

Témavezető:

Készítette:

Dr. Almási Béla

Dobos Gábor

egyetemi docens

mérnök informatikus (BSc)

Tartalomjegyzék 1. Bevezetés ................................................................................................................................ 5 2. BGP alapok ............................................................................................................................. 7 2.1. BGP bemutatása, jellemzői ............................................................................................. 7 2.2. Az internet felé BGP-vel vagy nélküle ........................................................................... 8 2.2.1. Szimpla egykapcsolatú modell ............................................................................. 9 2.2.2. Többes egykapcsolatú modell............................................................................... 9 2.2.3. Szimpla többkapcsolatú modell .......................................................................... 11 2.2.4. Többes többkapcsolatú modell ........................................................................... 12 2.3. BGP működési elve ...................................................................................................... 13 2.3.1. Szomszédsági viszony kialakítása ...................................................................... 13 2.3.2. Útvonal hirdetés és tárolása ................................................................................ 14 2.3.3. Döntési folyamat ................................................................................................. 15 2.3.4. BGP üzenettípusok ............................................................................................ 16 3. BGP konfigurálása és bemutatása gyakorlati példákon ....................................................... 17 3.1. eBGP szomszédság létrehozás ...................................................................................... 18 3.2. Multihop a rendundanciáért .......................................................................................... 20 3.3. Injektálás BGP-be ......................................................................................................... 21 3.3.1. Network parancs ................................................................................................. 22 3.3.2. Redistribute parancs............................................................................................ 23 3.4. iBGP szükségessége ..................................................................................................... 24 3.5 BGP táblái és szomszédságok ellenőrzése ..................................................................... 26 3.6 BGP Backdoor ............................................................................................................... 28 4. Útvonal attribútumok............................................................................................................ 30 4.1. A legjobb útvonal algoritmus ....................................................................................... 30 4.2. Attribútumok fajtái és rövid bemutatásuk .................................................................... 31 4.2.1. NEXT-HOP attribútum ....................................................................................... 32 4.2.2. AS_PATH attribútum ......................................................................................... 32 4.2.3. ORIGIN attribútum ............................................................................................. 33 4.2.4. LOC_PREF attribútum ....................................................................................... 33 4.2.5. ATOMIC_AGGREGATE attribútum ................................................................ 33

4.2.6. AGGREGATOR attribútum ............................................................................... 33 4.2.7. COMMUNITY attribútum.................................................................................. 33 4.2.8. MED attribútum .................................................................................................. 34 5. Összefoglalás ........................................................................................................................ 35 6. Irodalomjegyzék ................................................................................................................... 36 7. Függelék ............................................................................................................................... 37 8. Köszönetnyilvánítás ............................................................................................................. 51

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 e-mail-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

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

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

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

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.

2.2.1. 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ű.

2.2.2. Többes egykapcsolatú modell (Dual homed design)

2. ábra

9

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

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.

2.2.3 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

6. ábra 2.2.4 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

2.3. BGP működési elve 2.3.1. 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

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.

2.3.2. Ú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

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 ADJRIB-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

útvonalak feldolgozásra kerülnek és a megfelelő bejegyzések bekerülnek az ADJ-RIBOUT listába. Fontos viszont, hogy egy útválasztó sosem küld vissza oda útvonalat ahonnan kapta.

2.3.4. 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

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

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

-

ú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 13.0.0.0-s hálózat található. R1 S0/0 interfészének címe 13.0.0.13, míg R3-é 13.0.0.31. Itt konfigurált parancsok a következőek:

R1#

R3#

router bgp 100

router bgp 300

neighbor 13.0.0.31 remote-as 300


19

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

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 34.0.0.0 hálózat van. R3 s0/1 interfészének címe 34.0.1.34, s0/2-é 34.0.2.34, míg a Loopback0-é 3.3.3.3. R4-en az s0/1-hez 34.0.1.43, az s0/2-höz 34.0.2.34-et, míg a Loopback0-hoz 4.4.4.4.-et rendeltem. A konfigurációkhoz szükséges parancsok:

R3#

R4#

ip route 4.4.4.4 255.255.255.255 Serial0/1

ip route 3.3.3.3 255.255.255.255 Serial0/1

ip route 4.4.4.4 255.255.255.255 Serial0/2

ip route 3.3.3.3 255.255.255.255 Serial0/2

R3#

R4#

router bgp 300

router bgp 400



neighbor 4.4.4.4 ebgp-multihop 2


neighbor 4.4.4.4 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

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.

3.3.1. 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 13.0.0.0-s hálózat, míg R3 és R4 között 34.0.0.0-s hálózat van konfigurálva. R3-nak ezeket a hálózatokat hirdetni kell, mert R1-nek nem lesz tudomása a 34.0.0.0 hálózatról, R4-nek pedig a 13.0.0.0-s hálózatról, ha meg nem kapja más routertől. Konkrét parancsok:

R3# network 13.0.0.0 mask 255.255.0.0 network 34.0.0.0 mask 255.255.0.0

22

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 58.0.0.0 hálózatot már R8 hirdeti, másik esetben pedig az R2 és R5 között 25.0.0.0 hálózatot már az R2 hirdeti a hálózatra.

3.3.2. 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 67.0.0.0 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

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 111.111.111.111 /32-es hálózat felé és ezt redistribute static paranccsal hirdettem BGP-be. 3.4. 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

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 13.0.0.0-s hálózat az R1 és R3, a 34.0.0.0-s hálózat az R3 és R4, a 46.0.0.0-s hálózat az R4 és R6, a 68.0.0.0-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 12.0.0.21 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 58.0.0.85 a cél. A legjobb útvonal így már az R1 és R2 közötti 12.0.0.0-s, az R2 és R5 közötti 25.0.0.0-s és az R5 és R8 közötti 58.0.0.0-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

ú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/1es interfészét, hogy kommunikálhasson a külvilággal.

3.5. 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 58.0.0.58 az R5 forgalomirányító s0/0 interfészének címe, a 68.0.0.68 az R6 s0/1-é, a 81.0.0.18 az R10 s0/1-é, míg a 91.0.0.91 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

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 58.0.0.0-s hálózat sorát. Láthatjuk, hogy az 58.0.0.0-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. 58.0.0.0-s hálózatban az egyik a 13.0.0.31, ami az R3-mas router s0/0-s interfészének címe, a másik pedig a 25.0.0.52-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 58.0.0.0-s hálózat felé az irányt és iBGP-n adta tovább R1nek 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 0.0.0.0. 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

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 34.0.0.0, R4 és R6 között 46.0.0.0, R4 és R11 között 41.0.0.0, míg R6 és R11 között 61.0.0.0 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 11.11.11.11.-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 11.11.11.11-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

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 11.11.11.11 mask 255.255.255.255 backdoor parancsot. A 19. ábrán megtekinthető az eredmény és egyben a backdoor előnye.

19. ábra

29

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. 4.1. 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]).

-

1. 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.

-

2. lépés: LOC_PREF attribútumnál vizsgálata. Itt is a nagyobb érték van előnyben részesítve.

-

3. 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.

-

4. lépés: Mennyi az AS_PATH attribútum, azaz hány autonóm rendszeren keresztül halad a csomagunk.

-

5. 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.

-

6. 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

-

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.

-

8. 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.

-

9. lépés: A legrégebb óta ismert eBGP útvonal előnyben részesül.

-

10. lépés: Legalacsonyabb Router Azonosítójú (RID) BGP szomszéd előnyben részesül.

-

11. lépés: Legalacsonyabb IP című szomszéd szintén előnyösebb.

4.2. 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

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])

4.2.1 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 NEXTHOP-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]

4.2.2. 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

4.2.3. 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á.

4.2.4. 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.

4.2.5. 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.

4.2.6. 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.

4.2.7. 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

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]

4.2.8. 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

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

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 642-902, 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 642-832, 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, 1995. http://tools.ietf.org/html/rfc1771

2013. 11. 23.

[7] Y. Rekhter, T. Li, S Hares: A Border Gateway Protocol (BGP-4), RFC4271, 2006. http://tools.ietf.org/html/rfc4271

2013. 11. 23.

Internetes források:

[8] Border Gateway Protocol (BGP) http://www.szabilinux.hu/trendek/trendek5323.html 2013. 11. 21. [9] BGP Case Study http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a00800c95bb.shtml 2013. 11. 27. [10] IP Routing, BGP Best Path Selection Algorithm http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html 2013. 11. 28.

36

7. Függelék

#R1:

interface Serial0/1

!

no ip address

version 12.4

shutdown

service timestamps debug datetime msec

serial restart-delay 0

service timestamps log datetime msec

!

no service password-encryption

interface Serial0/2

!

ip address 12.0.0.12 255.255.0.0

hostname R1


!

!

boot-start-marker

interface Serial0/3

boot-end-marker

no ip address

!

shutdown

!


no aaa new-model

!

memory-size iomem 5

router bgp 100

!

no synchronization

!

bgp log-neighbor-changes

ip cef

network 12.0.0.0 mask 255.255.0.0

no ip domain lookup

network 13.0.0.0 mask 255.255.0.0

ip domain name lab.local


!


!

no auto-summary

ip auth-proxy max-nodata-conns 3

!

ip admission max-nodata-conns 3

no ip http server

!

no ip http secure-server

!

!

interface Serial0/0

ip forward-protocol nd

ip address 13.0.0.13 255.255.0.0

!


!

!

control-plane 37

!

!

!

!

line con 0

ip cef

exec-timeout 0 0

no ip domain lookup

privilege level 15


logging synchronous

!

line aux 0

!

exec-timeout 0 0


privilege level 15


logging synchronous

!

line vty 0 4

!

login

interface Serial0/0

!

no ip address

!

shutdown

end

serial restart-delay 0 ! interface Serial0/1

#R2:

ip address 25.0.0.25 255.255.0.0

!


version 12.4

!


interface Serial0/2


ip address 12.0.0.21 255.255.0.0



!

!

hostname R2

interface Serial0/3

!

no ip address

boot-start-marker

shutdown

boot-end-marker


!

!

!

router bgp 100

no aaa new-model

no synchronization

memory-size iomem 5


38

network 12.0.0.0 mask 255.255.0.0

#R3:

network 25.0.0.0 mask 255.255.0.0

!


version 12.4



no auto-summary


!


no ip http server

!


hostname R3

!

!


boot-start-marker

!

boot-end-marker

!

!

control-plane

!

!

no aaa new-model

!

memory-size iomem 5

line con 0

!

exec-timeout 0 0

!

privilege level 15

ip cef

logging synchronous

no ip domain lookup

line aux 0


exec-timeout 0 0

!

privilege level 15

!

logging synchronous


line vty 0 4


login

!

!

!

!

interface Loopback0

end

ip address 3.3.3.3 255.255.255.255 ! interface Serial0/0 ip address 13.0.0.31 255.255.0.0 serial restart-delay 0

39

!

!

interface Serial0/1

control-plane

ip address 34.0.1.34 255.255.0.0

!


!

!

line con 0

interface Serial0/2

exec-timeout 0 0

ip address 34.0.2.34 255.255.0.0

privilege level 15


logging synchronous

!

line aux 0

interface Serial0/3

exec-timeout 0 0

no ip address

privilege level 15

shutdown

logging synchronous


line vty 0 4

!

login

router bgp 300

!

no synchronization

!


end

network 13.0.0.0 mask 255.255.0.0 network 34.0.0.0 mask 255.255.0.0 neighbor 4.4.4.4 remote-as 400

#R4:


!


version 12.4



no auto-summary


!


no ip http server

!


hostname R4

!

!


boot-start-marker

ip route 4.4.4.4 255.255.255.255 Serial0/1

boot-end-marker

ip route 4.4.4.4 255.255.255.255 Serial0/2

!

!

!

40

no aaa new-model

router eigrp 1000

memory-size iomem 5

network 41.0.0.0 0.0.255.255

!

no auto-summary

!

!

ip cef

router bgp 400

no ip domain lookup

no synchronization



!

network

!

255.255.255.255 backdoor


network 34.0.0.0 mask 255.255.0.0


network 46.0.0.0 mask 255.255.0.0

!


!


interface Loopback0


ip address 4.4.4.4 255.255.255.255


!

no auto-summary

interface Serial0/0

!

ip address 41.0.0.41 255.255.0.0

no ip http server



!

!

interface Serial0/1


ip address 34.0.1.43 255.255.0.0

ip route 3.3.3.3 255.255.255.255 Serial0/1


ip route 3.3.3.3 255.255.255.255 Serial0/2

!

!

interface Serial0/2

!

ip address 34.0.2.43 255.255.0.0

control-plane


!

!

!

interface Serial0/3

line con 0

ip address 46.0.0.46 255.255.0.0

exec-timeout 0 0


privilege level 15

!

logging synchronous

41

11.11.11.11

mask

line aux 0


exec-timeout 0 0


privilege level 15 logging synchronous

!

line vty 0 4

interface Serial0/0

login

ip address 58.0.0.58 255.255.0.0

!


!

!

end

interface Serial0/1 ip address 25.0.0.52 255.255.0.0

#R5:


!

!

version 12.4

interface Serial0/2


no ip address


shutdown



!

!

hostname R5

interface Serial0/3

!

no ip address

boot-start-marker

shutdown

boot-end-marker


!

!

!

router bgp 500

no aaa new-model

no synchronization

memory-size iomem 5


!


!


ip cef

no auto-summary

no ip domain lookup

!


no ip http server

!


!

!

42


!

!

!

!

no aaa new-model

control-plane

memory-size iomem 5

!

!

!

!

line con 0

ip cef

exec-timeout 0 0

no ip domain lookup

privilege level 15


logging synchronous

!

line aux 0

!

exec-timeout 0 0


privilege level 15


logging synchronous

!

line vty 0 4

!

login

interface Serial0/0

!

ip address 67.0.0.67 255.255.0.0

!


end

! interface Serial0/1 ip address 68.0.0.68 255.255.0.0

#R6:


!

!

version 12.4

interface Serial0/2


ip address 61.0.0.61 255.255.0.0




!

!

interface Serial0/3

hostname R6

ip address 46.0.0.64 255.255.0.0

!


boot-start-marker

!

boot-end-marker

router rip

43

version 2

privilege level 15

redistribute bgp 600

logging synchronous

network 67.0.0.0

line vty 0 4

no auto-summary

login

!

!

router bgp 600

!

no synchronization

end

bgp log-neighbor-changes network 46.0.0.0 mask 255.255.0.0 network 61.0.0.0 mask 255.255.0.0

#R7:

network 68.0.0.0 mask 255.255.0.0

!

redistribute rip

version 12.4







no auto-summary

!

!

hostname R7

no ip http server

!


boot-start-marker

!

boot-end-marker


!

!

!

!

no aaa new-model

control-plane

memory-size iomem 5

!

!

!

!

line con 0

ip cef

exec-timeout 0 0

no ip domain lookup

privilege level 15


logging synchronous

!

line aux 0

!

exec-timeout 0 0


44


!

!

control-plane

!

!

interface Serial0/0

!

ip address 67.0.0.76 255.255.0.0

line con 0


exec-timeout 0 0

!

privilege level 15

interface Serial0/1

logging synchronous

no ip address

line aux 0

shutdown

exec-timeout 0 0


privilege level 15

!

logging synchronous

interface Serial0/2

line vty 0 4

no ip address

login

shutdown

!


!

!

end

interface Serial0/3 no ip address shutdown

#R8:


!

!

version 12.4

router rip


version 2


network 67.0.0.0


no auto-summary

!

!

hostname R8

no ip http server

!


boot-start-marker

!

boot-end-marker

ip forward-protocol nd!

!

!

!

45

no aaa new-model


memory-size iomem 5

network 58.0.0.0 mask 255.255.0.0

!

network 68.0.0.0 mask 255.255.0.0

!

network 81.0.0.0 mask 255.255.0.0

ip cef


no ip domain lookup




!


!

no auto-summary


!


no ip http server

!


!

!

interface Serial0/0


ip address 58.0.0.85 255.255.0.0

!


!

!

control-plane

interface Serial0/1

!

ip address 81.0.0.81 255.255.0.0

!


line con 0

!

exec-timeout 0 0

interface Serial0/2

privilege level 15

ip address 68.0.0.86 255.255.0.0

logging synchronous


line aux 0

!

exec-timeout 0 0

interface Serial0/3

privilege level 15

no ip address

logging synchronous

shutdown

line vty 0 4


login

!

!

router bgp 800

!

no synchronization

end

46

#R9:

shutdown

!


version 12.4

!


interface Serial0/2


no ip address


shutdown

!


hostname R9

!

!

interface Serial0/3

boot-start-marker

no ip address

boot-end-marker

shutdown

!


!

!

no aaa new-model

router bgp 800

memory-size iomem 5

no synchronization

!


!

network 91.0.0.0 mask 255.255.0.0

ip cef


no ip domain lookup



no auto-summary

!

!

!

no ip http server




!

!


!

ip

interface Serial0/0

Serial0/0

ip address 91.0.0.91 255.255.0.0

!


!

!

control-plane

interface Serial0/1

!

no ip address

!

47

route

81.0.0.81

255.255.255.255

line con 0

ip cef

exec-timeout 0 0

no ip domain lookup

privilege level 15


logging synchronous

!

line aux 0

!

exec-timeout 0 0


privilege level 15


logging synchronous

!

line vty 0 4

!

login

interface Serial0/0

!

ip address 91.0.0.19 255.255.0.0

!


end

! interface Serial0/1 ip address 81.0.0.18 255.255.0.0

#R10:


!

!

version 12.4

interface Serial0/2


no ip address


shutdown



!

!

hostname R10

interface Serial0/3

!

no ip address

boot-start-marker

shutdown

boot-end-marker


!

!

!

router bgp 800

no aaa new-model

no synchronization

memory-size iomem 5


!

network 81.0.0.0 mask 255.255.0.0

!

network 91.0.0.0 mask 255.255.0.0

48


#R11:


!

no auto-summary

version 12.4

!


no ip http server




!

!


hostname R11

!

!

!

boot-start-marker

control-plane

boot-end-marker

!

!

!

!

line con 0

no aaa new-model

exec-timeout 0 0

memory-size iomem 5

privilege level 15

!

logging synchronous

!

line aux 0

ip cef

exec-timeout 0 0

no ip domain lookup

privilege level 15


logging synchronous

!

line vty 0 4

!

login


!


!

!

end

! interface Loopback0 ip address 11.11.11.11 255.255.255.255 ! interface Serial0/0 ip address 41.0.0.14 255.255.0.0 serial restart-delay 0

49

!

!

interface Serial0/1


no ip address

ip route 111.111.111.111 255.255.255.255

shutdown

Null0

serial restart-delay 0 !

!

interface Serial0/2

!

ip address 61.0.0.16 255.255.0.0

control-plane

serial restart-delay 0 !

!

interface Serial0/3

line con 0

no ip address

exec-timeout 0 0

shutdown

privilege level 15


logging synchronous

!

line aux 0

router eigrp 1000

exec-timeout 0 0

network 11.11.11.11 0.0.0.0

privilege level 15

network 41.0.0.0 0.0.255.255

logging synchronous

no auto-summary

line vty 0 4

!

login

router bgp 1100

!

no synchronization

!


end

network

11.11.11.11

mask

255.255.255.255 network 61.0.0.0 mask 255.255.0.0 redistribute static neighbor 61.0.0.61 remote-as 600 no auto-summary ! no ip http server no ip http secure-server

50

8. Köszönetnyilvánítás Ezúton szeretném megköszönni témavezetőmnek, Dr. Almási Bélának a dolgozatom elkészítése során nyújtott szakmai segítséget és építő jellegű kritikát. Valamint azoknak, akik hozzájárultak munkámhoz.

51

SZAKDOLGOZAT. Dobos Gábor

Recommend Documents