Hlavní navigace

Úvod do IP multicastu (díl druhý)

Ondřej Filip 20. 9. 2004

V minulém dílu jsme si vysvětlili základy forwardování multicastu, dnes se pokusíme trochu blíže podívat na princip multicastového forwardování. Povíme si, která rozhodnutí musí router učinit, když k němu nějaký ten mutlticastový packet dorazí.

předchozím povídání o multicastu jsme se nedotkli pravidel, podle kterých se router rozhoduje. Situace v unicastovém světě je poměrně jednoduchá. Router si pomocí dynamického routovacího protokolu nastaví routovací tabulku nebo mu ji v jednodušších připadech nastaví ručně operátor. Pokud tomuto routeru přijde packet na libovolný interface, sníží tomuto packetu nejprve parametr TTL (Time To Live) o jedna, a pokud je tento parametr stále vyšší než nula, prozkoumá routovací tabulku. Pokud v ní pro cílovou adresu packetu najde odpovídající řádku, přepošle packet na příslušný interface následujícímu routeru (next hop). Už jen fakt, že při multicastu se packety často zdvojují, dává tušit, že situace zde nebude zdaleka tak jednoduchá.

Hlavní odlišnost je v tom, že s cílovou adresou packetu router nevystačí. Jeho rozhodnutí co dál je ovlivněno ještě tím, jakou má ten packet zdrojovou adresu a z jakého interface mu přišel.

Proč je to tak komplikované? Jak již bylo zmíněno minule, při multicastovém forwardování je nutné ošetřit více věcí. Protože se packet duplikuje, je nutné pečlivě hlídat, aby těchto duplikací nebylo příliš a aby packet k příjemci došel pouze v jednom exempláři a nikoliv vícekrát. Pokud by se toto dělo, zátěž sítě by mohla být i vyšší než u obyčejného unicastu.

Jak by se to mohlo stát? Pokud bychom to nehlídali, tak poměrně snadno. Představme si model velmi podobný unicastovému světu, ve kterém by si každý router postavil pouze tabulku destinací, kde se nacházejí příjemci dané multicastové skupiny. Pokud by mu někdo zaslal packet určený pro takovou skupinu, prostě by jej jen rozeslal na všechny interface, kde se takoví příjemci nacházejí. Následující sekvence obrázků ilustruje, jak by taková situace mohla vypadat.

1344

1345

1346

1347

1348

Jak vidíte, packet se neustále množí. Díky neustálému snižování parametru TTL (Time To Live) by se sice nemnožil navěky, ale rozhodně by spotřeba pásma byla několikanásobně vyšší, než je nutné. Stejně tak koncová zařízení dostanou svou zprávu několikrát, což se zbytečně zatěžuje.

Mnoho lidí jistě napadne jednoduchá úprava, že by tedy router neposílal packet zpět na interface, ze kterého ten packet obdržel. Taková situace je o něco lepší – k nadměrné duplikaci by v některých jednoduchých sítích nedocházelo, ale obecně nám to nepomůže. Tento příklad ilustruje následující sekvence.

1349

1350

1351

1352

Jak je vidět, stále to ještě není ono. Sice nám v tomto primitivním konkrétním případě packety vymizely dříve, než zasáhl mocný mechanismus TTL, nicméně každý si jistě umí představit topologii, kde tomu tak nebude. Navíc i zde bylo zatížení sítě vyšší, než je nutné, a opět jsou koncová zařízení otravována duplicitními packety.

Proto byl vymyšlen způsob, kterému se říká Reverse Path Forwarding (RPF). Router si stále drží unicastovou routovací tabulku. Tuto tabulku získává buď od operátora, z klasických routovacích protokolů (nebo jejich odvozenin, jako je MBGP), případně si ji sestavuje pomocí speciálních multicastových protokolů (například DVMRP). Často může jít i o více tabulek dohromady.
Pokud pak routeru přijde multicastový packet, zjistí si jeho zdrojovou adresu a interface, ze kterého přišel.
Potom otestuje, zda-li by stejným směrem poslal i unicastový packet, jehož cílová adresa by byla rovna té zdrojové u multicastového. Pokud test neprojde, packet je zahozen, v opačném případě packet pokračuje k dalším zpracování.

Raději se na to podívejme na příkladě. Představme si router A s následující routovací tabulkou:

Síť             Maska           Interface
192.168.0.0     255.255.255.0   eth0
192.168.1.0     255.255.255.0   eth1
192.168.2.0     255.255.255.0   eth2
192.168.3.0     255.255.255.0   eth3

Tento obrázek ukazuje situaci, kdy RPF test (anglicky RPF check) neuspěje:

1353

Jak je vidět, packet se zdrojovou adresou 192.168.1.1 a cílovou adresou 225.1.1.1 přijde přes interface eth3. Unicastová routovací tabulka ale říká, že packety pro 192.168.1.1 by se posílaly přes interface eth1. Packet je tedy zahozen.

Naopak tento obrázek ukazuje situaci příznivější:

1354

Packet přijde z interface, ze kterého je očekáván, a v dalším kroku tedy bude za odměnu rozeslán dle příslušné multicastové tabulky.

Router přirozeně nedělá toto rozhodnutí s každým packetem, to by ho velmi zatěžovalo. Obvykle je takto zkontrolován pouze první packet a záznam o tomto testu je uložen do cache. Testování následujících packetů je pak již mnohem rychlejší. Tuto cache je nutné obnovovat při změně unicastové routovací tabulky.

Forwardování tedy máme za sebou a v příštím díle si povíme něco více o tom, jak se routery dozví, kam mají packety rozesílat, tedy o multicastových dynamických routovacích protokolech.

Anketa

Setkáváte se v praxi s multicastem?

Našli jste v článku chybu?

20. 9. 2004 8:52

Dan Lukes (neregistrovaný)
Konecne technicky zamereny clanek s urovni nikoli pro naproste laiky (jeste jsou clanky Rity Puzmanove, ale ty nejsou tak uplne v "mem" oboru).

Problem, ktery resi RPF test jsem si sam od sebe neuvedomil. Ale ten test neni snad tak jednoduchy. Vzdyt v unicastovych sitich neni vyloucen (a skutecne se obcas pouziva) asymetricky routing, kdy prichozi a odchozi cesta paketu neni uplne totozna a tak paket muze v nekterych mistech prijit i z jineho smeru, nez do ktereho odejde paket "zpatecni".

Budu s…

Root.cz: Chytré hodinky Pebble úplně končí

Chytré hodinky Pebble úplně končí

Měšec.cz: Air Bank zruší TOP3 garanci a zdražuje kurzy

Air Bank zruší TOP3 garanci a zdražuje kurzy

Podnikatel.cz: Přehledná titulka, průvodci, responzivita

Přehledná titulka, průvodci, responzivita

DigiZone.cz: Milan Kruml: procházka TV historií

Milan Kruml: procházka TV historií

120na80.cz: Rovnátka, která nejsou vidět

Rovnátka, která nejsou vidět

Podnikatel.cz: 3, 2, 1..EET startuje. Na co nezapomenout?

3, 2, 1..EET startuje. Na co nezapomenout?

DigiZone.cz: ČT má dalšího zástupce v EBU

ČT má dalšího zástupce v EBU

Root.cz: 250 Mbit/s po telefonní lince, když máte štěstí

250 Mbit/s po telefonní lince, když máte štěstí

Měšec.cz: Banky mlží o nákladech na předčasnou splátku hypotéky

Banky mlží o nákladech na předčasnou splátku hypotéky

Vitalia.cz: Pravda o přibírání na zimu

Pravda o přibírání na zimu

Podnikatel.cz: Udávání kvůli EET začalo

Udávání kvůli EET začalo

DigiZone.cz: Flix TV má set-top box s HEVC

Flix TV má set-top box s HEVC

Podnikatel.cz: Babiše přesvědčila 89letá podnikatelka?!

Babiše přesvědčila 89letá podnikatelka?!

120na80.cz: Stoná vaše dítě často? Upravte mu jídelníček

Stoná vaše dítě často? Upravte mu jídelníček

Měšec.cz: Golfové pojištění: kde si jej můžete sjednat?

Golfové pojištění: kde si jej můžete sjednat?

Měšec.cz: Jak levně odeslat balík přímo z domu?

Jak levně odeslat balík přímo z domu?

Root.cz: Mirai má nový cíl 5 milionů routerů

Mirai má nový cíl 5 milionů routerů

Vitalia.cz: Spor o mortadelu: podle Lidlu falšovaná nebyla

Spor o mortadelu: podle Lidlu falšovaná nebyla

DigiZone.cz: HD programy ČT i v UPC Horizon

HD programy ČT i v UPC Horizon

DigiZone.cz: Rádio Šlágr má licenci pro digi vysílání

Rádio Šlágr má licenci pro digi vysílání