Multikast z pohledu uživatele Petr Kubín, Tubus p.kubin@sh.cvut.cz http://sut.sh.cvut.cz
Obsah kapka obecné teorie kupa další teorie příklady průchod televize natem Teorie všeobecně platná, ale ukázaná řešení pro linux
Síťování síť směrovače, přepínače, dráty unicast, broadcast, multicast, anycast pravidla, výjimky a výjimky z výjimek model ISO/OSI vrstvy procesy a jádro dnes jenom ipv4 a strahovská síť
Síťování 2 unicast nejznámější end to end, oba konce rovnocenné broadcast historický L2 i L3
Síťování 3 anycast teoreticky silný model každá implementace trochu jiná multicast
Připomenutí http://www.iana.org/assignments/ipv4-address-space rfc 3330 0.0.0.0/8 rezervováno 10.0.0.0/8 rfc 1918 127.0.0.1/8 loopback 169.254.0.0/16 zeroconf 172.16.0.0/12 rfc 1918 192.168.0.0/16 rfc 1918 224.0.0.0/4 multikast 240.0.0.0/4 rezervováno
Multicast dolepen dodatečně do ipv4 skupina jako cílová adresa celý systém přijímá a přihlašuje se, podobně jako u ICMP cílové mac adresy, historka z vývoje síťovou kartu musí ovladač přepnout k přijmu přislušné skupiny
Multicast 2 výhody datové toky cena serveru nevýhody stále nerozšířený nedořešené omezení území, špatně měřitelná sledovanost a podobné zátěž sítě
Adresy http://www.iana.org/assignments/multicast-addresses 224.0.0.0/24 lokální blok 224.0.0.0, 224.0.0.1, 224.0.0.2, 224.0.0.5, 224.0.0.6, 224.0.0.22 224.0.1.0/24 známé služby 232.0.0.0/8 source specific multicast 233.0.0.0/8 any source multicast
Adresy 2 239.0.0.0/8 rfc 2365 (obdoba 1918) 239.[0-191].*.* rezervováno 239.192.0.0/14 organisation local 239.25[2-4].*.* rezervováno 239.255.0.0/16 site local SAP: 224.0.0.255, 224.2.127.254, 239.195.255.255, 239.255.255.255 (můj vlc) obecně vždy poslední adresa přideleného 239/8 rozsahu, ale nikdo neřeší informování aplikace
IGMP povinná součást, ale šlo by to i bez něj fikaná zpětná kompatibilita v1 v2 v3
tcpdump postup: > membership report (začnou téct data) < membership query, > report > leave group igmp snooping trochu zamíchá postupem
Příklad ping 224.0.0.1 nejjednodušší program./prijimac.c ip maddr list ping6 ff02::1 -I eth0
A teď česky proces řekne jádru, aby se(!) přihlásilo do skupiny přihlášení je vlastnost celého systému Jak povolím IGMP pro vlc? - nijak, netřeba víc procesů může přijímat totéž najednou nemá smysl vysílat na stejné adrese na více portech, jenom by rostl datový tok
iptables INPUT igmp iptables -A -p 2 -j ACCEPT data iptables -A -p udp -d 224.0.0.0/4 -j ACCEPT OUTPUT igmp iptables -A -p 2 -j ACCEPT
iptables 2 poznámky: SAP: --dport 9875 -m state nefunguje -m pkttype --pkttype multicast -m ttl --ttl <n> např../iptables.sh
Směrování každý počítač s více rozhraními slouží automaticky jako směrovač směrovací rozhodnutí závisí pouze na cílové adrese ip route list; ip r list table all typicky součást jader systémů rozhodování pouze podle cílové adresy
Směrování multicastu obecně dost teorie stromy (S,G) nebo (*,G) reverse path filter tabulky co, odkud a komu dynamické směrování mnoho protokolů nevyvíjený software
Co z toho zajímá nás nezbytný směrovací démon linux posílá igmp rozhraním s 0.0.0.0/0 mrouted a pimd jsou nám na nic ani statické záznamy nejsou výhra
Co vlastně chceme 1) program si řekne jádru o data 2) přenést žádost na směrovač 3) vymyslet předávání dat 4) směrovač řekne svému zdroji... u každého ukázaného řešení si budeme všímat hlavně tohoto
Unicastem vysílací strana vlc <zdroj> --sout '#standard{ access=http,mux=ts,dst=<adr>:6543}' za <adr> dosaď ip adresu svého rozhraní pozor na paketový filtr, ať nevysílaš pro celou planetu přijímací strana vlc http://<adr>:6543
Unicastem 2 výhody: netřeba být root snadno pochopitelné nevýhody data k nám tečou už spuštěním vysílače přednáška je o multicastu obměny pomocí parametrů vlc nebo skriptováním webu
Můstek můstek s drobnou úpravou, protože jsme asi nedostali víc IP adres stylově čisté to nebude pokud je víc adres, rozhodně použij tohle, jenom bez natu./mustek.txt
Mangle tabulkou ne! v žádném případě ale poradit někomu neoblíbenému můžeme iptables -t mangle -A PREROUTING -p 2 -j TTL --ttl-inc 1 iptables -t. -A. -i eth0 -d 224../4 -j ROUTE --oif eth1 --tee iptables -t. -i eth1 -p 2 -j ROUTE --oif eth1 iptables -t nat -A. -o eth0 -j MASQUERADE navíc promiskuitní režim?
Staticky v nouzi nebo při testování smcroute -a <InputIntf> <OriginIpAdr> <McGroupAdr> <OutputIntf> přidá požadavek na směrování a -r zase zruší smcroute -j <InputIntf> <McGroupAdr> přihlásí skupinu a -l zase odhlásí potřeba vždy i -j
IGMP proxy rfc 4605 nutná topologie stromu právě jedno upstream rozhraní myšlenka připomíná igmp snooping pro nás asi nejlogičtější varianta ne-linuxoví uživatelé počkaji na příští verzi xorp nebo zkusí igmpv3proxy
igmpproxy http://sourceforge.net/projects/igmpproxy nesvobodná licence (mrouted + GPL) od 2005 asi nevyvíjený na rozdíl od jiných funguje
igmpproxy 2 stáhnout rozbalit volitelně patch -p0 <./igmpproxy-src-0.1-beta2- patch editovat Makefile make && make install
igmpproxy 3 konfigurační soubor např./igmpproxy.conf quickleave zakomentovat přidat do altnet zdrojové adresy nejmenší maska, která mi fungovala byla /8 parsování konfugurace je drobet zranitelné 147.0.0.0/8 pro nás a 194.0.0.0/8 pro Slovensko nastavit vnitřní rozhraní jako downstream
igmpproxy 4 povolit v iptables forward povolit volby v /proc /proc/sys/net/ipv4/conf/*/forwarding /proc/sys/net/ipv4/ip_forward mc_forwarding nic nedělá prostě spustit netřeba nic nového vůči stavu se samotným natem
Hledání chyb možné zádrhele: /proc nebo iptables chybka v konfiguráku nepřidávají se cesty špatně nastavená defaultní cesta ip route replace 0/0 via src <naše IP> špatně přeložené jádro rozhraní nepodporuje zrovna je výpadek
Hledání chyb 2 jak hledat: zkontrolovat zastrčení kabelu sledovat datové toky wireshark zkusit jiný software a odjinud zkontrolovat konfiguraci chvíli počkat
Doporučené čtení populární literatura dokumentace směrovacích démonů rfc vlastní experimenty seriál o multicastu na lupě