Category Archives: Multicast

Неоднозначность преобразования multicast IP-группы в mac-адрес и L2 свитч

Не так давно меня попросили разобраться в проблеме появления лишнего трафика на порту свитча Cisco 4924, к которому подключен преобразователь из IP-мультикаст в DVB-C или аналоговый сигнал (проще говоря, некая железка для организации услуги кабельного телевидения, не знаю точно чем она занимается). Схема включения включения выглядит так:

L2-multicast-scheme

Устройства MR1, MR2, MR3 – преобразователи IP multicast в КТВ-сигнал, далее просто потребители мультикаста. На порту Gi1/1 свитча sw1 по графику утилизации было примерно 110Мбит/с, а инженер, ответственный за оборудование MR1 утверждал, что он запрашивает мультикаста всего на 70Мбит/с, тем самым возник вопрос откуда взялось ещё 40Мбит/с трафика. Порты свитча Te1/29, Gi1/1, Gi1/2 включены в vlan 10, в vlan 10 igmp-snooping включен, таблица igmp-snooping содержит записи, ничего подозрительно замечено не было. Continue reading

Advertisements

Маршрутизация multicast в Linux (IGMPv3 и IGMPv2)

В продолжение предыдущей заметки о статической маршрутизации multicast в Linux, это статья опишет возможности приложения mcproxy, которое управляет mroute-таблицей ядра Linux, исходя из IGMP-сигнализации. В отличии от всех остальных вариантов(igmpproxy с патчем и т.п.), mcproxy нормально работает с IGMPv3 (не падает). Использовалась версия из git (6638aa9), ОС Ubuntu Linux 14.04, ядро 3.13.0-32, iproute2 3.12.0-2

Если быть кратким, то смысл статьи в конфигурации из двух строчек (/etc/myproxy.conf):

protocol IGMPv3;
pinstance myProxy: ppp1 ==> eth0 tun0;

(В этом примере мультикаст принимается из ppp-тунеля и реплицируется (при наличии запросов снизу) в eth0 и тунельный интерфейс tun0)
И строки запуска:

# mcproxy -r -f /etc/mcproxy.conf

Continue reading

Использование Source Specific Multicast (SSM) (IGMPv3)

Введение (можно пропустить)

Отличие Source Specific Multicast от “обычного”(Any Source Multicast(ASM)) в его сигнализации и фильтрации. Формально, существует 3 модели распространения multicast – ASM, SFM(source filtered multicast) и SSM. Но в действительности, с точки зрения запроса мультикаст-трафика со стороны клиента, SSM можно рассматривать как частный случай SFM. Модель SSM подразумевает, что мультикаст группы принадлежат к диапазону адресов 232.0.0.0/8, а IGMPv3 exclude mode запросы не отправляются клиентом и игнорируются свитчами и роутерами, их обрабатывающими.

В классическом варианте, внутри сети оператора используется протокол PIM для распространения мультикаста между роутерами, при этом задействуются RP(точка(и) рандеву) для регистрации источников (S,G) и получения информации о них роутерами, у которых клиенты запросили мультикаст. Использование IGMPv3 в режиме include mode и отказ от exclude mode позволяет избавиться от этих RP, что упрощает конфигурацию сети и, вообще говоря, повышает надёжность(за счёт понижения сложности). Использование адресов 232.0.0.0/8 позволяет роутерам понять что от них хотят, когда вещают или запрашивают мультикаст от них. Получая такой мультикаст(data-трафик), роутер знает, что его не надо регистрировать на RP (сеть может быть смешанная и использовать 1, 2 или 3 модели распространения multicast), а получая IGMPv3 запрос от клиента(include mode) на запрос канала из сети 232.0.0.0/8, роутер не пытается его интерпретировать как ASM с фильтром(т.е. SFM), а сразу шлёт PIM JOIN для построения SPT, если канал (S,G) ранее не был подключен. В терминологии SSM канал определён как (S,G). В общем случае(в зависимости от оборудования) можно изменить диапазон адресов, относящийся к SSM.

IGMPv3 клиент и генератор multicast

Рассмотрим IGMPv3 в контексте CE-устройства, т.е. как запросить SSM по IGMPv3 и как его обработать. Continue reading

Маршрутизация multicast в Linux

В современных реалиях, скорее всего, нет смысла заниматься маршрутизацией(репликацией) multicast-трафика с помощью софтроутеров(будь то ядро Linux или что-то иное). Причина довольно простая – даже дешёвые свитчи умеют L2/L3-multicast(хоть и с ограничениями по количеству групп/маршрутов, но всё же это делается в asic-ах). Однако, существует ряд задач, которые могут быть не решены в “железе” (нет поддержки со стороны ПО/невозможно реализовать ввиду возможностей asic), например ренамберинг(изменение destination ip), внесение случайных задержек(перемешивание), отправка multicast в тунель, резервирование источника по произвольному критерию.

Зачем может потребоваться ренамберинг мультикаст группы? Во-первых, маппинг IP-mac неодназначен(например, группам 238.1.1.1 и 239.1.1.1 соответствует один и тот же mac-адрес), что может вызвать проблемы в L2-сегменте. Конечно, такая коллизия маловероятна, однако возможна, когда вы берёте multicast из разных внешних источников(в принципе, IP-адреса могут даже полностью совпасть). Во-вторых, вы можете захотеть скрыть свой источник, изменив и destination и source адрес. В destination может быть “спрятан” номер AS источника(RFC3180), по source тоже можно догадаться об источнике, если он не серый. В третьих, перенумеровать группу может потребоваться для избежания коллизии на оборудовании, где заканчивается TCAM под multicast (как временное решение до замены оборудования/изменения схемы сети). И наконец, вы решили зарезервировать ТВ-каналы путём их получения из разных источников(т.е. вливать на сервер 2 разных группы(но одинаковых по контенту) и забирать из него одну, результирующую(работающую))

Внести случайную задержку(reordering) или потери может потребоваться для проверки поведения используемых STB/soft-плееров. Например, вам интересно, как будет выглядеть картинка, если где-то на сети мультикаст пройдёт через per-packet балансировку и не зависнет ли плеер при наличии потери пакетов, будут ли издаваться неприятные скрипящие звуки или же просто квадратики и тишина. Continue reading