{"id":360,"date":"2020-04-06T08:14:35","date_gmt":"2020-04-06T06:14:35","guid":{"rendered":"http:\/\/tech.sosthe.sk\/?p=360"},"modified":"2020-04-06T22:44:19","modified_gmt":"2020-04-06T20:44:19","slug":"4-9-broadcastove-smerovanie","status":"publish","type":"post","link":"http:\/\/tech.sosthe.sk\/index.php\/2020\/04\/06\/4-9-broadcastove-smerovanie\/","title":{"rendered":"4.13. Broadcastov\u00e9 smerovanie"},"content":{"rendered":"

V s\u00favislosti s broadcastom sa pou\u017e\u00edva pojem\u00a0broadcastov\u00e1 dom\u00e9na<\/strong>, ktor\u00e1 ur\u010duje mno\u017einu siet\u00ed a routrov, v ktorej sa maj\u00fa \u0161\u00edri\u0165 broadcastov\u00e9 spr\u00e1vy. Ak si vezmeme napr\u00edklad protokol OSPF, tak broadcastov\u00fa dom\u00e9nu tvoria v\u0161etky routre v AS.<\/p>\n

Pri broadcastovom smerovan\u00ed je cie\u013eom to, aby vyslan\u00fa spr\u00e1vu dostali v\u0161etky uzly (stanice a\/alebo routre) v broadcastovej dom\u00e9ne. Broadcastov\u00e9 spr\u00e1vy sa nikdy ne\u0161\u00edria pre cel\u00fd internet, ale v\u017edy len v r\u00e1mci AS alebo v r\u00e1mci siete. Broadcastov\u00e9 smerovanie sa realizuje bu\u010f pre cel\u00fd AS alebo jeho \u010das\u0165.<\/p>\n

Broadcast by sa dal realizova\u0165 aj tak, \u017ee ka\u017ed\u00e9mu uzlu v broadcastovej dom\u00e9ne po\u0161leme k\u00f3piu spr\u00e1vy priamo zo zdroja. Ak m\u00e1me N uzlov, tak vy\u0161leme N spr\u00e1v. Toto rie\u0161enie je s\u00edce jednoduch\u00e9, ale neefekt\u00edvne. Lep\u0161ie je, ak zdrojov\u00fd uzol vy\u0161le do ka\u017ed\u00e9ho spoja iba jednu spr\u00e1vu a t\u00e1 sa rozmno\u017e\u00ed a\u017e po ceste tak, aby ka\u017ed\u00fd uzol dostal svoju k\u00f3piu a z\u00e1rove\u0148, aby \u017eiaden uzol nemusel spr\u00e1vu vysiela\u0165 viackr\u00e1t t\u00fdm ist\u00fdm spojen\u00edm.<\/p>\n

\"\"<\/p>\n

Hlavn\u00fdm probl\u00e9mom broadcastov\u00e9ho smerovania je teda zistenie, kedy je potrebn\u00e9 vytv\u00e1ra\u0165 k\u00f3pie broadcastov\u00fdch spr\u00e1v a do ktor\u00fdch spojov ich zasiela\u0165. Pop\u00ed\u0161eme si 3 pr\u00edstupy k sp\u00f4sobu broadcastov\u00e9ho smerovania: nekontrolovan\u00e9 zaplavenie, kontrolovan\u00e9 zaplavenie a spanning tree (kostra grafu).<\/p>\n

4.13.1\u2002 Nekontrolovan\u00e9 zaplavenie<\/h3>\n

Tento pr\u00edstup pou\u017e\u00edva jednoduch\u00e9 pravidlo. Ak na router pr\u00edde broadcastov\u00e1 spr\u00e1va, router vytvor\u00ed k\u00f3piu tejto spr\u00e1vy a rozo\u0161le t\u00fato spr\u00e1vu do v\u0161etk\u00fdch rozhran\u00ed okrem toho, odkia\u013e spr\u00e1va pri\u0161la. Tento pr\u00edstup m\u00f4\u017ee fungova\u0165 \u00faplne bezchybne pokia\u013e sa v grafe tvorenom routrami a spojmi nevyskytuje cyklus. Vezmime si vy\u0161\u0161ie nakreslen\u00fd obr\u00e1zok. Ak router R1 vy\u0161le spr\u00e1vu, dostane ju R2 a rozo\u0161le ju k R3 a R4. R3 dostal spr\u00e1vu od R2 tak\u017ee ju po\u0161le na v\u0161etky ostatn\u00e9 rozhrania, teda k routru R4, ten ju prepo\u0161le op\u00e4\u0165 k R2, ktor\u00e1 ju zas prepo\u0161le k R1 a R3. Tak\u00e1to situ\u00e1cia vy\u00fasti k nekone\u010dn\u00e9mu cykleniu dvoch spr\u00e1v, jednej v smere a druh\u00e9 proti smeru hodinov\u00fdch ru\u010di\u010diek. Ak v\u0161ak m\u00e1me v grafe viac cyklov, doch\u00e1dza k nekontrolovan\u00e9mu mno\u017eeniu broadcastov\u00fdch spr\u00e1v. Tak\u00e9mu javu hovor\u00edme broadcastov\u00e1 b\u00farka, ktor\u00e1 vedie k \u00fapln\u00e9mu zahlteniu v\u0161etk\u00fdch routrov v broadcastovej dom\u00e9ne.<\/p>\n

4.13.2\u2002 Kontrolovan\u00e9 zaplavenie<\/h3>\n

K\u013e\u00fa\u010dom k zabr\u00e1neniu nekone\u010dn\u00fdch rozosielan\u00ed pri kontrolovanom zaplavovan\u00ed je zistenie routra, \u017ee dan\u00fa spr\u00e1vu u\u017e raz rozosielal a nebude to robi\u0165 op\u00e4\u0165.<\/p>\n

Jedn\u00fdm rie\u0161en\u00edm je, \u017ee ka\u017ed\u00fd p\u00f4vodn\u00fd odosielate\u013e spr\u00e1vy pribal\u00ed k spr\u00e1ve aj jedine\u010dn\u00e9 \u010d\u00edslo broadcastovej spr\u00e1vy. Ka\u017ed\u00fd uzol si potom mus\u00ed pam\u00e4ta\u0165 v\u0161etky \u010d\u00edsla spr\u00e1v, ktor\u00e9 u\u017e rozosielal a v pr\u00edpade, \u017ee u\u017e \u00e1no, tak ich druh\u00fdkr\u00e1t nerozo\u0161le. Tento pr\u00edstup vyu\u017e\u00edva Gnutella.<\/p>\n

Druh\u00fd pr\u00edstup ku kontrolovan\u00e9mu zaplaveniu je\u00a0reverse path forwarding (RPF)<\/strong>. Idea RPF je jednoduch\u00e1. Pokia\u013e pr\u00edde na nejak\u00fd uzol broadcastov\u00e1 spr\u00e1va, tak ju rozpo\u0161le cez v\u0161etky rozhrania okrem prij\u00edmaj\u00faceho iba vtedy, ak t\u00e1to spr\u00e1va pri\u0161la cez rozhranie, ktor\u00e9 je s\u00fa\u010das\u0165ou najkrat\u0161ej unicastovej cesty k zdrojov\u00e9mu uzlu. V opa\u010dnom pr\u00edpade je spr\u00e1va zahoden\u00e1. Vyu\u017e\u00edva teda smerovaciu tabu\u013eku ur\u010den\u00fa pre unicastov\u00e9 smerovanie. Toto vyu\u017eitie je tak trochu obr\u00e1ten\u00e9, lebo smerovacia tabu\u013eka nastavuje smerovanie odch\u00e1dzaj\u00facich spr\u00e1v a pri RPF filtrujeme prich\u00e1dzaj\u00face broadcastov\u00e9 spr\u00e1vy. Na nasleduj\u00facom obr\u00e1zku m\u00f4\u017eeme vidie\u0165, ako sa bude \u0161\u00edri\u0165 broadcastov\u00e1 spr\u00e1va z uzla A do cel\u00e9ho grafu pri pou\u017eit\u00ed RPF. Hrubou \u010diarou s\u00fa nazna\u010den\u00e9 spoje, ktor\u00e9 s\u00fa na najkrat\u0161ej ceste od jednotliv\u00fdch uzlov k uzlu A. \u0160\u00edpky s obd\u013a\u017eni\u010dkom ozna\u010duj\u00fa spr\u00e1vy, ktor\u00e9 bud\u00fa prij\u00edmaj\u00facim routrom zahoden\u00e9.<\/p>\n

\"\"<\/p>\n

4.13.3\u2002 Spanning tree (kostra grafu)<\/h3>\n

Aj ke\u010f predch\u00e1dzaj\u00face techniky zabra\u0148uj\u00fa broadcastov\u00fdm b\u00farkam, predsa len sa st\u00e1va, \u017ee niektor\u00e9 uzly dostan\u00fa viac k\u00f3pi\u00ed tej istej spr\u00e1vy. Rie\u0161en\u00edm aj tohto nedostatku je pr\u00e1ve smerovacia sch\u00e9ma spanning tree.<\/p>\n

Pri spanning tree sa e\u0161te pred odoslan\u00edm prvej broadcastovej spr\u00e1vy mus\u00ed vyrobi\u0165 strom rozosielania obsahuj\u00faci v\u0161etky uzly. Hrany tohto stromu tvoria vybran\u00e9 spojenia medzi uzlami. Ak je u\u017e strom rozosielania hotov\u00fd, broadcastov\u00e9 spr\u00e1vy sa \u0161\u00edria iba pozd\u013a\u017e hr\u00e1n tohto stromu. Ke\u010f\u017ee ide o strom, neexistuj\u00fa v \u0148om cykly a ka\u017ed\u00fd uzol dostane v\u017edy iba jednu k\u00f3piu broadcastovej spr\u00e1vy.<\/p>\n

Samozrejme je ide\u00e1lne, ak tento strom bude minim\u00e1lny. Ur\u010dite si spom\u00ednate na minim\u00e1lnu kostru grafu, ktor\u00e1 sa preberala v predmete PAZ1b. Kruskalov algoritmus, ktor\u00fd sa na PAZ1b preber\u00e1, v\u0161ak vy\u017eaduje \u00fapln\u00fa znalos\u0165 topol\u00f3gie siete. Met\u00f3da spanning tree negeneruje v\u017edy minim\u00e1lny strom. Pred vytvoren\u00edm stromu sa uzly musia dohodn\u00fa\u0165, ktor\u00fd z uzlov grafu bude centr\u00e1lny uzol (naz\u00fdvan\u00fd aj rendezvous point). Potom v\u0161etky uzly po\u0161l\u00fa prip\u00e1jaciu unicastov\u00fa spr\u00e1vu smerom k centr\u00e1lnemu uzlu. Ako spr\u00e1va prech\u00e1dza jednotliv\u00fdmi routrami na ceste k centr\u00e1lnemu uzlu, routre si zazna\u010duj\u00fa, \u017ee hrany, po ktor\u00fdch pre\u0161la, s\u00fa s\u00fa\u010das\u0165ou stromu. Ak tak\u00e1to spr\u00e1va d\u00f4jde na uzol, ktor\u00fd u\u017e je s\u00fa\u010das\u0165ou stromu, spr\u00e1va sa zahadzuje, lebo by aj tak \u0161la iba po t\u00fdch spojeniach, ktor\u00e9 u\u017e s\u00fa s\u00fa\u010das\u0165ou stromu. T\u00fdm p\u00e1dom aj na vytvorenie stromu je potrebn\u00e9 posla\u0165 iba to\u013eko spr\u00e1v, ko\u013eko je hr\u00e1n vo v\u00fdslednom strome, a teda to\u013eko spr\u00e1v, ako pri \u0161\u00edren\u00ed u\u017e be\u017enej broadcastovej spr\u00e1vy.<\/p>\n","protected":false},"excerpt":{"rendered":"

V s\u00favislosti s broadcastom sa pou\u017e\u00edva pojem\u00a0broadcastov\u00e1 dom\u00e9na, ktor\u00e1 ur\u010duje mno\u017einu siet\u00ed a routrov, v ktorej sa maj\u00fa \u0161\u00edri\u0165 broadcastov\u00e9 spr\u00e1vy. Ak si vezmeme napr\u00edklad…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[9],"tags":[],"_links":{"self":[{"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/posts\/360"}],"collection":[{"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/comments?post=360"}],"version-history":[{"count":3,"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/posts\/360\/revisions"}],"predecessor-version":[{"id":537,"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/posts\/360\/revisions\/537"}],"wp:attachment":[{"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/media?parent=360"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/categories?post=360"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/tech.sosthe.sk\/index.php\/wp-json\/wp\/v2\/tags?post=360"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}