Как тестировать multicast?

Question

[Валентин]

Вопрос знатокам-сетевикам. Какие существуют методики тестирования мультикаста(IPTV)? Приведу более конкретные вопросы:


1)Как работает mtrace, что можно взять из его вывода?

2)Как работает ping 239.0.0.2. То есть я пингую мультикастовую группу. Я что, пропингую всех, кто подписан на эту группу? И что я от них должен получить.

3)Существуют ли какие-нибудь инструменты для оценки качества multicast'а? Чисто визуально при просмотре iptv через цепочку маршрутизаторов время от времени прерывается звук. Можно ли как-то оценить, где затык?


Для наглядности приведу картинку. Было бы здорово, если кто-то помог разобраться с поставленными вопросами на примере ниже.




Может быть поможете разобраться с такими вопросами, как проверить конкретный канал(например 226.0.0.5) на работоспособность, выявить узкие места, из-за которых мультикаст может некорректно работать. Все оборудование на схеме Cisco и Huawei, L3 коммутаторы. Для маршрутизации используется PIM, OSPF.


P.S. Если коллективно поможете разобраться, оформлю в отдельный пост.


Заранее спасибо.

Answer 1

[JDima]

Как работает mtrace, что можно взять из его вывода?

learningnetwork.cisco.com/thread/26882

Как работает ping 239.0.0.2

Посылается банальный icmp echo на группу. Получатели, если возможно, отзываются reply, где source IP равен интерфейсному адресу. Отправитель echo при получении такого reply отображает вам адреса отправивших reply.
Говоря о цисках: если вы настроили на int vlan «ip igmp join-group 239.0.0.2», то если PIM настроен верно — циска ответит на пинг на эту группу из другого конца сети. И скорее всего, если не закосячен IGMP, любой хост в этом VLANе сможет слушать группу. Это — отличная предварительная проверка. Если она провалилась, то у вас точно проблема.
За других вендоров не отвечаю.

как проверить конкретный канал(например 226.0.0.5) на работоспособность

Пинг — принципиальная проверка работоспособности. А дальше, чтобы понять, как построен SPT, пройдитесь по железкам и посмотрите, что там с show ip mroute.

И да, если вы тестируете IPTV, то финальным этапом тестирования должен быть тот самый VLC или реальное приложение. С проверкой состояний IGMP и PIM в процессе трансляций.

И ни в коем случае не вводите мультикаст в продакшн, не получив полное понимание того, какие есть варианты работы PIM, IGMP, как их дебажить и траблшутить.

Comments

[JDima]

Чисто визуально при просмотре iptv через цепочку маршрутизаторов время от времени прерывается звук. Можно ли как-то оценить, где затык?

Перегрузка интерфейсов? QoS есть? Без него категорически нельзя такие вещи делать.

[JDima]

А вообще — www.cisco.com/en/US/docs/ios-xml/ios/ipsla/configuration/15-s/sla_mcast_suppt.html, или простой udp jitter между железками, одна из которых соседствует с отправителем, а другая поблизости к получателю с проблемным звуком.

[Валентин]

Пинг — принципиальная проверка работоспособности. А дальше, чтобы понять, как построен SPT, пройдитесь по железкам и посмотрите, что там с show ip mroute.

Вот непонятно. Я подключен к одному из роутеров, смотрю кино по одному из каналов. С какого бы роутера я не посылал ping на мультикаст-адрес, везде получаю в ответ ничего.

[Валентин]

Вернее, доступно, если только проключено ip igmp join-group. Но зачем его включать? Если и так igmp должно отрабатывать?

[JDima]

Ну значит другие подписанные на эту группу не приучены отзываться на пинги к группе. Вполне возможно.
Включите int vlan'ы на трех указанных в схеме роутерах (если там получатели) в новую группу, и пингуйте.
Только проблема. Таким образом вы подтвердите, что все работает. Как бы если звук хоть иногда доходит, то это и ежу понятно. Причину проблем узнать не удастся. Потому — qos, а заодно дебаги по igmp. Может, проблемные клиенты по каким-то причинам временно отключаются от группы.

[JDima]

Вернее, доступно, если только проключено ip igmp join-group. Но зачем его включать?

Это значит дословно «int vlan начинает слушать группу». Иначе он не будет ее слушать и не будет на нее отзываться. Цель сугубо диагностическая, не надо делать такое для боевых групп. Если он отозвался на пинг к группе, то PIM работает как надо.

[Валентин]

Вы меня опередили с ответом. Спасибо, сейчас смотрю в сторону SLA. Правильно ли я понимаю, что mtrace тоже работает исключительно с теми железками, на которых на интерфейсах прописаны join-группы?

И да, qos у нас не прописаны, так как аплинки заняты максимум на 20%. Надо ли включать, есть ли какие-нибудь особенности у SVI-интерфейсов Cisco? Потому что если без PIM, просто вланом к себе затащить, то задержек нет.

[JDima]

что mtrace тоже работает исключительно с теми железками, на которых на интерфейсах прописаны join-группы?

По идее, последний должен быть включен в группу, а промежуточные — нет. Хотя полной уверенности нет.

аплинки заняты максимум на 20%. Надо ли включать

Да. Вы смотрите усредненные значения за N секунд. А в пределах секунды при наличии взрывного TCP утилизация будет ненадолго подскакивать до 100%.

если без PIM, просто вланом к себе затащить, то задержек нет.

Но по тому же самому транспорту? Это уже забавнее. Включите дебаги PIM на пути и смотрите, не происходит ли там чего нехорошего с деревьями или самими соседствами PIM. Если он периодически пересобирается, то это плохо.

[Валентин]

А чтоб SLA запускать, никаких разрешений писать не надо?

Я делаю на C4900(будет отсылать):

sw1> enable
sw1# conf t
sw1(config)#
sw1(config)# ip sla 10
sw1(config-ip-sla)# udp-echo 172.16.1.10 1000

На C3560(приемнике)

sw2> enable
sw2# conf t
sw2(config)# ip sla responder 172.16.1.10 1000

Цепляется только если настраиваю тестирование ICMP.

[JDima]

Попробуйте «sw2(config)# ip sla responder» без дополнительных аргументов.

Answer 2

[Валентин]

Похоже у меня потери на сети. При более тщательном тестировании выявил участо с потерями 0.015% на UDP, 20MB. Походу влияет на качество.

Comments

[tgz]

iperf умеет multicast. Тестируйте на здоровье как только вздумается.

Answer 3

[f0x_m]

www.bridgetech.tv/product_VB20.php

Железка дорогая конечно, но очень удобная.