Протокол 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 мультикаст, хоча R3 за правилом RPF драпає його. Навіщо навантажувати канал? R3 шле PIM Prune Message і R2, при отриманні даного повідомлення, видалить інтерфейс S0/1 зі списку (outgoing interface list) для цього потоку, список інтерфейсів, з яких треба надсилати цей трафік.
Наступним є більш правильна definition of PIM Prune message:
PIM Prune message is sent by one router to a second router to cause the second router to remove the link on which Prune received from a particular (S,G) SPT.
Після отримання Prune повідомлення, R2 виставляє Prune таймер у 3 хвилини. Через три хвилини він почне відправляти трафік знову, доки не отримає чергового Prune повідомлення. Це в PIMv1.
А в PIMv2 доданий State Refresh таймер (за замовчуванням 60 секунд). Як тільки надіслано Prune повідомлення з R3, запускається даний таймер на R3. Після закінчення цього таймера, R3 відправлятиме State Refresh повідомлення, яке буде скидати 3-х хвилинний Prune Timer на R2 для цієї групи.
Причини надсилання повідомлення Prune:
- Коли мультикаст пакет не пройшов перевірку RPF.
- Коли немає локально підключених клієнтів, який запросив мультикастову групу (IGMP Join) і немає PIM сусідів, яким можна надсилати мультикастовий трафік (Non-prune Interface).
Graft Message.
Припустимо, що R3 не захотів трафік від R2, відправив Prune і отримував мультикаст від R1. Але раптом упав канал між R1-R3 та R3 залишився без мультикасту. Можна чекати 3 хвилини, поки R2 не спливе Prune Timer. Три хвилини чекати довго, ніж чекати, потрібно надіслати повідомлення, яке миттєво виведе цей інтерфейс S3/0 на R1 з 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 Message.
Уявимо таку ситуацію: в одну мережу ведуть мовлення відразу два маршрутизатори. Отримують той самий потік від джерела, і обидва мовлять його в одну мережу за інтерфейсом e0. Тому їм треба визначити, хто ж буде одним єдиним мовником для цієї мережі. Для цього використовуються повідомлення Assert. Коли R2 та R3 детектують дуплікацію мультикаст трафіку, тобто на R2 та R3 приходить мультикаст, який вони самі ведуть мовлення, маршрутизатори розуміють, що тут щось не так. Маршрутизатори відправляють у цьому випадку Assert повідомлення, які включені Administrative Distance і метрика маршруту за допомогою якого досягається джерело мультикасту - 10.1.1.10. Переможець визначається так:
- Той, у кого нижче AD.
- Якщо AD рівні, то у когось нижче метрика.
- Якщо і тут рівність, то той у кого вище IP в мережі, в яку вони ведуть мовлення цей мультикаст.
Переможець у цьому голосуванні маршрутизатор стає Designated Router-ом. Для вибору DR також використовують Pim Hello. На початку статті було показано повідомлення PIM Hello, там можна помітити DR поле. Перемагає той, у кого вище IP-адреси на цьому лінку.
Корисна табличка:
MROUTE Table.
Після початкового розгляду роботи протоколу 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 не надсилатиме мультикаст. Але хост-джерело мультикасту буде надсилати його, так що R1 після отримання Register-Stop, запустить таймер Register-Suppression timer, що дорівнює 60 секунд. За 5 секунд до закінчення даного таймера, 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. Як тільки 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 відправляється юнікастом на ту адресу, з якої надійшло PIM Register.
Як ми говорили раніше, як тільки маршрутизатор відправляє PIM Join іншому, наприклад, R5 на R4, то на R4 додається запис:
І запускається таймер, що скинути даний таймер R5 повинен PIM Join постійно постійно, а то R4 виключить з outgoing list. R5 буде відправляти кожні 60 PIM Join повідомлення.
Shortest-Path Tree Switchover.
Ми додамо інтерфейс між 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 і побудувати коротше дерево, яке називається Shortest-Path Tree (SPT). Для цього він через Gi0/2 відправляє PIM Join на R1 та R1 починає надсилати мультикаст ще й через Gi0/2. Тепер R5 треба відписатися від RPT, ніж отримувати дві копії. Для цього він відправляє Prune повідомлення, вказуючи ip адресу джерела і вставляючи спеціальний біт - RPT-bit. Це означає, що не треба мені посилати трафік, у мене тут краще дерево. RP також відправляє у бік R1 PIM Prune повідомлення, але не надсилає 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 тільки для мультикасту безпосередньо Auto-RP протоколу ( 224.0.1.39-40 ).
BootStrap Router (BSR).
Ця функція працює схоже на Auto-RP. Кожен RP шле повідомлення mapping agent-у, який збирає мапінг інформацію і далі розповідає всім іншим маршрутизаторам. Опишемо процес аналогічно 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.013, яке PIM протокол використовує і для інших своїх повідомлень. Він відправляє їх на всі боки і тому немає проблеми курки та яйця, як було в Auto-RP.
3) Як тільки RP отримає повідомлення від BSR маршрутизатора, він одразу відправить юнікастове повідомлення на адресу BSR маршрутизатора:
Після чого BSR отримавши інформацію про RP, розішле їх мультикастом на адресу 224.0.0.13, який слухають усі PIM маршрутизатори. Тому аналога команди ip pim autorp listener для звичайних маршрутизаторів немає у BSR.
Anycast RP with 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 на даний потік буде надсилати у бік Switch6 PIM Join, керуючись таблицею маршрутизації. Отже, R1 отримавши такий PIM Join, почне надсилати трафік у бік RP-R3.
MSDP працює по TCP, RP посилають один одному keepalive повідомлення для перевірки життєздатності. Таймер дорівнює 60 секунд.
Залишається незрозумілою функція поділу MSDP бенкетів у різні домени, оскільки у повідомленнях Keepalive і SA не вказується належність до домену. Також у цій топології тестувалася зміна із зазначенням різних доменів — різниці у роботі був.
Якщо хтось може внести ясність, радо почитаю в коментарях.
Джерело: habr.com