Мережі для самих маленьких. Частина дев'ята. Мультикаст

  Всі випуски 8.1. Мережі для самих маленьких. Мікровипуск № 3. iBGP
 8. Мережі для самих маленьких. Частина восьма. BGP і IP SLA
 7. Мережі для самих маленьких. Частина сьома. VPN
 6. Мережі для самих маленьких. Частина шоста. Динамічна маршрутизація
 5. Мережі для самих маленьких: Частина п'ята. NAT і ACL
 4. Мережі для самих маленьких: Частина четверта. STP
 3. Мережі для самих маленьких: Частина третя. Статична маршрутизація
 2. Мережі для самих маленьких. Частина друга. Комутація
 1. Мережі для самих маленьких. Частина перша. Підключення до обладнання cisco
 0. Мережі для самих маленьких. Частина нульова. Планування
 
 Наш умоглядний провайдер linkmeup дорослішає і обростає по-тихоньку всіма послугами звичайних операторів зв'язку. Тепер ми доросли до IPTV.
 Звідси випливає необхідність настройки мультікастового маршрутизації і в першу чергу розуміння того, що взагалі таке мультикаст.
 Це перше відхилення від звичних нам принципів роботи IP-мереж. Все-таки парадигма многоадресной розсилки в корені відрізняється від теплого лампового Юнікаст.
 Можна навіть сказати, це в деякій мірі кидає виклик гнучкості вашого розуму в розумінні нових підходів.
 
У цій статті зосередимося на наступному:
    
 
  
  
 
Традиційний видеоурок:
   
 
На зорі мого становлення, як інженера, тема мультикаст мене неймовірно лякала, і я пов'язую це з психотравмой мого першого досвіду з ним.
 «Так, Марат, терміново, до полудня потрібно прокинути відеопотік до нашого нового будинку в центрі міста — провайдер віддасть його нам тут на другому поверсі » — почув я одним чудесним вранці. Все, що я тоді знав про мультикаст, так це те, що відправник один, одержувачів багато, ну і, здається, протокол IGMP там якось задіяний.
 
У підсумку до полудня ми намагалися все це справа запустити — я прокинув самий звичайний VLAN від точки входу до точки виходу. Але сигнал був нестабільним — картинка замерзала, розвалювалася, переривалася. Я в паніці намагався розібратися, що взагалі можна зробити з IGMP, Тиркало, Тиркало, включав мультикаст роутинг, IGMP-snooping, перевіряв по тисячі разів затримки і втрати — нічого не допомагало. А потім раптом все запрацювало. Само собою, стабільно, безвідмовно.
 
Це послужило мені щепленням проти мультикаст, і довгий час я не виявляв до нього ніякого інтересу.
 
Вже набагато пізніше я прийшов у до наступного правила:
  
І тепер з висоти оттраблшученних кейсів я розумію, що там не могло бути ніяких проблем з налаштуванням мережної частини — глючить кінцеве обладнання.
 Зберігайте спокій і довіртеся мені. Після цієї статті такі речі вас лякати не будуть.
 
 
  Загальне розуміння Multicast
 Як відомо, існують такі типи трафіку:
  Unicast — одноадресна розсилка — один відправник, один одержувач. (Приклад: запит HTTP-сторінки у WEB-сервера ).
  Broadcast — широкомовлення — один відправник, одержувачі — всі пристрої в широкомовному сегменті. (Приклад: ARP-запит ).
  Multicast — багатоадресна розсилка — один відправник, багато одержувачів. (Приклад: IPTV ).
  Anycast — одноадресна розсилка найближчого вузла — один відправник, взагалі одержувачів багато, але фактично дані відправляються тільки одному. (Приклад: Anycast DNS ).
 

 
Раз вже ми вирішили поговорити про мультикаст, то, мабуть, почнемо цей параграф з питання, де і як він використовується.
 
Перше, що спадає на думку, — це телебачення (IPTV) — один сервер-джерело відправляє трафік, який хоче отримувати відразу багато клієнтів. Це і визначає сам термін — multicast — багатоадресне мовлення. Тобто, якщо вже відомий вам Broadcast означає мовлення всім, мультикаст означає мовлення певної групи.
 
Друге застосування — це, наприклад, реплікація операційної системи на безліч комп'ютерів разом. Це передбачає завантаження великих обсягів даних з одного сервера.
 
Можливі сценарії: аудіо та відеоконференції (один каже — всі слухають), електронна комерція, аукціони, біржі. Але це в теорії, а на практиці рідко тут таки використовується мультикаст.
 
Ще одне застосування — це службові повідомлення протоколів. Наприклад, OSPF у своєму широкомовному домені розсилає свої повідомлення на адреси 224.0.0.5 і 224.0.0.6. І обробляти їх будуть тільки ті вузли, на яких запущений OSPF.
 
Сформулюємо два основних принципи мультікастового розсилки:
  
     
  1. Відправник посилає тільки одну копію трафіку, незалежно від кількості одержувачів.
  2.  
  3. Трафік отримують тільки ті, хто дійсно зацікавлений в ньому.
  4.  
 

 У даній статті для практики ми візьмемо IPTV, як найбільш наочний приклад.
 
 Приклад I
 Почнемо з найпростішого випадку:
 
 
 
На сервері-джерелі налаштоване мовлення в групу 224.2.2.4 — це означає, що сервер відправляє трафік на IP-адресу 224.2.2.4. На клієнті відеоплеєр налаштований приймати потік групи 224.2.2.4.
  
При цьому, зауважте, клієнт і сервер не обов'язково повинні мати адреси з однієї підмережі і пінгувати один одного — достатньо, щоб вони були в одному широкомовному домені.
 Мультікастового потік просто ллється з сервера, а клієнт його просто приймає. Ви можете спробувати це прямо у себе на робочому місці, з'єднавши патчкордами два комп'ютера і запустивши, наприклад, VLC.
 
Треба зауважити, що в мультикаст немає ніякої сигналізації від джерела, мовляв, «Здрасьте, я Джерело, не треба трохи мультикаст?» .
 Сервер-джерело просто починає віщати в свій інтерфейс мультікастового пакети. У нашому прикладі вони напряму потрапляють клієнту і той, власне, відразу ж їх і приймає.
 Якщо на цьому лінк відловити пакети, то ви побачите, що мультікастового трафік — це ні що інше, як море UDP-пакетів.
 
 
 
Мультикаст не прив'язаний до якогось конкретного протоколу. По суті, все, що його визначає — адреси. Однак, якщо говорити про його застосування, то в абсолютній більшості випадків використовується саме UDP. Це легко пояснюється тим, що зазвичай за допомогою многоадресной розсилки передаються дані, які потрібні тут і зараз. Наприклад, відео. Якщо шматочок кадру загубиться, і відправник буде намагатися його послати повторно, як це відбувається в TCP, то, швидше за все, цей шматочок запізниться, і де його тоді показувати? Поїзд пішов. Рівно те ж саме зі звуком.
 Відповідно не потрібно і встановлювати з'єднання, тому TCP тут ні до чого.
 
Чим же так разюче відрізняється мультикаст від Юнікаст? Думаю, у вас є вже припущення. І ви, напевно, мають рацію.
 
У звичайній ситуації у нас 1 одержувач і 1 відправник — у кожного з них один унікальний IP-адресу. Відправник точно знає, куди треба слати пакет і ставить цю адресу в заголовок IP. Кожен проміжний вузол завдяки своїй таблиці маршрутизації точно знає, куди переслати пакет. Юнікастовий трафік між двома вузлами безперешкодно проходить крізь мережу. Але проблема в тому, що в звичайному пакеті вказується тільки один IP-адресу одержувача.
 Що робити, якщо у одного і того ж трафіку кілька одержувачів? У принципі можна розширити одноадресний підхід і на таку ситуацію — відправляти кожного клієнта свій екземпляр пакета. Клієнти не помітять різниці — хоч він один, хоч їх тисячі, але різниця буде виразно помітна на ваших каналах передачі даних.
  
 Припустимо у нас йде передача одного SD-каналу з мультикаст-сервера. Нехай, він використовує 2 Мб / с. Усього таких каналів 30, а дивиться кожен канал по 20 чоловік одночасно. Разом виходить 2 Мб / с * 30 каналів * 20 осіб = 1200 Мб / с або 1,2 Гб / с тільки на телебачення у разі одноадресної розсилки. А є ж ще HD канали, де можна сміливо множити цю цифру на 2. І де тут місце для торрентів?
 
Ось чому в IPv4 був закладений блок адрес класу D: 224.0.0.0 / 4 (224.0.0.0-239.255.255.255). Адреси цього діапазону визначають мультікастового групу. Один адреса — це одна група, зазвичай вона позначається буквою «G ».
 Тобто, кажучи, що клієнт підключений до групи 224.2.2.4, ми маємо на увазі, що він отримує мультікастового трафік з адресою призначення 224.2.2.4.
 
 Приклад II
 Додамо в схему комутатор і ще декілька клієнтів:
 
 
 
Мультікастового сервер і раніше веде мовлення для групи 224.2.2.4. На комутаторі всі 4 порту повинні бути в одному VLAN. Трафік приходить на комутатор і за замовчуванням розсилається в усі порти одного VLAN'а. Значить всі клієнти отримують цей трафік. На них на всіх у відеоплеєрі так само зазначений груповий адресу 224.2.2.4.
 Власне, всі ці пристрої стають членами даної мультікастового групи. Членство в ній динамічне: хто завгодно, в будь-який момент може увійти і вийти з неї.
  
У даній ситуаци трафік отримуватимуть навіть ті, хто цього в общем-то і не хотів, тобто на ньому не запущений ні плеєр, ні що б то не було інше. Але тільки, якщо він у тому ж VLAN'е. Пізніше ми розберемося, як з цим боротися.
 Зверніть увагу, що в даному випадку від сервера-джерела приходить тільки одна копія трафіку на комутатор, а не за окремою копії на кожного клієнта. І в нашому прикладі з SD каналами завантаження порту між джерелом і комутатором буде не 1,2 Гб / с, а всього 60 Мб / с (2Мб / с * 30 каналів).
 
Власне кажучи, весь цей величезний діапазон (224.0.0.0-239.255.255.255) можна використовувати.
 Ну, майже весь — перша адреси (діапазон 224.0.0.0/23) все-таки зарезервовані під відомі протоколи.
 
 Список зарезервованих IP-адрес                                                                                                  
Адреса Значення
224.0.0.0 Не використовується
224.0.0.1 Всі вузли даного сегмента
224.0.0.2 Всі мультікастового вузли даного сегмента
224.0.0.4 Ця електронна адреса виділявся для покійного протоколу DVMRP
224.0.0.5 Всі OSPF-маршрутизатори сегмента
224.0.0.6 Всі DR маршрутизатори сегмента
224.0.0.9 Всі RIPv2-маршрутизатори сегмента
224.0.0.10 Всі EIGRP-маршрутизатори сегмента
224.0.0.13 Всі PIM-маршрутизатори сегмента
224.0.0.18 Всі VRRP-маршрутизатори сегмента
224.0.0.19-21 Всі IS-IS-маршрутизатори сегмента
224.0.0.22 Всі IGMP-маршрутизатори сегмента (v2 і v3)
224.0.0.102 Всі HSRPv2/GLBP-маршрутізатори сегмента
224.0.0.107 PTPv2 — Precision Time Protocol
224.0.0.251 mDNS
224.0.0.252 LLMNR
224.0.0.253 Teredo
224.0.1.1 NTP
224.0.1.39 Cisco Auto-RP-Announce
224.0.1.40 Cisco Auto-RP-Discovery
224.0.1.41 H.323 Gatekeeper
224.0.1.129-132 PTPv1/PTPv2
239.255.255.250 SSDP
 
 Діапазон 224.0.0.0/24 зарезервований під link-local комунікації. Мультікастового пакети з такими адресами призначення не можуть виходити за межі одного широкомовного сегмента.
 Діапазон 224.0.1.0/24 зарезервований під протоколи, яким необхідно передавати мультикаст по всій мережі, тобто проходити через маршрутизатори.
  

 
Ось, власне, самі базисні речі щодо мультикаст.
 Ми розглянули просту ситуацію, коли джерело і одержувач знаходяться в одному сегменті мережі. Трафік, отриманий комутатором, просто розсилається їм в усі порти — ніякої магії.
 
Але поки зовсім незрозуміло, як трафік від сервера досягає клієнтів, коли між ними величезна провайдерська мережу лінкміап? Та й звідки, власне, буде відомо, хто клієнт? Ми ж не можемо вручну прописати маршрути, просто тому що не знаємо, де можуть виявитися клієнти. Чи не дадуть відповідь на це питання і звичайні протоколи маршрутизації. Так ми приходимо до розуміння, що доставка мультикаст — це щось зовсім нове для нас.
 
Взагалі, щоб доставити мультикаст від джерела до одержувача на даний момент існує багато протоколів — IGMP / MLD, PIM, MSDP, MBGP, MOSPF, DVMRP.
 Ми зупинимося на двох з них, які використовуються в даний час: PIM і IGMP.
 За допомогою IGMP кінцеві одержувачі-клієнти повідомляють найближчим маршрутизаторам про те, що хочуть отримувати трафік. А PIM будує шлях руху мультікастового трафіку від джерела до одержувачів через маршрутизатори.
 
<Img src="http://habrastorage.org/getpro/habr/post_images/149/c93/140/149c93140ceb8331d7ed2ca02fc2b138.png" title = "PIM + IGMP" />
 
 

 
 
  IGMP
 Знову повернемося до дампу. Бачите ось цей верхній пакет, після якого полився мультікастового потік?
 
 
 
Це повідомлення протоколу IGMP, яке відправив клієнт, коли ми на ньому натиснули Play. Саме так він повідомляє про те, що хоче отримувати трафік для групи 224.2.2.4.
  IGMP — Internet Group Management Protocol — це мережевий протокол взаємодії клієнтів мультікастового трафіку і найближчого до них маршрутизатора.
  
В IPv6 використовується MLD (Multicast Listener Discovery) замість IGMP. Принцип роботи у них абсолютно однаковий, тому далі скрізь ви сміливо можете міняти IGMP на MLD, а IP на IPv6.
 Як же саме працює IGMP?
 Мабуть, почати треба з того, що версій у протоколу зараз три: IGMPv1, IGMPv2, IGMPv3. Найбільш використовувана — друга, перша вже практично забута, тому про неї говорити не будемо, третя дуже схожа на другу.
 
Акцентуємося поки на другій, як на самій показовою, і розглянемо всі події від підключення клієнта до групи до його виходу з неї.
 Клієнт буде також запитувати групу 224.2.2.4 через програвач VLC.
 
Роль IGMP дуже проста: якщо клієнтів немає — передавати мультікастового трафік в сегмент не треба. Якщо з'явився клієнт, він повідомляє маршрутизатори з допомогою IGMP про те, що хоче отримувати трафік.
 
Для того, щоб зрозуміти, як все відбувається, візьмемо таку мережу:
 
 
 
Припустимо, що маршрутизатор вже налаштований на отримання та обробку мультікастового трафіку.
 
 
  1. Як тільки ми запустили додаток на клієнті і задали групу 224.2.2.4, в мережу буде відправлений пакет IGMP Membership Report — вузол «рапортує» про те, що хоче отримувати трафік цієї групи.
 
 
 
У IGMPv2 Report відправляється на адресу бажаної групи, і паралельно він же вказується в самому пакеті. Дані повідомлення повинні жити тільки в межах свого сегменту і не пересилатися нікуди маршрутизаторами, тому й TTL у них 1.
  
Часто в літературі ви можете зустріти згадку про IGMP Join . Не лякайтеся — це альтернативна назва для IGMP Membership Report.
  
  2. Маршрутизатор отримує IGMP-Report і, розуміючи, що за даними інтерфейсом тепер є клієнти, заносить інформацію у свої таблиці
 
 
 
Це висновок інформації по IGMP. Перша група запрошені клієнтом. Третя і четверта — це службові групи протоколу SSDP , вбудованого в Windows. Друга — спеціальна група, яка завжди присутня на маршрутизаторах Cisco — вона використовується для протоколу Auto-RP , який за замовчуванням активований на маршрутизаторах.
 Інтерфейс FE0 / 0 стає низхідним для трафіку групи 224.2.2.4 — в нього потрібно буде відправляти отриманий трафік.
 
Поряд із звичайною юнікастовой таблицею маршрутизації існує ще й мультікастового:
 
 
 
Про наявність клієнтів говорить перший запис (*, 224.2.2.4) . А запис (172.16.0.5, 224.2.2.4) означає, що маршрутизатор знає про джерело мультікастового потоку для цієї групи.
 З виведення видно, що трафік для групи 224.2.2.4 приходить через FE0 / 1, а передавати його треба на порт FE0 / 0.
 Інтерфейси, в які потрібно передавати трафік, входять до списку низхідних інтерфейсів — OIL — Outbound Interface List .
 Більш докладно висновок команди show ip mroute ми розберемо пізніше.
 
Вище на дампі ви бачите, що як тільки клієнт відправив IGMP-Report, відразу після нього полетіли UDP — це відеопотік.
 
 
  3. Клієнт почав отримувати трафік. Тепер маршрутизатор повинен іноді перевіряти, що одержувачі досі у нього є, щоб зазря НЕ віщати, якщо раптом клієнтів не залишилося. Для цього він періодично відправляє в усі свої спадні інтерфейси запит IGMP Query .
  
  * Дамп відфільтрований по IGMP * .
  
 
За умовчанням це відбувається кожні 60 секунд. TTL таких пакетів теж дорівнює 1. Вони відправляються на адресу 224.0.0.1 — всі вузли в цьому сегменті — без зазначення конкретної групи. Такі повідомлень Query називаються General Query — спільні. Таким чином маршрутизатор запитує: «Хлопців, а хто і що ще хоче отримувати?».
 
Отримавши IGMP General Query, будь-який хост, який слухає будь-яку групу, повинен відправити IGMP Report, як він це робив при підключенні. У Report, природно, повинна бути вказана адреса, що цікавить його групи.
  
  * Дамп відфільтрований по IGMP * .
  
 
Якщо у відповідь на Query на маршрутизатор прийшов хоча б один Report для групи, значить є ще клієнти, він продовжує вести мовлення в той інтерфейс, звідки прийшов цей Report, трафік цієї самої групи.
 Якщо на 3 поспіль Query не було з інтерфейсу відповіді для якоїсь групи, маршрутизатор видаляє цей інтерфейс зі своєї таблиці мультікастового маршрутизації для даної групи — перестає туди посилати трафік.
 
За своєю ініціативою клієнт зазвичай посилає Report тільки при підключенні, потім — просто відповідає на Query від маршрутизатора.
  
Цікава деталь у поведінці клієнта: отримавши Query, він не поспішає відразу ж відповісти Report'ом. Вузол бере тайм-аут довжиною від 0 до Max Response Time , який вказаний у отриманому Query:
 
 
 
При налагодженні або в дампі, до речі, можна бачити, що між отриманням різних Report може пройти кілька секунд.
 Зроблено це для того, щоб сотні клієнтів все скопом НЕ наповнили мережу своїми пакетам Report, отримавши General Query. Більш того, тільки один клієнт зазвичай відправляє Report.
 Справа в тому, що Report відсилається на адресу групи, а отже доходить і до всіх клієнтів. Отримавши Report від іншого клієнта для цієї ж групи, вузол не відправлятиме свій. Логіка проста: маршрутизатор і так вже отримав цей самий Report і знає, що клієнти є, більше йому не треба.
 Цей механізм називається Report Suppression .
 
 Далі в статті ми розповімо про те, чому цей механізм на ділі дуже рідко реально працює .
  
  4. Так триває століттями, поки клієнт не захоче вийти з групи (наприклад, вимкне плеєр / телевізор). У цьому випадку він відправляє IGMP Leave на адресу групи.
 
 
 
Маршрутизатор отримує його і по ідеї повинен відключити. Але ж він не може відключити одного конкретного клієнта — маршрутизатор їх не розрізняє — у нього просто є низхідний інтерфейс. А за інтерфейсом може бути декілька клієнтів. Тобто, якщо маршрутизатор видалить цей інтерфейс зі свого списку OIL (Outgoing Interface List) для цієї групи, відео вимкнеться у всіх.
 Але й не видаляти його зовсім теж не можна — раптом це був останній клієнт — навіщо тоді даремно віщати?
 
Якщо ви подивитеся в дамп, то побачите, що після отримання Leave маршрутизатор ще деякий час продовжує слати потік. Справа в тому, що маршрутизатор у відповідь на Leave висилає IGMP Query на адресу групи, для якої цей Leave прийшов в той інтерфейс, звідки він прийшов. Такий пакет називається Group Specific Query . На нього відповідають тільки ті клієнти, які підключені до даної конкретної групі.
 
 
 
Якщо маршрутизатор отримав відповідь Report для групи, він продовжує вести мовлення в інтерфейс, якщо не отримав — видаляє після закінчення таймера.
 
Всього після отримання Leave відправляється два Group Specific Query — один обов'язковий, другий контрольний.
 
 * Дамп відфільтрований по IGMP * .
  
 
Далі маршрутизатор зупиняє потік.
 
 

 
 Querier
 Розглянемо трохи складніший випадок:
 
 
 
У клієнтський сегмент підключено два (або більше) маршрутизатора, які можуть віщати трафік. Якщо нічого не зробити, мультікастового трафік буде дублюватися — обидва маршрутизатора адже отримуватимуть Report від клієнтів. Щоб уникнути цього існує механізм вибору Querier — опрашівателя. Той хто переможе, буде посилати Query, моніторити Report і реагувати на Leave, ну і, відповідно, він буде відправляти і трафік в сегмент. Переможений ж буде тільки слухати Report і тримати руку на пульсі.
 
Вибори відбуваються досить просто і інтуїтивно зрозуміло.
 Розглянемо ситуацію з моменту включення маршрутизаторів R1 і R2.
  1) Активували IGMP на інтерфейсах.
  2) Спочатку за замовчуванням кожен з них вважає себе Querier.
  3) Кожен відправляє IGMP General Query в мережу. Головна мета — дізнатися, чи є клієнти, а паралельно — заявити іншим маршрутизаторам в сегменті, якщо вони є, про своє бажання брати участь у виборах.
  4) General Query отримують всі пристрої в сегменті, в тому числі й інші IGMP-маршрутизатори.
  5) Отримавши таке повідомлення від сусіда, кожен маршрутизатор оцінює, хто достойніше.
  6) Перемагає маршрутизатор з меншим IP (вказана в полі Source IP пакета IGMP Query). Він стає Querier, всі інші — Non-Querier.
  7) Non-Querier запускає таймер, який обнуляється кожен раз, як приходить Query з меншим IP-адресою. Якщо до закінчення таймера (більше 100 секунд: 105-107) маршрутизатор не отримає Query з меншою адресою, він оголошує себе Querier і бере на себе всі відповідні функції.
  8) Якщо Querier отримує Query з меншою адресою, він складає з себе ці обов'язки. Querier'ом стає інший маршрутизатор, у якого IP менше.
 
 Той рідкісний випадок, коли міряються, у кого менше.
 
 Вибори Querier дуже важлива процедура в мультикаст, але деякі підступні виробники, що не дотримуються RFC, можуть вставити міцну палицю в колеса. Я зараз говорю про IGMP Query з адресою джерела 0.0.0.0, які можуть генеруватися комутатором. Такі повідомлення не повинні брати участь у виборі Querier, але треба бути готовими до всього. Ось приклад вельми складною довгограючою проблеми.
  

 
 Ще пара слів про інших версіях IGMP
 Версія 1 відрізняється по суті тільки тим, що в ній немає повідомлення Leave . Якщо клієнт не хоче більше отримувати трафік даної групи, він просто перестає посилати Report у відповідь на Query. Коли не залишиться жодного клієнта, маршрутизатор з таймаут перестане слати трафік.
 Крім того, не підтримується вибори Querier . За уникнення дублювання трафіку відповідає вищестоящий протокол, наприклад, PIM, про який ми говоритимемо далі .
 
Версія 3 підтримує все те, що підтримує IGMPv2, але є і ряд змін. По-перше, Report відправляється вже не на адресу групи, а на мультікастового службова адреса 224.0.0.22 . А адресу запитуваної групи вказаний тільки всередині пакета. Робиться це для спрощення роботи IGMP Snooping, про який ми поговоримо далі .
 
По-друге, що більш важливо, IGMPv3 став підтримувати SSM в чистому вигляді. Це так званий Source Specific Multicast . У цьому випадку клієнт може не просто запросити групу, але також вказати список джерел, від яких він хотів би отримувати трафік або навпаки не хотів би. У IGMPv2 клієнт просто запитує та отримує трафік групи, не піклуючись про джерело.
 
 
 
Отже, IGMP призначений для взаємодії клієнтів і маршрутизатора. Тому, повертаючись до Прикладу II , де немає маршрутизатора, ми можемо авторитетно заявити — IGMP там — не більше, ніж формальність. Маршрутизатора немає, і клієнтові не у кого запитувати мультікастового потік. А запрацює відео з тієї простої причини, що потік і так ллється від комутатора — треба тільки підхопити його.
 
Нагадаємо, що IGMP не працює для IPv6. Там існує протокол MLD .
  

 
 Повторимо ще раз
  
  * Дамп відфільтрований по IGMP * .
  
  1. Насамперед маршрутизатор відправив свій IGMP General Query після включення IGMP на його інтерфейсі, щоб дізнатися, чи є одержувачі і заявити про своє бажання бути Querier. На той момент нікого не було в цій групі.
  2. Далі з'явився клієнт, який захотів отримувати трафік групи 224.2.2.4 і він відправив свій IGMP Report. Після цього пішов трафік на нього, але він відфільтрований з дампа.
  3. Потім маршрутизатор вирішив навіщось перевірити — а чи немає ще клієнтів і відправив IGMP General Query ще раз, на який клієнт змушений відповісти (4 ).
  5. Періодично (раз на хвилину) маршрутизатор перевіряє, що одержувачі раніше є, за допомогою IGMP General Query, а вузол підтверджує це за допомогою IGMP Report.
  6. Потім він передумав і відмовився від групи, відправивши IGMP Leave.
  7. Маршрутизатор отримав Leave і, бажаючи переконатися, що більше ніяких інших одержувачів немає, посилає IGMP Group Specific Query… двічі. І після закінчення таймера перестає передавати трафік сюди.
  8. Однак передавати IGMP Query в мережу він як і раніше продовжує. Наприклад, на той випадок, якщо ви плеєр не відключали, а просто десь зі зв'язком проблеми. Потім зв'язок відновлюється, але клієнт-то Report не подає сам по собі. А ось на Query відповідає. Таким чином потік може відновитися без участі людини.
  

 
 І ще раз
  IGMP — протокол, за допомогою якого маршрутизатор дізнається про наявність одержувачів мультікастового трафіку і про їх відключення.
  IGMP Report — надсилається клієнтом при підключенні і у відповідь на IGMP Query. Означає, що клієнт хоче отримувати трафік конкретної групи.
  IGMP General Query — надсилається маршрутизатором періодично, щоб перевірити які групи зараз потрібні. В якості адреси одержувача вказується 224.0.0.1.
  IGMP Group Sepcific Query — надсилається маршрутизатором у відповідь на повідомлення Leave, щоб дізнатися чи є інші одержувачі в цій групі. В якості адреси одержувача вказується адреса мультікастового групи.
  IGMP Leave — надсилається клієнтом, коли той хоче покинути групу.
  Querier — якщо в одному широкомовному сегменті кілька маршрутизаторів, який можуть мовити, серед них вибирається один головний — Querier. Він і буде періодично розсилати Query і передавати трафік.
 
Детальний опис всіх термінів IGMP .
  

 
 
  PIM
 Отже, ми розібралися, як клієнти повідомляють найближчого маршрутизатора про свої наміри. Тепер непогано було б передати трафік від джерела одержувачу через велику мережу.
 
Якщо вдуматися, то ми стоїмо перед задоволеною складною проблемою — джерело тільки мовить на групу, він нічого не знає про те, де знаходяться одержувачі і скільки їх.
 Одержувачі і найближчі до них маршрутизатори знають тільки, що їм потрібен трафік конкретної групи, але поняття не мають, де знаходиться джерело і який у нього адресу.
 Як у такій ситуації доставити трафік?
 
Існує декілька протоколів маршрутизації мультікастового трафіку: DVMRP , MOSPF , CBT — всі вони по-різному вирішують таку задачу. Але стандартом де факто став PIM — Protocol Independent Multicast .
  Інші підходи настільки нежиттєздатні, що часом навіть їх розробники практично визнають це. Ось, наприклад, витяг з RFC по протоколу CBT:
  CBT version 2 is not, and was not, intended to be backwards compatible with version 1; we do not expect this to cause extensive compatibility problems because we do not believe CBT is at all widely deployed at this stage.
  
 
PIM має дві версії, які можна навіть назвати двома різними протоколами в принципі, вже сильно вони різні:
  
     
  • PIM Dense Mode (DM)
  •  
  • PIM Sparse Mode (SM)
  •  
 Independent він тому, що не прив'язаний до якогось конкретного протоколу маршрутизації юнікастового трафіку, і пізніше ви побачите чому.
 
 
  PIM Dense Mode
  PIM DM намагається вирішити проблему доставки мультіакста в лоб. Він свідомо припускає, що одержувачі є скрізь, у всіх куточках мережі. Тому спочатку він наводнює всю мережу мультікастового трафіком, тобто розсилає його в усі порти, крім того, звідки він прийшов. Якщо потім виявляється, що десь він не потрібен, то ця гілка «відрізається» за допомогою спеціального повідомлення PIM Prune — трафік туди більше не відправляється.
 
Але через деякий час в цю ж гілку маршрутизатор знову намагається відправити мультикаст — раптом там з'явилися одержувачі. Якщо не з'явилися, гілка знову відрізається на певний період. Якщо клієнт на маршрутизаторі з'явився в проміжку між цими двома подіями, відправляється повідомлення Graft — маршрутизатор запрошувати відрізану гілку назад, щоб не чекати, поки йому щось перепаде.
 Як бачите, тут не стоїть питання визначення шляху до одержувачів — трафік досягне їх просто тому, що він скрізь.
 Після «обрізання» непотрібних гілок залишається дерево, уздовж якого передається мультікастового трафік. Це дерево називається SPT — Shortest Path Tree .
 
Воно позбавлене петель і використовує найкоротший шлях від одержувача до джерела. По суті воно дуже схоже на Spanning Tree в STP , де коренем є джерело.
  
 SPT — це конкретний вид дерева — дерево найкоротшого шляху. А взагалі будь-яке мультікастового дерево називається MDT — Multicast Distribution Tree .
 
Передбачається, що PIM DM повинен використовуватися в мережах з високою щільністю мультікастового клієнтів, що і пояснює його назва (Dense). Але реальність така, що ця ситуація — скоріше, виняток, і часто PIM DM недоцільний.
 
Що нам дійсно важливо зараз — це механізм уникнення петель.
 Уявімо таку мережу:
 
 
 
Одне джерело, один одержувач і найпростіша IP-мережу між ними. На всіх маршрутизаторах запущений PIM DM.
 
Що сталося б, якби не було спеціального механізму уникнення петель?
 Джерело відправляє мультікастового трафік. R1 його отримує і відповідно до принципів PIM DM відправляє в усі інтерфейси, крім того, звідки він прийшов — тобто на R2 і R3.
 
R2 надходить точно так само, тобто відправляє трафік в сторону R3. R3 не може визначити, що це той же самий трафік, який він уже одержав від R1, тому пересилає його в усі свої інтерфейси. R1 отримає копію трафіку від R3 і так далі. Ось вона — петля.
 
Що ж пропонує PIM в такій ситуації? RPF — Reverse Path Forwarding . Це головний принцип передачі мультікастового трафіку в PIM (будь-якого виду: і DM і SM) — трафік від джерела повинен приходити по найкоротшому шляху.
 Тобто для кожного отриманого мультікастового пакету проводиться перевірка на основі таблиці маршрутизації, звідти він прийшов.
 
1) Маршрутизатор дивиться на адресу джерела мультікастового пакета.
 2) Перевіряє таблицю маршрутизації, через який інтерфейс доступний адресу джерела.
 3) Перевіряє інтерфейс, через який прийшов мультікастового пакет.
 4) Якщо інтерфейси збігаються — все відмінно, мультікастового пакет пропускається, якщо ж дані приходять з іншого інтерфейсу — вони будуть відкинуті.
 У нашому прикладі R3 знає, що найкоротший шлях до джерела лежить через R1 (статичний або динамічний маршрут). Тому мультікастового пакети, що прийшли від R1, проходять перевірку і приймаються R3, а ті, що прийшли від R2, відкидаються.
 
 
 
Така перевірка називається RPF-Check і завдяки їй навіть в складніших мережах петлі в MDT чи не виникнуть.
 Цей механізм важливий нам, тому що він актуальний і в PIM-SM і працює там точно також.
 Як бачите, PIM спирається на таблицю юнікастовой маршрутизації, але, по-перше, сам не маршрутизує трафік, по-друге, йому не важливо, хто і як наповнював таблицю.
 
Зупинятися тут і докладно розглядати роботу PIM DM ми не будемо — це застарілий протокол з масою недоліків (ну, як RIP ).
 
Однак PIM DM може застосовуватися в деяких випадках. Наприклад, в зовсім невеликих мережах, де потік мультикаст невеликий.
 
 
  

  
  PIM Sparse Mode
 Зовсім інший підхід застосовує PIM SM . Незважаючи на назву (розріджений режим), він з успіхом може застосовуватися в будь-якій мережі з ефективністю як мінімум не гірше, ніж у PIM DM.
 Тут відмовилися від ідеї безумовного повені мультикаст мережі. Зацікавлені вузли самостійно запитують підключення до дерева за допомогою повідомлень PIM Join .
 Якщо маршрутизатор не посилав би Join, то і трафік йому відправлятися не буде.
 
Для того, щоб зрозуміти, як працює PIM, почнемо з вже знайомої нам простий мережі з одним PIM-маршрутизатором:
  
 З налаштувань на R1 треба включити можливість маршрутизації мультикаст, PIM SM на двох інтерфейсах (в бік джерела і в сторону клієнта) і IGMP в сторону клієнта. Крім інших базових налаштувань, звичайно (IP, IGP).
 
З цього моменту ви можете расчехлить GNS і збирати лабораторію. Досить докладно про те, як зібрати стенд для мультикаст я розповів у цій статті .
 
 
R1(config)#ip multicast-routing
	R1(config)#int fa0/0
	R1(config-if)#ip pim sparse-mode
	R1(config-if)#int fa1/0
	R1(config-if)#ip pim sparse-mode

  
Cisco тут як зазвичай відрізняється своїм особливим підходом: при активації PIM на інтерфейсі, автоматично активується і IGMP. На всіх інтерфейсах, де активований PIM, працює і IGMP.
 У той же час у інших виробників два різних протоколу включаються двома різними командами: окремо IGMP, окремо PIM.
 Простим Cisco цю дивина? Разом з усіма іншими?
 
Плюс, можливо, буде потрібно налаштувати адресу RP (ip pim rp-address 172.16.0.1 , наприклад). Про це пізніше, поки прийміть як даність і змиріться.
 Перевіримо поточний стан таблиці мультікастового маршрутизації для групи 224.2.2.4:
 
 
 
Після того, як на джерелі ви запустите мовлення, треба перевірити таблицю ще раз.
 
 
 
Давайте розберемо цей небагатослівний висновок.
 
Запис виду (*, 225.0.1.1) називається (*, G) , / читається старкомаджі / і повідомляє нас про одержувачів. Причому не обов'язково мова про одного клієнта-комп'ютері, взагалі це може бути і, наприклад, інший PIM-маршрутизатор. Важливо те, в які інтерфейси треба передавати трафік.
 Якщо список низхідних інтерфейсів (OIL) порожній — Null , значить немає одержувачів — а ми їх поки не запускали.
 
Запис (172.16.0.5, 225.0.1.1) називається (S, G) , / читається ескомаджі / і говорить про те, що відомий джерело. У нашому випадку джерело з адресою 172.16.0.5 віщає трафік для групи 224.2.2.4. Мультікастового трафік приходить на інтерфейс FE0 / 1 — це висхідний (Upstream ) інтерфейс.
 
Отже, немає клієнтів. Трафік від джерела доходить до маршрутизатора і на цьому його життя закінчується. Давайте додамо тепер одержувача — налаштуємо прийом мультикаст на ПК.
 ПК відсилає IGMP Report, маршрутизатор розуміє, що з'явилися клієнти і оновлює таблицю мультікастового маршрутизації.
 Тепер вона виглядає так:
 
 
 
З'явився і спадний інтерфейс: FE0 / 0, що цілком очікувано. Причому він з'явився як в (*, G), так і в (S, G). Список низхідних інтерфейсів називається OIL — Outgoing Interface List .
 
Додамо ще одного клієнта на інтерфейс FE1 / 0:
 
 
 
Якщо читати висновок дослівно, то маємо:
 (*, G): Є одержувачі мультікастового трафіку для групи 224.2.2.4 за інтерфейсами FE0 / 0, FE1 / 0. Причому зовсім неважливо, хто відправник, про що і говорить знак «*».
 
(S, G): Коли мультікастового трафік з адресою призначення 224.2.2.4 від джерела 172.16.0.5 приходить на інтерфейс FE0 / 1, його копії потрібно відправити у FE0 / 0 і FE1 / 0.
 
Але це був дуже простий приклад — один маршрутизатор відразу знає і адресу джерела і де знаходяться одержувачі. Фактично навіть дерев тут ніяких немає — хіба що вироджені. Але це допомогло нам розібратися з тим, як взаємодіють PIM і IGMP.
  

 
 Щоб розібратися з тим, що таке PIM, звернемося до мережі набагато складнішою
  
 
Припустимо, що вже налаштовані всі IP-адреси у відповідності зі схемою. На мережі запущений IGP для звичайної юнікастовой маршрутизації.
  Кліент1 , наприклад, може пінгувати Сервер-джерело.
 
 
 
Але поки не запущений PIM, IGMP, клієнти не запитують канали.
 
 Файл початковій конфігурації .
  
 
Отже, момент часу 0.
 
Включаємо мультікастового маршрутизацію на всіх п'яти маршрутизаторах:
  
  
RX(config)#ip multicast-routing

 PIM включається безпосередньо на всіх інтерфейсах всіх маршрутизаторів (у тому числі на інтерфейсі в сторону Сервера-джерела і клієнтів):
  
  
RX(config)#int FEX/X
	RX(config-if)#ip pim sparse-mode

  
IGMP, по ідеї повинен включатися на інтерфейсах в сторону клієнтів, але, як ми вже зазначили вище, на обладнанні Cisco він включається автоматично разом з PIM.
  

 Перше, що робить PIM — встановлює сусідство. Для цього використовуються повідомлення PIM Hello . При активації PIM на інтерфейсі з нього відправляється PIM Hello на адресу 224.0.0.13 з TTL рівним 1. Це означає, що сусідами можуть бути тільки маршрутизатори, що знаходяться в одному широкомовному домені.
 
 
 
Як тільки сусіди отримали вітання один від одного:
 
 
 
Тепер вони готові приймати заявки на мультікастового групи.
 
Якщо ми зараз запустимо у вольєр клієнтів з одного боку і включимо мультікастового потік з сервера з іншого, то R1 отримає потік трафіку, а R4 отримає IGMP Report при спробі клієнта підключитися. У підсумку R1 не знатиме нічого про одержувачів, а R4 про джерело.
 
 
 
 
 
Непогано було б якби інформація про джерело і про клієнтів групи була зібрана десь в одному місці. Але в якому?
 
Така точка зустрічі називається Rendezvous Point — RP . Це центральне поняття PIM SM. Без неї нічого б не працювало. Тут зустрічаються джерело і одержувачі.
 Всі PIM-маршрутизатори повинні знати, хто є RP в домені, тобто знати її IP-адресу.
 
Щоб побудувати дерево MDT, в мережі вибирається як RP якась центральна точка, яка,
  
     
  1. відповідає за вивчення джерела,
  2.  
  3. є точкою тяжіння повідомлень Join від усіх зацікавлених.
  4.  
 Існує два способи завдання RP: статичний і динамічний. Ми розглянемо обидва в цій статті, але почнемо зі статичного, оскільки чого вже простіше статики?
 
Нехай поки R2 буде виконувати роль RP.
 Щоб збільшити надійність, зазвичай вибирається адреса Loopback-інтерфейсу. Тому на всіх маршрутизаторах виконується команда:
  
RX(config)#ip pim rp-address 2.2.2.2

 Природно, ця адреса має бути доступний по таблиці маршрутизації з усіх точок.
 Ну і оскільки адреса 2.2.2.2 є RP, на інтерфейсі Loopback 0 на R2 бажано теж активувати PIM.
 
 
R2(config)#interface Loopback 0
	RX(config-if)#ip pim sparse-mode

  
 Відразу після цього R4 дізнається про джерело трафіку для групи 224.2.2.4:
 
 
 
і навіть передає трафік:
 
 
 
На інтерфейс FE0 / 1 приходить 362000 б / с, і через інтерфейс FE0 / 0 вони передаються.
 
Все, що ми зробили:
 Включили можливість маршрутизації мультікастового трафіку (ip multicast-routing )
 Активували PIM на інтерфейсах (ip pim sparse-mode )
 Вказали адресу RP (ip pim rp-adress XXXX )
 
Все, це вже робоча конфігурація і можна приступати до розбору, адже за лаштунками ховається набагато більше, ніж видно на сцені.
  Повна конфігурація з PIM.
  

 
 Розбір польотів
 Ну так і як же в підсумку все працює? Як RP дізнається де джерело, де клієнти і забезпечує зв'язок між ними?
 
Оскільки всі затівається заради наших улюблених клієнтів, то, почавши з них, розглянемо в деталях весь процес.
 
 1) Клієнт 1 відправляє IGMP Report для групи 224.2.2.4
 
 
 
 
 
 2) R4 отримує цей запит, розуміє, що є клієнт за інтерфейсом FE0 / 0, додає цей інтерфейс в OIL і формує запис (*, G).
 
 
 
По побудованій Source Tree мультикаст передається RP (і всім проміжним клієнтам, якщо вони є, наприклад, R42).
 
Але треба мати на увазі, що повідомлення Register передавалися весь цей час і передаються до цих пір. Тобто фактично R1 відправляє дві копії трафіку зараз: один — чистий мультикаст по SPT, інший — інкапсульований в юнікастовий Register.
 
 
  
Спочатку R1 відправляє мультикаст в Register — пакет 231 . Потім R2 (RP) хоче підключитися до дерева, відправляє Join — пакет 232 . R1 ще якийсь час, поки обробляє запит від R2, відправляє мультикаст в Register (пакети з 233 по 238 ). Далі, коли низхідний інтерфейс доданий в OIL на R1, він починає передавати чистий мультикаст — пакети 239 і 242 , але поки не припиняє і Register — пакети 241 і 243 . А пакет 240 — це R2 не витримав і ще раз попросив побудувати дерево.
  
 
 10) Отже, незамутнений мультикаст досягає RP. Вона розуміє, що це той же самий трафік, який приходить в Register, тому що однакову адресу групи, однакову адресу джерела і з одного інтерфейсу. Щоб не отримувати дві копії, він відправляє на R1 юнікастовий PIM Register-Stop .
 
 
 
Register-Stop не означає, що R2 відмовляється від трафіку або не визнає більше це джерело, це говорить лише про те, що треба припинити посилати інкапсульований трафік.
 
Далі йде запекла боротьба — R1 продовжує передавати накопичився в буфері трафік, поки обробляє Register-Stop, і звичайним мультикаст і всередині повідомлень Register:
 
 
 
Але, рано чи пізно R1 починає віщати тільки чистий мультікастового трафік.
 
 
 
  
При підготовці у мене виникло, як мені здавалося, закономірне питання: ну і до чого всі ці тунелювання, PIM Register? Чому б не чинити з мультікастового трафіком, як з PIM Join — відправляти хоп за хопом з TTL = 1 в сторону RP — рано чи пізно адже дійде? Так би й дерево побудувалася б заодно без зайвих рухів тіла.
 Тут виникає кілька нюансів.
 По-перше, порушується головний принцип PIM SM — трафік посилати тільки туди, звідки він був запитаний. Ні Join — Ні дерева !
 По-друге, якщо клієнтів для даної групи немає, FHR не впізнає про це і буде продовжувати слати трафік по «свого дереву». До чого таке бездумне використання смуги пропускання? У світі зв'язку такий протокол просто не вижив би, як не вижив PIM DM або DVMRP.
 Таким чином ми маємо одне велике дерево MDT для групи 224.2.2.4 від Cервера-джерела до Клієнта 1 і Клієнта 2 . І це MDT складено з двох шматків, які будувалися незалежно один від одного: Source Tree від джерела до RP і RPT від RP до клієнтів. Ось воно відміну MDT від RPT і SPT. MDT — це досить загальний термін, що означає дерево передачі мультикаст взагалі, в той час, як RPT / SPT — це його дуже конкретний вид.
 
А що робити, якщо сервер вже мовить, а клієнтів все немає і ні? Мультикаст так і буде засмічувати ділянку між відправником і RP?
 Ні, в цьому випадку також допоможе PIM Register-Stop. Якщо на RP почали приходити повідомлення Register для якоїсь групи, а для неї ще немає одержувачів, то RP не зацікавлений в отриманні цього трафіку, тому, без пересилання PIM Join (S, G), RP відразу посилає Register-Stop на R1.
 R1, отримавши Register-Stop і бачачи, що дерева для цієї групи поки немає (немає клієнтів), починає відкидати мультікастового трафік від сервера.
 Тобто сам сервер з цього приводу абсолютно не турбується і продовжує посилати потік, але, дійшовши до інтерфейсу маршрутизатора, потік буде відкинутий.
 При цьому RP продовжує зберігати запис (S, G). Тобто трафік він не отримує, але де знаходиться джерело для групи знає. Якщо в групі з'являються одержувачі, RP дізнається про них і посилає на джерело Join (S, G), який будує дерево.
 
Крім того, кожні 3 хвилини R1 намагатиметься повторно зареєструвати джерело на RP, тобто відправляти пакети Register. Це потрібно для того, щоб повідомити RP про те, що це джерело ще живий.
 
 
У особливо допитливих читачів зобов'язаний виникнути питання — а як бути з RPF? Цей механізм адже перевіряє адресу відправника мультікастового пакету і, якщо трафік йде не з правильного інтерфейсу, він буде відкинутий. При цьому RP і джерело можуть перебувати за різними інтерфейсів. Ось і в нашому прикладі для R3 RP — за FE1 / 1, а джерело — за FE1 / 0.
 Відповідь передбачуваний — в такому випадку перевіряється не адресу джерела, а RP. Тобто трафік повинен прийти з інтерфейсу в сторону RP.
 Але, як ви побачите далі, це теж не непорушне правило.
 Важливо розуміти, що RP — це не універсальний магніт — для кожної групи може буття своя RP. Тобто в мережі їх може бути і дві, і три, і сто — одна RP відповідає за один набір груп, інша — за іншою. Більше того, є таке поняття, як Anycast RP і тоді різні RP можуть обслуговувати одну і ту ж групу.
 
 
=====================
 Завдання № 2
 
 Схема і початкова конфігурація .
 
 
 
 Зауваження до топології : в цьому завданні тільки маршрутизатори R1, R2, R3 знаходяться під управлінням адміністраторів нашої мережі. Тобто, конфігурацію змінювати можна тільки на них.
 
Сервер 172.16.0.5 передає мультикаст трафік на групи 239.1.1.1 і 239.2.2.2.
 
Налаштувати мережу таким чином, щоб трафік групи 239.1.1.1 не передавався в сегмент між R3 і R5, і в усі сегменти нижче R5.
Але при цьому, трафік групи 239.2.2.2 повинен передаватися без проблем.
 
Подробиці завдання тут .
=====================
 
  

 
 Бритва Оккама або відключення непотрібних гілок
 Після того, як останній клієнт в сегменті відмовився від підписки, PIM повинен відрізати зайву гілку RPT.
 Нехай, наприклад, єдиний клієнт на R4 вимкнув комп'ютер. Маршрутизатор за повідомленням IGMP Leave або після трьох безмовних IGMP Query розуміє, що клієнтів за FE0 / 0 більше немає, і відправляє в сторону RP повідомлення PIM Prune . За форматом воно точно таке ж, як Join, але виконує протилежну функцію.
 Адреса призначення також 224.0.0.13, і TTL дорівнює 1.
 
 
 
Але маршрутизатор, який отримав PIM Prune, перед тим, як видалити підписку, чекає деякий час (зазвичай 3 секунди — Join Delay Timer).
 Це зроблено ось для такої ситуації:
  
 В одному широкомовному домені 3 маршрутизатора. Один з них стоїть вище і саме він передає в сегмент мультікастового трафік. Це R1. Для обох маршрутизаторів (R2 і R3) його OIL містить тільки один запис.
  
 Якщо тепер R2 вирішить відключитися і відправить PIM Prune, то він може підставити свого колегу R3 — R1 адже перестане віщати в інтерфейс взагалі.
 Так от, щоб цього не сталося, R1 і дає таймаут в 3 секунди. За цей час R3 повинен встигнути зреагувати. Враховуючи широкомовність мережі, він теж отримає Prune від R2 і тому, якщо хоче продовжувати отримувати трафік, він миттєво відправляє звичайний PIM Join в сегмент, повідомляючи R1, що не треба видаляти інтерфейс.
 
Цей процес називається — Prune Override. R2 як би обдурити R1, перехопив ініціативу.
  

  
  SPT Switchover — перемикання RPT-SPT
 Досі ми переважно розглядали тільки Клієнта 1 . Тепер звернемося до Клієнту 2 .
 По початку все для нього ідентично Клієнту 1 — він користується RPT від RP, який ми розглядали раніше. До речі, оскільки обидва — і Клієнт 1 і Клієнт 2 — використовують одне дерево, таке дерево називається Shared Tree — це досить загальна назва. Shared tree = RPT.
 
Ось як виглядає таблиця мультікастового маршрутизації на R5 на самому початку, відразу після побудови дерева:
 
 
 
Тут немає запису (S, G), але це не означає, що мультікастового трафік не передається. Просто R5 не піклується про те, хто відправник.
 
Зверніть увагу по якому шляху повинен йти в цьому випадку трафік — R1-R2-R3-R5. Хоча адже коротше шлях R1-R3-R5.
 
 
 
А якщо мережа поскладніше?
 
 
 
Якось неакуратненько.
 
Справа в тому, що поки ми прив'язані до RP — вона корінь RPT, тільки вона спочатку знає, де хто знаходиться. Однак якщо вдуматися, то після першого ж мультікастового пакета всі маршрутизатори по шляху трафіку будуть знати адресу джерела, адже він вказаний в заголовку IP.
 
 
 
Чому б комусь не відправити самому Join в бік джерела та оптимізувати маршрут?
 
Дивиться в корінь. Таке переключення може ініціювати LHR (Last Hop Router) — R5. Після отримання першого мультікастового пакета від R3 R5 відправляє вже знайомий нам Source Specific Join (S, G) в інтерфейс FE0 / 1, який вказаний в його таблиці маршрутизації, як вихідний для мережі 172.16.0.0/24.
  
 
Отримавши такий Join, R3 відправляє його не так на RP, як робив це з звичайним Join (*, G), а в бік джерела (через інтерфейс згідно з таблицею маршрутизації).
 Тобто в даному випадку R3 відправляє Join (172.16.0.5, 224.2.2.4) в інтерфейс FE1 / 0.
 
 
 
Далі цей Join потрапляє на R1. А R1 за великим рахунком без різниці, хто його відправляв — RP чи хтось інший — він просто додає FE1 / 1 в свій OIL для групи 224.2.2.4.
 
 
 
У цей момент між джерелом і одержувачем два шляхи і R3 отримує два потоки.
 
 
 
Час зробити вибір, щоб обрізати зайве. Причому саме R3 його робить, бо R5 вже не зможе розрізнити ці два потоки — вони обидва прийдуть через один інтерфейс.
 Як тільки R3 зафіксував два однакових потоку з різних інтерфейсів, він вибирає переважний згідно з таблицею маршрутизації. У даному випадку прямої, краще, ніж через RP. У цей момент R3 посилає Prune (S, G) в сторону RP, обрубуючи цю гілку RPT. І з цього момент залишається тільки один потік безпосередньо від джерела.
 
 
 
Таким чином PIM побудував SPT — Shortest Path Tree. Воно ж Source Tree. Це найкоротший шлях від клієнта до джерела. До речі, дерево від джерела до RP, яке ми вже розглядали вище, — по суті рівно те ж саме SPT.
 Воно характеризується записом (S, G). Якщо маршрутизатор має таку запис, значить він знає, що S є джерелом для групи G і побудовано дерево SPT.
  
Коренем дерева SPT є джерело і дуже хочеться сказати «найкоротший шлях від джерела до клієнта ». Але це технічно некоректно, оскільки шляхи від джерела до клієнта і від клієнта до джерела можуть бути різними. А саме від клієнта починає будуватися гілка дерева: маршрутизатор відправляє PIM Join в бік джерела / RP і RPF також перевіряє правильність інтерфейсу при отриманні трафіку.
  Ви пам'ятаєте, що спочатку цього параграфа на R5 була тільки запис (*, G), тепер після всіх цих подій їх стане дві: (*, G) і (S, G) .
  

 
Між іншим, навіть якщо ви подивіться на мультікастового таблицю маршрутизації R3 в ту ж секунду, як натиснули Play в VLC, то побачите, що він вже отримує трафік від R1 безпосередньо, про що говорить наявність запису (S, G).
 Тобто SPT Switchover вже стався — це дія за замовчуванням на обладнанні багатьох виробників — ініціювати перемикання після отримання першого ж мультікастового пакета.
 
Взагалі кажучи, відбуватися таке перемикання може в кількох випадках:
  
     
  • Чи не відбуватися взагалі ніколи (команда ip pim spt-threshold infinity ).
  •  
  • При досягненні певної утилізації смуги пропускання (команда ip pim spt-threshold X ).
  •  
  • Безумовно — відразу після отримання першого пакету (дія за умовчанням або no ip pim spt-threshold X )
  •  
 Як правило, рішення про те, що «пора», приймає LHR.
  
У цьому випадку вдруге змінюється правило роботи RPF — він знову перевіряє місцезнаходження джерела. Тобто з двох потоків мультикаст — від RP і від джерела — перевага віддається трафіку від джерела.
  

  
  DR, Assert, Forwarder
 Ще кілька важливих моментів при розгляді PIM.
 
 DR — Designated Router .
 Це виділений маршрутизатор, який відповідальний за відправлення службових пакетів на RP.
  Source DR — відповідає за прийняття мультікастового пакетів безпосередньо від джерела і його реєстрацію на RP.
 Ось приклад топології:
 
 
 
Тут ні до чого, щоб обидва маршрутизатора передавали трафік на RP, нехай вони резервують один одного, але відповідальний повинен бути тільки один.
 Оскільки обидва маршрутизатора підключені в одну широкомовну мережу, вони отримують один від одного PIM-Hello. На основі нього вони і роблять свій вибір.
 PIM Hello несе значення пріоритету даного маршрутизатора на даному інтерфейсі.
 
 
 
Чим більше значення, тим вище пріоритет. Якщо вони однакові, то вибирається вузол з найбільшим IP-адресою (теж з повідомлення Hello).
 
 
 
Якщо інший маршрутизатор (Не DR) протягом Holdtime (за замовчуванням 105 с) не отримував Hello від сусіда, він автоматично бере на себе роль DR.
 
По суті Source DR — це FHR — First Hop Router .
 
 Receiver DR — те ж, що Source DR, тільки для одержувачів мультікастового трафіку — LHR (Last Hop Router) .
 Приклад топології:
 
 
 
Receiver DR відповідальний за відправлення на RP PIM Join. У вищенаведеної топології, якщо обидва маршрутизатора відправлять Join, то обидва будуть отримувати мультікастового трафік, але в цьому немає необхідності. Тільки DR відправляє Join. Другий просто моніторить доступність DR.
 Оскільки DR відправляє Join, то він же і буде віщати трафік в LAN. Але тут виникає закономірне питання — а що, якщо PIM DR'ом став один, а IGMP Querier'ом інший? А ситуація-то цілком можлива, адже для Querier чим менше IP, тим краще, а для DR, навпаки.
 У цьому випадку DR'ом вибирається той маршрутизатор, який вже є Querier і така проблема не виникає.
 
 
 
Правила вибору Receiver DR точно такі ж, як і Source DR.
 
 Assert і PIM Forwarder
 Проблема двох одночасно передавальних маршрутизаторів може виникнути і в середині мережі, де немає ні кінцевих клієнтів, ні джерел — тільки маршрутизатори.
 Дуже гостро це питання стояло в PIM DM, де це була зовсім рядова ситуація через механізму Flood and Prune.
 Але і в PIM SM вона не виключена.
 Розглянемо таку мережу:
 
 
 
Тут три маршрутизатора знаходяться в одному сегменті мережі і, відповідно, є сусідами по PIM. R1 виступає в ролі RP.
 R4 відправляє PIM Join у бік RP. Оскільки цей пакет мультікастового він потрапляє і на R2 і на R3, і обидва вони обробивши його, додають низхідний інтерфейс в OIL.
 Тут би повинен спрацювати механізм вибору DR, але і на R2 і на R3 є інші клієнти цієї групи, і обом маршрутизаторам так чи інакше доведеться відправляти PIM Join.
 Коли мультікастового трафік приходить від джерела на R2 і R3, в сегмент він передається обома маршрутизаторами і задваівается там. PIM не намагається запобігти такій ситуації — тут він діє за фактом доконаного злочину — як тільки в свій низхідний інтерфейс для певної групи (зі списку OIL) маршрутизатор отримує мультікастового трафік цієї самої групи, він розуміє: щось не так — другий відправник вже є в цьому сегменті.
 
 
 
Тоді маршрутизатор відправляє спеціальне повідомлення PIM Assert .
 Таке повідомлення допомагає вибрати PIM Forwarder — той маршрутизатор, який має право вести мовлення в даному сегменті.
 
 
 
Не треба його плутати з PIM DR. По-перше, PIM DR відповідає за відправку повідомлень PIM Join і Prune , а PIM Forwarder — за відправку трафіку . Друга відмінність — PIM DR вибирається завжди і в будь-яких мережах при встановленні сусідства, А PIM Forwrder тільки при необхідності — коли отримано мультікастового трафік з інтерфейсу зі списку OIL.
  

 
  Вибір RP
 Вище ми для простоти задавали RP вручну командою ip pim rp-address XXXX .
 І ось як виглядала команда show ip pim rp :
 
 
 
Але уявімо абсолютно неможливу в сучасних мережах ситуацію — R2 вийшов з ладу. Це все — фініш. Клієнт 2 ще працюватиме, оскільки відбувся SPT Switchover, а от все нове і все, що йшло через RP зламається, навіть якщо є альтернативний шлях.
 Ну і навантаження на адміністратора домену. Уявіть собі: на 50 маршрутизаторах перебити вручну як мінімум одну команду (а для різних груп адже можуть бути різні RP).
 
Динамічний вибір RP дозволяє і уникнути ручної роботи і забезпечити надійність — якщо одна RP стане недоступна, в бій вступить відразу ж інша.
 
У даний момент існує один загальновизнаний протокол, що дозволяє це зробити — Bootstrap . Циска в колишні часи просувала кілька незграбний Auto-RP , але зараз він майже не використовується, хоча циска цього не визнає, і в show ip mroute ми маємо дратівливий рудимент у вигляді групи 224.0.1.40.
  
Треба насправді віддати належне протоколу Auto-RP. Він був порятунком в колишні часи. Але з появою відкритого і гнучкого Bootstrap, він закономірно поступився свої позиції.
 Отже, припустимо, що в нашій мережі ми хочемо, щоб R3 підхоплював функції RP в разі виходу з ладу R2.
 R2 і R3 визначаються як кандидати на роль RP — так вони і називаються C-RP . На цих маршрутизаторах налаштовуємо:
  
RX(config)interface Loopback 0
	RX(config-if)ip pim sparse-mode
	RX(config-if)exit
	RX(config)#ip pim rp-candidate loopback 0	

 
Але поки нічого не відбувається — кандидати поки не знають, як повідомити всіх про себе.
 
Щоб інформувати всі мультікастового маршрутизатори домену про існуючі RP вводиться механізм BSR — BootStrap Router . Претендентів може бути декілька, як і C-RP. Вони називаються відповідно C-BSR . Налаштовуються вони схожим чином.
 
Нехай BSR у нас буде один і для тесту (виключно) це буде R1.
  

	R1(config)interface Loopback 0
	R1(config-if)ip pim sparse-mode
	R1(config-if)exit
	R1(config)#ip pim bsr-candidate loopback 0	

 Спочатку з усіх C-BSR вибирається один головний BSR, який і буде всім заправляти. Для цього кожен C-BSR відправляє в мережу мультікастового BootStrap Message (BSM) на адресу 224.0.0.13 — це теж пакет протоколу PIM. Його повинні прийняти і обробити всі мультікастового маршрутизатори і після розіслати в усі порти, де активований PIM. BSM передається не в бік чогось (RP або джерела), на відміну, від PIM Join, а в усі сторони. Така віялова розсилка допомагає досягти BSM усіх куточків мережі, в тому числі всіх C-BSR і всіх C-RP. Для того, щоб BSM не блукали по мережі нескінченно, застосовується все той же механізм RPF — якщо BSM прийшов не з того інтерфейсу, за яким знаходиться мережа відправника цього повідомлення, таке повідомлення відкидається.
 
 
 
За допомогою цих BSM все мультікастового маршрутизатори визначають найдостойнішого кандидата на основі пріоритетів. Як тільки C-BSR отримує BSM від іншого маршрутизатора з більшим пріоритетом, він припиняє розсилати свої повідомлення. У результаті всі мають однаковою інформацією.
 
 
 
На цьому етапі, коли обрано BSR, завдяки тому, що його BSM розійшлися вже по всій мережі, C-RP знають його адресу і Юнікаст відправляють на нього повідомлення Candidte-RP-Advertisement , в яких вони несуть список груп, які вони обслуговують — це називається group-to-RP mapping . BSR всі ці повідомлення агрегує і створює RP-Set — інформаційну таблицю: які RP кожну групу обслуговують.
 
 
 
Далі BSR в колишній віяловій манері розсилає ті ж BootStrap Message, які цього разу містять RP-Set. Ці повідомлення успішно досягають всіх мультікастового маршрутизаторів, кожен з яких самостійно робить вибір, яку RP потрібно використовувати для кожної конкретної групи.
 
 
 
BSR періодично робить такі розсилки, щоб з одного боку всі знали, що інформація по RP ще актуальна, а з іншого C-BSR були в курсі, що сам головний BSR ще живий.
 RP, до речі, теж періодично шлють на BSR свої анонси Candidate-RP-Advertisement.
 
Фактично все, що потрібно зробити для налаштування автоматичного вибору RP — вказати C-RP і вказати C-BSR — не так вже й багато роботи, все інше за вас зробить PIM.
 Як завжди, з метою підвищення надійності рекомендується вказувати інтерфейси Loopback в якості кандидатів.
  

 
 

Завершуючи главу PIM SM, давайте ще раз відзначимо найважливіші моменти

  
     
  1. Повинна бути забезпечена звичайна юнікастовая зв'язність за допомогою IGP або статичних маршрутів. Це лежить в основі алгоритму RPF.
  2.  
  3. Дерево будується тільки після появи клієнта. Саме клієнт ініціює побудову дерева. Ні клієнта — немає дерева.
  4.  
  5. RPF допомагає уникнути петель.
  6.  
  7. Всі маршрутизатори повинні знати про те, хто є RP — тільки з її допомогою можна побудувати дерево.
  8.  
  9. Точка RP може бути вказана статично, а може вибиратися автоматично за допомогою протоколу BootStrap.
  10.  
  11. У першій фазі будується RPT — дерево від клієнтів до RP — і Source Tree — дерево від джерела до RP. У другій фазі відбувається перемикання з побудованого RPT на SPT — найкоротший шлях від одержувача до джерела.
  12.  
 
Ще перерахуємо всі типи дерев і повідомлень, які нам тепер відомі.
 
 MDT — Multicast Distribution Tree . Загальний термін, що описує будь-яке дерево передачі мультикаст.
  SPT — Shortest Path Tree . Дерево з найкоротшим шляхом від клієнта або RP до джерела. У PIM DM є тільки SPT. У PIM SM SPT може бути від джерела до RP або від джерела до одержувача після того, як стався SPT Switchover. Позначається записом (S, G) — відомий джерело для групи.
  Source Tree — те ж саме, що SPT.
  RPT — Rendezvous Point Tree . Дерево від RP до одержувачів. Використовується тільки в PIM SM. Позначається записом (*, G) .
  Shared Tree — те ж, що RPT. Називається так тому, що всі клієнти підключені до одного загального дереву з коренем в RP.
 
Типи повідомлень PIM Sparse Mode:
  Hello — для встановлення сусідства і підтримки цих відносин. Також необхідні для вибору DR.
  Join (*, G) — запит на підключення до дерева групи G. Не важливо хто джерело. Відправляється в сторону RP. З їх допомогою будується дерево RPT.
  Join (S, G) — Source Specific Join. Це запит на підключення до дерева групи G з певним джерелом — S. Відправляється в бік джерела — S. З їх допомогою будується дерево SPT.
  Prune (*, G) — запит на відключення від дерева групи G, які б джерела для неї не були. Відправляється в сторону RP. Так обрізається гілка RPT.
  Prune (S, G) — запит на відключення від дерева групи G, коренем якого є джерело S. Відправляється в бік джерела. Так обрізається гілка SPT.
  Register — спеціальне повідомлення, всередині якого передається мультикаст на RP, поки не буде побудовано SPT від джерела до RP. Передається Юнікаст від FHR на RP.
  Register-Stop — відправляється Юнікаст з RP на FHR, наказуючи припинити посилати мультікастового трафік, інкапсульований в Register.
  Bootstrap — пакети механізму BSR, які дозволяють вибрати маршрутизатор на роль BSR, а також передають інформацію про існуючі RP і групах.
  Assert — повідомлення для вибору PIM Forwarder, щоб в один сегмент не передавали трафік два маршрутизатора.
  Candidate-RP-Advertisement — повідомлення, в якому RP відсилає на BSR інформацію про те, які групи він обслуговує.
  RP-Reachable — повідомлення від RP, яким вона повідомляє всіх про свою доступності.
  * Є й інші типи повідомлень в PIM, але це вже деталі *
  

 
А давайте тепер спробуємо абстрагуватися від деталей протоколу? І тоді стає очевидною його складність.
 
1) Визначення RP,
 2) Реєстрація джерела на RP,
 3) Перемикання на дерево SPT.
 
Багато станів протоколу, багато записів у таблиці мультікастового маршрутизації. Чи можна щось з цим зробити?
 
На сьогоднішній день існує два діаметрально протилежних підходи до спрощення PIM: SSM і BIDIR PIM.
 
 
  SSM
 Все, що ми описували досі — це ASM — Any Source Multicast . Клієнтам байдуже, хто є джерелом трафіку для групи — головне, що вони його отримують. Як ви пам'ятаєте в повідомленні IGMPv2 Report запитується просто підключення до групи.
  SSM — Source Specific Multicast — альтернативний підхід. У цьому випадку клієнти при підключенні вказують групу і джерело.
 Що ж це дає? Ні багато ні мало: можливість повністю позбутися RP. LHR відразу знає адресу джерела — немає необхідності слати Join на RP, маршрутизатор може відразу ж відправити Join (S, G) у напрямку джерела і побудувати SPT.
 Таким чином ми позбавляємося від
  
     
  • Пошуку RP (протоколи Bootstrap і Auto-RP),
  •  
  • Реєстрації джерела на мультикаст (а це зайвий час, подвійне використання смуги пропускання і туннелирование)
  •  
  • Перемикання на SPT.
  •  
 Оскільки немає RP, то немає і RPT, відповідно ні на одному маршрутизаторі вже не буде записів (*, G) — тільки (S, G).
 Ще одна проблема, яка вирішується за допомогою SSM — наявність декількох джерел. У ASM рекомендується, щоб адреса мультікастового групи був унікальний і тільки одне джерело віщав на нього, оскільки в дереві RPT декілька потоків зіллються, а клієнт, отримуючи два потоку від різних джерел, ймовірно, не зможе їх розібрати.
 У SSM трафік від різних джерел поширюється незалежно, кожен по своєму дереву SPT, і це вже стає проблемою, а перевагою — кілька серверів можуть віщати одночасно. Якщо раптом клієнт почав фіксувати втрати від основного джерела, він може переключитися на резервний, навіть не перезапрашівая його — він і так отримував два потоки.
 
Крім того, можливий вектор атаки в мережі з активованою мультікастового маршрутизацією — підключення зловмисником свого джерела і генерування великого обсягу мультікастового трафіку, який перевантажить мережу. У SSM таке практично виключено.
 
Для SSM виділений спеціальний діапазон IP-адрес: 232.0.0.0 / 8.
 На маршрутизаторах для підтримки SSM включається режим PIM SSM.
 
 
Router(config)# ip pim ssm

  
 IGMPv3 і MLDv2 підтримують SSM в чистому вигляді.
 При їх використанні клієнт може
  
     
  • Запитувати підключення до просто групі, без зазначення джерел. Тобто працює як типовий ASM.
  •  
  • Запитувати підключення до групи з певним джерелом. Джерел можна вказати кілька — до кожного з них буде побудовано дерево.
  •  
  • Запитувати підключення до групи і вказати список джерел, від яких клієнт не хотів б отримувати трафік
  •  
 
 
 
IGMPv1/v2, MLDv1 не підтримують SSM, але має місце таке поняття, як SSM Mapping . На найближчому до клієнта маршрутизаторі (LHR) кожній групі ставиться у відповідність адреса джерела (або декілька). Тому якщо в мережі є клієнти, які не підтримують IGMPv3/MLDv2, для них також буде побудовано SPT, а не RPT, завдяки тому, що адреса джерела все одно відомий.
 SSM Mapping може бути реалізований як статичної налаштуванням на LHR, так і за допомогою звернення до DNS-сервера.
 
Проблема SSM в тому, що клієнти повинні заздалегідь знати адреси джерел — ніякої сигналізацією вони їм не повідомляються.
 Тому SSM гарний у тих ситуаціях, коли в мережі певний набір джерел, їх адреси завідомо відомі і не будуть змінюватися. А клієнтські термінали або програми жорстко прив'язані до них.
 Іншими словами IPTV — вельми придатна середовище для впровадження SSM. Це добре описує концепцію One-to-Many — одне джерело, багато одержувачів.
  

 
  BIDIR PIM
 А що якщо в мережі джерела можуть з'являтися спонтанно то там, то тут, віщати на однакові групи, швидко припиняти передачу і зникати?
 Наприклад, така ситуація можлива в мережевих іграх або в ЦОД, де відбувається реплікація даних між різними серверами. Це концепція Many-to-Many — багато джерел, багато клієнтів.
 Як на це дивиться звичайний PIM SM? Ясна річ, що інертний PIM SSM тут зовсім не підходить?
 Ви тільки подумайте, який хаос почнеться: нескінченні реєстрації джерел, перестроювання дерев, величезна кількість записів (S, G) живуть по кілька хвилин з-за таймерів протоколу.
 На виручку йде двонаправлений PIM (Bidirectional PIM, BIDIR PIM ). На відміну від SSM в ньому навпаки повністю відмовляються від SPT і записів (S, G) — залишаються тільки Shared Tree з коренем в RP.
 І якщо в звичайному PIM, дерево є одностороннім — трафік завжди передається від джерела вниз по SPT і від RP вниз по RPT — є чіткий розподіл, де джерело, де клієнти, то в двунаправленном від джерела трафік до RP передається також вгору по Shared Tree — по тому ж самому, за яким трафік тече вниз до клієнтів.
 
Це дозволяє відмовитися від реєстрації джерела на RP — трафік передається безумовно, без якої б то не було сигналізації та зміни станів. Оскільки дерев SPT немає взагалі, то і SPT Switchover теж не відбувається.
 
Ось наприклад:
 
 
 
 Істочнік1 почав передавати в мережу трафік групи 224.2.2.4 одночасно з Істочніком2 . Потоки від них просто полилися в сторону RP. Частина клієнтів, які знаходяться поруч почали отримувати трафік відразу, тому що на маршрутизаторах є запис (*, G) (є клієнти). Інша частина отримує трафік по Shared Tree від RP. Причому отримують вони трафік від обох джерел одночасно.
 Тобто, якщо взяти для прикладу умоглядну мережеву гру, Істочнік1 це перший гравець в стрелялке, який зробив постріл, а Істочнік2 — це інший гравець, який зробив крок убік. Інформація про ці дві події поширилася по всій мережі. І кожен інший гравець (Одержувач ) повинен дізнатися про обох цих подіях.
  
Якщо пам'ятаєте, то трохи раніше ми пояснили, навіщо потрібен процес реєстрації джерела на RP — щоб трафік не займав канал, коли немає клієнтів, тобто RP просто відмовлявся від нього. Чому над цією проблемою ми не замислюємося зараз? Причина проста: BIDIR PIM для ситуацій, коли джерел багато, але вони віщають не постійно, а періодично, відносно невеликими шматками даних. Тобто канал від джерела до RP НЕ утилізуватиметься даремно.
 Зверніть увагу, що на зображенні вище між R5 і R7 є пряма лінія, набагато більш коротка, ніж шлях через RP, але вона не була використана, тому що Join йдуть у бік RP згідно з таблицею маршрутизації, в якій даний шлях не є оптимальним.
 
Виглядає досить просто — потрібно відправляти мультікастового пакети в напрямку RP і все, але є один нюанс, який все псує — RPF. У дереві RPT він вимагає, щоб трафік приходив від RP і не інакше. А у нас він може приходити звідки завгодно. Взяти і відмовитися від RPF ми, звичайно, не можемо — це єдиний механізм, який дозволяє уникнути утворення петель.
 
Тому в BIDIR PIM вводиться поняття DF — Designated Forwarder . У кожному сегменті мережі, на кожній лінії на цю роль вибирається той маршрутизатор, чий маршрут до RP краще.
 У тому числі це робиться і на тих лініях, куди безпосередньо підключені клієнти. У BIDIR PIM DF автоматично є DR.
 
 
 
Список OIL формується тільки з тих інтерфейсів, на яких маршрутизатор був обраний на роль DF.
 
Правила досить прозорі:
  
     
  • Якщо запит PIM Join / Leave приходить на той інтерфейс, який в даному сегменті є DF, він передається в сторону RP за стандартними правилами.
     Ось, наприклад, R3. Якщо запити прийшли в DF інтерфейси, що позначені червоним колом, він їх передає на RP (через R1 або R2, залежно від таблиці маршрутизації).
  •  
  • Якщо запит PIM Join / Leave прийшов на НЕ DF інтерфейс, він буде проігнорований.
     Припустимо, що клієнт, що знаходиться між R1 і R3, вирішив підключитися і відправив IGMP Report. R1 отримує його через інтерфейс, де він обраний DF (позначений червоним колом), і ми повертаємося до попереднього сценарію. А R3 отримує запит на інтерфейс, який не є DF. R3 бачить, що тут він не найкращий, і ігнорує запит.
  •  
  • Якщо мультікастового трафік прийшов на DF інтерфейс, він буде відправлений у інтерфейси зі списку OIL і в бік RP.
     Наприклад, Істочнік1 почав передавати трафік. R4 отримує його в свій DF інтерфейс і передає його і в іншій DF-інтерфейс — в сторону клієнта і в бік RP, — це важливо, тому що трафік повинен потрапити на RP і поширитися по всім одержувачам. Також надходить і R3 — одна копія в інтерфейси зі списку OIL — тобто на R5, де він буде відкинутий через перевірки RPF, і інша — в бік RP.
  •  
  • Якщо мультікастового трафік прийшов на НЕ DF інтерфейс, він повинен бути відправлений в інтерфейси зі списку OIL, але НЕ БУДЕ відправлений у бік RP.
     Наприклад, Істочнік2 почав віщати, трафік дійшов до RP і почав поширюватися вниз по RPT. R3 отримує трафік від R1, і він не передасть його на R2 — тільки вниз на R4 і на R5.
  •  
 
Таким чином DF гарантує, що на RP в підсумку буде відправлена ​​тільки одна копія мультікастового пакета та освіта петель виключено. При цьому те загальне дерево, в якому знаходиться джерело, природно, отримає цей трафік ще до потрапляння на RP. RP, згідно звичайними правилами розішле трафік в усі порти OIL, крім того, звідки прийшов трафік.
 
До речі, немає потреби більш і в повідомленнях Assert, адже DF вибирається в кожному сегменті. На відміну від DR він відповідає не тільки за відправку Join до RP, а й за передачу трафіку в сегмент, тобто ситуація, коли два маршрутизатора передають в одну підмережа трафік, виключена в BIDIR PIM.
 
Мабуть, останнє, що потрібно сказати про двунаправленном PIM, це особливості роботи RP. Якщо в PIM SM RP виконував цілком конкретну функцію — реєстрація джерела, то в BIDIR PIM RP — це якась дуже умовна точка, до якої прагне трафік з одного боку і Join від клієнтів з іншого. Ніхто не повинен виконувати декапсуляцію, запитувати побудова дерева SPT. Просто на якомусь маршрутизаторі раптом трафік від джерел починає передаватися в Shared Tree. Чому я кажу «на якомусь»? Справа в тому, що в BIDIR PIM RP — абстрактна точка, а не конкретний маршрутизатор, як адреса RP взагалі може виступати неіснуючий IP-адреса — головне, щоб він був маршрутизациї (така RP називається Phantom RP ).
 
Всі терміни, що стосуються PIM, можна знайти в глосарії .
  

 
  мультикаст на канальному рівні
 Отже, позаду довга трудовий тиждень з недосипамі, переробками, тестами — ви успішно впровадили мультикаст і задовольнили клієнтів, директора та відділ продажів.
 П'ятниця — не найгірший день, щоб оглянути творіння і дозволити собі приємний відпочинок.
 Але ваш післяобідній сон раптом потривожив дзвінок техпідтримки, потім ще один і ще — нічого не працює, все зламалося. Перевіряєте — йдуть втрати, розриви. Все сходиться на одному сегменті з декількох комутаторів.
 
Розчохлили SSH, перевірили CPU, перевірили утилізацію інтерфейсів і волосся дибки — завантаження майже під 100% на всіх інтерфейсах одного VLAN'а. Петля! Але звідки їй узятися, якщо ніяких робіт не проводилося? Хвилин 10 перевірки і ви помітили, що на висхідному інтерфейсі до ядра у вас багато вхідного трафіку, а на всіх низхідних до клієнтів — вихідного. Для петлі це теж характерно, але якось підозріло: впровадили мультикаст, ніяких робіт з переключення не робили і стрибок тільки в одному напрямку.
 Перевірили список мультікастового груп на маршрутизаторі — а там підписка на всі можливі канали і все на один порт — природно, той, який веде в цей сегмент.
 Допитливе розслідування показало, що комп'ютер клієнта заражений і розсилає IGMP Query на все мультікастового адреси поспіль.
 
Втрати пакетів почалися, тому що коммутаторам довелося пропускати через себе величезний обсяг трафіку. Це викликало переповнення буферів інтерфейсів.
 
Головне питання — чому трафік одного клієнта почав копіюватися в усі порти?
 
Причина цього криється в природі мультікастового MAC-адрес. Справа в тому, простір мультікастового IP-адрес спеціальним чином відображається в простір мультікастового MAC-адрес. І заковика в тому, що вони ніколи не будуть використовуватися в якості MAC-адреси джерела, а отже, не будуть вивчені комутатором і занесені в таблицю MAC-адрес. А як надходить комутатор з кадрами, адресу призначення яких не вивчений? Він їх розсилає в усі порти. Що й сталося.
 Ця дія за замовчуванням.
 
 
 
 мультікастового MAC-адреси
 Так які ж MAC-адреси одержувачів підставляються в заголовок Ethernet таких пакетів? Широкомовні? Ні. Існує спеціальний діапазон MAC-адрес, в які відображаються мультікастового IP-адреси.
 Ці спеціальні адреси починаються так: 0x01005e і наступний 25-й біт повинен бути 0 (спробуйте відповісти, чому так ). Решта 23 біта (нагадаю, всього їх в МАС-адресі 48) переносяться з IP-адреси.
 
Тут криється деяка не надто серйозна, але проблема. Діапазон мультікастового адрес визначається маскою 224.0.0.0 / 4, це означає, що перші 4 біти зарезервовані: 1110, а що залишилися 28 біт можуть змінюватися. Тобто у нас 2 ^ 28 мультікастового IP-адрес і тільки 2 ^ 23 MAC-адрес — для відображення 1 в 1 не вистачає 5 біт. Тому беруться просто останні 23 біта IP-адреси та один в один переносяться в MAC-адресу, решта 5 відкидаються.
 
 
 
Фактично це означає, що в один мультікастового MAC-адреса буде відображатися 2 ^ 5 = 32 IP-адреси. Наприклад, групи 224.0.0.1, 224.128.0.1, 225.0.0.1 і так до 239.128.0.1 всі будуть відображатися в один MAC-адресу 0100:5 e00: 0001.
 
Якщо взяти за приклад дамп потокового відео, то можна побачити:
 
 
 
IP адреса — 224.2.2.4, MAC-адреса: 01:00:5 E: 2:02:04.
 
Є також інші мультікастового MAC-адреси, які ніяк не відносяться до IPv4-мультикаст (клік ). Всі вони, до речі, характеризуються тим, що останній біт першого октету дорівнює 1.
 
Природно, ні на одній мережевій карті, не може бути налаштований такий MAC-адресу, тому він ніколи не буде в полі Source MAC Ethernet-кадру і ніколи не потрапить в таблицю MAC-адрес. Значить такі кадри повинні розсилатися як будь Unknown Unicast в усі порти VLAN'а.
 
Всього, що ми розглядали раніше, цілком достатньо для повноцінної передачі будь-якого мультікастового трафіку від потокового відео до біржових котирувань. Але невже ми у своєму майже досконалому світі будемо мириться з таким неподобством, як широкомовна передача того, що можна було б передати обраним?
 Зовсім ні. Спеціально для перфекціоністів придуманий механізм IGMP-Snooping .
  

 
  IGMP-Snooping
 Ідея дуже проста — комутатор «слухає» проходять через нього IGMP-пакети.
 Для кожної групи окремо він веде таблицю висхідних і низхідних портів.
 
Якщо з порту прийшов IGMP Report для групи, значить там клієнт, комутатор додає його до списку низхідних для цієї групи.
 Якщо з порту прийшов IGMP Query для групи, значить там маршрутизатор, комутатор додає його до списку висхідних.
 
Таким чином формується таблиця передачі мультікастового трафіку на канальному рівні.
 У підсумку, коли зверху приходить мультікастового потік, він копіюється тільки в спадні інтерфейси. Якщо на 16-портовому комутаторі тільки два клієнта, тільки їм і буде доставлений трафік.
 
 
 
Геніальність цієї ідеї закінчується тоді, коли ми замислюємося про її природу. Механізм передбачає, що комутатор повинен прослуховувати трафік на 3-му рівні.
 
Втім, IGMP-Snooping ні в яке порівняння не йде з NAT за ступенем ігнорування принципів мережевої взаємодії. Тим більше, крім економії в ресурсах, він несе в собі масу менш очевидних можливостей. Та й загалом-то в сучасному світі, комутатор, який вміє заглядати всередину IP — явище не виняткове.
 
 
=====================
 Завдання № 3
 
 Схема і початкова конфігурація .
 
 
 
Сервер 172.16.0.5 передає мультикаст трафік на групи 239.1.1.1, 239.2.2.2 і 239.0.0.x.
Налаштувати мережу таким чином, щоб:
 - Клієнт 1 не міг приєднатися до групи 239.2.2.2. Але при цьому міг приєднатися до групи 239.0.0.x.
 - Клієнт 2 не міг приєднатися до групи 239.1.1.1. Але при цьому міг приєднатися до групи 239.0.0.x.
 
Подробиці завдання тут .
=====================
 
 
 

 
 IGMP Snooping Proxy
 У допитливого читача може виникнути питання по тому, як IGMP Snooping дізнається всі клієнтські порти, враховуючи, що на IGMP Query відповідає тільки один найшвидший клієнт, як ми говорили вище. А дуже просто: IGMP-Snooping не дозволяє повідомленнями Report ходити між клієнтами. Вони відправляються тільки в висхідні порти до маршрутизаторів. Не бачачи Report від інших одержувачів цієї групи, клієнт зобов'язаний відповісти на Query протягом Max Response Time, зазначеному в цьому Query.
 У підсумку в мережі на 1000 вузлів на один IGMP Query протягом секунд 10 (звичайне значення Max Response Time) прийде 1000 Report'ов маршрутизатора. Хоча йому досить було б і одного для кожної групи.
 І відбувається це кожну хвилину.
 
У цьому випадку можна налаштувати проксінг IGMP-запитів. Тоді комутатор не просто «слухає» проходять пакети, він їх перехоплює.
 
Правила роботи IGMP-Snooping можуть відрізнятися для різних виробників. Тому розглянемо їх концептуально:
 
1) Якщо на комутатор приходить найперший запит Report на групу, він відправляється вгору до маршрутизатора, а інтерфейс вноситься в список низхідних. Якщо ж така група вже є, інтерфейс просто додається до списку низхідних, а Report знищується.
 2) Якщо на комутатор приходить самий останній Leave, тобто інших клієнтів немає, цей Leave буде відправлений на маршрутизатор, а інтерфейс видаляється зі списку низхідних. В іншому випадку просто видаляється інтерфейс, Leave знищується.
 3) Якщо IGMP Query приходить від маршрутизатора, комутатор перехоплює його, відправляє у відповідь IGMP Report для всіх груп, які в даний момент мають одержувачів.
 А далі, в залежності від налаштувань і виробника, або цей же самий Query розсилається в усі клієнтські порти, або комутатор блокує запит від маршрутизатора і сам виступає в ролі Querier, періодично опитуючи всіх одержувачів.
 
Таким чином знижується і частка зайвого службового трафіку в мережі і навантаження на маршрутизатор.
 
 
  Multicast VLAN Replication
 Скорочено MVR . Це механізм для тих провайдерів, хто практикує VLAN-per-user , наприклад.
 Ось типовий приклад мережі, де MVR життєво необхідний:
 
 
 
5 клієнтів у різних VLAN'ах, і всі хочуть отримувати мультікастового трафік однієї групи 224.2.2.4. При цьому клієнти повинні залишатися ізольованими один від одного.
 
IGMP-Snooping враховує, зрозуміло і VLAN'и. Якщо п'ять клієнтів у різних VLAN'ах запитують одну групу — це буде п'ять різних таблиць. Відповідно і до маршрутизатора йдуть 5 запитів на підключення до групи. І кожен сабінтерфейс з цих п'яти на маршрутизаторі буде додано окремо в OIL. Тобто отримавши 1 потік для групи 224.2.2.4 він відправить 5 копій, незважаючи на те, що всі вони йдуть в один сегмент.
 
 
 
Для вирішення цієї проблеми і було розроблено механізм Multicast VLAN Replication.
 Вводиться додатковий VLAN — Multicast VLAN — у ньому, відповідно, буде передаватися мультікастового потік. Він «проброшен» безпосередньо до останнього комутатора, де трафік з нього копіюється в усі клієнтські інтерфейси, які хочуть отримувати цей трафік — це і є реплікація.
 Залежно від реалізації реплікація з Multicast VLAN може проводитися в User-VLAN або в певні фізичні інтерфейси.
 
 
 А що з IGMP-повідомленнями? Query від маршрутизатора, природно, приходить по мультікастового VLAN'у. Комутатор їх розсилає в клієнтські порти. Коли Report або Leave приходить від клієнта, комутатор перевіряє звідки саме (VLAN, інтерфейс) і, якщо необхідно, перенаправляє в мультікастового VLAN.
 Таким чином звичайний трафік ізольований і раніше ходить до маршрутизатора в призначеному для користувача VLAN'е. А мультікастового трафік і IGMP-пакети передаються в Multicast VLAN.
  
На обладнанні Cisco MVR і IGMP-Snooping налаштовуються незалежно. Тобто можна відключити один і другий буде працювати. Взагалі ж MVR заснований на IGMP-Snooping і на комутаторах інших виробників для роботи MVR може бути обов'язковим включення IGMP-Snooping.
 Крім того, IGMP-Snooping дозволяє здійснювати на комутаторах фільтрацію трафіку, обмежувати кількість груп, доступних користувачеві, включення IGMP Querier, статичну настройку висхідних портів, перманентне підключення до якої-небудь групи (цей сценарій є в супутньому відео ), швидку реакцію на зміна топології шляхом розсилки додаткових Query, SSM-Mapping для IGMPv2 ітд.
 
 Закінчуючи розмову про IGMP-Snooping, хочеться повторити — це необов'язковий функціонал — все і без нього буде працювати. Але це зробить мережу більш передбачуваною, а життя інженера спокійніше.
 Проте всі плюси IGMP Snooping можна обернути і проти себе. Один такий видатний випадок можна почитати по посиланням .
 До слова у тієї ж Cisco є протокол CGMP — аналог IGMP, яка не порушує принципи роботи комутатора, але він пропріетарний і не сказати, що широко поширений.
  

 
Отже, мій невтомний читач, ми наближаємося до кінця випуску і наостанок хочеться показати, як може бути реалізована послуга IPTV на стороні клієнта.
 Найпростіший спосіб, до якого ми вже не раз зверталися в цій статті — запустити плеєр, який може прийняти мультікастового потік з мережі. На ньому можна вручну задати IP-адресу групи і насолоджуватися відео.
 Інший програмний варіант, який часто використовують провайдери — спеціальний додаток, зазвичай вельми кастомними, в якому зашитий набір каналів, які у мережі провайдера. Немає необхідності щось задавати вручну — потрібно просто перемикати канали кнопками.
 
Обидва ці способи дають можливість дивитися потокове відео тільки на комп'ютері.
 
Третій же варіант дозволяє використовувати телевізор, причому як правило, будь-який. Для цього в будинку клієнта ставить так званий Set-Top-Box (STB) — коробочка, що встановлюється на телевізор. Це Шелезяка, яка включається в абонентську лінію і розділяє трафік: звичайний Юнікаст вона віддає в Ethernet або WiFi, щоб клієнти мали доступ в Інтернет, а мультікастового потік передається на телевізор через кабель (DVI, RGB, антенний ітд.).
 Часто ви, до речі, можете побачити рекламу, де провайдер пропонує свої приставки для підключення телебачення — це і є ті самі STB
  
 
=====================
 Завдання № 4
 
Наостанок нетривіальна задачка по мультикаст (автори не ми, у відповідях буде посилання на оригінал).
 
Найпростіша схема:
 
 
 
З одного боку сервер-джерело, з дугою — комп'ютер, який готовий приймати трафік.
 
Адреса мультікастового потоку ви можете встановлювати самі.
 
І відповідно, два питання:
 1. Що потрібно зробити, щоб комп'ютер міг отримувати потік і при цьому не вдаватися до мультікастового маршрутизації?
 2. Припустимо, ви взагалі не знаєте, що таке мультикаст і не можете його налаштовувати, як передати потік з сервера до комп'ютера?
 
Завдання легко шукається в пошуковику, але спробуйте вирішити її самі.
 
Подробиці завдання тут .
=====================
 
 
 

 
Незачепленими в статті залишилися междоменной маршрутизація мультікастового трафіку (MSDP , MBGP , BGMP ), балансування навантаження між RP (Anycast RP ), PGM , пропрієтарні протоколи. Але, я думаю, маючи як точку старту цю статтю, розібратися в іншому не складе труднощів.
Всі терміни, що стосуються мультикаст, ви можете знайти в телекомунікаційному глосарії lookmeup .
  
За допомогу у підготовці статті спасибі JDima
За технічну підтримку спасибі Наташі Самойленко .
 КДПВ намальована Ніною Долгополовой — чудовим художником і другом проекту.
 
У пулі статей СДСМ ще багато цікавого до закінчення, тому не потрібно ховати цикл через довгу відсутність випуску — з кожною новою статтею складність значно зростає. Попереду майже весь MPLS, IPv6, QoS і дизайн мереж.
 
Як ви вже, напевно, помітили, у linkmeup з'явився новий проект — Глосарій lookmeup (так, недалеко у нас пішла фантазія). Ми сподіваємося, що цей глосарій стане найповнішим довідником термінів у галузі зв'язку, тому ми будемо раді будь-якій допомозі в його заповненні. Пишіть нам на info@linkmeup.ru
 
Залишайтеся з нами .
  
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.