Služba IPTV od poskytovatele

Stále více ruských poskytovatelů kromě poskytování služeb přístupu k internetu nabízí možnost sledovat standardní televizi. IPTV. Podívejme se, jaké výhody získáváme z používání tohoto standardu.

Výhody IPTV oproti klasické pozemní televizi

• Na vašem PC není potřeba instalovat TV tuner.
• Možnost pozastavení přehrávání kanálu na určitou dobu.
• IPTV může poskytovat další služby, jako je Video na vyžádání (VOD, Video On Demand).

Televizi ve formátu IPTV lze přijímat dvěma způsoby – prostřednictvím speciálního set-top boxu poskytovaného poskytovatelem nebo zakoupeného samostatně. IPTV lze také přehrávat pomocí softwarového přehrávače, jako je např IP TV přehrávač. Tato aplikace je doplňkem pro populární přehrávač VLC. Chcete-li zobrazit kanály, zadejte město a poskytovatele poskytující službu IPTV. V důsledku toho se do programu načte seznam kanálů a vy můžete sledovat video.

Softwarové přehrávače pro hraní IPTV: VLC, IPTV přehrávač, PC přehrávač atd.

Nejpalčivější problém pro uživatele při nastavování IPTV přes router- pro bezproblémový provoz je správné tento standard nakonfigurovat ve webovém rozhraní wi-fi routeru. Ne všechny routery jsou pro tyto účely vhodné.

Pozornost! Seznam routerů s podporou IPTV můžete to zjistit zavoláním svého poskytovatele nebo na oficiálních stránkách. Nebo použijte.

Směrovače pro provoz IPTV: Bezdrátové směrovače 54 Mbps (řada G), bezdrátové směrovače 150 Mbps (řada N), bezdrátové směrovače 300 Mbps (řada N) a vyšší.

Pro distribuce IPTV přes bezdrátové připojení bez prefixu (takové připojení je možné použít pouze při nekódovaném signálu), teoreticky je možné použít obrovské množství routerů, ale v praxi lze nepřerušovaného provozu z routeru dosáhnout pouze s alternativním firmwarem. Netgear WNR 3500L stabilně spolupracuje s IPTV s firmwarem od rajčete. Asus WL520g s firmwarem od oleg. Upozorňuji na skutečnost, že IPTV přes kabel a přes vzduch se liší způsoby implementace IPTV v bytě, IPTV přes vzduch musí být schopen zpracovat váš router a aby IPTV fungovalo, musíte zasahovat do firmwaru routeru.

Nezapomeňte také na pokrytí bezdrátové sítě, někdo bude muset síť optimalizovat a někdo se setká s „lagy“ a artefakty obrazu, když je klient (PC, notebook, TV) odstraněn z routeru. V některých případech je nutné provést konverzi UDP multicast Streamování IPTV na TCP Unicast. Tento postup je možný pomocí speciálního nástroje UDP na HTTP, která promění dopravu. Tato aplikace musí být aktivní na PC s IPTV připojeným přes kroucenou dvoulinku, ale to vyžaduje neustále aktivní počítač (severní nebo síťový klient), nebo zvolit router, který dokáže převádět provoz (s podporou pro udpxy). V tomto případě konverzi streamu provede router.

UDP-to-HTTP proxy navržený ke konverzi udp multicast Provoz IPTV na provoz tcp-unicast (konkrétně http). To je užitečné pro pohodlné sledování. IPTV přes WiFi, NAT, na PDA, spotřebitelských přehrávačích a herních konzolích.

IPTV přes router

Často kvůli práci IPTV na počítači přes wi-fi router, nemusíte na samotném zařízení nic konfigurovat. Aktualizujte verzi firmwaru vašeho zařízení a následně bude podpora IPTV na routeru automaticky povolena. Musíte pouze vybrat zařízení (router) s podporou IPTV ( protokol IGMP).

IGMP (Internet Group Management Protocol)- Jedná se o protokol pro správu multicastového (multicast) přenosu dat v sítích založených na protokolu IP. protokol IGMP používané routery k uspořádání síťových zařízení do skupin. Každý, kdo hledal informace na fórech, nejednou narazil na tento koncept multicast. IGMP se používá k podpoře streamovaného videa, což efektivně ovlivňuje implementaci streamu IPTV. Okamžitě zkontrolujte, zda firewall, firewall nebo antivirus neblokují tento protokol. Multicast, obvykle se aktivuje s opcí Povolit vícesměrové směrování.

Pozornost! Aktivní multicast u některých modelů routerů často „ucpává“ místní síť, zejména wi-fi.

IPTV přes set-top box

Pro provoz IPTV prostřednictvím set-top boxu se doporučuje použít funkci Most. Proto konfigurujeme porty LAN pro přepínání režimu s WAN. Navíc získáme možnost připojit kabel poskytovatele nikoli k WAN, ale k LAN portu, který je kombinován s WAN. Upozorňujeme, že ne všechny routery tuto funkci podporují. Například u routerů TP-LINK je tato funkce přítomna v nabídce Síťový most(Network - Bridge), v Asusu se tomu říká Vyberte WAN Bridge Port atd. Pro provoz IPTV stačí vybrat LAN port, který použijeme k připojení IPTV set-top boxy.

Pro ty, kteří chtějí využívat více set-top boxů, je možné zvolit dva porty (například LAN3 a LAN4, pokud máte dva set-top boxy). Pokud váš model wi-fi routeru nepodporuje Most a dostatečnou podporu pro vašeho ISP multicast (protokol IGMP), můžete sledovat IPTV prostřednictvím set-top boxu.

Abyste nehledali problémy s přenosem vaší IP televize tam, kde neexistuje, zkontrolujte, zda televize funguje bez routeru. Chcete-li to provést, připojte počítač přímo ke kabelu poskytovatele. Li IPTV nedává vitální funkce, pak je s největší pravděpodobností problém u vašeho poskytovatele. Kontaktujte technickou podporu. A v pozitivním případě přímého spojení byste se měli u nich ověřit. podpora stačí multicast pro IP TV.

Uživatelé, jejichž modely routerů nepodporují funkce Most, ale televize funguje přerušovaně („obraz se drolí“ a zvuk „zasekává“), měli byste věnovat pozornost vytížení jejich routerů. To platí zejména pro ty, kteří mají vysokou rychlost stahování, nadměrné zatížení (velký počet aktivních stahování torrentů, práce v DC ++ atd.). Tyto problémy můžete vyřešit omezením rychlosti stahování, omezením počtu současných připojení na 50. Pro ty, kteří používají modely bez podpory Most Doporučuje se připojit ne více než jeden IPTV set-top boxy. Pokud používáte dva (nebo více) set-top boxů a router nepodporuje funkce Bridge, můžete použít běžný přepínač. Přepínač musí být nainstalován před routerem. K přepínači budou připojeny dva IPTV set-top boxy, kabel od vašeho poskytovatele a kabel z routeru do WAN portu.

Jak nastavit IPTV

Například, Nastavení IPTV na routeru D-Link DIR-300 a podobných modelech je potřeba nastavit pouze jedno zaškrtnutí v položce „Enable multicast streams“:

Pro mě osobně, Nastavení IP TV pro kabelové připojení bylo zredukováno na několik kroků (na příkladu routeru Asus 520GU):

• Musíte jít do sekcechřadnout, po aktivaci DHCP
• přejděte na kartu Všeobecné
• najít položku Výběr portu IPTV STB- vyberte ze seznamu port, ke kterému bude připojen IPTV set-top box.
• Klikněte Aplikovat a všechno.

Nastavení IPTV na routeru ASUS

Nyní popíšu 2 způsoby, jak nastavit IPTV přes router RT-G32 B

Pozornost! Popsaný návod na nastavení IPTV lze pro přehlednost použít i na jiné modely routerů Asus a nejen Asus v praktickém i teoretickém využití.

1 způsob. Přejděte do sekce LAN —> Trasa a zaškrtněte políčko "Povolit směrování vícesměrového vysílání" - "Ano". Uložit - Použít.

V tomto případě bude multicastový stream pro přehrávač VLC vysílán do místní sítě beze změn.

Výhody této metody:
1. Pro přehrávač VLC nemusíte provádět žádná další nastavení.

Nevýhody:
1. Možnost připojení počítače pro sledování IPTV pouze pomocí kroucené dvoulinky (ethernetový kabel).
2. Snižte rychlost internetového připojení na ostatních počítačích v místní síti v době přehrávání IPTV.
3. Velké zatížení routeru.
4. Nadměrný multicast provoz v rámci sítě.

2 způsobem. Musíte nastavit funkci „IPTV UDP Multicast to HTTP Proxy“. Přejděte do sekce LAN —> Trasy a zaškrtněte políčko „Povolit směrování vícesměrového vysílání“ - „Ano“ a v poli „IPTV UDP
Multicast to HTTP Proxy“ vyberte libovolný port. Například 2323. Uložte změny - „Použít“.

Výhody této metody:

1. Možnost sledovat IPTV na počítači přes WiFi připojení.
2. U ostatních počítačů v místní síti nedochází při připojení k internetu k poklesu rychlosti.
3. Router se nerestartuje.
4. Multicastový provoz není vysílán do vnitřní sítě a VLC přehrávač zachycuje video stream z wifi routeru.

Nevýhody:

1. Musíte změnit seznam stop pro přehrávač médií, který používáte.

Úpravy, které je třeba provést v seznamu stop VLC při použití funkce „IPTV UDP Multicast to HTTP Proxy“:

Otevřete seznam skladeb v textovém editoru.
Najděte řádky ve tvaru − udp://@ 239.23.0.200:1234/ a odstranit část, kterou jsem zvýraznil tučně. Vše je potřeba změnit.
Na místo odstraněné části udp://@ vložit - http://192.168.1.1:2323/udp/, kde 192.168.1.1 - IP adresa vašeho wi-fi routeru a 2323 - port proxy, který jste vybrali.
Výsledkem bude řetězec − http://192.168.1.1:2323/udp/239.23.0.200:1234/

Na co si dát pozor při připojování IPTV :

Použití set-top boxu IPTV:

Aktivace opce VybratWANMostpřístav A výběr jednoho nebo více LAN porty routeru pro připojení IPTV set-top boxů.

Používání počítače ke sledování IPTV (kabelové a bezdrátové připojení)

Aktivace možnosti " umožnitmulticastsměrování", který zakáže filtrování multicast provoz a přesměrování do vnitřní podsítě na LAN v případě potřeby rozhraní. Nezapomeňte povolit aktivitě programu prohlížet IPTV ve firewallu.

Pro uživatele IPTV využívající možnost bezdrátového připojení, aby se zabránilo "lagy" a "artefakty" potřebovat možnost Multicasthodnotit(Mbps), pomocí kterého můžete omezit šířku pásma multicastový provoz odeslány do bezdrátového rozhraní. Doporučuje se nastavit maximální hodnotu, abyste se vyhnuli přerušení Wi-Fi připojení na jiných bezdrátových klientech při procházení.

Verze 3 podporuje vše, co podporuje IGMPv2, ale existuje řada změn. Za prvé, hlášení se již neposílá na skupinovou adresu, ale na adresu služby multicast 224.0.0.22 . A adresa požadované skupiny je uvedena pouze uvnitř paketu. To se provádí za účelem zjednodušení práce IGMP Snooping, o kterém budeme hovořit.

Za druhé, a co je důležitější, IGMPv3 začal podporovat čisté SSM. Jedná se o tzv. V tomto případě může klient nejen požádat o skupinu, ale také určit seznam zdrojů, ze kterých by chtěl přijímat návštěvnost nebo naopak. V IGMPv2 klient jednoduše požaduje a přijímá skupinový provoz, aniž by se staral o zdroj.

Proto je IGMP navržen pro interakci mezi klienty a routerem. Proto návrat k Příklad II, kde není router, můžeme autoritativně konstatovat - IGMP není nic jiného než formalita. Neexistuje žádný router a klient nemá od koho požádat o multicastový stream. A video bude fungovat z toho prostého důvodu, že stream už sype z vypínače – stačí ho zvednout.

Připomeňme, že IGMP nefunguje pro IPv6. Existuje protokol MLD.

Zopakujme si to znovu

*Dump filtrovaný pomocí IGMP*.


1. První věc, kterou router udělal, bylo odeslání svého obecného dotazu IGMP poté, co povolil IGMP na svém rozhraní, aby zjistil, zda existují nějací příjemci, a prohlásil, že chce být dotazovačem. V té době v této skupině nikdo nebyl.
2. Pak se objevil klient, který chtěl přijímat provoz ze skupiny 224.2.2.4 a poslal svůj IGMP Report. Poté do něj šel provoz, ale byl odfiltrován ze skládky.
3. Poté se router rozhodl z nějakého důvodu zkontrolovat, zda existují další klienti a znovu odeslal IGMP General Query, na který byl klient nucen odpovědět ( 4 ).
5. Směrovač pravidelně (jednou za minutu) kontroluje, zda stále existují příjemci pomocí obecného dotazu IGMP, a hostitel to potvrdí zprávou IGMP.
6. Pak si to rozmyslel a opustil skupinu zasláním IGMP Leave.
7. Router obdržel Dovolenou a chce se ujistit, že nejsou žádní další příjemci, odešle IGMP Group Specific Query... dvakrát. A po vypršení časovače sem přestane posílat provoz.
8. Stále však pokračuje v odesílání dotazu IGMP do sítě. Například v případě, že jste nevypnuli přehrávač, ale prostě někde s problémem s připojením. Poté se spojení obnoví, ale klient sám zprávu nepošle. A zde odpovídá Query. Tok lze tedy obnovit bez zásahu člověka.

Ještě jednou

IGMP- protokol, kterým se router dozví o přítomnosti příjemců multicastového provozu a o jejich odpojení.
- zasílané klientem při připojení a jako odpověď na dotaz IGMP. Znamená, že klient chce přijímat provoz z určité skupiny.
- pravidelně zasílané routerem pro kontrolu, které skupiny jsou aktuálně potřeba. Cílová adresa je 224.0.0.1.
Bezpečnostní dotaz skupiny IGMP- odeslané routerem jako odpověď na zprávu Leave, aby se zjistilo, zda jsou v této skupině další příjemci. Adresa multicastové skupiny je určena jako adresa příjemce.
- zasílá klient, když chce skupinu opustit.
Dotazovatel- pokud je v jednom segmentu vysílání více routerů, které mohou vysílat, je jeden z nich vybrán jako hlavní - Querier. Bude pravidelně posílat dotaz a přenášet provoz.

Podrobný popis všech podmínek IGMP.

PIM

Takže jsme přišli na to, jak klienti informují nejbližší router o svých záměrech. Nyní by bylo hezké posílat provoz od zdroje k příjemci přes velkou síť.

Pokud se nad tím zamyslíte, stojíme před poměrně složitým problémem - zdroj vysílá pouze do skupiny, neví nic o tom, kde jsou příjemci a kolik jich je.
Příjemci a jejich nejbližší routery vědí pouze to, že potřebují provoz určité skupiny, ale netuší, kde je zdroj a jakou má adresu.
Jak zajistit provoz v takové situaci?

Existuje několik protokolů pro směrování vícesměrového provozu: DVMRP, MOSPF, CBT – všechny řeší tento problém různými způsoby. Ale de facto se stal standardem PIM - Protocol Independent Multicast.
Jiné přístupy jsou tak neudržitelné, že to někdy i jejich vývojáři prakticky přiznávají. Zde je například výňatek z RFC o protokolu CBT:
CBT verze 2 není a nebyla zamýšlena jako zpětně kompatibilní s verzí 1; neočekáváme, že to způsobí rozsáhlé problémy s kompatibilitou, protože se domníváme, že CBT není v této fázi vůbec široce nasazeno.

PIM má dvě verze, které lze dokonce nazvat dvěma různými protokoly, v zásadě jsou velmi odlišné:

• PIM Dense Mode (DM)
• PIM Sparse Mode (SM)

Je nezávislý, protože není svázán s žádným konkrétním protokolem směrování provozu unicast a později uvidíte proč.

Režim PIM Dense

snaží vyřešit problém dodání multiakustiky do čela. Zjevně předpokládá, že příjemci jsou všude, ve všech koutech sítě. Proto zpočátku zahltí celou síť multicastovým provozem, to znamená, že jej pošle na všechny porty, kromě toho, odkud přišel. Pokud se později ukáže, že někde není potřeba, pak se tato větev „odřízne“ pomocí speciální zprávy PIM Prune – provoz se tam již neposílá.

Ale po nějaké době se router znovu pokusí poslat multicast do stejné pobočky - najednou jsou tam příjemci. Pokud se neobjeví, je větev na určitou dobu opět odříznuta. Pokud se mezi těmito dvěma událostmi na routeru objevil klient, je odeslána zpráva Graft – router si vyžádá uříznutou větev zpět, aby nečekal, až se mu něco přenese.
Jak vidíte, o určování cesty k příjemcům zde nemůže být řeč – návštěvnost se k nim dostane jednoduše proto, že je všude.
Po „ořezání“ nepotřebných větví zůstane strom, po kterém se přenáší multicastový provoz. Tento strom se nazývá SPT - Strom nejkratší cesty.

Je bez smyček a využívá nejkratší cestu od přijímače ke zdroji. V podstatě je velmi podobný Spanning Tree v STP, kde kořen je zdrojem.

SPT je specifický druh stromu - strom nejkratší cesty. Obecně se každý strom vícesměrového vysílání nazývá .

PIM DM se má používat v sítích s vysokou hustotou multicastových klientů, což vysvětluje jeho název (Dense). Realita je ale taková, že tato situace je spíše výjimkou a PIM DM často není praktické.

To, co nás nyní opravdu zajímá, je mechanismus vyhýbání se smyčce.
Představte si takovou síť:

Jeden zdroj, jeden cíl a mezi nimi nejjednodušší IP síť. PIM DM běží na všech routerech.

Co by se stalo, kdyby neexistoval žádný speciální mechanismus vyhýbání se smyčce?
Zdroj odesílá multicastový provoz. R1 jej přijme a v souladu s principy PIM DM odešle na všechna rozhraní, kromě toho, odkud přišel - tedy na R2 a R3.

R2 dělá úplně to samé, to znamená, že posílá dopravu na R3. R3 nemůže určit, že se jedná o stejný provoz, který již přijal od R1, a tak jej předává na všechna svá rozhraní. R1 získá kopii provozu z R3 a tak dále. Tady to je - smyčka.

Co PIM v takové situaci nabízí? RPF - Reverse Path Forwarding. Toto je hlavní princip přenosu multicastového provozu v PIM (jakéhokoli druhu: DM i SM) – provoz ze zdroje musí přicházet po nejkratší cestě.
To znamená, že pro každý přijatý multicastový paket se na základě směrovací tabulky zkontroluje, zda pochází odtud.

1) Router se podívá na zdrojovou adresu multicastového paketu.
2) Zkontroluje směrovací tabulku, přes které rozhraní je dostupná zdrojová adresa.
3) Zkontroluje rozhraní, přes které přišel paket multicast.
4) Pokud se rozhraní shodují - vše je v pořádku, paket multicast je přeskočen, pokud data přicházejí z jiného rozhraní - budou zahozena.
V našem příkladu R3 ví, že nejkratší cesta ke zdroji je přes R1 (statická nebo dynamická cesta). Proto jsou pakety multicast přicházející z R1 kontrolovány a přijímány R3, zatímco ty přicházející z R2 jsou vyřazeny.

Tato kontrola se nazývá Kontrola RPF a díky němu ani ve složitějších sítích nedojde ke smyčkám v MDT.
Tento mechanismus je pro nás důležitý, protože je relevantní i v PIM-SM a funguje tam stejným způsobem.
Jak vidíte, PIM se spoléhá na unicastovou směrovací tabulku, ale za prvé sám provoz nesměruje a za druhé je mu jedno, kdo a jak tabulku naplnil.

Zde se nezastavíme a podrobně zvážíme práci PIM DM - jedná se o zastaralý protokol se spoustou nedostatků (dobře jako RIP).

V některých případech však lze použít PIM DM. Například ve velmi malých sítích, kde je tok vícesměrového vysílání malý.

Řídký režim PIM

Je zvolen úplně jiný přístup PIM SM. Navzdory svému názvu (sparse mode) jej lze úspěšně použít v jakékoli síti s účinností minimálně tak dobrou jako u PIM DM.
Zde opustili myšlenku bezpodmínečného zahlcení sítě multicastem. Zainteresované uzly nezávisle požadují připojení ke stromu pomocí zpráv Připojte se k PIM.
Pokud router neposlal Join, nebude na něj odeslán žádný provoz.

Abychom pochopili, jak PIM funguje, začněme jednoduchou sítí s jedním PIM routerem, který už známe:


Z nastavení na R1 je potřeba povolit možnost multicast routingu, PIM SM na dvou rozhraních (na stranu zdroje a na stranu klienta) a IGMP na stranu klienta. Kromě dalšího základního nastavení samozřejmě (IP, IGP).

Od této chvíle můžete odhalit GNS a shromáždit laboratoř. O tom, jak sestavit stojan pro multicast, jsem mluvil dostatečně podrobně v tomto článku.

R1(config)#ip multicast-routing R1(config)#int fa0/0 R1(config-if)#ip pim sparse-mode R1(config-if)#int fa1/0 R1(config-if)#ip pim řídký režim

Cisco se zde jako obvykle vyznačuje speciálním přístupem: když je na rozhraní aktivován PIM, automaticky se aktivuje i IGMP. Na všech rozhraních, kde je povolen PIM, funguje také IGMP.
Jiní výrobci přitom mají dva různé protokoly povolené dvěma různými příkazy: zvlášť IGMP, zvlášť PIM.
Odpustit Cisco tuto zvláštnost? Spolu se všemi ostatními?

Navíc možná budete muset nakonfigurovat adresu RP ( ip pim rp-adresa 172.16.0.1, například). O tom později, zatímco to budete brát jako samozřejmost a smířit se s tím.

Pojďme zkontrolovat aktuální stav multicastové směrovací tabulky pro skupinu 224.2.2.4:

Po zahájení vysílání na zdroji je třeba znovu zkontrolovat tabulku.

Pojďme analyzovat tento lakonický závěr.

Zobrazit záznam (*, 225.0.1.1) volal / četl starkomadzhi/ a řekne nám o příjemcích. Navíc nemusí jít nutně o jeden klient-počítač, obecně to může být například další PIM router. Důležité je, na která rozhraní potřebujete provoz převést.
Pokud je seznam výstupních rozhraní (OIL) prázdný - Nula, takže nejsou žádní příjemci – a ještě jsme je nespustili.

Záznam (172.16.0.5, 225.0.1.1) volal / četl escomadge/ a říká, že zdroj je znám. V našem případě zdroj s adresou 172.16.0.5 vysílá provoz pro skupinu 224.2.2.4. Multicastový provoz přichází na rozhraní FE0/1 - to je vzestupně (Proti proudu) rozhraní.

Takže žádní klienti. Provoz ze zdroje se dostane do routeru a zde jeho životnost končí. Nyní přidáme příjemce – nastavte příjem multicastu na PC.
PC odešle IGMP Report, router pochopí, že existují klienti a aktualizuje multicastovou směrovací tabulku.
Nyní to vypadá takto:

Objevilo se také downstream rozhraní: FE0/0, což je celkem očekávané. Navíc se objevil jak v (*, G), tak v (S, G). Seznam navazujících rozhraní je volán OIL - Seznam odchozích rozhraní.

Přidejme do rozhraní FE1/0 ještě jednoho klienta:

(S, G): Když multicastový provoz s cílovou adresou 224.2.2.4 ze zdroje 172.16.0.5 dorazí na rozhraní FE0/1, jeho kopie by měly být odeslány do FE0/0 a FE1/0.

Tohle byl ale velmi jednoduchý příklad – jeden router okamžitě zná jak zdrojovou adresu, tak i to, kde se příjemci nacházejí. Vlastně tu ani nejsou žádné stromy - snad zdegenerované. Ale pomohlo nám to pochopit, jak PIM a IGMP interagují.

Abychom pochopili, co je PIM, zaměřme se na mnohem složitější síť.

Předpokládejme, že všechny IP adresy jsou již nakonfigurovány podle schématu. IGP běží v síti pro normální směrování unicast.
Klient1, například může pingnout na Origin Server.

Ale dokud se nespustí PIM, IGMP, klienti kanály nevyžadují.

Takže časový bod 0.

Povolit vícesměrové směrování na všech pěti směrovačích:

RX(config)#ip multicast-routing
PIM je povoleno přímo na všech rozhraních všech směrovačů (včetně rozhraní směrem ke zdrojovému serveru a klientům):

RX(config)#int FEX/X RX(config-if)#ip pim sparse-mode

IGMP by teoreticky měl být povolen na rozhraních směrem ke klientům, ale jak jsme uvedli výše, na zařízeních Cisco je automaticky povolen spolu s PIM.

První věc, kterou PIM udělá, je vytvoření sousedství. K tomu slouží zprávy. Když je PIM aktivován na rozhraní, odešle se z něj na adresu PIM Hello 224.0.0.13 s TTL 1. To znamená, že sousedy mohou být pouze směrovače ve stejné doméně vysílání.

Jakmile sousedé od sebe přijmou pozdravy:

Nyní jsou připraveni přijímat žádosti pro skupiny multicast.

Pokud nyní spustíme klienty do voliéry na jedné straně a povolíme multicast stream ze serveru na druhé, pak R1 bude přijímat tok provozu a R4 obdrží IGMP Report, když se klient pokusí připojit. V důsledku toho se R1 nedozví nic o příjemcích a R4 o zdroji.

Bylo by fajn, kdyby se informace o zdroji a o klientech skupiny shromáždily někde na jednom místě. Ale v čem?

Toto místo setkání se nazývá Rendezvous Point-RP. Toto je ústřední koncept PIM SM. Bez ní by nic nefungovalo. Zde se setkává zdroj a příjemci.
Všechny PIM routery potřebují vědět, kdo je RP v doméně, tedy znát jeho IP adresu.

Pro sestavení MDT stromu je jako RP v síti vybrán určitý centrální bod, který:

1. zodpovědný za studium zdroje,
2. je lákadlem pro zprávy Join od všech zainteresovaných stran.

Existují dva způsoby, jak nastavit RP: statické a dynamické. Na oba se podíváme v tomto článku, ale začneme statickým, protože co je jednodušší než statické?

Nechme R2 zatím hrát roli RP.
Pro zvýšení spolehlivosti se obvykle volí adresa rozhraní Loopback. Proto pro každého routery spustí příkaz:
RX(config)#ip pim rp-adresa 2.2.2.2
Tato adresa musí být přirozeně dostupná ve směrovací tabulce ze všech bodů.
No, protože adresa 2.2.2.2 je RP, na rozhraní Loopback 0 na R2 je také žádoucí aktivovat PIM.

R2(config)#rozhraní Loopback 0 RX(config-if)#ip pim sparse-mode

Ihned poté se R4 dozví o zdroji provozu pro skupinu 224.2.2.4:

A dokonce přenáší provoz:

362 000 bps přichází do rozhraní FE0/1 a jsou přenášeny přes rozhraní FE0/0.

Vše, co jsme udělali:
Povolena možnost směrovat vícesměrový provoz ( ip multicast směrování)
Aktivovaný PIM na rozhraních ( ip pim řídký režim)
Zadaná adresa RP ( ip pim rp adresa X.X.X.X )

To je vše, toto je již funkční konfigurace a můžete začít analyzovat, protože v zákulisí se skrývá mnohem více, než můžete vidět na pódiu.
Kompletní konfigurace pomocí PIM.

Debriefing

Jak to tedy nakonec všechno funguje? Jak RP ví, kde je zdroj, kde jsou klienti a zajišťuje komunikaci mezi nimi?

Vzhledem k tomu, že vše začíná kvůli našim milovaným zákazníkům, pak, počínaje nimi, celý proces podrobně zvážíme.

1) Klient 1 odešle zprávu IGMP pro skupinu 224.2.2.4

2) R4 obdrží tento požadavek, pochopí, že za rozhraním FE0/0 je klient, přidá toto rozhraní do OIL a vygeneruje záznam (*, G).

Zde můžete vidět uplink FE0/1, ale to neznamená, že R4 přijímá provoz pro skupinu 224.2.2.4. Říká pouze, že jediné místo, které může od této chvíle přijímat, je FE0/1, protože tam se nachází RP. Mimochodem soused, který prošel Kontrola RPF- R2: 10.0.2.24. očekávaný.

R4 se nazývá - LHR (Last Hop Router) - poslední směrovač na cestě multicastového provozu, pokud počítáte od zdroje. Jinými slovy, jedná se o router nejblíže příjemci. Pro Klient1 je R4, pro Klient2 je R5.

3) Vzhledem k tomu, že R4 ještě nemá multicastový stream (předtím o něj nepožádal), vytvoří zprávu PIM Join a odešle ji na stranu RP (2.2.2.2).

PIM Join se odesílá multicastem na adresu 224.0.0.13. "Směrem k RP" znamená přes rozhraní, které je uvedeno ve směrovací tabulce jako odchozí pro adresu, která je uvedena uvnitř paketu. V našem případě je to 2.2.2.2 - adresa ŘP. Takové spojení je také označováno jako Připojit (*,G) a říká: "Nezáleží na tom, kdo je zdrojem, potřebuji provoz ze skupiny 224.2.2.4."
To znamená, že každý router na cestě musí takový Join zpracovat a případně poslat nový Join směrem k RP. (Je důležité pochopit, že pokud router již tuto skupinu má, nebude posílat nad Join - jednoduše přidá rozhraní, ze kterého Join přišel, do OIL a začne přenášet provoz).
V našem případě Join přešel na FE0/1:

4) R2 po přijetí Join vytvoří záznam (*, G) a přidá rozhraní FE0 / 0 do OIL. Join ale není kam poslat - on sám už je RP, ale o zdroji se zatím nic neví.

Tímto způsobem se RP dozví o tom, kde se klienti nacházejí.

Li Klient 2 chce také přijímat multicastový provoz pro stejnou skupinu, R5 odešle PIM Join na FE0 / 1, protože za ním stojí RP, R3 poté, co jej přijal, vytvoří nový PIM Join a odešle ho do FE1 / 1 - kde se RP nachází .
To znamená, že Join cestuje uzel po uzlu, dokud nedosáhne RP nebo jiného routeru, kde již jsou klienti této skupiny.

Takže R2 - náš RP - nyní ví, že pro FE0/0 a FE1/0 má příjemce pro skupinu 224.2.2.4.
A nezáleží na tom, kolik jich je – jeden za každým rozhraním nebo sto – tok provozu bude stále jeden na každé rozhraní.

Pokud graficky znázorníme, co jsme dostali, bude to vypadat takto:

Vypadá to jako strom, že? Proto se tomu říká - RPT - strom bodů setkání. Je to strom zakořeněný v RP a rozvětvený k zákazníkům.
Obecnější pojem, jak jsme uvedli výše, je MDT - Multicast Distribution Tree- strom, podél kterého se šíří tok multicast. Později uvidíte rozdíl mezi MDT a RPT.

5) Nyní odřízneme server. Jak jsme probrali výše, nezajímá se o PIM, RP, IGMP – pouze vysílá. A R1 přijímá tento proud. Jeho úkolem je doručovat multicast do RP.
V PIM existuje speciální typ zprávy - Registrovat. Je potřeba pro registraci zdroje multicast na RP.
Takže R1 přijímá multicastový tok skupiny 224.2.2.4:

R1 je FHR (First Hop Router)- první router na trase multicastového provozu nebo nejblíže ke zdroji.

Věnujte pozornost zásobníku protokolů. Nad hlavičkou unicast IP a PIM přichází původní multicast IP, UDP a data.
Nyní, na rozdíl od všech ostatních PIM zpráv, které dosud známe, je adresa příjemce 2.2.2.2, nikoli multicastová adresa.

Takový paket je doručen do RP podle standardních pravidel unicastového směrování a nese původní multicastový paket, to znamená, že toto je ... toto je tunelování!

Na serveru 172.16.0.5 je spuštěna aplikace, která může odesílat pakety pouze na adresu vysílání 255.255.255.255 s cílovým portem UDP 10999.

Tento provoz je třeba doručit klientům 1 a 2:
Klient 1 ve formě multicastového provozu se skupinovou adresou 239.9.9.9.
A do klientského segmentu 2 formou broadcast paketů na adresu 255.255.255.255.

Poznámka k topologii: V této úloze spravují naši správci sítě pouze routery R1, R2, R3. To znamená, že konfiguraci lze změnit pouze na nich.

Server 172.16.0.5 odesílá multicastový provoz do skupin 239.1.1.1 a 239.2.2.2.

Nakonfigurujte síť tak, aby provoz skupiny 239.1.1.1 nebyl přenášen do segmentu mezi R3 a R5 a do všech segmentů pod R5.
Ale zároveň by měl být provoz skupiny 239.2.2.2 přenášen bez problémů.

Stejné jako Source DR, ale pro příjemce vícesměrového vysílání - LHR (směrovač posledního skoku) .
Příklad topologie:

Přijímač DR je zodpovědný za odeslání do RP PIM Join. Ve výše uvedené topologii, pokud oba směrovače posílají spojení, pak oba budou přijímat multicastový provoz, ale není to nutné. Pouze DR posílá Join. Druhý jednoduše sleduje dostupnost DR.
Protože DR posílá spojení, bude také vysílat provoz do LAN. Zde však vyvstává logická otázka – co kdyby se PIM DR stal jedním a IGMP Querier jiným? A situace je docela možná, protože pro Querier platí, že čím menší IP, tím lépe, ale pro DR naopak.
V tomto případě je router, který je již Querier, vybrán DR a tento problém nenastává.

Pravidla pro výběr DR přijímače jsou úplně stejná jako u DR zdroje.

Problém dvou současně vysílajících routerů může nastat i uprostřed sítě, kde nejsou koncoví klienti, žádné zdroje – pouze routery.
Tento problém byl velmi akutní u PIM DM, kde se jednalo o zcela běžnou situaci díky mechanismu Flood and Prune.
Ale v PIM SM to není vyloučeno.
Zvažte tuto síť:

Zde jsou tři směrovače ve stejném segmentu sítě, a proto jsou sousedy PIM. R1 funguje jako RP.
R4 pošle PIM Join směrem k RP. Vzhledem k tomu, že tento paket je vícesměrový, narazí na R2 i R3 a oba po jeho zpracování přidají do OIL downstreamové rozhraní.
Mechanismus výběru DR by zde měl fungovat, ale na R2 a R3 jsou další klienti této skupiny a oba routery stejně budou muset poslat PIM Join.
Když multicastový provoz přichází ze zdroje na R2 a R3, je přenášen do segmentu oběma směrovači a tam je zdvojnásoben. PIM se takové situaci nesnaží zabránit - zde jedná na základě skutkové podstaty trestného činu - jakmile router přijme multicastový provoz z této skupiny na svém downstream rozhraní pro určitou skupinu (ze seznamu OIL), pochopí: něco je špatně – v tomto segmentu je již jiný odesílatel.

Poté router odešle speciální zprávu.
Tato zpráva vám pomůže vybrat PIM Forwarder- router, který má právo vysílat v tomto segmentu.

Nepleťte si to s PIM DR. Za prvé, PIM DR je zodpovědný za odeslání PIM Join a Prune zprávy, a PIM Forwarder - pro odesílání provoz. Druhým rozdílem je, že PIM DR je vždy vybrán v jakékoli síti při vytváření sousedství, zatímco PIM Forwrder je vybrán pouze v případě potřeby - když je multicastový provoz přijímán z rozhraní ze seznamu OIL.

Výběr RP

Výše jsme pro jednoduchost nastavili RP ručně příkazem ip pim rp-adresa X.X.X.X .
A takto vypadal příkaz:

Představme si ale situaci, která je v moderních sítích zcela nemožná – R2 je mimo provoz. Všechno je hotovo. Klient 2 bude to stále fungovat, protože došlo k Přepnutí SPT, ale všechno nové a vše, co prošlo RP, se pokazí, i když existuje alternativní cesta.
No, zátěž na správce domény. Představte si: na 50 routerech ručně zabijte alespoň jeden příkaz (a pro různé skupiny mohou být různé RP).

Dynamický výběr RP umožňuje vyhnout se manuální práci a zajistit spolehlivost – pokud se jeden RP stane nedostupným, do bitvy okamžitě vstoupí další.

V současné době existuje jeden obecně uznávaný protokol, který vám to umožňuje -. Cisca v minulosti propagovala poněkud neohrabaný Auto-RP, ale nyní se téměř nepoužívá, i když to cisca nepřizná a máme tu nepříjemný rudiment v podobě skupiny 224.0.1.40.

Protokolu Auto-RP opravdu musíte připsat uznání. Byl spásou za starých časů. S příchodem otevřeného a flexibilního Bootstrapu ale svou pozici přirozeně ztratil.

Řekněme tedy, že v naší síti chceme, aby R3 převzal funkce RP v případě, že R2 vypadne.
R2 a R3 jsou identifikováni jako kandidáti na RP – tak se jim říká C-RP. Na těchto routerech konfigurujeme:
RX(config)interface Loopback 0 RX(config-if)ip pim sparse-mode RX(config-if)exit RX(config)#ip pim rp-candidate loopback 0

Zatím se ale nic neděje – kandidáti ještě nevědí, jak na sebe všechny upozornit.

Pro informování všech multicastových směrovačů domény o existujících RP je zaveden mechanismus BSR - BootStrap Router. Může být několik žadatelů, stejně jako C-RP. Podle toho se jmenují C-BSR. Jsou konfigurovány podobným způsobem.

Mějme jeden BSR a pro test (výhradně) to bude R1.
R1(config)interface Loopback 0 R1(config-if)ip pim sparse-mode R1(config-if)exit R1(config)#ip pim bsr-candidate loopback 0
Nejprve se ze všech C-BSR vybere jeden hlavní BSR, na kterém bude vše spuštěno. Za tímto účelem každý C-BSR odešle multicast Bootstrap Message (BSM) na adresu 224.0.0.13 - jedná se také o paket protokolu PIM. Musí být přijat a zpracován všemi směrovači multicast a poté odeslán na všechny porty, kde je aktivován PIM. BSM se na rozdíl od PIM Join nepřenáší ve směru něčeho (RP nebo zdroje), ale všemi směry. Toto rozvětvení pomáhá BSM dosáhnout všech koutů sítě, včetně všech C-BSR a všech C-RP. Aby BSM nebloudilo donekonečna po síti, používá se stejný mechanismus RPF – pokud BSM přišlo ze špatného rozhraní, za kterým se nachází síť odesílatele této zprávy, je taková zpráva zahozena.

S těmito BSM určují všechny multicastové směrovače toho nejvhodnějšího kandidáta na základě priorit. Jakmile C-BSR přijme BSM od jiného směrovače s vyšší prioritou, přestane vysílat své zprávy. Výsledkem je, že všichni mají stejné informace.

V této fázi, když je vybrán BSR, z důvodu skutečnosti, že jeho BSM jsou již rozptýleny po síti, C-RP znají jeho adresu a posílají na něj zprávy s unicastem. Candidte-RP-Reklama, ve kterém nosí seznam skupin, kterým obsluhují – tomu se říká mapování skupiny na RP. BSR všechny tyto zprávy agreguje a vytváří Sada RP- informační tabulka: které RP slouží každé skupině.

Dále BSR rozešle stejné zprávy BootStrap stejným způsobem, které tentokrát obsahují sadu RP. Tyto zprávy úspěšně dosáhnou všech směrovačů vícesměrového vysílání, z nichž každý na vlastní pěst provádí volbu, který RP použít pro každou konkrétní skupinu.

BSR pravidelně zasílá takové mailingy, aby na jedné straně každý věděl, že informace na RP jsou stále relevantní, a na druhé straně si C-BSR uvědomovali, že hlavní BSR sám o sobě stále žije.
RP, mimochodem, také pravidelně zasílá svá oznámení kandidátů-RP-inzerce BSR.

Ve skutečnosti vše, co musíte udělat pro nastavení automatického výběru RP, je zadat C-RP a zadat C-BSR - není to moc práce, PIM udělá zbytek za vás.
Jako vždy se pro zvýšení spolehlivosti doporučuje specifikovat rozhraní Loopback jako kandidáty.

Na závěr kapitoly PIM SM zopakujme nejdůležitější body

1. Běžné unicastové připojení by mělo být zajištěno pomocí IGP nebo statických tras. To je srdcem algoritmu RPF.
2. Strom je postaven až po vzhledu klienta. Stavbu stromu iniciuje klient. Žádný klient – ​​žádný strom.
3. RPF pomáhá vyhnout se smyčkám.
4. Všechny routery musí vědět, kdo je RP - pouze s jeho pomocí lze postavit strom.
5. RP lze zadat staticky nebo jej lze vybrat automaticky pomocí protokolu BootStrap.
6. V první fázi je postaven RPT - strom od klientů k RP - a Source Tree - strom od zdroje k RP. Ve druhé fázi dochází k přechodu z konstruovaného RPT na SPT - nejkratší cesta od příjemce ke zdroji.

Uvedeme také všechny typy stromů a zpráv, které nyní známe.

MDT - Multicast Distribution Tree. Obecný termín popisující jakýkoli strom multicastového přenosu.
SPT - Strom nejkratší cesty. Strom s nejkratší cestou od klienta nebo RP ke zdroji. PIM DM má pouze SPT. V PIM SM může být SPT od zdroje k RP nebo od zdroje k cíli poté, co došlo k přepnutí SPT. Označeno záznamem – zdroj pro skupinu je znám.
zdrojový strom- stejné jako SPT.
RPT - strom bodů setkání. Strom od RP k příjemcům. Používá se pouze v PIM SM. Označeno záznamem.
sdílený strom- stejné jako RPT. Říká se tomu tak, protože všichni klienti jsou připojeni k jednomu společnému stromu s kořeny v RP.

Typy zpráv PIM Sparse Mode:
Ahoj- vytvořit sousedství a udržovat tyto vztahy. Také je potřeba vybrat DR.
- požadavek na připojení ke stromu skupiny G. Nezáleží na tom, kdo je zdrojem. Odjíždí směrem k RP. S jejich pomocí je strom RPT postaven.
- Specifické připojení ke zdroji. Toto je požadavek na připojení ke stromu skupiny G s konkrétním zdrojem - S. Odesílá se směrem ke zdroji - S. S jejich pomocí je sestaven strom SPT.
Prune(*, G)- požadavek na odpojení od stromu skupiny G, bez ohledu na to, z jakých zdrojů. Odjíždí směrem k RP. Tím se odřízne větev RPT.
Sušené švestky (S, G)- požadavek na odpojení od stromu skupiny G, jehož kořenem je zdroj S. Odesláno směrem ke zdroji. Tím se přeruší větev SPT.
Registrovat- speciální zpráva, v rámci které je do RP přenášeno vícesměrové vysílání, dokud není sestaven SPT ze zdroje do RP. Přenášeno unicastem z FHR do RP.
registr-stop- zasílané unicastem z RP do FHR s příkazem k zastavení odesílání multicastového provozu zapouzdřeného v Registru.
- Pakety mechanismu BSR, které vám umožňují vybrat router pro roli BSR a také přenášet informace o existujících RP a skupinách.
tvrdit- zpráva pro výběr PIM Forwarder, aby dva směrovače nepřenášely provoz do jednoho segmentu.
Kandidát-RP-Inzerce- zpráva, ve které RP zasílá informaci do BSR o tom, které skupiny obsluhuje.
RP-dosažitelné- zpráva od RP, kterou všechny upozorní na svou dostupnost.
*V PIM jsou i jiné typy zpráv, ale toto jsou podrobnosti*

A zkusme nyní abstrahovat od detailů protokolu? A pak se ukáže jeho složitost.

1) Definice RP,
2) Registrace zdroje na RP,
3) Přepnutí do stromu SPT.

Mnoho stavů protokolu, mnoho položek ve směrovací tabulce vícesměrového vysílání. Dá se s tím něco dělat?

K dnešnímu dni existují dva diametrálně odlišné přístupy ke zjednodušení PIM: SSM a BIDIR PIM.

SSM

Vše, co jsme dosud popsali, je ASM - Any Source Multicast. Klientům je jedno, kdo je pro skupinu zdrojem návštěvnosti – hlavní je, že ji dostávají. Jak si pamatujete, zpráva IGMPv2 Report jednoduše žádá o připojení ke skupině.
SSM - Source Specific Multicast- alternativní přístup. V tomto případě klienti při připojení určují skupinu a zdroj.
co to dává? Ani více, ani méně: schopnost úplně se zbavit RP. LHR okamžitě zná zdrojovou adresu - není potřeba posílat Join do RP, router může okamžitě poslat Join (S, G) směrem ke zdroji a postavit SPT.
Tím se zbavujeme

• Hledat RP (protokoly Bootstrap a Auto-RP),
• Registrace zdroje vícesměrového vysílání (a to je čas navíc, využití dvojnásobné šířky pásma a tunelování)
• Přechod na SPT.

Protože neexistuje RP, neexistuje ani RPT, takže na žádném routeru nebudou žádné položky (*, G) - pouze (S, G).
Dalším problémem, který SSM řeší, je přítomnost více zdrojů. ASM doporučuje, aby adresa skupiny vícesměrového vysílání byla jedinečná a aby k ní byl vysílán pouze jeden zdroj, protože ve stromu RPT se sloučí více proudů a klient přijímající dva proudy z různých zdrojů je pravděpodobně nebude schopen analyzovat.
V SSM je provoz z různých zdrojů distribuován nezávisle, každý ve svém vlastním stromu SPT, a to již není problém, ale výhoda – více serverů může vysílat současně. Pokud najednou klient začne opravovat ztráty z hlavního zdroje, může přejít na záložní, aniž by o to znovu žádal – již obdržel dva streamy.

Navíc možným vektorem útoku v síti s aktivovaným multicastovým směrováním je to, že útočník připojí svůj zdroj a generuje velké množství multicastového provozu, který přetíží síť. V SSM je to prakticky nemožné.

Pro SSM byl přidělen speciální rozsah IP adres: 232.0.0.0/8.
Na směrovačích podporujících SSM je povolen režim PIM SSM.

Router(config)# ip pim ssm

IGMPv3 a MLDv2 podporují čisté SSM.
Při jejich použití může klient

• Požádejte o připojení k jednoduché skupině, aniž byste uváděli zdroje. To znamená, že funguje jako typický ASM.
• Požádejte o připojení ke skupině s konkrétním zdrojem. Můžete zadat několik zdrojů - ke každému z nich bude vytvořen strom.
• Požádejte o připojení ke skupině a zadejte seznam zdrojů, ze kterých klient nechtěl získat provoz

IGMPv1/v2, MLDv1 nepodporují SSM, ale existuje něco jako Mapování SSM. Na routeru nejblíže klientovi (LHR) je každé skupině přiřazena zdrojová adresa (nebo několik). Pokud jsou tedy v síti klienti, kteří nepodporují IGMPv3 / MLDv2, bude pro ně sestaven SPT a ne RPT, protože je stejně známá zdrojová adresa.
Mapování SSM lze implementovat jako statické nastavení na LHR nebo přístupem k serveru DNS.

Problém SSM je v tom, že klienti musí znát zdrojové adresy předem - nejsou informováni žádnou signalizací.
Proto je SSM dobré v situacích, kdy v síti existuje určitá množina zdrojů, jejich adresy jsou známé a nebudou se měnit. A klientské terminály nebo aplikace jsou s nimi pevně svázány.
Jinými slovy, IPTV je velmi vhodné prostředí pro implementaci SSM. To dobře vystihuje koncept jeden k mnoha- jeden zdroj, mnoho příjemců.

Co když se ale zdroje v síti mohou tu a tam spontánně objevit, vysílat do stejných skupin, rychle přestat vysílat a zmizet?
Taková situace je například možná v online hrách nebo v datovém centru, kde jsou data replikována mezi různými servery. Je to koncept mnoho-k-mnoho- mnoho zdrojů, mnoho klientů.
Jak se na to dívá běžný PIM SM? Je jasné, že inertní PIM SSM se sem vůbec nehodí?
Jen si pomyslete, jaký chaos začne: nekonečné registrace zdrojů, přestavba stromů, obrovské množství záznamů (S, G) žijících několik minut díky protokolovým časovačům.
Obousměrný PIM přichází na záchranu ( Obousměrný PIM, BIDIR PIM). Na rozdíl od SSM naopak zcela odmítá SPT a zaznamenává (S, G) - zůstává pouze Shared Tree s rootem v RP.
A pokud je v běžném PIM strom jednosměrný - provoz se vždy přenáší ze zdroje dolů po SPT a z RP dolů po RPT - je jasné rozdělení, kde je zdroj, kde jsou klienti, tak v obousměrný provoz ze zdroje do RP je také přenášen po sdíleném stromu – stejnou cestou, jakou provoz proudí dolů k zákazníkům.

To umožňuje odmítnout registraci zdroje na RP - provoz je přenášen bezpodmínečně, bez jakékoli signalizace a změn stavu. Protože zde nejsou vůbec žádné stromy SPT, nedochází ani k přechodu na SPT.

Například:

Zdroj1 začal odesílat provoz skupiny 224.2.2.4 do sítě ve stejnou dobu jako Zdroj2. Potoky z nich se jen lily směrem k RP. Někteří z klientů, kteří jsou poblíž, začali okamžitě přijímat provoz, protože na směrovačích je záznam (*, G) (existují klienti). Druhá část přijímá provoz prostřednictvím sdíleného stromu z RP. A přijímají provoz z obou zdrojů současně.
To znamená, že pokud vezmeme například spekulativní síťovou hru, Zdroj1 je prvním hráčem ve střílečce, který vystřelil, a Zdroj2 je dalším hráčem, který udělal krok vedle. Informace o těchto dvou událostech se šířily po síti. A každý jiný hráč ( Příjemce) by se měli dozvědět o obou těchto událostech.

Pokud si pamatujete, vysvětlili jsme, proč je potřeba proces registrace zdroje na RP - aby provoz nezabíral kanál, když nejsou žádní klienti, to znamená, že jej RP jednoduše odmítne. Proč o tomto problému nepřemýšlíme nyní? Důvod je jednoduchý: BIDIR PIM je pro situace, kdy existuje mnoho zdrojů, ale nevysílají neustále, ale periodicky, v relativně malých úsecích dat. To znamená, že kanál od zdroje k RP nebude promarněn.

Všimněte si, že na obrázku výše je přímka mezi R5 a R7, mnohem kratší než cesta přes RP, ale nebyla použita, protože Join jde směrem k RP podle směrovací tabulky, ve které tato cesta není optimální.

Vypadá to docela jednoduše - je potřeba posílat multicastové pakety ve směru RP a je to, ale je tu jedna nuance, která vše kazí - RPF. Ve stromu RPT vyžaduje, aby provoz pocházel z RP a nic jiného. A tady to může přijít odkudkoliv. Samozřejmě nemůžeme vzít a odmítnout RPF - to je jediný mechanismus, který nám umožňuje vyhnout se tvorbě smyček.

Proto je tento koncept zaveden do BIDIR PIM. V každém segmentu sítě na každé lince je pro tuto roli vybrán router s nejlepší cestou k RP.
Včetně toho se děje na těch linkách, kde jsou zákazníci přímo připojeni. V BIDIR PIM je DF automaticky DR.

Seznam OIL je tvořen pouze z těch rozhraní, na kterých byl router vybrán pro roli DF.

Pravidla jsou celkem jasná:

• Pokud na rozhraní, které je DF v tomto segmentu, dorazí požadavek PIM Join/Leave, je odeslán do RP podle standardních pravidel.
  Zde například R3. Pokud přijdou požadavky na rozhraní DF, která jsou označena červeným kroužkem, přenese je do RP (přes R1 nebo R2, podle směrovací tabulky).
• Pokud požadavek na připojení/opuštění PIM přišel na rozhraní bez DF, bude ignorován.
  Řekněme, že se klient mezi R1 a R3 rozhodne připojit a odešle zprávu IGMP. R1 jej přijme přes rozhraní, kde jej vybere DF (označený červeným kroužkem) a vrátíme se k předchozímu scénáři. A R3 obdrží požadavek na rozhraní, které není DF. R3 vidí, že tady není nejlepší, a ignoruje žádost.
• Pokud multicastový provoz přišel na rozhraní DF, bude odeslán na rozhraní ze seznamu OIL a směrem k RP.
  Například, Zdroj1 začal posílat provoz. R4 jej přijme na svém DF rozhraní a odešle do jiného DF rozhraní - na stranu klienta a na stranu RP - to je důležité, protože provoz se musí dostat do RP a šířit se ke všem příjemcům. Stejně tak R3 - jedna kopie do rozhraní ze seznamu OIL - tedy do R5, kde bude vypuštěna kvůli kontrole RPF a druhá - směrem k RP.
• Pokud multicastový provoz dorazil na jiné než DF rozhraní, měl by být odeslán na rozhraní ze seznamu OIL, ale nebude odesláno do RP.
  Například, Zdroj2 začal vysílat, provoz dosáhl RP a začal se šířit po RPT. R3 přijímá provoz z R1 a nepřesměruje ho na R2 - pouze dolů na R4 a R5.

DF tedy zaručuje, že pouze jedna kopie multicastového paketu bude nakonec odeslána do RP a smyčky jsou vyloučeny. Obecný strom, ve kterém se zdroj nachází, přitom tento provoz přirozeně přijme ještě dříve, než narazí na RP. RP bude podle běžných pravidel posílat provoz do všech portů OIL, kromě toho, odkud provoz přišel.

Mimochodem, zprávy Assert již nejsou potřeba, protože v každém segmentu je vybráno DF. Na rozdíl od DR zodpovídá nejen za odesílání Join do RP, ale také za přenos provozu do segmentu, tedy v BIDIR PIM je vyloučena situace, kdy dva routery přenášejí provoz do stejné podsítě.

Snad poslední věc, kterou je třeba říci o obousměrném PIM, je to, jak funguje RP. Jestliže v PIM SM RP plnilo velmi specifickou funkci - registraci zdroje, tak v BIDIR PIM RP jde o jakýsi velmi podmíněný bod, ke kterému směřuje provoz na jedné straně a Join od klientů na straně druhé. Nikdo by neměl dekapsulovat, požadovat stavbu stromu SPT. Prostě na nějakém routeru se najednou začne provoz ze zdrojů přenášet do Sdíleného stromu. Proč říkám "nějaké"? Faktem je, že v BIDIR PIM je RP abstraktní bod, nikoli konkrétní router, jako RP adresa může obecně fungovat neexistující IP adresa - hlavní je, aby byla směrovatelná (takový RP se nazývá Phantom RP).

Všechny termíny související s PIM lze nalézt ve glosáři.

Multicast na úrovni spojení

Takže za dlouhým pracovním týdnem s nedostatkem spánku, zpracování, testů - máte úspěšně implementovaný multicast a spokojené zákazníky, ředitele a obchodní oddělení.
Pátek není nejhorší den na průzkum stvoření a dopřát si příjemný odpočinek.
Ale váš odpolední spánek je náhle narušen telefonátem technické podpory, pak dalším a dalším - nic nefunguje, všechno je rozbité. Kontrolujete - jsou ztráty, mezery. Vše se sbíhá na jednom segmentu několika přepínačů.

Odkryli jsme SSH, zkontrolovali CPU, zkontrolovali vytížení rozhraní a vlasy na hlavě - zatížení je téměř 100% na všech rozhraních jedné VLAN "a. Smyčka! Ale kde se to bere, když nebyla provedena žádná práce? 10 minut kontroly a všimli jste si, že na upstreamovém rozhraní máte hodně příchozího provozu do jádra a odchozího provozu ke všemu sestupně ke klientům. To je také typické pro smyčku, ale nějak podezřelé: byl zaveden multicast, žádné přepínání nefunguje byl proveden a skok byl pouze jedním směrem.
Zkontrolovali jsme seznam skupin multicast na routeru - a tam je předplatné na všechny možné kanály a všechny na jeden port - samozřejmě ten, který vede do tohoto segmentu.
Pečlivé vyšetřování ukázalo, že klientský počítač je infikován a posílá IGMP Query na všechny multicastové adresy v řadě.

Ztráta paketů začala, protože přepínače musely přes sebe procházet obrovské množství provozu. To způsobilo přetečení vyrovnávací paměti rozhraní.

Hlavní otázkou je, proč se provoz jednoho klienta začal kopírovat na všechny porty?

Důvod spočívá v povaze vícesměrových MAC adres. Faktem je, že prostor multicastových IP adres je mapován speciálním způsobem na prostor multicastových MAC adres. A háček je v tom, že nikdy nebudou použity jako zdrojová MAC adresa, a tudíž je switch nenaučí a nezadá do tabulky MAC adres. Ale co přepínač s rámečky, jejichž cílová adresa se nenaučí? Posílá je do všech přístavů. Co se stalo.
Toto je výchozí akce.

Multicast MAC adresy

Jaké cílové MAC adresy jsou tedy nahrazeny do ethernetové hlavičky takových paketů? Přenos? Ne. Existuje speciální rozsah MAC adres, na které jsou mapovány multicastové IP adresy.
Tyto speciální adresy začínají takto: 0x01005e a další 25. bit musí být 0 (zkuste odpovědět proč). Zbývajících 23 bitů (nezapomeňte, že jich je v MAC adrese celkem 48) je přeneseno z IP adresy.

Zde leží některé nepříliš závažné, ale problém. Rozsah multicastových adres je definován maskou 224.0.0.0/4, což znamená, že první 4 bity jsou vyhrazeny: 1110 a zbývajících 28 bitů se může změnit. To znamená, že máme 2 ^ 28 multicastových IP adres a pouze 2 ^ 23 MAC adres – 5 bitů nestačí k mapování 1 ku 1. Proto se jednoduše vezme posledních 23 bitů IP adresy a přenese se jeden na jeden na MAC adresu, zbývajících 5 se zahodí.

Ve skutečnosti to znamená, že 2^5=32 IP adres bude mapováno na jednu multicast MAC adresu. Například skupiny 224.0.0.1, 224.128.0.1, 225.0.0.1 a tak dále až do 239.128.0.1 budou všechny mapovány na stejnou MAC adresu 0100:5e00:0001.

Vezmeme-li jako příklad výpis streamovaného videa, můžeme vidět:

IP adresa je 224.2.2.4, MAC adresa je 01:00:5E:02:02:04.

Existují i ​​další multicastové MAC adresy, které s IPv4 multicastem (kliknutím) nijak nesouvisí. Všechny se mimochodem vyznačují tím, že poslední bit prvního oktetu je 1.

Přirozeně taková MAC adresa nemůže být konfigurována na žádné síťové kartě, takže nikdy nebude v poli Source MAC ethernetového rámce a nikdy nevstoupí do tabulky MAC adres. To znamená, že takové rámce by měly být odeslány jako jakýkoli neznámý Unicast na všechny porty VLAN.

Vše, co jsme zvažovali dříve, je dostačující pro plný přenos jakéhokoli multicastového provozu od streamovaného videa až po ceny akcií. Sneseme ale v našem téměř dokonalém světě takovou ostudu, jako je vysílání toho, co by se dalo přenášet vyvoleným?
Vůbec ne. Zejména pro perfekcionisty vynalezl mechanismus IGMP slídění.

IGMP slídění

Myšlenka je velmi jednoduchá – přepínač „poslouchá“ IGMP pakety, které jím procházejí.
Pro každou skupinu zvlášť udržuje tabulku upstream a downstream portů.

Pokud zpráva IGMP pro skupinu přišla z portu, pak existuje klient, přepínač jej přidá do seznamu příjemců pro tuto skupinu.
Pokud z portu přišel dotaz IGMP pro skupinu, pak existuje router, přepínač jej přidá do upstream seznamu.

Tak je vytvořena tabulka pro přenos multicastového provozu na spojové vrstvě.
Výsledkem je, že když multicastový tok přichází shora, je zkopírován pouze do navazujících rozhraní. Pokud jsou na 16portovém přepínači pouze dva klienti, budou provoz doručovat pouze tito klienti.

Genialita této myšlenky končí, když se zamyslíme nad její povahou. Mechanismus předpokládá, že přepínač by měl naslouchat provozu na vrstvě 3.

IGMP-Snooping však nelze srovnávat s NAT z hlediska míry ignorování principů síťové interakce. Kromě toho, že šetří zdroje, přináší spoustu méně zjevných příležitostí. A obecně v moderním světě není přepínač, který dokáže nahlédnout do IP, výjimečným jevem.

Server 172.16.0.5 odesílá multicastový provoz do skupin 239.1.1.1, 239.2.2.2 a 239.0.0.x.
Nastavte síť tak, aby:
- klient 1 se nemohl připojit ke skupině 239.2.2.2. Zároveň se ale mohl připojit ke skupině 239.0.0.x.
- klient 2 se nemohl připojit ke skupině 239.1.1.1. Zároveň se ale mohl připojit ke skupině 239.0.0.x.

Na závěr netriviální multicastový problém (autoři nejsme my, v odpovědích bude odkaz na originál).

Nejjednodušší schéma:

Na jedné straně zdrojový server, na druhé straně - počítač, který je připraven přijímat provoz.

Adresu multicastového streamu si můžete nastavit sami.

A tak dvě otázky:
1. Co je třeba udělat, aby počítač mohl přijímat datový proud, aniž by se uchýlil k vícesměrovému směrování?
2. Řekněme, že vůbec nevíte, co je multicast a neumíte to nastavit, jak přenést stream ze serveru do počítače?

Úkol se snadno hledá ve vyhledávači, ale zkuste si ho vyřešit sami.

Děkuji za pomoc při přípravě tohoto článku...
Děkujeme Natashe Samoylenko za technickou podporu.
KDPV nakreslila Nina Dolgopolova - skvělá umělkyně a přítelkyně projektu.

V poolu článků SDSM je před koncem ještě spousta zajímavého, takže není potřeba cyklus pohřbívat kvůli dlouhé absenci vydání – s každým novým článkem se složitost výrazně zvyšuje. Téměř všechny MPLS, IPv6, QoS a síťový design jsou napřed.

Jak jste si již pravděpodobně všimli, linkmeup má nový projekt - Lookmeup Glossary (ano, naše fantazie není daleko). Doufáme, že se tento glosář stane nejobsáhlejší referencí pojmů v oblasti komunikace, proto uvítáme jakoukoli pomoc při jeho vyplnění. Napište nám na [e-mail chráněný]

Štítky:

• sítě pro nejmenší
• multicast
• pim
• igmp
• ssm

Přidat štítky

V současné době existuje poměrně zajímavá služba poskytovatele internetu, jedná se o IPTV, jednu z možností digitální televize. Poskytovatelé obvykle nabízejí několik možností pro použití takové služby, jako je IPTV, například pomocí speciálního televizního set-top boxu nebo pomocí speciálního programu v počítači.

Nastavení iptv přes router je celkem jednoduché, většinou to nezabere moc času. Poměrně často celé nastavení spočívá v aktivaci volby Povolit multicastové směrování. Po povolení tohoto nastavení nebude váš router filtrovat multicastový provoz a přesměruje tento provoz na síťová rozhraní LAN a do vnitřní podsítě pouze v případě potřeby.

Po tomto postupu si ve skutečnosti stačí stáhnout speciální přehrávač se seznamem kanálů v seznamu skladeb a povolit jeho použití, pokud je na vašem počítači nainstalována brána firewall. V případě úspěšného nastavení začne přehrávač přenášet obraz ve formátu digitální televize. Ale zároveň normální sledování, bez rušení a zamrzání, je obvykle možné pouze při použití kabelu.

Iptv přes wifi většinou funguje dost špatně, obraz často cuká a je plný různých druhů rušení. V případě, že se přesto rozhodnete sledovat digitální televizi prostřednictvím wifi systému, může vám pomoci taková možnost, jako je Multicast Rate. Toto nastavení vám umožňuje omezit množství multicastového provozu přenášeného do wi-fi rozhraní. Při konfiguraci iptv přes router musíte v tomto nastavení nastavit hodnotu na 36, ​​pomocí tohoto jednoduchého triku můžete vážně omezit počet odpojených připojení při prohlížení.

V případě, že jste si nemohli užít sledování IPTV pomocí těchto nastavení, následují technické tipy pro nastavení iptv prostřednictvím routeru.

Způsob změny firmwaru

Nejprve přejdeme k našemu routeru prostřednictvím prohlížeče. Zobrazí se informační okno vašeho routeru, ve kterém nahoře uprostřed (u některých routerů bude vedle něj panel pro výběr jazyka) je verze firmwaru vašeho routeru. Kliknutím na něj se zobrazí okno s názvem „Administrace-Aktualizace firmwaru“. Ve spodní části tohoto okna uvidíte tři nápisy odshora dolů – „identifikátor produktu“ (nedotýkejte se), dále bude „verze firmwaru“ (ve skutečnosti se jedná o verzi vašeho firmwaru) a „soubor nového firmwaru“ - tato linka je to, co potřebujeme.

Minimalizujte toto okno a přejděte do vyhledávače prohlížeče. Tam jezdíme ve frázi „stáhnout firmware pro router ...“ Po stažení firmwaru jej uložte na vhodné místo a rozbalte, pokud je ve formátu ZIP nebo RAR. Znovu otevřete okno „Administrace-Aktualizace firmwaru“. Vedle řádku, který potřebujeme ve spodní části okna, vidíme nápis „recenze“. Otevře se okno, ve kterém vybereme umístění nového firmwaru pro router a klikneme na „OK“. Důležité, před instalací nového firmwaru pro router si nezapomeňte vytvořit záložní kopii starého firmwaru, pokud nevíte, jak to udělat, podívejte se na verzi vašeho firmwaru a po zkopírování jeho čísla do vyhledávání motor, stáhněte si ho.

Dále v okně nastavení routeru (kam jsme šli od samého začátku) vlevo pod nápisem „pokročilá nastavení“ vidíme nápis „LAN“. Stlačíme, otevře se okno skládající se ze tří sekcí, potřebujeme tu s názvem „trasa“. Zobrazí se okno Nastavení směrování. V případě dotazů na povolení tras DHCP, statických tras a směrování vícesměrového vysílání nastavte „Ano“. V dolní části okna budete muset napsat „IP adresa sítě nebo hostitele“, „maska ​​sítě“ a „brána“.

Do pole ip address zadejte adresu vaší síťové karty, do pole maska ​​podsítě zadejte hodnotu 255.255.255.0, do pole brány zadejte adresu vašeho routeru. Nastavení je dokončeno, nyní si můžete stáhnout kterýkoli z přehrávačů nabízených na internetu.

Nastavení iptv přes router asus

Nejprve přejděte na stránku nastavení routeru. Dále vidíme kartu „pokročilá nastavení“, přejděte tam. Tam vidíme záložku s názvem „bezdrátová síť“, klikněte. Zde najdeme okno s nápisem „profesionální“, v této záložce jej potřebujeme, přičemž měníme pouze ta nastavení, která jsou napsána níže, nic jiného neměníme. Zde najdeme nápis „multicast data transfer rate“ a změníme jeho hodnotu na 24 (m/bps). Poté v okně nastavení routeru pod nápisem "pokročilá nastavení" najdeme kartu "LAN" a jdeme tam.

Do pole, kde je potřeba vložit čísla před nápis IPTV proxy port (nápis se bude u různých modelů lišit, ale myslím, že obecný význam je jasný) napíšeme čísla „2021“. Nezapomeňte odpovědět „ano“ na kartě, kde se ptá „povolit směrování vícesměrového vysílání“. Poté si stáhneme speciální přehrávač pro sledování digitální televize (pokud tam není). Jdeme do nastavení přehrávače, na kartu Obecné, pak do síťového rozhraní a tam vložíme adresu 192.168.1.1.2021.

Obecně platí, že nastavení iptv přes router je pro běžného uživatele poměrně obtížný úkol, ale pokud se nemůžete obrátit na profesionály, pak si myslím, že tyto typy nastavení vám pomohou v obtížné situaci.

IP hostitelé a směrovače používají protokol pro správu IGMP k seskupování síťových zařízení. Internet Group Management Protocol řídí vícesměrové (skupinové) sítě. Nachází se na síťové vrstvě a připojuje klientský počítač k místnímu routeru za účelem přenosu dat mezi nimi. Multicastový provoz je pak směrován ke zbytku klientů prostřednictvím protokolu PIM. Propojuje místní router se vzdáleným. Díky využití IGMP lze efektivněji využívat síťové zdroje řady aplikací (online hry, streamování videa).

Pomocí funkce IGMP snooping se můžete rozhodnout, zda chcete převést provoz na určitá rozhraní. proces sledování požadavků IGMP od spotřebitelů (hostitelů) k poskytovatelům (skupinovým směrovačům).

Koncept a účel IGMP snoopingu

V překladu z angličtiny znamená snooping „odposlouchávání“. Po zapnutí začne zprostředkující síťové zařízení (směrovač nebo komunikátor) analyzovat přenos všech datových paketů mezi klientskými počítači, které jsou k němu připojeny, a směrovači, které dodávají multicastový provoz. Když je detekován požadavek na připojení, zapne se port, ke kterému je spotřebitel (klient) připojen, v opačné situaci (požadavek na opuštění) je příslušný port ze seznamu skupin odstraněn.

Ve většině komunikátorů je IGMP snooping k dispozici, ale musí být předem povolen.

Proč sledovat síťový provoz?

Multicastový provoz lze přenášet i do počítačů, které o něj nemají zájem. Toto se nazývá přenos vysílání. Aby se tomu zabránilo, aby se snížilo zatížení sítě, používá se IGMP snooping. Tento druh filtrování zároveň vyžaduje dodatečné náklady na paměť a zvyšuje zátěž komunikátoru. Je však oprávněná.

Pokud komunikátor začne vysílat multicastový provoz na všech svých portech, pak:

• tento proces je zbytečný;
• problémy mohou nastat při provozu konečného příjemce (síťového zařízení), nuceného zpracovávat velký proud nepotřebných dat.

Pro eliminaci takových situací existuje funkce IGMP snooping, která výrazně zlepšuje výkon celé sítě. Zohledňuje potřeby na síťové (třetí) úrovni a optimalizuje tak kanálovou (druhou) úroveň přenosu dat.

Povolení funkce poslechu

Abyste mohli sledovat multicastový provoz, musíte nejprve povolit IGMP snooping a sami jej nakonfigurovat. Zvažme, jak to udělat na komunikátorech D-Link při implementaci schématu multicastového přenosu dat. Příkazy pro aktivaci síťového naslouchání:

Funkce IGMP Snooping Fast Leave se používá k vyloučení portu ze síťové skupiny, když komunikátor obdrží od klienta požadavek na opuštění. Umožňuje vám zastavit přenos nepotřebných po síti, aby fungoval efektivněji. Chcete-li tuto funkci povolit, použijte následující příkaz:

Používá se v případě, že je potřeba povolit multicastové filtrování switche s připojeným uzlem účastnícím se přenosu dat.

Typy naslouchání IGMP

IGMP snooping může být pasivní nebo aktivní. Jak se to zobrazuje?

1. Pasivní provoz nefiltruje, ale pouze monitoruje.
2. Aktivní – naslouchá a filtruje datové pakety, aby se snížilo zatížení skupinového routeru.

Druhý typ implementace této funkce je nejvýhodnější, protože umožňuje minimalizovat množství přenášených informací filtrováním požadavků na připojení a odpojení od routeru.

Funkčnost snoopingového komunikátoru IGMP pomáhá snižovat zatížení sítě monitorováním procesů výměny dat mezi poskytovateli (lokální routery) a spotřebiteli (klientské počítače) multicastového provozu.