ПИМ протокол је скуп протокола за пренос вишеструког преноса у мрежи између рутера. Суседски односи се граде на исти начин као у случају динамичких протокола рутирања. ПИМв2 шаље Хелло поруке сваких 30 секунди на резервисану мултицаст адресу 224.0.0.13 (Алл-ПИМ-Роутерс). Порука садржи тајмере чекања - обично једнако 3.5*Хелло Тимер, односно 105 секунди подразумевано.
ПИМ користи два главна режима рада - густи и ретки режим. Почнимо са густим режимом.
Стабла дистрибуције заснована на извору.
Режим густог режима је препоручљиво користити у случају великог броја клијената различитих мултицаст група. Када рутер прими мултицаст саобраћај, прва ствар коју уради је да провери да ли има РПФ правило. РПФ - ово правило се користи за проверу извора вишеструког преноса са табелом рутирања уницаст. Неопходно је да саобраћај стиже на интерфејс иза којег је скривен овај хост према верзији табеле уницаст рутирања. Овај механизам решава проблем петље која се јавља током мултицаст преноса.
Р3 ће препознати вишеструки извор (ИП извора) из мултицаст поруке и проверити два тока од Р1 и Р2 користећи своју уницаст табелу. Стрим са интерфејса на који указује табела (Р1 до Р3) ће се даље преносити, а ток са Р2 ће бити испуштен, јер да бисте дошли до мултицаст извора, потребно је да пошаљете пакете преко С0/1.
Питање је шта се дешава ако имате две еквивалентне руте са истом метриком? У овом случају, рутер ће изабрати следећи скок са ових рута. Ко има већу ИП адресу побеђује. Ако треба да промените ово понашање, можете користити ЕЦМП. Детаљније .
Након провере РПФ правила, рутер шаље мултицаст пакет свим својим ПИМ суседима, осим оној од ког је пакет примљен. Други ПИМ рутери понављају овај процес. Путања коју је мултицаст пакет прошао од извора до крајњих прималаца формира стабло које се зове стабло дистрибуције засновано на извору, стабло најкраћег пута (СПТ), стабло извора. Три различита имена, изаберите било које.
Како решити проблем што неки рутери нису одустали од неког мултицаст стрима и нема коме да га пошаље, већ му га упстреам рутер шаље. За ово је измишљен механизам Пруне.
Пруне Мессаге.
На пример, Р2 ће наставити да шаље мултицаст на Р3, иако га Р3, према РПФ правилу, одбацује. Зашто учитавати канал? Р3 шаље ПИМ Пруне поруку и Р2, по пријему ове поруке, уклања интерфејс С0/1 са листе одлазних интерфејса за овај ток, листе интерфејса са којих овај саобраћај треба да буде послат.
Следеће је формалнија дефиниција ПИМ Пруне поруке:
Поруку ПИМ Пруне шаље један рутер другом рутеру како би други рутер уклонио везу на којој се прима Пруне од одређеног (С,Г) СПТ-а.
Након што прими поруку Пруне, Р2 подешава тајмер за Пруне на 3 минута. Након три минута, поново ће почети да шаље саобраћај док не прими другу Пруне поруку. Ово је у ПИМв1.
А у ПИМв2 је додат тајмер за освежавање стања (подразумевано 60 секунди). Чим је порука Пруне послата са Р3, овај тајмер се покреће на Р3. По истеку овог тајмера, Р3 ће послати поруку за освежавање стања, која ће ресетовати 3-минутни тајмер за орезивање на Р2 за ову групу.
Разлози за слање Пруне поруке:
- Када вишеструки пакет не прође РПФ проверу.
- Када нема локално повезаних клијената који су захтевали мултицаст групу (ИГМП Јоин) и нема ПИМ суседа којима се може послати вишеструки саобраћај (Интерфејс без смањења).
Графт Мессаге.
Замислимо да Р3 није желео саобраћај са Р2, послао Пруне и примио мултицаст од Р1. Али изненада, канал између Р1-Р3 је пао и Р3 је остао без мултицаст. Можете сачекати 3 минута док не истекне тајмер за пруне на Р2. 3 минута је дуго чекање, да не бисте чекали, потребно је да пошаљете поруку која ће одмах довести овај С0/1 интерфејс у Р2 из искљученог стања. Ова порука ће бити Графт порука. Након пријема поруке Графт, Р2 ће одговорити Графт-АЦК.
Пруне Оверриде.
Погледајмо овај дијаграм. Р1 емитује мултицаст у сегмент са два рутера. Р3 прима и емитује саобраћај, Р2 прима, али нема коме да емитује саобраћај. Он шаље Пруне поруку Р1 у овом сегменту. Р1 би требало да уклони Фа0/0 са листе и заустави емитовање у овом сегменту, али шта ће бити са Р3? И Р3 је у истом сегменту, такође је примио ову поруку од Пруне и схватио трагедију ситуације. Пре него што Р1 заустави емитовање, поставља тајмер од 3 секунде и престаће са емитовањем након 3 секунде. 3 секунде - то је тачно колико времена Р3 има да не изгуби свој мултицаст. Стога, Р3 шаље поруку Пим Јоин за ову групу што је пре могуће, а Р1 више не размишља да прекине емитовање. О порукама за придруживање у наставку.
Потврдите поруку.
Замислимо ову ситуацију: два рутера емитују на једну мрежу одједном. Они примају исти ток од извора и оба га емитују на исту мрежу иза интерфејса е0. Због тога треба да одреде ко ће бити један и једини емитер ове мреже. За ово се користе поруке за потврду. Када Р2 и Р3 открију дуплирање мултицаст саобраћаја, односно, Р2 и Р3 приме мултицаст који сами емитују, рутери схватају да овде нешто није у реду. У овом случају, рутери шаљу поруке Ассерт, које укључују административну удаљеност и метрику руте са којом се достиже мултицаст извор - 10.1.1.10. Победник се одређује на следећи начин:
- Онај са нижим АД.
- Ако су АД једнаки, ко има нижу метрику.
- Ако овде постоји равноправност, онда онај ко има већи ИП у мрежи на коју емитују овај мултикаст.
Победник овог гласања постаје именовани рутер. Пим Хелло се такође користи за одабир ДР. На почетку чланка је приказана порука ПИМ Хелло, тамо можете видети поље ДР. Побеђује онај са највећом ИП адресом на овој вези.
Користан знак:
МРОУТЕ Табле.
Након почетног погледа на то како ПИМ протокол функционише, морамо да разумемо како да радимо са табелом за мултицаст рутирање. Мроуте табела чува информације о томе који токови су тражени од клијената и који токови теку са мултицаст сервера.
На пример, када се на неком интерфејсу прими ИГМП Извештај о чланству или ПИМ придруживање, запис типа ( *, Г ) се додаје у табелу рутирања:
Овај унос значи да је примљен саобраћајни захтев са адресом 238.38.38.38. ДЦ заставица значи да ће мултицаст радити у густо режиму, а Ц значи да је прималац директно повезан са рутером, односно да је рутер примио ИГМП Мемберсхип Репорт и ПИМ Јоин.
Ако постоји запис типа (С,Г) то значи да имамо мултицаст стреам:
У пољу С - 192.168.1.11, регистровали смо ИП адресу мултицаст извора, то ће бити проверено РПФ правилом. Ако постоје проблеми, прва ствар коју треба да урадите је да проверите уницаст табелу за руту до извора. У пољу Инцоминг Интерфаце означава интерфејс на који се прима мултицаст. У једнострукој табели рутирања, рута до извора мора да се односи на интерфејс који је овде наведен. Одлазни интерфејс одређује где ће се вишеструко слање преусмерити. Ако је празан, рутер није примио ниједан захтев за овај саобраћај. Више информација о свим заставама можете пронаћи .
ПИМ Спарсе-моде.
Стратегија ретког режима је супротна од густог режима. Када Спарсе-моде прими мултицаст саобраћај, он ће слати саобраћај само преко оних интерфејса где су постојали захтеви за овај ток, на пример Пим Јоин или ИГМП Репорт поруке које захтевају овај саобраћај.
Слични елементи за СМ и ДМ:
- Суседски односи се граде на исти начин као у ПИМ ДМ.
- РПФ правило функционише.
- Избор ДР је сличан.
- Механизам порука „Пуне Оверридес“ и „Асерт“ је сличан.
За контролу коме, где и какав мултицаст саобраћај је потребан на мрежи, потребан је заједнички информациони центар. Наш центар ће бити Рендезвоус Поинт (РП). Свако ко жели неку врсту мултицаст саобраћаја или је неко почео да прима мултицаст саобраћај са извора, онда га шаље у РП.
Када РП прими мултицаст саобраћај, он ће га послати оним рутерима који су претходно захтевали овај саобраћај.
Хајде да замислимо топологију где је РП Р3. Чим Р1 прими саобраћај од С1, он инкапсулира овај мултицаст пакет у једноструку поруку ПИМ Регистер и шаље је РП-у. Како он зна ко је РП? У овом случају, он је конфигурисан статички, а о динамичкој РП конфигурацији ћемо касније.
ип пим рп-адреса 3.3.3.3
РП ће погледати - да ли је било информација од некога ко би желео да прими овај саобраћај? Претпоставимо да није. Тада ће РП послати Р1 поруку ПИМ Регистер-Стоп, што значи да никоме није потребан овај мултицаст, регистрација је одбијена. Р1 неће слати мултицаст. Али мултицаст изворни хост ће га послати, тако да ће Р1, након што прими Регистер-Стоп, покренути тајмер за сузбијање регистра једнак 60 секунди. 5 секунди пре него што овај тајмер истекне, Р1 ће послати празну поруку регистра са битом Нулл-Регистер (то јест, без инкапсулираног мултицаст пакета) ка РП-у. РП ће се, заузврат, понашати овако:
- Ако није било прималаца, онда ће одговорити поруком Регистер-Стоп.
- Ако се појаве примаоци, он на то неће одговорити ни на који начин. Р1, пошто није примио одбијеницу да се региструје у року од 5 секунди, биће срећан и послаће поруку за регистрацију са инкапсулираним мултицастом на РП.
Чини се да смо схватили како мултицаст стиже до РП-а, сада покушајмо да одговоримо на питање како РП испоручује саобраћај примаоцима. Овде је потребно увести нови концепт - стабло корена путање (РПТ). РПТ је стабло укорењено у РП, које расте ка примаоцима, гранајући се на сваком ПИМ-СМ рутеру. РП га креира тако што прима ПИМ Јоин поруке и додаје нову грану стаблу. И тако, сваки низводни рутер ради. Опште правило изгледа овако:
- Када ПИМ-СМ рутер прими поруку ПИМ Јоин на било ком интерфејсу осим интерфејса иза којег је РП скривен, он додаје нову грану стаблу.
- Грана се такође додаје када ПИМ-СМ рутер прими извештај о чланству ИГМП-а од директно повезаног хоста.
Замислимо да имамо мултицаст клијента на Р5 рутеру за групу 228.8.8.8. Чим Р5 прими извештај о чланству ИГМП-а од хоста, Р5 шаље ПИМ Јоин у правцу РП-а и сам додаје интерфејс стаблу које гледа на хост. Затим, Р4 прима ПИМ Јоин од Р5, додаје интерфејс Ги0/1 стаблу и шаље ПИМ Јоин у правцу РП. Коначно, РП ( Р3 ) прима ПИМ Јоин и додаје Ги0/0 стаблу. Дакле, мултицаст прималац је регистрован. Градимо дрво са кореном Р3-Ги0/0 → Р4-Ги0/1 → Р5-Ги0/0.
Након тога, ПИМ Јоин ће бити послат на Р1 и Р1 ће почети да шаље вишеструки саобраћај. Важно је напоменути да ако је домаћин затражио саобраћај пре почетка мултицаст емитовања, онда РП неће послати ПИМ Јоин и неће послати ништа Р1 уопште.
Ако изненада док се мултицаст шаље, хост престане да жели да га прими, чим РП прими ПИМ Пруне на Ги0/0 интерфејсу, одмах ће послати ПИМ Регистер-Стоп директно на Р1, а затим ПИМ Пруне порука преко Ги0/1 интерфејса. ПИМ Регистер-стоп се шаље путем уницаст на адресу са које је ПИМ регистар дошао.
Као што смо раније рекли, чим рутер пошаље ПИМ Јоин другом, на пример Р5 на Р4, тада се запис додаје у Р4:
Покреће се и тајмер који Р5 мора стално да ресетује овај тајмер ПИМ Придружи поруке стално, у супротном ће Р4 бити искључен са одлазне листе. Р5 ће послати сваких 60 ПИМ Јоин порука.
Пребацивање на стабло најкраћег пута.
Додаћемо интерфејс између Р1 и Р5 и видети како саобраћај тече са овом топологијом.
Претпоставимо да је саобраћај послат и примљен по старој шеми Р1-Р2-Р3-Р4-Р5 и овде смо повезали и конфигурисали интерфејс између Р1 и Р5.
Пре свега, морамо да поново изградимо табелу уницаст рутирања на Р5 и сада се до мреже 192.168.1.0/24 долази преко Р5 Ги0/2 интерфејса. Сада Р5, који прима мултицаст на интерфејсу Ги0/1, разуме да РПФ правило није задовољено и било би логичније да прими мултицаст на Ги0/2. Требало би да се одвоји од РПТ-а и да направи краће стабло под називом Стабло најкраћег пута (Схортест-Патх Трее (СПТ). Да би то урадио, он шаље ПИМ Јоин на Р0 преко Ги2/1 и Р1 почиње да шаље мултицаст такође преко Ги0/2. Сада Р5 треба да се одјави са РПТ-а како не би добио две копије. Да би то урадио, он шаље Прунеу поруку која указује на изворну ИП адресу и убацује посебан бит - РПТ-бит. То значи да не морате да ми шаљете саобраћај, овде имам боље дрво. РП такође шаље ПИМ Пруне поруке на Р1, али не шаље Регистер-Стоп поруку. Још једна карактеристика: Р5 ће сада континуирано слати ПИМ Пруне РП-у, пошто Р1 наставља да шаље ПИМ Регистер РП-у сваког минута. Док не буде нових људи који желе овај саобраћај, РП ће га одбити. Р5 обавештава РП да наставља да прима мултицаст преко СПТ-а.
Динамичка РП претрага.
Ауто-РП.
Ова технологија је власништво компаније Цисцо и није нарочито популарна, али је још увек жива. Ауто-РП операција се састоји од две главне фазе:
1) РП шаље РП-Анноунце поруке на резервисану адресу - 224.0.1.39, проглашавајући се РП или за све или за одређене групе. Ова порука се шаље сваког минута.
2) Потребан је агент за РП мапирање, који ће слати РП-Дисцовери поруке које указују на групе које РП треба слушати. Из ове поруке ће обични ПИМ рутери сами одредити РП. Агент за мапирање може бити или сам РП рутер или засебни ПИМ рутер. РП-Дисцовери се шаље на адресу 224.0.1.40 са тајмером од једног минута.
Погледајмо процес детаљније:
Хајде да конфигуришемо Р3 као РП:
ип пим сенд-рп-анноунце лоопбацк 0 опсег 10
Р2 као агент за мапирање:
ип пим сенд-рп-дисцовери лоопбацк 0 опсег 10
А на свим осталима очекујемо РП преко Ауто-РП-а:
ип пим ауторп слушалац
Када конфигуришемо Р3, он ће почети да шаље РП-Анноунце:
А Р2, након подешавања агента за мапирање, ће почети да чека поруку РП-Анноунце. Тек када пронађе барем један РП, почеће да шаље РП-Дисцовери:
На овај начин, чим обични рутери (ПИМ РП Листенер) приме ову поруку, они ће знати где да траже РП.
Један од главних проблема са Ауто-РП је то што да бисте примали РП-Анноунце и РП-Дисцовери поруке, морате да пошаљете ПИМ Јоин на адресе 224.0.1.39-40, а да бисте послали, морате да знате где се РП се налази. Класични проблем са пилетином и јајима. Да би се решио овај проблем, измишљен је ПИМ Спарсе-Денсе-Моде. Ако рутер не познаје РП, онда ради у густом режиму; ако зна, онда у режиму ретке. Када су ПИМ Спарсе-моде и ип пим ауторп листенер команда конфигурисани на интерфејсима обичних рутера, рутер ће радити у густом режиму само за мултицастинг директно из Ауто-РП протокола (224.0.1.39-40).
БоотСтрап рутер (БСР).
Ова функција функционише слично као Ауто-РП. Сваки РП шаље поруку агенту за мапирање, који прикупља информације о мапирању и затим говори свим осталим рутерима. Хајде да опишемо процес слично као Ауто-РП:
1) Када конфигуришемо Р3 као кандидата да буде РП, са командом:
ип пим рп-кандидат лоопбацк 0
Тада Р3 неће учинити ништа; да би почео да шаље посебне поруке, прво треба да пронађе агента за мапирање. Дакле, прелазимо на други корак.
2) Конфигуришите Р2 као агента за мапирање:
ип пим бср-кандидат лоопбацк 0
Р2 почиње да шаље ПИМ Боотстрап поруке, где се означава као агент за мапирање:
Ова порука се шаље на адресу 224.0.013, коју ПИМ протокол користи и за своје остале поруке. Шаље их у свим правцима и стога нема проблема са кокошком и јајима као у Ауто-РП-у.
3) Чим РП прими поруку од БСР рутера, одмах ће послати једноструку поруку на адресу БСР рутера:
Након тога, БСР, пошто је примио информације о РП-овима, ће их послати мултицастом на адресу 224.0.0.13, коју слушају сви ПИМ рутери. Дакле, аналог команде ип пим ауторп слушалац за обичне рутере који нису у БСР-у.
Аницаст РП са Мултицаст Соурце Дисцовери Протоцол (МСДП).
Ауто-РП и БСР нам омогућавају да расподелимо оптерећење на РП на следећи начин: Свака мултицаст група има само један активан РП. Неће бити могуће распоредити оптерећење за једну мултицаст групу на неколико РП-ова. МСДП то ради тако што РП рутерима даје исту ИП адресу са маском 255.255.255.255. МСДП учи информације користећи један од метода: статички, Ауто-РП или БСР.
На слици имамо Ауто-РП конфигурацију са МСДП-ом. Оба РП-а су конфигурисана са ИП адресом 172.16.1.1/32 на интерфејсу Лоопбацк 1 и користе се за све групе. Са РП-Анноунце, оба рутера се оглашавају позивањем на ову адресу. Агент за аутоматско РП мапирање, након што је примио информацију, шаље РП-Дисцовери о РП-у са адресом 172.16.1.1/32. Рутерима говоримо о мрежи 172.16.1.1/32 која користи ИГП и, сходно томе. Дакле, ПИМ рутери захтевају или региструју токове од РП-а који је наведен као следећи скок на рути до мреже 172.16.1.1/32. Сам МСДП протокол је дизајниран да сами РП размењују поруке о мултицаст информацијама.
Размотрите ову топологију:
Свитцх6 емитује саобраћај на адресу 238.38.38.38 и до сада само РП-Р1 зна за то. Свитцх7 и Свитцх8 су захтевали ову групу. Рутери Р5 и Р4 ће послати ПИМ Јоин на Р1 и Р3, респективно. Зашто? Рута до 13.13.13.13 за Р5 ће се односити на Р1 користећи ИГП метрику, баш као и за Р4.
РП-Р1 зна за ток и почеће да га емитује према Р5, али Р4 не зна ништа о томе, пошто га Р1 неће једноставно послати. Стога је МСДП неопходан. Конфигуришемо га на Р1 и Р5:
ип мсдп пеер 3.3.3.3 Цоннецт-соурце Лоопбацк1 на Р1
ип мсдп пеер 1.1.1.1 Цоннецт-соурце Лоопбацк3 на Р3
Они ће покренути међусобну сесију и када приме било какав ток, пријавиће то свом РП комшији.
Чим РП-Р1 прими стрим од Свитцх6, он ће одмах послати једносмерну МСДП Соурце-Ацтиве поруку, која ће садржати информације као што су (С, Г) - информације о извору и дестинацији мултицаст. Сада када РП-Р3 зна да извор као што је Свитцх6, када прими захтев од Р4 за овај ток, он ће послати ПИМ Јоин ка Свитцх6, вођен табелом рутирања. Сходно томе, Р1 након што је примио такав ПИМ Јоин ће почети да шаље саобраћај ка РП-Р3.
МСДП ради преко ТЦП-а, РП-ови шаљу једни другима поруке о одржавању да би проверили живост. Тајмер је 60 секунди.
Функција поделе МСДП пеер-а на различите домене остаје нејасна, пошто Кеепаливе и СА поруке не указују на чланство у било ком домену. Такође, у овој топологији смо тестирали конфигурацију која указује на различите домене - није било разлике у перформансама.
Ако неко може да разјасни, радо бих то прочитао у коментарима.
Извор: ввв.хабр.цом