Како функционира PIM протоколот

Протоколот PIM е збир на протоколи за пренос на мултикаст во мрежа помеѓу рутери. Односите со соседството се градат на ист начин како и во случајот со протоколи за динамичко рутирање. PIMv2 испраќа пораки Hello на секои 30 секунди до резервираната мултикаст адреса 224.0.0.13 (All-PIM-Routers). Пораката содржи тајмери ​​за задржување - обично еднаква на 3.5*Здраво тајмер, односно стандардно 105 секунди.

PIM користи два главни режими на работа - густ и редок режим. Да почнеме со густ режим.
Дрвја за дистрибуција базирани на извори.
Режимот на густ режим се препорачува да се користи во случај на голем број клиенти од различни мултикаст групи. Кога рутерот добива мултикаст сообраќај, првото нешто што го прави е да го провери за правилото RPF. RPF - ова правило се користи за проверка на изворот на мултикаст со уникаст рутирачка табела. Неопходно е сообраќајот да пристигне до интерфејсот зад кој се крие овој домаќин според верзијата на уникаст рутирачката табела. Овој механизам го решава проблемот на јамка што се јавува при мултикаст пренос.

R3 ќе го препознае изворот на повеќекратно емитување (ИП на извор) од мултикаст пораката и ќе ги провери двата текови од R1 и R2 користејќи ја неговата уникаст табела. Преносот од интерфејсот на кој е посочена табелата (R1 до R3) ќе се пренесува понатаму, а потокот од R2 ќе се исфрли, бидејќи за да стигнете до изворот на мултикаст, треба да испраќате пакети преку S0/1.
Прашањето е, што се случува ако имате две еквивалентни правци со иста метрика? Во овој случај, рутерот ќе го избере следниот скок од овие правци. Кој има повисока IP адреса победи. Ако треба да го промените ова однесување, можете да го користите ECMP. Повеќе детали тука.
По проверка на правилото RPF, рутерот испраќа мултикаст пакет до сите негови PIM соседи, освен оној од кого е примен пакетот. Другите PIM рутери го повторуваат овој процес. Патеката што мултикастиран пакет ја презел од изворот до крајните примачи формира дрво наречено дрво за дистрибуција базирано на извор, дрво со најкраток пат (SPT), изворно дрво. Три различни имиња, изберете кое било.
Како да се реши проблемот што некои рутери не се откажале од некој мултикаст стрим и нема на кој да го прати, туку му го праќа рутерот upstream. За ова е измислен механизмот Prune.
Исчистете ја пораката.
На пример, R2 ќе продолжи да испраќа мултикаст до R3, иако R3, според правилото RPF, го испушта. Зошто да го вчитате каналот? R3 испраќа PIM Prune порака и R2, по добивањето на оваа порака, ќе го отстрани интерфејсот S0/1 од списокот на појдовни интерфејси за овој тек, списокот на интерфејси од кои треба да се испрати овој сообраќај.

Следното е поформална дефиниција за пораката PIM Prune:
Пораката PIM Prune се испраќа од еден рутер до вториот рутер за да предизвика вториот рутер да ја отстрани врската на која е примена Prune од одреден (S,G) SPT.

Откако ќе ја прими пораката Prune, R2 го поставува тајмерот Prune на 3 минути. По три минути, повторно ќе започне да испраќа сообраќај додека не прими друга порака за Prune. Ова е во PIMv1.
И во PIMv2 е додаден тајмер за државно освежување (стандардно 60 секунди). Штом е испратена порака за Prune од R3, овој тајмер се стартува на R3. По истекот на овој тајмер, R3 ќе испрати порака за Освежување на државата, која ќе го ресетира 3-минутниот тајмер за чистење на R2 за оваа група.
Причини за испраќање порака на Prune:

• Кога мултикаст пакетот не успее, проверката на RPF.
• Кога нема локално поврзани клиенти кои побарале мултикаст група (IGMP Join) и нема PIM соседи на кои може да се испрати сообраќај со повеќекратни емитувања (Interface Non-prune).

Порака за графт.
Да замислиме дека R3 не сакаше сообраќај од R2, го испрати Prune и доби мултикаст од R1. Но, одеднаш, каналот помеѓу R1-R3 падна и R3 остана без мултикаст. Може да почекате 3 минути додека не истече тајмерот за чистење на R2. 3 минути е долго чекање, за да не чекате, треба да испратите порака која веднаш ќе го извади овој интерфејс S0/1 на R2 од отсечената состојба. Оваа порака ќе биде порака за Graft. Откако ќе ја прими пораката Graft, R2 ќе одговори со Graft-ACK.
Изчистете го замени.

Ајде да го погледнеме овој дијаграм. R1 емитува мултикаст до сегмент со два рутери. R3 прима и емитува сообраќај, R2 прима, но нема на кого да емитува сообраќај. Испраќа порака Prune до R1 во овој сегмент. R1 треба да го отстрани Fa0/0 од списокот и да престане да емитува во овој сегмент, но што ќе се случи со R3? И R3 е во истиот сегмент, исто така ја доби оваа порака од Prune и ја разбра трагедијата на ситуацијата. Пред R1 да престане да емитува, поставува тајмер од 3 секунди и ќе престане да емитува по 3 секунди. 3 секунди - е точно колку време има R3 за да не го изгуби мултикастот. Затоа, R3 испраќа порака Pim Join за оваа група што е можно поскоро, а R1 повеќе не размислува да го прекине емитувањето. За пораките за придружување подолу.
Потврдете ја пораката.

Да ја замислиме оваа ситуација: два рутери се емитуваат на една мрежа одеднаш. Тие го добиваат истиот поток од изворот и обајцата го емитуваат на истата мрежа зад интерфејсот e0. Затоа треба да утврдат кој ќе биде единствениот радиодифузер на оваа мрежа. За ова се користат пораките за наметнување. Кога R2 и R3 детектираат дуплирање на мултикаст сообраќај, односно R2 и R3 добиваат мултикаст што тие самите го емитуваат, рутерите разбираат дека тука нешто не е во ред. Во овој случај, рутерите испраќаат пораки за Assert, кои вклучуваат Административно растојание и метрика на маршрутата со која се доаѓа до изворот на мултикаст - 10.1.1.10. Победникот се одредува на следниов начин:

1. Онаа со пониска АД.
2. Ако АД се еднакви, тогаш кој ја има пониската метрика.
3. Ако тука има еднаквост, тогаш оној што има повисока IP во мрежата на која го емитуваат овој мултикаст.

Победникот на ова гласање станува Назначениот рутер. Pim Hello се користи и за избор на DR. На почетокот на статијата беше прикажана пораката PIM Hello, таму можете да го видите полето DR. Оној со највисока IP адреса на оваа врска победи.
Корисен знак:

МРУТЕ Табела.
По првичниот поглед на тоа како функционира PIM протоколот, треба да разбереме како да работиме со multicast рутирачка табела. Табелата mroute складира информации за тоа кои стримови се побарани од клиентите и кои потоци течат од мултикаст сервери.
На пример, кога ќе се прими извештај за членство во IGMP или PIM Join на некој интерфејс, запис од типот ( *, G ) се додава во рутирачката табела:

Овој запис значи дека е примено барање за сообраќај со адреса 238.38.38.38. Знамето DC значи дека мултикастот ќе работи во режим на густа, а C значи дека примачот е директно поврзан со рутерот, односно рутерот го добил Извештајот за членство во IGMP и PIM Join.
Ако има запис од типот (S,G) тоа значи дека имаме мултикаст поток:

Во полето S - 192.168.1.11, ја регистриравме IP адресата на мултикаст изворот, токму тоа ќе се провери со правилото RPF. Ако има проблеми, првото нешто што треба да направите е да ја проверите уникаст табелата за маршрутата до изворот. Во полето Влезен интерфејс, го означува интерфејсот на кој се прима мултикастот. Во уникаст рутирачка табела, маршрутата до изворот мора да се однесува на интерфејсот наведен овде. Појдовниот интерфејс одредува каде ќе се пренасочува мултикасетот. Ако е празен, тогаш рутерот не добил никакви барања за овој сообраќај. Повеќе информации за сите знамиња може да се најдат тука.
Редок режим на PIM.
Стратегијата на Sparse-mode е спротивна на Dense-mode. Кога Sparse-mode добива повеќекратен сообраќај, тој ќе испраќа сообраќај само преку оние интерфејси каде што имало барања за овој тек, на пример пораки Pim Join или IGMP Report што го бараат овој сообраќај.
Слични елементи за SM и DM:

• Односите со соседството се градат на ист начин како и во PIM DM.
• Правилото RPF работи.
• Изборот на DR е сличен.
• Механизмот на Prune Overrides и Assert пораките се слични.

За да се контролира кој, каде и каков вид на мултикаст сообраќај е потребен на мрежата, потребен е заеднички информативен центар. Наш центар ќе биде Randevous Point (RP). Секој што сака некаков мултикаст сообраќај или некој почнал да добива мултикаст сообраќај од изворот, тогаш го испраќа до RP.
Кога RP ќе добие мултикаст сообраќај, ќе го испрати до оние рутери кои претходно го побарале овој сообраќај.

Ајде да замислиме топологија каде RP е R3. Штом R1 ќе добие сообраќај од S1, го инкапсулира овој мултикаст пакет во уникаст PIM Регистар порака и го испраќа до RP. Од каде знае кој е РП? Во овој случај, тој е конфигуриран статички, а подоцна ќе зборуваме за динамичка RP конфигурација.

ip pim rp-адреса 3.3.3.3

РП ќе изгледа - имаше ли информации од некој што би сакал да го добие овој сообраќај? Да претпоставиме дека не беше. Потоа RP ќе му испрати на R1 порака PIM Register-Stop, што значи дека никому не му треба оваа мултикаст, регистрацијата е одбиена. R1 нема да испрати мултикаст. Но, мултикаст изворниот домаќин ќе го испрати, така што R1, по добивањето на Register-Stop, ќе започне со тајмер за потиснување на регистрација еднаков на 60 секунди. 5 секунди пред истекот на овој тајмер, R1 ќе испрати празна порака за регистрација со бит Null-Register (што значи, без инкапсулиран мултикаст пакет) кон RP. RP, пак, ќе дејствува вака:

• Ако немаше примачи, тогаш ќе одговори со порака Регистрирај-Стоп.
• Ако се појават приматели, тој нема да одговори на тоа на кој било начин. R1, откако не добил одбивање да се регистрира во рок од 5 секунди, ќе биде среќен и ќе испрати порака за Регистрација со инкапсулирана мултикаст до RP.

Се чини дека сфативме како multicast достигнува RP, сега ајде да се обидеме да одговориме на прашањето како RP доставува сообраќај до примачите. Овде е неопходно да се воведе нов концепт - дрво на корен-патека (RPT). RPT е дрво вкоренето во RP, кое расте кон примателите, разгранувајќи се на секој PIM-SM рутер. RP го создава со примање пораки за PIM Join и додава нова гранка на дрвото. И така, секој низводно рутер го прави тоа. Општото правило изгледа вака:

• Кога PIM-SM рутер добива порака за PIM Join на кој било интерфејс освен интерфејсот зад кој се крие RP, тој додава нова гранка на дрвото.
• Се додава и гранка кога рутерот PIM-SM добива извештај за членство во IGMP од директно поврзан домаќин.

Да замислиме дека имаме мултикаст клиент на рутерот R5 за групата 228.8.8.8. Штом R5 го прими Извештајот за членство во IGMP од домаќинот, R5 испраќа PIM Join во насока на RP, и самиот додава интерфејс на дрвото што гледа во домаќинот. Следно, R4 добива PIM Join од R5, додава интерфејс Gi0/1 на дрвото и испраќа PIM Join во насока на RP. Конечно, RP ( R3 ) добива PIM Join и додава Gi0/0 на дрвото. Така, мултикаст примачот е регистриран. Градиме дрво со корен R3-Gi0/0 → R4-Gi0/1 → R5-Gi0/0.
После ова, PIM Join ќе биде испратен до R1 и R1 ќе започне да испраќа сообраќај со повеќекратни емитувања. Важно е да се напомене дека ако домаќинот побарал сообраќај пред да започне мултикаст емитувањето, тогаш RP нема да испрати PIM Join и нема да испрати ништо до R1 воопшто.
Ако одеднаш додека се испраќа мултикаст, домаќинот престане да сака да го прими, штом RP добие PIM Prune на интерфејсот Gi0/0, веднаш ќе испрати PIM Register-Stop директно до R1, а потоа PIM Prune порака преку интерфејсот Gi0/1. PIM Register-stop се испраќа преку unicast на адресата од која дојде PIM регистарот.
Како што рековме претходно, штом рутер испрати PIM Join на друг, на пример R5 до R4, тогаш записот се додава на R4:

И се стартува тајмер кој R5 мора постојано да го ресетира овој тајмер PIM Постојано придружувајте се на пораките, инаку R4 ќе биде исклучен од списокот на појдовни. R5 ќе испраќа на секои 60 PIM Join пораки.
Префрлување на дрвото со најкраток пат.
Ќе додадеме интерфејс помеѓу R1 и R5 и ќе видиме како сообраќајот тече со оваа топологија.

Да претпоставиме дека сообраќајот бил испратен и примен според старата шема R1-R2-R3-R4-R5, и тука го поврзавме и конфигуриравме интерфејсот помеѓу R1 и R5.
Пред сè, треба да ја обновиме уникастната рутирачка табела на R5 и сега до мрежата 192.168.1.0/24 се доаѓа преку интерфејсот R5 Gi0/2. Сега R5, примајќи мултикаст на интерфејсот Gi0/1, разбира дека правилото RPF не е задоволено и би било пологично да добие мултикаст на Gi0/2. Треба да се исклучи од RPT и да изгради пократко дрво наречено Дрво на најкратката патека (SPT). За да го направите ова, тој испраќа PIM Join до R0 преку Gi2/1 и R1 почнува да испраќа мултикаст исто така преку Gi0/2. Сега R5 треба да се откаже од RPT за да не добие две копии. За да го направите ова, тој му испраќа на Prune порака која ја означува изворната IP адреса и вметнува посебен бит - RPT-bit. Ова значи дека не треба да ми испраќате сообраќај, имам подобро дрво овде. RP, исто така, испраќа PIM Prune пораки до R1, но не испраќа порака за Регистрирај-Стоп. Друга карактеристика: R5 сега постојано ќе испраќа PIM Prune до RP, бидејќи R1 продолжува да испраќа PIM Register до RP секоја минута. Сè додека нема нови луѓе кои го сакаат овој сообраќај, RP ќе го одбие. R5 го известува RP дека продолжува да прима мултикаст преку SPT.
Динамично RP пребарување.
Auto-RP.
Оваа технологија е сопственост на Cisco и не е особено популарна, но сè уште е жива. Работата на Auto-RP се состои од две главни фази:
1) RP испраќа RP-Објави пораки на резервираната адреса - 224.0.1.39, декларирајќи се како RP или за секого или за одредени групи. Оваа порака се испраќа секоја минута.
2) Потребен е агент за мапирање RP, кој ќе испраќа пораки RP-Discovery кои ќе означат за кои групи кои RP треба да се слушаат. Токму од оваа порака обичните PIM рутери сами ќе го одредат RP. Агентот за мапирање може да биде или самиот RP рутер или посебен PIM рутер. RP-Discovery се испраќа на адреса 224.0.1.40 со тајмер од една минута.
Ајде да го разгледаме процесот подетално:
Ајде да го конфигурираме R3 како RP:

ip pim send-rp-announce loopback 0 опсег 10

R2 како агент за мапирање:

ip pim send-rp-discovery loopback 0 опсег 10

И на сите други ќе очекуваме RP преку Auto-RP:

ip pim autorp слушател

Откако ќе го конфигурираме R3, тој ќе започне да испраќа RP-Announce:

И R2, откако ќе го постави агентот за мапирање, ќе почне да ја чека пораката RP-Announce. Само кога ќе најде барем еден RP, ќе започне да испраќа RP-Discovery:

На овој начин, штом обичните рутери (PIM RP listener) ја добијат оваа порака, тие ќе знаат каде да го бараат RP.
Еден од главните проблеми со Auto-RP е тоа што за да примате пораки RP-Announce и RP-Discovery, треба да испратите PIM Join на адресите 224.0.1.39-40, а за да испратите, треба да знаете каде РП се наоѓа. Класичен проблем со пилешко и јајца. За да се реши овој проблем, измислен е PIM Sparse-Dense-Mode. Ако рутерот не знае RP, тогаш работи во густ режим; ако знае, тогаш во редок режим. Кога PIM Sparse-mode и командата ip pim autorp listener се конфигурирани на интерфејсите на обичните рутери, рутерот ќе работи во Dense-mode само за multicasting директно од протоколот Auto-RP (224.0.1.39-40).
BootStrap рутер (BSR).
Оваа функција работи слично на Auto-RP. Секој RP испраќа порака до агентот за мапирање, кој собира информации за мапирањето и потоа им кажува на сите други рутери. Ајде да го опишеме процесот слично како Auto-RP:
1) Откако ќе го конфигурираме R3 како кандидат да биде RP, со командата:

ip pim rp-кандидат за враќање назад 0

Тогаш R3 нема да направи ништо; за да започне да испраќа специјални пораки, прво треба да најде агент за мапирање. Така, преминуваме на вториот чекор.
2) Конфигурирајте го R2 како агент за мапирање:

ip pim bsr-кандидат за враќање назад 0

R2 започнува да испраќа PIM Bootstrap пораки, каде што се покажува како агент за мапирање:

Оваа порака се испраќа на адресата 224.0.013, која протоколот PIM ја користи и за своите други пораки. Ги праќа во сите правци и затоа нема проблем со кокошката и јајцата како што беше во Auto-RP.
3) Штом RP прими порака од рутерот BSR, веднаш ќе испрати порака за unicast до адресата на рутерот BSR:

После тоа, BSR, откако доби информации за RP, ќе ги испрати со мултикаст на адресата 224.0.0.13, која ја слушаат сите PIM рутери. Затоа, аналог на командата ip pim autorp слушател за обични рутери кои не се во BSR.
Anycast RP со Multicast Source Discovery Protocol (MSDP).
Auto-RP и BSR ни дозволуваат да го дистрибуираме оптоварувањето на RP на следниов начин: Секоја мултикаст група има само еден активен RP. Нема да биде можно да се дистрибуира оптоварувањето за една мултикаст група преку неколку RP. MSDP го прави ова со издавање на RP рутери со иста IP адреса со маска од 255.255.255.255. MSDP учи информации користејќи еден од методите: статички, Auto-RP или BSR.

На сликата имаме Auto-RP конфигурација со MSDP. Двата RP се конфигурирани со IP адреса 172.16.1.1/32 на интерфејсот Loopback 1 и се користат за сите групи. Со RP-Announce, двата рутери се најавуваат со повикување на оваа адреса. Агентот за мапирање Auto-RP, откако ги добил информациите, испраќа RP-Discovery за RP со адреса 172.16.1.1/32. Ние им кажуваме на рутерите за мрежата 172.16.1.1/32 користејќи IGP и, соодветно. Така, PIM рутерите бараат или регистрираат текови од RP што е наведено како следен скок на рутата до мрежата 172.16.1.1/32. Самиот протокол MSDP е дизајниран за самите RP да разменуваат пораки за мултикаст информации.
Размислете за оваа топологија:

Switch6 емитува сообраќај до адресата 238.38.38.38 и засега само RP-R1 знае за тоа. Switch7 и Switch8 ја побараа оваа група. Рутерите R5 и R4 ќе испратат PIM Join до R1 и R3, соодветно. Зошто? Трасата до 13.13.13.13 за R5 ќе се однесува на R1 користејќи ја метриката IGP, исто како и за R4.
RP-R1 знае за потокот и ќе почне да го емитува кон R5, но R4 не знае ништо за тоа, бидејќи R1 нема едноставно да го испрати. Затоа, МСДП е неопходен. Ние го конфигурираме на R1 и R5:

ip msdp peer 3.3.3.3 connect-source Loopback1 на R1

ip msdp peer 1.1.1.1 connect-source Loopback3 на R3

Тие ќе подигнат сесија меѓу себе и кога ќе добијат било каков проток ќе го пријават на нивниот сосед RP.
Штом RP-R1 добие пренос од Switch6, веднаш ќе испрати уникаст MSDP Source-Active порака, која ќе содржи информации како (S, G) - информации за изворот и дестинацијата на мултикастот. Сега кога RP-R3 знае дека извор како што е Switch6, кога прима барање од R4 за овој тек, ќе испрати PIM Join кон Switch6, водени од табелата за насочување. Следствено, R1 откако добил таков PIM Join ќе започне да испраќа сообраќај кон RP-R3.
MSDP работи преку TCP, RP-ите си испраќаат пораки за одржување за да ја проверат живоста. Тајмерот е 60 секунди.
Функцијата за поделба на MSDP врсниците во различни домени останува нејасна, бидејќи пораките Keepalive и SA не укажуваат на членство во ниеден домен. Исто така, во оваа топологија, тестиравме конфигурација што покажува различни домени - немаше разлика во перформансите.
Ако некој може да појасни, со задоволство би го прочитал во коментар.

Извор: www.habr.com