Оптимізація передачі multicast-трафіку в локальній мережі за допомогою IGMP snooping


Всім привіт! Сьогодні хотів би торкнутися теми передачі multicast-трафіку локальної корпоративної мережі, а саме роботу технології IGMP snooping на комутаторах. Так вийшло, що за останній тиждень до мене звернулося кілька людей з питаннями щодо цієї технології. І я вирішив підготувати невелику статтю з описом даної технології. Але в процесі підготовки, з'ясувалося, що стислістю тут не відбудешся, так як є про що написати. Кому цікавий питання роботи IGMP snooping, ласкаво просимо під кат.

Досить часто ми не особливо замислюємося над тим, як передається multicast трафік в межах нашого L2-домену корпоративної мережі. Нагадаю, multicast трафік (він же «багатоадресний трафік») призначений для передачі даних певної групи пристроїв. За замовчуванням комутатор передає multicast трафік як broadcast (трансляція), тобто на всі порти без винятку. Це обумовлено тим, що в пакеті multicast як MAC-адреси одержувача використовує спеціально сформований адресу, нікому не належить в мережі. Якщо multicast-трафіку не багато, це не створює великих проблем і найчастіше адміністратор не вживає ніяких заходів щодо оптимізації його передачі. Якщо ж такого трафіку багато чи хочеться просто «причесати» мережа, постає завдання обмежити його поширення. Тут на допомогу приходять різні технології оптимізації передачі multicast-трафіку на канальному рівні (IGMP snooping, CGMP тощо). Найбільш поширеною і мультивендорной є технологія IGMP snooping. IGMP snooping на багатьох пристроях включений за замовчуванням. Наприклад, це справедливо для комутаторів Cisco. Але як часто буває, щастя з коробки отримати вдається далеко не у всіх випадках. Включений IGMP snooping не завжди дає очікуваний результат і multicast трафік у ряді випадків чомусь продовжує литися з усіх портів. Давайте спробуємо розібратись з усім цим.

Почати варто з абревіатури IGMP. Всім нам відомо, що коли в мережі з'являється пристрій, який хоче отримувати певний multicast трафік, це пристрій повідомляє про своє бажання за коштами протоколу IGMP (Internet Group Management Protocol). На багатьох пристроях за замовчуванням використовується IGMP версії 2. Обмін повідомленнями даного протоколу в найпростішому випадку виглядає наступним чином:

  1. Пристрій, коли вирішує отримувати multicast трафік, відправляє свій запит в повідомленні IGMP Membership Report (далі IGMP Report). У ньому вказується, що саме пристрій бажає отримувати. Адреса запитуваної multicast-групи вказується в якості IP-адреси призначення. Дане повідомлення в першу чергу призначається найближчого маршрутизатора. Адже саме він відповідає за передачу трафіку між локальним сегментом та іншою мережею.

  2. Отримавши таке повідомлення, маршрутизатор починає транслювати в даний сегмент мережі, запитуваний multicast трафік. Звичайно, це відбувається за умови, що маршрутизатор сам бере участь у передачі multicast-трафіку і одержує потрібний трафік.

  3. Щоб бути впевненим, що в мережі все ще є одержувачі multicast-трафіку, маршрутизатор періодично розсилає повідомлення IGMP General Membership Query (далі IGMP General Query). Адже якщо нікого вже немає, навіщо даремно «засмічувати» даний сегмент мережі нікому не потрібним трафіком.

  4. У відповідь на IGMP General Query маршрутизатор отримує повідомлення IGMP Report. Зазвичай його відправляє один з одержувачів multicast-трафіку. Інші почувши це повідомлення, просто мовчать, так як одного підтвердження для кожної групи достатньо. Вибір того, хто буде відповідати маршрутизатора, реалізується через механізм Report Suppression.

    Report SuppressionЯкщо у нас в мережі багато одержувачів multicast-трафіку, їх відповіді на IGMP General Query можуть породити досить велика кількість повідомлень IGMP Report. Так як маршрутизатора достатньо отримати лише одне таке повідомлення, використовується наступний механізм оптимізації. У повідомленні IGMP General Query вказується максимальний час (Maximum Response Time — MTR), протягом якого маршрутизатор чекає відповіді. Клієнт, отримавши IGMP General Query, вибирає довільне значення таймера від 0 до MTR. Як тільки обраний час таймера закінчується, клієнт відправляє повідомлення IGMP Report. Це відбувається тільки в тому випадку, якщо до цього клієнт не отримав IGMP Report від якогось іншого одержувача.
  5. Коли пристрій більше не бажає отримувати multicast трафік для певної групи, воно шле повідомлення IGMP Leave.

  6. На це маршрутизатор відповідає повідомленням IGMP Group Membership-Specific Query (далі IGMP Group-Specific Query), уточнюючи, чи є ще у мережі пристрої, які бажають отримувати трафік для даної групи. Зазвичай цих повідомлень маршрутизатор відправляє два. Якщо такі пристрої в мережі є, вони відгукнуться. Якщо ні, маршрутизатор припинить трансляцію трафіку в локальний сегмент мережі.
Більш детально про роботи протоколу IGMP, так і в цілому про multicast-трафіку можна почитати, наприклад, у циклі статей мережі для самих маленьких.

Так як всі повідомлення IGMP проходять через комутатор, він міг би їх аналізувати, щоб визначити, за якими портами знаходяться ті або інші одержувачі multicast-трафіку. І далі на підставі цієї інформації передавати трафік тільки туди, куди потрібно. Власне, саме цим і займається технологія IGMP snooping.

Реалізація IGMP snooping у різних виробників мережного обладнання в якихось нюансах може відрізняється. Але в цілому схема роботи схожа. Пропоную в загальних рисах розглянути її роботу на прикладі комутаторів Cisco. Далі ми подивимося на весь процес більш детально:

  1. Перше, що робить комутатор, визначає, де знаходиться маршрутизатор(и). Для цього він слухає наявність у мережі повідомлень IGMP General Query, PIM, DVMRP тощо

  2. Пристрій надсилає IGMP Report, коли хоче отримувати той чи інший multicast трафік. Дане повідомлення перехоплює комутатор. З такого повідомлення комутатор отримує наступну інформацію: пристрій з таким-то MAC-адресою, що знаходиться за певним портом, хоче отримувати трафік такий-то multicast групи. Причому для комутатора при ідентифікації multicast групи важливий не IP-адресу цієї групи (IP-адреси multicast груп лежать в діапазоні від 224.0.0.0 – 239.255.255.255), а її MAC-адресу. У нас все-таки комутатор і він працює на канальному рівні. Як ми знаємо, MAC-адресу формується за певним правилом з адреси IP multicast групи. Вся ця інформація заноситься до таблиці MAC-адрес комутатора.

    Далі комутатор відправляє в бік маршрутизатора IGMP Report, що містить таку ж інформацію, як була отримана від пристрою.

  3. Маршрутизатор, отримавши повідомлення IGMP Report, починає передавати multicast трафік. Але так як тепер комутатор знає, де знаходиться пристрій, який бажає її отримувати, він передає цей трафік тільки на певний порт. Адже тепер в таблиці MAC-адрес є запис з MAC-адресою multicast-групи, яка дивиться на конкретний порт.

  4. Періодично маршрутизатор відправляє в мережу IGMP General Query. Комутатор перехопивши його, розсилає повідомлення через всі порти, незважаючи на те, що він знає, де знаходяться одержувачі multicast-трафіку.

  5. Отримавши IGMP General Query, пристрій відповідає повідомленням IGMP Report. Комутатор перехоплює це повідомлення, відправляє його тільки в бік маршрутизатора. Інші одержувачі multicast-трафіку його не отримують. А, значить, відповідають своїми повідомленнями IGMP Report (таким чином механізм Report Suppression порушується). Комутатор, отримавши від усіх клієнтів такі повідомлення, оновлює записи MAC-адрес одержувачів у себе в таблиці. Тим самим підтримуючи запису в актуальному стані. Безумовно, у бік маршрутизатора всі ці повідомлення відсилати сенсу немає, тому комутатор далі з ними нічого не робить.

  6. Якщо пристрій вирішує припинити отримувати трафік для певної multicast-групи, він надсилає повідомлення IGMP Leave. Комутатор, як зазвичай, перехоплює його.

  7. По-перше, комутатор перевірять, чи немає за цим же портом (звідки прийшло повідомлення IGMP Leave) інших одержувачів multicast-трафіку. Адже в цей порт може бути підключений інший комутатор. Для цього він відправляє повідомлення IGMP Group-Specific Query. Якщо відповіді на нього не було, комутатор просто прибирає закріплення MAC-адреси multicast-групи за даними портом. Якщо відповідь прийшов, продовжує передавати трафік через цей порт.

  8. Далі комутатор перевіряє, чи є на ньому інші одержувачі multicast-трафіку для даної групи, але знаходяться за іншими портами. Для цього він просто дивиться в свою таблиці MAC-адрес.

    • Якщо такі одержувачі є, більше комутатор нічого не робить. Посилати повідомлення IGMP Leave в сторону маршрутизатора сенсу ніякого немає.


    • Якщо це був останній одержувач для даної multicast-групи, комутатор відправляє повідомлення IGMP Leave в сторону маршрутизатора.


  9. Отримавши повідомлення IGMP Leave, маршрутизатор розсилає повідомлення IGMP Group-Specific Query, які комутатор в свою чергу розсилає через свої порти. Звичайно ж, ніхто не відгукується і маршрутизатор перестає передавати трафік для даної групи.
Отже, в загальних рисах ми розібрали теоретичні основи. Спробуємо подивитися, як це виглядає на практиці. Наша топологія мережі буде виглядати наступним чином:



Джерело і одержувач потокового multicast-трафіку буде реалізований через VLC media player (далі програвач VLC).

IGMP snooping відключений, джерело multicast-трафіку знаходиться в іншій мережі

Почнемо з того, що розглянемо передачу multicast-трафіку без використання технології IGMP snooping. Для початку відключимо IGMP snooping. Як ми пам'ятаємо, на обладнанні Cisco він включений за умовчанням:

cbs-sw-2960x#conf t
cbs-sw-2960x(config)#no ip igmp snooping 
cbs-sw-2960x(config)#exit
cbs-sw-2960x#
cbs-sw-2960x#sh ip igmp snooping 
Global IGMP Snooping configuration:
-------------------------------------------
IGMP snooping : Disabled

На роутері включаємо маршрутизацію multicast-трафіку і запускаємо протокол маршрутизації multicast-трафіку PIM (Protocol Independent Multicast) в режимі dense-mode. Нам не принципове режим. Головне, щоб маршрутизатор запустив IGMP на потрібному нам інтерфейсі і забезпечив передачу через себе multicast-трафіку.

На джерелі включаємо VLC плеєр у режимі передачі потокового трафіку. Це і буде наш джерело multicast-трафіку. В якості адреси групи будемо використовувати 230.255.0.1. Передавати по мережі будемо тільки аудіо. В якості переданої композиції вибираємо Adele " Rolling in the Deep. Момент важливий, так як саме вона найкраще передається по мережі (факт перевірений).

Трішки тернистий шлях вже на самому початкуЗ проблемою маршрутизації multicast-трафіку я зіткнувся вже при налаштуванні першого комп'ютера, який повинен був стати джерелом. В якості піддослідних я взяв кілька ноутбуків, якими користуються інженери компанії.

Я встановив програвач VLC, налаштував передачу потокового аудіо і… нічого не побачив в дампі Wireshark на зовнішньому інтерфейсі комп'ютера.

Заглянувши в таблицю маршрутизації, я побачив два маршруту в мережу 224.0.0.0/4 з абсолютно однаковою метрикою 276. Причому першим в списку йшов маршрут через деякий інтерфейс з адресою 169.254.55.11. І лише другим йшов маршрут через нормальний інтерфейс даного комп'ютера (172.17.16.11).



У зв'язку з цим всі multicast-пакети загорталися на незрозумілий інтерфейс. Заглянувши в мережеві підключення, я виявив активоване інтерфейс Cisco Systems VPN Adapter. Даний інтерфейс з'являється в системі, коли на комп'ютер встановлюється Cisco VPN client. Це досить старе рішення для підключення VPN і, мабуть, його просто забули видалити.



Відключення даного інтерфейсу вирішило проблему.

Далі на клієнті включаємо програвач VLC в режимі одержання потокового аудіо для групи 230.255.0.1.

І знову проблеми...Коли я перейшов до налаштування одержувача потокового аудіо, у мене відразу не запрацювало. Тут я анітрохи не здивувався, а відразу поліз в таблицю маршрутизації. На цьому комп'ютері симптоми були ідентичні: multicast-пакети не з'являлися на провідному інтерфейсі.


І знову я виявив два маршруту в мережу 224.0.0.0/4 з абсолютно однаковою метрикою 306. Але тепер першим був стандартний маршрут loopback інтерфейсу. Зазвичай метрика маршруту для цього інтерфейсу більше, метрики через інші інтереси. З якоїсь причини в моєму випадку вони були рівні.

Як виявилося, хтось на цьому ноутбуці в ручному режимі виставив метрику проводового інтерфейсу.


Після того, як я встановив галочку «Автоматичне вивчення метрики», multicast-пакети стали нормально йти з даного комп'ютера.

У підсумку на обох комп'ютерах була проблема з маршрутизацією multicast-трафіку, але в кожному випадку джерело проблеми був свій.

Відразу бачимо, як пішов multicast трафік. У нашому випадку це пакети потокового мовлення, на транспортному рівні використовує протокол UDP.


Не забуваємо про TTLВарто зауважити, що за замовчуванням програвач VLC встановлює TTL для пакетів потокового мовлення рівним 1. Це означає, що такі пакети не можуть бути передані в іншу мережу, тобто маршрутизироваться. Тому для нашого випадку у налаштуваннях VLC значення TTL було виставлено більше одиниці.

За дампу видно, що одержувач запросив трафік (відправив повідомлення IGMP Report) і маршрутизатор відразу ж почав транслювати в мережу потрібний multicast трафік. Повідомлень IGMP Report цілих два. Мабуть, друге програвач VLC надсилає для вірності. Одного повідомлення цілком було б достатньо.

Перевіряємо таблицю маршрутизації multicast-трафіку на маршрутизаторі. У ній з'явилися записи, що свідчать про те, звідки і куди передається трафік:

cbs-rtr-4000#sh ip mroute 
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report, 
Z - Multicast Tunnel, z - MDT-data group sender, 
Y - Joined MDT-data group, y - Sending to MDT-data group, 
G - Received BGP C-Mroute, g - Sent BGP C-Mroute, 
N - Received BGP Shared-Tree Prune, n - BGP C-Mroute suppressed, 
Q - Received BGP S-A Route, q - Sent BGP S-A Route, 
V - RD & Vector, v - Vector, p - PIM Joins on route, 
x - VxLAN group
Outgoing interface flags: H - Hardware switched, A - Assert winner, p - PIM Join
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode

(*, 230.255.0.1), 00:29:20/stopped, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet0/0/1.115, Forward/Dense, 00:29:20/stopped

(172.17.16.11, 230.255.0.1), 00:03:27/00:02:32, flags: T
Incoming interface: GigabitEthernet0/0/1.116, RPF nbr 0.0.0.0
Outgoing interface list:
GigabitEthernet0/0/1.115, Forward/Dense, 00:03:27/stopped

Бачимо, що джерелом multicast-трафіку є хост 172.17.16.11. При цьому одержувачі знаходяться за інтерфейсом GigabitEthernet0/0/1.115. Маршрутизатор запам'ятовує тільки, куди слати трафік. Базу самих одержувачів він не веде.

Давайте подивимося на дамп трафіку на клієнті, відфільтроване за повідомленнями IGMP:


  1. Натискаємо кнопку «Відтворення» програвача VLC і наш комп'ютер запитує отримання multicast-трафіку для групи 230.255.0.1, відправивши повідомлення IGMP Report. Як ми вже відзначили, він відправляє два таких повідомлення.

    Отримавши це повідомлення, маршрутизатор починає трансляцію multicast-трафіку (потокового аудіо) в локальну мережу і на нашого клієнта ми починаємо чути передається по мережі музику.

  2. Періодично (кожні 60 секунд) маршрутизатор розсилає повідомлення IGMP General Query.

  3. Наш комп'ютер відгукується на дане повідомлення, відправляючи у зворотний бік IGMP Report для групи 230.255.0.1.

  4. Наживаємо кнопку «Зупинити» програвача VLC і наш комп'ютер відправляє повідомлення IGMP Leave, про те, що він більше не хоче отримувати multicast трафік для групи 230.255.0.1.

  5. Маршрутизатор у відповідь на IGMP Leave відправляє повідомлення IGMP Group-Specific Query 230.255.0.1. Він хоче зрозуміти, чи є в даному сегменті мережі, інші одержувачі. Рівно через 1 секунду маршрутизатор надсилає повторне повідомлення IGMP Group-Specific Query. І ще через 1 секунду, не отримавши у відповідь жодного IGMP Report, припиняє передавати multicast трафік в даний сегмент мережі.

  6. маршрутизатор Періодично продовжує розсилати повідомлення IGMP General Query. Але так як наш комп'ютер більше не зацікавлений в отриманні чого-небудь, він нічого на це не відповідає.
Так як на комутаторі у нас вимкнений IGMP snooping, весь multicast трафік розсилається (флудится) по всім портам у нашому VLAN'е, поки там є хоча б один одержувач. Коли одержувачів більше не буде, маршрутизатор тут же припинить передачу трафіку в даний сегмент мережі.


Дамп трафіку з комп'ютера в тому ж сегменті мережі, але не бере участь в отриманні потокового трафіку:


Точно також будуть обстоять справи з усіма IGMP повідомленнями. Вони будуть розсилатися на всі порти без винятку. Що є абсолютно логічним, так як у всіх цих повідомленнях в якості адреси отримувача використовується multicast-адресу.

IGMP snooping включений, джерело multicast-трафіку знаходиться в іншій мережі

Тепер перейдемо до розгляду ситуації, коли на комутаторі включений IGMP snooping. Запускаємо IGMP snooping на Cisco 2960x:

cbs-sw-2960x(config)#ip igmp snooping 
cbs-sw-2960x(config)#exit
cbs-sw-2960x#
cbs-sw-2960x#sh ip igmp snooping 
Global IGMP Snooping configuration:
-------------------------------------------
IGMP snooping : Enabled

Для початку перевіряємо, чи вдалося комутатора виявити маршрутизатор. Як ми пам'ятаємо, це перший пункт у списку завдань IGMP snooping:

cbs-sw-2960x#sh ip igmp snooping mrouter 
Vlan ports
---- -----
115 Gi1/0/19(dynamic)

Бачимо, що за портом Gi1/0/19 сховався наш маршрутизатор. Як ми раніше обговорювали, комутатор підглядає за наявністю в мережі пакетів, що свідчать про присутність маршрутизатора. У разі 2960x комутатор чекає пакети IGMP General Query, PIM або DVMRP.

Sep 17:39:39 MSK: IGMPSN: router: PIMV2 Hello packet received in 115
Sep 17:39:39 MSK: IGMPSN: router: Is not a router port on Vlan 115, port Gi1/0/19
Sep 17:39:39 MSK: IGMPSN: router: Is not a router port on Vlan 115, port Gi1/0/19
Sep 17:39:39 MSK: IGMPQR: vlan_id 115: querier/multicast router detected on port Gi1/0/19 Disabled in state
Sep 17:39:39 MSK: IGMPSN: router: Created router port on Vlan 115, port Gi1/0/19
Sep 17:39:39 MSK: IGMPSN: mgt: Reverting flood mode to only multicast router ports for Vlan 115.
Sep 17:39:39 MSK: IGMPSN: Adding port router Gi1/0/19 to all GCEs in Vlan 115
Sep 17:39:39 MSK: IGMPSN: added rport Gi1/0/19 on Vlan 115
Sep 17:39:39 MSK: IGMPSN: router: Learning port: Gi1/0/19 as rport on Vlan 115

Комутатор побачив повідомлення PIMV2 Hello від маршрутизатора на порту Gi1/0/19 і додав собі про це інформацію.

Знову запускаємо нашу трансляцію потокового аудіо і дивимося, що ми маємо на маршрутизаторі:

(*, 230.255.0.1), 00:00:12/stopped, RP 0.0.0.0, flags: DP
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list: Null

(172.17.16.11, 230.255.0.1), 00:00:12/00:02:47, flags: PT
Incoming interface: GigabitEthernet0/0/1.116, RPF nbr 0.0.0.0
Outgoing interface list: Null

З'явився джерело трафіку — 172.17.16.11. Одержувачів поки немає, про що свідчить рядок: Outgoing interface list: Null.

Запускаємо клієнт VLC, натискаємо кнопку «Відтворити» і насолоджуємося музикою. Паралельно дивимося Wireshark, де бачимо, як йдуть multicast-пакети потокового мовлення:


Тепер найцікавіше. Аналізуємо повідомлення IGMP на стику одержувач-комутатор і комутатор або маршрутизатор.

Пройдемо по основних кроків:

1. Після натискання кнопки «Відтворення» програвач VLC, наш комп'ютер запитує отримання multicast-трафіку для групи 230.255.0.1, відправивши повідомлення IGMP Report.


Прим. Пакети на одержувача

Комутатор, коли отримав повідомлення IGMP Report, заносить інформацію, про те, що за його портом (у нашому випадку – це порт GE0/0/15) є одержувач трафіку для групи з MAC-адресою 01:00:5e:7f:00:01.

Примітка. Знайти запис про даному MAC-адресі на комутаторі не вдасться. Він ніде не фігурує, в тому числі в стандартному виводі «show mac address-table».
2. IGMP Report потрапляє на маршрутизатор. Якщо ми заглянемо в саме повідомлення, то побачимо, що це оригінальне повідомлення від нашого ПК. Комутатор його просто переслав на порт, куди підключений маршрутизатор:


Прим. Пакети на маршрутизаторі. Підкреслений MAC адреса належить ПК

Якщо б на комутаторі вже був клієнт, який отримував трафік для групи 230.255.0.1, комутатор б просто почав трансляцію трафіку через наш порт (GE0/0/15) і більше нічого не робив би. Це логічно, так як у комутатора вже був би потрібний трафік, який слід було просто загорнути на ще один порт. Але в нашому прикладі, даний клієнт перший.

3. Маршрутизатор починає трансляцію потокового трафіку в локальну мережу.


Прим. Пакети на маршрутизаторі

4. Комутатор в свою чергу передає трафік на порт GE0/0/15, куди підключений наш ПК.


Прим. Пакети на одержувача

5. Комп'ютер відправляє повторний запит на отримання multicast-трафіку (специфіка реалізації підтримки IGMP на VLC плеєрі).


Прим. Пакети на одержувача

Так як воно не дуже вписується в нормальне поведінка, комутатор дане повідомлення скидає. У зв'язку з цим на маршрутизаторі ми його вже не бачимо.

6. Періодично маршрутизатор розсилає повідомлення IGMP General Query.

7. Комутатор транслює їх без змін на всі свої порти.


Прим. Пакети на одержувача. Підкреслений MAC адреса належить маршрутизатора

8. Комп'ютер відгукується на дане повідомлення, відправляючи у зворотний бік IGMP Report для групи 230.255.0.1.

9. Комутатор пересилає перше отримане повідомлення IGMP Report (а в даному прикладі повідомлення від нашого комп'ютера і є першим) у бік маршрутизатора.


Прим. Пакети на маршрутизаторі. Підкреслений MAC адреса належить одержувачу

Комутатор, отримавши перше повідомлення IGMP Report пересилає його тільки в бік маршрутизатора. Іншим одержувачам дане повідомлення не передається, на відміну від звичайної схеми роботи без IGMP snooping. Тобто механізм Report Suppression порушується. Таким чином кожен одержувач змушений буде відправити своє повідомлення IGMP Report у відповідь на IGMP General Query. Отримавши такі повідомлення, комутатор актуалізує свою базу відповідності одержувачів multicast-трафіку і внутрішніх портів.

10. Наживаємо кнопку «Зупинити» програвача VLC. Комп'ютер відправляє повідомлення IGMP Leave, про те, що він більше не хоче отримувати multicast трафік для групи 230.255.0.1.


Прим. Пакети на одержувача

11. На комп'ютер приходить повідомлення IGMP Group-Specific Query для групи 230.255.0.1. Якщо ми його розвернемо, ми побачимо, що дане повідомлення відправив комутатор:


Прим. Пакети на одержувача. Підкреслений MAC адреса належить комутатора. При цьому IP-адреса відправника комутатор використовував 172.17.15.1 (це адреса маршрутизатора)

Тобто комутатор, отримавши повідомлення IGMP Leave, виконує перевірку, чи немає інших пристроїв за даними портом, бажаючих отримувати multicast-трафіку для групи 230.255.0.1.

У бік маршрутизатора комутатор нічого не відправляє. Поки комутатор ніяк не турбує маршрутизатор, так як він ще не впевнений, що потрібно щось робити з multicast-трафіком.

12. Рівно через одну секунду комутатор надсилає повторне повідомлення IGMP Group-Specific Query.

13. І ще через одну секунду, не отримавши у відповідь жодного IGMP Report, припиняє передавати multicast трафік на даний порт.


Прим. Пакети на одержувача. Трансляція припинилася в 13:32:58:58

14. Після того, як комутатор зрозумів, що за портом, де було прийнято повідомлення IGMP Leave, більше немає одержувачів, він перевіряє, чи є у нього одержувачі за іншими портами. Для цього він дивиться у себе в таблиці MAC-адрес наявність записів для MAC-адреси 01:00:5e:7f:00:01 (як ми пам'ятаємо, це MAC-адресу групи 230.255.0.1). Якщо б до цього комутатора були підключені інші одержувачі, комутатор на цьому б зупинився і продовжив передавати multicast трафік. Але в нашому випадку, інших одержувачів немає. Тому він надсилає маршрутизатора повідомлення IGMP Leave.


Прим. Пакети на маршрутизаторі. Підкреслений MAC адреса належить комутатора

15. Отримавши повідомлення IGMP Leave, маршрутизатор, починає перевірку наявності інших одержувачів трафіку. Він же не знає, що комутатор вже сам все перевірив. Маршрутизатор відправляє повідомлення IGMP Group-Specific Query для групи 230.255.0.1.

16. Це повідомлення комутатор транслює на всі свої порти. В тому числі на порт, куди підключений наш комп'ютер. Як видно з дампа тепер дане повідомлення надіслано маршрутизатором:


Прим. Пакети на одержувача. Підкреслений MAC адреса належить маршрутизатора

17. Через одну секунду після відправки першого повідомлення маршрутизатор надсилає повторне повідомлення IGMP Group-Specific Query.

18. І ще через одну секунду, не отримавши у відповідь жодного IGMP Report (що очікувано, так як ми вже знаємо, що комутатора до цього ніхто не відгукнувся), маршрутизатор припиняє передавати потоковий трафік в даний сегмент локальної мережі.


Прим. Пакети на маршрутизаторі. Трансляція припинилася в 13:33:00:65

19. Маршрутизатор продовжує разів у хвилину розсилати повідомлення IGMP General Query.

20. Комутатор в свою чергу транслює його на усі свої порти.

Підсумковий дамп з пристроївЯ спеціально відфільтрував дампи таким чином, щоб було видно, в який момент починається трансляція трафіку, а в якій завершується. Більшу частину UDP пакетів я прибрав для більшої наочності.

Дамп на одержувача (одержувач-комутатор):



Дамп на маршрутизаторі (комутатор або маршрутизатор):




Резюмуючи, можна сказати наступне. Комутатор перехоплює всі повідомлення IGMP від клієнтів. Аналізує їх. І в залежності від ситуації пересилає повідомлення на маршрутизатор або ж видаляє. Так само комутатор сам бере участь у процесі створення IGMP повідомлень. Коли останній клієнт вирішує припинити отримувати multicast трафік, ми маємо дві перевірки наявності одержувачів. Першу виконує комутатор, а другу – маршрутизатор. У всій цій схемі маршрутизатор веде себе абсолютно також, як у випадку, коли у нас на комутаторі немає IGMP snooping. Тобто маршрутизатор ніяк не здогадується про наявність комутатора з включеною технологією IGMP snooping.

Давайте ще подивимося на дамп трафіку комп'ютера, який не бере участь в отриманні потокового трафіку, але знаходиться в тій же локальній мережі.


Прим. Підкреслений MAC адреса належить маршрутизатора

З дампа видно, що даний комп'ютер за весь час отримав тільки два види повідомлень і жодного multicast-пакету потокового мовлення:

  1. Повідомлення IGMP Group-Specific Query, яке відправив маршрутизатор, коли в мережі більше не залишилося ні одного одержувача multicast-трафіку.
  2. Повідомлення IGMP General Query, яке періодично розсилає маршрутизатор.
Таким чином, при включеному IGMP snooping, комутатор, по-перше, шле multicast трафік для певних груп тільки на ті порти, де є реальні одержувачі. Тобто оптимізує передачу даного типу трафіку.


По-друге, зменшує кількість IGMP повідомлень у бік маршрутизатора. Фактично маршрутизатор дізнається лише про присутність першого і про відключення останнього одержувачів multicast-трафіку. Підключення та відключення інших одержувачів повністю регулюється комутатором, що є логічним.

По-третє, істотно зменшує кількість IGMP повідомлень, які потрапляють на всі порти комутатора, не залучені в передачу multicast-трафіку. Як ми пам'ятаємо, у разі відсутності IGMP snooping всі пакети IGMP без винятку розсилаються на всі порти.

Залишилося подивитися, що ми побачимо на самому комутаторі:

cbs-sw-2960x#sh ip igmp snooping groups
Vlan Group Type Version Port List
-----------------------------------------------------------------------
115 230.255.0.1 igmp v2 Gi1/0/14, Gi1/0/15, 
Gi1/0/19

Ми бачимо, що одержувачі multicast-трафіку для групи 230.255.0.1 знаходяться за портами Gi1/0/14, Gi1/0/15 і Gi1/0/19. За портом Gi1/0/19 знаходиться сам маршрутизатор. Комутатор автоматично додав порт з маршрутизатором. Для отримання більш детальної інформації на комутаторі можна запустити отладчик debug ip igmp snooping.

IGMP snooping включений, джерело multicast-трафіку знаходиться в тій же мережі

І так, коли джерело знаходиться десь в іншому місці нашої мережі, все чудово працює. Але тепер давайте перенесемо наш джерело multicast-трафіку в той же сегмент мережі, де знаходяться одержувачі. Ситуація цілком собі життєва. Наприклад, ми маємо систему прийому телевізійних каналів з супутника і кілька STB-приставок. Або ж використовуємо програвач VLC або, наприклад, камери відео спостереження, що передають дані відразу декільком споживачам, що знаходяться в тому ж сегменті мережі. Ще один кейс – передача multicast-трафіку між контролером бездротової мережі і точками доступу. Як у цій ситуації відпрацює IGMP snooping?

Для чистоти експерименту на маршрутизаторі відключаємо PIM, так як тепер нам не потрібно більше маршрутизувати multicast трафік.

Розглядати варіант з відключеним IGMP snooping сенсу немає: весь трафік буде просто передаватися як широкомовний. Тому перевіряємо, що IGMP snooping включений, і запускаємо потокову трансляцію на нашому імпровізованому сервері. На клієнті поки програвач VLC не запускаємо (тобто клієнт ніяких IGMP повідомлень не надсилає).

Бачимо, що на наш комп'ютер, що виконує роль клієнта, став відразу ж сипатися multicast трафік:


Дивно, адже IGMP snooping включений. Подивимося, як зміниться ситуація, якщо на клієнті запустити програвач VLC і підключитися до групи 230.255.0.1 (саме її ми продовжуємо використовувати для трансляції нашого потокового аудіо). Натискаємо кнопку «Відтворення», бачимо, як наш комп'ютер відправив повідомлення IGMP Report, починаємо чути музику. Ясна річ, що multicast трафік на комп'ютер приходив весь час. Просто тепер клієнт VLC став його обробляти:


Повідомлення IGMPv3Я думаю, Ви вже помітили, що в дампі фігурують пакети IGMPv3. При цьому раніше ми скрізь бачили тільки IGMPv2. Обумовлено це тим, що на обладнанні Cisco за замовчуванням використовується IGMPv2. А в ОС Windows (7, 8, 10) використовується IGMPv3. У всіх попередніх випадках на маршрутизаторі був включений IGMP і клієнти, періодично отримуючи від маршрутизатора повідомлення IGMPv2 General Query, автоматично перейшли також на другу версію протоколу. У поточному сценарії на маршрутизаторі відключений IGMP, тому клієнт використовує третю версію протоколу.
Тепер треба переконатися, чи продовжує комутатор розсилати multicast трафік через всі інші порти. Або нарешті запрацював IGMP snooping і комутатор став слати трафік тільки туди, де є клієнти. Але немає. Нічого не змінилося. На іншому комп'ютері, який ніяк не бере участь в нашому експерименті, ми бачимо multicast трафік (сам дамп приводити не буду, multicast-пакети ми вже добре знаємо в обличчя). Варто відзначити, в дампі ми не знайдемо жодного повідомлення IGMP Report, які раніше відправив наш клієнт, і які, по ідеї, повинні були також надсилатися на всі порти. Значить IGMP snooping на комутаторі все-таки частково працює: як мінімум комутатор перехоплює IGMP повідомлення.


Саме час заглянути в консоль комутатора. Інформація про одержувачів для різних груп порожня:

cbs-sw-2960x#sh ip igmp snooping groups 
cbs-sw-2960x#

Запустивши налагодження (debug), бачимо:

Sep 13:54:01 MSK: IGMPSN: Received IGMPv3 Report for group v3 received on Vlan 115, port Gi1/0/15
Sep 13:54:01 MSK: IGMPSN: Rx IGMPv3 Report on Gi1/0/15 when Querier is not IGMPv3, Vlan 115.

З цих повідомлень єдино, що стає ясним, — комутатор отримав повідомлення IGMPv3 Report, при цьому версія нікого Querier не радить IGMPv3 (про Querier поговоримо трохи пізніше). А що ми отримаємо, якщо перемкнемо IGMPv3 на нашому комп'ютері на IGMPv2 (дана процедура робиться через реєстр). Раптом заведеться.

Перевіряємо. Поведінка комутатора залишилося таким же, але ось повідомлення в налагоджувач помінялися:

Sep 15:07:08 MSK: IGMPSN: Received IGMPv2 Report for group 230.255.0.1 received on Vlan 115, port Gi1/0/15
Sep 15:07:08 MSK: IGMPSN: group: Received IGMPv2 report for group 230.255.0.1 received on Vlan 115, port Gi1/0/15
Sep 15:07:08 MSK: IGMPSN: router: Is not a router port on Vlan 115, port Gi1/0/15
Sep 15:07:08 MSK: IGMPSN: group: Skip client info adding - ip 172.17.15.11, port_id Gi1/0/17, on vlan 115
Sep 15:07:08 MSK: IGMPSN: No mroute detected: Drop IGMPv2 report for group 230.255.0.1 received on Vlan 115, port Gi1/0/15

З цих повідомлень стає зрозуміло, що комутатор ігнорує інформацію в повідомленнях IGMP (і більше того видаляє), так як у нього немає «mroute». І тут ми починаємо згадувати, що першим пунктом програми IGMP snooping є визначення, де знаходиться маршрутизатор. І не важливо чи збираємося ми маршрутизувати multicast трафік чи ні. У попередньому розділі ми перевіряли висновок команди «show ip igmp snooping mrouter». Там був вказаний номер порту, куди був підключений наш маршрутизатор, рассылающий повідомлення IGMP General Query. Так от, комутатора з IGMP snooping обов'язково потрібно знати, де знаходиться маршрутизатор multicast-трафіку. Порт на комутаторі, куди буде підключений такий маршрутизатор, як раз і отримує назву mrouter-порт (multicast port router). Без mrouter-порту IGMP snooping нормально працювати не буде. А у нас такого порту немає, так як ми відключили на маршрутизаторі IGMP.

Включаємо назад IGMP на маршрутизаторі (для цього активуємо на інтерфейсі протокол PIM). Перевіряємо, що на комутаторі з'явився mrouter-порт:

cbs-sw-2960x#sh ip igmp snooping mrouter 
Vlan ports
---- -----
115 Gi1/0/19(dynamic)

І знову запускаємо наш джерело потокового аудіо. Поки програвач VLC не включаємо. Перевіряємо, розсилається чи трафік по всіх портів комутатора. Немає. Єдино, куди комутатор тепер транслює multicast трафік – це через mrouter-порт. Робиться він це завжди, так як маршрутизатор в нормальних умовах ніколи не відсилає повідомлень IGMP Report для груп, multicast трафік яких він буде маршрутизувати. А значить комутатор ніяк не зможе дізнатися, потрібен чи ні маршрутизатора той чи інший multicast трафік.

Зауваження. Коли ми розглядали схеми, де джерело multicast-трафіку знаходився в іншій мережі, multicast пакети потрапляли на маршрутизатор від джерела рівно з тієї ж причини, яку ми описували. Маршрутизатор не відправляв в мережу з джерелом multicast-трафіку повідомлення IGMP Report для групи 230.255.0.1.
Як тільки ми запускаємо програвач VLC, комутатор відразу починає передавати multicast трафік на даний комп'ютер. В цілому схема взаємодії між клієнтом-комутатором-маршрутизатором в рамках протоколу IGMP не відрізняється від того, що ми розглядали раніше, коли джерело знаходився в іншій мережі. Але є невеликий нюанс.

Поглянемо на дамп, отриманий з маршрутизатора (частина UDP-пакетів було відфільтровано для більшої наочності):


З дампа видно, наступне:

  • На маршрутизатор, як і очікувалося, постійно надходить multicast трафік.
  • Маршрутизатор продовжує відпрацьовувати логіку роботи IGMP для групи 230.255.0.1. На повідомлення IGMP Leave, він відсилає повідомлення IGMP Specific-Group Query.
  • Але на відміну від попереднього випадку, коли маршрутизатор з'ясовує, що більше немає одержувачів для групи 230.255.0.1, маршрутизатор не може припинити передавати multicast трафік. Його ініціатором в даному сегменті мережі є зовсім інше пристрій (це хост з адресою 172.17.15.12).


І так, ми зрозуміли, що для коректної роботи IGMP snooping на комутаторі Cisco нам потрібен маршрутизатор. Але можна отримати на комутаторі mrouter-порт без запуску протоколу IGMP на маршрутизаторі? Та й взагалі, чи можна обійтися зовсім без маршрутизатора? Так, для цього існує кілька способів. Перший варіант – статично прописати mrouter-порт. Дивитися, він може, куди завгодно. Головне, щоб був. Безумовно, це не самий елегантний спосіб. Другий варіант – запустити на комутаторі режим IGMP Querier. У цьому режимі комутатор вообразит себе multicast-маршрутизатором і почне розсилати і обробляти повідомлення IGMP. При цьому в якості mrouter-порту буде вказувати сам на себе:

cbs-sw-2960x#sh ip igmp snooping mrouter 
Vlan ports
---- -----
115 Switch

Наш комутатор буде відсилати в тому числі від свого імені повідомлення IGMP General Query. Це великий плюс. Інші комутатори в мережі, отримавши його, вирішать, що наш комутатор – це multicast-маршрутизатор, а значить у них з'являться свої mrouter-порти. Таким чином, IGMP snooping буде працювати коректно по всій мережі.

Зауваження. Комутатор весь multicast трафік завжди передає через mrouter-порт. Якщо такого трафіку буде багато, він легко може забити транкові порти між комутаторами, які опиняться в кінцевому підсумку mrouter-портами. Тому до дизайну мережі варто підходити акуратно, правильно вибираючи розташування пристроїв, які будуть виконувати роль IGMP Querier.
Підсумую. Для того щоб на комутаторах Cisco коректно працював IGMP snooping, необхідно, щоб на комутаторі був хоча б один mrouter-порт. Якщо на комутаторі немає жодного mrouter-порту:

  1. Комутатор з включеним IGMP snooping (а він, як ми пам'ятаємо, включений за умовчанням) передає multicast трафік, що генерується в даному сегменті мережі, як широкомовний. При цьому не важливо чи є, чи нема у нас хоча б один одержувач.

  2. Комутатор перехоплює і видаляє всі повідомлення IGMP Report.
    Якщо у нас є mrouter-порт і включений IGMP snooping, комутатор завжди шле multicast трафік від локально джерела через даний mroute-порт. При цьому не важливо чи є, чи нема у нас хоча б один отримувати.
IGMP snooping і 224.0.0.X

Коли я перший раз познайомився з IGMP snooping, перше про що я подумав, чи можна обмежити за допомогою даної технології multicast трафік, адресований групам з діапазону 224.0.0.0-255 (224.0.0.0/24).

Як ми пам'ятаємо, цей діапазон адрес використовується лише для локальних комунікацій всередині одного сегмента мережі (широкомовного домену). Багато IP-адреси з нього зарезервовані під різні службові протоколи. Наприклад, адреса 224.0.0.5 використовується протоколом OSPF, а адреса 224.0.0.10 – протоколу EIGRP. Але так як ці адреси використовуються суто для локально взаємодії ніякі механізми приєднання/від'єднання до цих груп не використовуються. Тобто для цих адрес не буде повідомлень IGMP Report. Тому всі вони повністю виключені з процесу IGMP snooping і комутатор Cisco буде розсилати трафік для даних груп на всі порти.

Бувають і виняткиБувають винятки у плані відсилання повідомлень IGMP Report. Наприклад, мій комп'ютер намагається приєднатися до груп 224.0.0.251 і 224.0.0.251. Це сервіси Multicast DNS і Link-Local Multicast Name Resolution, які в своїй роботі використовують механізм приєднання до групи.
Sep 17:27:36 MSK: IGMPSN: Received IGMPv2 Report for group 224.0.0.251 received on Vlan 115, port Gi1/0/15
Sep 17:27:36 MSK: IGMPSN: 224.0.0.251 is a Reserved MCAST address
Sep 17:27:36 MSK: IGMPSN: group: Received IGMPv2 report for group 224.0.0.251 received on Vlan 115, port Gi1/0/15 with invalid group address

Sep 17:27:37 MSK: IGMPSN: Received IGMPv2 Report for group 224.0.0.252 received on Vlan 115, port Gi1/0/15
Sep 17:27:37 MSK: IGMPSN: 224.0.0.252 is a Reserved MCAST address
Sep 17:27:37 MSK: IGMPSN: group: Received IGMPv2 report for group 224.0.0.252 received on Vlan 115, port Gi1/0/15 with invalid group address

Правда комутатор Cisco вважає таку поведінку не гідним для сервісів, які використовують адреси, що починаються з «224.0.0.». У зв'язку з чим ігнорує повідомлення IGMP Report.
висновок
Ми розібрали загальні аспекти роботи IGMP snooping на прикладі обладнання Cisco. Причому розглянута поведінка є поведінкою «за замовчуванням». За кадром залишилися питання, пов'язані з тюнінгом різних параметрів даної технології (наприклад, тайм-аутів між посилками повідомлень IGMP Group-Specific Query), зміною схеми роботи комутатора в разі отримання від клієнтів повідомлень IGMP Leave (наприклад, ми знаємо, що за портом точно немає інших пристроїв), взаємодією з протоколом STP (точніше, що робити, коли відбувається перебудова топології мережі) та ін. Зазвичай дані елементи є вже більш вендоро залежними і добре описані в документації.

Якщо ми подивимося на комутатори інших виробників, на багатьох з них ми також знайдемо технологію IGMP snooping. Звичайно ж, будуть відмінності в синтаксисі налаштування, якісь терміни (наприклад, замість mrouter-порту у багатьох використовується просто router-порт), різних доповнень і параметри, які можна підкрутити. Але здебільшого загальна схема роботи IGMP snooping буде схожою з тим, що ми розглянули.
Джерело: Хабрахабр

0 коментарів

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