Ең кішкентай желілер. Тоғызыншы бөлігі. Multicast / Habr.

Біздің тілдік байланыс провайдері қарапайым телекоммуникация операторларының барлық қызметтерімен өсіп, тыныштықпен өседі. Енді біз IPTV-ге өттік.

Бұл Multicast-ті бағыттауды және алдымен мұндай көп люконның бар екенін түсіну қажеттілігін білдіреді.

Бұл IP желілерінің әдеттегі принциптерінен алғашқы ауытқу. Әйтсе де, мультикаст парадигмасы жылы лампадан түбегейлі ерекшеленеді.

Сіз тіпті айта аласыз, бұл қандай да бір жолмен жаңа тәсілдерді түсінуде сіздің ойыңыздың икемділігіне қатысты.

Бұл мақалада келесілерге назар аударыңыз:

Дәстүрлі бейнеролик:

Менің қалыптасуымда инженер сияқты, мультикастың тақырыбы өте қорқынышты болды, мен оны онымен алғашқы тәжірибемнің психотрамымен байланыстырдым. « Сонымен, Марат, жедел, түстен бұрын, сіз қалалық орталықта жаңа ғимаратқа бейне ағынын оятуыңыз керек - Провайдер оны екінші қабатта береді «Мен бір керемет таңды естідім. Мен содан кейін мен мультикаст туралы білетінім, сондықтан жіберуші - алушылар - алушылар көп, және IGMP протоколы қандай да бір рет қатысқан сияқты.

Нәтижесінде, түске дейін, біз бәрін бастауға тырыстық - мен ең қарапайым VLAN-ді шығыс нүктесінен кейінірек жеңдім. Бірақ сигнал тұрақсыз болды - сурет тоңазытылған, құлаған, бұзылған, үзілмеген. Мен дүрбелеңде IGMP-мен, тирхогозы, тирхогозы, IGMP-SNOOP-пен не істеуге болатынын анықтауға тырыстым, IGMP-SNOOPING, Кешірулер мен шығындар мың рет тексерілді - ештеңе көмектеспеді. Сосын кенеттен бәрі жұмыс істеді. Әрине, тұрақты, проблемасыз.

Бұл маған мультикастты егу арқылы қызмет етті, және ұзақ уақыт бойы оған ешқандай қызығушылық танытпадым.

Кейінірек мен келесі ережеге келдім: Енді, түсініксіз жағдайлардың биіктігінен, мен желінің бөлігін - Buggy ақырғы жабдықтарын орнатуда ешқандай проблемалар болмайтынын түсінемін. Тыныштап, маған сеніңіз. Осы мақаладан кейін мұндай жағдайлар сізді қорқытпайды. Жалпы түсіну мультикаст. Өздеріңіз білесіздер, келесі трафик түрлері бар: Unicast. - Unicast - бір жіберуші, бір алушы. ( Мысал: веб-сервердегі HTTP-беттен сұрау Өздеріңіз білесіздер, келесі трафик түрлері бар: ). Таратылымы. - Тарату - бір жіберуші, алушылар - тарату сегментіндегі барлық құрылғылар. ( Өздеріңіз білесіздер, келесі трафик түрлері бар: Мысал: ARP сұранысы Мультикаст. - Көпчаст - бір жіберуші, көптеген алушылар. ( Мысал: IPTV.

Кездейсоқ.

- Ең жақын түйіннің - бір Жіберуші, жалпы көптеген алушылар, бірақ іс жүзінде деректер тек біреуіне жіберіледі. ( Мысал: Кездейкім, DNS ).

Біз мультикаст туралы сөйлесуді ұйғарғандықтан, бұл абзацтан басталсақ, онда ол қай жерде және қалай қолданылады.

Ақыл-ойға келген бірінші нәрсе - бұл теледидар (IPTV) - бір бастапқы сервер бірден көптеген клиенттерді алуы керек трафикті жібереді. Бұл өз терминімен анықталады -

Мультикаст.

- Көпіршыс тарату. Яғни, егер сіз өзіңізге белгілі таратылымдар сізге белгілі болса, әркімге хабар таратуды білдіреді, мультикаст белгілі бір топты таратады.

  1. Екінші қосымша, мысалы, операциялық жүйенің репликациясы көптеген компьютерлерге жатады. Бұл бір серверден үлкен деректердің көлемін жүктеуді білдіреді.
  2. Мүмкін болатын сценарийлер: аудио және бейне конференциялар (біреуі тыңдады - барлығы тыңдады), электрондық коммерция, аукциондар, қор биржалары. Бірақ бұл теорияда, және іс жүзінде мультикаст сирек кездеседі.

Тағы бір қосымша - хаттамалық қызмет хабарламалары. Мысалы, OSPF өзінің тарататын домендегі хабарламаларын 224.0.0.5 және 224.0.0.6 мекен-жайларына жібереді. Және тек OSPF жұмыс істеп тұрған түйіндер ғана өңделеді.

Біз «Мультицест» ақпараттық бюллетендерінің екі негізгі қағидатын қалыптастырамыз:

Жіберуші алушылардың санына қарамастан, жіберуші трафиктің бір данасын ғана жібереді.

Трафик тек оған қызығушылық танытқандарды алады.

Осы мақалада біз IPTV-ді көрнекі мысал ретінде қабылдаймыз.

Мысал

Қарапайым жағдайда бастайық: Бастапқы серверде таратылым 224.2.2.4 топқа теңшелген, бұл сервердің IP-мекен-жайға трафикті 2.4.2.2.4-ке жібереді дегенді білдіреді. Клиентте бейне ойнатқыш 224.2.2.4 тобын алуға теңшелген. .

Сонымен бірге, ескерту, клиент пен серверде бір ішкі желіде және бір-бірінен мекен-жайлар болуы керек емес - бір-біріне бір-бірінен, бір хабар тарату доменінде болу үшін жеткілікті.

Multicast ағыны жай ғана серверден құйып, клиент оны жай ғана алады. Екі компьютерді патчпен және жұмыс істеп, VLC көмегімен тікелей жұмыс орнында көре аласыз.

Айта кету керек, мультипластта көзден сигнал жоқ, олар айтады,

- Сәлем, мен көзіммін, сізге аздап мультикаст қажет емес пе?

Бастапқы сервер жай интерфейсіндегі мультикаст пакеттерін тарата бастайды. Біздің мысалда олар клиентке тікелей кіріп, оларды дереу қабылдайды.

Егер сіз осы сілтемеге пакеттер алсаңыз, онда сіз мультикасттың трафигі теңіздегі UDP пакеттеріне ұқсамайтынын көресіз.

Мультичас белгілі бір хаттамаға тіркелмеген. Шын мәнінде, оның мекен-жайларын анықтайтын барлық нәрсе. Алайда, егер біз оның өтініші туралы сөйлесетін болсақ, онда олардың көпшілігінде ол UDP болып табылады. Бұл мұнда қажет деген мәліметтерді оңай түсіндіреді, бұл мультикасттың көмегімен жіберіледі. Мысалы, бейне. Егер жақтаудың бір бөлігі жоғалып кетсе, ал жіберуші оны TCP-де қалай жіберуге тырысады, содан кейін бұл, ең алдымен, бұл бөліктің кешігіп қалады және оны қайда көрсету керек? Пойыз қалды. Дыбыспен дәл солай.

Тиісінше, қосылымды орнатудың қажеті жоқ, сондықтан TCP қажет.

Мультичасканы біржоликті қалай бұру керек? Менің ойымша, сізде болжам бар. Және сіз дұрыс шығарсыз. Кәдімгі жағдайда бізде 1 алушы және 1 жіберуші бар - олардың әрқайсысында бір ерекше IP мекен-жайы бар. Жіберуші пакетті қайдан конькимен сырғанайтынын және осы мекенжайды IP тақырыбына қояды. Бағыттау кестесінің салдарынан әр аралық түйін пакетті қайда жіберу керектігін біледі. Екі түйін арасындағы Юникаст трафигі желі арқылы кедергісіз. Бірақ мәселе - әдеттегі пакетте тек бір алушының IP мекен-жайы көрсетілген. Егер бір және сол трафиктің бірнеше алушылары болса ше? Негізінде, Юникаст көзқарасын және осындай жағдайды кеңейтуге болады - пакеттің көшірмесін әр клиентке жіберу мүмкін. Клиенттер айырмашылықты байқамайды - тіпті біреуі, кем дегенде мың, бірақ айырмашылық деректер беру арналарында нақты ерекшеленеді. GБізде бір SD арнасын мультикаст серверінен беру бар делік. 2 Мб / с қолдануға рұқсат етіңіз. 30-дің жалпы каналдары және әр арнаны бір уақытта 20 адамға қарайды. Ол 2 МБ / с * 30 арнаны айналдырады * 20 адам = 1200 мб / с немесе тек 1,2 Гб / с немесе 1,2 Гб / с дутациялар кезінде теледидарда. Бірақ әлі де HD арналары бар, онда сіз бұл көрсеткішті 2-ге көбейте аласыз, ал қайғылы, қай жерде торрентке арналған?

Сондықтан мекен-жай блогы IPv4-те орналастырылды

D класы: 224.0.0.05.4

(224.0.0.29.255.255.255). Бұл диапазонның мекен-жайлары мультикаст тобымен анықталады. Бір мекен-жай - бұл бір топ, әдетте ол әріппен көрсетіледі »

«

Яғни, клиент 224.2.2.4 тобына қосылғанын, біз бұл мультикастты трафикті тағайындалған мекен-жайы бар 224.2.2.4 алады дегенді білдіреміз.

II мысал.

Схема мен тағы бірнеше тұтынушыларды қосыңыз:

Multicast сервері 224.2.2.4 тобына хабарланады. Коммутаторда барлық 4 порттар бір VLAN-да болуы керек. Қозғалыс коммутаторға келеді, ал әдепкі бір VLAN порттарына жіберіледі. Сондықтан барлық клиенттер осы трафикті алады. Олардан 224.2.2.4 топ мекен-жайы бейне ойнатқышта да көрсетілген.

Шынында, барлық осы құрылғылар осы мультикаст тобының мүшелері болады. Оған мүшелік динамикалық: кез-келген адам, кез-келген уақытта, одан шығып, одан шығады. Бұл жағдайда трафик тіпті мұны қаламайтындар да, бұл, яғни ойыншы да, бұл ойыншы да, басқа ештеңе де болмауы керек. Бірақ егер ол дәл сол Вланда болса. Кейін біз онымен қалай күресуге тырысамыз.

Есіңізде болсын, бұл жағдайда әр клиентке бөлек көшірмеде емес, коммутаторға трафиктің тек бір данасы келеді. Және біздің SD арналарымен бірге, көзі және коммутаторы арасындағы жүк 1,2 Гб / с болмайды, бірақ тек 60 Мб / с болмайды (2MB / C * 30 арналар).

Шын мәнінде, бұл бүкіл үлкен ауқымда (224.0.0.0.255.255.255) қолдануға болады.

Жақсы, барлығы дерлік - алғашқы мекен-жайлар (224.0.0.0.02.23) белгілі хаттамалар үшін сақталған.

Сақталған IP мекенжайларының тізімі

Жергілікті сілтеме бойынша қорғалатын 224.0.0.02.24

Байланыс. Мұндай мекен-жайлармен мультикаст пакеттері бір эфирлік сегменттің шегінен асып кете алмайды.

224.0.1.0/24 аралығында барлық желі ішінде мультипликтерді жіберу керек, яғни маршрутизаторлар арқылы өту керек хаттамалар бойынша сақталған.

Мұнда, шын мәнінде, мультикаст туралы ең негізгі нәрселер.

Біз қарапайым жағдайға көздік, ал алушы сол желілік сегментте болған кезде қарастырдық. Коммутатор қабылдаған трафик оларға барлық порттарда жіберіледі - сиқырлы емес.

Бірақ, әлі күнге дейін кеңестендірілмейтін нәрсе, ол серверден трафиктің клиенттерге қалай жететіні, егер үлкен провайдер желісі бар? Шын мәнінде, бұл клиент кім екені белгілі? Біз маршруттарды қолмен тіркей алмаймыз, өйткені клиенттердің қай жерде болуы мүмкін екенін білмейміз. Әдеттегі маршруттау протоколдары бұл сұраққа жауап бермейді. Сондықтан біз мультикасттың жеткізілуі біз үшін мүлдем жаңа нәрсе екенін түсінеміз.

Жалпы, мультипласттарды алушыға мультикаст жіберу үшін қазіргі уақытта көптеген протоколдар бар - IGMP / MLD, PHDP, MSDP, MSDP, MBGP, MPGP, MOPF, DVMR.

Біз олардың екеуіне назар аударамыз, олар қазіргі уақытта пайдаланылады: PIM және IGMP. IGMP көмегімен клиенттердің соңғы алушылары трафик алғысы келетін ең жақын маршрутизаторларды жеткізеді. Және Pim мультикастты трафикті алушыларға алушыларға маршрутизаторлар арқылы көшіру жолын қалыптастырады. Игм

Қоқысқа қайта оралыңыз. Осы жоғарғы буманы қараңыз, содан кейін мультикаст ағыны лақтырылды ма?

Бұл IGMP протоколының хабарламасы, біз ойнатуды басқан кезде клиент жіберген. Ол 224.2.2.4 тобына трафик алғысы келетіні туралы хабарлайды.

IGMP - Интернет-топты басқару хаттамасы

- Бұл мультикаст трафигі клиенттері мен ең жақын маршрутизатормен өзара әрекеттесетін желілік протокол.

IPv6 IGMP орнына MLD (Multicast тыңдаушысын табу) қолданады. Жұмыс принципі Олар мүлдем бірдей, сондықтан сіз IGMP-ді MLD және IP IPv6-да оңай өзгертуге болады.

IGMP қалай жұмыс істейді?

Мүмкін сіз протоколдың нұсқаларының қазір үшеуі: igmpv1, igmpv2, igmpv3. Ең көп пайдаланылатындар - екіншісі, бірінші болып ұмытылған, сондықтан біз бұл туралы сөйлеспейміз, үшіншісі екіншісіне өте ұқсас.

Мен екіншісіне, ең алдымен, ең әсерінен және оның ішінде клиентті топқа қосудан барлық оқиғаларды қарастырамын.

Клиент сонымен қатар VLC ойнатқышы арқылы 224.2.2.4 тобын сұрайды. IGMP рөлі өте қарапайым: егер клиенттер болмаса, мультикаст трафигін сегменттің алдына жіберудің қажеті жоқ. Егер клиент пайда болса, ол маршрутизаторларды ИГМП көмегімен трафикті алғысы келетінін хабарлайды. Бәрі қалай болатынын түсіну үшін осы желіні алыңыз: Маршрутизатор қазірдің өзінде Multicast трафигін қабылдауға және өңдеуге теңшелген делік.

бір.

Біз клиентте өтінімді іске қосып, 224.2.2.4 тобын орнатқан кезде, пакет желіге жіберіледі IGMP мүшелік туралы есеп - ол осы топтың трафигін алғысы келетін «есептер» түйінін.

IGMPv2 есебі қалаған топтың мекен-жайына өтеді, ал параллель ол қаптамада көрсетілген. Бұл хабарламалар тек сегментінде өмір сүруі керек және бәрібір бағытталмауы керек, сондықтан маршрутизаторлар бойынша, демек, оларда олар 1 ТТЛ бар. Жиі әдебиеттерде сіз туралы айтуға болады

IGMP қосылды.

. Қорықпаңыз - бұл IGMP мүшелік туралы есептің балама атауы.

2.

Маршрутизатор IGMP-есепті алады және осы интерфейстің клиенттері бар екенін түсініп, олардың кестелеріне ақпарат береді

Бұл IGMP туралы ақпарат нәтижесі. Бірінші топты клиент сұрайды. Үшінші және төртінші - SSDP қызметі.

Windows жүйесінде салынған. Екіншісі - әрқашан Cisco маршрутизаторларында қатысатын арнайы топ - ол Авто-RP протоколында қолданылады. ол маршрутизаторларда әдепкі бойынша іске қосылады. Fe0 / 0 интерфейсі 224.2.2.2.4 тобына түседі - алынған трафикті жіберу қажет. Әдеттегі ерекше маршруттау кестесімен бірге мультикаст бар: Клиенттердің қол жетімділігі туралы алдымен бірінші жазба айтылған

(*, 224.2.2.4)

. Және жазба (172.16.0.5, 224.2.2.4) .

Бұл маршрутизатор бұл топқа арналған мультикасттың қайнар көзі туралы білетіндігін білдіреді. Өнімнен 224.2.2.4 тобына трафик FE0 / 1 арқылы келетіні анық және оны FE0 / 0 портына жіберу керек. Трафикті жіберу қажет интерфейстер төменгі ағыс интерфейстерінің тізіміне енгізілген -

Мұнай - шығыс интерфейстерінің тізімі

Толығырақ IP MrOute көрсетіңіз. Біз кейінірек білеміз. . Саңылаудың үстінде, сіз оны клиент IGMP-есепті жібергеннен кейін, оны ұшқаннан кейін бірден UDP-ді жібергеннен кейін, ол видео ағын. .

3. Клиент трафик ала бастады. Енді маршрутизатор кейде алушылардың кенеттен клиенттер қалса, таратпау үшін алшақтық бар екенін тексеруі керек. Мұны істеу үшін ол барлық түсетін интерфейстерге сұраныс жібереді. IGMP сұранысы.

* IGMP сүзгідендірілген қоқыс * Саңылаудың үстінде, сіз оны клиент IGMP-есепті жібергеннен кейін, оны ұшқаннан кейін бірден UDP-ді жібергеннен кейін, ол видео ағын. .

Әдепкі бойынша, бұл әр 60 секунд сайын болады. TTL мұндай пакеттер де тең. Олар 224.0.0.1 мекен-жайына жіберіледі - осы сегменттегі барлық түйіндер - белгілі бір топты көрсетпестен. Мұндай сұрау хабарламалары шақырылады

Жалпы сұрау.

- Жалпы. Осылайша, маршрутизатор: «Жігіттер және тағы кім алғысы келетіндер» сұрайды.

IGMP жалпы сұранысын алғаннан кейін, кез-келген топты тыңдайтын кез-келген хост IGMP есебін қосылған кезде жіберіп алуы керек. Өз тобына қызығушылық топтарының мекен-жайы есепте көрсетілуі керек. Егер сұранысқа жауап ретінде, кем дегенде бір есеп маршрутизаторға келді, бұл әлі де клиенттердің бар екенін білдіреді, ол әлі де осы есепті қайдан шыққан интерфейс, осы топтың трафигі туралы хабарлауды жалғастырады. Егер сұрауда кейбір топтар үшін жауап интерфейсінің жауабы болмаса, маршрутизатор осы интерфейсті осы топқа жібереді - бұл топқа арналған «Трафик жіберу». Өзінің бастамасымен клиент әдетте есепті қосылған кезде ғана жібереді, содан кейін ол маршрутизатордан сұрауға жауап береді. Клиенттің мінез-құлқындағы қызықты мәліметтер: сұраныс алғаннан кейін ол тез арада есеп беруге асығып кетпейді. Түйін 0-ден бастап күту уақытын алады .Максималды жауап уақыты. .

ол келесі сұрауда көрсетілген: Қайта құру немесе қоқыстарда, айтпақшы, әр түрлі есептерді алу арасында бірнеше секундтан өтуі мүмкін екенін көруге болады. Бұл жүздеген клиенттер барлық ауқымда жалпы сұраныс алу арқылы өз есептерімен желіні өз баяндамаларымен толықтырады. Сонымен қатар, тек бір клиент тек есеп жібереді. Дәл осы есеп - бұл есеп тобының мекен-жайына жіберіледі, сондықтан барлық тұтынушыларға келеді. Басқа клиенттен бір топқа есеп алғаннан кейін, түйін өздігінен жібермейді. Логика қарапайым: Маршрутизатор бұл туралы осы есепті алды және клиенттер бар екенін біледі, қажет емес.

Бұл механизм деп аталады

Есепті басу

Келесі мақалада біз бұл механизм неліктен сирек жұмыс істейтіні туралы айтамыз Төрт. Сонымен, клиент топтан шыққысы келгенше ғасырлар бойы жалғасады (мысалы, ойнатқышты / теледидарды өшіріңіз). Бұл жағдайда ол жібереді IGMP кетеді. топ мекен-жайына.

Маршрутизатор оны алады және идеяны өшіру керек. Бірақ ол бір нақты клиентті өшіре алмайды - маршрутизатор оларды ажыратпайды - ол тек төменгі интерфейсі бар. Интерфейс бірнеше тұтынушы бола алады. Яғни, егер маршрутизатор осы интерфейсті осы топқа (шығыс интерфейстер тізімінен) осы топқа жоятын болса, бейне мүлде өшеді.

Сондай-ақ, оны жою да мүмкін емес - бұл мүмкін емес - кенеттен ол соңғы клиент болды - неге оны жуыңыз? Саңылаудың үстінде, сіз оны клиент IGMP-есепті жібергеннен кейін, оны ұшқаннан кейін бірден UDP-ді жібергеннен кейін, ол видео ағын. .

Егер сіз қоқысқа қарасаңыз, сіз демалыс орнын алғаннан кейін, ағын біраз уақытқа бара жатқанын көресіз. Шығуға жауап ретінде маршрутизатор IGMP сұрауында IGMP сұранысын осы демалысқа шыққан интерфейске келген топ мекен-жайына жібереді. Мұндай пакет деп аталады

Топтық арнайы сұрау.

. Оған жауап беріңіз

жалғыз Топтық арнайы сұрау. Осы топқа қосылған клиенттер.

Егер маршрутизатор топ үшін жауап туралы есеп алса, ол интерфейсте таратуды жалғастырады, егер қабылданбаған болса, таймердің мерзімі біткеннен кейін таймерді жояды.

Жалпы алғанда, демалысқа шыққаннан кейін, екі топқа арнайы сұраныс - бір міндетті, екінші бақылау. Әрі қарай, маршрутизатор ағынды тоқтатады. Сұрау Біршама қиын жағдайды қарастырыңыз: Трафикті таратуға болатын екі (немесе одан да көп) маршрутизаторлар клиенттің сегментіне қосылған. Егер сіз ештеңе жасамасаңыз, Multicast трафигі қайталанады - екі маршрутизаторлар да клиенттерден есеп алады. Бұған жол бермеу үшін таңдау механизмі бар - Саясат. Жеңіске алатын адам сұраныс жібереді, есепті жібереді және кетуге реакция жасайды және, сәйкесінше, ол сегментке трафик жібереді. Жеңілгендер тек есеп тыңдап, қолыңызды импульсте сақтайды. Сайлау өте қарапайым және интуитивті болады. R1 және R2 маршрутизаторлар қосылған кезден бастап жағдайды қарастырыңыз. бір) Интерфейстерде іске қосылған IGMP. 2) Алдымен, әдепкі бойынша олардың әрқайсысы өзін-өзі санайды. 3) Әрқайсысы IGMP жалпы сұранысын желіге жібереді. Басты мақсат - клиенттердің бар-жоғын және параллель-параллельді, егер олар болса, егер олар болса, олар сіз қатысса, сайлауға қатысуға деген ұмтылыстарыңыз туралы хабарлау. төрт) Жалпы сұрау сегменттегі барлық құрылғыларды, соның ішінде басқа IGMP маршрутизаторларынан алады. бес) Көршісінен осындай хабарлама алғаннан кейін, әр маршрутизатор өзіне лайықты кімге баға береді. 6) Routs S.

Кіші IP.

(IGMP сұрауының бастапқы IP өрісінде көрсетілген). Ол барлық басқалардан, басқаларға - жауап бермейді.

7)

Кодерьер кез келген уақытта квариядан кіші IP мекен-жайымен бірге қалпына келтірілген таймерді бастайды. Егер таймердің жарамдылық мерзімі аяқталғанға дейін (100 секундтан артық: 105-107), маршрутизатор кіші мекен-жайы бар сұраныс алмайды, ол өзін-өзі жауап бермейді және барлық сәйкес функцияларды қабылдайды. сегіз) Егер сұраушы кіші мекен-жайы бар сұрау алса, ол осы міндеттерді қосады. Куберер басқа маршрутизаторға айналуда, оның ішінде IP аз.

Бұл сирек кездесетін жағдай, ол аз, ол аз. Сайлауды сайлау - бұл көп деңгейдегі өте маңызды процедура, бірақ RFC өткізбейтін кейбір тауарлар өндірушілері доңғалақтарға күшті таяқшаны сала алады. Мен IGMP сұранысы туралы айтып отырмын, оны коммутатор арқылы жасауға болады. Мұндай хабарламалар сұрауды таңдауға қатыспауы керек, бірақ сіз бәріне дайын болуыңыз керек. Міне, мысал Өте күрделі ұзақ уақыт.

.

Басқа IGMP нұсқалары туралы бірнеше сөз 1 нұсқасы мәні бойынша, тек осыған байланысты Оның хабарламасы жоқ

.

. Егер Клиент осы топтың қосымша трафигін алғысы келмесе, ол сұрауға жауап ретінде есеп жіберуді тоқтатады. Бір клиент қалмаған кезде күту уақыты маршрутизаторы трафикті жіберуді тоқтатады. Оның үстіне, Ешқандай сұрауларға сайлауға қолдау көрсетілмейді.

. Трафиктің қайталануын болдырмас үшін жоғары протоколға жауап береді, мысалы, біз, бұдан әрі қарай сөйлейтін пим 3-нұсқа IGMPv2 қолдайтындардың бәрін қолдайды, бірақ бірқатар өзгерістер бар. Біріншіден, есеп енді топ мекен-жайына жіберілмейді, бірақ Multicast қызметінің мекен-жайы бойынша 224.0.0.22

. Және сұралған топтың мекен-жайы тек пакетте көрсетілген. Бұл IGMP Snooping жұмысын жеңілдету үшін жасалады, ол біз туралы сөйлесеміз

.

Екіншіден, ең бастысы, Игмпв3 SSM-ді таза түрінде қолдай бастады. Бұл деп аталады

Саңылаудың үстінде, сіз оны клиент IGMP-есепті жібергеннен кейін, оны ұшқаннан кейін бірден UDP-ді жібергеннен кейін, ол видео ағын. .

Клиент сонымен қатар VLC ойнатқышы арқылы 224.2.2.4 тобын сұрайды. Сигнал көзі арнайы мультичас. IGMPv2 есебі қалаған топтың мекен-жайына өтеді, ал параллель ол қаптамада көрсетілген. Бұл хабарламалар тек сегментінде өмір сүруі керек және бәрібір бағытталмауы керек, сондықтан маршрутизаторлар бойынша, демек, оларда олар 1 ТТЛ бар. . Бұл жағдайда Клиент топты ғана сұрамауы мүмкін, сонымен қатар ол трафик алғысы келетін немесе керісінше алғысы келмейтін көздер тізімін көрсете алмайды. IGMPV2-де клиент топтық трафикті дереккөзге қамқорсыз сұрайды және алады. Сонымен, IGMP клиенттер мен маршрутизатормен өзара әрекеттесуге арналған. Сондықтан, оралу Толығырақ II мысал. 4Өздеріңіз білесіздер, келесі трафик түрлері бар: Маршрутизатор жоқ жерде біз беделді түрде жария ете аламыз - IGMP - бұл формальдылықтан артық емес. Маршрутизатор жоқ, ал клиенттің мультикастты ағын сұрайтын ешкімі жоқ. Ол қарапайым себептер үшін видео табады, сондықтан ағынның және оны коммутатордан құйып, оны алу керек. Еске салайық, IGMP IPv6 үшін жұмыс істемейді. MLD протоколы бар Қайталаңыз Біріншіден, маршрутизатор IGMP жалпы сұранысын IGMP-ті өзінің интерфейсіне қосқаннан кейін жіберді және алушылардың бар-жоғын білу және олардың жұмысқа деген ниеті туралы хабарлаңыз. Ол кезде бұл топта ешкім болған жоқ. Содан кейін 224.2.2.2 топтың трафигін алғысы келген клиент пайда болды және ол өзінің IGMP есебін жіберді. Осыдан кейін мен ондағы трафикке бардым, бірақ ол қоқыстардан алынады. Содан кейін маршрутизатор тексеру үшін қандай да бір себептерді шешуге шешім қабылдады және клиенттерге жауап беретін IGMP жалпы сұранысы жоқ па, себебі қайтадан жіберілді ме ( бес.

Мерзімді түрде (минут бір рет) маршрутизатор алушылардың алушыларының әлі де бар екенін тексереді, ал IGMP жалпы сұранысын пайдаланып, IGMP есебін пайдаланып, мұны растайды.

Бірақ, әлі күнге дейін кеңестендірілмейтін нәрсе, ол серверден трафиктің клиенттерге қалай жететіні, егер үлкен провайдер желісі бар? Шын мәнінде, бұл клиент кім екені белгілі? Біз маршруттарды қолмен тіркей алмаймыз, өйткені клиенттердің қай жерде болуы мүмкін екенін білмейміз. Әдеттегі маршруттау протоколдары бұл сұраққа жауап бермейді. Сондықтан біз мультикасттың жеткізілуі біз үшін мүлдем жаңа нәрсе екенін түсінеміз. 6. Содан кейін ол өз ойын өзгертіп, топты игмп демалысын жіберіп, бас тартты. 7. Маршрутизатор демалысқа келіп, басқа алушылардың басқа алушылар болмағанына көз жеткізгіңізші, IGMP Group арнайы сұранысын жіберіңіз ... екі рет. Таймер аяқталғаннан кейін осы жерден тасымалданады. сегіз. Дегенмен, IGMP сұрауын желіге жіберуді жалғастыруда. Мысалы, егер сіз ойнатқышты өшірмеген болсаңыз, бірақ жай мәселені байланыстырыңыз. Содан кейін байланыс қалпына келтірілді, бірақ клиент өздігінен есеп жібермейді. Бірақ сұрау жауаптар. Осылайша, ағын адамның қатысуынсыз қалпына келеді. Тағы бір рет Бұл жүздеген клиенттер барлық ауқымда жалпы сұраныс алу арқылы өз есептерімен желіні өз баяндамаларымен толықтырады. Сонымен қатар, тек бір клиент тек есеп жібереді. - маршрутизатор мультикаст жол қозғалысы алушылардың болуы және оларды ажырату туралы білетін хаттама. Топтық арнайы сұрау. IGMP есебі

- IGMP сұрауына қосылған кезде Клиент жіберген. Бұл клиент белгілі бір топтың көрінісін алғысы келетінін білдіреді.

.

IGMP жалпы сұранысы.

- Қазір оны маршрутизатор қазір қай топтар қажет екенін тексеру үшін жіберіледі. 224.0.0.1 Алушының мекен-жайы көрсетілгендей.

IGMP Group Sepcific Query

- Маршрутизатор хабарламаның демалысына жауап ретінде жіберіледі, осы топта басқа алушылардың бар-жоғын білу үшін жіберіледі. Алушының мекен-жайы бойынша Multicast тобының мекен-жайы көрсетілген.

- Топтан кеткісі келген кезде Клиент таңдаған.

- Егер бір таратылым сегментінде таратылатын бірнеше маршрутизаторлар болса, олардың арасында бір негізгі сұрау таңдалады. Ол мезгіл-мезгіл сұрауды жіберіп, трафикті жібереді.

Барлық IGMP шарттарының толық сипаттамасы

Аспап

Сонымен, біз клиенттердің жақын жердегі маршрутизаторға олардың ниеті туралы қалай хабарлағанын білдік. Енді трафикті алушыға үлкен желі арқылы тасымалдау жақсы болар еді. Егер сіз бұл туралы ойласаңыз, біз күрделі күрделі мәселе алдында тұрмыз - тек топқа тек топқа таратылады, ол алушылар қай жерде және қанша тұратындығы туралы білмейді. .

Алушылар мен жақын маршрутизаторлар тек белгілі бір топтың көрінісі қажет екенін біледі, бірақ оның қай жерде екендігі туралы түсінік жоқ және оның мекен-жайы қандай. Бұл жағдайда трафикті қалай жеткізуге болады?

Бірнеше мультикасттың бірнеше маршруттық протоколдары бар: DVMRPR

  • , Моспкет.
  • , CBT.

- Олардың барлығы осындай тапсырманы әр түрлі жолмен шешеді. Бірақ стандартты де-факто болды

PIM - тәуелсіз мультикаст

Басқа тәсілдер соншалықты қажетсіз, олар кейде оларды әзірлеушілер де таниды. Мысалы, CBT протоколы арқылы RFC-ден үзінді: 2-нұсқа 2-нұсқа жоқ, және 1-нұсқа бойынша кері үйлесімді болуға арналған; Біз бұл үйлесімділік проблемаларын тудырмаймыз, өйткені біз CBT-ді осы кезеңде кеңінен орналастырылғанына сенбейміз.

Pim-да екі түрлі хаттама деп аталуы мүмкін екі нұсқа бар, олар әр түрлі ерекшеленеді:

PIM тығыз режимі (DM)

Пим сирек (SM) Тәуелсіз ол ерекше трафикті бағыттаудың белгілі бір бағдарламасына байланбағандықтан, кейінірек сіз неге екенін көресіз. .

PIM тығыз режимі.

Пим DM.

Маңдайдағы көп сілтемені жеткізу мәселесін шешуге тырысады. Ол алушылар барлық жерде, барлық жерде, желінің барлық бұрыштарында екенін анық көрсетеді. Осылайша, ол бүкіл мультикасттың бүкіл желісін қояды, яғни ол барлық порттарға жібереді, сонымен қатар ол келген жерде. Егер ол бір жерде оның қажеті жоқ болса, онда бұл филиал арнайы хабарламаның көмегімен «кесіп тастаңыз», сонымен қатар арнайы хабарламаның көмегімен - трафик енді жіберілмейді. Бірақ біраз уақыттан кейін маршрутизатор тағы да мультикаст жіберуге тырысады - кенеттен алушылар пайда болды. Егер пайда болмаса, бұтақ белгілі бір уақытта қайтадан кесіледі. Егер маршрутизатордағы Клиент осы екі оқиға аралықында пайда болса, ATPARS хабарламасы жіберіледі - маршрутизатор кесілген бұтақты бір нәрсені түсіргенше күтпеу үшін сұрайды. .

Көріп отырғаныңыздай, алушыларға жолды анықтау туралы ешқандай мәселе жоқ - трафик оларға қол жеткізеді, өйткені ол барлық жерде.

Қажетсіз бұтақтарды «сүндеттеу» кейін, ағаш қалады, оның бойында мультикаст трафигі өтті. Бұл ағаш деп аталады

SPT - ең қысқа жол ағашы

Бұл ілмектерден жоқ және алушыдан алынған ең қысқа жолды қайнар көзге қолданады. Негізінде бұл STP-дегі аузына арналған ағашқа өте ұқсас

Тамыр көзі болып табылады.

SPT - бұл бетон ағашының көрінісі - ең қысқа ағаш ағашы. Жалпы, кез-келген көп цифрлық ағаш деп аталады

MDT - мультикаст тарату ағашы

Pim DM-ді мультикасттың жоғары тығыздығы желілерінде қолданған жөн, ол оның атын (тығыз) түсіндіреді. Бірақ шындық дегеніміз, бұл жағдайдың бұл жағдайы да, көбінесе пим Дм орынсыз деп санайды. Біз үшін шынымен не маңызды нәрсе - ілмектерден аулақ болу тетігі. Мұндай желіні елестетіп көріңізші:

Бір көзі, бір алушы және олардың арасындағы қарапайым IP желісі. Пим DM жұмыс істейтін барлық маршрутизаторларда.

Егер ілмектерден аулақ болу үшін арнайы механизм болмаса, не болады?

Көзі мультикаст трафигін жібереді. R1 оны қабылдайды және Pim DM қағидаттарына сәйкес барлық интерфейстерге жібереді, сонымен қатар ол келген, ол қайдан келді - бұл R2 және R3.

R2 бірдей, яғни R3-ге трафик жібереді. R3 бұл R1-ден алған трафик екенін анықтай алмайды, сондықтан оны оның барлық интерфейстеріне жібереді. R1 трафиктің көшірмесін R3 және т.б. алады. Мұнда ол цикл.

Мұндай жағдайда PIM нені ұсынады?

RPF - кері жолды қайта жіберу

. Бұл мультимрастикалық трафикті PIM (кез-келген түрдегі: және DM және SM) берудің басты қағидасы - көзден трафик қысқа жолмен жүруі керек. Яғни, әрбір алынған мультикасттың пакеттік пакеті үшін ол маршруттау кестесінің негізінде тексеріледі, ол сол жерден келді. 1) Маршрутизатор мультикаст пакет көзінің мекен-жайына қарайды.

2) Бағыттау кестесін тексереді, оның көмегімен бастапқы мекенжай қол жетімді.

3) мультикаст пакеті келген интерфейсті тексереді.

4) Егер интерфейстер сәйкес келсе - бәрі жақсы, егер деректер басқа интерфейс болса, олар алынып тасталады - олар алынып тасталады.

Мысал: IPTV.

Біздің мысалда R3 дереккөздің ең қысқа жолы R1 (статикалық немесе динамикалық маршрут) болатынын біледі. Сондықтан R1-ден алынған мультикасттың пакеттері R3 алынады, ал R2-ден шыққандар алынып тасталады.

Бұл тексеру шақырылады

RPF-тексеру. Оның арқасында тіпті күрделі желілерде де, MDT-дағы ілмектер пайда болмайды. Бұл механизм біз үшін маңызды, өйткені ол өзекті және PIM-SM-де және басқа да жұмыс істейді.

Көріп отырғаныңыздай, PIM бірегей маршруттау кестесіне негізделеді, бірақ алдымен ол кездейсоқ трафикке ұшырамайды, екіншіден, кестені кім және қалай толтыратыны маңызды емес. Сіз осында тоқтап, PIM DM жұмысын егжей-тегжейлі қарастырайық - бұл кемшіліктерді өлшеуі бар ескірген хаттама (жақсы, RIP сияқты) .

Алайда, кейбір жағдайларда Pim DM қолдануға болады. Мысалы, өте кішкентай желілерде, мұнда мультикасттың ағуы аз.

Пим са тымалы режимі.

Мүлдем басқа тәсіл қолданылады Пим.

. Атауға қарамастан (зақымдалған режим), оны кез-келген желіде, ең болмағанда, Pim DM-ден гөрі тиімділігі бар кез-келген желіде пайдалануға болады.

.

Мұнда олар көп деңгейлі желіні сөзсіз су басу туралы ойдан бас тартты. Мүдделі түйіндер Хабарламаларды қолдана отырып, ағаш қосылымын дербес сұрайды 
PIM қосылу. Егер маршрутизатор қосылса, онда трафик жіберілмейді. PIM қалай жұмыс істейтінін түсіну үшін қарапайым желіні бір пышақ маршрутизаторымен бастайық:

Параметрлерден R1-ге дейін, сіз Multicast, Pim SM-ді екі интерфейске (көзге және клиентке қарай және клиентке қарай) және IGMP-ге бағыттау мүмкіндігін қосуыңыз керек.

Басқа негізгі параметрлерге қосымша, әрине, (IP, IGP).

Осыдан бастап, сіз GN-ді тастап, зертхананы жинай аласыз. Бұл мақалада мен айтқан мультикастты қалай жинауға болатындығы туралы жеткілікті.

R1 (config) #ip multicast-маршруттау R1 (config) # fa0 / 0 R1 (config-if) #IP PIM SARSE режимі R1 (config-if) # fa1 / 0 R1 (config-if) #ip pim (config Сирек режим. Cisco мұнда әдетте оның ерекше тәсілімен ерекшеленеді: Интерфейсте PIM-ді қосқан кезде, IGMP автоматты түрде қосылады. Пим іске қосылған барлық интерфейстерде ол жұмыс істейді және IGMP. Сонымен бірге, басқа өндірушілерде екі түрлі протоколдар бар, екі түрлі команданы қосады: жеке IGMP, бөлек пим. КИСКО-ны кешіру Бұл таңқаларлық? Басқалармен бірге? Сонымен қатар, RP мекенжайын конфигурациялау қажет болуы мүмкін ( IP PIM RP-мекен-жайы 172.16.0.1 , мысалы). Бұл туралы кейінірек, берілген және қабылдау кезінде қабылдау кезінде.

224.2.2.2 тобына арналған «Multicast маршруттау кестесінің ағымдағы күйін» тексеріңіз: Дереккөзден таратқаннан кейін, сіз кестені қайта тексеруіңіз керек. Осы кішкентай қорытындыға талдау жүргізейік.

Жазу көрінісі (*, 225.0.1.1) Сонымен бірге, басқа өндірушілерде екі түрлі протоколдар бар, екі түрлі команданы қосады: жеке IGMP, бөлек пим. қоңырау шалу Сонымен қатар, RP мекенжайын конфигурациялау қажет болуы мүмкін ( (*, G) , / оқыңыз Старкомаджи (/ Және алушылар туралы бізге хабарлайды. Бір клиент-компьютер туралы айтудың қажеті жоқ, жалпы ол, мысалы, басқа пим роутері болуы мүмкін емес. Қай интерфейстердің трафикті өтуі керек. Егер төменгі интерфейстердің (майдың) тізімі бос болса -

Нөл

Сондықтан алушылар жоқ, және біз оларды әлі іске қоспадық.

Хаттама

(172.16.0.5, 225.0.1.1) (S, g) .

Эския

/ Және қайнар көзі белгілі. Біздің жағдайда, 172.16.0.5 мекен-жайы бар көзі 224.2.2.2.4 тобына трафик таратады. Multicast трафигі FE0 / 1 интерфейсіне келеді - бұл

өсу

Неғаш

) Интерфейс.

Сонымен, клиенттер жоқ. Дереккөзден трафик маршрутизаторға келеді және осы өмірде аяқталады. Алушыға қазір қосылайық - біз компьютердегі мультикасттың қабылдауын орнатамыз.

ДК IGMP есебін жібереді, маршрутизатор клиенттердің клиенттердің пайда болғанын және Multicast маршрутизациялау кестесін жаңартатынын түсінеді. Енді ол келесідей: Төменгі ағын интерфейсі пайда болды: FE0 / 0, ол өте күтілген. Бұл (*, g) және ішінен де пайда болды (s, g). Төменгі интерфейстердің тізімі шақырылады

Мұнай - шығыс интерфейстері

.

Fe1 / 0 интерфейсіне басқа клиентті қосыңыз:

Егер сіз нәтижені сөзбе-сөз оқыған болсаңыз, бізде:

(*, G): 224.2.2.4 тобына MultIall қозғалыс алушылары бар, олар FE0 / 0, Fe1 / 0 интерфейстерінің сыртқы интерфейсі бар. Жіберуші кімге, не дейді және «*» белгісін дейді. 

(S, g): Қайнар көзі 172.16.0.5.

Бірақ бұл өте қарапайым мысал болды - бір маршрутизатор бастапқы мекенжайды және алушылар орналасқан жерді бірден біледі. Шын мәнінде, тіпті ағаштар да жоқ, тіпті азаяды. Бірақ бұл бізге Pim мен IGMP қалай қарым-қатынас жасауға көмектесті. 
Қандай пиммен жұмыс істеу үшін біз желіні әлдеқайда күрделірек айтамыз

Барлық IP мекенжайлары схемаға сәйкес теңшелген делік. Желі қарапайым бірегей маршруттау үшін IGP іске қосады. Клиент11 Мысалы, бастапқы серверді жинай алады. Бірақ әзірге пим, IGMP жұмыс істемейді, клиенттер арналарды сұрамайды. Файлдың бастапқы конфигурациясы

Сонымен, уақыт сәті 0.

Барлық бес маршрутизаторға мультикастты бағыттауды қосыңыз:

Rx (config) #IP Multicast-маршрут

PIM тікелей барлық маршрутизаторлардың барлық интерфейстеріне кіреді (соның ішінде бастапқы сервер мен клиенттерге интерфейске):

Rx (config) # fex / x rx (config-if) #IP PIM SARSE режимі IGMP, теорияда, теорияға клиенттерге интерфейске қосылу керек, бірақ біз жоғарыда атап өткеніміздей, біз жоғарыда айтып өткендей, ол Cisco жабдықтарында автоматты түрде қосылады. PIM - бұл көршілерді белгілейді. Бұл үшін пайдаланылатын хабарламалар

Пим Сәлеметсіз бе?

. Интерфейске арналған пимді іске қосқан кезде, pim helly мекен-жайға жіберіледі

  1. 224.0.0.13
  2. TTL-мен тең. Бұл тек бір таратқан домендегі маршрутизаторлар көршілер болуы мүмкін дегенді білдіреді.

Көршілер бір-бірінен құттықтаулар болғаннан кейін:

Енді олар мультикаст топтарына өтініш қабылдауға дайын.

Егер біз қазір бір қолыңыздағы клиенттің корпусынан басталсақ және көптеген серверден басқа серверден бастаймыз, содан кейін R1-де R1 қосылып, R4 қосылу кезінде IGMP есебін алады. Нәтижесінде R1 алушылар туралы ештеңе білмейді және R4 дереккөзде. Егер ақпарат көзі туралы ақпарат пен топтың клиенттері туралы ақпарат бір жерде жиналса жақсы болар еді. Бірақ не? Мұндай кездесудің мұндай нүктесі шақырылады

Rendezvous Point - RP 

. Бұл Pim Sm-дің орталық тұжырымдамасы. Онсыз ештеңе жұмыс істемейді. Мұнда бастапқы және алушылар бар.

Барлық пимдік маршрутизаторлар домендегі RP екенін білуі керек, яғни оның IP-мекен-жайын біледі. MDT ағашын салу үшін, желі RP ретінде таңдалады, ол, ол, Дереккөзді оқуға жауапты,

Бұл барлық қызығушылық танытқан хабарламаларды тарту нүктесі. 

RP тапсырмасының екі әдісі бар: статикалық және динамикалық. Біз осы мақалада да қарастырамыз, бірақ статистен бастаймыз, өйткені статикалық нәрсе болуы мүмкін?

R2 RP ойнауға рұқсат етіңіз.

Сенімділікті арттыру үшін, кері мекен-жайы әдетте таңдалады. сондықтан

Барлығы үшін

Маршрутизаторларды пәрмен орындайды: Rx (config) #IP PIM RP-мекен-жайы 2.2.2.2 )

Әрине, бұл мекен-жайы маршруттау кестесінде барлық нүктелерден қол жетімді болуы керек. Ал, өйткені 2.2.2.2 мекен-жайы RP, өйткені интерфейске )

0-ден R2-де пимді іске қосу керек. R2 (config) # sithace leasback 0 rx (config-if) #IP PIM SARSE режимі )

Осыдан кейін бірден R4 224.2.2.2 тобына трафиктің қайнар көзі туралы біледі:

Тіпті аударымдар:

Fe0 / 1 интерфейсі 362000 б / с және олар жіберілген Fe0 / 0 интерфейсі арқылы келеді.

Біз жасадық: Әрі қарай, маршрутизатор ағынды тоқтатады. Multicast трафигін бағыттау мүмкіндігі болды (

Біршама қиын жағдайды қарастырыңыз: IP Multicast-маршрут

Интерфейстерде активтендірілген пим ( Яғни, әрбір алынған мультикасттың пакеттік пакеті үшін ол маршруттау кестесінің негізінде тексеріледі, ол сол жерден келді. IP PIM SARSE режимі

Rp мекен-жайы көрсетілген ( IP PIM RP-адрес X.x.x.x. Бәрі, бұл қазірдің өзінде жұмыс конфигурациясы болып табылады және оларды іздеуге болады, өйткені сахна сахнада көрінетіннен әлдеқайда жасырылған. Пиммен толық конфигурация.

- Саясат. Жеңіске алатын адам сұраныс жібереді, есепті жібереді және кетуге реакция жасайды және, сәйкесінше, ол сегментке трафик жібереді. Жеңілгендер тек есеп тыңдап, қолыңызды импульсте сақтайды. Қиылыс

Ал, бәрі қалай жұмыс істейді? RP тұтынушылар қай жерде екенін біледі және олардың арасында байланыс орнатады? Бәрі біздің сүйікті клиенттерімізге шыққандықтан, олардан бастап, олардан бастап, бүкіл процесті егжей-тегжейлі қарастырайық. Клиент 1 224.2.2.4 топ үшін IGMP есебін жібереді

R4 Бұл сұрау алады, FE0 / 0 интерфейсінен тыс клиенттің бар екенін түсінеді, бұл интерфейсті май мен формалар жазуға қосады (*, g).

Мұнда FE0 / 1 интерфейсі қарастырылған, бірақ бұл R4 224.2.2.2 тобына трафикті қабылдайды дегенді білдірмейді. Ол тек ол алатын жерден жалғыз орын, Fe0 / 1, өйткені ол жерде RP бар. Айтпақшы, көршісі өткен көрші

R1 және R2 маршрутизаторлар қосылған кезден бастап жағдайды қарастырыңыз. - R2: 10.0.2.24. Күтілетін.

R4 деп аталады - LHR (соңғы хоп маршрутизаторы) - егер сіз көзден есептесеңіз, мультикасттың жолындағы соңғы маршрутизатор. Басқаша айтқанда, бұл алушыға ең жақын маршрутизатор. Үшін

Клиент11. - бұл R4 үшін Клиент22.

- Бұл R5.

R4-де мультикастта жоқ (ол бұрын сұралмады), ол PIM қосылыңыз және оны RP-ге жібереді (2.2.2.2).

PIM қосылу 224.0.0.13 мекен-жайына мультикаст арқылы жіберіледі. «RP бағыты бойынша» маршрутизация кестеде көрсетілген интерфейс арқылы, қаптамада көрсетілген мекен-жайға шығады. Біздің жағдайда, бұл 2.2.2.2 - RP мекен-жайы. Мұндай қосылыстар деп аталады

Қосылу (*, g)

Оның айтуынша,: «Кімнің көзі маңызды емес, маған топтық трафик қажет 224.2.2.4.» Яғни, жолдағы әрбір маршрутизатор осындай қосылыстармен жұмыс істеуі керек және қажет болған жағдайда RP-ге жаңа қосылуды жіберіңіз. (Егер маршрутизаторда осы топ бар болса, онда ол біріктіруді жібермейді, ол жайылымдық интерфейсті қосады және олай қосылған интерфейсті қосады және трафик өтуді бастайды). Біздің жағдайда қосылыңыз FE0 / 1-ге кетті:

R2 Қосылуды алғаннан кейін (*, g) жазбаны жасайды және FE0 / 0 интерфейсін майға қосады. Бірақ қосылу енді жібере алмайды - оның өзі РП, әлі күнге дейін көзі туралы білмейді. Бірақ біраз уақыттан кейін маршрутизатор тағы да мультикаст жіберуге тырысады - кенеттен алушылар пайда болды. Егер пайда болмаса, бұтақ белгілі бір уақытта қайтадан кесіледі. Егер маршрутизатордағы Клиент осы екі оқиға аралықында пайда болса, ATPARS хабарламасы жіберіледі - маршрутизатор кесілген бұтақты бір нәрсені түсіргенше күтпеу үшін сұрайды. Осылайша, RP тұтынушылар қай жерде орналасқандығы туралы біледі.

Интерфейстерде іске қосылған IGMP. Егер а

Клиент 2. Сондай-ақ, бір топқа Multicast трафигін алғыңыз келеді, R5 FE0 / 1-ге қосылады, өйткені ол оны алған, RP, R3, RP, R3 қосылыңыз, жаңа PIM-ді құрайды және оны FE1 / 1 құрайды, мұндағы RP орналасқан. Яғни, түйіннің артындағы түйіннің артында RP немесе басқа маршрутизаторға дейін қосылыңыз, онда ол осы топтың тұтынушылары бар.

Сонымен, R2 - біздің RP - қазір FE0 / 0 және Fe1 / 0 үшін 224.2.2.2 тобына алушылары бар екенін біледі.

Онда қанша тұратыны маңызды емес, ал біреуі әр түрлі немесе жүзден бірнеше рет трафиктің ағымы интерфейсте болады. Егер сіз графикалық түрде көрсеткен болсаңыз, онда ол келесідей болады: Қашықтан ағашқа ұқсайды, дұрыс па? Сондықтан, ол шақырылады -

Алдымен, әдепкі бойынша олардың әрқайсысы өзін-өзі санайды. RPT - Rendezvous Point The

. Бұл ағаш RP-де тамырланған, ал бұтақтары клиенттерге таралған.

Жоғары деңгейдегі жалпы термин - біз жоғарыда айттық -

- мультикаст ағыны таратылатын ағаш. Кейінірек сіз MDT және RPT арасындағы айырмашылықты көресіз.

Енді біз серверді береміз. Жоғарыда айтқанымыздай, ол PIM, RP, IGMP туралы алаңдамайды - ол жай таратады. Және R1 бұл ағынды алады. Оның міндеті - RP-ге мультикаст жіберу. Пимде хабарламалардың ерекше түрі бар - Тіркеу . RP-ге мультикаст көзін тіркеу қажет.

Жалпы сұрау сегменттегі барлық құрылғыларды, соның ішінде басқа IGMP маршрутизаторларынан алады. Сонымен, R1 мультикастты ағындарды алады 224.2.2.4:

R1

FHR (бірінші хоп маршрутизаторы)

- мультикасттың жолындағы алғашқы маршрутизатор немесе көзге жақын орналасқан алғашқы маршрутизатор.

Әрі қарай, ол көзден алынған әр түрлі пакетті кодтарды бірегей PIM регистріне және тікелей RP-ге жібереді.

  1. Хаттамалық стекке назар аударыңыз. Юниктің IP-інің үстіне және PIM тақырыбы - бұл Multicast IP, UDP және деректер.
  2. Енді, басқалардан айырмашылығы, бізге белгілі PIM хабарламалары, Алушының мекен-жайы бойынша, 2.2.2.2 мекен-жайы бойынша, көп селекон мекен-жайы емес.

Мұндай пакет RP-ге Unickrens маршрутизациясының стандартты ережелеріне сәйкес жеткізіледі және түпнұсқа мультикаст пакетін алады, яғни, бұл ... Бұл туннельдеу!

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

Тапсырма нөмірі 1. Схема және бастапқы конфигурация. .

Көршісінен осындай хабарлама алғаннан кейін, әр маршрутизатор өзіне лайықты кімге баға береді. 172.16.0.5 серверінде пакеттерді тек 255.255.255.255 мекен-жайына жібере алады, бұл UDP 10999 алушы портымен. Бұл трафик 1 және 2 клиенттерге жеткізілуі керек: .

Тапсырыс беруші 1 Топтық мекен-жайы бар мультикаст трафигі түрінде 239.9.9.9.

Және 2-сегментте, 255.255.255.255 мекен-жайға таратылатын пакеттер түрінде.

Тапсырма туралы толық ақпарат.

===================== Схема және бастапқы конфигурация. RP PIM регистрін қабылдайды, оны шығарып, 224.2.2.2.4 тобына орауышпен анықтайды. Тәуелсіз ол ерекше трафикті бағыттаудың белгілі бір бағдарламасына байланбағандықтан, кейінірек сіз неге екенін көресіз. Бұл туралы ақпарат, ол бірден мультикасттың кестесіне енеді:

Кіру (S, G) - (172.16.0.5, 224.2.2.4). Шығырылмаған RP пакеттері FE0 / 0 және Fe1 / 0 интерфейстеріне жіберіледі, оған сәйкес клиенттерге трафик келеді.

Негізінде, оны тоқтатуға болады. Барлығы жұмыс істейді - клиенттер трафикті алады. Бірақ екі мәселе бар:

Инкапсуляция мен декапсация процестері - маршрутизаторлар үшін өте қымбат әрекеттер. Сонымен қатар, қосымша тақырыптар пакеттің мөлшерін арттырады, және ол бір жерде MTU-ға кірмейді, бұл аралық түйіннің бір жеріне көтерілмейді (сіз туннельдің барлық мәселелерін есіңізде сақтаңыз).

Егер кенеттен қайнар көзі мен RP арасында бір жерде топқа арналған алушылар бар, сонымен қатар, Multicast трафигі екі есе көп өтуі керек. Мысалы, мұндай топология: Тіркелу хабарламаларындағы трафик R1-R42-R2 сызығымен RP-ге жетеді, содан кейін Net Multicast R2-R42 жолымен қайтарылады. Осылайша, R42-R2 сызығында бір трафиктің екі данасы қарама-қарсы бағытта алынады. Сондықтан, таза мультикастты RP-ге RP-ге ауыстырған дұрыс, және ол үшін ағаш салу керек - Бастапқы ағаш Сондықтан, RP PIM жібереді R1-ге қосылу. Бірақ қазір ол топтық мекен-жайы үшін, бірақ дереккөзі регистр хабарламасынан оқытылады. Бұл хабарлама шақырылады Қосылу (S, G) - көздің нақты қосылуы Оның мақсаты - PIM қосылыңыз (*, g) - ағашты, тек осы уақытқа дейін ағынға дейін жасаңыз. Қосылу (S, G) Түйіннің артындағы түйіннің артындағы түйінді (*, g) кеңейтеді. Тек қосылыңыз (*, g) RP-ге ұмтылып, S - S - S - SOURCE (S, G) қосылыңыз. Алушының мекен-жайы бойынша 224.0.0.13 және TTL = 1 қызмет мекен-жайы болып табылады. Егер аралық түйіндер болса, мысалы, R42, олар сонымен қатар, олар жазбалар (S, G) және осы топ үшін төмен ағыс интерфейстерінің тізімі және көздеріне қосылыңыз. RP-ден көзге қосылатын жол - Ағаш көзден. Бірақ кең таралған атау - - Айтылғаннан кейін, көзден RP-ге трафик қысқа жолмен жүреді.

тоғыз) R1 Қосылу (S, G), FE1 / 0 интерфейсін қосады, оның ішінде бума төменгі ағыс интерфейстерінің тізіміне келді және таза мультикастты трафикті, мүмкін емес инкапсуляцияны тарата бастайды. R1-де жазу (S, G) бастапқы серверден бірінші көп қабатты пакетті алған кезде болды. Салынған бастапқы ағашқа сәйкес, мультикаст жіберіледі RP (және және олар, мысалы,, мысалы, R42). .

Есіңізде болсын, тіркелу хабарламалары осы уақытқа дейін беріліп, осы уақытқа дейін өтті. Яғни, R1 қазір трафиктің екі данасын жібереді: біреуі - бұл таза мультикаст, екіншісі, екіншісі Юникелік тіркелімде капсулаланған. Біріншіден, R1 Тіркелу үшін мультикастты жібереді - 231 пакет.

. Содан кейін R2 (RP) ағашқа қосылғысы келеді, қосылыңыз -

232 пакет.

. R1 біраз уақыт болып табылады, егер сұрау R2 өңдеген кезде, тіркелу үшін мультикастты жібереді ( 233-238 аралығында пакеттер ). Әрі қарай, Төменгі интерфейс R1-ге қосылған кезде, ол таза мультикастты тарата бастайды -

Пакеттер 239 және 242 , бірақ әлі тоқтап, тіркелмейді - 241 және 243 пакеттер . Бірақ и 240 пакет. - Бұл R2 тұра алмады және тағы бір рет ағаш салуды сұрады. Схема және бастапқы конфигурация. 10) Сонымен, жайлы мультикаст rp-ге жетеді. Ол бұл тіркеуде болатын трафик екенін түсінеді, өйткені бірдей топ мекен-жайы бірдей бастапқы мекен-жайы және бір интерфейстен тұрады. Екі көшірмесін алмағаныңыз үшін ол R1-ге бірегейге жіберіледі Pim тіркеу аялдамасы

Тіркелу - R2 трафикті бас тартпайды немесе осы дереккөзді көбірек білмейді дегенді білдірмейді, ол тек жіберуді тоқтату керек дейді

капсулаланған трафик. Әрі қарай, қатал күрес - R1 тіркеуді тоқтату процестері және әдеттегі мультикаст және тіркелім хабарламалары ішіндегі буферде жинақталған трафикті беруді жалғастыруда:

Бірақ, ерте ме, кеш пе, R1 тек таза мультикаст трафигін тарата бастайды.

Дайындық кезінде менде заңды сұрақ болды: жақсы, неге осы туннельдеу, пимді тіркеді? Неліктен мультикаст тасымалы бар емес, PIM қосылыңыз - TTL = 1-мен Hop-қа HOP-қа RP-ге дейін хоп жіберіңіз - ерте ме, кеш пе, ол келеді? Сондықтан ол сонымен бірге бір уақытта қажетсіз қимылсыз ағаш салады.

Мұнда бірнеше нюанстар бар.

Біріншіден, Pim SM негізгі қағидасы бұзылады - трафик тек сұралған жерге жіберілді.

Қосылу жоқ - ағаш жоқ

! Екіншіден, егер бұл топқа тапсырыс берілмесе, FHR мұны танымайды және «өз ағашына» трафик жіберуді жалғастырады. Өткізу қабілеттілігін сансыз пайдалану дегеніміз не? Байланыс әлемінде мұндай протокол жай ғана өмір сүрмейді, өйткені PIM DM немесе DVMR арқылы өмір сүрмейді. Сондықтан бізде 224.2.2.4 тобына бір үлкен MDT ағашы бар

Енді біз серверді береміз. Жоғарыда айтқанымыздай, ол PIM, RP, IGMP туралы алаңдамайды - ол жай таратады. Және R1 бұл ағынды алады. Оның міндеті - RP-ге мультикаст жіберу. Дереккөз серверлер Тіркеу дейін Тапсырыс беруші 1.

Тапсырыс беруші 2.

. Бұл Мдт бір-біріне тәуелсіз салынған екі дана тұрады:

Дереккөзден RP-ге және Оқытушы RP-ден тұтынушыларға. Мұнда бұл RPT және SPT-ден MDT арасындағы айырмашылық. MDT - бұл өте қарапайым, бұл жалпы беріліс ағашын, ал RPT / SPT - бұл өте нақты көрінісі.

Ал егер сервер таратылса, және ешқандай тұтынушы жоқ және жоқ па? Multicast, сондықтан оны жіберуші мен RP арасында бітеді ме?

Жоқ, бұл жағдайда PIM тіркеуді тоқтату да көмектеседі. Егер Тіркеу хабары кейбір топ үшін RP-де басталса және оған алушылар жоқ болса, RP осы трафикті алуға мүдделі емес, сондықтан

Жібермеңіз

PIM Қосылу (S, G), RP дереу R1-ге тіркелуді дереу жібереді.

R1 тіркеуді қабылдап, осы топқа ағаш жоқ екенін көріп, осы топқа ағаш жоқ екенін көріп, серверден мультикастты трафикті алып тастай бастайды.

Яғни, сервердің өзі бұл туралы алаңдамайды және ағынды жіберуді жалғастыруда, бірақ маршрутизатор интерфейсіне жетті, бірақ ағын алынып тасталады.

Бұл жағдайда RP кіруді сақтауды жалғастырады (S, G). Яғни, трафик алмайды, бірақ тауар көзі тауар біледі. Егер алушылар топта пайда болса, RP олар туралы біледі және ағашты құрайтын бастапқы қосылыстарға (S, G) жібереді.

Сонымен қатар, R1 әр 3 минут сайын RP-ге қайта тіркеуге тырысады, яғни регистр пакеттерін жібереді. RP-ге хабарлау үшін, бұл ақпарат әлі де тірі екенін хабарлайды.

Атап айтқанда, ізденткіш оқырмандарда мәселе туындауы керек - rpf ше? Өйткені, бұл механизм Multicast бумасының мекен-жайын тексереді және егер трафик дұрыс интерфейстен шықпаса, ол алынып тасталады. Сонымен бірге, RP және SOURCE әр түрлі интерфейстерде болуы мүмкін. Сонымен, біздің мысалда R3 RP үшін - Fe1 / 1 үшін және Fe1 / 0 көзі үшін. . Бірақ Жауап болжалды - бұл жағдайда бастапқы мекен-жайы тексеріледі, бірақ RP. Яғни, трафик интерфейстен RP-ге дейін болуы керек. Бірақ, сіз одан әрі көргендей, бұл да шындыққа жанаспайтын ереже емес. .

RP әмбебап магнит емес екенін түсіну маңызды - әр топ үшін оның RP болуы мүмкін. Яғни, олардың екеуі желіде болуы мүмкін, ал үш және жүз бір RP бір топқа жауап береді, екіншісі басқалардан кейін. Сонымен қатар, мұндай нәрсе бар Кездейсоқ RP. Содан кейін әр түрлі RP бірдей топқа қызмет ете алады. № 2 тапсырма. и - бұл R4 үшін Топологияға ескерту : Бұл проблемада тек R1, R2 маршрутизаторлары біздің желіміздің әкімшілері болып табылады. Яғни, конфигурацияны тек оларда өзгертуге болады. Сервер 172.16.0.5 Көптұрсо трафигін топтарға жібереді 239.1.1.1 және 239.2.2.2.

Желіні 239.1.1.1 Топ трафигі R3 және R5 арасындағы сегментке жіберілмеген етіп теңшеу, R3 арасындағы және барлық сегменттерге R5 төменірек.

Бірақ сонымен бірге, 239.2.2-ші трафик тобы проблемасыз түрде берілуі керек.

Тапсырма туралы толық ақпарат.

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

Оккама немесе қажетсіз бұтақтарды өшіру

Сегменттегі соңғы клиенттен кейін жазылудан бас тартқаннан кейін, пим, PIM артық RPT филиалын кесіп тастауы керек.

Мысалы, R4-тегі жалғыз клиент компьютерді өшіре берсін. IGMP маршрутизаторды немесе үштен кейін қалдырудан кейін немесе үштен кейін, FE0 / 0 үшін клиенттердің жоқтығын түсінеді және RP хабарламасына жібереді

Пим жүзі . Пішім бойынша, ол біріктірумен бірдей, бірақ керісінше функцияны орындайды. Межелі мекен-жайы 224.0.0.13, және TTL - 1.

Бірақ жазылымды жоймас бұрын, Pim Prune алған маршрутизаторы біраз уақытты күтеді (әдетте 3 секунд - кідіріс таймеріне қосылыңыз).

Бұл мұндай жағдай үшін жасалады:

Бір тарату доменінде 3 маршрутизатор. Олардың бірі жоғары және ол мультикаст трафигін сегментке жібереді. Бұл R1. Екі маршрутизаторлар үшін (R2 және R3) үшін оның майында тек бір жазба бар.

Егер R2 Pim Prune ажырату және жіберу туралы шешім қабылдаса, ол өзінің әріптесін R3 - R1-ді алмастыра алады, өйткені ол барлық интерфейске таратыла бастайды.

Сонымен, бұл болмайды, R1 және 3 секунд ішінде уақыт береді. Осы уақыт ішінде R3 реакцияға уақыт болуы керек. Егер ол R2-ден бас тартуды ескере отырып, егер ол трафикті алуды қаласа, ол әдеттегі PIM-ді лезде жібереді, ол әдеттегі PIM-ді сегментке жібереді, бұл R1-ге хабарлама жібереді, бұл интерфейсті жою қажет емес.

Бұл процесс Қуаттануды болдырмайды. R2, R1-Йелингтің echruction бастаманы ұстап алғандай.

SPT ауыстырғыш - RPT-SPT коммутациясы

Осы уақытқа дейін біз көбіне ғана қарастырдық

. Енді бұрайық Тапсырыс беруші 2. Басында бәрі бірдей Тапсырыс беруші 1. - Ол біз бұрын қарастырған RP-ден UP қолданамыз. Айтпақшы, өйткені екеуі де - және

Клиент 1. .

- бір ағашты қолданыңыз, мұндай ағаш деп аталады

Ортақ ағаш

- Бұл өте қарапайым атау. Ортақ ағаш = RPT.

  • R5-дегі Multicast маршруттау кестесі ағаштың құрылысы аяқталғаннан кейін бірден көрінеді: Жазба (S, G) жоқ, бірақ бұл мультикаст трафигі берілмейді дегенді білдірмейді. Жай R5, ол кім жіберушіге мән бермейді. Осы жағдайда трафиктің қалай өтуі керек екенін ескеріңіз - R1-R2-R3-R5. Қысқаша айтқанда, R1-R3-R5 жолы.
  • Егер желі қиын болса? Қандай да бір, неше, Неэккуратомо. Осы жағдайда трафиктің қалай өтуі керек екенін ескеріңіз - R1-R2-R3-R5. Қысқаша айтқанда, R1-R3-R5 жолы.
  • Бұл факт - бұл бізге RP-ге байланған кезде - бұл RPT түбірі, ол алдымен ол қай жерде екенін біледі. Алайда, егер сіз бірінші Multicast пакеті туралы ойласаңыз, бағдаршам бойындағы барлық маршрутизаторлар бастапқы мекенжайды біледі, өйткені ол IP тақырыпында көрсетілген. Неліктен ешкімге жіберілмейді? Дереккөзге қосылып, маршрутты оңтайландыра алмайсыз ба? )

Тамырдағы сайт. Мұндай коммутация бастауға болады

LHR (соңғы хоп маршрутизаторы)

- r5. R3 R5-ден бірінші мультикальды пакетті алғаннан кейін, ол бастапқы қосылыстарды (S, g) бізге FE0 / 1 интерфейсіне жібереді, ол өзінің бағыттау кестесінде көрсетілген, ол 172.16.0.02.24.

Осындай кіреберісті алғаннан кейін R3 оны әдеттегідей (*, g), бірақ дереккөзге (маршруттау кестесіне сәйкес интерфейс арқылы) жібереді. Яғни, бұл жағдайда R3 (172.16.0.5, 224.2.2.4) Fe1 / 0 интерфейсіне жібереді. .

Әрі қарай, бұл қосылыстар R1-ге түседі. Және R1-ді және үлкен айырмашылықсыз, оны жіберген - RP немесе басқа біреу - ол 224.2.2.4 тобына FE1 / 1-ді өз мойнына қосады. Осы кезде, бастапқы және алушы арасында екі жол мен R3 екі ағынды алады. Қажет емес нәрсені таңдауға уақыт келді. Бұл R3 жасайды, өйткені R5 бұдан былай осы екі ағынды ажырата алмайды, өйткені екеуі де бір интерфейс арқылы келеді.

R3 әр түрлі интерфейстерден екі бірдей ағын жазғаннан кейін, ол бағыттау кестесіне сәйкес артықшылықты таңдайды. Бұл жағдайда RP арқылы тікелей, жақсы. Осы кезде R3 Қуаттан (S, g) RP-ге жібереді, осы RPT бұтақтарын жағып жібереді. Осы кезде тікелей көзден бір ғана ағын бар.

Осылайша, Pim SPT - ең қысқа жол ағашы. Бұл бастапқы ағаш. Бұл клиенттің дереккөзден ең қысқа жолы. Айтпақшы, біз жоғарыдан біз жоғары деп санаған rp-ге дейін ағаштар бірдей SPT болып табылады.

Ол жазу арқылы сипатталады (S, G). Егер маршрутизаторда осындай жазба болса, онда ол S тобының G және SPT Thee салғанын біледі.

SPT ағашының тамыры - бұл көзі болып табылады және шынымен «ең қысқа жол» деп айтқысы келеді

Тапсырыс беруші көзі « Бірақ бұл техникалық тұрғыдан дұрыс емес, өйткені көзден алынған жолдар клиентке және клиенттен бастап көзге дейін әр түрлі болуы мүмкін. Клиенттен ағаш бұтақтарын салуды бастайды: Маршрутизатор PIM-ді жібереді, Socke / RP және RPF-ке қосылады, сонымен қатар интерфейстің дұрыстығын тексереді Түсім

трафик.

Сіз есіңіздеше, осы тармақтың басында тек жазба болды (*, g), енді осы оқиғалардан кейін екі жасар болады: (*, g) және (s, g) Айтпақшы, егер сіз R3-ке R3-ке дейін R3-ке дейін, VLC-де ойнатсаңыз да, сіз R1-ден тікелей трафикті алғаныңызды көресіз, ол қазірдің өзінде көліктің бар екенін көресіз (S, G) дейді. . Яғни, SPT ауыстырғыш болып өтті - бұл көптеген өндірушілердің жабдықтарындағы әдепкі әрекет - бірінші мультикаст пакетін алғаннан кейін коммутациялау. Жалпы, мұндай коммутатор бірнеше жағдайда пайда болуы мүмкін: . Пішім бойынша, ол біріктірумен бірдей, бірақ керісінше функцияны орындайды. .

Мүлдем болмаңыз (команда)

IP PIM SPT-Tashstord шексіздігі

).

Өткізу қабілеттілігін пайдалану кезінде (команда)

IP PIM SPT-TRESTOLD x Әрине - бірінші пакетті алғаннан кейін бірден (әдепкі немесе IP Pim SPT-TRESTOLD x жоқ

Әдетте, «уақыт» деп шешілетін шешім LHR.

Бұл жағдайда RPF әрекеті екінші рет өзгертіледі - ол бастапқы орынды қайтадан тексереді. Яғни, екі мультикальды ағындардың ішінен - ​​RP-ден және көзден - артықшылыққа ие.

Др, растау, экспедитор

Пимді қарастыру кезінде тағы бірнеше маңызды ойлар.

DR - тағайындалған маршрутизатор

Бұл арнайы маршрутизатор, ол RP-ге коммуналдық қызметтерді жіберуге жауапты.

Доктор көзі Доктор

- Multicast пакеттерін тікелей көзден және оны RP-ге тіркейді. Міне, топологияның мысалы: .

Екі маршрутизаторлар да RP-ге трафик өткізетін ештеңе жоқ, олар бір-біріне резерв өткізсін, бірақ жауапкершілік тек біреуі болуы керек. Екі маршрутизатор екі трансляция желісіне қосылғандықтан, олар бір-бірінен пим-сәлем алады. Оның негізінде олар өз таңдауын жасайды. Pim сәлем осы интерфейстегі осы маршрутизатордың басым мәнін ұсынады.

Мәні көп, басымдық соғұрлым жоғары болады. Егер олар бірдей болса, түйін таңдалған Ең жоғары IP мекенжайы (сонымен қатар сәлем хабарламасынан). Егер күту уақытында тағы бір маршрутизатор (DR-ді емес) (DR-ді емес) (әдепкі 105-ж.-да) көршісінен сәлем алмады, ол автоматты түрде др рөлін болжады. Enter enter dr

FHR - бірінші хоп маршрутизаторы

Қабылдағыш доктор - DR көзі сияқты, тек Multicast-тің қозғалыс алушылары үшін - R2 (config) # sithace leasback 0 rx (config-if) #IP PIM SARSE режимі .

Мысал топология: DR қабылдағыш RP PIM-ге қосылуға жауап береді. Жоғарыда аталған топологияда, егер екі маршрутизаторлар да қосылса, екеуі де мультикастикалық трафик алады, бірақ қажет емес. Тек DR жібереді. Екіншіден, ДР-ның қол жетімділігін бақылайды. :

DR жіберулер қосылсын, ол да LAN-да трафик таратылады. Бірақ содан кейін табиғи сұрақ туындайды - және егер пим дрикі біреуі болып, ал IGMP-дің басқа сұрағы болса ше? Жағдай өте мүмкін, өйткені сұраушы, аз IP үшін, соғұрлым жақсы және доктор үшін, керісінше. - бұл R4 үшін Бұл жағдайда DR-ді қазірдің өзінде сұраныс болып табылатын маршрутизатор таңдалған, және бұл проблема болмайды.

Ресивер DR таңдау ережелері DR көзіне бірдей бірдей.

Болжам және Пим-экспедитор

Бір уақытта транпуттерді таратудың екеуі желінің ортасында пайда болуы мүмкін, онда түпкілікті тұтынушылар немесе көздер жоқ, тек маршрутизаторлар жоқ. Бұл сұрақ өте өткір бұл сұрақ Пим Д.М. тұрды, мұнда тасқын және қылшық тетігі салдарынан мүлдем қарапайым жағдай болды. Бірақ Pim SM-де ол алынып тасталмайды.

Мұндай желіні қарастырыңыз: Өнімнен 224.2.2.4 тобына трафик FE0 / 1 арқылы келетіні анық және оны FE0 / 0 портына жіберу керек. Мұнда үш маршрутизатор бірдей желілік сегментте және тиісінше, пимнің көршілері. R1 RP ретінде әрекет етеді.

R4 PIM жібереді RP-ге қосылу. Бұл мультикаст пакеті R2-ге және R3-ге түсіп кетеді, ал екеуі де оны өңдейді, екеуі де мұнайға төмен ағын интерфейсін қосыңыз.

Мұнда DR селекциялық механизмін, сонымен қатар R2 және R3-де және R3-де осы топтың басқа клиенттері бар, сонымен қатар маршрутизаторлар да PIM-ге жіберілуі керек еді.

Multicast трафигі R2 және R3-тегі дереккөзден шыққан кезде, ол сегментте де, көтеріліске де жіберіледі. Пим мұндай жағдайдың алдын алуға тырыспайды - мұнда ол дау тудыратын қылмыс фактісі бойынша әрекет етеді - маршрутизатор осы топтың төменгі интерфейсінде (мұнай тізімінен) мультикастты трафикті қабылдаған кезде, ол түсінеді: бірдеңе дұрыс емес - Осы сегментте тағы бір жіберуші бар. Содан кейін маршрутизатор арнайы хабарлама жібереді. PIM сендіреді.

Мұндай хабарлама таңдауға көмектеседі 

Пим экспедиторы.

- осы сегментте таратылатын маршрутизатор. Pim Dr-мен шатастырмаңыз. Біріншіден, Pim Dr жіберуге жауап береді PIM Қосылыңыз және алдын алыңыз және Pim экспедиторы - жіберу үшін Трафик

. Екінші айырмашылық - Pim DR-ді кез-келген желілерде кез-келген желілерде әрқашан таңдалады, ал PHIM құралы қажет болған жағдайда ғана, егер қажет болса, майдың тізімінен Multicast трафигі алынды.

RP таңдаңыз. 

Жоғарыда біз қарапайымдыққа қол жеткіздік IP PIM RP-мекен-жайы Міне, команда қалай көрінді

IP PIM RP көрсетіңіз

Бірақ біз заманауи желілерде мүлдем мүмкін емес жағдайды ұсынамыз - R2 сәтсіз аяқталды. Мұның бәрі - аяқтау. Ол әлі де жұмыс істейді, өйткені SPT ауыстырылды, бірақ бәрі жаңа, бірақ балама әдіс болса да, RP-ге өткен барлық нәрсе сынады. Ал, домен әкімшісіне жүктеме. Елестетіп көріңізші: 50 маршрутизаторды кем дегенде бір пәрменмен өлтіру (және әртүрлі топтар үшін, ол әр түрлі RPS болуы мүмкін). RP динамикалық түрде таңдау қолдануға мүмкіндік береді және қолдан жасалған және сенімділікті қамтамасыз етеді - егер бір RP қол жетімді болмаса, басқасы дереу шайқасады. Қазіргі уақытта оған қол жеткізуге мүмкіндік беретін жалпы қабылданған протокол бар - Жүктеу . Бұрынғы уақытта Циска бірнеше ілулі авто-РП-ны алға тартты

бірақ қазір бұл дерлік қолданылмайды, дегенмен Циска оны танымаса да, 224.0.1.40 тобының түрінде бізде тітіркендіргіш румен бар. Автоматты RP протоколын іс жүзінде төлеу керек. Ол бұрынғы уақытта құтқарылу болды. Бірақ ашық және икемді жүктеудің пайда болуымен ол табиғи түрде оның ұстанымына жол берді.

Сонымен, біздің желімізде R2-ді сәтсіз болған жағдайда R3 функцияларын алуды қалаймыз делік.

R2 және R3 RP рөліне үміткер ретінде анықталған, сондықтан олар шақырылады

C-RP.

. Осы маршрутизаторларда:

Rx (config) Интерфейс Интерфейс 0 rx (config-if) IP PIM SARSE режимі RX (config-if) rx (config) rx (config) #ip pim rp rp-үміткер 0

  1. Бірақ әлі де ештеңе болмайды - кандидаттар барлығына өздері туралы хабардар етуді әлі білмейді.
  2. Барлық RP енгізілген RP-дің бар механизмі туралы барлық мультиплекстік домендік маршруттарды хабарлау
  3. BSR - жүктеу маршрутизаторы
  4. . C-RP сияқты бірнеше үміткер болуы мүмкін. Олар сәйкесінше шақырылады
  5. C-bsr.
  6. . Олар ұқсас түрде конфигурацияланған.

BSR бізбен бірге болыңыз және тест үшін (тек) ол R1 болады. Бірақ біраз уақыттан кейін маршрутизатор тағы да мультикаст жіберуге тырысады - кенеттен алушылар пайда болды. Егер пайда болмаса, бұтақ белгілі бір уақытта қайтадан кесіледі. Егер маршрутизатордағы Клиент осы екі оқиға аралықында пайда болса, ATPARS хабарламасы жіберіледі - маршрутизатор кесілген бұтақты бір нәрсені түсіргенше күтпеу үшін сұрайды. R1 (Config) интерфейсінің интерфейсі 0 R1 (егер IF) IP PIM SARSE-MODE R1 (config-IF) R1 (config-IF) r1 (config) r1 (config) #IP PIM BSR-кандидат 0 Тәуелсіз ол ерекше трафикті бағыттаудың белгілі бір бағдарламасына байланбағандықтан, кейінірек сіз неге екенін көресіз. Біріншіден, бір негізгі BSR барлық C-BSR-ден таңдалады, олар барлығына ақы алынады. Мұны істеу үшін әр C-BSR мультикастты жібереді қоңырау шалу Жүктеу туралы хабарлама (BSM) Схема және бастапқы конфигурация. 224.0.0.13 мекен-жайы - PIM протоколының пакеті. Оны барлық мультикасттың барлық маршрутизаторларын қабылдау және өңдеу керек және PIM қосылған барлық порттарға жіберілгеннен кейін. BSM бір нәрсенің (RP немесе SOURCE) емес, PIM қосылудан және барлық бағыттар бойынша беріледі. Желдеткіштің мұндай поштасы желінің барлық бұрыштарының, соның ішінде барлық C-BSR және барлық C-RP-нің BSM-ге қол жеткізуге көмектеседі. BSM желінің жанында жүргені үшін RPF механизмі қолданылады - егер BSM осы хабарламаның Жіберуші желісі босатылған дұрыс емес интерфейстен пайда болса, мұндай хабарлама алынып тасталады. Яғни, жолдағы әрбір маршрутизатор осындай қосылыстармен жұмыс істеуі керек және қажет болған жағдайда RP-ге жаңа қосылуды жіберіңіз. (Егер маршрутизаторда осы топ бар болса, онда ол біріктіруді жібермейді, ол жайылымдық интерфейсті қосады және олай қосылған интерфейсті қосады және трафик өтуді бастайды). Осы BSM-мен барлық мультикаст роутерлері басымдықтарға негізделген ең лайықты кандидатты анықтайды. C-BSR BSM-ді басқа маршрутизатордан үлкен басымдықпен қабылдағаннан кейін, ол өз хабарламаларын жіберуді тоқтатады. Нәтижесінде, әркім бірдей ақпаратқа ие. КИСКО-ны кешіру Бұл таңқаларлық? Басқалармен бірге? . : Бұл проблемада тек R1, R2 маршрутизаторлары біздің желіміздің әкімшілері болып табылады. Яғни, конфигурацияны тек оларда өзгертуге болады. Бұл кезеңде BSR таңдалған кезде, оның BSM желісі бүкіл желіде тұрғанына байланысты, C-RP өзінің мекен-жайы мен бірегейлігін біледі

Кандидат-РП-Хабарландыру олар өздері қызмет ететін топтардың тізімін алып жүреді - бұл аталады Топтық-RP картасын жасау . BSR Барлық осы хабарламалар агрегаттарымен және жасайды RP-SET. - Ақпараттық кесте: Әр топқа қандай RP қызмет көрсетіледі. Әрі қарай, BSR бұрынғы желдеткіш тәсілдеріндегі Bootstrap хабарламасын жібереді, бұл жолы RP-SET бар. Бұл хабарламалар барлық мультикасттың барлық маршрутизаторларына сәтті қол жеткізеді Тек Әр нақты топ үшін қандай RP қолданылуы керек таңдау жасайды. BSR мезгіл-мезгіл осындай таралуды жүзеге асырады, сондықтан бір жағынан RP-дегі ақпараттың әлі де маңызды екенін және басқа C-BSR-де білгендер, олар БСР-дің басты бессінің өзі әлі тірі екенін білді. Айтпақшы, rp, сонымен қатар, сонымен бірге мезгіл-мезгіл үміткер-RP-жарнамалық хабарландыруларыңызды BSR-ге жіберіңіз. Сондай-ақ, бір топқа Multicast трафигін алғыңыз келеді, R5 FE0 / 1-ге қосылады, өйткені ол оны алған, RP, R3, RP, R3 қосылыңыз, жаңа PIM-ді құрайды және оны FE1 / 1 құрайды, мұндағы RP орналасқан. Шын мәнінде, автоматты RP таңдауын теңшеу үшін не істеу керек - C-RP, C-RP көрсетіңіз және C-BSR-ді көрсетіңіз - көп жұмыс емес, басқалары сізге арналған шпалдар жасайды. Әдеттегідей, сенімділікті арттыру мақсатында, алдағы уақытта кандидаттар ретінде цифрлық интерфейстерді көрсету ұсынылады. Pim SM тарауын толтыру, ең маңызды сәттерді байқайық Бұл сұрақ өте өткір бұл сұрақ Пим Д.М. тұрды, мұнда тасқын және қылшық тетігі салдарынан мүлдем қарапайым жағдай болды. Қарапайым бірегей қосылым IGP немесе статикалық бағыттармен қамтамасыз етілуі керек. Бұл RPF алгоритмі негізінде жасалады. Ағаш клиент пайда болғаннан кейін ғана негізделген. Бұл ағаш құрылысын бастайтын клиент. Клиент жоқ - ағаш жоқ. RPF ілмектерді болдырмауға көмектеседі. Барлық маршрутизаторлар кімнің кім екенін білуі керек, өйткені сіз тек ағаш салуға болады. RP нүктесі статикалық түрде көрсетілуі мүмкін және оны жүктеу протоколын пайдаланып автоматты түрде таңдауға болады. RPT бірінші фазада жасалады - клиенттерден RP-ге және бастапқы ағашқа ағаш - қайнар көзден бастап RP-ге дейін ағаш. Екінші кезеңде салынған RPT-ден SPT-ден ауысу алушының көзге дейінгі ең қысқа жолы болып табылады. Сондай-ақ, біз қазір белгілі ағаштар мен хабарламалардың барлық түрлерін де тізімдімін. . Кез-келген мультикаст беру ағашын сипаттайтын ортақ термин.

. Клиенттен немесе RP-ге ең қысқа жолмен ағаш көзге дейін. Pim DM-де тек SPT бар. PIM SM SM SPT SPT-ден RP-ге немесе көзден алушыларға SPT ауыстырылғаннан кейін алушыға дейін болуы мүмкін. Жазба арқылы көрсетілген

- Топ үшін белгілі көздер.

- SPT сияқты.

. RP-ден алушыларға дейін. Тек Pim sm қолданылады. Жазба арқылы көрсетілген

- RPT сияқты. Ол осылай деп аталады, өйткені барлық тұтынушылар RP-де тамыры бар бір ортақ ағашқа қосылған.

PIM SARSE MODE хабарламалары:

Сәлеметсіз бе.

- көршілерді құру және осы қатынастарды сақтау. DR таңдау қажет. Қосылу (*, g) - G тобына қосылу туралы өтініш. Кімнің көзіне қарамастан. RP-ге кетеді. Анықтамамен бірге RPT ағашы тұрғызылған. Қосылу (S, G) - көздің нақты қосылуы. Бұл G тобына бір топқа қосылу туралы сұраныс, S. белгілі көзі бар, S. Set - S. көмегімен жіберілген, SPT The ағаш салынған.

Prune (*, g)

- G ағашынан ажырату туралы сұрау, ол үшін қандай көздер болды. RP-ге кетеді. Сондықтан Филиал СПТ жабылған.

  • Prune (s, g)
  • - g ағашынан өшіруді сұрау, оның түбірі S. S. S. жүйесі көзге жіберіледі. Сондықтан SPT филиалы кесілген.
  • - Қандай, RP-ге RP-ге жіберілген арнайы хабарлама, SPT көзінен RP-ге дейін салынғанға дейін. Юникаст арқылы FHR-дан RP-ге жіберіледі.

Тіркелу аялдамасы.

- Ол rp-ге rp-ге rp-пен, мультикастты трафикті жіберуді тоқтату, тіркеуге тапсырыс беру арқылы жіберіледі.

- BSR механизмі пакеттері BSR рөліне жол жоспарлағышты таңдауға мүмкіндік беретін, сонымен қатар қолданыстағы RP және топтар туралы ақпаратты жіберуге мүмкіндік береді.

Растау.

- екі маршрутизатор бір сегментке өткендей, PIM экспедиторын таңдаңыз.

Кандидат-rp-жарнамасы

- RP компаниясы қандай топтарға қызмет ететін хабарлама жібереді. 

Rp қол жетімді

- RP-тен алған хабарлама, ол ол барлығын оның қол жетімділігі туралы хабарлайды.

  • * Пимдегі хабарламалардың басқа түрлері бар, бірақ бұл қазірдің өзінде мәліметтер *
  • Енді хаттаманың егжей-тегжейіне тез арада реферат жасамайық? Содан кейін оның күрделілігі айқын болады.
  • 1) RP анықтамасы, 2) RP-де дереккөзді тіркеу, 3) SPT ағашын ауыстыру.

Көптеген хаттама: Көптеген жазбалар, «Multicast маршруттау» кестесіндегі көптеген жазбалар. Бір нәрсе жасауға бола ма? Бүгінгі таңда Pim жеңілдікпен қарама-қарсы екіге қарама-қарсы тәсілдер бар: SSM және BESRIN PIM. SSM.

Біз сипаттағанның бәрі әлі де

ASM - кез-келген көздің мультикасты

. Топтарға клиенттер бей-жай қарамайды, ол топқа трафиктің қайнар көзі - бастысы, олар оны алады. Естегенде, IGmpv2 есебін топқа қосу сұралады.

SSM - Мультичастиканың бастапқы көзі - балама тәсіл. Бұл жағдайда клиенттер қосылған кезде топ пен көзді көрсетеді. Ол не береді? Енді: RP-дан толығымен арылту мүмкіндігі. LHR бастапқы мекенжайды бірден біледі - RP-ге қосылудың қажеті жоқ, маршрутизатор бірден қосылыстарды (S, G) дереу SPT бағыты бойынша жібере алады.

Сондықтан біз құтыламыз

RP іздеу (жүктеу және авто-rp протоколдары),

Multicast-та дереккөзді тіркеу (және бұл тым көп уақыт, өткізу қабілеттілігі мен туннельді қосарлы қолдану) SPT-ге ауысу. Себебі RP жоқ, содан кейін ешқандай RPT жоқ, сәйкесінше, бір маршрутизаторда ешқандай жазба болмайды (*, g) - тек (s, g).

SSM-мен шешілетін тағы бір мәселе - бұл бірнеше дереккөздердің болуы. ASM-де Multicast тобының мекен-жайы бірегей және оған бір ғана ақпарат таратылатыны ұсынылады, өйткені RPT ағашында бірнеше ағындар біршама, ал клиент түрлі көздерден екі ағынды алады, мүмкін, бөлшектелмейді оларға. СММ-де, әр түрлі көздерден трафик өздігінен, әрқайсысы өздігінен таратылады, олардың әрқайсысы өздігінен таратылады, және бұл қазірдің өзінде проблема болып табылады және бұл артықшылығы - бірнеше серверлерді бір уақытта таратуға болады. Егер кенеттен клиент негізгі көзден шығындарды шеше бастаса, ол резервтік көшірмені ауыстыра алады, оны қалпына келтіре алмайды, сонымен қатар екі ағынды қабылдады. Сонымен қатар, қосылатын мультиикастты бағыттаумен шабуылдың ықтимал векторы оның қайнар көзінің қаскүнемін қосу және желіні шамадан тыс жүктейтін көп мөлшерде мультикасттың көп мөлшерін құру болып табылады. СММ-де бұл іс жүзінде алынып тасталады.

SSM үшін IP мекенжайларының арнайы спектрі бөлектелген: 232.0.0.0.8. SSM қолдау үшін маршрутизаторларда PIM SSM режимі қосылған. Маршрутизатор (Config) # IP PIM SSM

IGMPV3 және MLDV2 таза түрде SSM қолдауы.

Оларды пайдаланған кезде клиент мүмкін

Дереккөздерді көрсетпестен жай топқа қосылуды сұраңыз. Яғни, ол әдеттегі ASM ретінде жұмыс істейді.

Белгілі бір көзі бар топқа қосылуды сұраңыз. Дереккөздерді бірнеше рет көрсетуге болады - ағаштардың алдында ағаш салынады. Топтық қосылымды сұраңыз және клиент көздерінің тізімін көрсетіңіз қаламадым трафик алады

IGMPV1 / v2, mldv1 SSM-ді қолдамайды, бірақ мұндай нәрсе бар Белгілі бір көзі бар топқа қосылуды сұраңыз. Дереккөздерді бірнеше рет көрсетуге болады - ағаштардың алдында ағаш салынады. SSM картографиясы. . Клиенттің жанында, маршрутизатор (LHR) Әр топ бастапқы мекен-жайға (немесе бірнеше) сәйкес орналастырылған. Сондықтан, егер клиенттер болса, егер олар үшін IGMPV3 / MLDV2 қолдамаса, SPT, сонымен қатар, олар үшін де, бастапқы мекен-жайы әлі де белгілі болғандықтан, олар үшін салынады. SSM картасын LHR-де және DNS серверіне сілтеме жасау арқылы орнатуға болады. SSM проблемасы, клиенттер бастапқы мекенжайларды алдын-ала білуі керек - олар оларға хабарланбайды. Сондықтан, SSM осы жағдайларда жақсы, егер желінің белгілі бір көздер жиынтығы болса, олардың мекен-жайы білетін және өзгермейді. Және клиенттердің терминалдары немесе қосымшалары оларға байланысты. Басқаша айтқанда, IPTV - SSM енгізу үшін өте қолайлы орта. Ол ұғымды жақсы сипаттайды Бір-бірден көп

- Бір көзі, көптеген алушылар.

Бинир пим.

Ал егер желі көздерінде өздігінен көрінуі мүмкін болса, сол топтарда таратылуы керек болса, сол топтарда тарату, таратуды тез тоқтатыңыз және жоғалады?

Мысалы, бұл жағдай желілік ойындарда немесе деректер орталығында мүмкін, мұнда мәліметтер әр түрлі серверлер арасында көшіріледі. Бұл тұжырымдама Көп-көп - Көптеген дереккөздер, көптеген клиенттер.

Кәдімгі пимдер см қалай қарайды?

Intert Pim SSM барлық сәйкес келмейтіні анық?

Сіз әлі де хаос басталады деп ойлайсыз: хаттаманың таймерлеріне байланысты бірнеше минут ішінде көздерді, қалпына келтіретін көздерді, қайта құру (S, g) бірнеше минут ішінде өмір сүреді.

  • Екі бағытты пим кірістер болып табылады ( Екі бағыттағы пим, BESIR PIM
  • ). SSM-ге қарағанда, оны SPT және жазбалар толығымен бас тартты (s, g) - тек RP-де тамырмен қалады. Егер әдеттегі пимде болса, ағаш бір жақты, трафик әрқашан SPT және RP-ден RP-ден бастап, RPT-ден бастап - нақты дивизия, онда тұтынушылар, содан кейін қайнар көзі, содан кейін бастапқы трафиктен екі бағыттағы RP, сонымен қатар ортақ ағашты - сол сызықта, оған сәйкес, трафик клиенттерге ағып кетеді.
  • Бұл сізге RP-де дереккөзді тіркеуден бас тартуға мүмкіндік береді, әрине, ешқандай дабыл және күйге келтірілмейді. SPT ағаштары мүлдем жоқ болғандықтан, содан кейін SPT ауыстырылды да болмайды. Мысалға: Белгілі бір көзі бар топқа қосылуды сұраңыз. Дереккөздерді бірнеше рет көрсетуге болады - ағаштардың алдында ағаш салынады. Көзі1
  • 224.2.2.4 трафик тобын желіге бір уақытта жібере бастады Source2. . Олардың ағындары RP-ге құйылды. Жақын жерде болып жатқан кейбір клиенттер бірден көлік қозғалысын ала бастады, өйткені маршрутизаторларда кіреберіс бар (*, g) (клиенттер бар). Тағы бір бөлігі RP-ден ортақ ағашта трафикті алады. Олар екі көзден трафикті бір уақытта алады. Яғни, егер сіз мысалға алыпсатарлық желілік ойын алсаңыз, . Клиенттің жанында, маршрутизатор (LHR) Әр топ бастапқы мекен-жайға (немесе бірнеше) сәйкес орналастырылған. Сондықтан, егер клиенттер болса, егер олар үшін IGMPV3 / MLDV2 қолдамаса, SPT, сонымен қатар, олар үшін де, бастапқы мекен-жайы әлі де белгілі болғандықтан, олар үшін салынады. Бұл атқыштағы алғашқы атқыш, ол ату және

Source2.

- Бұл басқа ойыншы, ол жаққа қадам жасады. Осы екі оқиға туралы ақпарат бүкіл желі бойынша таралады. ЖӘНЕ

барлығы

Мысал: IPTV.

Басқа ойыншы (

.

Алушы

) Осы екі оқиға туралы білуім керек.

Есіңізде болса, онда біз RP-дегі дереккөзді тіркеу процесі қажет екенін түсіндіргенге дейін, сондықтан трафикті клиенттер болмаған кезде алып жатыр, бұл, яғни RP одан бас тартты. Неліктен біз қазір бұл проблема туралы ойламаймыз? Себебі, қарапайым: BISIR PIM, олар көптеген көздер бар жағдайлар үшін, бірақ олар үнемі таратпайды, бірақ мезгіл-мезгіл, салыстырмалы түрде аз мәліметтер. Яғни, көзден-р.П-ға дейін арна суды тастамайды.

R5 және R7 арасында жоғарыдағы суретте R5 және R7 арасында тура сызық бар, бірақ ол RP-тен әлдеқайда қысқа, бірақ ол қолданылмаған, өйткені қосылу маршрутизация кестесіне сәйкес RP-ге ауысады, оның ішінде бұл жол оңтайлы емес.

Бұл өте қарапайым болып көрінеді - сізге RP бағыты мен барлығын және барлығын жіберу керек, бірақ бәрібір, барлық бұзылған - RPF. RPT ағашында трафикті басқаша емес, трафик қажет. Біз кез-келген жерден келеміз. Біз, әрине, әрине, RPF-ті ала алмаймыз - бұл ілмектердің пайда болуына жол бермейтін жалғыз механизм.

Сондықтан, тұжырымдама Bestir Pim-ке енгізілді

Df - экспедитор

. Әр желілік сегментте бір маршрутизаторда RP-ге дейін роутер жақсы, әр жолда осы рөлге таңдалады.

Бұл, соның ішінде бұл клиенттер тікелей қосылған желілерде жасалады. Bidir pim df автоматты түрде др.

Мұнай тізімі тек маршрутизатор DF рөлі үшін таңдалған сол интерфейстерден құрылады.

Ережелер айқын:

Егер PIM қосылыңыз / қалдыру Сұраныс осы сегментте DF болса, ол стандартты ережелерге сәйкес RP-ге жіберіледі.

Міне, мысалы, R3. Егер қызыл шеңбермен белгіленген DF интерфейстеріне сұраныс келсе, ол оларды RP-ге жібереді (маршруттау кестесіне байланысты R1 немесе R2 арқылы).

Егер PIM қосылса / қалдыру туралы сұраныс DF емес интерфейске келсе, ол еленбейді. R1 және R3 арасындағы клиент IGMP-ланд туралы есепті қосу және жіберу туралы шешім қабылдады делік. R1 Оны DF таңдалған жерде алады (қызыл шеңбермен белгіленген) және біз алдыңғы сценарийге ораламыз. Және r3 DF емес интерфейске сұрау алады. R3 ол осында ең жақсы емес екенін және сұранысты елемейді деп санайды. (Егер Multicast трафигі DF интерфейсіне келсе, ол интерфейстерге мұнай тізімінен және RP-қа жіберіледі. Мысалға,

Трафикті жібере бастады. R4 оны сіздің DF интерфейсіңізге алады және оны басқа DF интерфейсіне алады - клиентке және RP-ге жібереді, өйткені трафик RP-ге және барлық алушыларға таралуы керек. R3 сонымен қатар - мұнай тізіміндегі интерфейстерге бір дананы - яғни RPF тексеруіне байланысты алынып тасталады, ал екіншісі RP-ге дейін алынады.

Егер Multicast трафигі DF емес интерфейске келсе, оны мұнай тізімінен интерфейстерге жіберу керек, бірақ

болмайды

RP-ге орналастырылған.

Мысалыға,

Тарата бастады, трафик RP-ге жетті және RPT-ге тарала бастады. R3 R1-ден трафик алады және ол оны R2-ге жібермейді - тек R4 және R5-де төмен түспейді.

Осылайша, DF «Multicast пакетінің бір данасы» және цикл түзілуінің тек бір данасы RP-де алынып тасталғанына кепілдік беріледі, ақыр соңында жіберіледі. Сонымен қатар, көзі орналасқан жалпы ағаш, әрине, RP енгізбес бұрын осы трафикті алады. RP, қарапайым ережелерге сәйкес трафик барлық мұнай порттарына, сонымен қатар трафик келген жерде жіберіледі.

Айтпақшы, растау хабарламалары қажет емес, өйткені DF әр сегментте таңдалады. Доктордан айырмашылығы, ол тек RP-ге қосылу үшін жауап бермейді, сонымен бірге трафикті сегментке жіберуге ғана емес, сонымен қатар, екі маршрутизатордың бір қалыпқа жіберілген кездегі жағдайы бар, жоққа шығарылған.

Бәлкім, сіз екі бағытты пим туралы айтуыңыз керек, бұл RP ерекшеліктері. Егер PIM SM RP белгілі бір функцияны - дереккөзді тіркеген болса, онда BEDIR PIM RP-де трафик бір жағынан ұмтылатын және басқа жағынан клиенттерден қосылатын белгілі бір шартты нүкте. Ешкім Decaplation-ді жасауы керек, SPT ағашының құрылысын сұрамауы керек. Тек кейбір маршрутизаторда кенеттен көздерден трафик ортақ ағашқа беріле бастайды. Мен неге «кейбіреулер» деп отырмын? Бұл нақты маршрутизаторда, мысалы, RP мекенжайы емес, белгілі бір маршрутизаторда, өйткені RP мекен-жайы емес, өйткені RP мекен-жайы емес, ең бастысы, ол бағытталған (мұндай RP фантом RP деп аталады)

Пимге қатысты барлық терминдерді глоссарийден табуға болады Арналардағы мультикаст Сонымен, ұйқының, өңдеудің, сынақтардың жетіспеушілігі бар ұзақ еңбек аптасының артында - сіз мультикаст және қанағаттанған клиенттер, директор және сату бөлімі сәтті жүзеге асырдыңыз. Жұма - жаратылысты елемеу және жағымды болу үшін ең жаман күн емес. .

Жұма - жаратылысты елемеу және жағымды болу үшін ең жаман күн емес.

Бірақ сіздің күндізгі арманыңыз кенеттен техникалық қолдауды, содан кейін тағы бір, бірақ ештеңе істемейді - ештеңе істемейді, бәрі бұзылды. Тексеру - шығындар, үзілістер. Барлығы бірнеше қосқыштардың бір сегментінде жиналады.

SSH келісілмеген, процессорды тексерді, интерфейстер мен шаштың соңында, бір Вланның барлық интерфейстерінде 100% -ға жуық жүктеуді тексерді. Цикл! Бірақ егер ешқандай жұмыс болмаған болса, қайдан пайда болады? Тексерудің 10 минутын тексеріп, сіз ядродағы астық интерфейсінде сіз көптеген кіріс трафигі бар екенін және тұтынушыларға барлық түсушілерге баратындығын байқадыңыз. Цикл үшін ол тән, бірақ қандай да бір жолмен күдікті: мультикаст ұсынған, коммутация бойынша ешқандай жұмыс жасамады және секіру тек бір бағытта ғана емес.

Маршрутизатордағы мультикаст топтарының тізімін тексерді және барлық мүмкін арналарға жазылым бар, ал бір портта барлығы осы сегменттің барлығына арналған.

Мұқият тергеу көрсеткендей, клиенттің компьютері жұқтырады және IGMP сұрауын қатардағы барлық мультикрафиялық мекен-жайларға жібереді.

Пакеттің шығындары басталды, өйткені коммутаторлар өздерінен өте көп трафиктен өтуі керек еді. Бұл интерфейс буферлерінің толып кетуіне себеп болды.

Негізгі сұрақ: неге бір клиенттің трафигі барлық порттарға көшіріле бастады?

Мұның себебі MURCAST MAC мекен-жайларының сипатында жатыр. Бұл факт, Multicast IP мекенжайларының кеңістігі Multicast Mac мекенжайларының кеңістігінде арнайы көрсетілген. Ал сноуборд, олар ешқашан MAC мекен-жайы ретінде пайдаланылмайды, сондықтан оны коммутатормен зерттелмейді және MAC мекен-жай кестесінде тізімделеді. Мақсаттары бар, оның тағайындалған мекен-жайы зерттелмеген бе? Ол оларды барлық порттарға жібереді. Не болып қалды.

Бұл әдепкі әрекет.

Multicast Mac мекенжайлары Сонымен, мұндай пакеттердің Ethernet тақырыбына қандай MAC мекен-жайлары ауыстырылады? Эфир? Емес. MAC мекен-жайларының арнайы диапазоны бар, онда Multicast IP мекенжайлары көрсетілген. Тіркеу Бұл арнайы мекен-жайлар басталады:

0x01005e және келесі 25-ші бит 0 болуы керек

Неге жауап беруге тырысыңыз

). Қалған 23 бит (барлығын Mac-mail 48-де еске салу) IP мекен-жайынан аударылған.

Бұл жерде кейбіреулер өте маңызды емес, бірақ проблема. Multicast мекен-жайларының ассортименті 224.0.0.02.4 маскасымен анықталады, яғни алғашқы 4 биттің сақталуы: 1110, ал қалған 28 бит өзгеруі мүмкін. Яғни, бізде 2 ^ 28 мультикальды IP мекенжайлары және бар-жоғы 2 ^ 23 MAC мекен-жайы бар - 1-ден 1-дегі 5 бит жоқ. Сондықтан, соңғы 23 битінде IP мекенжайлары қабылданады, біреуі MAC мекен-жайына ауыстырылады, ал қалған 5-еуі алынып тасталады.

Шын мәнінде, бұл 2 ^ 5 = 32 IP мекенжайлары бір мультикастта MAC мекен-жайында көрсетіледі дегенді білдіреді. Мысалы, 224.0.0.1, 224.0.0.128.0.1, 225.0.0.1, 225.0.0.1 және 239.128.0.1-ге дейін, барлығы бір MAC мекен-жайы бойынша 0100: 0001 мекен-жайы бойынша көрсетіледі.

Егер сіз мысал ретінде ағынды бейне қоқысты алсаңыз, сіз мыналарды көре аласыз:

IP мекенжайы - 224.2.2.4, MAC МАДЕУ: 01: 00: 5E: 02: 02: 02: 04.

Сонымен қатар IPv4-Multicast-қа жатпайтын басқа MAC мекен-жайы бар (нұқыңыз)

). Олардың барлығы, айтпақшы, бірінші октивтің соңғы битінің 1-ге теңдігі сипатталады.

Әрине, бірдей желілік картада да осындай MAC мекен-жайы бойынша теңшеу мүмкін емес, сондықтан ол ешқашан Mac Ethernet-тің бастапқы нүктесінде болмайды және ешқашан Mac мекен-жай кестесіне түспейді. Осылайша мұндай кадрлар кез-келген белгісіз Юнастика ретінде жіберілуі керек

Барлық VLAN порттарына.

Біз бұған дейін қарастырғанымызда, біз барлық мультикрафиялық трафикті ағынды бейнелерден қор бағасының бағасына аудару жеткілікті. Бірақ біз өзіміздің керемет әлемде осындай масқарамен айналысамыз, эфирді хабар тарату ретінде, оны сайлауға жіберілуі мүмкін бе?

Мүлдем жоқ. Әсіресе перфекционистер үшін Ойлап тапқан механизм

IGMP-snooping.

Идея өте қарапайым - ауыстырғыш «тыңдайды» коммутаторы IGMP пакеттері арқылы өтеді.

Әр топ үшін, ол бөлек, ол өсіп келе жатқан және төмен қарай порттардың кестесін жасайды.

Егер IGMP есебі порттан топқа, содан кейін клиент пайда болса, коммутатор оны осы топ үшін Downlink тізіміне қосады.

Егер IGMP сұранысы топқа арналған порттан пайда болса, онда маршрутизатор бар, коммутатор оны өсу тізіміне қосады.

Бұл арна деңгейіндегі «Трафикті» тарату кестесін жасайды. Нәтижесінде, мультикаст ағыны жоғарыдан шыққан кезде, ол тек төмен қарай интерфейстерге көшіріледі. Егер 16 порттың қосқышында тек екі клиент болса, тек олар трафик жеткізіледі. Бұл идеяның данышпасы біз оның табиғаты туралы ойлағанда аяқталады. Механизм 3-деңгейдегі трафикті тыңдауы керек деп болжайды.

Алайда, IGMP-Snooping желінің өзара әрекеттесу қағидаларын елемеу үшін NAL-мен салыстыруға болмайды. Сонымен қатар, ресурстарды үнемдеуден басқа, ол көптеген айқын мүмкіндіктерді жүзеге асырады. Иә, және тұтастай қазіргі әлемде IP ішіне қалай қарау керектігін білетін коммутатор - құбылыс ерекше емес. ===================== Тапсырма нөмірі 3.

Сервер 172.16.0.5 Көптұрсо трафигі топтарға 239.1.1.1, 239.2.2.2.2.2 және 239.03.3 таратады.

Желіні келесідей теңшеңіз:

- Тапсырыс беруші 1-топқа қосыла алмады 239.2.2.2.2.2. Бірақ сонымен бірге ол 239.0.0.x тобына қосыла алды.

- 2-ші тапсырыс беруші 239.1.1.1 тобына қосыла алмады. Бірақ сонымен бірге ол 239.0.0.x тобына қосыла алды.

Тапсырма туралы толық ақпарат.

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

IGMP SNOOPING Прокси.

.

Жауап оқу құралында IGMP-дің SNOOPING барлық клиенттік порттарды қалай білуі мүмкін, бұл біз жоғарыда айтылғандай IGMP сұранысына жауап беретінін ескере отырып, тек бір ғана ең жылдам клиент жауап береді. Және өте қарапайым: IGMP Snooping есепке клиенттер арасында өтуге рұқсат бермейді. Олар тек өсіп келе жатқан порттарға маршрутизаторларға жіберіледі. Осы топтың басқа алушылардың есебін көрмей, клиент осы сұрауда көрсетілген Max жауап беру уақыты кезінде сұранысқа жауап беруге міндетті.

Нәтижесінде, желідегі 1000 түйінге бір IGMP сұранысына 10 секундтан (әдеттегі жауап уақытының әдеттегі мәні) маршрутизаторға 1000 есеп келеді. Ол оған әр топ үшін жеткілікті болар еді.

Және бұл әр минут сайын болады.

Бұл жағдайда сіз IGMP сұрауларының прокси-кодын теңшей аласыз. Содан кейін коммутатор өтетін бумаларды «тыңдайды», ол оларды ұстап алады.

IGMP-Snooping жұмыс ережелері әртүрлі өндірушілер үшін әртүрлі болуы мүмкін. Сондықтан, оларды тұжырымдаманы қарастырыңыз:

1) Егер коммутатор Топқа бірінші есепті жіберсе, ол маршрутизаторға жіберіледі, ал интерфейс төмен қаратылады. Егер мұндай топ қазірдің өзінде болса, интерфейс тек кему тізіміне қосылады және есеп жойылады.

2) Егер соңғы демалыс ауысымға келеді, содан кейін басқа тұтынушылар жоқ, бұл демалыс маршрутизаторға жіберіледі, ал интерфейс DownLink тізімінен жойылады. Әйтпесе, интерфейс жай жойылады, кету жойылады.

3) Егер IGMP сұранысы маршрутизатордан шыққан болса, коммутатор оны ұстап алады, оны қазір алушылары бар барлық топтар үшін IGMP есеп жауабына жібереді.

Енді біз серверді береміз. Жоғарыда айтқанымыздай, ол PIM, RP, IGMP туралы алаңдамайды - ол жай таратады. Және R1 бұл ағынды алады. Оның міндеті - RP-ге мультикаст жіберу. Содан кейін, параметрлерге және өндірушіге байланысты немесе бірдей сұрау клиенттің барлық порттарына жіберіледі немесе коммутатор маршрутизатордан сұранысты және өзі сұраныстарды барлық алушыларды мезгіл-мезгіл саясаткер ретінде басқарады. Бұл желідегі қажетсіз қызмет трафигі мен маршрутизатордағы жүктеме үлесін азайтады. Multicast VLAN репликациясы Клиент сонымен қатар VLC ойнатқышы арқылы 224.2.2.4 тобын сұрайды. Қысқартылған IGMPv2 есебі қалаған топтың мекен-жайына өтеді, ал параллель ол қаптамада көрсетілген. Бұл хабарламалар тек сегментінде өмір сүруі керек және бәрібір бағытталмауы керек, сондықтан маршрутизаторлар бойынша, демек, оларда олар 1 ТТЛ бар. Мвр

. Бұл VLAN-Per-vLan-vlan-provider-дің тетігі

, мысалы.

Міне, MVR өте маңызды желінің типтік мысалы:

Әр түрлі VLAN-дағы 5 клиент және барлығы бір топтың мультикасттық трафигін алғысы келеді 224.2.2.4. Бұл жағдайда тұтынушылар бір-бірінен оқшауланған болуы керек.

IGMP-Snooping, әрине, Вландар есепке алады. Егер әртүрлі VLAN-дағы бес клиент бір топқа тапсырыс берсе, ол бес түрлі үстел болады. Тиісінше, топқа маршрутизаторға қосылуға арналған 5 сұраныс бар. Және маршрутизатордағы осы бесеуден әрбір саблыаралық мұнайға бөлек қосылады. Яғни, 224.2.2.4 тобына 1 ағынды алған соң, ол барлығы бір сегментке кіргеніне қарамастан, 5 дананы жібереді.

Бұл мәселені шешу үшін «Vlan» мультикастының репликация тетігі жасалды.

Қосымша VLAN енгізіледі -

.

Multicast VLAN.

- Онда, сәйкесінше, мультикасттың ағымы беріледі. Ол «талғаммен» тікелей ауыстырылды, онда ол одан трафик барлық клиенттердің интерфейстеріне көшіріледі, олар осы трафикті алғысы келетін барлық интерфейстерге көшіріледі - бұл репликация.

.

Multicast VLAN-дан шағылыстырудың орындалуына байланысты жасалуы мүмкін

Пайдаланушы-VLAN.

немесе белгілі бір физикалық интерфейстерде.

Ал IGMP хабарламалары туралы не деуге болады? Маршрутизатордан сұраным, әрине, «Multicast VLAN» арқылы келеді. Коммутатор оларды клиенттік порттарға жібереді. Клиенттен есеп немесе шығу клиенттен шыққан кезде, коммутатор ол тұрған жерден (VLAN, интерфейс) тексеріледі, қажет болған жағдайда, «Multicast VLAN» -ге қайта бағытталады.

Осылайша, қарапайым трафик оқшауланған және әлі де Vlan пайдаланушыдағы маршрутизаторға барады. Multicast трафигі және IGMP пакеттері Multicast VLAN-ге жіберіледі.

.

Cisco MVR және IGMP-Snooping өз бетінше конфигурацияланған. Яғни, сіз біреуін өшіре аласыз, ал екіншісі жұмыс істейді. Жалпы, МВР ИГМП-США-ға негізделген және MVR операциялары үшін басқа өндірушілердің қосқыштары IGMP-Snooping-ді міндетті түрде қосуы мүмкін.

RPF тексеру.

Сонымен қатар, IGMP-Snooping коммутаторларда трафикті сүзуді жүргізуге, пайдаланушыға қол жетімді топтардың санын, IGMP сұрауларының санын, өсу порттарының статикалық параметрін, кез-келген топқа тұрақты қосу (осы сценарий) вызшақ

), IGMPV2 және т.б. үшін қосымша сұрау жіберу арқылы топологияның өзгеруіне жылдам әрекет ету

  • IGMP-Snooping туралы әңгімені аяқтау, мен қайталағым келеді - бұл қосымша функционалдылық - бәрі онсыз жұмыс істейді. Бірақ бұл желіні болжауға болады, және инженердің өмірі тыныш.
  • Алайда, IGMP-дің барлық артықшылықтарын өздеріне орауға болады. Осындай осындай істің біріне сілтеме бойынша оқи алады.
  • Айтпақшы, Cisco-да CGMP протоколы бар

- Коммутатордың қағидаларын бұзбайтын IGMP аналогы, бірақ ол дұрыс және бұл кең таралған деп айтпайды.

Сонымен, біздің қажырлы оқырманым, біз мәселенің соңына жақындап, ақыры IPTV қызметінің клиенттің қалай жүзеге асырылуы мүмкін екенін көрсеткім келеді.

Осы мақалада біз бірнеше рет жүгінгеніміз оңай, бұл желіден мультикастты ағынға ие бола алатын ойыншыны іске қосыңыз. Сіз топтың IP мекенжайын қолмен орнатып, бейнені пайдалана аласыз.

Провайдерлер жиі қолданатын бағдарламаның тағы бір нұсқасы - бұл арнайы қолданба, әдетте, арнайы қолданба, әдетте, провайдер желісінде қолданылатын арналар жиынтығы тігіледі. Бір нәрсені қолмен орнатудың қажеті жоқ - сіз арналарды түймелермен ауыстыруыңыз керек.

Осы екі тәсілдер де ағынды бейнені тек компьютерде көруге мүмкіндік береді.

Үшінші нұсқа теледидарды пайдалануға мүмкіндік береді, ереже ретінде кез келген. Ол үшін клиенттің үйі теледидарда орнатылған топырақ деп аталатын (STB) - теледидарда орнатылған қорапты қояды. Бұл абоненттік желіге кіретін және трафиктің ортақ пайдаланылатын пюейтик: Кәдімгі Unicnter, бұл клиенттердің Интернетке кіре алатындай етіп, ол Ethernet немесе WiFi-ге береді, сондықтан мультикаст, ал мультикаст РГБ, антенна ПТ.).

Айтпақшы, сіз, айтсақ, сіз провайдер теледидарды қосуға арналған консоллды ұсынатын жарнаманы көре аласыз - бұл өте ЕДБ

4-тапсырма.

Ақыры, емес, мультикастың емес тапсырмасы (авторлар біз емес, жауаптардағы түпнұсқа).

  1. Қарапайым схема:
  2. Бір жағынан, бастапқы сервер, доғаны бар - трафик алуға дайын компьютер.

Сіз Multicast Stream мекен-жайыңызды өзіңіз орната аласыз.

Тиісінше, екі сұрақ:

  • Компьютер ағын ала алатындай етіп не істеу керек және Multicast маршрутизациясына жүгінбейді?
  • Сіз мультикасттың не екенін білмейсіз және оны теңшей алмайсыз, оны серверден компьютерге қалай тасымалдауға болады?
  • Тапсырма іздеу жүйесінде оңай ізделеді, бірақ оны өзіңіз шешуге тырысыңыз.
  • Тапсырма туралы толық ақпарат.
  • =====================
  • Мақаладағы тиімсіз, мультикаст трафигінің көлденең бағыты (MSDP)
  • , Mbgp.

, Bgmp

), RP аралығындағы жүктемелерді теңестіру (ANDCAT RP)

, меншікті хаттамалар. Бірақ, менің ойымша, бұл мақаланы бастауға тура келеді, қалғандармен күресу қиын болмайды.

MultIrast-ке қатысты барлық терминдер, сіз телекоммуникация глоссарийінен таба аласыз

Мақалаларды дайындауға көмек үшін рахмет jdima

Техникалық қолдау үшін Наташа Самоойленкоға рахмет CDPV сызылған Нина Долгопольов

- керемет суретші және басқа жоба.

RPF тексеру.

SDSM мақалалар пулында әлі де қызықты, сондықтан әлі күнге дейін циклді одан сайын қызарудың қажеті жоқ, сондықтан сіз ұзақ уақытқа дейін циклді көмудің қажеті жоқ - әр жаңа мақаламен күрделілік едәуір артады. Алда барлық дерлік MPLS, IPv6, QOS және желілік дизайн.

  1. Сіз қазірдің өзінде байқағаныңыз, мүмкін, LinkMeup-тің жаңа жобасы бар - LookMueup глоссарийі (Иә, біз қиялдан шықтық). Бұл глоссарий қарым-қатынас саласындағы терминдердің толық анықтамалығына айналады деп сенеміз, сондықтан біз оны толтыруға кез-келген көмекке қуаныштымыз. Бізге [email protected] жазыңыз
  2. Бізбен бірге болыңыздар
  3. IGMP SNOOPING: Маршрутта не деген не және сізге не үшін керек?
  4. Егер сіз маршрутизатордағы IGMP Snooping нұсқасы туралы сұрақ туындаса және сізге бұл параметр не үшін қажет болса, сіз дұрыс мақаланы таптыңыз. Интернеттегі ақпараттың көп бөлігі әдеттегі пайдаланушыны түсіну үшін күрделі, ал егер сіз белгілі бір тапсырманы шешкіңіз келсе, бұл шарттар мүлдем қажет емес.
  5. Проблемалар туралы біршама уақыт, себебі сіз IGMP-ге қызығушылық танытуыңыз мүмкін:

Сіз желілік ойындар ойнайсыз;

IPTV Rostelecom Интернет-теледидар функциясын немесе кез-келген басқа провайдерді қолданыңыз;

Желілік жүйеде қол қойылған: бейне конференциялар, онлайн оқыту немесе тіпті пошта жөнелтімдері.

Сонымен бірге сіз маршрутизаторға қосылған барлық құрылғыларда жылдамдықты едәуір қысқарттыңыз. Мысалы, сіз теледидардан IPTV-ді қарап отырсыз, бірақ сіз телефоннан Интернетті «ұялшақ» немесе одан да нашарлай бастайсыз. Тағы бір мәселе - мүмкін - IPTV, жоғарыда аталған желілік ойындар немесе қызметтер мүлдем басталмайды және жұмыс істемейді. Барлық осы жағдайларда шешім IGMP SNOOPING күйіне келтіруге көмектеседі.

IGMP дегеніміз не және ол не үшін қажет

Деректер желі арқылы берілсе - ғаламдық Интернетке немесе провайдерде немесе құрылғылардан немесе құрылғылардан бұл нақты ережелерде болады: Хаттамалар. Әрбір протокол Zeros мен бірліктерді қалай тану, оларды деректер пакеттерінде қалай жинауға болатындығын анықтайды, экранда экранда қабылдау және жиналған кезде оларды қалай жинауға болады. Жалпы алғанда, барлығы жеті деңгей - сіздің браузеріңізге электр сигналдарынан.

Интернет-топты басқару протоколы, олардың алғашқы хаттары бойынша қысқартылған әріптер пайда болады - арналар деңгейіндегі осы хаттамалардың бірі. Егер сіз жоғарыда сипатталған «проблемалар» пайда болса, сіз оның бар екендігі туралы білмейсіз. Атаудан көрінетіндей, бұл хабар тарату топтарын басқаруға арналған протокол.

Яғни, IPTV Интернет ТВ сигналы сізге провайдерден маршрутизаторға келген кезде, оны барлық құрылғыларға тарата бастайды. Бұл ыңғайлы, смартфон мен теледидарда бірдей берілістерді көру ыңғайлы. Бірақ сонымен бірге кез-келген басқа құрылғы - мысалы, сіздің компьютеріңіз сигнал қажет болса, «сұралмайды».

Сондықтан ол әлі де оны алады, бұл Интернеттің жылдамдығын азайтады және өз ресурстарын жұмсайды.

Snooping - бұл маршрутизаторға қандай құрылғыларға онлайн ойыннан, теледидардан немесе арнайы қызметтен деректердің ағымы қажет екенін білуге ​​көмектесетін функция. Жай, бұл сіздің желіңіздегі трафикті оңтайландыру және оның қауіпсіздігін жақсарту. Ол автоматты түрде жұмыс істеуі керек, бірақ кейде оны қолмен конфигурациялау керек. IGMP маршрутизаторда.

IGMP көріністері Осы протоколдың маршрутизаторының қолдауы сіздің IPTV және басқа қызметтерден сигнал алғаныңыз жоқ екендігіңізді білдіреді. Бірақ маршрутизатор немесе модем үлкен болса, ол таратылым деректерді беруді қабылдамауы мүмкін немесе ол тек қуат жетіспейді және ол жетпейді және ол «іліп тұр». Бірақ бәрі тәртіпте болған кезде IGMP Snooping әр түрлі болуы мүмкін: Пассивті. Бұл негізгі технологияларды қолдау, жалпы бақылау және тарату. Барлығы жұмыс істейді, маршрутизатордағы жүктеме минималды. Дегенмен, оның ішіндегі құрылғыларда жүктеме артады. Белсенді. Мұндай протокол желіні барынша арттырады. Ол маршрутизаторға «қосымша» сұраныстарды ұсынады, ол қажет емес, деректерді беру ресурстарын босату. Дегенмен, ол процессордағы және құрылғыны жадтағы жүктемені арттырады. Орташа және жоғары баға сегменттерінің құрылғылары проблемасыз. Құрылғылар үшін ол деректердің мөлшеріне байланысты. .

Маршрутизаторда функцияны қалай орнатуға болады IGMP маршрутизатордағы бөлшектеу, бұл параметр дегеніміз не - IPTV мысалында. Әдетте бәрі автоматты түрде қосылады. Бірақ егер сіз осы мақаланы оқыған болсаңыз, бірдеңе дұрыс болмады. Сондықтан келесі әрекеттерді орындаңыз: Маршрутизатордың веб-интерфейсіне өтіңіз: 192.168.1.1 немесе 192.168.0.1 мекен-жайлар тақтасында шолғышты енгізіңіз немесе төменгі жапсырмада көрсетілген мекенжай. Пайдаланушы аты мен парольді енгізіңіз - Әдетте, егер сіз «admin» логині және «admin» паролі, егер сіз қолмен өзгертілмеген болсаңыз. Немесе маршрутизатордағы бірдей жапсырманы тексеріңіз. .

«Желіге», «Желі параметрлері» немесе ұқсас. Асусқа ол «жергілікті желі» деп аталады. Сіз «IPTV» қойындысын табу керек. «Прокси» опциясы хабар таратуды қамтиды, IPTV функциясын іс жүзінде іске қосады. Бұл, ол роутердегі IGMP проксиі. Бұны қосыңызшы. Барлық модельдерде IGMP Snooping элементі бола бермейді, бірақ егер ол болса, оны қосыңыз. Суреттеу барлық құрылғылардың жұмысын жақсартады. .

«Қолдану» түймесін басыңыз. Бәрі дайын.

Мүмкін проблемалар Хабар тарату қашан жұмыс істемеген кезде проблема мүмкін. Бұл брандмауэрмен байланысты болуы мүмкін. Оны бірнеше минут ажыратыңыз. Егер мәселе шешілмесе, қосылып, параметрлерде қосылып, Интернет-теледидарға, онлайн ойындарға немесе басқа қызметке рұқсат етіңіз. Бейне. Мысал: Кездейкім, DNS .

Егер IPTV бөлек жабдықты пайдаланса (сізге теледидар префиксі қажет, бұл сізге бір сөйлесу тақырыбы), содан кейін маршрутизатор параметрлерінде «Көпір» опциясын шешу қажет болуы мүмкін. Оны «WAN WAN PORT» немесе «Желілік-көпір» деп атауға болады - бұл құрылғыға байланысты.

Соңында, егер сигнал «баяулайды», содан кейін құрылғы жүктелген шығар. Басқа құрылғылардың жұмысын шектеуі керек немесе оларды өшіріңіз. Егер ештеңе көмектеспесе, маршрутизаторды одан да күшті етіп өзгертуге тура келеді.

Осы мақалада мен маршрутизаторда IGMP-дің ең таза тілін түсіндіруге тырыстым. Бұл ақпарат сізге пайдалы болады деп сенемін және сіз туындаған мәселелерді шешесіз. Енді сіздің деректеріңіз оңтайлы және дұрыс түрлендіріліп, оған барлық құрылғыларды шамадан тыс жүктеу үшін желідегі шабуыл нәтиже бермейді. Дереккөз: https://besprovodnik.ru/igmp-snooping-Chto-to-to-rutere/

Микротикке IPTV құру Мысалы, IPTV параметрлері Біз Mikrotik Rb2011UIAS-2HND қабылдадық. Әрине, үй маршрутизаторы емес, әрине, бірақ басқа құрылғылардағы параметрлер әр түрлі болмайды. Конфигурация маршрутизаторын қалпына келтіру. / Және алушылар туралы бізге хабарлайды. Бір клиент-компьютер туралы айтудың қажеті жоқ, жалпы ол, мысалы, басқа пим роутері болуы мүмкін емес. Қай интерфейстердің трафикті өтуі керек. Маршрутизаторды жаңартамыз (IPTV үшін пакет қосу).

IGMP прокси-серверін орнату. Брандмауэрдің ерекшеліктерін қосыңыз. Wi-Fi орнату.

Кіру нүктесінің параметрлерін қалпына келтіріңіз

Бұл элемент міндетті емес. Егер сіз маршрутизаторда IPTV-ді сіз бұрын жасаған жұмыс параметрлерімен теңшесеңіз, төмендегі әрекеттер қажет емес. Ол сонымен қатар резервтік конфигурацияның алдын алмайды. Алайда, кейде IPTV-дің микроттивті болуы кезінде бір нәрсе дұрыс болмай қалса, ең жақсы жол «конфигурацияны қалпына келтіріп, бәрін қайтадан жаса. .

Қорма параметрлерін қалпына келтіру үшін үш жол болуы мүмкін: Бағдарламалық түрде Winbox бағдарламасына өтіп, жүйелік мәзірді ашып, қалпына келтіру конфигурациясын жасаңыз. Механикалық: Mikrotik-тағы Reset түймесін басып, маршрутизатор қайта іске қосқанша күтіңіз. (Көптеген Mikrotik сайтында сіз түймені жабдыққа қосу үшін, қосып, қосқаннан кейін шамамен 10 секунд ұстап тұруға кеңес береміз) / Және алушылар туралы бізге хабарлайды. Бір клиент-компьютер туралы айтудың қажеті жоқ, жалпы ол, мысалы, басқа пим роутері болуы мүмкін емес. Қай интерфейстердің трафикті өтуі керек. Маршрутизатордағы конфигурацияны қалпына келтіріңіз (орнату экранында). Нақты, егер маршрутизаторда сенсорлық экран болса. Routeros жаңарту (IPTV үшін пакет қосу) IPTV үшін қосымша пакетті орнату үшін жаңарту қажет. Біз Микротик сайтына барамыз, біз сіздің модельіңіздің сызығын іздейміз және ол үшін бағдарламалық жасақтама нұсқасын жүктейміз. Сіз негізгі пакеттермен (негізгі) және қосымша (қосымша) бар микробағдарламаны таңдамайтындығыңызға назар аударыңыз.

Ашу

Winbox

Біз маршрутизаторға барамыз (біз MAC мекен-жайына бастапқыда кіруге кеңес береміз, ол одан әрі конфигурация процесін жеңілдетеді). Маршрутизаторда жаңарту үшін мәзірге өтіңіз Файлдар. Оны ашып, оны терезеге апарыңыз Файлдар. Жүктелген файлымыз шақырылмаған архивтен шыққан . Multicast-x.xx-mpsbe.npk

Пакет қосылды және одан кейін біз мәзірге жабдықты қайта жүктейміз

Жүйе.

Қайта жүктеп

Маршрутизатор микробағдарламаны қайта жүктеп, жаңартады. Процесс 5 минутқа созылуы мүмкін.

Бұл уақытта тамақтану өшірілмеуі керек!

Қайта жүктеуден кейін

Жүйе - пакеттер. және модуль пайда болса, қараңыз

Егер біреуі болса, онда сіз бәрін дұрыс жасадыңыз. IGMP прокси-серверін орнату

Mikrotik мәзірінде ашыңыз Бағыттау - IGMP прокси. Бізге жаңа интерфейс қосу керек, сондықтан плюс түймесін басыңыз (экранда көрсетілгендей). Жаңа интерфейсте, далада Интерфейс. Біз Интернет бізбен бірге келетін портты таңдаймыз, біздің жағдайда ол эфир2-шебер болып табылады және кене орнатыңыз Скриншот сияқты:

Өрісте сәл төмен

Балама ішкі желілер.

Балама ішкі желілерді көрсету керек. Ол жаққа не кіру керектігін білмеген болсаңыз, ең көп таралған нұсқаларды қолданып көріңіз: 10.0.0.08.8; 172.16.0.02.12; 192.168.0.05.0.

  • Төтенше жағдайда, сіз нөлдерді қалдыруға болады, бірақ маршрутизатор бүкіл Интернетке қолданылмайтын етіп қалаған ішкі желіні тапқан дұрыс. Өзгерістерді растаңыз, нұқыңыз ЖАРАЙДЫ МА. Басқа интерфейсті жасаңыз, көк плюс түймесін басыңыз, бірақ қазір біз жоқ
  • Төтенше жағдайда, сіз нөлдерді қалдыруға болады, бірақ маршрутизатор бүкіл Интернетке қолданылмайтын етіп қалаған ішкі желіні тапқан дұрыс. ). Керісінше кене қойыңыз ЖАРАЙДЫ МА. Сонымен бірге, біз өзіміздің портын таңдаңыз Асырқын

IPTV. - Яғни, біз оны IPTV-ді көретін құрылғы қосылған. Біздің жағдайда бұл көпір, өйткені стационарлық компьютер оған қосылған. .

Яғни, бірінші жағдайда, біз деректер бар, және қазір - қай жерде пайда болатын портты атап өттік. Біз түймесін басқаннан кейін Параметрлер

Иставим керісінше

Техникалық қолдау үшін Наташа Самоойленкоға рахмет Жылдам.

Лев.

RPF тексеру.

Біз мұны арналар арасында тез ауысу үшін жасаймыз.

Брандмауэрді орнату

Қазіргі уақытта IPTV-ны жіберіп алмайтын брандмауэрді теңшеңіз, өйткені біз жаңа терминал жасаймыз, жаңа терминалды нұқыңыз және терезе ашылады: Енді біз осы консольде бірнеше командаларды орындауымыз керек: / IP Firewall сүзгісі Қабаттама = Қабылдау Chain = «IGMP» рұқсат ету »рұқсат етілген =« IGMP »рұқсат ету = IN интерфейсі = жоқ = Ether2-Master Protocol = IGMP

/ IP Firewall сүзгісі қосу action rection = Қабылдау тізбегі = »IPTV UDP кіріс

/ IP Firewall сүзгісі қосу action action action rection = Қабылдау тізбегі = «IPTV UDP қайта жіберу» = «IPTV UDP қайта бағыттау» Ажыратылған = Dst-Port = 1234 протокол = UDP 1234.

- порт бейненің бейне және IPTV үшін бейресми түрде тіркелген Эфир2-шебер. - Бұл IPTV провайдерден келетін интерфейс.

Келесі қажеттілік Мәзірде

Сор Элементті таңдаңыз Брандмауэр

және қойындыға өтіңіз Сүзгі ережелері.

. Біз ережелерді жоққа шығардық және олар жұмыс істейтіндіктен, олар тыйым салу үшін жоғары болуы керек. Біз оларды тінтуірге апарамыз.

  1. Wi-Fi орнату
  2. Егер сіз таратқан болсаңыз немесе IPTV-ді Wi-Fi арқылы тапсаңыз, қосымша параметрлер қосуыңыз керек. Мұны істеу үшін:
  3. Қосымша режим түймесін басқаннан кейін қосымша параметрлер пайда болады:
  4. Алаңда
  5. WMM қолдауы

Қою

Қосылған -

RPF тексеру.

Wi-Fi арқылы мультимедиялық беріліске жан-жақты қолдау.

Көмекші.

Толық

. Бұл параметр Wi-Fi-да отырған мультикастты клиенттерді жіберуді қамтиды.

Барлығы түймені растайды

IGMP көмегімен клиенттердің соңғы алушылары трафик алғысы келетін ең жақын маршрутизаторларды жеткізеді. Және Pim мультикастты трафикті алушыларға алушыларға маршрутизаторлар арқылы көшіру жолын қалыптастырады. ЖАРАЙДЫ МА.

және бағдарламаларды қараудан ләззат алыңыз

Бұл біздің конфигурацияның орындалуын тексеру үшін ғана қалады. Біз осы IPTV ойыншысы үшін қолдандық, n

Біздің провайдер үшін арналардың арналарын түбегейлі жүктеу

(Волтон Телеком) Ойнатқыш параметрлерінде.

Біздің парағымыз толығымен жұмыс істейтінін көре аламыз. Бақытты қарау!

https://lantorg.com/article/nastrojka-piptv-pikrotik.

Маршрутизаторда IGMP снопинг дегеніміз не? Функция не үшін Неліктен IGMP

Клиент сонымен қатар VLC ойнатқышы арқылы 224.2.2.4 тобын сұрайды. IGMP рөлі өте қарапайым: егер клиенттер болмаса, мультикаст трафигін сегменттің алдына жіберудің қажеті жоқ. Егер клиент пайда болса, ол маршрутизаторларды ИГМП көмегімен трафикті алғысы келетінін хабарлайды. Бәрі қалай болатынын түсіну үшін осы желіні алыңыз: Интернеттегі бірқатар платформалар Multicast әдісін пайдаланушы тобына жіберу үшін көп қолданады. Мұндай технология онлайн ойындар, тікелей эфирлер, қашықтықтан оқыту, тіпті пошта жөнелтімдері үшін қолданылады. Бірақ көпформа әрдайым трафикті релдені сауатты оңтайламайды және пайдаланушының желісін жүктейді, сондықтан IGMP Snooping функциясы бұл мәселені жасады. Функцияның не екенін және оны трафикті оңтайландыруға қалай қосу керектігін анықтайық.

IGMP SNOOPING функциясы деген не және неге керек

Бастау үшін біз IGMP анықтамасын технология принципін түсіну үшін береміз.

Internet Group Management Protocol - топтарда бірнеше құрылғыларды ұйымдастыратын мультикастты желіні басқару протоколы. IGMP мүшелік туралы есеп - ол осы топтың трафигін алғысы келетін «есептер» түйінін.

IGMPv2 есебі қалаған топтың мекен-жайына өтеді, ал параллель ол қаптамада көрсетілген. Бұл хабарламалар тек сегментінде өмір сүруі керек және бәрібір бағытталмауы керек, сондықтан маршрутизаторлар бойынша, демек, оларда олар 1 ТТЛ бар. Ол IP протоколына негізделген және желілік ресурстарды тиімді пайдаланып, Интернетте қолданылады.

IGMP SNOOPING - бұл тұтынушылар топтары мен хост арасындағы мультикастты трафикті бақылау процесі. Snooping мүмкіндігі пайдаланушының сұраныстарын көп мастер-топпен қосып, портты IGMP тарату тізіміне қосады. Мультиррафиканы қолданғаннан кейін, пайдаланушы сұрау және протоколды қалдырады, портты топтық деректер тізімінен жояды.

Осылайша, Snooping қажетсіз деректерді мультикаст арналарына ауыстыруды жояды.

Бұл арна деңгейіндегі мәліметтермен алмасуды тиімдірек етеді және желілік қабаттың қажеттіліктерін ескереді, бұл әсіресе ақпараттық провайдерлер үшін өте маңызды. Пайдаланушылар сонымен қатар оңтайландырылған мазмұнды алады, дегенмен, нәтижесінде желідегі жүктеме артады.

Деректерді бақылау және талдаусыз, нақты IP мекенжайлар түріндегі түпкілікті тұтынушылар олар үшін қосымша пайдасыз ақпаратты «дайджестке» мәжбүр етеді. ол маршрутизаторларда әдепкі бойынша іске қосылады. Fe0 / 0 интерфейсі 224.2.2.2.4 тобына түседі - алынған трафикті жіберу қажет. Әдеттегі ерекше маршруттау кестесімен бірге мультикаст бар: Клиенттердің қол жетімділігі туралы алдымен бірінші жазба айтылған

IGMP Snooping пайдаланушыларды артық трафиктен сақтап қана қоймайды, сонымен қатар ақпарат алмасуды қамтамасыз етеді.

Бақылау режимі DDoS шабуылының алдын алу үшін қосылады, ал DDoS шабуылының желісіне немесе арнайы мекенжайларына әрекеттенбестен Интернет-топты басқару протоколы осал. Іске қосу функциясы IGMP SNOOPING Бақылау және талдау мүмкіндігі басқарылатын желілік қосқыштарда немесе қосқыштарда қол жетімді. Бұл құрылғы желінің арна деңгейінде топтық тарату қағидаларын жүзеге асыруға көмектеседі. .

IGMP SNOOPING іске қосу үшін, оны қосқышта қолмен қосу және конфигурациялау керек.

Басқарылмайтын аналогтар трафикті талдау режиміне қолдау көрсетпейді, өйткені оларды интерфейс арқылы теңшеу мүмкін емес.

Толығырақ IP MrOute көрсетіңіз. Біз кейінірек білеміз. .

Желідегі коммуникаторды пайдаланбас бұрын, соңғы алушы (мысалы, Smart-TV) SNOOPIND режиміне қол жеткізгеніне көз жеткізіңіз.

Әдетте, құрылғыларда «Орнату желісіне қосылу» бөлімінде тиісті элемент бар, ол мультикасттың реттелуін айтарлықтай жеңілдетеді. Клиент трафик ала бастады. Енді маршрутизатор кейде алушылардың кенеттен клиенттер қалса, таратпау үшін алшақтық бар екенін тексеруі керек. Мұны істеу үшін ол барлық түсетін интерфейстерге сұраныс жібереді. Танымал D-Link қосқышының мысалындағы пәрмен жолымен функцияны қосу тәсілін қарастырыңыз:

CLI интерфейсімен пәрмен жолын ашыңыз.

«Enable-Igmp-Snooping» енгізіңіз. Бұл команда коммутатордағы және барлық жалғанған мекен-жайларды қосады.

VLAN протоколын конфигурациялауға мүмкіндік беретін «Config-Igmp-Vlan-vlan-vlan-vlan-iney-reet-emunit» енгізіңіз.

«CONFON-VLAN-VLAN-сүзгілеу режимі-VLAN-vlan-vlan-valan-урмалды топтар» пәрмені коммуникатордағы бірнеше мекенжайдан деректерді сүзуді қамтиды.

Соңында VLAN желісіндегі «Config-Igmp-snoop-vlan-vlan-vlan-vloping-remove-remout» қолданыңыз.

Соңғы команданы пайдаланушы «REAT» сұраныс жасағаннан кейін желіден шығаратын IGMP SNOOPN FAST RENUST мүмкіндігін қамтиды. Жылдам демалыстың арқасында тұтынушы қажет емес мәліметтерді алмайды және оларды өңдемейді. Бұл желідегі жүктемені азайтады және коммутатордың жұмыс істеуіне мүмкіндік береді. Егер сұранысқа жауап ретінде, кем дегенде бір есеп маршрутизаторға келді, бұл әлі де клиенттердің бар екенін білдіреді, ол әлі де осы есепті қайдан шыққан интерфейс, осы топтың трафигі туралы хабарлауды жалғастырады. Егер сұрауда кейбір топтар үшін жауап интерфейсінің жауабы болмаса, маршрутизатор осы интерфейсті осы топқа жібереді - бұл топқа арналған «Трафик жіберу».

Ең кішкентай желілер. 9.2 бөлім. Мультикаст. IGMP протоколы

Multicast IGMP (Internet Group Management Protocol) Multicast (Internet Group Management Protocol), «Multicast трафигі» клиенттерінің өзара әрекеттесуіне және оларға жақын маршрутизаторға арналған желілік протоколды зерттеуді жалғастырыңыз.

IGMP протоколы

Қоқысқа қайта оралыңыз. Осы жоғарғы буманы қараңыз, содан кейін мультикаст ағыны лақтырылды ма? Клиенттің мінез-құлқындағы қызықты мәліметтер: сұраныс алғаннан кейін ол тез арада есеп беруге асығып кетпейді. Түйін 0-ден бастап күту уақытын алады .

Жалғанған кезде IGMP протоколының хабарламасы

ол келесі сұрауда көрсетілген: Қайта құру немесе қоқыстарда, айтпақшы, әр түрлі есептерді алу арасында бірнеше секундтан өтуі мүмкін екенін көруге болады. Бұл жүздеген клиенттер барлық ауқымда жалпы сұраныс алу арқылы өз есептерімен желіні өз баяндамаларымен толықтырады. Сонымен қатар, тек бір клиент тек есеп жібереді. Бұл IGMP протоколының хабарламасы, біз ойнатуды басқан кезде клиент жіберген. Ол 224.2.2.4 тобына трафик алғысы келетіні туралы хабарлайды.

- Бұл мультикаст трафигі клиенттері мен ең жақын маршрутизатормен өзара әрекеттесетін желілік протокол.

IPv6 IGMP орнына MLD (Multicast тыңдаушысын табу) қолданады. Жұмыс принципі Олар мүлдем бірдей, сондықтан сіз IGMP-ді MLD және IP IPv6-да оңай өзгертуге болады.

IGMP қалай жұмыс істейді? Төрт. Сонымен, клиент топтан шыққысы келгенше ғасырлар бойы жалғасады (мысалы, ойнатқышты / теледидарды өшіріңіз). Бұл жағдайда ол жібереді IGMP кетеді. Мүмкін сіз протоколдың нұсқаларының қазір үшеуі: igmpv1, igmpv2, igmpv3. Ең көп пайдаланылатындар - екіншісі, бірінші болып ұмытылған, сондықтан біз бұл туралы сөйлеспейміз, үшіншісі екіншісіне өте ұқсас.

Мен екіншісіне, ең алдымен, ең әсерінен және оның ішінде клиентті топқа қосудан барлық оқиғаларды қарастырамын. Клиент сонымен қатар VLC ойнатқышы арқылы 224.2.2.4 тобын сұрайды.

IGMP рөлі өте қарапайым: егер клиенттер болмаса, мультикаст трафигін сегменттің алдына жіберудің қажеті жоқ. Егер клиент пайда болса, ол маршрутизаторларды ИГМП көмегімен трафикті алғысы келетінін хабарлайды.

Бәрі қалай болатынын түсіну үшін осы желіні алыңыз:

Маршрутизатор қазірдің өзінде Multicast трафигін қабылдауға және өңдеуге теңшелген делік.

- ол осы топтың трафигін алғысы келетін «есептер» түйінін.

Топтық арнайы сұрау.

IGMP мүшелік туралы есеп жіберу

IGMPv2 есебі қалаған топтың мекен-жайына өтеді, ал параллель ол қаптамада көрсетілген. Бұл хабарламалар тек сегментінде өмір сүруі керек және бәрібір бағытталмауы керек, сондықтан маршрутизаторлар бойынша, демек, оларда олар 1 ТТЛ бар. Топтық арнайы сұрау. Жиі әдебиеттерде сіз туралы айтуға болады

Маршрутизатор IGMP-есепті алады және осы интерфейстің клиенттері бар екенін түсініп, олардың кестелеріне ақпарат береді

Бұл IGMP туралы ақпарат нәтижесі. Бірінші топты клиент сұрайды. Үшінші және төртінші - SSDP-салған SSDP хаттамалық топтары. Екіншісі - Cisco маршрутизаторларында әрқашан қатысатын арнайы топ - ол маршрутизаторлар бойынша әдепкі бойынша іске қосылатын Авто-rp протоколы үшін қолданылады.

  1. Fe0 / 0 интерфейсі 224.2.2.2.4 тобына түседі - алынған трафикті жіберу қажет.
  2. Әдеттегі ерекше маршруттау кестесімен бірге мультикаст бар:
  3. Клиенттердің қол жетімділігі туралы алдымен бірінші жазба айтылған
  4. Өнімнен 224.2.2.4 тобына трафик FE0 / 1 арқылы келетіні анық және оны FE0 / 0 портына жіберу керек.
  5. Трафикті жіберу қажет интерфейстер төменгі ағыс интерфейстерінің тізіміне енгізілген -
  6. Майлау Әрқайсысы IGMP жалпы сұранысын желіге жібереді. Басты мақсат - клиенттердің бар-жоғын және параллель-параллельді, егер олар болса, егер олар болса, олар сіз қатысса, сайлауға қатысуға деген ұмтылыстарыңыз туралы хабарлау. Шығыс интерфейстерінің тізімі.
  7. Толығырақ, IP Mroorte тобының шоуында біз кейінірек қарастырамыз.
  8. Саңылаудың үстінде, сіз оны клиент IGMP-есепті жібергеннен кейін, оны ұшқаннан кейін бірден UDP-ді жібергеннен кейін, ол видео ағын.

Routs S.

IGMP сұрауының сұранысын алу (қоқыс игмппен сүзіледі).

7)

Әдепкі бойынша, бұл әр 60 секунд сайын болады. TTL мұндай пакеттер де тең. Олар 224.0.0.1 мекен-жайына жіберіледі - осы сегменттегі барлық түйіндер - белгілі бір топты көрсетпестен. Мұндай сұрау хабарламалары шақырылады сегіз) - Жалпы. Осылайша, маршрутизатор: «Жігіттер және тағы кім алғысы келетіндер» сұрайды.

IGMP жалпы сұранысын алғаннан кейін, кез-келген топты тыңдайтын кез-келген хост IGMP есебін қосылған кезде жіберіп алуы керек. Өз тобына қызығушылық топтарының мекен-жайы есепте көрсетілуі керек. Сайлауды сайлау - бұл көп деңгейдегі өте маңызды процедура, бірақ RFC өткізбейтін кейбір тауарлар өндірушілері доңғалақтарға күшті таяқшаны сала алады. Мен IGMP сұранысы туралы айтып отырмын, оны коммутатор арқылы жасауға болады. Мұндай хабарламалар сұрауды таңдауға қатыспауы керек, бірақ сіз бәріне дайын болуыңыз керек. Міне, мысал IGMP жалпы сұранысына компьютерлік жауап (қоқыс игмп сүзіледі)

Егер сұранысқа жауап ретінде, кем дегенде бір есеп маршрутизаторға келді, бұл әлі де клиенттердің бар екенін білдіреді, ол әлі де осы есепті қайдан шыққан интерфейс, осы топтың трафигі туралы хабарлауды жалғастырады. 1 нұсқасы мәні бойынша, тек осыған байланысты Егер сұрауда кейбір топтар үшін жауап интерфейсінің жауабы болмаса, маршрутизатор осы интерфейсті осы топқа жібереді - бұл топқа арналған «Трафик жіберу».

Өзінің бастамасымен клиент әдетте есепті қосылған кезде ғана жібереді, содан кейін ол маршрутизатордан сұрауға жауап береді.

Клиенттің мінез-құлқындағы қызықты мәліметтер: сұраныс алғаннан кейін ол тез арада есеп беруге асығып кетпейді. Түйін 0-ден бастап күту уақытын алады

Қайта құру немесе қоқыстарда, айтпақшы, әр түрлі есептерді алу арасында бірнеше секундтан өтуі мүмкін екенін көруге болады.

Бұл жүздеген клиенттер барлық ауқымда жалпы сұраныс алу арқылы өз есептерімен желіні өз баяндамаларымен толықтырады. Сонымен қатар, тек бір клиент тек есеп жібереді.

Дәл осы есеп - бұл есеп тобының мекен-жайына жіберіледі, сондықтан барлық тұтынушыларға келеді. Басқа клиенттен бір топқа есеп алғаннан кейін, түйін өздігінен жібермейді. Логика қарапайым: Маршрутизатор бұл туралы осы есепті алды және клиенттер бар екенін біледі, қажет емес.

Саңылаудың үстінде, сіз оны клиент IGMP-есепті жібергеннен кейін, оны ұшқаннан кейін бірден UDP-ді жібергеннен кейін, ол видео ағын.

Клиент сонымен қатар VLC ойнатқышы арқылы 224.2.2.4 тобын сұрайды. Бұл механизм деп аталады

IGMPv2 есебі қалаған топтың мекен-жайына өтеді, ал параллель ол қаптамада көрсетілген. Бұл хабарламалар тек сегментінде өмір сүруі керек және бәрібір бағытталмауы керек, сондықтан маршрутизаторлар бойынша, демек, оларда олар 1 ТТЛ бар. Әрі қарай мақалада біз бұл механизм неліктен сирек жұмыс істейтіні туралы айтамыз.

Толығырақ II мысал. 4Осы жағдайда трафиктің қалай өтуі керек екенін ескеріңіз - R1-R2-R3-R5. Қысқаша айтқанда, R1-R3-R5 жолы.

Маршрутизатор жоқ жерде біз беделді түрде жария ете аламыз - IGMP - бұл формальдылықтан артық емес. Маршрутизатор жоқ, ал клиенттің мультикастты ағын сұрайтын ешкімі жоқ. Ол қарапайым себептер үшін видео табады, сондықтан ағынның және оны коммутатордан құйып, оны алу керек. топ мекен-жайына.

Қайталаңыз IGMP-ді жіберу

Содан кейін 224.2.2.2 топтың трафигін алғысы келген клиент пайда болды және ол өзінің IGMP есебін жіберді. Маршрутизатор оны алады және идеяны өшіру керек. Бірақ ол бір нақты клиентті өшіре алмайды - маршрутизатор оларды ажыратпайды - ол тек төменгі интерфейсі бар. Интерфейс бірнеше тұтынушы бола алады. Яғни, егер маршрутизатор осы интерфейсті осы топқа (шығыс интерфейстер тізімінен) осы топқа жоятын болса, бейне мүлде өшеді. Сондай-ақ, оны жою да мүмкін емес - бұл мүмкін емес - кенеттен ол соңғы клиент болды - неге оны жуыңыз?

Содан кейін маршрутизатор тексеру үшін қандай да бір себептерді шешуге шешім қабылдады және клиенттерге жауап беретін IGMP жалпы сұранысы жоқ па, себебі қайтадан жіберілді ме ( Егер сіз қоқысқа қарасаңыз, сіз демалыс орнын алғаннан кейін, ағын біраз уақытқа бара жатқанын көресіз. Шығуға жауап ретінде маршрутизатор IGMP сұрауында IGMP сұранысын осы демалысқа шыққан интерфейске келген топ мекен-жайына жібереді. Мұндай пакет деп аталады

Мерзімді түрде (минут бір рет) маршрутизатор алушылардың алушыларының әлі де бар екенін тексереді, ал IGMP жалпы сұранысын пайдаланып, IGMP есебін пайдаланып, мұны растайды.

Осы топқа қосылған клиенттер.

IGMP демалысына жауап ретінде маршрутизатордың маршрутизаторлар тобының арнайы сұрауын жіберу

Егер маршрутизатор топ үшін жауап туралы есеп алса, ол интерфейсте таратуды жалғастырады, егер қабылданбаған болса, таймердің мерзімі біткеннен кейін таймерді жояды.

Жалпы алғанда, демалысқа шыққаннан кейін, екі топқа арнайы сұраныс - бір міндетті, екінші бақылау.

Екі топтың арнайы сұрауы - бір міндетті, екінші бақылау

Әрі қарай, маршрутизатор ағынды тоқтатады. Бірақ, әлі күнге дейін кеңестендірілмейтін нәрсе, ол серверден трафиктің клиенттерге қалай жететіні, егер үлкен провайдер желісі бар? Шын мәнінде, бұл клиент кім екені белгілі? Біз маршруттарды қолмен тіркей алмаймыз, өйткені клиенттердің қай жерде болуы мүмкін екенін білмейміз. Әдеттегі маршруттау протоколдары бұл сұраққа жауап бермейді. Сондықтан біз мультикасттың жеткізілуі біз үшін мүлдем жаңа нәрсе екенін түсінеміз. Біршама қиын жағдайды қарастырыңыз: ). Трафикті таратуға болатын екі (немесе одан да көп) маршрутизаторлар клиенттің сегментіне қосылған. Егер сіз ештеңе жасамасаңыз, Multicast трафигі қайталанады - екі маршрутизаторлар да клиенттерден есеп алады. Бұған жол бермеу үшін таңдау механизмі бар - Саясат. Жеңіске алатын адам сұраныс жібереді, есепті жібереді және кетуге реакция жасайды және, сәйкесінше, ол сегментке трафик жібереді. Жеңілгендер тек есеп тыңдап, қолыңызды импульсте сақтайды. Сайлау өте қарапайым және интуитивті болады.

Техникалық қолдау үшін Наташа Самоойленкоға рахмет R1 және R2 маршрутизаторлар қосылған кезден бастап жағдайды қарастырыңыз.

Интерфейстерде іске қосылған IGMP.

RPF тексеру.

Алдымен, әдепкі бойынша олардың әрқайсысы өзін-өзі санайды.

  • Әрқайсысы IGMP жалпы сұранысын желіге жібереді. Мақсат - бұл клиенттердің бар-жоғын және параллель-параллельді білу - сегменттегі басқа маршрутизаторларды сайлауға, егер сіз сайлауға қатысуға деген құштарлығыңыз туралы білу. Жалпы сұрау сегменттегі барлық құрылғыларды, соның ішінде басқа IGMP маршрутизаторларынан алады.
  • Көршісінен осындай хабарлама алғаннан кейін, әр маршрутизатор өзіне лайықты кімге баға береді. Routs S.
  • Мысал: Кездейкім, DNS (IGMP сұрауының бастапқы IP өрісінде көрсетілген). Ол барлық басқалардан, басқаларға - жауап бермейді.

Кодерьер кез келген уақытта квариядан кіші IP мекен-жайымен бірге қалпына келтірілген таймерді бастайды. Егер таймердің жарамдылық мерзімі аяқталғанға дейін (100 секундтан артық: 105-107), маршрутизатор кіші мекен-жайы бар сұраныс алмайды, ол өзін-өзі жауап бермейді және барлық сәйкес функцияларды қабылдайды.

Егер сұраушы кіші мекен-жайы бар сұрау алса, ол осы міндеттерді қосады. Куберер басқа маршрутизаторға айналуда, оның ішінде IP аз. Сайлауды сайлау - бұл көп деңгейдегі өте маңызды процедура, бірақ RFC өткізбейтін кейбір тауарлар өндірушілері доңғалақтарға күшті таяқшаны сала алады. Мен IGMP сұранысы туралы айтып отырмын, оны коммутатор арқылы жасауға болады. Мұндай хабарламалар сұрауды таңдауға қатыспауы керек, бірақ сіз бәріне дайын болуыңыз керек. Міне, өте күрделі ұзақ жұмыс істеп тұрған проблеманың мысалы. .

1 нұсқасы мәні бойынша, тек осыған байланысты

. Егер Клиент осы топтың қосымша трафигін алғысы келмесе, ол сұрауға жауап ретінде есеп жіберуді тоқтатады. Бір клиент қалмаған кезде күту уақыты маршрутизаторы трафикті жіберуді тоқтатады.

Оның үстіне, Бірақ, әлі күнге дейін кеңестендірілмейтін нәрсе, ол серверден трафиктің клиенттерге қалай жететіні, егер үлкен провайдер желісі бар? Шын мәнінде, бұл клиент кім екені белгілі? Біз маршруттарды қолмен тіркей алмаймыз, өйткені клиенттердің қай жерде болуы мүмкін екенін білмейміз. Әдеттегі маршруттау протоколдары бұл сұраққа жауап бермейді. Сондықтан біз мультикасттың жеткізілуі біз үшін мүлдем жаңа нәрсе екенін түсінеміз. . Трафиктің қайталануын болдырмас үшін, жоғары протоколға жауап береді, мысалы, біз бұдан әрі қарай сөйлейтін пим.

3-нұсқа IGMPv2 қолдайтындардың бәрін қолдайды, бірақ бірқатар өзгерістер бар. Біріншіден, есеп енді топ мекен-жайына жіберілмейді, бірақ Multicast қызметінің мекен-жайы бойынша

. Және сұралған топтың мекен-жайы тек пакетте көрсетілген. Бұл IGMP SNOOPING-дің жұмысын жеңілдету үшін жасалады, біз келесіде сөйлесеміз.

Екіншіден, ең бастысы, Игмпв3 SSM-ді таза түрінде қолдай бастады. Бұл SOURE SOURCE SUBSICTION MULTICAST. Бұл жағдайда Клиент топты ғана сұрамауы мүмкін, сонымен қатар ол трафик алғысы келетін немесе керісінше алғысы келмейтін көздер тізімін көрсете алмайды. IGMPV2-де клиент топтық трафикті дереккөзге қамқорсыз сұрайды және алады.

IGMP мүшелігі IGmpv3-тегі мазмұн Сонымен, IGMP клиенттер мен маршрутизатормен өзара әрекеттесуге арналған. Сондықтан, 2-мысалға оралу, роутер жоқ жерде біз беделді түрде жария ете аламыз - IGMP - IGMP - формалдылықтан артық емес. Маршрутизатор жоқ, ал клиенттің мультикастты ағын сұрайтын ешкімі жоқ. Ол қарапайым себептер үшін видео табады, сондықтан ағынның және оны коммутатордан құйып, оны алу керек. Еске салайық, IGMP IPv6 үшін жұмыс істемейді. MLD протоколы бар.

Қайталаңыз Біріншіден, маршрутизатор IGMP жалпы сұранысын IGMP-ті өзінің интерфейсіне қосқаннан кейін жіберді және алушылардың бар-жоғын білу және олардың жұмысқа деген ниеті туралы хабарлаңыз. Ол кезде бұл топта ешкім болған жоқ. Содан кейін 224.2.2.2 топтың трафигін алғысы келген клиент пайда болды және ол өзінің IGMP есебін жіберді. Осыдан кейін мен ондағы трафикке бардым, бірақ ол қоқыстардан алынады.

Мерзімді түрде (минут бір рет) маршрутизатор алушылардың алушыларының әлі де бар екенін тексереді, ал IGMP жалпы сұранысын пайдаланып, IGMP есебін пайдаланып, мұны растайды.

Содан кейін ол өз ойын өзгертіп, топты игмп демалысын жіберіп, бас тартты. Маршрутизатор демалысқа келіп, басқа алушылардың басқа алушылар болмағанына көз жеткізгіңізші, IGMP Group арнайы сұранысын жіберіңіз ... екі рет. Таймер аяқталғаннан кейін осы жерден тасымалданады. Дегенмен, IGMP сұрауын желіге жіберуді жалғастыруда. Мысалы, егер сіз ойнатқышты өшірмеген болсаңыз, бірақ жай мәселені байланыстырыңыз. Содан кейін байланыс қалпына келтірілді, бірақ клиент өздігінен есеп жібермейді. Бірақ сұрау жауаптар. Осылайша, ағын адамның қатысуынсыз қалпына келеді. Маршрутизатор мультикаст-трафик алушылардың болуын және олардың соғып жатқанын білетін Игмпропол .Біркеуі туралы .Біркеу туралы хабарлайды. Бұл клиенттің нақты топтық трафик алғысы келетінін білдіреді. Migmp Genual Query-еуі қазір қай топтар қажет екенін тексеру үшін маршрутизаторды мезгіл-мезгіл-мезгіл-мезгіл-мезгілде тексеріп отырады. 224.0.0.1 Алушының мекен-жайы көрсетілгендей. .

IGMP Group Sepcify Sepcify QuertPrication компаниясы осы топта басқа алушылардың бар-жоғын білу үшін хабарлама жіберіңіз. Алушының мекен-жайы көрсетілгендей, «Multicast» тобының мекен-жайы көрсетілген. MIGMP топтан кеткісі келгенде, ол бір трансляция сегментінде бірнеше маршрутизаторларда шығарылады, олардың арасында бірнеше маршрутизаторлар таңдалды оларға. Ол мезгіл-мезгіл сұрауды жіберіп, трафикті жібереді. Дереккөз:

Тегтер

Cisco.

IPTV.

Sdsm

Желілік жабдық

Ең кішкентай желілер https://radioprog.ru/post/623.
Маршрутизатордағы мультикаст қандай. Жүйелік ресурстарға қойылатын талаптар. Multicast және Unicast: негізгі айырмашылықтар

Техникалық қолдау үшін Наташа Самоойленкоға рахмет Біріншіден, одан әрі түсінбеушілікті болдырмау үшін бірнеше ұғымдарды айтайық. Трафиктің үш түрі бар:

(*, G) (s, g)

Біз мұны арналар арасында тез ауысу үшін жасаймыз.

Брандмауэрді орнату

Қазіргі уақытта IPTV-ны жіберіп алмайтын брандмауэрді теңшеңіз, өйткені біз жаңа терминал жасаймыз, жаңа терминалды нұқыңыз және терезе ашылады: Енді біз осы консольде бірнеше командаларды орындауымыз керек: / IP Firewall сүзгісі Қабаттама = Қабылдау Chain = «IGMP» рұқсат ету »рұқсат етілген =« IGMP »рұқсат ету = IN интерфейсі = жоқ = Ether2-Master Protocol = IGMP

/ IP Firewall сүзгісі қосу action rection = Қабылдау тізбегі = »IPTV UDP кіріс

/ IP Firewall сүзгісі қосу action action action rection = Қабылдау тізбегі = «IPTV UDP қайта жіберу» = «IPTV UDP қайта бағыттау» Ажыратылған = Dst-Port = 1234 протокол = UDP 1234. Мұнай мультипроскциясы.

- порт бейненің бейне және IPTV үшін бейресми түрде тіркелген Эфир2-шебер. - Бұл IPTV провайдерден келетін интерфейс.

Келесі қажеттілік Мәзірде

Сор Элементті таңдаңыз Брандмауэр

және қойындыға өтіңіз Сүзгі ережелері.

. Біз ережелерді жоққа шығардық және олар жұмыс істейтіндіктен, олар тыйым салу үшін жоғары болуы керек. Біз оларды тінтуірге апарамыз.

  1. Wi-Fi орнату
  2. Егер сіз таратқан болсаңыз немесе IPTV-ді Wi-Fi арқылы тапсаңыз, қосымша параметрлер қосуыңыз керек. Мұны істеу үшін:
  3. Қосымша режим түймесін басқаннан кейін қосымша параметрлер пайда болады:
  4. Алаңда
  5. WMM қолдауы Pim Sm RP.

Қою

4-тапсырма.

Unicast.

  1. - Unicast, бір ағын көзі Бірінші алушы Таратылымы.
  2. - таратылым, бір көзі, барлық клиенттер Интернетте - Multicast, бір жіберуші, алушылар Кейбір тұтынушылар тобы

IPTV үшін қандай трафикті қолдану үшін?

Әрине, мультикаст тарату арналарына беріледі. Желіні таратқымыз келетін кез келген теледидар арнасы осы мақсаттарға сақталған ауқымнан таңдалатын топ мекен-жайымен сипатталады:

224.0.0.0 - 239.255.255.255

Новости

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