Music On Hold - замечательная функция, позволяющая проигрывать абоненту музыку, в то время пока тот находится на ожидании или поставлен on hold.

MoH различают по настройке и методу передачи на два типа:

• Unicast MOH - Представляет собой однонаправленный поток point-to-point. Это означает, что для любого абонента поставленного on hold генерируется отдельный поток.
  По умолчанию CUCM поддерживает 250 одновременных потоков Unicast MOH.
  Понятно, что при большом количестве абонентов использование Unicast MOH может сказаться на производительности MOH Server а также сети.
• Multicast MOH - Это потоки MOH, которые отсылаются от MOH Server на multicast group address, при этом endpoints могут к нему подключаться при необходимости.
  Multicast MOH не загружает ресурсы, но его должна поддерживать сеть.
  По умолчанию Multicast MOH поддерживает 30 000 одновременных подключений к потоку MOH.

По умолчанию на CUCM включена только функция Unicast MOH; она же и самая простая в настройке.
Но при большом количестве абонентов, а также в крупном предприятии для экономии расхода трафика на участках сети WAN рекомендуется настройка Multicast MoH.
Как понятно из названия Multicast MoH базируется на методе передачи данных Multicast.

Multicasting

Для примера рассмотрим поток Music on Hold.
При использовании Unicast для его передачи каждому получателю отсылаются по копии каждого пакета. Т.е. от источника будет одновременно исходить столько же потоков RTP, сколько получателей на данный момент.
При использовании broadcast от источника будет исходить только один поток, но трафик broadcast получают все устройства сети, в том числе и те кому этот поток не нужен.
При использовании технологии Multicast сервер-источник отдаёт только один поток, а получают этот поток только те клиенты кому этот поток нужен.

Получатели подключаются к определенной multicast group (Class D IP address, т.е. находящийся в интервале 224.0.0.0 - 239.255.255.255). Сервер-источник шлет трафик на этот Class D IP address; свитчи а также routing protocols передают этот трафик только к подписавшимся машинам.

Internet Group Management Protocol

IGMP - это протокол, который используется между клиентами и маршрутизаторами. Его работа происходит следующим образом:

• Клиент отсылает IGMP Join message на multicast-enabled router.
• Маршрутизатор получает IGMP Join message на свой интерфейс. И теперь маршрутизатор знает, что на этот интерфейс следует отсылать трафик multicast на определённую multicast group

Существует три версии IGMP, но широко используются только две:

• IGMP Version 1 - Когда клиенту нужно присоединиться к группе multicast, клиент отсылает роутеру сообщение IGMP Re-
  port. Далее по умолчанию каждые 60сек маршрутизатор шлёт клиенту запросы IGMP Query message на адрес 224.0.0.1 (all IP multicast hosts), чтобы убедиться что клиенту всё еще нужно членство в этой multicast group. По истечении таймаута 3мин считается что клиент покинул группу и передача мультикастного трафика к нему прекращается.
• IGMP Version 2 - очень похожа на первую версию, добавлена возможность отсылать em>IGMP Query message на определённую группу, также добавлена поддержка Leave message.

Хосты и роутеры разных версий IGMP способны работать совместно.

Как уже упоминалось, multicast router периодически отсылает запросы IGMP Query message со стороны интерфейса, где находятся клиенты. Если окажется что в сети находятся два и более multicast router, только один из них выбирается как querier для данного сегмента.
IGMP designated querier - это маршрутизатор с наименьшим IP адресом.

Для определения какой маршрутизатор является querier:
show ip igmp interface [interface-id]

Отображение мультикастных групп, доступных через данный маршрутизатор:
show ip igmp group

Если Layer 2 switch получает на интерфейсе multicast frame, то по умолчанию он флудит копии этого кадра на все интерфейсы. Для предотвращения такого поведения необходимо настроить IGMP snooping.
IGMP snooping - фича, позволяющая коммутатору автоматически определять интерфейсы, подключенные к клиентам для определённых multicast groups. Это достигается тем, что коммутатор анализирует IGMP traffic между клиентами и маршрутизатором.

Глобально включаем IGMP snooping:
Switch(config)# ip igmp snooping

Включение IGMP snooping на определённых VLANs:
Switch(config)# ip igmp snooping vlan vlan_id

Multicast Addressing

В мультикастной сети сервер-источник отсылает пакеты на Class D IP Address.
Адреса класса D это IP адреса, которые начинаются с 1110 и находятся в интервале 224.0.0.0 - 239.255.255.255.

Class D IP Address в свою очередь делится на следующие подинтервалы:

Также в дополнение к адресу 3-го уровня, multicast applications также должны иметь адреса 2-го уровня (MAC Addresses).
Адрес 2-го уровня автоматом составляется исходя из адреса 3-го уровня:
- Multicast MAC address это адрес длиной 48-bit, и первая его половина (24бита) всегда будет (hex) 01-00-5e
- 25-ый бит всегда "0"
- Последние 23 бита для Multicast MAC address напрямую забираются из Multicast IP address

Для примера рассмотрим Multicast IP address 224.1.10.10:

1. В двоичном коде он будет выглядеть:
   11100000.00000001.00001010.00001010
   Здесь нас интересуют последние 24 бита, т.е.:
   00000001.00001010.00001010
2. Если самый левый бит не "0", его нужно сделать нулём. Поскольку 25-ый бит у Multicast MAC address всегда "0"
3. Переводим каждый октет в 16-ную систему:
   01-0a-0a
4. Слева приставляем первую половину 01-00-5e и получаем:
   01-00-5e-01-0a-0a

Distribution Trees

Маршрутизаторы, находящиеся в сети, должны определить для мультикаста forwarding path, т.е. путь для пакетов от источника до клиента. Структуру этого пути принято изображать в виде дерева, корнем которого является источник. Источнику абсолютно всё равно кто является клиентом, следовательно структуру дерева определяют маршрутзаторы, через которые идёт трафик.
На рисунке изображен пример пример возникновения проблемы duplicate packets, которая заключается в том, что роутеру необходимо решить какой из потоков следует форвардить далее, а какой нет.

В этом случае маршрутизатор применяет метод Reverse Path Forwarding (RPF) .
RPF - это процедура при которой у входящего пакета multicast берется source address, и затем по таблице маршрутизации проверяется egress interface для данного маршрута. Если входящий пакет использует этот интерфес, RPF check passes и данный пакет пропускается дальше, если нет, то RPF check fails.

Как уже было сказано, трафик multicast получают только члены данной мултикастной группы.
Но источник мультикастного трафика не обязан входит в эту группу.

Мультикастный трафик идёт от источника к назначению по пути, который называют distribution tree. Различают два типа distribution tree:

• Source Distribution Tree - создаёт оптимальный путь между каждым source router и last-hop router.
  Source Distribution Tree помечает состояния маршрутизаторов как S(source) и G(address of the group).
  При использовании Source Distribution Tree каждый источник имеет отдельный маршрут, что требует использования определённого объма памяти.
  
• Shared Distribution Tree - создаёт оптимальный путь начиная от центрального Rendezvous point (RP) router на все last-hop router. Путь Shared Distribution Tree может быть использован для нескольких источников, и требует меньшей памяти. Shared distribution tree помечает состояние маршрутизаторов (*, G) в multicast routing table.
  

PIM-DM Mechanics

Для создания IP multicast distribution trees маршрутизаторы cisco используют протокол Protocol Independent Multicast (PIM). PIM способен работать в любой IP сети, т.е. к примеру OSPF, EIGRP или статика, - отсюда и название : Independent.
Существуют два вида протокола PIM:

• PIM Dense Mode (PIM-DM) - использует source distribution tree. Изначально каждый PIM DM router или multilayer switch полагают, что все нижестоящие девайсы нуждаются в мультикастном трафике для данной группы. В результате мультикастный трафик изначально флудит (flood) по всем устройствам, независимо от того кому он нужен, а кому не нужен; и только потом обрубается (prune). Мультикастное дерево в режиме работы PIM Dense Mode (PIM-DM) растет начиная от источника т.е. от корня к листьям. Получившееся дерево называют source tree или source distribution tree, т.к. корень его есть источник мультикаста.
  Алгоритм работы:
  1. Источник трафика multicast начинает отдавать трафик в сеть
  2. Если в broadcast medium более одного роутера форвардят мультикастный трафик, только один из них выбирается как PIM forwarder. Выборы производятся через использование Assert messages, побеждает роутер с лучшей метрикой (по умолчанию это highest IP address)
  3. Некоторые маршрутизаторы могут не иметь за собой подписавшихся клиентов на данный мультикастный трафик. Такие роутеры отсылают вышестоящим соседям сообщения Prune message - в результате ведвь дерева в этом направлении "обрубается". При этом, если роутер ничего не отсылает, и мультикаст продолжает на него валиться.
  4. Если за роутером появляется клиент на данную группу, данный роутер может присоединиться к дереву, отсылая сообщение Graft message

  Таким образом, PIM Dense Mode (PIM-DM) рекомендуется использовать в сравнительно небольших сетях, где получатели мультикаста расположены относительно плотно. Если различные группы мультикаста разбросаны по большой сети, могут возникнуть проблемы с полосой пропускания из-за флуда.

• PIM Sparse Mode (PIM-SM) - использует shared distribution tree.
  В этом режиме работы мультикастное дерево растёт и расширяется только тогда, когда какой-нибудь клиент подключится к мультикастной группе.
  В режиме PIM Sparse Mode (PIM-SM) мультикастное дерево растет в обратном направлении: от листьев к корню. При этом корень дерева не обязательно будет источником трафика. Корнем дерева может быть некий маршрутизатор, находящийся в центре сети. Такой маршрутизатор называется Rendezvous Point (RP).
  Как только клиент присоединяется к мультикастной группе, last hop router отсылает на RP membership report. По этому пути каждый роутер добавляется к дереву подобно веткам. Поскольку к дереву подсоединяются только маршрутизаторы, за которыми есть клиент в группе, при данном алгоритме нет необходимости впоследствии обрубать ненужные маршруты.

  Подробный алгоритм работы:

  1. Получатель шлёт на свой маршрутизатор IGMP Report message, чтобы подсоединиться к определённой группе. Этот маршрутиатор (т.е. last hop router) высылает Join message на RP, таким образом по пути от RP до last hop router, у маршрутизаторов будет состояние (*, G)
  2. Источник включается и создаёт source tree между first-hop router и RP: вдоль этого пути будет состояние (S, G). Источник шлёт в сторону RP мультикастные сообщения Register messages, после этого tree is completely established.
  3. После того, как RP получает от источника Register message, для их остановки он отсылает обратно Register Stop message. В итоге образуется два дерева:
     - Source tree from the first-hop router to the RP.
     - Shared tree from the RP to the last-hop router.
     Но путь может оказаться не оптимальным.
  4. last-hop router определяет откуда идёт мультикастный трафик, и отсылает Join message напрямую к first-hop router, таким образом формируется оптимальный путь.
  5. Теперь last-hop router получает мультикастный трафик напрямую от first-hop router, и поэтому более не нуждается в мультикастном трафике от RP. last-hop router отсылает на RP (S, G) RP-bit Prune message, тем самым запрашивая RP остановить мультикастный трафик.
  6. Поскольку Shared tree от RP до last-hop router теперь находится в состоянии pruned , то теперь и RP более не нуждается в получении мультикаста от first-hop router. Поэтому RP отсылает (S, G) Prune message на first-hop router. Теперь трафик идет по оптимальному пути от first-hop router до last-hop router.
     Процесс перехода от пути_через_RP на прямой путь называется Shortest-Path Tree (SPT) Switchover.

Сравнивая PIM-DM и PIM-SM, можно сказать, что PIM-SM даёт тот же результат, что и PIM-DM, но без необходимости флудить и затем прунить (flood-and-prune behavior).

Глобально включаем multicast routing:
Router(config)# ip multicast-routing

Далее нам необходимо включить на отдельных интерфейсах поддержку PIM:
Router(config-if)# ip pim {dense-mode sparse-mode sparse-dense-mode}

Cisco рекомендует использовать sparse-dense-mode, поскольку данный алгоритм работает более эффективно.

Для проверки топологии дерева мы можем посмотреть multicast routing table:
show ip mroute
Здесь мы можем посмотреть (*, G) и (S, G).
А также incoming interface (IIF) и outgoing interface list (OIL).

Rendezvous Points

В сети PIM-SM один или более маршрутизатор должен быть выделенным rendezvous point (RP).
RP задаётся либо статически через команду ip pim rp-address ip-address, либо динамически.
Cisco поддерживает два метода автоопределения RP:

• Auto-RP - проприетарный цисковский метод
• Bootstrap Router (BSR) - Стандартизированный метод