Пратакол PIM - гэта набор пратаколаў для перадачы мультыкаста ў сеткі паміж маршрутызатарамі. Адносіны суседства будуюцца аналагічна як і ў выпадку дынамічных пратаколаў маршрутызацыі. PIMv2 адпраўляе кожныя 30 секунд Hello паведамлення на зарэзерваваны мультыкаст адрас 224.0.0.13 ( All-PIM-Routers ). Паведамленне змяшчае ў сабе Hold Timers - звычайна роўны 3.5 * Hello Timer, гэта значыць 105 секунд па змаўчанні.
PIM выкарыстоўвае два асноўных рэжыму працы – Dense і Sparse mode. Пачнём c 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:
ПІМ Пруна электроннай пошты з'яўляецца адным routerам для другога router да з'яўляецца другім зыходным зыходным зыходным кодам для таго, каб адправіць link on which Prune received from 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 c адрасам 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