Как работи протоколът PIM

Протоколът PIM е набор от протоколи за предаване на мултикаст в мрежа между рутери. Съседските връзки се изграждат по същия начин, както в случая с протоколите за динамично маршрутизиране. PIMv2 изпраща Hello съобщения на всеки 30 секунди до запазения мултикаст адрес 224.0.0.13 (Всички PIM-маршрутизатори). Съобщението съдържа таймери за задържане - обикновено е равно на 3.5*Hello Timer, което е 105 секунди по подразбиране.

PIM използва два основни режима на работа - Dense и Sparse режим. Да започнем с режим Dense.
Базирани на източника разпределителни дървета.
Режимът на плътен режим е препоръчително да се използва в случай на голям брой клиенти от различни групи за мултикаст. Когато рутерът получи мултикаст трафик, първото нещо, което прави, е да го провери за правилото RPF. RPF - това правило се използва за проверка на източника на мултикаст с уникаст таблица за маршрутизиране. Необходимо е трафикът да пристига до интерфейса, зад който е скрит този хост, според версията на таблицата за маршрутизиране на едноадресно предаване. Този механизъм решава проблема с възникването на цикъл по време на мултикаст предаване.

R3 ще разпознае мултикаст източника (Source IP) от мултикаст съобщението и ще провери двата потока от R1 и R2, използвайки своята таблица за едноадресно предаване. Потокът от интерфейса, посочен от таблицата (R1 до R3), ще бъде предаден по-нататък, а потокът от R2 ще бъде премахнат, тъй като за да стигнете до източника на мултикаст, трябва да изпратите пакети през S0/1.
Въпросът е какво се случва, ако имате два еквивалентни маршрута с една и съща метрика? В този случай рутерът ще избере следващия хоп от тези маршрути. Който има по-висок IP адрес, печели. Ако трябва да промените това поведение, можете да използвате ECMP. Повече информация тук.
След проверка на правилото RPF, рутерът изпраща мултикаст пакет до всички свои PIM съседи, с изключение на този, от който е получен пакетът. Други PIM рутери повтарят този процес. Пътят, който един мултикаст пакет е извървял от източника до крайните получатели, образува дърво, наречено дърво на разпространение, базирано на източника, дърво на най-краткия път (SPT), дърво на източника. Три различни имена, изберете което и да е.
Как да се реши проблема, че някои рутери не са се отказали от някакъв мултикаст поток и няма на кого да го изпрати, но upstream рутера му го изпраща. Механизмът Prune е изобретен за това.
Подрязване на съобщение.
Например, R2 ще продължи да изпраща мултикаст към R3, въпреки че R3, според правилото RPF, го изпуска. Защо да заредите канала? R3 изпраща PIM Prune Message и R2, при получаване на това съобщение, ще премахне интерфейс S0/1 от списъка с изходящи интерфейси за този поток, списъкът с интерфейси, от които този трафик трябва да бъде изпратен.

Следното е по-официална дефиниция на съобщение за PIM Prune:
Съобщението PIM Prune се изпраща от един рутер към втори рутер, за да накара вторият рутер да премахне връзката, на която е получено Prune от определен (S,G) SPT.

След получаване на съобщението за изрязване, R2 настройва таймера за изрязване на 3 минути. След три минути ще започне отново да изпраща трафик, докато не получи ново съобщение за съкращаване. Това е в PIMv1.
А в PIMv2 е добавен таймер за обновяване на състоянието (60 секунди по подразбиране). Веднага щом съобщението за изрязване е изпратено от R3, този таймер се стартира на R3. При изтичане на този таймер R3 ще изпрати съобщение за обновяване на състоянието, което ще нулира 3-минутния таймер за изрязване на R2 за тази група.
Причини за изпращане на съобщение за изрязване:

• Когато мултикаст пакет е неуспешен при проверката на RPF.
• Когато няма локално свързани клиенти, които са поискали мултикаст група (IGMP Join) и няма PIM съседи, към които може да се изпраща мултикаст трафик (интерфейс без подрязване).

Съобщение за присаждане.
Нека си представим, че R3 не иска трафик от R2, изпраща Prune и получава мултикаст от R1. Но изведнъж каналът между R1-R3 падна и R3 остана без мултикаст. Можете да изчакате 3 минути, докато изтече таймерът за изрязване на R2. 3 минути са дълго чакане, за да не чакате, трябва да изпратите съобщение, което незабавно ще изведе този S0/1 интерфейс към R2 от съкратеното състояние. Това съобщение ще бъде съобщение за присаждане. След получаване на съобщението за присаждане, R2 ще отговори с Graft-ACK.
Отмяна на подрязване.

Нека да разгледаме тази диаграма. R1 излъчва мултикаст към сегмент с два рутера. R3 получава и излъчва трафик, R2 получава, но няма към кого да излъчва трафик. Той изпраща съобщение за изрязване до R1 в този сегмент. R1 трябва да премахне Fa0/0 от списъка и да спре излъчването в този сегмент, но какво ще стане с R3? И R3 е в същия сегмент, също получи това съобщение от Prune и разбра трагедията на ситуацията. Преди R1 да спре излъчването, той настройва таймер от 3 секунди и ще спре излъчването след 3 секунди. 3 секунди - точно толкова време има R3, за да не загуби своя мултикаст. Следователно R3 изпраща съобщение Pim Join за тази група възможно най-скоро и R1 вече не мисли да спира излъчването. Относно съобщенията за присъединяване по-долу.
Потвърдете съобщение.

Нека си представим тази ситуация: два рутера излъчват към една мрежа едновременно. Те получават един и същ поток от източника и го излъчват към една и съща мрежа зад интерфейс e0. Следователно те трябва да определят кой ще бъде единственият оператор за тази мрежа. За това се използват съобщения за потвърждаване. Когато R2 и R3 открият дублиране на мултикаст трафик, тоест R2 и R3 получават мултикаст, който самите те излъчват, рутерите разбират, че тук нещо не е наред. В този случай рутерите изпращат Assert съобщения, които включват Administrative Distance и метриката на маршрута, с която се достига до мултикаст източника - 10.1.1.10. Победителят се определя както следва:

1. Този с по-ниско AD.
2. Ако AD са равни, тогава кой има по-ниската метрика.
3. Ако тук има равенство, тогава този, който има по-високо IP в мрежата, към която излъчват този мултикаст.

Победителят в това гласуване става Определен рутер. Pim Hello също се използва за избор на DR. В началото на статията беше показано съобщението PIM Hello, можете да видите полето DR там. Този с най-висок IP адрес на тази връзка печели.
Полезен знак:

MROUTE Таблица.
След първоначален поглед върху това как работи протоколът PIM, трябва да разберем как да работим с таблица за мултикаст маршрутизиране. Таблицата mroute съхранява информация за това кои потоци са били поискани от клиенти и кои потоци текат от мултикаст сървъри.
Например, когато IGMP Membership Report или PIM Join се получи на някакъв интерфейс, запис от тип ( *, G ) се добавя към таблицата за маршрутизиране:

Този запис означава, че е получено искане за трафик с адрес 238.38.38.38. Флагът DC означава, че мултикастът ще работи в плътен режим, а C означава, че получателят е директно свързан с рутера, т.е. рутерът е получил IGMP Membership Report и PIM Join.
Ако има запис от тип (S,G), това означава, че имаме мултикаст поток:

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

• Междусъседските отношения се изграждат по същия начин, както в PIM DM.
• Правилото RPF работи.
• Изборът на DR е подобен.
• Механизмът на съобщенията Prune Overrides и Assert е подобен.

За да се контролира кой, къде и какъв вид мултикаст трафик е необходим в мрежата, е необходим общ информационен център. Нашият център ще бъде Rendezvous Point (RP). Всеки, който иска някакъв вид мултикаст трафик или някой е започнал да получава мултикаст трафик от източника, след това го изпраща на RP.
Когато RP получи мултикаст трафик, той ще го изпрати до онези рутери, които преди това са поискали този трафик.

Нека си представим топология, където RP е R3. Веднага щом R1 получи трафик от S1, той капсулира този мултикаст пакет в едноадресно PIM регистърно съобщение и го изпраща на RP. Откъде знае кой е RP? В този случай той е конфигуриран статично и ще говорим за динамична RP конфигурация по-късно.

ip pim rp-адрес 3.3.3.3

RP ще погледне - имаше ли информация от някой, който би искал да получи този трафик? Да приемем, че не е било. След това RP ще изпрати на R1 съобщение PIM Register-Stop, което означава, че никой не се нуждае от този мултикаст, регистрацията е отказана. R1 няма да изпраща мултикаст. Но хостът източник на мултикаст ще го изпрати, така че R1, след като получи Register-Stop, ще стартира таймер за потискане на регистъра, равен на 60 секунди. 5 секунди преди изтичането на този таймер, R1 ще изпрати празно съобщение за регистър с бит Null-Register (т.е. без капсулиран мултикаст пакет) към RP. RP от своя страна ще действа така:

• Ако няма получатели, то ще отговори със съобщение за спиране на регистрацията.
• Ако се появят получатели, той няма да отговори на това по никакъв начин. R1, след като не е получил отказ за регистрация в рамките на 5 секунди, ще се радва и ще изпрати съобщение за регистрация с капсулиран мултикаст към RP.

Изглежда разбрахме как мултикаст достига RP, сега нека се опитаме да отговорим на въпроса как RP доставя трафик на получателите. Тук е необходимо да се въведе ново понятие - root-path tree (RPT). RPT е дърво, вкоренено в RP, растящо към получателите, разклонено на всеки PIM-SM рутер. RP го създава чрез получаване на PIM Join съобщения и добавя нов клон към дървото. И така, всеки рутер надолу по веригата го прави. Общото правило изглежда така:

• Когато PIM-SM рутер получи PIM Join съобщение на всеки интерфейс, различен от интерфейса, зад който е скрит RP, той добавя нов клон към дървото.
• Добавя се също клон, когато PIM-SM рутерът получи отчет за членство в IGMP от директно свързан хост.

Нека си представим, че имаме мултикаст клиент на рутера R5 за група 228.8.8.8. Веднага щом R5 получи IGMP Membership Report от хоста, 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 Join съобщения постоянно, в противен случай 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-бит. Това означава, че не е нужно да ми изпращате трафик, имам по-добро дърво тук. RP също изпраща съобщения за PIM Prune до R1, но не изпраща съобщение за спиране на регистъра. Друга функция: R5 вече непрекъснато ще изпраща PIM Prune към RP, тъй като R1 продължава да изпраща PIM Register към RP всяка минута. Докато няма нови хора, които искат този трафик, RP ще го отказва. R5 уведомява RP, че продължава да получава мултикаст чрез SPT.
Динамично RP търсене.
Авто-RP.
Тази технология е собственост на Cisco и не е особено популярна, но все още е жива. Работата на Auto-RP се състои от два основни етапа:
1) RP изпраща RP-Announce съобщения до запазения адрес - 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 изпращане-rp-откриване 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 само за мултикастинг директно от Auto-RP протокола (224.0.1.39-40).
Рутер BootStrap (BSR).
Тази функция работи подобно на Auto-RP. Всеки RP изпраща съобщение до агента за картографиране, който събира информация за картографиране и след това съобщава на всички други рутери. Нека опишем процеса подобно на Auto-RP:
1) След като конфигурираме R3 като кандидат за RP, с командата:

ip pim rp-кандидат loopback 0

Тогава R3 няма да направи нищо; за да започне да изпраща специални съобщения, той първо трябва да намери агент за картографиране. Така преминаваме към втората стъпка.
2) Конфигурирайте R2 като агент за картографиране:

ip pim bsr-кандидат loopback 0

R2 започва да изпраща PIM Bootstrap съобщения, където се посочва като агент за картографиране:

Това съобщение се изпраща на адрес 224.0.013, който PIM протоколът използва и за другите си съобщения. Той ги изпраща във всички посоки и следователно няма проблем с кокошката и яйцето, както беше в Auto-RP.
3) Веднага щом RP получи съобщение от BSR рутера, той незабавно ще изпрати едноадресно съобщение до адреса на 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 няма просто да го изпрати. Следователно MSDP е необходим. Ние го конфигурираме на R1 и R5:

ip msdp peer 3.3.3.3 свързване на източник Loopback1 на R1

ip msdp peer 1.1.1.1 свързване на източник Loopback3 на R3

Те ще създадат сесия помежду си и когато получат някакъв поток, ще го докладват на своя RP съсед.
Веднага след като RP-R1 получи поток от Switch6, той незабавно ще изпрати едноадресно MSDP Source-Active съобщение, което ще съдържа информация като (S, G) - информация за източника и дестинацията на мултикаст. Сега, когато RP-R3 знае, че източник като Switch6, когато получи заявка от R4 за този поток, той ще изпрати PIM Join към Switch6, ръководен от таблицата за маршрутизиране. Следователно R1, след като получи такова PIM присъединяване, ще започне да изпраща трафик към RP-R3.
MSDP работи през TCP, RP изпращат един на друг съобщения за поддържане на активността, за да проверят жизнеността. Таймерът е 60 секунди.
Функцията за разделяне на партньорите на MSDP в различни домейни остава неясна, тъй като съобщенията Keepalive и SA не показват членство в нито един домейн. Освен това в тази топология тествахме конфигурация, указваща различни домейни - нямаше разлика в производителността.
Ако някой може да изясни, ще се радвам да го прочета в коментарите.

Източник: www.habr.com