Принципи на работа на протокола PIM

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

PIM използва два основни режима на работа — Dense и Sparse mode. Нека започнем с Dense mode.
Source-Based Distribution Trees.
Dense-mode режимът е целесообразно да се използва в случай на голям брой клиенти от различни мултикаст групи. Когато рутер получи мултикаст трафик, той първо проверява правилото RPF. RPF — това правило се използва за проверка на източника на мултикаста с таблицата за маршрутиране на юникаст. Трафикът трябва да идва по интерфейса, под който се крие този хост според таблицата за маршрутиране на юникаст. Този механизъм решава проблема с възникването на цикли при предаването на мултикаст.

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

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

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

• Когато multicast пакетът не е преминал проверката RPF.
• Когато няма локално свързани клиенти, които да са поискали multicast групата (IGMP Join) и няма PIM съседи, на които да се изпраща multicast трафик (Non-prune Interface).

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

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

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

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

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

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

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

В полето S — 192.168.1.11, имаме зададен IP адрес на източника на мултикаста, именно той ще бъде проверен от правилото RPF. При проблеми, първото нещо, което трябва да се провери, е юникастовата таблица за маршрут до източника. В полето Incoming Interface се посочва интерфейсът, на който постъпва мултикастът. В юникастовата таблица за маршрутизиране маршрутът до източника трябва да сочи към интерфейса, посочен тук. В Outgoing Interface се указва къде ще бъде пренасочен мултикастът. Ако е празно, значи към маршрутизатора не е получавано запитване за този трафик. По-подробна информация за всички флагове можете да намерите тук..
PIM Sparse-mode.
Стратегията 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 Register съобщение и го изпраща на RP. Как знае кой е RP? В този случай, той е настроен статично, а за динамичното настройване на RP ще говорим по-късно.

ip pim rp-address 3.3.3.3

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

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

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

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

Представете си, че имаме клиент на мултикаст на рутера R5 за групата 228.8.8.8. След получаването на 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.
Ако по време на изпращането на мултикаста хостът спре да иска да го получава, веднага след получаването на PIM Prune на интерфейса Gi0/0, RP ще изпрати PIM Register-Stop директно на R1, а след това и PIM Prune съобщение през интерфейса Gi0/1. PIM Register-Stop се изпраща като юникаст на адреса, от който е получено PIM Register.
Както споменахме по-рано, щом маршрутизаторът изпрати PIM Join на друг, например R5 на R4, то на R4 се добавя запис:

И се стартира таймер, който R5 трябва постоянно да нулира с PIM Join съобщения, иначе R4 ще изключи елемента от outgoing list. R5 ще изпраща PIM Join съобщения на всеки 60 секунди.
Смяна на най-краткото дърво на пътя.
Ще добавим интерфейс между R1 и R5 и ще видим как трафикът ще тече при тази топология.

Да предположим, че трафикът се е изпращал и получавал по старата схема R1-R2-R3-R4-R5 и сега сме свързали и конфигурирали интерфейс между R1 и R5.
Първото нещо е, че юникастовата таблица за маршрутизация на R5 ще се пренастрои и сега мрежата 192.168.1.0/24 ще се достига през интерфейса R5 Gi0/2. Сега, получавайки мултикаст на интерфейса Gi0/1, R5 разбира, че правилото RPF не е удовлетворено и е по-разумно да получава мултикаст на Gi0/2. Той трябва да се отключи от RPT и да изгради по-кратко дърво, наречено Shortest-Path Tree (SPT). За това той изпраща PIM Join през Gi0/2 към R1 и R1 започва да изпраща мултикаст и през Gi0/2. Сега R5 трябва да се откаже от RPT, за да не получава две копия. За това той изпраща Prune съобщение, указвайки IP адреса на източника и добавяйки специален бит — RPT-bit. Това означава, че не трябва да ми изпращате трафик, имам по-добро дърво тук. RP също така изпраща PIM Prune съобщения към R1, но не изпраща Register-Stop съобщение. Още една особеност: R5 сега ще изпраща постоянно PIM Prune на RP, тъй като R1 продължава да изпраща PIM Register на RP всяка минута. RP, докато няма нови желаещи за този трафик, ще отговаря с отказ. R5 уведомява RP, че продължава да получава мултикаст през SPT.
Динамично търсене на RP.
Auto-RP.
Тази технология е собственост на Cisco и не е особено популярна, но все пак съществува. Работата на Auto-RP се състои от два основни етапа:
1) RP изпраща съобщения RP-Announce на запазения адрес — 224.0.1.39, обявявайки се за RP, било то за всички, или за определени групи. Това съобщение се изпраща всяка минута.
2) Необходим е RP mapping agent, който да изпраща съобщения RP-Discovery с информация за това за кои групи кой RP трябва да се слуша. Именно от това съобщение обикновените PIM маршрутизатори ще определят своя RP. Mapping Agent може да бъде както самият RP маршрутизатор, така и различен PIM маршрутизатор. RP-Discovery се изпраща на адрес 224.0.1.40 с таймер от една минута.
Нека разгледаме процеса по-подробно:
Нека настроим R3 като RP:

ip pim send-rp-announce loopback 0 scope 10

R2 като mapping agent:

ip pim send-rp-discovery loopback 0 scope 10

А на всички останали ще очакваме RP чрез Auto-RP:

ip pim autorp listener

Веднага щом настроим R3, той ще започне да изпраща RP-Announce:

А R2, след като бъде настроен като mapping agent, ще започне да чака съобщения RP-Announce. Само когато намери поне един RP, ще започне да изпраща RP-Discovery:

Така, когато обикновените маршрутизатори (PIM RP Listener) получат тези съобщения, те ще знаят къде да търсят RP.
Една от основните проблеми на Auto-RP е, че за да получавате съобщения RP-Announce и RP-Discovery, е необходимо да изпратите PIM Join на адресите 224.0.1.39-40, а за да изпратите, трябва да знаете къде се намира RP. Класическата задача 'птица и яйце'. За решаване на този проблем беше измислен режимът PIM Sparse-Dense-Mode. Ако маршрутизаторът не знае RP, той работи в режим Dense-mode; ако знае, то в режим Sparse-mode. Когато на интерфейсите на обикновените маршрутизатори е настроен PIM Sparse-mode и командата ip pim autorp listener, маршрутизаторът ще работи в режим Dense-mode само за multicast, свързан с Auto-RP протокола (224.0.1.39-40).
BootStrap Router (BSR).
Тази функция работи подобно на Auto-RP. Всеки RP изпраща съобщение до mapping agent-a, който събира информация за мапинг и след това я предава на всички останали маршрутизатори. Нека опишем процеса, аналогично на Auto-RP:
1) Веднага щом настроим R3 като кандидат за RP с командата:

ip pim rp-candidate loopback 0

R3 няма да направи нищо, за да започне да изпраща специални съобщения, първо трябва да намери mapping agent-ът. Така преминаваме към втория етап.
2) Настройваме R2 като mapping agent:

ip pim bsr-candidate loopback 0

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

Това съобщение се изпраща на адрес 224.0.0.13, който PIM протоколът използва и за други свои съобщения. Той ги изпраща във всички посоки, така че няма проблем с пилето и яйцето, както беше при Auto-RP.
3) Веднага щом RP получи съобщение от BSR маршрутизатора, той незабавно изпраща юникастово съобщение на адреса на BSR маршрутизатора:

След което, BSR, получавайки информация за RP, ще я разпрати multicast на адрес 224.0.0.13, на който слушат всички PIM маршрутизатори. Следователно, аналог на командата ip pim autorp listener за обикновените маршрутизатори не съществува в 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 mapping agent, получавайки информация, разпространява RP-Discovery за RP с адрес 172.16.1.1/32. За мрежата 172.16.1.1/32, маршрутизаторите се информират чрез IGP. По този начин, PIM маршрутизаторите запитват или регистрират потоци от RP, който е посочен като next-hop за маршрута към мрежата 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 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 си изпращат keepalive съобщения помежду си, за да проверяват жизнеспособността. Таймерът е 60 секунди.
Не е ясна функцията за разделяне на MSDP пирсовете в различни домейни, тъй като в keepalive и SA съобщенията не се указва принадлежност към определен домейн. Също така в тази топология беше тествана конфигурация с указание на различни домейни — нямаше разлика в работата.
Ако някой може да внесе яснота, с радост ще прочета в коментарите.

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