Informatika | Hálózatok » Szviatovszki Balázs - IP útvonalválasztás

IP útvonalválasztás Szviatovszki Balázs e-mail: Balazs.Szviatovszki@ethericssonse IP mint harmadik réteg IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 2. oldal IP protokoll • Nem megbízható, kapcsolatmentes csomag átviteli protokoll végberendezések között (L3) 0. bit 31. bit version HL type of service total length identification time to live flags protocol 20 by te s fragment offset header checksum source IP address destination IP address options (if any) data . IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 3. oldal Csomagtovábbítás • hop-by-hop, azaz minden router maga dönt • útvonalválasztás cél cím alapján táblázatból • leghosszabb illeszkedő prefix router A 164.4840/24 164.4860/24 164.4870/24 IP útvonalválasztás I. router B router C Táblázat bejegyzés: cím/prefix, next-hop router (IP+if) • 164.4840/22, router A (IP cím + if cím)

164.4850/24 • 164.4850/24, router C (IP cím + if cím) Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 4. oldal Ki is egy IP router? • Egyszerű végberendezés (alap routing) – – – – direkt út a subnet többi gépéhez explicit módon konfigurált egyéb utak ICMP redirect procedúrával megismert utak default út • Bonyolultabb router: – dinamikus útvonalválasztó protokollok, több információ, (lsd. később RIP, OSPF) IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 5. oldal Alap IP útvonalválasztás I. • Direkt út: azonos subneten vagyunk: • Indirekt: nem azonos subneten vagyunk: IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 6. oldal Alap IP útvonalválasztás II. • Mi kell ahhoz, hogy az IP működhessen egy tetszőleges adatkapcsolati réteg, például Ethernet felett ? – Konfigurációs adatok megszerzése – L2 címzés, type azonosítás –

0x800 IP csomag, – 0x806 ARP kérés válasz – ARP: address resolution protocol – Router felfedezés (ICMP) IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 7. oldal Konfigurációs adatok • A végállomásban eleve konfigurálva • BOOTstrap Prot (RFC 951, 1497): – merevlemez nélküli gépek távoli bootolásához, – IP stack konfigurációs info. nélkül – alap konfigurációs adatok megszerzése (boot program, saját IP cím) • Dynamic Host Config. Protocol (RFC 1541, 1533) – BOOTP alap, (együtt tudnak működni) – újrafelhasználható címek kiosztása, – több konfig info. egy un repository-ból IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 8. oldal BOOTP • • • • Server HW cím ROM-ból client IP cím: 0.000 Limitált broadcast címre UDP 67 Broadcast válasz UDP 68: your + server IP Address, • router IP, ha nincs BOOTP server a subneten, és speciális a R •

TFTP-vel boot file letöltése IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 9. oldal ARP • IP cím - Ethernet cím hozzárendelés – a routing tábla kiadta a kimenő interface-t és az IP címet (dest.host, vagy Next-hop router), MAC keretet kell csinálnunk 0. bit 31. bit hardware address type hardware addr. size protocol address type protocol addr. size operation 28 by te s sender Ethernet address sender Ethernet address sender IP address sender IP address target Ethernet address target Ethernet address ??? ??? target IP address IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 10. oldal ARP működés • kérés: – broadcast címre – a cél Ethernet cím helye üresen marad • válasz (a keresett IP cím tulajdonosától): – a keresett Ethernet címmel • ARP cache – a már megtanult Ethernet címek időleges tárolására IP útvonalválasztás I. Szviatovszki Balázs

Balazs.Szviatovszki@ethericssonse 11. oldal ICMP Internet Control Msg. Prot • ICMP Router Discovery: megtudja egy végberendezés a router címét • ICMP Redirect (optimális kimenő router) • ICMP Echo, Echo Reply (egy cím elérhetőségét lehet vele teszteli lsd. ping) • ICMP Error – paraméter probléma, – nem elérhető, – DF bit beállítva és fregmentálni kellene IP útvonalválasztás I. Szviatovszki Balázs – TTL lejárt, Balazs.Szviatovszki@ethericssonse 12. oldal IP opció csemegék • Opció: az IP csomag végén (TLV kódolás) • Nem mindenkinek kell tudnia generálni, de mindenkinek kell tudni processzálni (halott) • Loose source routing, néhány R megjelölve • Strict source routing, csak a megjelölt R-ek használhatók • Record route, beírja a használt R-eket. • Baj: Router teljesítmény csökken, Security (opcióba elrejtett cél) IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 13.

oldal Internet felépítés • AS Autonomous System: csoportosítási egység, amit egy szervezet üzemeltet • AS-en bellüli (Intra-Domain) és az AS-ek közötti (Inter-Domain) útvonalválasztásra különböző protokollokat használnak • IGP: Interior Gateway Protocol (RIP, OSPF) • EGP: Exterior Gateway Protocol (BGP) IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 14. oldal Miért AS ? • AS-re bontással egymástól függetlenül többféle útvonalválasztó protokoll használható • AS-en belül nem kell az egész Internet címtartományát ismerni, • Default free zona: legbikább routerek • Lokális forgalom, topológia változás nem látszik kifelé IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 15. oldal Route Server Internet felépítés ma Default-free szolgáltató NAP/MAE/CIE Közép-szintű szolgáltató Vállalat A IP útvonalválasztás I. Route Server

Internet Exchange Default-free szolgáltató Közép-szintű szolgáltató Dial-up szolgáltató Dial-up szolgáltató Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse Vállalat B 16. oldal Fontosabb terminusok • • • • • • • ISP internet service provider Peering agreement (ISP-k közötti megáll.) NANOG: North American Operators Group NAP: Network Access Point MAE: Metropolitan Area Ethernets CIX: Commercial Internet Exchanges Route Server IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 17. oldal Szintek feladatai • EGP: AS-ek között – Politikai okok, – hatékony ISP együttműködés • IGP: rengeteg féle AS méretre, fajtára más más protokoll az optimális – distance vector, link-state – statikus, dinamikus – egy-utas, több-utas (single path, multipath) IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 18. oldal IGP-k összehasonlítása RIP •

Összehasonlítási kritériumok: – – – – – – – Hálózat topológia (lapos, hierarchikus) Címzés, és útvonal agregálció Útvonal választási kritériumok Konvergencia idő, Stabilitás, Memória, CPU, sávszélesség használat Biztonság IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse OSPF IGRP EIGRP 19. oldal RIPv1 (RFC 1058) • • • • • • • • Distance-vector (Bellman-Ford alg.) Hop szám a költség (16 a végtelen) periodikus tábla terjesztés (30 sec) lekérdezés a feléledési procedúra támogatáshoz nincs VLSM (subnet v. host cím) UDP 520 transzport Végtelenig számlálás lehetséges Hurokképződés lehetséges IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 20. oldal Bellman Ford algoritmus Klasszikus Bellman-Ford dij := i-j él költsége := végtelen , ha nincs él Feltétel: út költség adódik az él költségekből additívan Dij := minimum

költség i és j közt Bellman egyenlet: Routing Táblázat Dii = 0 , minden i -re Dij = mink { dik + Dkj} • Elosztott Bellman-Ford Dikj(t) = k -ból j-be a távolság amit az i csomópont lát t időben Dii = 0 , minden i-re Cél IP cím – távolság – Next-hop IP cím – route change flag (nemrég változott) – időzítők Dij(t) = mink { dik + Dikj(t)} IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 21. oldal Végtelenig számolás • A ból X 5-ről végtelenre változik • Mielőtt ezt B-nek terjesztené, B küld egy 6-os költségű update-et (ami valójában A-n keresztül van) • A 7-re módosítja X költségét • És így szépen elszámolgatnak 16-ig Megoldás: split horizon és poisoned reverse • SP: B nem terjeszti arra vissza a költséget ahonnan hallotta • PR: Minden azonos linken levő routernek (pl D) végtelen utat terjeszt • Körben attól még lehet hurok Részmegoldás: triggered update

• Amint változik a routing tábla, továbbadom (nem tökéletes mo.) • A triggered update alatt beüthet pechesen egy rendes update IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 22. oldal Időzítők • Az update periódus 30 másodperc • ez nem késhet, ha közben kapok mástól én is update-et (szinkronizáció léphet fel) • ha egy útról 180 másodpercig nem jön frissítés, megjelöljük, és egy szemétgyűjtő időzítőt elindítunk, • ha ez lejár, töröljük a bejegyzést IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 23. oldal RIPv2 (RFC 1723) • Kiküszöböli a RIPv1 pár hibáját: – subnet maszk terjesztés, VLSM támogatás – jelszavas védelem az UDP 520-as port zavarása ellen IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 24. oldal IGRP • • • • Cisco szabvány, nem publikus IGRP RIP alap 90 sec frissítés,

összetett költség (sávszél, késleltetés) hop MTU Path Holddown: karanténba kerül a változott út (ez kiküszöböli a hurkokat, de fekete lyukat csinál) • Route poisoning: ha 10%-ot emelkedik a költség, letiltom amíg valaki meg nem erősít IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 25. oldal EIGRP • Ez is minden szomszéd terjesztett adatát tárolja • DUAL Diffuse Update Algorithm – passzív, aktív állapotok – alap passzív, aktívba megy ha elérhetetlen lesz egy cél, ekkor befagyasztja az eddiginél magasabb költséget – lekérdezi a szomszédait, hogy ők tudnak-e jobb utat a célhoz, – ez a kérés a szomszédokat megint csak aktív állapotba billentheti, ami egy fa mentén terjed • Nincs periodikus frissítés • VLSM van prefixekkel IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 26. oldal Új útvonalválasztó protokoll kell • RIP nem volt jó, IGRP,

EIGRP nem szabvány, ezért új protokoll kellet • Fejlesztésénél célok: – – – – – – Jobb metrika több út találás egyenlő súllyal (ha van) hierarchikus kétszintes topológia megkülönböztethető külső és belső utak VLSM támogatás Biztonságosabb protokoll IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 27. oldal OSPFv1 • További elvárások: – 1%-nál kevesebb sávszélességet igényeljen – 2%-nál kevesebb CPU terheltséget jelentsen – 100msec alatt reagáljon a topológia változásokra • OSPFv1 néhány probléma, – MaxAge LSA tovább él, – TOS kihasználatlanság, – Sequence Numbering gondok IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 28. oldal OSPFv2 • Él-állapot leíráson alapuló dinamikus, hierarchikus útvonalválasztó protokoll • Direkt IP fölött fut, transzport protokoll nélkül • Saját megbízható terjesztési protokollt

használ • Az így kapott elosztott adatbázison mindenki maga számol útvonalat, • ugyan azon algoritmus szerint, így hiába csak a következő csomópontnak adom tovább, jó felé megy (kivéve tranziens állapotban) IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 29. oldal Miért dinamikus? • Észreveszi ha egy link megszakad: – az adatkapcsolati réteg jelzi az router alkalmazásnak (néhány sec), vagy – a Hello csomagok elmaradása miatt maga az OSPF protokoll veszi észre (40 sec) • Eredmény: egyből elterjeszti a Router az új topológia állapotot • Mi nincs: sávszélesség, késleltetés terjesztés (QoS-routing jelen verzióval nem megoldható) IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 30. oldal Kétszintű hierarchia • Területekre osztás • LSA terjesztés csak a területeken belül, köztük aggregálás • Kiemelt terület: gerinc (AreaID=0) • Minden

területről egy Routernek a gerincre kell csatlakoznia (lehet virtuális linken) IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 31. oldal OSPF komponensek • Szomszédok felfedezése (Hello) • Broadcast vagy NBMA hálózaton kiválasztott router (DR) és tartalék router (BDR) választás • Szomszédsági viszony kialakítás (adjacencies) • Adatbázis szinkronizáció • Él állapot terjesztés (LSA Flooding) • Routing tábla számolás IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 32. oldal OSPF csomag fejléc • Típus: – – – – – Hello (1) Database Description (2) Link-State Request (3) Link-State Update (4) Link-State Acknowledgment (5) • Router ID, Area ID egyedi azonosítás • CheckSum: szokásos IP • Authentication: jelszavas védelem IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 33. oldal OSPF Hello • Linkek állapotának

folyamatos figyelése • Alap konfigurációs beállítások egyeztetése • Broadcast vagy NBMA linken DR választás: – DR=0 ha nem ismert még – elsőség vagy router prioritás dönt – Pr=0 soha nem leszek IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 34. oldal Szomszédsági viszony kialakítás • Aki a szomszédom, azzal fogom összehangolni az adatbázisomat, és annak terjesztem tovább az LSA-kat. • Pont pont linken mindig szomszédos a másik oldal • Broadcast és NBMA linken mindenki a DR-el és a BDR-el lesz szomszédsági viszonyban • Ez leegyszerűsíti az adatbázis szinkronizációt és az LSA terjesztési procedúrát IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 35. oldal Adatbázis szinkronizáció (DS) • Master-slave/kérésválasz alapon számozva • Csak LSA fejlécek • ami hiányzik, lekérem LSA Request-el • ha mindenre jött LSAupdate: ‘fully adjacent’

• új LSA terjesztés erről a feléledt linkről IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 36. oldal 10.116 10.114 DS példa OSPF Hello OSPF Hello: I heard 10.116 Database Description: Sequence = X Database Description: Sequence = X, 3 LSA router-LSA 10.111 0x80000004 router-LSA 10.114 0x8000003b router-LSA 10.116 0x80000005 Database Description: Sequence = X+1, 1 LSA router-LSA 10.116 0x80000001 Database Description: Sequence = X+1 Link State Request packet LSAs = router-LSA 10.111 router-LSA 10.114 router-LSA 10.116 Link State Update packet LSAs = router-LSA 10.111 0x80000004 router-LSA 10.114 0x8000003b router-LSA 10.116 0x80000005 Link State Update packet LSAs = router-LSA 10.116 0x80000006 IP útvonalválasztás I. • Második ‘Hello’ azonnal • Látom a címem: kétirányú a link • DD sorszám nő, • ACK: következő csomag • Kérésnél a legutolsót kérem • 10.116 lekéri a másiknál lévő régi LSA-t,

majd frissíti azt Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 37. oldal LSA Flooding • Link-state Advertisement megbízható terjesztése • Minden szomszédnak továbbadom, kivéve akitől kaptam • Újraküldés sor, • Nyugtázandó sor, (azonnali, vagy késleltetett) • Implicit nyugta.: ha újabb van nekem azzal is válaszolhatok IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 38. oldal LSA és az idő • Időnként ha nincs változás is újat küld a forrás új SN-el, (LSARefrestTime = 30 perc) • LSA megölés MaxAge-el elküldöm, új SN-el másik • Öregítés az adatbázisában (ChechAge = 5 perc) • Két LSA különbözik (MaxAgeDiff = 15 perc) • Ha nem jön frissítés eldobják (MaxAge = 60 perc) IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 39. oldal Védelmi időzítők • Elképzelhető hogy egy link megbolondul • Beépített védelem van erre az esetre:

– LSA-t nem szabad túl gyakran kreálni (MinLSInterval = 5 sec) – Ha mégis túl gyakran jönne mindig csak filterezve szabad nézni (MinLSArrival = 1 sec) • Más védelem: CRC + újra küldés – Ha CRC hibát találok: no ACK - újra küldik IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 40. oldal LSA típusok • • • • • • • • • • • Router Network Network Summary AS Boundary Router summary AS-External Group membership NSSA (not so stubby area) Ext attributes Link-local Opague Are-local Opague AS-external Opague IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 41. oldal Router LSA • • • • V: virtuális él végpont E: AS boundary router B: area border router Link ID: – neighbour’s router ID – DR IP címe • TOS csak kompatibilitás miatt IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 42. oldal Network LSA

Network LSA Router LSA IP útvonalválasztás I. • Broadcast, NBMA hálózaton • Link-StateID: DR IP címe: • Ha a Router-LSA tartalmaz utalást • DR halálakor BDR új network LSA-t készít Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 43. oldal NBMA hálózatok • Nonbroadcast multiaccess: bárki bárkivel kommunikálhat, de nincs broadcast (X.25, ATM) • Felfedezés nem megy: konfigurálni kell • Router Priority = 0 csak a DR el és a BRD el Hellozik • Halott felé a Hello csak PollInterval (120s) másodpercenként megy • DS, LSA készítés ugyan olyan mint broadcast hálózaton IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 44. oldal Pont-többpont hálózatok • NBMA-nál túl sok PVC kellhet a teljesen összekötött hálózathoz, • Ez a módszer megelégszik részleges összekötöttséggel • Ahol PVC van úgy fogható fel mintha egy soros vonal lenne, • nincs DR, BDR, • mindenki szomszédos a

PVC másik végén ülővel IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 45. oldal Summary LSA • Area Border Router készíti • A belső terület elérhetőségét terjeszti a gerincen • Link State ID-ban van a cím, LSA-ban a mask • A költség a legtávolabbi cím elérésére utal a területen belül • Saját terültre az ABR új summary-LSA-kat terjeszt IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 46. oldal Gerinc számítás • ABR-ek a gerinc summary-LSA-inak felhasználásával distance vector számítással döntenek a legjobb útról • Ez megfelelően működik, hisz minden terület kapcsolódik a gerinchez OSPF gerinc 0.001 0.003 0.002 IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 47. oldal Külső információk terjesztése • Az AS szélén valamelyik router (ASBR AS boundary router) kapcsolódik az Internetre (pl. BGP-t futtat)

• Ha csak egy kijárat van default utak jók • Ha több ASBR van, néhány útnál számíthat, hogy merre megy ki az AS-ből • Ha az OSPF alatt RIP fut, az elérhetőségeket szeretném terjeszteni IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 48. oldal Hierarchia a külső utak között • Területen belülit ha lehet, • Területek közöttit azután, • Külső utakat aztán, amin a távolságképzés ugyan olyan mint az OSPF-ben (Type 1 pl. RIP utak) • Olyan külső utakat végső esetben, aminek a külső részén a költség jóval nagyobb súlyú mint a belső részen a költség (Type 2 pl. BGP utak) IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 49. oldal AS-External LSA • A Mask megint az LS IDvel ad teljes címet • E = 1 Type 2 költség • Metric: AS út hossz BGP esetén • Forwarding Address: plusz hop kiküszöbölésére • External Route Tag: szél szél között

szállít infót IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 50. oldal ASBR summary LSA • Az AS-External LSA-kat az egész AS-en belül terjesztik (az ABR-ek nem gyártják újra) • El kell terjeszteni az ASBR-ek elérhetését is • Ezt az ABR teszi egy ASBR summary LSA-val • Ennek a Link State ID mezejében az ASBR router azonosítója szerepel, amúgy megegyezik egy sima summary LSA-val IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 51. oldal OSPF hálózat típusok • Vak területek (Stub areas) – csak default utak kifelé (AS-ext. LSA nem kerül be) – belül nem lehet ASBR és virtuális út – summary LSA kreálás befelé sem fontos • Nem olyan vak területek (Not-so-stubby Areas) – belül nem lehet ASBR és virtuális út, de – terjesztenek befelé külső elérhetőséget (spec Type 7 LSA) de csak egy irányban, a határon fordítás – Pl. RIP elérhetőség átszivárog

a gerincre egy NSSA-n keresztül IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 52. oldal Deman Circuit extension • Pl X.25 modemes elérés támogatására • Hello és LSA periodikus újraküldés fölösleges forgalmat generál, • Ez kivédhető: – DS alatt DoNoAge bit-et beállítom az LSA-ban – a Hello üzeneteket elfelejtem IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 53. oldal EGP • Exterior Gateway Protocol RFC 904 • AS-ek közötti útvonalválasztás elérhetőségi információk alapján • Kifejlesztésénél még hierarchikus volt az Internet NFSNet volt a gerinc, aminek átgondolt konfigurálása megoldható volt • Alapvetően distance-vector protokoll, nem véd a hurokképződés ellen, • Nincsenek védelmi mechanizmusai IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 54. oldal Border Gateway Protocol (RFC 1771) • • • •

EGP hiányosságait küszöböli ki CIDR támogatás, hatékony cím aggregáció Konfigurálni kell a BGP szomszédokat TCP fölött fut (179-es port) megbízható, kapcsolatorientált transzportot feltételez • nincs periodikus újraküldés, minden hallott útvonalat megjegyeznek a routerek • Hurokmentesség ellen path vector módszert használ (a célig vezető AS-ek listája) IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 55. oldal BGP kapcsolatok, aggregálás • Internal/External BGP • Egy AS lehet – Vak (Stub), – Több-bázisú (Multihomed) vagy – Tranzit • Az AS utat is lehet aggregálni: Z: sorozat (Z,X) cél 152.6600 /16 Q: sorozat(Q,Z), halmaz(X,Y), cél 152.6400 /14 IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 56. oldal Aggregálás II. • • • • • Q ezt hallja: Z: sorozat(Z), halmaz (X, Y), cél: 152.6400/14 W: sorozat (W, V, Y), cél: 152.6700/16 Q ezt terjeszti

belül: sorozat(Z), halmaz (X, Y), cél: 152.6400/15 és 1526600/16 • sorozat (W, V, Y), cél: 152.6700/16 • Q ezt terjeszti kívül jelezve hogy volt részletesebb infója is: • Q: sorozat (Q), halmaz (X, Y, V, W, Z) cél: 152.6500/14 *atomic aggregate IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 57. oldal BGP működés • OPEN (első üzenet, BGP verzió, AS szám, KeepaliveIntervall megbeszélése) • KEEPALIVE (kapcsolat életben tartására ha nem volt UPDATE v. NOTIFICATION mostanában) • UPDATE (ebben közlik az útvonalakat egymással) • NOTIFICATION (ha valami hiba volt) IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 58. oldal UPDATE • Út attribútumok: – Forrás: IGP/EGP/Rész info – Út: szegmens sorozat (halmaz/sorozat,hossz,AS-ek) – Következő hop IP címe – Multi Exit discriminator: opcionális, nem tranzitív – Lokális referencia – Láthatatlan aggregáció

– Utolsó aggregáló AS + IP cím IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 59. oldal Útvonal számítás • Kapott utak: RIB-In (Route Information Base) • Az ebben lévő utakat különböző helyi szabályok alapján értékeljük, és belső BGP kapcsolaton terjesztjük (PIB: Policy Information Base) • Az így kapott utakból építjük meg a Local-RIB-et, • Amin megint csak különböző műveleteket végezve kapjuk a RIB-Out-ot amit terjesztünk • Költség: AS szám az úton, vagy lokálisan az ASekhez rendelt súly IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 60. oldal IBGP • Belső BGP kapcsolatok is kellenek • Teljesen összekötött topológia, (segít a confederation, vagy route reflector használata) • Az AS-ből való optimális kivezető út megtalálását segíti egy u.n lokális preferencia, amit az IBGPszomszédok csak egymás közt terjesztenek • Hasonló

célt szolgál csak EBGP-ben a multi exit discriminator, ami két AS közötti párhuzamos linkek esetén segít a választásban IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 61. oldal Irodalom • RFC 1058 Routing Information Protocol • RFC 1723 RIP Version 2 • RFC 2328 • RFC 1771 BGP-4 • John T. Moy OSPF: Anatomy of an Internet Routing Protocol (Addison-Wesley 1998) • Turányi Zoltán: Hálózati Trendek, 5.3 Routing • Designing Large-Scale IP Internetworks http://www.ciscocom/ • TCP/IP Tutorial and Technical Overview: Interior Routing Protocols OSPF Version 2 http://home.schbmehu/~koltl/htrend/trendek53html http://www.rs6000ibmcom/resource/aix resource/ /Pubs/redbooks/htmlbooks/gg243376.04/3376fmhtml IP útvonalválasztás I. Szviatovszki Balázs Balazs.Szviatovszki@ethericssonse 62. oldal