Katedra softwarového inženýrství, Matematicko-fyzikální fakulta UK

Transkript

1 Katedra softwarového inženýrství, Matematicko-fyzikální fakulta, Univerzita Karlova, Praha, verze 2.2 Jií Peterka, 2005 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í cích ("podklad") vedení cích tabulek pedávání paket (forwarding) ("podklad") udržování sm rovacích 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 cích tabulek ešení smrování v opravdu velkých systémech y cí politiky.. používání výsledk výpot J.Peterka, MFF UK, Celková koncepce smrování Pipomenutí: koncepce internetu statické smrování obsah cích tabulek má statický charakter a nemní se vyžaduje to runí konfiguraci (jejich cí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 cích politik kdy je zámrem reagovat na cí informace jinak než obvykle jako obrana proti nekorektním cím m.. dynamické smrování obsah cích tabulek má dynamický charakter a mní se asto je základ konfigurace vytváen staticky, runí konfigurací nap. implicitní cesty ostatní údaje se prbžn aktualizují existují dv základní varianty dynamického smrování vector-distance routing sousední e si pedávají celé své cí tabulky (obsahující "vzdálenostní vektory") je he škálovatelné a mén stabilní, pestává se používat link-state routing e si pedávají jen údaje o prchodnosti cest k sousedm lépe škálovatelné, používá se. J.Peterka, MFF UK, internet je budován na principu katenetu je soustavou vzájemn propojených sítí jednotlivé sít jsou oddleny i "pedávání" paket (forwarding): má na starosti protokol IP aktualizaci cích, výpoty cest: zajišují specializované protokoly jako RIP, OSPF,.. pedstava katenetu skutená sí = = IP Router () J.Peterka, MFF UK, Pipomenutí: hostitelské poítae vs. e 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) e (IP Routers) jsou pipojeny nejmén do dvou tí zajišují "pestup" (smrování) teze: oba typy uzl by se nemly prolínat e by nemly plnit další funkce hostitelské poítae by nemly fungovat jako e v podob tzv. multihomed-hosts, kdy jsou pipojeny do více sítí souasn = =hostitelské poítae (hosts) = multihomed host J.Peterka, MFF UK, Pímé a nepímé doruování pímé doruení nepímé doruení 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. ležící v tomto smru) odesilatel pošle datagramu i ve zvoleném odchozím smru J.Peterka, MFF UK, , verze 2/2 1

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, Pedstava nepímého doruování nepímé doruení cí tabulka pro sí adresa píjemce porovnáním síových ástí adres odesilatel zjistí, že se píjemce nachází v jiné síti volba volba odchozího smru smru odesilatel se "podívá" do své cí tabulky a podle ní zvolí odchozí smr - v odchozím = + pes smru pímé pímédoruování odešle datagram zvolenému i síová ást adresy odesilatele již se jedná o pímé doruení pedchozí pípad J.Peterka, MFF UK, Pedstava cích tabulek Optimalizace cích tabulek (agregace položek) / / / /24 cí tabulka uzlu smruj pímo jsou to adresy nejbližšího peskoku (next hop) ( ) ve cí tabulce se nenachází úplná cesta k cíli, ale pouze "next hop" adresa nejbližšího e prefix v adrese cílové sít odpovídá masce "CIDR prefix" vyjaduje poet jednikových bitu masky J.Peterka, MFF UK, / / / /24 ( ) cí tabulka uzlu celou skupinu sítí lze slouit (agregovat) do vtšího smruj pímo CIDR bloku xx 22 bit 24 bit /22 smruj pímo J.Peterka, MFF UK, Optimalizace cích tabulek (implicitní cesty default route) Host-specific route cí tabulka uzlu /22 doru pímo v pípad stromovité topologie lze definovat implicitní cestu (default route), vedoucí "nahoru" doru pímo ( ) J.Peterka, MFF UK, 2005 všechno ostatní /24 cí tabulka uzlu doru pímo pomocí masky (prefixu) lze do cích tabulek zavést i specifické cí 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 /32 "host-specific J.Peterka, MFF UK, 2005 route" route" k uzlu uzlu , verze 2/2 2

3 Pravidla smrování Základní algoritmus smrování "host-specific route" by mly být používány jen výjimen velmi zvtšují objemy cí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 cích tabulek agregace položek pomáhá snižovat objem cích tabulek pomáhá i používání "default route" default route odpovídá prefixu 0 pravidlo pro prohledávání cí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: / /22 x/0 (ostatní) postup prohledávání host-specific route default route J.Peterka, MFF UK, 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 cí 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, Role hostitelských poíta a Píklad IP protokol e: úastní se všech inností v rámci smrování vetn aktualizace cích když kdyžse se hostitelský poíta poíta "chová "chovášpatn", jej jej "pouí" (poskytne mu mu správné cí informace) IP protokol hostitelský poíta hostitelské poítae: také musí volit smr penosu paketu vedou si cí informace ve svých cích tabulkách a využívají je aplikují základní algoritmus smrování ale neúastní se aktualizace cích!!! host A od A pro B Y X host B host C "na poátku" musí každý hostitelský poíta znát alespo jeden "vedoucí ven" ze sít ve které se nachází nech host A zná X (ale nikoli Y) potebuje-li host A poslat nco hostu B, pozná že jde o nepímé doruování a pošle to i X X pozná, že neleží na nejvhodnjší cest mezi hostem A a hostem B upozorní hosta A na vhodnjší (kratší) cestu na existenci e Y J.Peterka, MFF UK, J.Peterka, MFF UK, ICMP Redirect host A ICMP Redirect: pro B Y od A pro B Y X X se postará o správné doruení IP datagramu k uzlu B sám pošle data Smrovai Y, ten se postará o doruení X pošle hostu A zprávu "ICMP Redirect" ve smyslu: "datagramy pro uzel B píšt Y" host A by se ml pouit ml by si zanést Y do své cí tabulky a píšt jej použít host B host C J.Peterka, MFF UK, TYPE = 5 ICMP Redirect CODE = 0-3 IP adresa e CHECKSUM IP header plus 64 bit pvodních dat zahozeného datagramu Jde o hlášení od e, že existuje lepší cesta pro doruení IP datagramu a vede pes jiný 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 e do své cí tabulky pokud tak neuiní, nesprávn oslovený má právo jej znovu upozornit, ale nesmí jej odmítnout (musí vždy pedat data správným smrem) J.Peterka, MFF UK, , verze 2/2 3

4 C o reb u il ld er C o reb u il ld er C o reb u il ld er C o re Bu ui ld de r C o reb u il ld er Katedra softwarového inženýrství TYPE = 10 ICMP Router Solicitation CODE = 0 nepoužito (nastaveno na 0) CHECKSUM jde o "dotaz do pléna": jaké jsou tady e? ICMP zpráva je rozesílána pomocí IP broadcastu všem uzlm dané sít odpov pináší informaci o dostupných í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ý e odpovídají na dotazy ale samy také generují odpovdi (advertisement) v náhodném intervalu mezi 450 až 600 vteinami J.Peterka, MFF UK, TYPE = 9 poet položek ICMP Router Advertisement CODE = 0 délka položky CHECKSUM životnost položek adresa e, preference adresa e, preference jde o odpov na Router Solicitation, nebo o samostatn generovanou "reklamu" (advertisement) preference umožují píjemci stanovit, pes který vede implicitní cesta (default route) životnost íká, jak dlouho má být záznam o i ponechán ve cí tabulce píjemce J.Peterka, MFF UK, Aktualizace cích Smrování v ranném Internetu 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 cí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í e s úplnou pozdji: vznikla 2-úrovová struktura core e s úplnou non-core e s neúplnou ješt pozdji došlo k "dekompozici" Internetu vzniku tzv. autonomních systém (AS), které v sob lokalizují detailní cí informace a nešíí je mimo sebe J.Peterka, MFF UK, B A páte Internetu (ARPANET, NSFNET) D C E core gateway non-core gateway existovala soustava tzv. core gateways (centrálních ), 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í e byly "non-core gateways" pracovali s neúplnou o topologii Internetu "znaly" jen sít "pod sebou", provoz do ostatních sítí ly 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, J.Peterka, MFF UK, 2005 ostatní posílá pes default route 22 Smrování v ranném Internetu Další vývoj y B A páte Internetu (ARPANET, NSFNET) EGP GGP D F C E EGP G pro vzájemnou komunikaci centrálních ("core gateways") byl vytvoen protokol GGP Gateway-to-Gateway Protocol pro komunikaci mezi centrálními a "ostatními" (vnjšími) i byl vytvoen protokol EGP Exterior Gateway Protocol terminologie: pvodn se IP m íkalo "IP Gateways" proto GGP a EGP problém tohoto ešení: nebylo dostaten škálovatelné J.Peterka, MFF UK, 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, "cí 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á") cí 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. y J.Peterka, MFF UK, , verze 2/2 4

5 Pedstava autonomního systému Pedstava autonomního systému B A AS1 páteníásti Internetu D C E AS2 "navenek" neinformuje o své vnitní struktue ani o detailních cích je "autonomní" v tom smyslu, že si mže sám stanovit svou vlastní cí politiku vetn toho, jakým zpsobem je uvnit AS ešena aktualizace cích navenek 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, AS2 AS1 AS4 AS3 každý 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, Dnešní struktura Internetu Exterior Gateway Protocols NAP vzájemn alternativní pátení sít komunikace pi neexistenci peeringu komunikace pi existenci peeringu J.Peterka, MFF UK, NAP (sí upstream providera) (sí providera) mezi autonomními systém musí probíhat výmna 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, IGP Interior Gateway Protocols RIP Routing Information Protocol pipomenutí: uvnit sebe sama si každý mže ešit smrování tak jak uzná za vhodné mže aplikovat vlastní cí politiku týká se to hlavn aktualizace cích existuje více alternativních protokol, které lze použít pro aktualizaci cích 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ší y) 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é cí 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, J.Peterka, MFF UK, , verze 2/2 5

6 Protocol RIP Protocol RIP pedstava fungování 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, 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. 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. cí. tabulky síová v. linková v. již nastaví cí tabulky fyzická v. port 520 routed transportní v. cí. tabulky síová v. linková v. fyzická v. J.Peterka, MFF UK, J.Peterka, MFF UK, RIP2, RIPng Protokol OSPF (Open SPF) 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 e, pes který vede spojení do cílové sít zvyšuje efektivnost umožuje t provoz i pes e, které nepodporují RIP autentizace ochrana proti útokm skrze falešné RIP zprávy "Route Tag" 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 další informace o inzerované cest má jiný formát zpráv J.Peterka, MFF UK, je "otevenou verzí staršího protokolu všechny uzly v síti mají úplnou SPF (Shortest Path First) informaci o jednotlivých spojích a jeho specifickace jsou veejn mohou si vypoítat optimální cesty pístupné, pochází od IETF každý poítá "za sebe", chybou ovlivní je typu link-state jen sebe sama každý uzel testuje dostupnost svých OSPF podporuje alternativní cesty soused stav linky umožuje definovat rzné cesty pro každý uzel sestavuje "link state rzné druhy provozu paket", ve kterém uvede údaje o podporuje load balancing dostupnosti svých soused OSPF podporuje další "dekompozici" stav linky a její ohodnocení umožuje rozdlení sít na menší tyto pakety jsou rozesílány všem uzlm v síti/soustav sítí "areas", které jsou analogické autonomním systém v tom, že jejich staí ale jen pi zmn njakého údaje!!!! topologie není šíena mimo danou jinak pro osvžení každých 30 minut "area" minimalizuje to objemy aktualizaních J.Peterka, MFF UK, Protokol OSPF oblasti Píklad: hierarchické OSPF jde o vlastnost, která zvtšuje "dosah" OSPF umožuje vtší škálovatelnost, tj. realizovat AS celý se rozdlí na (disjunktní) oblasti jedna se prohlásí za pátení (backbone) e 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í cí informace s jinými AS J.Peterka, MFF UK, J.Peterka, MFF UK, , verze 2/2 6

7 Fungování OSPF Fungování OSPF každý OSPF si udržuje: komunikace mezi OSPF databázi pímých soused i 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ý 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 cí tabulky používají se pro samotné smrování IP paket J.Peterka, MFF UK, "nový" : 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 e ve dvojici "ohlásí svtu své sousedství" pomocí broadcastu oba rozešlou všem ostatním m 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í" 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, , verze 2/2 7