A multicast routing a linux
A jelenlegi helyzetben, a legvalószínűbb, hogy nincs értelme, hogy vegyenek részt a routing (replikáció), multicast forgalom softrouterov (akár a Linux kernel, vagy valami mást). Az ok nagyon egyszerű - még olcsóbb kapcsolók képesek L2 / L3-multicast (jóllehet korlátozások a csoportok száma / utak, de még mindig ez történik ASIC-ah). Azonban vannak olyan feladatok, amelyeket nem lehet megoldani a „vas” (nincs támogatás a program / nem lehet végrehajtani a kapacitás ASIC), például renambering (változás cél ip), a véletlenszerű késedelem (shuffle), küldés multicast az alagútban, fenntartás forrás szerinti egy tetszőleges feltétel.
Hogy vezessenek be egy véletlen késleltetés (átrendezésre) vagy veszteség lehet szükség, hogy ellenőrizze a magatartás, STB / soft-lejátszók. Például, ha kíváncsi, hogyan lesz a kép, ha valahol a hálózaton multicast áthaladnak per-packet kiegyenlítő és ne lógjon, ha a játékos jelenlétében packet loss-e közzé kellemetlen nyikorgó hangok, vagy csak négyzetek és a csend.
Amikor írom ezt a cikket használt Ubuntu Linux 14.04 LTS (3.13.0-24-generic kernel), de ez a legtöbb modern disztribúció, de meg kell, hogy ellenőrizze az IPv4 multicast támogatás a kernel:
Ellentétben unicast routing ip segédprogram nem elég, még egy statikus (S, G) útvonalon, nem is beszélve a már dinamikus. A formáció a multicast replikációs asztal igényel „harmadik fél”, egy felhasználói típus. Például, a statikus útvonalak smcroute, hogy össze egy táblázatot az IGMP-kéréseknek daunlink interfészek - igmpproxy (az útvonal a maghoz adjuk, amikor az „alulról” jön IGMP-kérelem), használható PIM-SM jelzés - pimd (támogatásra van szükség PIMSM_V2 a mag).
Statikus routing multicast
Tekintsük az alábbi problémát: hogy végre lemásolni multicast forgalom (* 233.251.240.1) az eth1 interfész eth2 és eth3 felületek, míg a eth1, ez a csoport jön csak IGMPv2-kérelmet.
Configuration interfészek az alábbiak szerint:
Sajnos smcroute ubuntu 14.04 nem támogatja a (* G) -forma, ezért meg kell fordítani a forráskódból:
Mielőtt futtatná a routing (telepíteni útvonalak a kernel), akkor ki kell kapcsolni az RPF az eth1 (állapota miatt a probléma úgy vélik, hogy a forrás IP multicast-csoport tetszőleges):
Továbbá, mi létre kifejezetten IGMP módban eth1:
Most viszont, hogy smcroute konfiguráció (/etc/smcroute.conf):
(Ehhez line feed end konfiguráció)
Az első sor - csatlakoztatott csoport IGMP protokollt (töltse ki az adatokat a mag), a második - a tényleges multicast útvonalon.
Fuss smcroute:
(Napló vannak írva a syslog)
Ellenőrizze a táblázat IGMP:
Ez így van, 01F0FBE9 mi csoport 233.251.240.1.
Mielőtt eth1 majd öntsük a multicast routing tábla a kernel fog kinézni:
Akkor ez így fog kinézni:
Ellenőrizze replikációs feladat:
Renambering multicast csoportok
Megváltoztatni az IP multicast csoport segítségével DNAT. Például meg akarjuk változtatni a 233.251.240.1 233.251.250.5:
/etc/smcroute.conf a következő lesz:
Ezután tisztítsa meg a conntrack (command "conntrack -F"), és ellenőrizze:
Mint azt sejteni lehet, hogy cserélje ki a több és a forrás IP fogjuk használni SNAT:
Ismét tiszta conntrack ( "conntrack -F"), és ellenőrizze:
Segítségével iptables és tc is tenni valamit a forgalom (add késedelem és veszteség, például). Ha szükséges, akkor intézkedik a foglalás a tv-csatorna váltás terjesztő forrás szkriptek (smcroute-működtethető „kívülről”), így akár önkényes kritériumokat, hogy kiválassza a legjobb forrás (például megoldás szolgáltatók és van egy csomó pénzt)