Sítě pro nejmenší. Část devátého. Multicast / Habr.

Náš aspektický poskytovatel LinkMeup vyrůstá a obrací se tiše všemi službami běžných telekomunikačních operátorů. Nyní jsme vyrostli do IPTV.

To znamená, že je třeba konfigurovat směrování multicastu a především pochopení, že existuje takový multikon.

Jedná se o první odchylku od obvyklých principů IP sítí. Multicast paradigma se stále liší od lampy teplé lampy.

Můžete dokonce říci, že nějakým způsobem zpochybňuje flexibilitu vaší mysli v porozumění novým přístupům.

V tomto článku se zaměřuje na následující:

Tradiční video tutoriál:

Při úsvitu mé formace, jako inženýr, téma multicastu bylo neuvěřitelně vyděšené, a já s sebou spojil s psychotrahamem mé první zkušenosti s ním. " Takže, Marat, naléhavě, před polednem, musíte vyvolat video stream do naší nové budovy v centru města - Poskytovatel jej zde dá ve druhém patře "Slyšel jsem s jedním nádherným raním. Všechno, co jsem pak věděl o multicastu, takže to je to, co je odesílatel jedním, příjemci hodně, a zdá se, že protokol IGMP je nějakým způsobem zapojen.

Výsledkem je, že před polednem jsme se snažili začít celou věc - porazil jsem nejobvyklejší VLAN od vstupního bodu do výstupního bodu. Signál však byl nestabilní - obraz zmrazený, zhroutil, přerušen. Snažil jsem se v panice, abych zjistil, co lze provést s IGMP obecně, Tyrhogozy, zapnutý multicast směrování, IGMP-Snooping, zkontroloval tisíckrát zpoždění a ztráty - nic nepomohlo. A pak najednou všechno fungovalo. Samozřejmě stabilní, bezproblémové.

Sloužila mi očkováním multicast, a na dlouhou dobu jsem mu neukazoval zájem.

Už mnohem později jsem přišel k dalšímu pravidlu: A teď, z výšky nepochopitelných případů, chápu, že nemohlo být žádné problémy s nastavením síťové části - buggy konečných zařízení. Zachovejte mi klid a věřte mi. Po tomto článku vás takové věci nebudou vyděsit. Obecné porozumění víceslastu. Jak víte, existují následující typy provozu: Unicast. - Unicast - jeden odesílatel, jeden příjemce. ( Příklad: Dotaz HTTP-Stránka na webovém serveru Jak víte, existují následující typy provozu: ). Přenos. - vysílání - jeden odesílatel, příjemci - všechna zařízení v segmentu vysílání. ( Jak víte, existují následující typy provozu: Příklad: Žádost ARP Multicast. - Multicast - jeden odesílatel, mnoho příjemců. ( Příklad: IPTV.

Každý pokus.

- Unicast nejbližšího uzlu - jeden odesílatel, obecně mnoho příjemců, ale ve skutečnosti jsou údaje zaslány pouze na jeden. ( Příklad: Anycast DNS ).

Vzhledem k tomu, že jsme se rozhodli hovořit o multicastu, pak, možná, začněme tímto odstavcem z této otázky, kde a jak se používá.

První věc, která přijde na mysl, je televize (IPTV) - jeden zdrojový server odesílá provoz, který potřebuje přijímat mnoho zákazníků najednou. To je určeno samotným termínem -

Multicast.

- Multicast vysílání. To znamená, že pokud vám vysílání již známo, znamená vysílání všem, multicast znamená vysílání určité skupiny.

  1. Druhá aplikace je například replikace operačního systému do mnoha počítačů. To znamená načtení velkých svazků dat z jednoho serveru.
  2. Možné scénáře: Audio a videokonference (jeden říká - všichni poslouchali), e-commerce, aukce, burzy akcií. Ale to je teoreticky a v praxi se zde používá multicast.

Další aplikace je servisní zprávy protokolu. Například OSPF ve své vysílané doméně odešle své zprávy na adresy 224.0.0.5 a 224.0.0.6. A pouze ty uzly, na kterých je OSPF spuštěn.

Formulujeme dva základní principy multicast bulletinů:

Odesílatel odešle pouze jednu kopii provozu, bez ohledu na počet příjemců.

Doprava obdrží pouze ty, kteří se o to opravdu zajímají.

V tomto článku vezmeme IPTV jako nejvíce vizuálně.

Příklad I.

Začněme s nejjednodušším pouzdrem: Na zdrojovém serveru je vysílání nakonfigurováno pro skupinu 224.2.2.4 - to znamená, že server odešle provoz na adresu IP 224.2.2.4. V klientovi je video přehrávač nakonfigurován tak, aby se skupina 224.2.2.4. .

Zároveň oznámení, klient a server nemusí mít adresy z jedné podsítě a ping navzájem - dost, aby byly v jedné vysílání domény.

Multicast Stream se jednoduše vylévá ze serveru a klient ji prostě vezme. Můžete si to vyzkoušet přímo na pracovišti připojením dvou počítačů s náplastí a spuštěním, například VLC.

Je třeba poznamenat, že v multicastu není signalizace ze zdroje, říkají,

"Ahoj, jsem zdroj, nepotřebujete malý multicast?"

Zdrojový server jednoduše začíná vysílat pakety vícesměrového vysílání v jeho rozhraní. V našem příkladu přímo vstupují do klienta a ten, který je skutečně vezme okamžitě.

Pokud chytíte balíčky na tomto odkazu, uvidíte, že multicast provoz není nic jako pakety UDP moře.

Multicast není připojen k určitému protokolu. Ve skutečnosti vše, co definuje jeho adresy. Pokud však hovoříme o jeho aplikaci, pak v naprosté většině případů je UDP. Snadno je vysvětleno skutečností, že obvykle data, která je zapotřebí, přenášena na pomoc vícesměrového vysílání. Například video. Pokud je ztracen rámec, a odesílatel se bude snažit poslat znovu, jak se to stane v TCP, pak s největší pravděpodobností, tento kus je pozdě, a kde to pak ukázat? Vlak vlevo. Přesně stejný se zvukem.

V souladu s tím není nutné instalovat spojení, takže TCP je potřeba.

Co je tak odklonění multicast z UniCust? Myslím, že už máte předpoklad. A pravděpodobně budete mít pravdu. V obvyklé situaci máme 1 příjemce a 1 odesílatele - každý z nich má jednu jedinečnou adresu IP. Odesílatel přesně ví, kde bruslit balíček a vloží tuto adresu do záhlaví IP. Každý mezilehlý uzel v důsledku jeho směrovacího stolu ví, kde odeslat balíček. Unicast Provoz mezi oběma uzly je bez překážek přes síť. Problém je však, že v obvyklém balíčku je uvedena pouze jedna adresa IP příjemce. Co když jeden a stejný provoz má několik příjemců? V zásadě je možné rozšířit přístup k jednozkustranci a takovou situaci - poslat kopii balíčku každému klientovi. Zákazníci si nevšimnou rozdíl - dokonce jeden, alespoň tisíc, ale rozdíl bude jasně rozlišitelný na kanálech přenosu dat. GPředpokládejme, že máme přenos jednoho SD kanálu z multicast serveru. Nechte to použít 2 MB / s. Celkové kanály 30, a sledování každého kanálu pro 20 lidí současně. Ukazuje se 2 MB / S * 30 kanálů * 20 osob = 1200 MB / s nebo 1,2 GB / s pouze v televize v případě Unicast. Ale je zde stále HD kanály, kde můžete bezpečně vynásobit tuto hodnotu 2 a kde je místo pro torrenty?

Proto byl blok adresy položen v IPv4

Třída D: 224.0.0.0/4

(224.0.0.0-239.255.2555.255). Adresy tohoto rozsahu jsou určeny skupinou multicast. Jedna adresa je jedna skupina, obvykle je označena písmenem "

"

To znamená, že klient je připojen ke skupině 224.2.2.4, znamená to, že přijímá vícesměrový provoz s adresou určení 224.2.2.4.

Příklad II.

Přidat přepínač do schématu a několika dalších zákazníků:

Multicast Server stále vysílá pro skupinu 224.2.2.4. Na spínači musí být všechny 4 porty v jednom VLAN. Provoz přichází na přepínač a výchozí nastavení je odesláno do všech portrétů jednoho VLAN. Takže všichni zákazníci obdrží tento provoz. Skupinová adresa 224.2.2.2.4 je na nich také specifikována vůbec ve videohru.

Ve skutečnosti se všechna tato zařízení stávají členy této multicastové skupiny. Členství v něm je dynamický: Každý, kdykoliv může vstoupit a dostat se z toho. V této situaci se provoz dostane i ty, kteří to nechtějí obecně, to znamená, že ani hráč není na něm nespustí, ani nic jiného. Ale pouze v případě, že je ve stejném VLAN. Později se budeme zabývat tím, jak se s ním vypořádat.

Vezměte prosím na vědomí, že v tomto případě pouze jedna kopie provozu na přepínač pochází ze zdrojového serveru, a ne na samostatné kopii každému klientovi. A v našem příkladu se kanály SD, portový zatížení mezi zdrojem a spínačem nebude 1,2 GB / s, ale pouze 60 MB / s (2MB / C * 30 kanálů).

Ve skutečnosti lze použít celou celou řadu (224.0.0.0.0-239.255.255.255.255).

No, téměř všechny - první adresy (rozsah 224.0.0.0.0.23) jsou stále vyhrazeny pro známé protokoly.

Seznam rezervovaných IP adres

Rozsah 224.0.0.0/24 Vyhrazeno pod link-local

komunikace. Multicast balíčky s takovými adresami určení nemohou překračovat omezení jednoho vysílacího segmentu.

Rozsah 224.0.1.0/24 je vyhrazen pod protokoly, které potřebujete vysílat multicast v celé síti, tj. Směrovače.

Zde ve skutečnosti nejzákladnější věci o multicastu.

Podívali jsme se na jednoduchou situaci, když je zdroj a příjemce ve stejném segmentu sítě. Provoz přijatý přepínačem je prostě odeslána do všech portů - žádná magie.

Ale stále je to naprosto nepochopitelný, jak provoz ze serveru dosáhne zákazníků, pokud je obrovský poskytovatel síť Linkmiap? A kde bude ve skutečnosti známo, kdo je klient? Nemůžeme ručně registrovat trasy, prostě proto, že nevíte, kde mohou být zákazníci. Obvyklé směrovací protokoly neodpoví na tuto otázku. Tak jsme pochopili, že doručení multicastu je pro nás něco úplně nového.

Obecně platí, že pro doručování vícesměrového vysílání ze zdroje do příjemce v současné době existuje mnoho protokolů - IGMP / MLD, PIM, MSDP, MBGP, MSPF, DVMRP.

Zaměřme se na dva z nich, které jsou v současné době používány: PIM a IGMP. S IGMP, konečné příjemci zákazníků sdělují nejbližší směrovače, které chtějí přijímat provoz. A PIM staví cestu pohybu multicast provozu ze zdroje pro příjemce přes směrovače. Igmp.

Znovu se vrátit na výpis. Podívejte se na tento top balení, po kterém byl hozen multicast proud?

Tato zpráva protokolu IGMP odeslaná klientem, když jsme na něm stiskli. To je způsob, že hlásí, že chce přijímat provoz pro skupinu 224.2.2.4.

IGMP - Internet Group Management Protocol

- Jedná se o síťový protokol interagující klienty multicast dopravy a nejbližší směrovač.

IPv6 používá MLD (Multicast Listener Discovery) namísto IGMP. Princip operace, kterou mají naprosto stejné, takže můžete snadno změnit IGMP všude na MLD a IP na IPv6.

Jak přesně funguje IGMP?

Možná musíte začít s tím, že verze protokolu jsou nyní tři: IGMPv1, IGMPv2, IGMPv3. Nejpoužívanější - druhý, první je téměř zapomenut, takže o tom nebudeme mluvit, třetí je velmi podobná druhému.

Budu se zaměřovat na druhý, jako na nejvíce dopad a zvážit všechny události od připojení klienta do skupiny dříve, než je z toho.

Klient bude také požadovat skupinu 224.2.2.4 prostřednictvím přehrávače VLC. Úloha IGMP je velmi jednoduchá: Pokud neexistují zákazníci - není nutné přenášet vícesměrový provoz na segmentu. Pokud se objeví klient, upozorní směrovače pomocí IGMP, které chce přijímat provoz. Abychom pochopili, jak se všechno děje, vezměte tuto síti: Předpokládejme, že směrovač je již nakonfigurován pro přijímání a zpracování provozu vícesměrového vysílání.

jeden.

Jakmile jsme spustili aplikaci na klienta a nastavili skupinu 224.2.2.4, balíček bude zaslán do sítě Zpráva o členství IGMP - "Zprávy" uzel, který chce dostávat provoz této skupiny.

Ve zprávě IGMPv2 jde na adresu požadované skupiny a paralelně je uvedena v samotném balení. Tyto zprávy musí žít pouze v rámci svého segmentu a negmentují se přesto směrovači, proto mají 1 TTL. Často v literatuře můžete splnit zmínku o

IGMP Připojit.

. Nenechte se bát - to je alternativní název pro zprávu o členství IGMP.

2.

Router obdrží zprávu IGMP a uvědomit si, že toto rozhraní má nyní zákazníky, poskytuje informace ve svých tabulkách

Jedná se o výstup informací o IGMP. První skupina je požadována klientem. Třetí a čtvrté jsou zprávy SSDP služby.

Vestavěný v oknech. Druhá je speciální skupina, která je vždy přítomna na směrovačích Cisco - používá se pro Auto-RP protokol. který je aktivován ve výchozím nastavení na směrovačích. Rozhraní Fe0 / 0 se stává sestupovat pro skupinu 224.2.2.4 - bude muset poslat přijatý provoz. Spolu s obvyklým unikátním směrovacím stolem je také multicast: O dostupnosti zákazníků říká první záznam

(*, 224.2.2.4)

. A záznam (172.16.0.5, 224.2.2.2.4) .

To znamená, že router ví o zdroji multicastu proudu pro tuto skupinu. Z výstupu je zřejmé, že provoz pro skupinu 224.2.2.4 přichází přes FE0 / 1 a je nutné jej přenášet do portu FE0 / 0. Rozhraní, ve kterých potřebujete přenášet provoz, jsou zahrnuta do seznamu navazujících rozhraní -

Seznam olejů - Outbound Interface

Podrobněji příkaz Zobrazit IP MRULE. Budeme rozeznat později. . Nad skládkou vidíte, že jakmile klient odeslal zprávu IGMP, ihned po letu UP UP UDP je video stream. .

3. Klient začal přijímat provoz. Nyní by měl směrovač někdy zkontrolovat, zda příjemci mají stále mezeru, aby vysílali, pokud zůstanou náhle zákazníci. K tomu periodicky odešle požadavek na všechna jeho sestupná rozhraní. IGMP dotaz.

* Výpis filtrován podle IGMP * Nad skládkou vidíte, že jakmile klient odeslal zprávu IGMP, ihned po letu UP UP UDP je video stream. .

Ve výchozím nastavení se to stane každých 60 sekund. TTL takové balíčky jsou rovné 1. Jsou zaslány na adresu 224.0.0.1 - všechny uzly v tomto segmentu - bez určení specifické skupiny. Takové zprávy dotazu jsou volány

Obecný dotaz.

- Všeobecné. Směrovač se tedy ptá: "kluci, a kdo a co ostatní chce dostávat?".

Po obdržení generálního dotazu IGMP, kterýkoli hostitel, který poslouchá jakoukoli skupinu, musí poslat zprávu IGMP, jak to bylo při připojení. Adresa skupiny zájmu své skupiny by měla být uvedena ve zprávě. Pokud se v reakci na dotaz přišla alespoň jedna zpráva do routeru, znamená to, že stále existují zákazníci, pokračuje v vysílání, že rozhraní z místa, kde tato zpráva pochází, provoz této skupiny. Pokud dotaz neměl odpověď z rozhraní reakce pro některé skupiny, směrovač odstraní toto rozhraní z jeho multicast směrovací tabulky pro tuto skupinu - přestane odesílat provoz. Na své iniciativě klient obvykle odešle zprávu pouze v případě připojení, pak jednoduše reaguje na dotaz z routeru. Zajímavým detailem v chování klienta: Po obdržení dotazu není ve spěchu, aby okamžitě odpověděl. Uzel má délku časového limitu od 0 do .Maximální doba odezvy. .

který je uveden v dalším dotazu: Při ladění nebo ve výpisu, mimochodem, je vidět, že mezi různými sestavami může projít několik sekund. To se děje, takže stovky zákazníků není celost působnosti, které nejsou zaplaveny sítí se svými zprávami tím, že obdrželi obecný dotaz. Kromě toho pouze jeden klient obvykle odešle zprávu. Faktem je, že zpráva je odeslána na adresu skupiny, a proto přichází ke všem zákazníkům. Po obdržení zprávy z jiného klienta pro stejnou skupinu, uzel nebude posílat své vlastní. Logika je jednoduchá: router již obdržel tuto zprávu a ví, že existují zákazníci, není to nutné.

Tento mechanismus se nazývá

Zpráva o potlačení

Další v článku budeme říct, proč je tento mechanismus ve skutečnosti velmi zřídka pracuje čtyři. Tak pokračuje po staletí, dokud klient chce ukončit skupinu (například vypnout přehrávač / TV). V tomto případě posílá IGMP dovolená. adresu skupiny.

Směrovač to obdrží a v myšlence se musí vypnout. Ale nemůže zakázat jeden konkrétní klient - směrovač je nerozlišuje - má to jen po proudu. A rozhraní může být několik zákazníků. To znamená, že pokud router odstraní toto rozhraní z jeho seznamu OU (seznam odchozích rozhraní) pro tuto skupinu, video se vůbec vypne.

Ale také to neodstraňujte, je také nemožné - najednou to byl poslední klient - Proč to pak omyjte? Nad skládkou vidíte, že jakmile klient odeslal zprávu IGMP, ihned po letu UP UP UDP je video stream. .

Pokud se podíváte do skládky, uvidíte, že po obdržení routeru dovolené, proud pokračuje po nějakou dobu. Faktem je, že směrovač v reakci odešlete odesílá dotaz IGMP na adresu skupiny, pro kterou tato dovolená přišla k tomuto rozhraní, odkud pocházel. Takový balíček se nazývá

Specifický dotaz skupiny.

. Odpověz

pouze Specifický dotaz skupiny. Ti klienti, kteří jsou spojeni s touto konkrétní skupinou.

Pokud router obdržel zprávu odpovědi pro skupinu, pokračuje v vysílání v rozhraní, pokud není přijata - odstraní časovač poté, co časovač vypršela.

Celkem po obdržení dovolené, dvě skupiny specifický dotaz jde - jedna povinná, druhá kontrola. Dále router zastaví proud. Querier. Zvažte o něco více obtížnějšího: Dva (nebo více) směrovačů, které mohou vysílat provoz, jsou připojeny k segmentu klienta. Pokud neuděláte nic, bude multicast provoz duplikován - oba směrovače dostanou zprávu od zákazníků. Aby se tomu zabránilo, existuje volba mechanismus - politika. Ten, kdo vyhraje, bude posílat dotaz, sledovat zprávu a reagovat na odchod, a proto bude posílat provoz na segmentu. Loser bude poslouchat pouze hlášení a udržet ruku na pulsu. Volby se vyskytují poměrně jednoduché a intuitivní. Zvažte situaci od okamžiku, kdy jsou routery R1 a R2 zapnuty. jeden) Aktivované IGMP na rozhraní. 2) Zpočátku, ve výchozím nastavení, každý z nich považuje sám Querier. 3) Každý odešle generální dotaz IGMP do sítě. Hlavním cílem je zjistit, zda existují zákazníci, a paralelně - prohlásit ostatním směrovačům v segmentu, pokud jsou, o vaší touze účastnit se voleb. čtyři) Obecný dotaz přijímá všechna zařízení v segmentu, včetně dalších směrovačů IGMP. Pět) Po obdržení takové zprávy od souseda, každý router odhaduje, kdo hodnější. 6) Vyhrává router S.

Menší IP.

(specifikováno ve zdrojovém IP pole IGMP dotazu). Stává se Querier, všechny ostatní - ne-Querier.

7)

Ne-Querier Spustí časovač, který je resetován pokaždé, když se kvaryny dodává s menší IP adresou. Pokud před vypršením časovače (více než 100 sekund: 105-107), směrovač nedostane dotaz s menší adresou, prohlašuje sám QEERIER a přebírá všechny odpovídající funkce. osm) Pokud Querier obdrží dotaz s menší adresou, dodává tyto povinnosti. Querier se stává dalším routerem, který má IP méně.

Tento vzácný případ, když je měřen, kdo je méně. Volby Querier jsou velmi důležitým postupem v multicastu, ale některé zákeřné výrobci, kteří nedrží RFC, mohou vložit silnou hůlku do kol. Mluvím o dotazu IGMP s adresou zdroje 0.0.0.0, který může být generován přepínačem. Tyto zprávy by se neměly zúčastnit volby Querier, ale musíte být připraveni na všechno. Zde je příklad Velmi složitý dlouhodobý problém.

.

Více slov o jiných verzích IGMP Verze 1 se liší v podstatě pouze skutečností, že Nemá žádnou zprávu

.

. Pokud klient nechce získat více provozu této skupiny, jednoduše přestane poslat zprávu v reakci na dotaz. Pokud není jediný klient zůstane, časový limitový router přestane odesílat provoz. Navíc, Žádné volby Querier jsou podporovány.

. Aby se zabránilo zdvojování provozu, je vyšší protokol zodpovědný, například PIM, o kterém budeme mluvit dále Verze 3 podporuje všechny, které podporuje IGMPv2, ale existuje řada změn. Za prvé, zpráva není odeslána již na adresu skupiny, ale na adrese služby vícesměrového vysílání 224.0.0.22.

. A adresa požadované skupiny je uvedena pouze v rámci balíčku. To se děje pro zjednodušení díla IGMP Snooping, o kterém budeme mluvit

.

Za druhé, co je důležitější, IGMPv3 začal podporovat SSM v jeho čisté formě. To je tzv.

Nad skládkou vidíte, že jakmile klient odeslal zprávu IGMP, ihned po letu UP UP UDP je video stream. .

Klient bude také požadovat skupinu 224.2.2.4 prostřednictvím přehrávače VLC. Zdroj specifický multicast. Ve zprávě IGMPv2 jde na adresu požadované skupiny a paralelně je uvedena v samotném balení. Tyto zprávy musí žít pouze v rámci svého segmentu a negmentují se přesto směrovači, proto mají 1 TTL. . V tomto případě klient nemusí jen požadovat skupinu, ale také specifikovat seznam zdrojů, ze kterých by chtěl získat provoz nebo naopak, by to nechtěl. V IGMPV2 klient jednoduše požádá a přijímá skupinový provoz bez péče o zdroj. IGMP je tedy navržen tak, aby spolupracoval zákazníky a router. Proto se vracet Podrobněji příkaz Příklad II. 4Jak víte, existují následující typy provozu: Tam, kde neexistuje žádný router, můžeme autoritativně deklarovat - IGMP tam - ne více než formalita. Neexistuje žádný router, a klient nemá nikdo požádat o multicast proud. A vydělá video pro jednoduchý důvod, že proud a tak se vylévá z přepínače - stačí ho vyzvednout. Připomeňme, že IGMP nefunguje pro IPv6. Protokol MLD Opakuj znovu Za prvé, router poslal svůj generální dotaz IGMP po zapnutí IGMP na svém rozhraní, abyste zjistili, zda jsou příjemci a prohlásili svou touhu být dotazem. V té době nikdo nebyl v této skupině. Poté se objevil klient, který chtěl přijímat provoz skupiny 224.2.2.4 a poslal svou zprávu IGMP. Poté jsem na něm šel do provozu, ale je odfiltrován z skládky. Potom se router z nějakého důvodu z nějakého důvodu zkontroloval - a zda nejsou žádné další zákazníky a zaslány generálního dotazu IGMP, ke kterému je klient nucen odpovědět ( Pět.

Pravidelně (jednou za minutu) směrovač kontroluje, že příjemci stále mají, pomocí generálního dotazu IGMP a uzel toto potvrzuje pomocí zprávy IGMP.

Ale stále je to naprosto nepochopitelný, jak provoz ze serveru dosáhne zákazníků, pokud je obrovský poskytovatel síť Linkmiap? A kde bude ve skutečnosti známo, kdo je klient? Nemůžeme ručně registrovat trasy, prostě proto, že nevíte, kde mohou být zákazníci. Obvyklé směrovací protokoly neodpoví na tuto otázku. Tak jsme pochopili, že doručení multicastu je pro nás něco úplně nového. 6. Pak změnil svou mysl a odmítl skupinu odesláním opuštění IGMP. 7. Router přijal dovolenou a chtěl se ujistit, že žádné další příjemci nejsou jiní příjemci, odesílejte specifický dotaz skupiny IGMP ... dvakrát. A po uplynutí časovače přestane vysílat provoz. osm. Nicméně, pokračuje v přenášení dotazu IGMP do sítě. Například v případě, že jste přehrávač nevypnuli, ale jednoduše někde s připojením problému. Poté je připojení obnoveno, ale klient neposílá zprávu sama. Ale dotaz odpovědi. Průtok tak může obnovit bez lidské účasti. Ještě jednou To se děje, takže stovky zákazníků není celost působnosti, které nejsou zaplaveny sítí se svými zprávami tím, že obdrželi obecný dotaz. Kromě toho pouze jeden klient obvykle odešle zprávu. - Protokol, kterými se směrovač dozví o přítomnosti příjemců multicastů a jejich odpojení. Specifický dotaz skupiny. IGMP Zpráva

- Odeslané klientem při připojení a v reakci na dotaz IGMP. To znamená, že klient chce dostávat podívanou konkrétní skupiny.

.

IGMP Obecný dotaz.

- Poslání routeru periodicky ke kontrole, které skupiny jsou nyní potřebné. Jako adresa příjemce, 224.0.0.1 je uvedena.

IGMP Group SEPCIFIC QUERY

- Poslal směrovač v reakci na zprávu odešlete, zjistit, zda v této skupině jsou další příjemci. Jako adresa příjemce je uvedena adresa skupiny multicastu.

- Vybraní klientem, když chce opustit skupinu.

- Pokud v jednom vysílaném segmentu existuje několik směrovačů, které lze vysílat, mezi nimi je vybrán jeden hlavní - Querier. Pravidelně posílá dotaz a přenášet provoz.

Podrobný popis všech IGMP termíny

Pime

Takže jsme přišli, jak zákazníci informují nejbližší router o jejich záměru. Teď by bylo hezké přenášet provoz ze zdroje do příjemce přes velkou síť. Pokud o tom přemýšlíte, stojíme před spokojeným komplexním problémem - zdroj pouze vysílat skupině, neví nic o tom, kde jsou příjemci nacházejí a kolik. .

Příjemci a nejbližší směrovače vědí jen to, že potřebují podívanou konkrétní skupiny, ale není tušení, kde je zdroj a jaká je jeho adresa. Jak dodávat provoz v této situaci?

Existuje několik multicast provozních směrovacích protokolů: DVMRP

  • , MSPF.
  • , CBT.

- Všichni vyřeší takový úkol různými způsoby. Ale standardní de facto se stal

PIM - Nezávislý multicast protokolu

Ostatní přístupy jsou tak nechtěné, že někdy i jejich vývojáři ji prakticky uznávají. Zde například výňatek z RFC přes protokol CBT: CBT verze 2 není a nebyla zamýšlena, aby byla zpětně kompatibilní s verzí 1; Neodpovídáme toto tak, aby způsobily rozsáhlé problémy s kompatibilitou, protože nevěříme, že CBT je vůbec široce nasazen v této fázi.

PIM má dvě verze, které mohou být v zásadě nazývány dvěma různými protokoly, jsou silně odlišné:

PIM hustý režim (DM)

Režim PIM řídký (SM) Nezávislý Je proto, že není vázán na konkrétní program směrování jedinečného provozu a později uvidíte proč. .

Pim hustý režim.

Pim dm.

Snaží se vyřešit problém doručení multicustu na čele. Zřejmě předpokládá, že příjemci jsou všude, ve všech koutech sítě. Proto zpočátku položí celou síť vícesměrového provozu, to znamená, že to pošle do všech přístavů, navíc, odkud pochází. Pokud se tedy ukáže, že někde není potřeba, pak tato větev je "odříznuta" s pomocí speciální zprávy PIM prořezání - provoz již není odeslán. Ale po chvíli ve stejné pobočce se router znovu snaží poslat vícesměrový počítač - náhle se tam objevili příjemci. Pokud se neobjevil, větev je opět odříznuta v určitém období. Pokud se klient na směrovači objevil v intervalu mezi těmito dvěma událostmi, zpráva štěpu je odeslána - router požaduje odbočku zpět tak, aby nečekal, až něco zapadne. .

Jak vidíte, neexistuje žádná otázka určování cesty pro příjemce - provoz bude dosáhnout jednoduše proto, že je všude.

Po "obřízce" zbytečných větví zůstává strom, na kterém je předán vícesměrový provoz. Tento strom se nazývá

SPT - Nejkratší cestou strom

Jedná se o smyčky a používá nejkratší cestu od příjemce ke zdroji. V podstatě je velmi podobná překlenování stromu v STP

Kde je kořen zdrojem.

SPT je betonový strom pohled - nejkratší strom strom. Obecně se nazývá každý multikonní strom

MDT - Multicast Distribution Strom

Předpokládá se, že PIM DM by měl být používán na sítích s vysokou hustotou zákazníků multicastu, což vysvětluje jeho název (hustý). Ale realita je taková, že tato situace je spíše výjimkou, a často PIM DM je nevhodné. To, co je pro nás opravdu důležité, je mechanismus, který se vyhnul smyčcům. Představte si takovou síť:

Jeden zdroj, jeden příjemce a nejjednodušší síť IP mezi nimi. Na všech směrovačích běží PIM DM.

Co by se stalo, kdyby nebyl žádný zvláštní mechanismus, aby se zabránilo smyčkám?

Zdroj odesílá vícesměrový provoz. R1 ji přijímá a v souladu s principy PIM DM posílá všem rozhraním, krome, kde pocházel z - to je na R2 a R3.

R2 vstupuje stejným způsobem, to znamená, že posílá provoz směrem R3. R3 nemůže určit, že se jedná o stejný provoz, který již obdržel od R1, takže jej odešle na všechna jeho rozhraní. R1 obdrží kopii provozu z R3 a tak dále. Zde je smyčka.

Co nabízí PIM v takové situaci?

RPF - Reverzní přesměrování cesty

. To je hlavní princip přenášení vícesměrového provozu v PIM (jakýkoliv druh: a DM a SM) - provoz ze zdroje musí přijít podél nejkratší cesty. To znamená, že pro každý přijatý multicast balíček je zkontrolován na základě směrovacího stolu, ať už to pochází. 1) Směrovač se dívá na adresu zdroje paketu vícesměrového vysílání.

2) Zkontroluje směrovací tabulku, přes které je k dispozici zdrojová adresa.

3) Kontroluje rozhraní, kterým přišel multicast balíček.

4) Pokud se rozhraní shodují - vše je v pořádku, balíček vícesměrového vyskočení je přeskočen, pokud data pocházejí z jiného rozhraní - budou vyřazeny.

Příklad: IPTV.

V našem příkladu R3 ví, že nejkratší cesta ke zdroji leží přes R1 (statická nebo dynamická trasa). Proto multicast pakety, které pocházejí z R1, jsou testovány a přijaté R3, a ty, které přišly od R2, jsou vyřazeny.

Tato kontrola se nazývá

Kontrola RPF. A díky ní i ve složitějších sítích nebudou vzniknout smyčky v MDT. Tento mechanismus je pro nás důležitý, protože je to relevantní a v Pim-SM a pracuje tam sám.

Jak vidíte, PIM je založen na tabulce unikátních směrování, ale nejprve to neurčí provoz, za druhé, nezáleží na tom, kdo a jak vyplnit tabulku. Nebudete zde zastavit a zvažovat práci PIM DM podrobně - jedná se o zastaralý protokol s vážením nedostatků (stejně jako rip .

V některých případech však může být použit PIM DM. Například ve velmi malých sítích, kde je tok multicast malý.

Režim sparse PIM.

Úplně jiný přístup platí Pim sm.

. Navzdory názvu (poškozený režim) může být úspěšně použit v jakékoli síti s účinností alespoň ne horší než PIM DM.

.

Zde odmítli představu o bezpodmínečných záplavách sítě multicastu. Zúčastněné uzly nezávisle vyžádejte připojení stromu pomocí zpráv 
Pim připojit. Pokud směrovač neposleněn, pak nebude provoz odeslán. Abychom pochopili, jak PIM funguje, začněte s jednoduchou sítí s jedním směrovačem PIM:

Z nastavení na R1 musíte povolit schopnost směrování multicastu, PIM SM na dvou rozhraních (směrem ke zdroji a k ​​klientovi) a IGMP směrem k klientovi.

Kromě dalších základních nastavení, samozřejmě (IP, IGP).

Od nynějška můžete pustit GNS a sbírat laboratoř. Stačí, jak sestavit stojan pro multicast, který jsem v tomto článku řekl.

R1 (CONFIG) #IP Multicast-směrování R1 (CONFIG) #int FA0 / 0 R1 (CONFIG-IF) #IP PIM SPARLSE-Mode R1 (Config-If) #int FA1 / 0 R1 (Config-If) #IP PIM Řídký režim. Cisco zde obvykle obsahuje svůj speciální přístup: Když aktivujete PIM na rozhraní, IGMP se automaticky aktivuje. Na všech rozhraních, kde je PIM aktivován, funguje a IGMP. Zároveň mají další výrobci dva různé protokoly zapnout dva různé příkazy: Samostatný IGMP, samostatně PIM. Odpusťte Cisco tuto zvláštnost? Spolu se všemi ostatními? Plus, může být nutné konfigurovat adresu RP ( IP PIM RP-adresa 172.16.0.1 např.). O tom později při přijímání jako daný a přijetí.

Zkontrolujte aktuální stav multicast směrovací tabulky pro skupinu 224.2.2.4: Po spuštění vysílání na zdroji musíte znovu zkontrolovat tabulku. Pojďme analyzovat tento malý závěr.

Zobrazení záznamu (*, 225.0.1.1) Zároveň mají další výrobci dva různé protokoly zapnout dva různé příkazy: Samostatný IGMP, samostatně PIM. volala Plus, může být nutné konfigurovat adresu RP ( (*, G) / Přečtěte si Starkomadzhi. (/ A informuje nás o příjemcích. A není nutné hovořit o jednom klientském počítači, obecně to může být například další směrovač PIM. Je důležité, na které rozhraní musí projít provozem. Pokud je seznam sestupných rozhraní (olej) prázdný -

NULA

Proto neexistují žádné příjemce - a ještě jsme je nespustili.

Záznam

(172.16.0.5, 225.0.1.1) (S, G) .

Eskijah.

/ A naznačuje, že zdroj je znám. V našem případě zdroj s adresou 172.16.0.5 vysílání provozu pro skupinu 224.2.2.4. Provoz multicastu přichází do rozhraní FE0 / 1 - to je

vzestupně

Proti proudu

) Rozhraní.

Takže žádné zákazníky. Provoz ze zdroje přichází do routeru a na tomto životě končí. Přidejme nyní příjemce - nastavíme příjem multicast na PC.

PC odesílá sestavu IGMP, router chápe, že se zákazníci objevili a aktualizuje směrovací tabulku vícesměrového vysílání. Teď vypadá takto: Následně se objevilo downstream rozhraní: Fe0 / 0, který je zcela očekávaný. A objevilo se jak v (*, g) a v (s, g). Seznam následných rozhraní se nazývá

Seznam olejů - odchozí rozhraní

.

Přidání jiného klienta do rozhraní FE1 / 0:

Pokud si přečtete výstup doslova, máme:

(*, G): Existují vícesměrové dopravní příjemce pro skupinu 224.2.2.4 mimo rozhraní FE0 / 0, FE1 / 0. A absolutně bez ohledu na to, kdo odesílatel, co a říká znamení "*". 

(S, G): Při multicastu s cílovou adresou 224.2.2.2.4 od zdroje 172.16.0.5 přichází do rozhraní FE0 / 1, jeho kopie musí být odeslány do FE0 / 0 a FE1 / 0.

Byl to však velmi jednoduchý příklad - jeden směrovač okamžitě zná zdrojovou adresu a kde jsou příjemci umístěny. Ve skutečnosti, i stromy, které zde nejsou - s výjimkou degenerovaného. Ale pomohlo nám řešit, jak PIM a IGMP interagují. 
Chcete-li se vypořádat s tím, co je pim, obracíme se k síti mnohem složitější

Předpokládejme, že všechny adresy IP jsou již nakonfigurovány v souladu se schématem. Síť běží IGP pro běžné unikátní směrování. Klient1 Můžete například ping zdrojový server. Ale zatím PIM, IGMP není spuštěn, zákazníci nevyžadují kanály. Konfigurace souboru

Takže okamžik času 0.

Zapněte směrování multicast na všech pěti směrovačích:

RX (config) #ip multicast-směrování

PIM je zahrnut 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 SPARLSE-MODE IGMP, teoreticky, by měla být zahrnuta na rozhraní vůči zákazníkům, ale jak jsme již zaznamenali výše, zapne se automaticky na zařízení Cisco s PIM. První věc, kterou PIM dělá - nastaví sousedství. Zprávy používané pro toto

PIM Ahoj.

. Když aktivujete PIM na rozhraní, PIM Ahoj je odeslán na adresu

  1. 224.0.0.13.
  2. S TTL rovnou 1. To znamená, že pouze směrovače v jedné vysílané doméně mohou být sousedé.

Jakmile se sousedé dostali pozdravy z sebe:

Nyní jsou připraveni přijmout aplikace pro vícesměrové skupiny.

Pokud nyní začneme v uzavřeném prostoru zákazníka na jedné straně a zapnete proud multicast ze serveru na druhé straně, pak R1 obdrží tok dopravy a R4 obdrží zprávu IGMP při pokusu o připojení. V důsledku toho R1 nebude vědět nic o příjemcích a R4 na zdroji. Bylo by hezké, kdyby informace o zdroji a klientům skupiny byly shromážděny někde na jednom místě. Ale v čem? Takový bod schůzky se nazývá

Rendezvous Point - RP 

. To je centrální koncept SM. Bez ní nic nefungovalo. Zde je zdroj a příjemci.

Všechny směrovače PIM by měly vědět, kdo je RP v doméně, to je, znát jeho IP adresu. Chcete-li vytvořit strom MDT, síť je vybrána jako RP nějaký centrální bod, který, zodpovědný za studium zdroje,

Je to bod přitažlivost spojených zpráv ze všech zájemců. 

Existují dva způsoby, jak úkol RP: statický a dynamický. Podíváme se na oba v tomto článku, ale začínáme statickým, protože to, co je pravděpodobnější, že bude statický?

Nechte R2 hrát RP.

Pro zvýšení spolehlivosti je obvykle vybrána adresa Loopback. proto

pro každého

Směrovače jsou provedeny příkazem: RX (CONFIG) #IP PIM RP-adresa 2.2.2.2 )

Tato adresa musí být přirozeně dostupná na 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) #Interface Loopback 0 RX (CONFIG-IF) #IP PIM SPARLSE-MODE )

Ihned po tom, R4 se dozví o zdroji provozu pro skupinu 224.2.2.4:

A dokonce převodů provozu:

Rozhraní Fe0 / 1 přichází 362000 b / s a ​​přes rozhraní FE0 / 0 jsou přenášeny.

Jediné, co jsme udělali: Dále router zastaví proud. Zahrnoval schopnost směrování provozu vícesměrového vysílání (

Zvažte o něco více obtížnějšího: IP multicast-směrování

Aktivovaný pim na rozhraní ( To znamená, že pro každý přijatý multicast balíček je zkontrolován na základě směrovacího stolu, ať už to pochází. IP PIM řídký režim

Uvedeno adresu RP ( IP PIM RP-Adresa X.x.x.x. Všechno, to je již pracovní konfigurace a lze je vyhledat, protože scény jsou skryté mnohem více než viditelné na jevišti. Plná konfigurace s PIM.

- politika. Ten, kdo vyhraje, bude posílat dotaz, sledovat zprávu a reagovat na odchod, a proto bude posílat provoz na segmentu. Loser bude poslouchat pouze hlášení a udržet ruku na pulsu. Debriefing.

No, jak to všechno funguje na konci? Jak RP ví, kde je zdroj, ve kterém zákazníci a poskytuje komunikaci mezi nimi? Vzhledem k tomu, že všechno dopadne kvůli našim oblíbeným zákazníkům, počínaje s nimi, zvažte celý proces v detailech. Klient 1 Odesílá sestavu IGMP pro skupinu 224.2.2.4

R4 Dostane tento dotaz, chápe, že existuje klient mimo rozhraní Fe0 / 0, přidá toto rozhraní k nahrávání olejů a formulářů (*, g).

Zde je vidět vzestupné rozhraní Fe0 / 1, ale to neznamená, že R4 přijímá provoz pro skupinu 224.2.2.4. Mluví pouze, že jediné místo odkud může přijímat, je Fe0 / 1, protože je tam, že RP je tam. Mimochodem, soused, který prošel

Zvažte situaci od okamžiku, kdy jsou routery R1 a R2 zapnuty. - R2: 10.0.2.24. Očekávaný.

R4 se nazývá - LHR (poslední hopový router) - poslední směrovač na cestě vícesměrového provozu, pokud se počítají ze zdroje. Jinými slovy, to je router nejblíže příjemci. Pro

Klient1. - Je to R4 Klienta2.

- To je R5.

Vzhledem k tomu, že neexistuje žádný multicast proud na R4 (dříve nebylo požadováno), tvoří zprávu PIM spojit a odešle směrem k RP (2.2.2.2.2).

PIM Join je zaslán multicast k adrese 224.0.0.13. "Ve směru RP," prostředky přes rozhraní uvedené v tabulce směrování, jako odchozí pro adresu, která je zadána uvnitř balíčku. V našem případě je to 2.2.2.2 - Adresa RP. Takové spojení je označováno jako

Připojit (*, g)

A říká: "Nezáleží na tom, kdo zdroj potřebuji skupinovou dopravu 224.2.2.4." To znamená, že každý router na cestě by měl zvládnout takové spojení a v případě potřeby zaslat nový se spojení na stranu RP. (Je důležité pochopit, že pokud již existuje tato skupina na routeru, nebude posílat spojení - jednoduše přidá rozhraní, ze kterého se připojuje k oleji a začne projíždět provoz). V našem případě se připojte do Fe0 / 1:

R2, které mají přijaté spojení, generuje záznam (*, g) a přidá rozhraní Fe0 / 0 na olej. Ale připojit se již nemůže poslat - on sám už RP, a nic není známo o zdroji. Ale po chvíli ve stejné pobočce se router znovu snaží poslat vícesměrový počítač - náhle se tam objevili příjemci. Pokud se neobjevil, větev je opět odříznuta v určitém období. Pokud se klient na směrovači objevil v intervalu mezi těmito dvěma událostmi, zpráva štěpu je odeslána - router požaduje odbočku zpět tak, aby nečekal, až něco zapadne. RP se tedy učí o tom, kde se nacházejí zákazníci.

Aktivované IGMP na rozhraní. Pokud

Klienta 2. Také chtějí přijímat vícesměrový provoz pro stejnou skupinu, R5 bude posílat PIM připojit k Fe0 / 1, protože je RP, R3, který byl přijat, tvoří nový pim připojit a odešle jej do FE1 / 1 - kde se nachází RP. To znamená, že se připojte k putováním tak uzlu za uzlem, dokud se nedostane na RP nebo do jiného směrovače, kde již existují zákazníci této skupiny.

R2 je náš RP - nyní ví, že pro Fe0 / 0 a Fe1 / 0 má příjemce pro skupinu 224.2.2.4.

Nezáleží na tom, kolik je tam - jeden po každém rozhraní nebo sto - tok dopravy bude stále jeden na rozhraní. Pokud zobrazíte graficky to, co máme, bude to vypadat takto: Dálkově podobá stromu, že? Proto se nazývá -

Zpočátku, ve výchozím nastavení, každý z nich považuje sám Querier. RPT - Rendezvous Point Strom

. Tento strom je zakořeněn v RP, a jehož pobočky se rozšiřují zákazníkům.

Obecnější termín, jak jsme zmíněni výše -

- Strom podél toho, který je distribuován multicast proud. Později uvidíte rozdíl mezi MDT a RPT.

Nyní dáváme serveru. Jak jsme již diskutovali výše, nemusí se starat o PIM, RP, IGMP - jen vysílá. A R1 dostane tento proud. Jeho úkolem je dodat multicast k RP. V PIM je speciální typ zpráv - Registrovat . Je třeba zaregistrovat vícesměrový zdroj na RP.

Obecný dotaz přijímá všechna zařízení v segmentu, včetně dalších směrovačů IGMP. Tak, R1 obdrží proud multicastu skupin 224.2.2.4:

R1 je

FHR (první hopový router)

- první směrovač na cestě vícesměrového provozu nebo nejblíže zdroji.

Dále zapouzdí každý multicast balíček přijatý ze zdroje do jedinečného registru PIM a odešle jej přímo na RP.

  1. Věnujte pozornost zásobníku protokolu. Na vrcholu UniCust IP a záhlaví PIM je původní multicast IP, UDP a data.
  2. Nyní, na rozdíl od všech ostatních, jsou uvedeny zprávy PIM známé, na adrese příjemce, 2.2.2.2, a nikoli multikonální adresu.

Takový balíček je dodáván RP podle standardních pravidel Unicreten Suring a nese původní balíček vícesměrového vysílání, to znamená, že je to ... Toto je tunelování!

=====================================

Číslo úkolu 1. Schéma a počáteční konfigurace. .

Po obdržení takové zprávy od souseda, každý router odhaduje, kdo hodnější. Na serveru 172.16.0.5, aplikace, která může přenášet balíčky pouze na vysílání adresy 255.255.255.255 s příjemcem UDP 10999. Tento provoz musí být doručen zákazníkům 1 a 2: .

Zákazník 1 ve formě vícesměrového provozu s adresou skupiny 239.9.9.9.

A v segmentu klienta 2 ve formě balíčků vysílání na adresu 255.255.255.255.

Podrobnosti o úkolu zde.

===================================== Schéma a počáteční konfigurace. RP přijímá registru PIM, rozbalí ji a detekuje provoz pod obalem pro skupinu 224.2.2.4. Nezávislý Je proto, že není vázán na konkrétní program směrování jedinečného provozu a později uvidíte proč. Informace o tom okamžitě vstoupí do své tabulky multicast směrování:

Vstup (S, G) - (172.16.0.5, 224.2.2.2.2.4). Rozbalené RP pakety dále odešle na rozhraní Fe0 / 0 a Fe1 / 0, podle kterého provoz přichází zákazníkům.

V zásadě to mohlo být zastaveno. Všechno funguje - zákazníci dostávají provoz. Existují však dva problémy:

Zpracovává zapouzdření a decapsulation - velmi nákladné akce pro směrovače. Kromě toho, další záhlaví zvyšují velikost balíčku, a to prostě nemůže vylézt do MTU někde na mezilehlém uzlu (pamatujete si všechny problémy tunelování).

Pokud se najednou někde mezi zdrojem a RP jsou také příjemci pro skupinu, multicast provoz bude muset projít dvakrát jednou cestou. Take zde je taková topologie: Provoz v registrových zprávách budou nejprve dosáhnout RP podél řádky R1-R42-R2, pak se čistý vícesměrový počítač vrátí podél řádku R2-R42. Tak, na lince R42-R2, dvě kopie jednoho provozu půjdou, i když v opačných směrech. Proto je lepší převést čistý multicast k RP RP, a pro to musíte vytvořit strom - Zdrojový strom Proto RP posílá pim připojit k R1. Nyní je však uveden v něm pro adresu skupiny, která není RP, ale zdroj studoval ze zprávy rejstříku. Tato zpráva se nazývá Připojte se k (S, G) - Specifický zdroj Jeho cílem je přesně stejný jako pim spojení (*, g) - vybudovat strom, pouze tentokrát ze zdroje k RP. Připojit (s, g) také rozšiřuje uzel za uzlem jako obvyklé spojení (*, g). Připojit se pouze (*, g) se snaží o RP a připojit se (S, G) na S - zdroj. Jak adresa příjemce je také adresa služby 224.0.0.13 a TTL = 1. Pokud existují mezilehlé uzly, například R42, také tvoří záznam (S, G) a seznam navazujících rozhraní pro tuto skupinu a dopředu připojit ke zdroji. Cesta, pro kterou se připojí z RP ke zdroji, se změní na - Strom ze zdroje. Ale běžnější jméno - - Koneckonců, provoz ze zdroje k RP půjde podél nejkratší cesty.

devět) R1 Po obdržení spojení (S, G) přidává rozhraní FE1 / 0, ze kterého balíček přišel do seznamu advokátových rozhraní downstream a začne vysílat čistý vícesměrový provoz, nezapisující se zapouzdření. Nahrávání (S, G) na R1 již byl, jakmile dostane první multifunkční balíček ze zdrojového serveru. Podle vybudovaného zdrojového stromu je multicast přenášen RP (a všechny mezilehlé klienty, pokud jsou například R42). .

Je však nutné mít na paměti, že registrační zprávy byly po celou dobu přenášeny a prošly až do provozu. To znamená, že R1 pošle dvě kopie provozu nyní: Jeden je čistý multicast SPT, druhý je zapouzdřen v jednokalu. Za prvé, R1 odešle vícesměrový počítač k registraci - Balení 231.

. Pak R2 (RP) se chce připojit ke stromu, odesílá spojení -

Balení 232.

. R1 je stále nějaký čas, zatímco dotaz je zpracován R2, odešle vícesměrový počítač k registraci ( Balíčky od 233 do 238 ). Dále, když bylo do ropy přidáno do oleje, začne přenášet čistý multicast -

Balíčky 239 a 242 , ale ještě nezastavení a registrace - Balíčky 241 a 243 . ALE и Balení 240. - Tento R2 nemohl stát a opět požádat, aby postavil strom. Schéma a počáteční konfigurace. 10) Takže nezaniklý multicast dosáhne RP. Chápe, že se jedná o stejný provoz, který je v rejstříku, protože stejná adresa skupiny je stejná zdrojová adresa az jednoho rozhraní. Aby nedostal dva kopie, odešle na R1 jedinečné PIM REGISTRACE-STOP

REGISTRACE-STOP neznamená, že R2 odmítne provoz nebo neuznává více tohoto zdroje, pouze říká, že je nutné přestat odeslat

zapouzdřený provoz. Dále, divoký boj - R1 pokračuje v přenosu provozu akumulovaného v vyrovnávací paměti, zatímco procesy registru-stop, a obvyklé vícesměrové vysílání a uvnitř zpráv registrů:

Ale dříve nebo později, R1 začne vysílat pouze čistý vícesměrový provoz.

Při přípravě jsem měl legitimal otázku: No, proč všechny tyto tunelování, registr PIM? Proč ne dělat s vícesměrovým provozem, stejně jako s pim připojit - poslat hop za hop s ttl = 1 směrem k rp - dříve nebo později to přijde? Tak to by také stavěl strom ve stejnou dobu bez zbytečných gest.

Zde je několik nuancí.

Za prvé, hlavní princip SM SM PIM je porušen - provoz poslano pouze tam, odkud bylo požadováno.

Žádné spojení - žádný strom

Dokázal se! Zadruhé, pokud nejsou pro tuto skupinu žádné zákazníky, FHR toto nerozpozná a bude i nadále posílat provoz na "vlastním stromu". Co je bezduchý používání šířky pásma? Ve světě komunikace by takový protokol prostě nepřežil, stejně jako nepřežil PIM DM nebo DVMRP. Takže máme jeden velký MDT strom pro skupinu 224.2.2.4

Nyní dáváme serveru. Jak jsme již diskutovali výše, nemusí se starat o PIM, RP, IGMP - jen vysílá. A R1 dostane tento proud. Jeho úkolem je dodat multicast k RP. Zdrojové servery Registrovat před Zákazník 1.

Zákazník 2.

. A tento MDT se skládá ze dvou kusů, které byly postaveny nezávisle na sobě:

ze zdroje k RP a Rpt. od RP zákazníkům. Zde je to rozdíl mezi MDT z RPT a SPT. MDT je ​​spíše společný termín, který znamená vícecestující přenosový strom obecně, zatímco RPT / SPT je jeho velmi specifický vzhled.

A co když je server již vysílán, a neexistuje žádný zákazník a ne? Multicast, takže bude ucpat místo mezi odesílatelem a RP?

Ne, v tomto případě, PIM Register-Stop bude také pomoci. Pokud zpráva registru zahájila na RP pro některou skupinu, a tam nejsou žádní příjemci pro IT, RP nemá zájem o získání tohoto provozu,

Nezasílat

PIM JOIN (S, G) RP okamžitě odešle registru-zastávku na R1.

R1, po obdržení registru-stopu a vidět, že pro tuto skupinu neexistuje žádný strom (žádné zákazníky), začne vyřazovat vícesměrový provoz ze serveru.

To znamená, že server sám o tom není o tom strach a nadále posílá tok, ale po dosažení routerového rozhraní, tok bude vyřazen.

V tomto případě RP nadále ukládá vstup (S, G). To znamená, že provoz nedostane, ale kde je zdroj umístěn pro skupinu, ví. Pokud se jedná o příjemci ve skupině, RP se o nich učí a odešle do zdrojového spojení (S, G), které vytváří strom.

Kromě toho se každých 3 minuty R1 pokusí znovu zaregistrovat zdroj na RP, tj. Odeslat registrovat pakety. Je nutné, aby oznámil RP, že tento zdroj je stále naživu.

Ve zvláště zvídavých čtenářech, otázka musí nastat - co rpf? Koneckonců, tento mechanismus kontroluje adresu odesílatele balíčku vícesměrového vysílání a pokud provoz pochází ze správného rozhraní, bude vyřazen. Současně mohou být RP a zdroj v různých rozhraních. Takže v našem příkladu pro R3 RP - pro FE11 / 1 a zdroj pro FE1 / 0. . ALE Odpověď je předvídatelná - v tomto případě je kontrolována zdrojová adresa, ale RP. To znamená, že provoz musí pocházet z rozhraní směrem k RP. Ale jak vidíte dál, to také není nereálné pravidlo. .

Je důležité pochopit, že RP není univerzální magnet - pro každou skupinu může být jeho RP. To znamená, že v síti mohou být dva z nich, a tři a sto - jeden RP je zodpovědný za jednu sadu skupin, druhý je po druhém. Kromě toho je taková věc jako Anycast RP. A pak může sloužit stejné RP ve stejné skupině. Úkol číslo 2. и - Je to R4 Poznámka k topologii : V tomto problému jsou pouze R1, R2 směrovače správcům naší sítě. To znamená, že konfigurace může být změněna pouze na nich. Server 172.16.0.5 přenáší vícesměrový provoz do skupin 239.1.1.1 a 239.2.2.2.

Nakonfigurujte síť tak, aby provoz skupiny 239.1.1.1 není přenášen na segment mezi R3 a R5 a ve všech segmentech pod R5.

Ale zároveň by měla být provozová skupina 239.2.2.2 předána bez problémů.

Podrobnosti o úkolu zde.

=====================================

Razor OKKAMA nebo Zakázání zbytečných větví

Poté, co poslední klient v segmentu odmítl přihlásit, musí PIM odříznout přebytečnou pobočku RPT.

Nechte například jediný klient na R4 vypnut počítač. IGMP opustí router nebo po třech nezodpovězených dotazu IGMP chápe, že neexistuje žádné další zákazníky pro FE0 / 0 a odešle zprávu RP

Pim prořezán . Podle formátu je to přesně stejné jako spojení, ale provádí opačnou funkci. Cílová adresa je také 224.0.0.13 a TTL je 1.

Ale router, který přijal pim švestek před odstraněním předplatného, ​​čekal nějaký čas (obvykle 3 sekundy - připojit zpoždění časovače).

To se provádí pro takovou situaci:

V jednom routeru vysílání domény 3. Jeden z nich je vyšší a je to on, kdo přenáší vícesměrový provoz na segment. To je R1. Pro oba směrovače (R2 a R3) obsahuje jeho olej pouze jeden záznam.

Pokud se R2 rozhodne odpojit a poslat PIM prořezat, může nahradit jeho kolega R3 - R1, když se všichni zastaví vysílání do rozhraní vůbec.

Takže to se nestane, R1 a dává časový limit za 3 sekundy. Během této doby musí mít R3 čas reagovat. Vzhledem k vysílací síti bude také dostávat prořezávku od R2, a proto, pokud chce i nadále přijímat provoz, okamžitě odešle obvyklý PIM se připojit k segmentu, oznamující R1, že není nutné vymazat rozhraní.

Tento proces se nazývá přepsání pro prořezávání. R2, jak to bylo, Echriting R1, zachytil iniciativu.

SPT přepínač - přepínání RPT-SPT

Doposud jsme se většinou zvážili

. Teď se obrátme Zákazník 2. Nejdřív je pro něj identický Zákazník 1. - Používá RPT od RP, který jsme považovali dříve. Mimochodem, protože oba - i

Klient 1. .

- Použijte jeden strom, takový strom se nazývá

Sdílený strom

- To je poměrně běžný název. Sdílený strom = RPT.

  • To je způsob, jak se multicast směrovací stůl na R5 vypadá jako na samém počátku, ihned po výstavbě stromu: Neexistuje žádný záznam (s, g), ale to neznamená, že provoz vícesměrového vysílání není přenášen. Jen R5 se nestará o to, kdo odesílatel. Upozorňujeme, jak by měl provoz jít v tomto případě - R1-R2-R3-R5. Ačkoli stručně, cesta R1-R3-R5.
  • A pokud je síť složitější? Nějaký Nečuratnyko. Upozorňujeme, jak by měl provoz jít v tomto případě - R1-R2-R3-R5. Ačkoli stručně, cesta R1-R3-R5.
  • Skutečnost je, že když jsme vázáni na RP - je to rpt kořen, jen ona nejprve věděla, kde je. Pokud však přemýšlíte o prvním balíčku multicast, všechny směrovače podél dopravní cesty budou znát zdrojovou adresu, protože je uvedena v záhlaví IP. Proč nikdo neposílá připojit ke zdroji a optimalizovat trasu? )

Místo v kořenu. Takové spínání může iniciovat

LHR (poslední chmelový router)

- R5. Po obdržení prvního paketu vícesměrového vysílání z R3 R5 odešle zdrojové spojení (S, G) pro nás do rozhraní FE0 / 1, které je specifikováno ve směrovací tabulce, jako odchozí pro síť 172.16.0.0/24.

Po obdržení takového spojení, R3 to neříká, že není RP, protože to udělal s obvyklým připojením (*, g), ale směrem ke zdroji (přes rozhraní podle směrovací tabulky). To je v tomto případě R3 odesílá spojení (172.16.0.5, 224.2.2.2.4) do rozhraní FE1 / 0. .

Dále toto spojení spadá na R1. A R1 a velký bez rozdílu, který ji poslal - RP nebo někoho jiného - jednoduše přidává FE1 / 1 na svůj olej pro skupinu 224.2.2.4. V tomto bodě, mezi zdrojem a příjemcem, dvěma způsoby a R3 dostávají dva proudy. Čas, aby se rozhodl nařídit zbytečné. A to je R3, že to dělá, protože R5 již nemůže být schopen rozlišovat mezi těmito dvěma proudy - oba procházejí jedním rozhraním.

Jakmile R3 nahráli dvě identické toky z různých rozhraní, rozhoduje se výhodné podle směrovací tabulky. V tomto případě přímé, lepší než přes RP. V tomto okamžiku R3 posílá prořezávku (S, G) na stranu RP, vypalování této RPT. A z tohoto okamžiku je přímo jeden proud přímo ze zdroje.

PIM postavil SPT - nejkratší cestou stromu. Je to zdrojový strom. Toto je nejkratší cesta od klienta ke zdroji. Mimochodem, strom ze zdroje k RP, který jsme již považovali za vyšší, jsou v podstatě stejný SPT.

Vyznačuje se nahráváním (S, G). Pokud má router takový záznam, pak ví, že S je zdrojem skupiny G a postavený strom SPT.

Kořen stromu SPT je zdrojem a opravdu chcete říci "Nejkratší cestu

Zdroj zákazníka " Ale je to technicky nesprávné, protože cesty ze zdroje klienta a od klienta ke zdroji lze jiné. Jmenovitě od klienta začne vytvářet větev stromu: směrovač odešle pim připojit ke zdroji / rp a rpf také kontroluje správnost rozhraní, když Účtenka

provoz.

Pamatujete si, že na začátku tohoto odstavce na R5 byl pouze záznam (*, g), nyní po všech těchto událostech budou dva: (*, g) a (s, g) Mimochodem, i když se podíváte na multicast směrovací tabulku R3 na stejnou sekundu, jak přehrávání přehrávání ve VLC, uvidíte, že již získáte provoz od R1 přímo, co je přítomnost záznamu (S, G) říká. . To znamená, že SPT přepnutí se již stalo - to je výchozí akce na vybavení mnoha výrobců - pro zahájení přepínání po obdržení prvního balíčku vícesměrového vysílání. Obecně řečeno, takový přepínač může nastat v několika případech: . Podle formátu je to přesně stejné jako spojení, ale provádí opačnou funkci. .

Nenechte se vůbec (tým

IP PIM SPT-prahová hodnota Infinity

).

Po určité využití šířky pásma (tým

IP PIM SPT-prahová hodnota X Jistě - ihned po obdržení prvního balíčku (výchozí nebo Žádný IP PIM SPT-práh X

Rozhodnutí, které "čas" vezme LHR.

V tomto případě se podruhé změní provoz RPF - kontroluje opětovné místo zdroje. To znamená, že ze dvou proudů vícesměrového vysílání - od RP az zdroje - preference dává provoz ze zdroje.

Dr, assert, forwarder

Někteří důležitější body při zvažování PIM.

DR - určený router

Jedná se o vyhrazený směrovač, který je zodpovědný za zasílání nástrojů na RP.

Zdroj Dr. Dr.

- zodpovědný za přijetí paketů vícesměrového vysílání přímo ze zdroje a zaregistrujte jej na RP. Zde je příklad topologie: .

Neexistuje nic, co by mělo něco udělat, že oba směrovače projíždí provoz na RP, nechte je rezervovat, ale odpovědný musí být pouze jeden. Vzhledem k tomu, že oba směrovače jsou připojeny k jedné vysílací síti, dostanou pim-hello od sebe navzájem. Na základě toho dělají svou volbu. PIM Dobrý den, nese hodnotu priority tohoto routeru na tomto rozhraní.

Čím větší je hodnota, tím vyšší je priorita. Pokud jsou stejné, uzel je vybrán Nejvyšší adresa IP (Také z zprávy HELLO). Pokud jiný směrovač (ne Dr) během Holdtime (výchozí 105 s) neobdrží Hello od souseda, automaticky přebírá roli DR. V podstatě zdroj dr

FHR - první hopový router

Přijímač Dr. - stejný jako zdroj DR, pouze pro vícesměrové dopravní příjemce - R2 (CONFIG) #Interface Loopback 0 RX (CONFIG-IF) #IP PIM SPARLSE-MODE .

Příklad topologie: Přijímač DR je zodpovědný za zaslání RP PIM spojení. Ve výše uvedené topologii, pokud budou obě směrovače posílat, oba obdrží vícesměrový provoz, ale není třeba. Připojuje se pouze DR. Druhá jednoduše monitoruje dostupnost dr. :

Protože DR odesílá spojení, bude také vysílat provoz v LAN. Ale pak vzniká přirozená otázka - a co když se Pim Dr'om stal jedním, a IGMP Querier jinde? A situace je docela možné, protože pro Querier, méně IP, tím lépe a pro DR, naopak. - Je to R4 V tomto případě je DR vybrán tím, že router, který je již dotazem a tento problém nenastane.

Pravidla selekce přijímače jsou přesně stejné jako zdroj dr.

Assert a Pim Forwarder

Problém dvou současně vysílacích směrovačů může dojít ve středu sítě, kde nejsou žádné konečné zákazníky nebo zdroje - pouze směrovače. Velmi akutní tuto otázku stála v PIM DM, kde to byla zcela obyčejná situace kvůli mechanismu povodní a prořízené. Ale v PIM SM, není vyloučeno.

Zvažte takovou síť: Z výstupu je zřejmé, že provoz pro skupinu 224.2.2.4 přichází přes FE0 / 1 a je nutné jej přenášet do portu FE0 / 0. Zde jsou tři směrovače ve stejném segmentu sítě, a proto jsou sousedé PIM. R1 funguje jako RP.

R4 posílá pim připojit k RP. Vzhledem k tomu, že tento multicast balíček spadne na R2 a na R3 a oba zpracovávají jej, přidejte do ropy downstream rozhraní.

Zde bylo nutné pracovat s výběrovým mechanismem Dr.

Když multicast provoz pochází ze zdroje na R2 a R3, je přenášen na oba směrovače v segmentu a rebel tam. PIM se nepokouší zabránit takové situaci - Zde působí na skutečnost napadeného trestného činu - jakmile směrovač obdrží multicast provoz této skupiny v jeho navazujícím rozhraní (z seznamu ropy), chápe: Něco je špatné - Jiný odesílatel již má v tomto segmentu. Poté router odešle zvláštní zprávu. Pim prosazovat.

Taková zpráva pomáhá vybrat si 

Pim forwarder.

- router, který má právo vysílat v tomto segmentu. Nenechte se zaměnit s pim dr. Za prvé, Pim Dr je zodpovědný za zaslání Pim připojit a prořezávat a pim forwarder - pro odeslání Provoz

. Druhý rozdíl - PIM DR je vždy vybrán v jakýchkoli sítích při zřizování sousedství a PIM Forwrder je pouze v případě potřeby pouze - když je dosaženo vícesměrového vysílání z rozhraní z rozhraní z listu ropy.

Vyberte RP. 

Nad my pro jednoduchost zeptal RP ručně IP PIM RP-adresa A tady je to, jak vypadal tým

Zobrazit IP PIM RP

Představujeme však zcela nemožnou situaci v moderních sítích - R2 selhalo. To je vše - dokončit. Bude stále fungovat, protože spotoven SPT došlo, ale všechno je nové a vše, co prošlo RP, se zlomí, i když existuje alternativní způsob. No, zatížení správce domény. Představte si: Zabít 50 směrovačů ručně alespoň jeden příkaz (a pro různé skupiny, může to být jiné RPS). Dynamický výběr RP umožňuje a vyhnout se rehy a zajistit spolehlivost - pokud se jeden RP stane nedostupným, další bude trvat okamžitě do bitvy. V současné době existuje obecně přijímaný protokol, který to umožňuje udělat - Bootstrap . Tsiska v dřívějších časech podporoval několik nemotorných auto-rp

Ale teď to není téměř nepoužívá, i když TSiska to nepozná, a Máme nepříjemnou rudiment ve formě skupiny 224.0.1.40. Je nutné skutečně zaplatit protokol Auto-RP. Byl spasení v dřívějších časech. Ale s příchodem otevřeného a flexibilního bootstrapu přirozeně položil svou pozici.

Předpokládejme, že v naší síti chceme R3 vyzvednout funkce RP v případě selhání R2.

R2 a R3 jsou definovány jako kandidáty na roli RP - takže se nazývají

C-RP.

. Na těchto směrovačích konfigurujte:

RX (CONFIG) rozhraní Loopback 0 RX (CONFIG-IF) IP PIM SPARSE-MODE RX (CONFIG-IF) EXIT RX (CONFIG) #IP PIM RP-CANDIDIDE LOOPBOCK 0

  1. Ale stále se nic nestane - kandidáti ještě nevědí, jak informovat každého o sobě.
  2. Informovat všechny směrovače domény vícesměrového vysílání o existujícím mechanismu RP
  3. BSR - bootstrap router
  4. . Může existovat několik žadatelů, jako je C-RP. Jsou volány
  5. C-BSR.
  6. . Jsou konfigurovány podobným způsobem.

Nechte BSR s ​​jedním a pro test (výlučně) bude R1. Ale po chvíli ve stejné pobočce se router znovu snaží poslat vícesměrový počítač - náhle se tam objevili příjemci. Pokud se neobjevil, větev je opět odříznuta v určitém období. Pokud se klient na směrovači objevil v intervalu mezi těmito dvěma událostmi, zpráva štěpu je odeslána - router požaduje odbočku zpět tak, aby nečekal, až něco zapadne. R1 (CONFIG) Loopback 0 R1 (CONFIG-IF) IP PIM SPARSE-MODE R1 (CONFIG-IF) Konec R1 (Config) #ip PIM BSR-Candide Loopback 0 Nezávislý Je proto, že není vázán na konkrétní program směrování jedinečného provozu a později uvidíte proč. Za prvé, jeden hlavní BSR je vybrán ze všech C-BSR, který bude účtován všem. Chcete-li to provést, každý C-BSR odešle multicast volala Zpráva Bootstrap (BSM) Schéma a počáteční konfigurace. Adresa 224.0.0.13 je také balíček protokolu PIM. Musí být přijat a zpracovávat všechny směrovače vícesměrového vysílání a po odeslání do všech portů, kde je PIM aktivován. BSM je přenášen na stranu něčeho (RP nebo zdroj), na rozdíl od připojení pim a ve všech směrech. Taková fanoušková pošta pomáhá dosáhnout BSM všech rohů sítě, včetně všech C-BSR a všech C-RP. Aby se BSM putoval po síti nekonečně, použije se stejný mechanismus RPF - pokud BSM pocházel z nesprávného rozhraní, za kterou je síť odesílatele této zprávy vydána, je tato zpráva vyřazena. To znamená, že každý router na cestě by měl zvládnout takové spojení a v případě potřeby zaslat nový se spojení na stranu RP. (Je důležité pochopit, že pokud již existuje tato skupina na routeru, nebude posílat spojení - jednoduše přidá rozhraní, ze kterého se připojuje k oleji a začne projíždět provoz). S těmito BSM, všechny směrovače multicast určují nejpoužívanější kandidát na základě priorit. Jakmile C-BSR obdrží BSM z jiného routeru s velkou prioritou, přestane odesílat své zprávy. V důsledku toho každý má stejné informace. Odpusťte Cisco tuto zvláštnost? Spolu se všemi ostatními? . : V tomto problému jsou pouze R1, R2 směrovače správcům naší sítě. To znamená, že konfigurace může být změněna pouze na nich. V této fázi, kdy je vybrán BSR, vzhledem k tomu, že jeho BSM se odráží v celé síti, C-RP zná svou adresu a jedinečnost posílat zprávy

Candidte-RP-reklama ve kterém nesou seznam skupin, které slouží - to se nazývá Skupinové mapování . BSR Všechny tyto zprávy agregáty a vytvářejí RP-SET. - Informační tabulka: Jaká skupina RP je každá skupina obsluhována. Dále, BSR v bývalém ventilátoru odesílá stejnou zprávu Bootstrap, která tato doba obsahuje SET RP. Tyto zprávy úspěšně dosahují všech vícesměrných směrovačů, z nichž každá Sám Dělá výběr, který RP musí být použit pro každou konkrétní skupinu. BSR periodicky činí takovou distribuci tak, aby na jedné straně všichni věděli, že informace o RP jsou stále relevantní a na druhém C-BSR, si byli vědomi toho, že hlavní BSR sám je stále naživu. RP, mimochodem, také pravidelně posílat oznámení o kandidátské RP-reklamní reklamy na BSR. Také chtějí přijímat vícesměrový provoz pro stejnou skupinu, R5 bude posílat PIM připojit k Fe0 / 1, protože je RP, R3, který byl přijat, tvoří nový pim připojit a odešle jej do FE1 / 1 - kde se nachází RP. Ve skutečnosti vše, co potřebujete udělat pro konfiguraci automatického výběru RP - zadejte C-RP a určete C-RP - ne tolik práce, všechno ostatní učiní PIM pro vás. Jako vždy, aby se zvýšila spolehlivost, doporučuje se specifikovat rozhraní loopback jako kandidáty. Dokončení kapitoly PIM SM, pojďme si všimnout nejdůležitějších momentů Velmi akutní tuto otázku stála v PIM DM, kde to byla zcela obyčejná situace kvůli mechanismu povodní a prořízené. Obyčejné jedinečné spojení musí být vybaveno IGP nebo statickými trasami. To je základem algoritmu RPF. Strom je založen pouze po zobrazení klienta. Je to klient, který iniciuje výstavbu stromu. Žádný klient - žádný strom. RPF pomáhá vyhnout se smyček. Všechny směrovače by si měly být vědomy, kdo je RP pouze s pomocí, které můžete vybudovat strom. Bod RP může být staticky indikováno a lze jej vybrat automaticky pomocí protokolu Bootstrap. RPT je postaven v první fázi - strom od zákazníků na RP - a zdrojový strom - strom ze zdroje k RP. Ve druhé fázi je přepínání z postavené RPT na SPT nejkratší cestu od příjemce ke zdroji. Seznam i všechny typy stromů a zpráv, které jsme nyní známí. . Společný termín popisující jakýkoli přenos vícesměrového vysílání.

. Strom s nejkratší cestou od klienta nebo RP ke zdroji. V PIM DM je jen SPT. V PIM SM SM SPT může být ze zdroje na RP nebo ze zdroje do příjemce po spínači SPT došlo. Naznačeno záznamem

- Známý zdroj pro skupinu.

- Stejně jako SPT.

. Strom od RP příjemci. Používá se pouze v PIM SM. Naznačeno záznamem

- stejně jako rpt. Říká se, takže všichni zákazníci jsou připojeni k jednomu společnému stromu s kořenem v RP.

Zprávy režimu sparse PIM:

Ahoj.

- Zřídit sousedství a udržení těchto vztahů. Také nutné vybrat DR. Připojit (*, g) - Žádost o připojení ke skupině G. Bez ohledu na to, kdo zdroj. Odjíždí směrem k RP. S jejich pomocí je postaven strom RPT. Připojit (s, g) - Zvedněte konkrétní spojení. Jedná se o žádost o připojení ke skupině G se specifickým zdrojem - S. Odeslaný směrem ke zdroji - S. S jejich pomocí, strom SPT je postaven.

Prořezejte (*, G)

- Žádost o odpojení od stromu g, bez ohledu na zdroje pro to. Odjíždí směrem k RP. Takže břevo RPT je pokryta.

  • Švestka (s, g)
  • - Žádost o vypnutí ze stromu G stromu, jehož root je S. S. System odeslán směrem ke zdroji. Takže větev SPT je řezána.
  • - Zvláštní zpráva, ve které je multicast přenášen na RP, dokud není SPT zabudován ze zdroje k RP. Přenášen Unicastem z FHR na RP.

Registrace.

- Poslane se UniCust s RP na FHR, objednání zastavit odesílání multicast provozu, zapouzdřené v registru.

- Mechanismové pakety BSR, které umožňují vybrat router role BSR, a také přenášet informace o existujícím RP a skupinách.

Prosazovat.

- Zpráva vyberte PIM Forwarder tak, aby dva směrovače prošly do jednoho segmentu.

Kandidát-RP-reklama

- Zpráva, ve které RP odešle informace o tom, které skupiny slouží. 

RP-Reachable.

- Zpráva od RP, kterou oznámí všem o jeho dostupnosti.

  • * V PIM jsou jiné typy zpráv, ale tyto jsou již podrobnosti *
  • A zkusíme abstrakt z podrobností protokolu? A pak se jeho složitost zřejmá.
  • 1) Definice RP, 2) Registrace zdroje na RP, 3) Přepínání stromu SPT.

Mnoho stavů protokolu, mnoho záznamů v multicast směrovací tabulce. Je možné něco udělat? Dosud existují dva diametrálně opačné přístupy ke zjednodušení PIM: SSM a Bidir PIM. SSM.

Vše, co jsme popsali, je

ASM - libovolný zdrojový multicast

. Zákazníci jsou lhostejní, kteří jsou zdrojem dopravy pro skupinu - hlavní věc je, že ji dostanou. Jak si pamatujete, zpráva IGMPv2 je požadována jednoduše připojit se ke skupině.

SSM - Zdrojový specifický multicast - alternativní přístup. V tomto případě klienti označují skupinu a zdroj při připojení. Co to dá? Už ne: Schopnost zcela zbavit RP. LHR okamžitě zná zdrojovou adresu - není třeba zasílat spojení na RP, router může okamžitě poslat spojení (S, G) ve směru zdroje a sestavit SPT.

Tak se zbavíme

Hledání RP (Bootstrap a Auto-RP protokoly),

Registrace zdroje na multicast (a to je příliš mnoho času, dvojího využití šířky pásma a tunelování) Přepnutí na SPT. Vzhledem k tomu, že neexistuje žádná RP, pak žádná RPT, na jednom směrovači nebude žádné záznamy (*, g) - pouze (s, g).

Dalším problémem, který je vyřešen s SSM, je přítomnost několika zdrojů. V ASM se doporučuje, aby byla adresa skupiny multicastu jedinečnou a pouze jeden zdroj vysílání, protože ve stromu RPT je několik proudů poněkud a klient, získání dvou proudů z různých zdrojů, pravděpodobně nebudou schopen rozebrat jim. V SSM je provoz z různých zdrojů distribuován nezávisle, z nichž každý v jeho SPT stromu, a to se již stává problémem a výhoda - několik serverů může být vysílán současně. Pokud se náhle klient začal opravit ztráty z hlavního zdroje, může přepnout na zálohu, ani ho přestavět - on také dostal dva proudy. Kromě toho, možné vektor útoků na síti s aktivovaným směrováním vícesměrového vysílání je připojit vetřelec svého zdroje a generování velkého množství provozu vícesměrového vysílání, který přetíží sítě. V SSM je to prakticky vyloučeno.

Pro SSM se zvýrazní speciální sortiment IP adres: 232.0.0.0/8. Na směrovačích na podporu SSM je povolen režim PIM SSM. Router (CONFIG) # IP PIM SSM

IGMPv3 a MLDV2 podporují SSM v čisté formě.

Při použití je klient

Vyžádejte si připojení k pouze skupině bez zadání zdrojů. To znamená, že to funguje jako typický ASM.

Vyžádejte si připojení ke skupině se specifickým zdrojem. Zdroje mohou být specifikovány několik - strom bude postaven před každým z nich. Vyžádejte si skupinové připojení a zadejte seznam zdrojů, ze kterých klient nechtěl by dostal provoz

IGMPV1 / V2, MLDv1 Nepodporujte SSM, ale je tu taková věc jako Vyžádejte si připojení ke skupině se specifickým zdrojem. Zdroje mohou být specifikovány několik - strom bude postaven před každým z nich. Mapování SSM. . Na vedle klienta je router (LHR) každá skupina vložena v souladu se zdrojovou adresou (nebo několika). Proto, pokud existují klienti, kteří nepodporují IGMPv3 / MLDv2, bude pro ně také vybudován SPT, a ne RPT, vzhledem k tomu, že zdrojová adresa je stále známa. Mapování SSM lze implementovat jak statické nastavení na LHR a odkazem na server DNS. Problém SSM je, že zákazníci musí poznat zdrojové adresy předem - nejsou jim sděleny. Proto je SSM dobrý v těchto situacích, kdy má síť určitou sadu zdrojů, jejich adresy jsou známy, že znají a nebudou měnit. A klientské terminály nebo aplikace jsou vázány na ně. Jinými slovy, IPTV je velmi vhodným prostředím pro implementaci SSM. Popisuje koncept dobře Jednorázový

- Jeden zdroj, mnoho příjemců.

Bidir PIM.

A co když v síťových zdrojích se tam mohou objevit spontánně, pak vysílat na stejných skupinách, rychle zastavit přenos a zmizet?

Tato situace je například možná v síťových hrách nebo datovém centru, kde jsou data replikována mezi různými servery. To je koncept Mnohokrát - Mnoho zdrojů, mnoho zákazníků.

Jak se na to dívá obvyklý PIM SM?

Je jasné, že inertní PIM SSM není vůbec vhodný?

Jen si myslíte, co chaos začne: nekonečná registrace zdrojů, přestavby stromů, obrovský počet záznamů (s, g) žijících na několik minut kvůli časovačům protokolu.

  • Bidirectional PIM je příjmy ( Obousměrný PIM, Bidir PIM
  • ). Na rozdíl od SSM je zcela zcela odmítnut pomocí SPT a záznamy (S, G) - pouze sdílený strom zůstává s kořenem v RP. A pokud je v obvyklém PIM, strom je jednostranný - provoz je vždy přenášen ze zdroje dolů SPT a od RP dolů RPT - existuje jasná divize, kde je zdroj, ve kterém zákazníci, pak v obousměrném od zdrojového provozu RP, také prochází sdílený strom - stejným způsobem, podle kterého provoz teče pro zákazníky.
  • To vám umožní odmítnout zaregistrovat zdroj na RP - dopravní transfery určitě bez jakýchkoliv alarmů a stavu stavu. Vzhledem k tomu, že stromy SPT nejsou vůbec, pak se SPT přepne také. Například: Vyžádejte si připojení ke skupině se specifickým zdrojem. Zdroje mohou být specifikovány několik - strom bude postaven před každým z nich. Zdroj1.
  • začal převést provozní skupinu 224.2.2.4 do sítě současně s Source2. . Proky z nich právě nalil směrem k RP. Někteří zákazníci, kteří jsou v blízkosti, začali přijímat provoz najednou, protože na směrovačích je vstup (*, g) (existují zákazníci). Další část dostává provoz na sdíleném stromu od RP. A dostávají provoz od obou zdrojů současně. To znamená, že pokud jste pro příklad spekulativní sítě, . Na vedle klienta je router (LHR) každá skupina vložena v souladu se zdrojovou adresou (nebo několika). Proto, pokud existují klienti, kteří nepodporují IGMPv3 / MLDv2, bude pro ně také vybudován SPT, a ne RPT, vzhledem k tomu, že zdrojová adresa je stále známa. To je první střelec ve střelci, který udělal výstřel a

Source2.

- To je další hráč, který udělal krok na boku. Informace o těchto dvou událostech se šíří v celé síti. A

každý

Příklad: IPTV.

Jiného hráče (

.

Příjemce

) Musím se dozvědět o obou těchto událostech.

Pokud si pamatujete, pak těsně předtím, než jsme vysvětlili, proč je nutný proces registrace zdroje na RP - tak, že provoz nezabírá kanál, když neexistují žádné zákazníky, tj. RP ji právě odmítl. Proč teď nemyslíme na tento problém? Důvodem je jednoduchý: Bidir PIM pro situace, kdy existuje mnoho zdrojů, ale nejsou neustále vysílány, ale pravidelně, relativně malé údaje. To znamená, že kanál ze zdroje na RP nebude likvidován vodou.

Upozorňujeme, že na obrázku výše mezi R5 a R7 je přímka, mnohem kratší než cesta přes RP, ale nebyla použita, protože spojení směřuje směrem k RP podle směrovacího stolu, ve které tato cesta není optimální.

Vypadá to docela jednoduché - musíte posílat vícesměrové pakety ve směru RP a vše, ale je tu jeden nuance, že všechny kořisti - rpf. Ve stromu RPT vyžaduje, aby provoz pochází z RP a nikoliv jinak. A můžeme přijít odkudkoliv. Samozřejmě nemůžeme brát a opustit RPF - to je jediný mechanismus, který se vyhýbá tvorbě smyček.

Proto je koncept zaveden do Bidir PIM

DF - určený forwarder

. V každém segmentu sítě jeden směrovač, jehož trasa na RP je lepší je v každém řádku lépe vybrána na každém řádku.

Včetně toho se provádí na těchto linkách, kde jsou zákazníci přímo připojeni. Bidir PIM DF je automaticky dr.

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

Pravidla jsou poměrně transparentní:

Pokud se požadavek PIM připojit / opustit na toto rozhraní, které v tomto segmentu je DF, je předáván směrem k RP podle standardních pravidel.

Zde například R3. Pokud požadavky přišly na rozhraní DF, které jsou označeny červeným kruhem, přenáší je na RP (přes R1 nebo R2 v závislosti na směrovací tabulce).

Pokud požadavek PIM Joint / Leate přišel do rozhraní než DF, bude ignorován. Předpokládejme, že klient, který je mezi R1 a R3, rozhodl se připojit a odeslanou IGMP zprávu. R1 se dostane přes rozhraní, kde je vybrána možnost DF (označeno červeným kruhem) a vracíme se do předchozího scénáře. A R3 obdrží požadavek na rozhraní, které není DF. R3 vidí, že není to nejlepší, a ignoruje žádost. (Pokud se multicast provoz připadlo do rozhraní DF, bude odeslán na rozhraní z seznamu ropy a směrem k RP. Například,

Začal vysílat provoz. R4 se dostane do rozhraní DF a přenáší jej do jiného rozhraní DF - směrem k klientovi a směrem k RP, je důležité, protože provoz by se měl dostat na RP a rozšířit se přes všechny příjemce. R3 také vstupuje - jedna kopie na rozhraní z seznamu ropy - to znamená, že na R5, kde bude vyřazen z důvodu kontroly RPF a druhý je směrem RP.

Pokud se multicast provozoval do rozhraní než DF, musí být zasláno na rozhraní z seznamu ropy, ale

nebude

Do RP.

Například,

Začal vysílat, provoz dosáhl RP a začal se rozprostírat nahoru RPT. R3 dostane provoz od R1 a nebude to přenášet na R2 - pouze na R4 a R5.

DF zaručuje, že pouze jedna kopie balíčku vícesměrového vysílání a tvorba smyčka je vyloučena na RP, bude nakonec odeslána. Současně, společný strom, ve kterém se zdroj nachází, bude samozřejmě dostávat tento provoz před vstupem do RP. RP, podle běžných pravidel, doprava bude zaslán do všech ropných přístavů, navíc, odkud pochází provoz.

Mimochodem, není nutné pro tvrdé zprávy, protože DF je vybrán v každém segmentu. Na rozdíl od DR, on je nejen zodpovědný za zaslání spojení s RP, ale také pro přenos provozu do segmentu, to znamená, že situace, kdy jsou obě směrovače přenášeny na jednu pozici, vyloučeny v Bidir PIM.

Možná, že poslední věc, kterou potřebujete říci o obousměrném PIM, je funkce RP. Pokud PIM SM RP provedl konkrétní funkci - registrace zdroje, pak v Bidir PIM RP je jistým velmi podmíněným bodem, na který provoz se snaží usilovat o jednu stranu a připojit se od zákazníků na straně druhé. Nikdo by neměl provádět dekapataci, požádat výstavbu stromu SPT. Jen na nějakém směrovači náhle provoz od zdrojů začíná předávat sdílenému stromu. Proč říkám "na nějaký"? Faktem je, že v Bidir PIM RP - abstraktní bod, a ne specifický směrovač, protože adresa RP může provést neexistující IP adresu - hlavní věc je, že je to směrováno (takový RP se nazývá Phantom RP

Všechny podmínky týkající se PIM lze nalézt ve slovníci Multicast na kanálu Takže za dlouhým pracovním týdnem s nedostatkem spánku, zpracování, testů - úspěšně jste implementovali multicast a spokojené zákazníky, ředitele a prodejní oddělení. Pátek není nejhorší den s výhledem na stvoření a dovolit příjemný pobyt. .

Pátek není nejhorší den s výhledem na stvoření a dovolit příjemný pobyt.

Ale odpolední sen náhle narušil výzvu technické podpory, pak ještě jeden a přesto - nic nefunguje, všechno se zlomilo. Check - Go Ztráta, přestávky. Všechno se konverguje na jednom segmentu z několika přepínačů.

SSH uncredited, zkontroloval CPU, zkontroloval likvidaci rozhraní a konce vlasů - zatížení téměř do 100% na všech rozhraních jednoho VLAN. Smyčka! Ale kde to pochází, pokud nebyla držena žádná práce? 10 minut kontroly a jste si všimli, že na upstreamovém rozhraní k jádru máte spoustu příchozího provozu a na všechny sestupné zákazníkům - odchozí. Pro smyčku je také charakteristická, ale nějak podezřele: představil multicast, neudělal žádnou práci na spínání a skoku pouze v jednom směru.

Zaškrtnuto seznam multicast skupin na routeru - a tam je předplatné na všechny možné kanály a vše na jednom portu je samozřejmě ten, který vede k tomuto segmentu.

Pečlivé vyšetřování ukázalo, že počítač klienta je infikován a odešle dotaz IGMP na všechny adresy vícesměrového vysílání v řadě.

Ztráty balíčků začaly, protože přepínače musely projít sami obrovským množstvím provozu. To způsobilo přetečení vyrovnávacích pamětí rozhraní.

Hlavní otázkou je, proč se provoz jednoho klienta zkopíruje do všech přístavů?

Důvodem pro to je v povaze multicast MAC adres. Faktem je, že prostor multicast IP adres je speciálně zobrazen v prostoru multicast MAC adres. A SAG je, že nebudou nikdy používány jako zdrojová MAC adresa, a proto nebude studován přepínačem a jsou uvedeny v tabulce adres MAC. Co dělá přepínač s rámy, jehož cílová adresa není studována? Posílá je do všech přístavů. Co se stalo.

Toto je výchozí akce.

Multicast MAC adres. Jaké adresy MAC jsou tedy nahrazeny do záhlaví Ethernet těchto balíčků? Přenos? Ne. Existuje speciální sortiment adres MAC, ve kterých se zobrazují adresy Multicast IP. Registrovat Tyto speciální adresy začínají:

0x01005E a další 25. bit musí být 0

Snažte se odpovědět proč

). Zbývajících 23 bitů (připomenutí všeho v adresáři MAC 48) jsou přeneseny z adresy IP.

Zde leží některé ne velmi vážné, ale problém. Rozsah multicastových adres je určen maskou 224.0.0.0/4, což znamená, že prvních 4 bitů jsou rezervovány: 1110 a zbývajících 28 bitů se může změnit. To znamená, že máme 2 ^ 28 multicast IP adres a pouze 2 ^ 23 MAC adres - pro zobrazení 1 v 1 nedostatku 5 bitů. Proto jsou přijata jen poslední 23 bitů IP adres a jeden k jednomu se převede do adresy MAC, zbývající 5 jsou vyřazeny.

Ve skutečnosti to znamená, že 2 ^ 5 = 32 adres IP se zobrazí v jedné multicast MAC adresy. Například skupiny 224.0.0.1, 224.128.0.1, 225.0.0.1 a tak až do 239.128.0.1, každý bude zobrazen v jedné adrese MAC 0100: 5E00: 0001.

Pokud vezmete jako příklad streamování video výpis, můžete vidět:

Adresa IP - 224.2.2.4, MAC Adresa: 01: 00: 5E: 02: 02: 04.

Existují také další adresy MUTICAST MAC, které nepatří do IPv4-multicastu (klikněte

). Mimochodem, mimochodem, jsou charakterizovány skutečností, že poslední kousek prvního oktetu je roven 1.

Samozřejmě, že ani na stejné síťové kartě nelze konfigurovat takovou adresou MAC, takže nikdy nebude ve zdrojovém prostředí Mac Ethernet a nikdy nebude spadat do tabulky adres MAC. Takové rámce by proto měl být poslán jako žádný neznámý Unicast

Všem přístavům VLAN.

Celkem, že jsme zvažovali dříve, stačí, aby plně předal jakýkoli vícesměrový provoz od streamování videa na cenové cenové nabídky. Ale v našem téměř dokonalém světě opravdu děláme s takovou hanbou, jako vysílání vysílání toho, co by mohlo být převedeno na volit?

Vůbec ne. Zejména pro perfekcionisty Vynalezený mechanismus

Igmp-snooping.

Myšlenka je velmi jednoduchá - přepínač "poslouchá" procházející IGMP pakety.

Pro každou skupinu, samostatně vede tabulku vzestupných a klesajících portů.

Pokud IGMP zpráva pochází z portu pro skupinu, pak klient, přepínač jej přidá do seznamu downlink pro tuto skupinu.

Pokud IGMP dotaz přišel z portu pro skupinu, pak je router, přepínač jej přidá do vzestupného seznamu.

To vytváří tabulku multicast dopravního přenosu na úrovni kanálu. V důsledku toho, když se z výše uvedených multicast proud pochází, je zkopírován pouze do rozhraní směrem dolů. Pokud na 16-port přepíná pouze dva klienty, budou dodány provoz. Genius této myšlenky končí, když přemýšlíme o její povaze. Mechanismus předpokládá, že přepínač musí poslouchat provoz na 3. úrovni.

IGMP-Snooping však není srovnávání s NAT, aby ignoroval principy interakce sítě. Kromě toho, kromě spoření ve zdrojích, nese spoustu méně zřejmých příležitostí. Ano, a obecně, v moderním světě, přepínač, který ví, jak vypadat dovnitř IP - fenomén není výjimečný. ===================================== Číslo úlohy 3.

Server 172.16.0.5 vysílá vícesměrový provoz do skupin 239.1.1.1, 239.2.2.2 a 239.0.x.

Nakonfigurujte síť tak, aby:

- Zákazník 1 se nemohl připojit ke skupině 239.2.2.2. Ale zároveň se mohl připojit ke skupině 239.0.0.x.

- Zákazník 2 se nemohl připojit ke skupině 239.1.1.1. Ale zároveň se mohl připojit ke skupině 239.0.0.x.

Podrobnosti o úkolu zde.

=====================================

IGMP Snooping Proxy.

.

Reakce reakce může mít otázku o tom, jak IGMP Snooping se učí všechny klientské porty, vzhledem k tomu, že pouze jeden nejrychlejší klient je zodpovědný za dotaz IGMP, jak jsme uvedli výše. A velmi jednoduchý: IGMP Snooping neumožňuje zprávu jít mezi zákazníky. Jsou posílány pouze na rostoucí přístavy do směrovačů. Bez vidění zprávy od ostatních příjemců této skupiny je klient povinen reagovat na dotaz během doby odezvy maximální doby uvedené v tomto dotazu.

Výsledkem je, že v síti pro 1000 uzlů na jeden dotaz IGMP na sekundy 10 (obvyklá hodnota maximální doby odezvy) přijde 1000 zpráv routeru. I když by pro něj stačilo pro každou skupinu.

A to se stane každou minutu.

V tomto případě můžete konfigurovat proxetování požadavků IGMP. Pak přepínač nejen "poslouchá" projíždějící balíčky, zachytí je.

Pravidla provozu IGMP-Snooping se mohou lišit pro různé výrobce. Zvažte je proto koncepčně:

1) Pokud přepínač dorazí s velmi první zprávou skupiny, je zaslán do směrovače a rozhraní je shodněno downlink. Pokud je taková skupina již již tam, rozhraní je jednoduše přidáno do sestupného seznamu a zpráva je zničena.

2) Pokud nejnovější dovolená přichází na přepínač, neexistují žádné další zákazníky, tato dovolená bude odeslána do routeru a rozhraní je odebráno ze seznamu DownLink. V opačném případě je rozhraní jednoduše odstraněno, odničení je zničeno.

3) Je-li dotaz IGMP pochází z routeru, přepínač jej zachytí, odešle jej do odpovědi sestavy IGMP pro všechny skupiny, které mají v současné době příjemcům.

Nyní dáváme serveru. Jak jsme již diskutovali výše, nemusí se starat o PIM, RP, IGMP - jen vysílá. A R1 dostane tento proud. Jeho úkolem je dodat multicast k RP. A pak je v závislosti na nastaveních a výrobci, nebo stejný dotaz odeslán do všech klientských portrétů nebo přepínač blokuje dotaz z routeru a sám funguje jako Querier, periodicky politizující všechny příjemce. To snižuje podíl zbytečného servisního provozu v síti a zatížení routeru. Multicast VLAN replikace Klient bude také požadovat skupinu 224.2.2.4 prostřednictvím přehrávače VLC. Zkráceně Ve zprávě IGMPv2 jde na adresu požadované skupiny a paralelně je uvedena v samotném balení. Tyto zprávy musí žít pouze v rámci svého segmentu a negmentují se přesto směrovači, proto mají 1 TTL. Mvr.

. Jedná se o mechanismus pro ty poskytovatele, kteří praktikují VLAN-PER-Uder

např..

Zde je typický příklad sítě, kde MRR je vital:

5 zákazníků v různých VLAN a každý chce přijímat vícesměrový provoz jedné skupiny 224.2.2.4. V tomto případě musí zákazníci zůstat izolováni od sebe.

IGMP-Snooping bere v úvahu samozřejmě a VLANS. Pokud pěti zákazníků v různých VLAN vyžaduje jednu skupinu - bude to pět různých tabulek. V souladu s tím existuje 5 žádostí o připojení ke skupině routeru. A každá sabinterna z těchto pěti na routeru bude přidána odděleně v oleji. To znamená, že přijal 1 proud pro skupinu 224.2.2.4 On bude posílat 5 kopií, a to navzdory skutečnosti, že všichni jdou do jednoho segmentu.

Pro vyřešení tohoto problému byl vyvinut mechanismus replikace vícesměrového vysílání VLAN.

Je zadán další VLAN -

.

Multicast Vlan.

- V něm proto bude přenášen tok multicast. Je to "vkusný" přímo k poslednímu přepínači, kde je provoz z něj zkopírován do všech klientských rozhraní, které chtějí přijímat tento provoz - to je replikace.

.

V závislosti na realizaci replikace z multicast může být VLAN provedeno v

Uživatel-vlan.

nebo v určitých fyzických rozhraní.

A co zprávy IGMP? Dotaz z routeru, samozřejmě, prochází multicast VLAN. Přepínač je odešle do klientských portů. Když se zpráva nebo dovolená pochází od klienta, přepínač kontroluje od místa, kde je (VLAN, rozhraní) a v případě potřeby přesměrování na multicast VLAN.

Tak, obyčejný provoz je izolován a stále jde do routeru v uživateli VLAN. Multicast Provoz a IGMP pakety jsou přenášeny na multicast VLAN.

.

Cisco MVR a IGMP-Snooping jsou konfigurovány nezávisle. To znamená, že můžete vypnout jeden a druhý bude fungovat. Obecně platí, že MVR je založen na IGMP-Snooping a na přepínačích jiných výrobců pro operace MVR mohou být povinné začlenění IGMP-Snooping.

RPF kontrola.

Kromě toho, IGMP-Snooping umožňuje provádět provozní filtrování na přepínačích, omezit počet skupin dostupných uživateli, začlenění querier IGMP, statické nastavení vzestupných portrétů, trvalé připojení k libovolné skupině (tento skript je v doprovodu video

), Rychlá reakce na změnu topologie odesíláním dalšího dotazu, mapování SSM pro IGMPv2 atd.

  • Dokončení konverzace o IGMP-Snooping, chci opakovat - to je volitelná funkce - vše bude fungovat bez ní. Ale bude to sítě předvídatelnější a život inženýra je klidnější.
  • Všechny výhody IGMP Snooping však mohou být zabaleny proti sobě. Jeden takový vynikající případ lze číst odkazem.
  • Mimochodem, stejný Cisco má protokol CGMP

- analogie IGMP, který neporušuje principy spínače, ale je to správně a neřekne to rozšířené.

Takže, můj neúnavný čtenář se přiblížíme ke konci problému a nakonec chci ukázat, jak může být IPTV služba implementována na straně klienta.

Nejjednodušší způsob, jak jsme se v tomto článku opakovaně odvolali - spusťte hráče, který může mít multicast proud ze sítě. Adresa IP skupiny můžete ručně nastavit a vychutnat si video.

Další možností programu, kterou poskytovatelé často používají, je speciální aplikace, obvykle docela zvyk, ve které bude sada kanálů použitých v síti Poskytovatele šitá. Není třeba nastavit něco ručně - stačí přepnout kanály pomocí tlačítek.

Oba tyto způsoby umožňují sledovat streamování videa pouze v počítači.

Třetí volba umožňuje používat televizor a zpravidla. K tomu bude dům klienta klade tzv. Set-top-box (STB) - krabici nainstalovanou na televizoru. Jedná se o Pusaleak, který je zahrnut do účastnické linky a sdílí provoz: obvyklé Unicnter, který dává Ethernetovi nebo WiFi, aby zákazníci měli přístup k internetu a proud multicast je přenášen do televizoru přes kabel (DVI, RGB, anténa TD.).

Často, mimochodem, můžete vidět reklamu, kde poskytovatel nabízí své konzoly pro připojení televize - to je velmi stb

Úkol číslo 4.

Nakonec, netrivial vícesměrový úkol (autoři nejsou nás, bude existovat odkaz na originál v odpovědích).

  1. Nejjednodušší režim:
  2. Na jedné straně zdrojový server s obloukem - počítač, který je připraven k provozu.

Můžete nainstalovat multicast Stream adresu sami.

A tedy dvě otázky:

  • Co je třeba udělat tak, aby počítač mohl dostat proud a neuvažte se k multicast směrování?
  • Předpokládejme, že nevíte, co multicast a nemůže jej konfigurovat, jak převést proud ze serveru do počítače?
  • Úkol je snadno vyhledávaný v vyhledávači, ale zkuste to vyřešit sami.
  • Podrobnosti o úkolu zde.
  • =====================================
  • Nezisknutelné v článku zůstal cross-doména směrování multicast provozu (msdp
  • , MBGP.

, BGMP.

), vyvažování zatížení mezi RP (Anycast RP

, proprietární protokoly. Přemýšlím, ale mít bod zahájení tohoto článku, abych vypořádal se zbytkem, nebude obtížný.

Všechny výrazy týkající se vícesměrového vysílání, můžete najít v telekomunikacích Slovník Lookmeup

Pro pomoc při přípravě článků Děkuji JDIMA

Pro technickou podporu díky Natasha Samoilenko CDPV tažené Nina Dolgopolov

- nádherný umělec a jiný projekt.

RPF kontrola.

V bazénu článků SDSM je ještě mnoho zajímavých před koncem, takže nemusíte pohřbít cyklus kvůli dlouhému nedostatku propuštění - s každým novým článkem se významně zvyšuje složitost. Vpřed je téměř všechny MPLS, IPv6, QoS a Network Design.

  1. Jak jste již všimli, že LinkMeup má nový projekt - Lookmeup Slovník (Ano, opustili jsme fantazii). Doufáme, že tento glosář se stane nejúplnějším adresářem termínů v oblasti komunikace, takže budeme rádi pomoc při plnění. Napište nám na [email protected]
  2. Zůstaň s námi
  3. IGMP Snooping: Co je to v routeru a proč potřebujete?
  4. Pokud narazíte na otázku týkající se možnosti IGMP Snooping, která je v routeru a proč potřebujete toto nastavení, objevili jste správný článek. Většina informací na internetu je složitá pro pochopení obvyklého uživatele a tyto podmínky nejsou potřebné vůbec, pokud chcete vyřešit konkrétní úkol.
  5. O něco více o problémech, protože o kterém byste se mohli zajímat o IGMP Snooping:

Hrajete síťové hry;

Použijte funkci IPTV Rostelecom Internet Television nebo jiný poskytovatel;

Přihlášen na jakémkoli síťovém systému: videokonference, online učení nebo dokonce poštovní zásilky.

A zároveň jste významně snížili rychlost na všech zařízeních, která jsou připojena k routeru. Například, sledujete IPTV na televizoru, ale začnete "plachý" počítač nebo horší pracovat na internetu v telefonu. Dalším problémem je - IPTV, síťové hry nebo služby uvedené výše nejsou spuštěny vůbec a nefungují. Ve všech těchto případech bude řešení pomůže konfigurovat IGMP Snooping.

Co je to IGMP a proč je potřeba

Když jsou data přenášena přes síť - na globálním internetu, nebo od poskytovatele, nebo mezi svými zařízeními, to se děje na jasných pravidlech: protokoly. Každý protokol určuje, jak rozpoznat nuly a jednotky, jak je sbírat v datových paketech, jak zkontrolovat jejich "správnost" při přijímání a montáži na obrazovce na obrazovce. Existuje celkem sedm úrovní - od elektrických signálů do vašeho prohlížeče.

Protokol pro správu internetových skupin podle prvních písmen, z nichž zkratka je vytvořena - jedna z těchto protokolů na úrovni kanálu. Nevěděli byste o své existenci, pokud "Problémy" popsané výše vznikly. Jak je vidět z názvu, jedná se o protokol pro správu skupin vysílání.

To znamená, že když k vám v routeru od poskytovatele přijde signál IPTV Internet TV Signál, začne jej vysílat na všech zařízeních. Je to vhodné, sledovat stejné zařízení na smartphonu a televizi. Ale zároveň jakékoli jiné zařízení - například váš počítač je "není žádán", pokud potřebuje signál.

Proto je stále dostává, což snižuje rychlost internetu a vynakládá své zdroje.

Snooping je funkce, která pomáhá routeru zjistit, které zařízení potřebují tok dat z online hry, televize nebo speciální služby. Jednoduše řečeno, toto je optimalizace provozu ve vaší síti a zlepšování jeho bezpečnosti. Mělo by fungovat automaticky, ale někdy musíte jej nakonfigurovat ručně. To je to, co IGMP je v routeru.

Pohledy na IGMP Snooping Podpora směrovače tohoto protokolu již znamená, že nebudete mít problémy s přijetím signálu z IPTV az jiných služeb. Pokud je však router nebo modem starší, nemusí přijmout přenos dat vysílání, nebo to prostě nemá dostatek energie a bude "pověsit". Ale když je vše v pořádku, IGMP Snooping se může lišit podle typu: Pasivní. Tato základní technologická podpora, celkové sledování a vysílání dat přenos. Všechno funguje, zatížení routeru je minimální. Nicméně, zátěž se zvyšuje na zařízení v něm. Aktivní. Takový protokol maximalizuje síť. To prosévá "extra" žádosti na router, který nepotřebuje, uvolnit zdroj přenosu dat. Zvyšuje však zatížení procesoru a na paměť zařízení. Zařízení středních a vysokých cenových segmentů se s tím bez problémů vyrovnávají. Pro zařízení levnější záleží na množství dat. .

Jak nastavit funkci v routeru IGMP Disable v routeru, co je toto nastavení - na příkladu IPTV. Obvykle se vše automaticky zapne. Ale pokud si přečtete tento článek, něco jasně se pokazilo. Proto tyto kroky proveďte: Přejděte na webové rozhraní routeru: Zadejte prohlížeč v adresním panelu 192.168.1.1 nebo 192.168.0.1 nebo adresu, která je zadána v dolní nálepce. Zadejte uživatelské jméno a heslo - obvykle se jedná o "Admin" Přihlášení a heslo "Admin", pokud jste nebyli změněni ručně. Nebo zkontrolujte stejnou nálepku na routeru. .

Jděte do "Síť", "Nastavení sítě" nebo podobně. V ASUS se nazývá "Local Síť". Musíte najít kartu "IPTV". Možnost "Proxy" zahrnuje vysílání, skutečně spustí funkci IPTV. To je to, co to je, IGMP proxy v routeru. Zapnout. Ne všechny modely mají IGMP snooping položku, ale pokud je přítomen, pak jej zapněte. Snooping zlepší práci všech zařízení. .

Klikněte na tlačítko Použít ". Všechno je připraveno.

Možné problémy Je možné, když vysílání nepracovalo. To může být spojeno s brány firewall. Odpojte ji několik minut. Pokud problém zmizel, zapněte a v nastavení zapněte a v nastavení povolte protokol pro Internet TV, online hry nebo jinou službu. Video. Příklad: Anycast DNS .

Pokud IPTV používá samostatný přijímač zařízení (proč potřebujete televizní předponu, jedná se o jediné téma konverzace), pak v nastavení směrovače může být nutné vyřešit volbu "Bridge". Může být nazýván "Vybrat WAN Bridge Port" nebo "Síťový most" - záleží na zařízení.

Konečně, pokud signál "zpomaluje", pak je přístroj s největší pravděpodobností přetížen. Bude muset omezit provoz ostatních zařízení nebo je zakázat. Pokud nic nepomůže, budete muset změnit router silnějším.

V tomto článku jsem se snažil vysvětlit nejlevnější jazyk, co IGMP snooping v routeru je. Doufám, že tyto informace budou pro vás užitečné, a vy rozhodnete o problémech, které vznikly. Nyní budou vaše data přenášena tak optimálně a správně a útok v síti za účelem přetížení všech zařízení v něm nebude mít za následek. Zdroj: https://besprovodnik.ru/igmp-snooping-chto-to-v-v-rutere/

Nastavení IPTV na Mikrotik Například nastavení IPTV jsme vzali Mikrotik RB2011UIAS-2HND. Ne zcela domácí směrovač, samozřejmě, ale nastavení na jiných zařízeních se v zásadě liší. Resetovat konfigurační směrovač. / A informuje nás o příjemcích. A není nutné hovořit o jednom klientském počítači, obecně to může být například další směrovač PIM. Je důležité, na které rozhraní musí projít provozem. Aktualizujeme router (přidat balíček pro IPTV).

Nastavení proxy IGMP. Přidat výjimky firewall. Nastavení Wi-Fi.

Obnovit nastavení přístupového bodu

Tato položka je volitelná. Pokud nakonfigurujete IPTV na routeru s pracovními nastaveními, které jste udělali dříve, níže uvedené akce nejsou nutné. Také nebrání konfiguraci zálohy. Někdy však, pokud během IPTV nastavení na mikrotika něco pokazilo, nejlepší cesta ven je "resetovat" konfiguraci a dělat vše znovu. .

Obnovit nastavení do továrny může být tři způsoby: Programově Přejít na WinBox, otevřete systémové menu a proveďte konfiguraci resetu. Mechanicky: Klikněte na tlačítko Reset na Mikrotik a počkejte, až se router restartuje. (Na většině mikrotik doporučujeme, abyste sevřeli tlačítko pro zapnutí zařízení a bez uvolnění uchovávání přibližně 10 sekund po zapnutí) / A informuje nás o příjemcích. A není nutné hovořit o jednom klientském počítači, obecně to může být například další směrovač PIM. Je důležité, na které rozhraní musí projít provozem. Obnovit konfiguraci v samotném směrovači (na obrazovce nastavení). Skutečný pouze v případě, že na routeru je dotykový displej. Aktualizace Routeros (Přidání balíčku pro IPTV) Aktualizace je nutná pro instalaci dalšího balíčku pro IPTV. Jdeme na stránku Mikrotik, hledáme řadu modelu na seznamech a stahujeme nejnovější verzi firmwaru. Vezměte prosím na vědomí, že si firmware nevybíráte s hlavními balíčky (hlavními) a další (extra):

Otevřeno

Winbox.

Jdeme do routeru (doporučujeme vám, abyste zadali původně na adresu MAC, usnadní další konfigurační proces). Chcete-li aktualizovat router, přejděte do menu Soubory. Otevřete ji a přetáhněte ji do okna Soubory. Náš stažený soubor z rozbaleného archivu nazval . Multicast-x.xx-mipbebe.npk

Přidáno balíček a poté, co restartujeme vybavení v menu

Systém.

Reboot

Router bude restartovat a aktualizovat firmware. Proces může trvat až 5 minut.

Výživa v této době by neměla být zakázána!

Po restartu otevřené

Systém - balíčky. a podívejte se, zda se modul objevil

Pokud je k dispozici, pak jste udělali všechno správně. Nastavení proxy IGMP

Otevřeno v menu Mikrotik Směrování - IGMP Proxy. Pro tuto kliknutím na tlačítko PLUS musíme přidat nové rozhraní (jak je uvedeno na obrazovce). V novém rozhraní v poli Rozhraní. Vybereme port, pro který přichází internet s námi, v našem případě se jedná o ether2-mistr a nainstalovat klíště Stejně jako screenshot:

Mírně nižší v poli

Alternativní podsítí.

Měli byste zadat alternativní podsítí. V případě, že nevíte, co tam zadat, zkuste nejčastější možnosti: 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16.

  • V extrémním případě můžete také opustit nuly, ale je lepší stále najít požadovanou podsítě, takže směrovač se nevztahuje na celý internet. Potvrďte změny, klepněte na tlačítko OK. Vytvořit další rozhraní, kliknutím na modrou plus, ale teď jsme ne
  • V extrémním případě můžete také opustit nuly, ale je lepší stále najít požadovanou podsítě, takže směrovač se nevztahuje na celý internet. ). naopak OK. a zároveň vybrat přístav, který budeme Nadměrný

IPTV. - To znamená, že ten, ke kterému je zařízení připojeno, na které budeme sledovat IPTV. V našem případě je to most, protože k němu je připojen stacionární PC. .

To je v prvním případě poukázali na přístav, kde data zahrnují a nyní - odkud pocházejí. Po stisknutí tlačítka Nastavení

Istavim tick naopak

Pro technickou podporu díky Natasha Samoilenko Rychlý.

Leve.

RPF kontrola.

Děláme to, abychom mohli rychle přepínat mezi kanály.

Nastavení brány firewall

Přizpůsobte náš firewall, který nemá ujít IPTV v tuto chvíli, pro to vytvoříme nový terminál, klepněte na tlačítko Nový terminál a otevře se okno: Nyní musíme v této konzole provádět několik týmů: / IP Firewall Filter Filter Přidat akci = Přijmout řetězec = vstupní komentář = »Povolit IGMP» Zakázáno = Ne In-Interface = Ether2-Master Protocol = IGMP

/ IP Firewall Filter Filter Přidat akci = Přijmout řetěz = vstupní komentář = »IPTV UDP Příchozí» Zakázáno = Ne DST-port = 1234 In-Interface = Ether2-Master Protocol = UDP

/ IP Firewall Filter Filter Přidat akci = Přijmout řetězec = Forward Comment = »IPTV UDP Přesměrování» Zakázáno = Ne DST-port = 1234 protokol = UDP 1234.

- Přístav je neoficiálně registrován pro streamování videa a IPTV Ether2-Master. - Toto je rozhraní, pro které IPTV pochází z poskytovatele.

Další potřebu v menu

IP. Vybrat předmět Firewall

a přejděte na kartu Filtrační pravidla.

. Vytvořili jsme s výjimkou pravidel a že pracují, měli by být vyšší za zákaz. Přetahujeme je s myší.

  1. Nastavení Wi-Fi
  2. V případě, že distribuujete nebo budete vydat IPTV přes Wi-Fi, musíte přidat další nastavení. Chcete-li to udělat, otevřete v pořádku:
  3. Po stisknutí tlačítka Rozšířený režim se zobrazí další parametry:
  4. V terénu
  5. WMM Support.

Dát

Povoleno -

RPF kontrola.

Komplexní podporu pro multimediální přenos přes Wi-Fi.

Pomocník

ÚPLNÝ

. Tento parametr obsahuje odesílání zákazníků vícesměrového vysílání na Wi-Fi.

Všechny potvrďte tlačítkem

S IGMP, konečné příjemci zákazníků sdělují nejbližší směrovače, které chtějí přijímat provoz. A PIM staví cestu pohybu multicast provozu ze zdroje pro příjemce přes směrovače. OK.

a užívat si sledování programů

Zůstává pouze kontrolovat výkon naší konfigurace. Použili jsme pro tento IPTV přehrávač, n

Radiálně stahování kanálů kanálů pro našeho poskytovatele

(Volton Telecom) v nastavení přehrávače.

Vidíme, že naše nastavení je plně funkční. Šťastný prohlížení!

https://lantorg.com/article/nastrojka-iptv-na-mikrotik.

Co je igmp snooping v routeru: proč igmp snooping funkce

Klient bude také požadovat skupinu 224.2.2.4 prostřednictvím přehrávače VLC. Úloha IGMP je velmi jednoduchá: Pokud neexistují zákazníci - není nutné přenášet vícesměrový provoz na segmentu. Pokud se objeví klient, upozorní směrovače pomocí IGMP, které chce přijímat provoz. Abychom pochopili, jak se všechno děje, vezměte tuto síti: Řada platforem na internetu použijte metodu vícesměrového vysílání pro přenos dat do skupiny uživatelů. Taková technologie se používá pro online hry, živé vysílání, distanční vzdělávání a dokonce i pro poštovní zásilky. Ale multiforming ne vždy kompetentně optimalizuje dopravní relé a načte síť uživatele, takže tento problém vytvořil funkci Snooping IGMP. Pojďme rozeznat, jaká je funkce a jak ji povolit optimalizovat provoz.

Co je a proč potřebovat funkci IGMP Snooping

Chcete-li začít, dáme definici IGMP, abychom pochopili princip technologie.

Internet Group Management Protocol - Multicast Network Management Protocol, který organizuje několik zařízení ve skupinách. Zpráva o členství IGMP - "Zprávy" uzel, který chce dostávat provoz této skupiny.

Ve zprávě IGMPv2 jde na adresu požadované skupiny a paralelně je uvedena v samotném balení. Tyto zprávy musí žít pouze v rámci svého segmentu a negmentují se přesto směrovači, proto mají 1 TTL. Je založen na protokolu IP a aplikován na internet všude, efektivně pomocí síťových zdrojů.

IGMP Snooping je proces sledování multicast provozu mezi skupinami spotřebitele a hostitelem. Funkce Snooping je povoleno analyzovat požadavky uživatelů pro připojení s multi-master Group a přidá port do seznamu vysílání IGMP. Po dokončení použití multitrafication uživatel opustí dotaz a protokol, odstraní port ze seznamu dat skupiny.

Snooping tedy eliminuje přenos zbytečných dat na multicast kanálů.

Díky tomu je výměna údajů na úrovni kanálu efektivnější a zohledňuje potřeby síťové vrstvy, která je zvláště důležitá pro poskytovatele informací. Uživatelé budou také přijímat optimalizovaný obsah, i když v důsledku toho se zátěže v síti zvýší.

Bez sledování a analýzy dat, konečné spotřebitelé ve formě konkrétních adres IP budou nuceni "Digest" další zbytečné informace pro ně. který je aktivován ve výchozím nastavení na směrovačích. Rozhraní Fe0 / 0 se stává sestupovat pro skupinu 224.2.2.4 - bude muset poslat přijatý provoz. Spolu s obvyklým unikátním směrovacím stolem je také multicast: O dostupnosti zákazníků říká první záznam

IGMP Snooping nejen ušetří pouze uživatele z nadměrného provozu, ale také berou výměnu informací.

Režim sledování je povolen včas, aby se zabránilo pokusům o útoku DDOS na síti nebo konkrétní adresy, na které je protokol pro správu Internetu zranitelné. Aktivační funkce IGMP Snooping Funkce sledování a analýzy je k dispozici na spravovaných síťových přepínačích nebo přepínačích. Toto zařízení pomáhá implementovat principy vysílání skupin na úrovni kanálu sítě. .

Chcete-li aktivovat Snooping IGMP, musíte jej ručně povolit a nakonfigurovat na přepínači.

Neřízené analogy nepodporují režim analýzy provozu, protože nelze konfigurovat přes rozhraní.

Podrobněji příkaz Zobrazit IP MRULE. Budeme rozeznat později. .

Před použitím komunikátoru v síti se ujistěte, že konečný příjemce (například Smart-TV) podporuje režim Snooping.

Přístroje mají obvykle příslušnou položku v části "Setup Síťové připojení", která bude znatelně zjednodušuje nastavení vícesměrového vysílání. Klient začal přijímat provoz. Nyní by měl směrovač někdy zkontrolovat, zda příjemci mají stále mezeru, aby vysílali, pokud zůstanou náhle zákazníci. K tomu periodicky odešle požadavek na všechna jeho sestupná rozhraní. Zvažte způsob připojení funkce přes příkazový řádek na příkladu populárních přepínačů D-Link:

Otevřete příkazový řádek pomocí rozhraní CLI.

Zadejte "enable-igmp-snooping". Tento příkaz se zapne funkce na přepínači a všech připojených adresách.

Zadejte "CONFIG-IGMP-Snooping-Vlan-Default-Povolit", který vám umožní konfigurovat protokol VLAN.

Příkaz "CONFOG-MULTICAST-VLAN-filtrování-filtrační režim-Výchozí filtr-filtr-EXPREGIGRED-Skupiny" obsahuje filtrování dat z několika adres v komunikátoru.

Nakonec použijte "CONFIG-IGMP-Snooping-Vlan-Default-Snooping-Povolit" v síti VLAN.

Poslední příkaz obsahuje funkci IGMP Snooping Rychlé opuštění, která vylučuje port ze sítě, jakmile uživatel provedl žádost "dovolenou". Díky rychlému odchodu spotřebitel neobdrží zbytečná data a nebude je zpracovávat. To sníží zatížení v síti a umožní přepínač efektivněji pracovat. Pokud se v reakci na dotaz přišla alespoň jedna zpráva do routeru, znamená to, že stále existují zákazníci, pokračuje v vysílání, že rozhraní z místa, kde tato zpráva pochází, provoz této skupiny. Pokud dotaz neměl odpověď z rozhraní reakce pro některé skupiny, směrovač odstraní toto rozhraní z jeho multicast směrovací tabulky pro tuto skupinu - přestane odesílat provoz.

Sítě pro nejmenší. Část 9.2. Multicast. Protokol IGMP.

Pokračovat ve studiu multicast IGMP (Internet Group Management Protocol), síťový protokol pro interakci multicast dopravních klientů a routeru nejbližšího.

Protokol IGMP.

Znovu se vrátit na výpis. Podívejte se na tento top balení, po kterém byl hozen multicast proud? Zajímavým detailem v chování klienta: Po obdržení dotazu není ve spěchu, aby okamžitě odpověděl. Uzel má délku časového limitu od 0 do .

Zpráva protokolu IGMP při připojení

který je uveden v dalším dotazu: Při ladění nebo ve výpisu, mimochodem, je vidět, že mezi různými sestavami může projít několik sekund. To se děje, takže stovky zákazníků není celost působnosti, které nejsou zaplaveny sítí se svými zprávami tím, že obdrželi obecný dotaz. Kromě toho pouze jeden klient obvykle odešle zprávu. Tato zpráva protokolu IGMP odeslaná klientem, když jsme na něm stiskli. To je způsob, že hlásí, že chce přijímat provoz pro skupinu 224.2.2.4.

- Jedná se o síťový protokol interagující klienty multicast dopravy a nejbližší směrovač.

IPv6 používá MLD (Multicast Listener Discovery) namísto IGMP. Princip operace, kterou mají naprosto stejné, takže můžete snadno změnit IGMP všude na MLD a IP na IPv6.

Jak přesně funguje IGMP? čtyři. Tak pokračuje po staletí, dokud klient chce ukončit skupinu (například vypnout přehrávač / TV). V tomto případě posílá IGMP dovolená. Možná musíte začít s tím, že verze protokolu jsou nyní tři: IGMPv1, IGMPv2, IGMPv3. Nejpoužívanější - druhý, první je téměř zapomenut, takže o tom nebudeme mluvit, třetí je velmi podobná druhému.

Budu se zaměřovat na druhý, jako na nejvíce dopad a zvážit všechny události od připojení klienta do skupiny dříve, než je z toho. Klient bude také požadovat skupinu 224.2.2.4 prostřednictvím přehrávače VLC.

Úloha IGMP je velmi jednoduchá: Pokud neexistují zákazníci - není nutné přenášet vícesměrový provoz na segmentu. Pokud se objeví klient, upozorní směrovače pomocí IGMP, které chce přijímat provoz.

Abychom pochopili, jak se všechno děje, vezměte tuto síti:

Předpokládejme, že směrovač je již nakonfigurován pro přijímání a zpracování provozu vícesměrového vysílání.

- "Zprávy" uzel, který chce dostávat provoz této skupiny.

Specifický dotaz skupiny.

Odesílání zprávy o členství v IGMP

Ve zprávě IGMPv2 jde na adresu požadované skupiny a paralelně je uvedena v samotném balení. Tyto zprávy musí žít pouze v rámci svého segmentu a negmentují se přesto směrovači, proto mají 1 TTL. Specifický dotaz skupiny. Často v literatuře můžete splnit zmínku o

Router obdrží zprávu IGMP a uvědomit si, že toto rozhraní má nyní zákazníky, poskytuje informace ve svých tabulkách

Jedná se o výstup informací o IGMP. První skupina je požadována klientem. Třetí a čtvrtý je skupiny protokolu SSDP SSDP. Druhý je speciální skupina, která je vždy přítomna na směrovačích Cisco - používá se pro automatický protokol, který je standardně aktivován na směrovačích.

  1. Rozhraní Fe0 / 0 se stává sestupovat pro skupinu 224.2.2.4 - bude muset poslat přijatý provoz.
  2. Spolu s obvyklým unikátním směrovacím stolem je také multicast:
  3. O dostupnosti zákazníků říká první záznam
  4. Z výstupu je zřejmé, že provoz pro skupinu 224.2.2.4 přichází přes FE0 / 1 a je nutné jej přenášet do portu FE0 / 0.
  5. Rozhraní, ve kterých potřebujete přenášet provoz, jsou zahrnuta do seznamu navazujících rozhraní -
  6. Olej Každý odešle generální dotaz IGMP do sítě. Hlavním cílem je zjistit, zda existují zákazníci, a paralelně - prohlásit ostatním směrovačům v segmentu, pokud jsou, o vaší touze účastnit se voleb. Seznam odchozích rozhraní.
  7. Podrobněji se přehlídka týmu Show IP MROORTE budeme hledat později.
  8. Nad skládkou vidíte, že jakmile klient odeslal zprávu IGMP, ihned po letu UP UP UDP je video stream.

Vyhrává router S.

Příjem dotazu dotazu IGMP (výpis je filtrován podle IGMP).

7)

Ve výchozím nastavení se to stane každých 60 sekund. TTL takové balíčky jsou rovné 1. Jsou zaslány na adresu 224.0.0.1 - všechny uzly v tomto segmentu - bez určení specifické skupiny. Takové zprávy dotazu jsou volány osm) - Všeobecné. Směrovač se tedy ptá: "kluci, a kdo a co ostatní chce dostávat?".

Po obdržení generálního dotazu IGMP, kterýkoli hostitel, který poslouchá jakoukoli skupinu, musí poslat zprávu IGMP, jak to bylo při připojení. Adresa skupiny zájmu své skupiny by měla být uvedena ve zprávě. Volby Querier jsou velmi důležitým postupem v multicastu, ale některé zákeřné výrobci, kteří nedrží RFC, mohou vložit silnou hůlku do kol. Mluvím o dotazu IGMP s adresou zdroje 0.0.0.0, který může být generován přepínačem. Tyto zprávy by se neměly zúčastnit volby Querier, ale musíte být připraveni na všechno. Zde je příklad Počítačová odpověď na generální dotaz IGMP (výpis je filtrován podle IGMP)

Pokud se v reakci na dotaz přišla alespoň jedna zpráva do routeru, znamená to, že stále existují zákazníci, pokračuje v vysílání, že rozhraní z místa, kde tato zpráva pochází, provoz této skupiny. Verze 1 se liší v podstatě pouze skutečností, že Pokud dotaz neměl odpověď z rozhraní reakce pro některé skupiny, směrovač odstraní toto rozhraní z jeho multicast směrovací tabulky pro tuto skupinu - přestane odesílat provoz.

Na své iniciativě klient obvykle odešle zprávu pouze v případě připojení, pak jednoduše reaguje na dotaz z routeru.

Zajímavým detailem v chování klienta: Po obdržení dotazu není ve spěchu, aby okamžitě odpověděl. Uzel má délku časového limitu od 0 do

Při ladění nebo ve výpisu, mimochodem, je vidět, že mezi různými sestavami může projít několik sekund.

To se děje, takže stovky zákazníků není celost působnosti, které nejsou zaplaveny sítí se svými zprávami tím, že obdrželi obecný dotaz. Kromě toho pouze jeden klient obvykle odešle zprávu.

Faktem je, že zpráva je odeslána na adresu skupiny, a proto přichází ke všem zákazníkům. Po obdržení zprávy z jiného klienta pro stejnou skupinu, uzel nebude posílat své vlastní. Logika je jednoduchá: router již obdržel tuto zprávu a ví, že existují zákazníci, není to nutné.

Nad skládkou vidíte, že jakmile klient odeslal zprávu IGMP, ihned po letu UP UP UDP je video stream.

Klient bude také požadovat skupinu 224.2.2.4 prostřednictvím přehrávače VLC. Tento mechanismus se nazývá

Ve zprávě IGMPv2 jde na adresu požadované skupiny a paralelně je uvedena v samotném balení. Tyto zprávy musí žít pouze v rámci svého segmentu a negmentují se přesto směrovači, proto mají 1 TTL. Dále v článku řekneme o tom, proč tento mechanismus skutečně opravdu funguje velmi zřídka.

Podrobněji příkaz Příklad II. 4Upozorňujeme, jak by měl provoz jít v tomto případě - R1-R2-R3-R5. Ačkoli stručně, cesta R1-R3-R5.

Tam, kde neexistuje žádný router, můžeme autoritativně deklarovat - IGMP tam - ne více než formalita. Neexistuje žádný router, a klient nemá nikdo požádat o multicast proud. A vydělá video pro jednoduchý důvod, že proud a tak se vylévá z přepínače - stačí ho vyzvednout. adresu skupiny.

Opakuj znovu Odeslání opuštění IGMP

Poté se objevil klient, který chtěl přijímat provoz skupiny 224.2.2.4 a poslal svou zprávu IGMP. Směrovač to obdrží a v myšlence se musí vypnout. Ale nemůže zakázat jeden konkrétní klient - směrovač je nerozlišuje - má to jen po proudu. A rozhraní může být několik zákazníků. To znamená, že pokud router odstraní toto rozhraní z jeho seznamu OU (seznam odchozích rozhraní) pro tuto skupinu, video se vůbec vypne. Ale také to neodstraňujte, je také nemožné - najednou to byl poslední klient - Proč to pak omyjte?

Potom se router z nějakého důvodu z nějakého důvodu zkontroloval - a zda nejsou žádné další zákazníky a zaslány generálního dotazu IGMP, ke kterému je klient nucen odpovědět ( Pokud se podíváte do skládky, uvidíte, že po obdržení routeru dovolené, proud pokračuje po nějakou dobu. Faktem je, že směrovač v reakci odešlete odesílá dotaz IGMP na adresu skupiny, pro kterou tato dovolená přišla k tomuto rozhraní, odkud pocházel. Takový balíček se nazývá

Pravidelně (jednou za minutu) směrovač kontroluje, že příjemci stále mají, pomocí generálního dotazu IGMP a uzel toto potvrzuje pomocí zprávy IGMP.

Ti klienti, kteří jsou spojeni s touto konkrétní skupinou.

Odeslání specifického dotazu Router Router Group v reakci na opuštění IGMP

Pokud router obdržel zprávu odpovědi pro skupinu, pokračuje v vysílání v rozhraní, pokud není přijata - odstraní časovač poté, co časovač vypršela.

Celkem po obdržení dovolené, dvě skupiny specifický dotaz jde - jedna povinná, druhá kontrola.

Dva specifické dotazy skupiny - jedna povinná, druhá kontrola

Dále router zastaví proud. Ale stále je to naprosto nepochopitelný, jak provoz ze serveru dosáhne zákazníků, pokud je obrovský poskytovatel síť Linkmiap? A kde bude ve skutečnosti známo, kdo je klient? Nemůžeme ručně registrovat trasy, prostě proto, že nevíte, kde mohou být zákazníci. Obvyklé směrovací protokoly neodpoví na tuto otázku. Tak jsme pochopili, že doručení multicastu je pro nás něco úplně nového. Zvažte o něco více obtížnějšího: ). Dva (nebo více) směrovačů, které mohou vysílat provoz, jsou připojeny k segmentu klienta. Pokud neuděláte nic, bude multicast provoz duplikován - oba směrovače dostanou zprávu od zákazníků. Aby se tomu zabránilo, existuje volba mechanismus - politika. Ten, kdo vyhraje, bude posílat dotaz, sledovat zprávu a reagovat na odchod, a proto bude posílat provoz na segmentu. Loser bude poslouchat pouze hlášení a udržet ruku na pulsu. Volby se vyskytují poměrně jednoduché a intuitivní.

Pro technickou podporu díky Natasha Samoilenko Zvažte situaci od okamžiku, kdy jsou routery R1 a R2 zapnuty.

Aktivované IGMP na rozhraní.

RPF kontrola.

Zpočátku, ve výchozím nastavení, každý z nich považuje sám Querier.

  • Každý odešle generální dotaz IGMP do sítě. Cílem je zjistit, zda existují zákazníci a paralelně - deklarovat jiné směrovače v segmentu, pokud existují, o vaší touze účastnit se voleb. Obecný dotaz přijímá všechna zařízení v segmentu, včetně dalších směrovačů IGMP.
  • Po obdržení takové zprávy od souseda, každý router odhaduje, kdo hodnější. Vyhrává router S.
  • Příklad: Anycast DNS (specifikováno ve zdrojovém IP pole IGMP dotazu). Stává se Querier, všechny ostatní - ne-Querier.

Ne-Querier Spustí časovač, který je resetován pokaždé, když se kvaryny dodává s menší IP adresou. Pokud před vypršením časovače (více než 100 sekund: 105-107), směrovač nedostane dotaz s menší adresou, prohlašuje sám QEERIER a přebírá všechny odpovídající funkce.

Pokud Querier obdrží dotaz s menší adresou, dodává tyto povinnosti. Querier se stává dalším routerem, který má IP méně. Volby Querier jsou velmi důležitým postupem v multicastu, ale některé zákeřné výrobci, kteří nedrží RFC, mohou vložit silnou hůlku do kol. Mluvím o dotazu IGMP s adresou zdroje 0.0.0.0, který může být generován přepínačem. Tyto zprávy by se neměly zúčastnit volby Querier, ale musíte být připraveni na všechno. Zde je příklad velmi složitého dlouhodobého problému. .

Verze 1 se liší v podstatě pouze skutečností, že

. Pokud klient nechce získat více provozu této skupiny, jednoduše přestane poslat zprávu v reakci na dotaz. Pokud není jediný klient zůstane, časový limitový router přestane odesílat provoz.

Navíc, Ale stále je to naprosto nepochopitelný, jak provoz ze serveru dosáhne zákazníků, pokud je obrovský poskytovatel síť Linkmiap? A kde bude ve skutečnosti známo, kdo je klient? Nemůžeme ručně registrovat trasy, prostě proto, že nevíte, kde mohou být zákazníci. Obvyklé směrovací protokoly neodpoví na tuto otázku. Tak jsme pochopili, že doručení multicastu je pro nás něco úplně nového. . Aby se zabránilo zdvojování provozu, je vyšší protokol odpovědný, například PIM, o kterém budeme mluvit dále.

Verze 3 podporuje všechny, které podporuje IGMPv2, ale existuje řada změn. Za prvé, zpráva není odeslána již na adresu skupiny, ale na adrese služby vícesměrového vysílání

. A adresa požadované skupiny je uvedena pouze v rámci balíčku. To se děje zjednodušit práci IGMP Snooping, o kterém budeme mluvit dál.

Za druhé, co je důležitější, IGMPv3 začal podporovat SSM v jeho čisté formě. Jedná se o tzv. Zdroj specifický multicast. V tomto případě klient nemusí jen požadovat skupinu, ale také specifikovat seznam zdrojů, ze kterých by chtěl získat provoz nebo naopak, by to nechtěl. V IGMPV2 klient jednoduše požádá a přijímá skupinový provoz bez péče o zdroj.

IGMP členství reort obsah v igmpv3 IGMP je tedy navržen tak, aby spolupracoval zákazníky a router. Proto se vracet například 2, kde není žádný router, můžeme autoritativně deklarovat - IGMP tam - ne více než formalita. Neexistuje žádný router, a klient nemá nikdo požádat o multicast proud. A vydělá video pro jednoduchý důvod, že proud a tak se vylévá z přepínače - stačí ho vyzvednout. Připomeňme, že IGMP nefunguje pro IPv6. Existuje protokol MLD.

Opakuj znovu Za prvé, router poslal svůj generální dotaz IGMP po zapnutí IGMP na svém rozhraní, abyste zjistili, zda jsou příjemci a prohlásili svou touhu být dotazem. V té době nikdo nebyl v této skupině. Poté se objevil klient, který chtěl přijímat provoz skupiny 224.2.2.4 a poslal svou zprávu IGMP. Poté jsem na něm šel do provozu, ale je odfiltrován z skládky.

Pravidelně (jednou za minutu) směrovač kontroluje, že příjemci stále mají, pomocí generálního dotazu IGMP a uzel toto potvrzuje pomocí zprávy IGMP.

Pak změnil svou mysl a odmítl skupinu odesláním opuštění IGMP. Router přijal dovolenou a chtěl se ujistit, že žádné další příjemci nejsou jiní příjemci, odesílejte specifický dotaz skupiny IGMP ... dvakrát. A po uplynutí časovače přestane vysílat provoz. Nicméně, pokračuje v přenášení dotazu IGMP do sítě. Například v případě, že jste přehrávač nevypnuli, ale jednoduše někde s připojením problému. Poté je připojení obnoveno, ale klient neposílá zprávu sama. Ale dotaz odpovědi. Průtok tak může obnovit bez lidské účasti. IGMPROTOKOL, se kterým se směrovač dozví přítomnost příjemců provozu vícesměrového vysílání a o jejich vypínacích .IGMP hlášení klientem při připojení a odpověděla na dotaz IGMP. To znamená, že klient chce získat konkrétní skupinový provoz. MigMP General Queryprotes router pravidelně kontrolovat, které skupiny jsou nyní potřebné. Jako adresa příjemce, 224.0.0.1 je uvedena. .

IGMP Group Sepcific QueryPrust routerem v reakci na zprávu o dovolené zjistit, zda v této skupině existují i ​​další příjemci. Jako adresa příjemce je uvedena adresa skupiny multicastu. MigMP opustí klientem, když chce opustit skupinu.querielened v jednom vysílání segmentu několik směrovačů, které lze vysílat, mezi nimi je jeden hlavní jim. Pravidelně posílá dotaz a přenášet provoz. Zdroj:

Tagy

Cisco.

IPTV.

SDSM.

Síťový hardware

Sítě pro nejmenší https://radioprog.ru/post/623.
Co je multicast v routeru. Požadavky na systémové prostředky. Multicast a Unicast: Klíčové rozdíly

Pro technickou podporu díky Natasha Samoilenko Za prvé, pojďme hlas několik konceptů vyloučit další nedorozumění. Existují tři typy provozu:

(*, G) (s, g)

Děláme to, abychom mohli rychle přepínat mezi kanály.

Nastavení brány firewall

Přizpůsobte náš firewall, který nemá ujít IPTV v tuto chvíli, pro to vytvoříme nový terminál, klepněte na tlačítko Nový terminál a otevře se okno: Nyní musíme v této konzole provádět několik týmů: / IP Firewall Filter Filter Přidat akci = Přijmout řetězec = vstupní komentář = »Povolit IGMP» Zakázáno = Ne In-Interface = Ether2-Master Protocol = IGMP

/ IP Firewall Filter Filter Přidat akci = Přijmout řetěz = vstupní komentář = »IPTV UDP Příchozí» Zakázáno = Ne DST-port = 1234 In-Interface = Ether2-Master Protocol = UDP

/ IP Firewall Filter Filter Přidat akci = Přijmout řetězec = Forward Comment = »IPTV UDP Přesměrování» Zakázáno = Ne DST-port = 1234 protokol = UDP 1234. Olejový multicast.

- Přístav je neoficiálně registrován pro streamování videa a IPTV Ether2-Master. - Toto je rozhraní, pro které IPTV pochází z poskytovatele.

Další potřebu v menu

IP. Vybrat předmět Firewall

a přejděte na kartu Filtrační pravidla.

. Vytvořili jsme s výjimkou pravidel a že pracují, měli by být vyšší za zákaz. Přetahujeme je s myší.

  1. Nastavení Wi-Fi
  2. V případě, že distribuujete nebo budete vydat IPTV přes Wi-Fi, musíte přidat další nastavení. Chcete-li to udělat, otevřete v pořádku:
  3. Po stisknutí tlačítka Rozšířený režim se zobrazí další parametry:
  4. V terénu
  5. WMM Support. PIM SM RP.

Dát

Úkol číslo 4.

Unicast.

  1. - Unicast, jeden zdroj proudu jeden příjemce Přenos.
  2. - vysílání, jeden zdroj, příjemci Všichni zákazníci online - Multicast, jeden odesílatel, příjemci některá zákaznická skupina

Jaký druh provozu pro IPTV?

Samozřejmě je multicast dáno vysílání kanálů. Jakýkoliv televizní kanál, který chceme vysílat sítě, je charakterizován adresou skupiny, která je vybrána z rozsahu vyhrazeného pro tyto účely:

224.0.0.0 - 239.255.255.255.

Новости

Добавить комментарий