Rodina protokol TCP/IP, verze 2.2. ást 6: IP smrování

Transkript

1 v. 2.2 Katedra softwarového inženýrství, Matematicko-fyzikální fakulta, Univerzita Karlova, Praha Rodina protokol, verze 2.2 ást 6: IP smrování Jií Peterka, 2005

2 v. 2.2 Co je smrování (routing)? striktn vzato: volba smru pro další pedání paketu/datagramu ve skutenosti to zahrnuje: výpoet optimální cesty je to kombinatorický problém hledání nejkratší cesty v grafu výsledkem jsou "podklady pro volbu smru" uchovávání smrovacích informací ("podklad") vedení smrovacích tabulek pedávání paket (forwarding) používání výsledk výpot ("podklad") udržování sm rovacích informací co všechno s tím dále souvisí? celková koncepce smrování celková koncepce internetu katenetový model které uzly se úastní historický vývoj pímé a nepímé smrování metody optimalizace smrovacích tabulek ešení smrování v opravdu velkých systémech autonomní systémy smrovací politiky.. J.Peterka, MFF UK,

3 v. 2.2 Celková koncepce smrování statické smrování obsah smrovacích tabulek má statický charakter a nemní se vyžaduje to runí konfiguraci smrova (jejich smrovacích tabulek) což je pracné a náchylné k chybám nereaguje to na zmny v síti dostupnost njaké sít není závislá na stavu spojení používá se jen výjimen: pro definování tzv. implicitních cest default route pro zavedení smr které nejsou inzerovány napíklad v rámci firewall pro implementaci speciálních smrovacích politik kdy je zámrem reagovat na smrovací informace jinak než obvykle jako obrana proti nekorektním smrovacím informacím.. dynamické smrování obsah smrovacích tabulek má dynamický charakter a mní se asto je základ konfigurace vytváen staticky, runí konfigurací smrova nap. implicitní cesty ostatní údaje se prbžn aktualizují existují dv základní varianty dynamického smrování vector-distance routing sousední smrovae si pedávají celé své smrovací tabulky (obsahující "vzdálenostní vektory") je he škálovatelné a mén stabilní, pestává se používat link-state routing smrovae si pedávají jen údaje o prchodnosti cest k sousedm lépe škálovatelné, používá se. J.Peterka, MFF UK,

4 v. 2.2 Pipomenutí: koncepce internetu internet je budován na principu katenetu je soustavou vzájemn propojených sítí jednotlivé sít jsou oddleny smrovai "pedávání" paket (forwarding): má na starosti protokol IP aktualizaci smrovacích informací, výpoty cest: zajišují specializované protokoly jako RIP, OSPF,.. pedstava katenetu skutená sí = = IP Router (smrova) J.Peterka, MFF UK,

5 v. 2.2 Pipomenutí: hostitelské poítae pedpokládá, dva typy uzl v síti: hostitelské poítae (host computers) tj. koncové uzly, nap. servery, pracovní stanice, PC, rzná zaízení (tiskárny, ) jsou pipojeny jen do jedné t (mají jen jednu síovou adresu) smrovae (IP Routers) jsou pipojeny nejmén do dvou tí zajišují "pestup" (smrování) teze: oba typy uzl by se nemly prolínat smrovae by nemly plnit další funkce hostitelské poítae by nemly fungovat jako smrovae v podob tzv. multihomed-hosts, kdy jsou pipojeny do více sítí souasn vs. smrovae = smrova =hostitelské poítae (hosts) = multihomed host J.Peterka, MFF UK,

6 v. 2.2 Pímé a nepímé doruování pímé doruení nepímé doruení smrova pímé doruování: odesilatel a píjemce se nachází ve stejné ti pozná se podle toho, že mají stejnou síovou ást své IP adresy odpadá rozhodování o volb smru, o doruení se dokáže postarat linková vrstva (vrstva síového rozhraní) odesilatel pošle datagram "pímo" koncovému píjemci nepímé doruování odesilatel a píjemce se nachází v rzných tích odesilatel musí urit nejvhodnjší odchozí smr (resp. smrova ležící v tomto smru) odesilatel pošle datagramu smrovai ve zvoleném odchozím smru J.Peterka, MFF UK,

7 v. 2.2 Pedstava pímého doruování odesilatel pímé doruení adresa píjemce = síováást adresy odesilatele ( ) address resolution xx píjemce IP datagram linkový rámec odesilatel rozdlí cílovou adresu na její síovou ást a relativníást použije dlení, platné pro jeho vlastní sí masku sít, CIDR prefix, event. vyjde z tídy adresy získá síovou ást adresy píjemce pokud se síováást adresy píjemce shoduje se síovou ástí vlastní adresy, jde o pímé doruování odesilatel pevede IP adresu píjemce na jeho linkovou adresu provede "Address Resolution", nap. pomocí protokolu ARP získá linkovou adresu XX odesilatel (jeho síová vrstva) pedá datagram vrstv síového rozhraní s požadavkem na doruení na adresu XX J.Peterka, MFF UK,

8 v. 2.2 Pedstava nepímého doruování ( ) nepímé doruení ( ) smrovací tabulka pro sí posílej pes adresa píjemce = síováást adresy odesilatele volba volba odchozího smru smru pes smrova pímé pímédoruování pedchozí pípad porovnáním síových ástí adres odesilatel zjistí, že se píjemce nachází v jiné síti odesilatel se "podívá" do své smrovací tabulky a podle ní zvolí odchozí smr smrova v odchozím smru odešle datagram zvolenému smrovai již se jedná o pímé doruení J.Peterka, MFF UK,

9 v. 2.2 Pedstava smrovacích tabulek ( ) ( ) ( ) ( ) ( ) ( ) ( ) ( ) smrovací tabulka uzlu cílová sí/prefix / / / / / / / /24 posílej pes smruj pímo jsou to adresy nejbližšího peskoku (next hop) ve smrovací tabulce se nenachází úplná cesta k cíli, ale pouze "next hop" adresa nejbližšího smrovae prefix v adrese cílové sít odpovídá masce "CIDR prefix" vyjaduje poet jednikových bitu masky J.Peterka, MFF UK,

10 v. 2.2 Optimalizace smrovacích tabulek (agregace položek) / / / / / / / /24 cílová sí/prefix ( ) smruj pímo ( ) ( ) ( ) ( ) ( ) ( ) ( ) smrovací tabulka uzlu celou skupinu sítí lze slouit posílej pes (agregovat) do vtšího CIDR bloku xx 22 bit 24 bit cílová sí/prefix / / / / /22 posílej pes smruj pímo J.Peterka, MFF UK,

11 v. 2.2 Optimalizace smrovacích tabulek (implicitní cesty default route) ( ) smrovací tabulka uzlu cílová sí/prefix / / / / /22 posílej pes doru pímo ( ) ( ) ( ) ( ) ( ) v pípad stromovité topologie lze definovat implicitní cestu (default route), vedoucí "nahoru" cílová sí/prefix / / /24 posílej pes doru pímo ( ) ( ) ( ) ( ) ( ) J.Peterka, MFF UK, 2005 všechno ostatní 11

12 v. 2.2 Host-specific route ( ) ( ) ( ) ( ) ( ) ( ) ( ) smrovací tabulka uzlu cílová sí/prefix posílej pes /24 doru pímo / / / /24 pomocí masky (prefixu) lze do smrovacích tabulek zavést i specifické smrovací informace, týkající se jednotlivých uzl tzv. host-specific route lze to využít pi redundantním pipojení napíklad pro odlišné smrování dat smujících k njakému serveru / "host-specific route" route" k uzlu uzlu J.Peterka, MFF UK,

13 v. 2.2 Pravidla smrování "host-specific route" by mly být používány jen výjimen velmi zvtšují objemy smrovacích tabulek musí se vyhodnocovat jako první snaha je rozhodovat pi smrování podle píslušnosti cílového uzlu k urité síti pak postauje menší poet položek smrovacích tabulek agregace položek pomáhá snižovat objem smrovacích tabulek pomáhá i používání "default route" default route odpovídá prefixu 0 pravidlo pro prohledávání smrovacích tabulek: postupuj od nejvíce konkrétního k nejmén konkrétnímu tedy: nejprve hledej položku s nejvtším prefixem, postupuj k menším prefixm píklad: cílová sí/prefix / / /22 x/0 (ostatní) postup prohledávání posílej pes host-specific route default route J.Peterka, MFF UK,

14 v. 2.2 Základní algoritmus smrování vezmi I d ( plnou IP adresu píjemce), a zjisti zda se píjemce nachází ve stejné síti jako ty pokud ano, použij pímé doruování. Jinak... zani prohledávat smrovací tabulku postupn podle velikosti prefixu pokud se hodnota v prefixu práv prohledávané položky shoduje se stejnolehlou ástí I d (píslušným potem vyšších bit), doruuj nepímo dle této položky. Jinak pokrauj další položkou, pokud existuje... existuje-li implicitní cesta (default route) použij tuto cestu. Jinak... skoni chybou generuj ICMP zprávu "Destination Unreachable" J.Peterka, MFF UK,

15 v. 2.2 Role hostitelských poíta a smrova IP protokol IP protokol smrova hostitelský poíta smrovae: úastní se všech inností v rámci smrování vetn aktualizace smrovacích informací když kdyžse se hostitelský poíta poíta "chová "chovášpatn", smrova jej jej "pouí" "pouí"(poskytne mu mu správné správné smrovací informace) hostitelské poítae: také musí volit smr penosu paketu vedou si smrovací informace ve svých smrovacích tabulkách a využívají je aplikují základní algoritmus smrování ale neúastní se aktualizace smrovacích informací!!! J.Peterka, MFF UK,

16 v. 2.2 Píklad smrova Y host B host A od A pro B smrova X host C "na poátku" musí každý hostitelský poíta znát alespo jeden smrova "vedoucí ven" ze sít ve které se nachází nech host A zná smrova X (ale nikoli smrova Y) potebuje-li host A poslat nco hostu B, pozná že jde o nepímé doruování a pošle to smrovai X smrova X pozná, že neleží na nejvhodnjší cest mezi hostem A a hostem B upozorní hosta A na vhodnjší (kratší) cestu na existenci smrovae Y J.Peterka, MFF UK,

17 v. 2.2 ICMP Redirect ICMP Redirect: pro B posílej pes Y smrova Y host B host A od A pro B smrova X host C smrova X se postará o správné doruení IP datagramu k uzlu B sám pošle data Smrovai Y, ten se postará o doruení smrova X pošle hostu A zprávu "ICMP Redirect" ve smyslu: "datagramy pro uzel B píšt posílej pes smrova Y" host A by se ml pouit ml by si zanést smrova Y do své smrovací tabulky a píšt jej použít J.Peterka, MFF UK,

18 v. 2.2 ICMP Redirect TYPE = 5 CODE = 0-3 IP adresa smrovae CHECKSUM IP header plus 64 bit pvodních dat zahozeného datagramu Jde o hlášení od smrovae, že existuje lepší cesta pro doruení IP datagramu a vede pes jiný smrova jeho IP adresa je uvedena CODE=0: zm smrování pro sí, 1: zm smrování pro uzel CODE=2: zm smrování pro sí pro daný typ služby, 3: dtto, uzel&služba odesilatel (hostitelský poíta) by ml zareagovat zanesením nového smrovae do své smrovací tabulky pokud tak neuiní, nesprávn oslovený smrova má právo jej znovu upozornit, ale nesmí jej odmítnout (musí vždy pedat data správným smrem) J.Peterka, MFF UK,

19 v. 2.2 ICMP Router Solicitation TYPE = 10 CODE = 0 nepoužito (nastaveno na 0) CHECKSUM jde o "dotaz do pléna": jaké jsou tady smrovae? ICMP zpráva je rozesílána pomocí IP broadcastu všem uzlm dané sít odpov pináší informaci o dostupných smrovaích v síti (zejm) je brána první odpov která dorazí, eventuelní neúplnost je ešena pomocí ICMP Redirect umožuje to, aby hostitelské poítae nemusely "na poátku" znát žádný smrova smrovae odpovídají na dotazy ale samy také generují odpovdi (advertisement) v náhodném intervalu mezi 450 až 600 vteinami J.Peterka, MFF UK,

20 v. 2.2 ICMP Router Advertisement TYPE = 9 poet položek CODE = 0 délka položky CHECKSUM životnost položek adresa smrovae, preference adresa smrovae, preference jde o odpov na Router Solicitation, nebo o samostatn generovanou "reklamu" (advertisement) preference umožují píjemci stanovit, pes který smrova vede implicitní cesta (default route) životnost íká, jak dlouho má být záznam o smrovai ponechán ve smrovací tabulce píjemce J.Peterka, MFF UK,

21 v. 2.2 Aktualizace smrovacích informací základní problém: jak zajistit rychlou a správnou reakci na zmny, tak aby s tím nebyla spojena píliš velká režie navíc: jak to udlat v rozsahu dnešního Internetu? je teba prbžn šíit aktualizaní informace ze kterých se prbžn vypoítávají údaje (next hop) ve smrovacích tabulkách lze to ešit na principu "vector distance" nebo "link state" ešení tohoto problému se mnilo s vývojem Internetu hlavn v dsledku jeho zvtšování zpoátku: Internet byl malý, existovaly centrální smrovae s úplnou informací pozdji: vznikla 2-úrovová struktura core smrovae s úplnou informací non-core smrovae s neúplnou informací ješt pozdji došlo k "dekompozici" Internetu vzniku tzv. autonomních systém (AS), které v sob lokalizují detailní smrovací informace a nešíí je mimo sebe J.Peterka, MFF UK,

22 CoreBuilder r CoreBuilder r CoreBuilder r Rodina protokol v. 2.2 Smrování v ranném Internetu B A páte Internetu (ARPANET, NSFNET) D C E core gateway non-core gateway existovala soustava tzv. core gateways (centrálních smrova), nacházejících se v páteníásti Internetu tyto core gateways mly úplnou informaci o celé topologii Internetu byly centráln spravovány (povenou organizací) ostatní smrovae byly "non-core gateways" pracovali s neúplnou informací o topologii Internetu "znaly" jen sít "pod sebou", provoz do ostatních sítí smrovaly pes implicitní cesty do core gateways inzerovaly existenci "svých" sítí (sítí "pod sebou") smrem ke core gateways F G zná pouze cestu k sítím D,E, F a G, ostatní posílá pes default route J.Peterka, MFF UK,

23 CoreBuilder r CoreBuilder r Rodina protokol v. 2.2 Smrování v ranném Internetu B A páte Internetu (ARPANET, NSFNET) EGP GGP D F C E EGP G pro vzájemnou komunikaci centrálních smrova ("core gateways") byl vytvoen protokol GGP Gateway-to-Gateway Protocol pro komunikaci mezi centrálními a "ostatními" (vnjšími) smrovai byl vytvoen protokol EGP Exterior Gateway Protocol terminologie: pvodn se IP smrovam íkalo "IP Gateways" proto GGP a EGP problém tohoto ešení: nebylo dostaten škálovatelné J.Peterka, MFF UK,

24 v. 2.2 Další vývoj autonomní systémy s rstem Internetu se ešení s core gateways stalo neúnosné úplná informace o celé topologii Internetu je píliš velká, režie na distribuci této informace mezi všemi core gateways neúnosná core gateways nešlo donekonena nafukovat muselo se najít jinéešení souvislost: Internet pešel do komerní sféry, "smrovací politika" jednotlivých ástí Internetu již nemusela být stejná bylo teba vyhovt individuálním požadavkm jednotlivých providerm, požadavkm na peering,. princip "jiného ešení" "dekompozice" Internetu z hlediska smrování detailní ("úplná") smrovací informace nebude šíena po celém Internetu resp. po páteníásti ale zstane lokalizována v uritých oblastech bude šíena pouze uvnit tchto oblastí, ne mimo n tyto oblasti budou šíit kolem sebe pouze mnohem "menší" informace o dostupnosti jde o tzv. autonomní systémy J.Peterka, MFF UK,

25 v. 2.2 Pedstava autonomního systému B A autonomní systém AS1 páteníásti Internetu D C E autonomní systém AS2 autonomní systém "navenek" neinformuje o své vnitní struktue ani o detailních smrovacích informací je "autonomní" v tom smyslu, že si mže sám stanovit svou vlastní smrovací politiku vetn toho, jakým zpsobem je uvnit AS ešena aktualizace smrovacích informací navenek autonomní systém zveejuje pouze informace o dostupnosti ve smyslu: AS1: "uvnit mne se nachází sít A až B" AS2: "uvnit mne se nachází sít C až G" F G je je to to typicky typicky "intervalová "intervalová informace" informace" (od-do), (od-do), tvoená tvoená rozsahem rozsahem IP IP adres adres (resp. (resp. CIDR CIDR blok blok náležejících náležejících do do AS) AS) J.Peterka, MFF UK,

26 v. 2.2 Pedstava autonomního systému AS2 AS1 AS4 AS3 každý autonomní systém má uritý (malý) poet vstupních/výstupních bod skrz tyto body se propojují s ostatními autonomními systémy skrz tyto body si vymují informace o dostupnosti (o svém obsahu) a také testují svou vzájemnou existenci pvodn musela být struktura autonomních systém striktn stromovitá dnes již nemusí každý AS si mže sám zvolit, jak ("kudy") chce komunikovat s jinými autonomními systémy díky tomu je možný peering pímé propojení autonomních systém, obcházející implicitní propojení pes páteníásti J.Peterka, MFF UK,

27 v. 2.2 Dnešní struktura Internetu NAP vzájemn alternativní pátení sít NAP komunikace pi neexistenci peeringu komunikace pi existenci peeringu autonomní systém (sí upstream providera) autonomní systém (sí providera) J.Peterka, MFF UK,

28 v. 2.2 Exterior Gateway Protocols mezi autonomními systém musí probíhat výmna informací o dostupnosti, existenci, "navazování vzájemných vztah", ) k tomu jsou zapotebí vhodné protokoly díve se používal protokol EGP (Exterior Gateway Protocol) byl šit na míru centralizovanému Internetu, s jediným pátením autonomním systémem nepipouštl nic jiného než stromovitou strukturu nedokázal využít více alternativních páteních AS dnes je "Exterior Gateway Protocols" generické oznaení pro všechny protokoly, které zajišují komunikaci mezi AS dnes se používá modernjší protokol BGP (Border Gateway Protocol) napravuje nedostatky EGP pipouští obecné propojení autonomních systém ne pouze "do stromu" umožuje stanovit rzná kritéria pi volb mezi alternativními smry správce AS mže stanovit priority. napíklad v závislosti na rychlosti, kapacit linek, spolehlivosti atd. podporuje CIDR dnes verze BGP-4 J.Peterka, MFF UK,

29 v. 2.2 IGP Interior Gateway Protocols pipomenutí: uvnit sebe sama si každý autonomní systém mže ešit smrování tak jak uzná za vhodné mže aplikovat vlastní smrovací politiku týká se to hlavn aktualizace smrovacích informací existuje více alternativních protokol, které lze použít pro aktualizaci smrovacích informací uvnit AS obecn jsou oznaovány jako IGP (Interior Gateway Protocols) píklady protokol IGP: RIP (Routing Information Protocol) pracuje na principu "vector distance" vyvinut firmou Xerox ve stedisku PARC, použit mnoha firmami, používal se již v pvodním ARPANETu vhodný pro malé až stední sít, ne pro velké OSPF (Open Shortest Path First) pracuje na principu "link state" vhodný i pro vtší sít (vtší autonomní systémy) J.Peterka, MFF UK,

30 v. 2.2 RIP Routing Information Protocol je typu vector-distance uzly si vymují aktualizace tvoené smrovým vektorem a jeho ohodnocením (vzdáleností k cíli) metrika je pevná, a to poet peskok!! aktualizace (updaty): se vysílají každých 30 sekund když do 180 sekund nepijde update od njakého konkrétního (sousedního) routeru, jsou všechny cesty vedoucí pes tento router oznaeny jako nekonen dlouhé. po dalších 120 sekundách jsou odstranny z tabulky (nastoupí jakýsi garbage collector). výpoet cest je distribuovaný každý poítá kousek algoritmus probíhá trvale, nikdy nekoní!!! každý je závislý na ostatních, chyba jednoho ovlivuje druhé aktualizace (updaty): posílají se jen k pímým sousedm (routerm) každý uzel se od svých soused dozvídá jen o dostupnosti cílových sítí (a metrice), ne o dalším routování za svými sousedy (nevidí dál než ke svým sousedm) nemá informace o celé topologii!!! obsahují údaje o dostupnosti ostatních uzl z daného uzlu (s jakou cenou) v zásad jde o obsah celé smrovací tabulky alternativní cesty nejsou uvažovány, jsou zahazovány (tj. cesty se stejným ohodnocením) aby se zabránilo oscilacím, RIP aktualizuje njakou už existující cestu pouze takovou, která má nižší metriku!!! (nestaí stejná)!!! J.Peterka, MFF UK,

31 v. 2.2 Protocol RIP Command Version (1) 0 Address Family (=2) 0 IP adresa cílové sít 0 0 vzdálenost do sít až 25x Zpráva RIP-u obsahuje: pole Command, obsahuje bu výzvu k zaslání routovacích informací, nebo odpov na tuto výzvu. pole Address Family (= 2 pro RIP) pole "vzdálenost" musí obsahovat íslo od 1 do 15, zatímco 16 je považována za nekoneno. J.Peterka, MFF UK,

32 v. 2.2 Protocol RIP pedstava fungování RIP je v je implementován jako aplikace (na aplikaní úrovni) jako démon "routed" bží nad UDP sedí na portu 520 (well-known portu) velikost každého RIP paketu je max. 512 byt výhoda: je to jednoduché, nemusí se konfigurovat staí spustit démona routed, ten routed transportní v. smrovací. tabulky síová v. linková v. již nastaví smrovací tabulky fyzická v. port 520 routed transportní v. smrovací. tabulky síová v. linková v. fyzická v. J.Peterka, MFF UK,

33 v. 2.2 RIP2, RIPng v roce 1993 byl pvodní RIP updatován na verzi RIP-2 nové vlastnosti/schopnosti: podpora IP adres s maskami a CIDR "Next Hop Specification" v RIP záznamu je explicitn uvedena IP adresa smrovae, pes který vede spojení do cílové sít zvyšuje efektivnost umožuje smrovat provoz i pes smrovae, které nepodporují RIP autentizace ochrana proti útokm skrze falešné RIP zprávy "Route Tag" další informace o inzerované cest použití multicastu pro rozesílání zpráv (RIP Response) zasílají se na adresu , která je vyhrazena pro RIP všechny uzly "v dosahu" musí podporovat multicast RIP-2 mže koexistovat s RIP-1 RIOP-2 vkládá svá nová data do nevyužitých ástí zpráv RIP-1 v roce 1997 byl RIP upraven i pro IPv6 RIPng, RIPv6 umožuje používat IP adresy verze 6 má jiný formát zpráv J.Peterka, MFF UK,

34 v. 2.2 Protokol OSPF (Open SPF) je "otevenou verzí staršího protokolu SPF (Shortest Path First) jeho specifickace jsou veejn pístupné, pochází od IETF je typu link-state každý uzel testuje dostupnost svých soused stav linky každý uzel sestavuje "link state paket", ve kterém uvede údaje o dostupnosti svých soused stav linky a její ohodnocení tyto pakety jsou rozesílány všem uzlm v síti/soustav sítí staí ale jen pi zmn njakého údaje!!!! jinak pro osvžení každých 30 minut všechny uzly v síti mají úplnou informaci o jednotlivých spojích a mohou si vypoítat optimální cesty každý poítá "za sebe", chybou ovlivní jen sebe sama OSPF podporuje alternativní cesty umožuje definovat rzné cesty pro rzné druhy provozu podporuje load balancing OSPF podporuje další "dekompozici" umožuje rozdlení sít na menší "areas", které jsou analogické autonomním systém v tom, že jejich topologie není šíena mimo danou "area" minimalizuje to objemy aktualizaních informací J.Peterka, MFF UK,

35 v. 2.2 Protokol OSPF oblasti jde o vlastnost, která zvtšuje "dosah" OSPF umožuje vtší škálovatelnost, tj. realizovat AS celý autonomní systém se rozdlí na (disjunktní) oblasti jedna se prohlásí za pátení (backbone) smrovae v oblastech se rozdlí na interní zajišují smrování v rámci oblasti, mají stejné informace (navzájem) pátení (Backbone) zajišují smrování v rámci pátení oblasti na rozhraní (Area Border) patí souasn do oblasti i do pátee, vymují informace mezi nimi hraniní (Boundary) v pátení oblasti, vymují smrovací informace s jinými AS J.Peterka, MFF UK,

36 v. 2.2 Píklad: hierarchické OSPF J.Peterka, MFF UK,

37 v. 2.2 Fungování OSPF každý OSPF smrova si udržuje: komunikace mezi OSPF databázi pímých soused smrovai probíhá pomocí každý ji má jinou OSPF paket udržuje aktuální pomocí HELLO vkládají se pímo do IP paket paket, které pravideln posílá svým Protocol No. 89 sousedm každých 10 sekund existuje 5 druh zpráv: Hello každý smrova si udržuje "topologickou databázi" Database Description databázi s údaji o topologii celé sít Link State Request všichni (v oblasti) by ji mli mít Link State Update stejnou Link State Acknowledgement pomocí této databáze poítá "nejkratší" cesty smrovací tabulky používají se pro samotné smrování IP paket J.Peterka, MFF UK,

38 v. 2.2 Fungování OSPF "nový" smrova: nejprve zjistí, jaké má sousedy eší se jinak v prostedí s broadcastem, bez broadcastu a na dvoubodových spojích s každým sousedem si synchronizuje svou topologickou databázi pomocí píkaz Database Description Link State Request Link State Acknowledgement po úspšné synchronizaci oba smrovae ve dvojici "ohlásí svtu své sousedství" pomocí broadcastu oba rozešlou všem ostatním smrovam v síti tzv. LSA (Link State Advertisement) informaci o existenci spojení (vazby, hrany) mezi nimi pomocí píkaz Link State Update "již fungující" smrova trvale monitoruje dostupnost svých pímých soused pomocí HELLO paket, každých 10 sekund pokud není zmna: každých 30 minut opakuje všem své "sousedství" rozesílá LSA s údaji o dostupnosti souseda, pomocí broadcastu pokud je zmna okamžit informuje o zmn pomocí LSA (Link State Advertisement) OSPF píkaz "Link State Update" LSA se šíí jako inteligentní broadcast fakticky jako záplava (záplavové smrování), s eliminací duplicitních paket J.Peterka, MFF UK,