[Илья В.]

Коллеги, добрый день.
Столкнулись со следующей проблемой.
На сети стоит cisco c4900m в качестве ядра сети. Выше по топологии стоят ASR`ы в качестве BRAS`ов, ниже по сети стоят абоненты ( за коммутаторами уровня агрегации и за коммутаторами уровня доступа).
Проблема касается рассыпания ТВ в вечерний ЧНН независимо от типа ТВ мультикаст/юникаст.
Анализ ошибок/логов/дампов привел к тому, что на Cisco поступает слишком много мультикаст трафика с разных участков сети, на интерфейсах Cisco возникаете очередь, буферы "забиваются" и появляются дропы.
С коллегими проводим работы по настройке фильтрации мультикаста на абонентских vlan`ах, что в принципе должно решить проблему.
На портах трафик не в "потолок".
Собственно ,вопрос : куда "копать", если фильтрация мультикаста не решит проблему и очереди на интерфесах останутся? ( фильтры ставим на коммутаторах агрегации на абонентский vlan)
Хотелось бы услышать мнение/совет основанное на опыте решения подобных проблем.

[alibek]

Схему подробную нарисуйте.

 

Правильный мультикаст требует правильной архитектуры и QoS.

Какая у вас архитектура — непонятно.

Но судя по оговоркам про BRAS, "поступаем много мультикаста с разных участков", "буферы забиваются", "фильтрация мультикаста на абонентских vlan" — у вас многое неправильно.

 

В 31.10.2022 в 13:08, Илья В. сказал:

если фильтрация мультикаста не решит проблему и очереди на интерфесах останутся

Фильтрация мультикаста не для этого. А для того, чтобы в сети не было чужого или несанкционированного мультикаста.

[Илья В.]

В 31.10.2022 в 20:50, alibek сказал:

Схему подробную нарисуйте.

 

Правильный мультикаст требует правильной архитектуры и QoS.

Какая у вас архитектура — непонятно.

Но судя по оговоркам про BRAS, "поступаем много мультикаста с разных участков", "буферы забиваются", "фильтрация мультикаста на абонентских vlan" — у вас многое неправильно.

 

Фильтрация мультикаста не для этого. А для того, чтобы в сети не было чужого или несанкционированного мультикаста.

Здравствуйте!

"Правильный мультикаст требует правильной архитектуры и QoS." 
В этом вопросе у нас промах.
QOS не настроен, весь трафик идет в восьмую ( как я понимаю дефолтную) очередь.

"у вас многое неправильно" 
Буду рад наставлению на правильный путь построения архитектуры сети и необходимые изменения.
Схему сети прикрепил.
Абонент находятся за локальными ядрами, это коммутаторы на которых собирается трафик одного географического района.
Делаю пояснения т.к. бывает что у разных операторов разная терминология.

 

[alibek]

Сервер IPTV — это стример? На схеме я его не нашел.

 

Судя по рисунку, у вас мультикаст не сегментирован и не маршрутизируется (то есть в сети один общий мультикастовый VLAN).

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

Так же, как можно ближе к ядру, нужно разместить igmp querier.

Нужно настроить igmp snooping на уровне агрегации и доступа - разрешать query со стороны ядра, разрешать report со стороны абонентов, запрещать остальное. Так же нужно настроить тайминги igmp, прежде всего query-interval, тут зависит от оборудования. Я настраивал 60 секунд на уровне доступа и 50 секунд на уровне агрегации.

Если оборудование позволяет, так же можно настроить ACL, чтобы фильтровать посторонний мультикаст (например 239.255.255.250, 224.0.0.0/8).

Обязательно нужно проверять, как распределяется мультикаст и как работает igmp snooping (регистрация подписок и т.п.) на разных участках и уровнях сети.

QoS и маркировка трафика делается уже после того, как мультикаст в целом начнет работать правильно (то есть "литься" будет только в те порты, где есть активные подписчики). Реализация тоже во многом зависит от оборудования и вендора. Мы на уровне ядра ставили метки, на уровне доступа настраивали очереди.

[Илья В.]

В 01.11.2022 в 17:17, alibek сказал:

Сервер IPTV — это стример? На схеме я его не нашел.

 

Судя по рисунку, у вас мультикаст не сегментирован и не маршрутизируется (то есть в сети один общий мультикастовый VLAN).

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

Так же, как можно ближе к ядру, нужно разместить igmp querier.

Нужно настроить igmp snooping на уровне агрегации и доступа - разрешать query со стороны ядра, разрешать report со стороны абонентов, запрещать остальное. Так же нужно настроить тайминги igmp, прежде всего query-interval, тут зависит от оборудования. Я настраивал 60 секунд на уровне доступа и 50 секунд на уровне агрегации.

Если оборудование позволяет, так же можно настроить ACL, чтобы фильтровать посторонний мультикаст (например 239.255.255.250, 224.0.0.0/8).

Обязательно нужно проверять, как распределяется мультикаст и как работает igmp snooping (регистрация подписок и т.п.) на разных участках и уровнях сети.

QoS и маркировка трафика делается уже после того, как мультикаст в целом начнет работать правильно (то есть "литься" будет только в те порты, где есть активные подписчики). Реализация тоже во многом зависит от оборудования и вендора. Мы на уровне ядра ставили метки, на уровне доступа настраивали очереди.

"Сервер IPTV — это стример?" 
Да, получает мультикаст отдает юникаст и мультикаст.

По расположению с коллегами обсудили возможное изменение расположения еще до создания темы, это хорошая идея, я согласен с вами.

"то есть в сети один общий мультикастовый VLAN" 
да, верно, для мультикаста выделен отдельный vlan, на коммутаторах доступа настроен MVR, на коммутаторах агрегации настроен IGMP

Тайминги стоят дефолтные, querier не настроен или настроен по дефолту, изучу этот момент, спасибо.

ACL для мультикаста и бродкаста настроили только на уровне агрегации, но только несколько правил, для блокировки SSDP мультикаста, например.
Дайте, пожалуйста, рекомендации какие мультикаст адреса, кроме указанных выше, можно заблокировать без вреда для абонента?
На d-link`ах (уровень агрегации) есть настройка по фильтрации мультикаста в абонентских vlan`ах, оставили только мультикаст vlan для ТВ, для этого же vlan`а включен igmp snooping.
Правильно я понимаю что для оставильных vlan`ов igmp_snooping должен быть отключен?
Есть нюанс, у нас через сеть проброшено множество каналов связи партнеров, в которых ходит абонентская локалка, пока нет понимания что абоненту оставить, что заблокировать .

Про QOS и маркировку понял, спасибо, займемся после работ по мультикасту.

Подскажите еще по необходимости настройки fast leave при подписках на мультикаст группы?
 

[stnx]

fast leave обязательно включить на абонентских портах, на агрегации не нужно и даже вредно

Edited November 1, 2022 by stnx

[alibek]

В 01.11.2022 в 12:42, Илья В. сказал:

Дайте, пожалуйста, рекомендации какие мультикаст адреса, кроме указанных выше, можно заблокировать без вреда для абонента?

Все, кроме некоторых сервисных адресов в 224.0.0.0/24 (но при включенном igmp snooping они до ACL обычно не доходят) и тех групп, которые вы используете.

 

В 01.11.2022 в 12:42, Илья В. сказал:

Правильно я понимаю что для оставильных vlan`ов igmp_snooping должен быть отключен?

Лучше проконсультироваться в ТП вендора.

Где-то igmp snooping нужно включать в мультикастовом VLAN, где-то в мультикастовом и абонентском, где-то нужно включать везде.

Мы D-Link почти не использовали, но на DES-3200 делали примерно так:

create  vlan IPTV tag 60
...
enable igmp_snooping
enable igmp_snooping multicast_vlan
create igmp_snooping multicast_vlan IPTV 60
config igmp_snooping multicast_vlan IPTV state enable
config igmp_snooping multicast_vlan IPTV add member_port 1-24
config igmp_snooping multicast_vlan IPTV add source_port 25-26
config igmp_snooping multicast_vlan_group IPTV add  239.0.0.0-239.0.255.255
config igmp_snooping multicast_vlan_group IPTV add  239.195.0.0-239.195.255.255
config igmp_snooping vlan_name IPTV fast_leave enable
config multicast port_filtering_mode all   filter_unregistered_groups
config multicast port_filtering_mode 25-26 forward_unregistered_groups
create mcast_filter_profile profile_id 10 profile_name iptv_access
config mcast_filter_profile profile_id 10 add 239.0.0.0-239.0.255.255
config mcast_filter_profile profile_id 10 add 239.195.0.0-239.195.255.255
create mcast_filter_profile profile_id 11 profile_name iptv_trunk
config mcast_filter_profile profile_id 11 add 239.0.0.0-239.0.255.255
config mcast_filter_profile profile_id 11 add 239.195.0.0-239.195.255.255
config max_mcast_group ports 1-24  max_group 1024
config max_mcast_group ports 25-26 max_group 1024

Впрочем это очень старый конфиг и не обязательно хороший.

 

В 01.11.2022 в 12:42, Илья В. сказал:

Есть нюанс, у нас через сеть проброшено множество каналов связи партнеров, в которых ходит абонентская локалка, пока нет понимания что абоненту оставить, что заблокировать .

Это может быть проблемой.

Транзитный трафик с тэгами или без тэгов?

В транзитном трафике есть multicast или broadcast (например DHCP)?

 

В 01.11.2022 в 12:42, Илья В. сказал:

Подскажите еще по необходимости настройки fast leave при подписках на мультикаст группы?

Зависит от оборудования.

Но обычно на портах доступа лучше включать; не включать только если реализация глючит.

На магистральных портах и агрегации включать не нужно.

[Илья В.]

@alibek 
 

В 01.11.2022 в 22:41, alibek сказал:

Все, кроме некоторых сервисных адресов в 224.0.0.0/24 (но при включенном igmp snooping они до ACL обычно не доходят) и тех групп, которые вы используете.

Обсужу с коллегами, потестируем, спасибо.

 

 

В 01.11.2022 в 22:41, alibek сказал:

Это может быть проблемой.

Транзитный трафик с тэгами или без тэгов?

В транзитном трафике есть multicast или broadcast (например DHCP)?

стык с партнерами настроен в транк и перечислены разрешенные вланы ( вывод настроек порта ниже), дальше по сети аналогично прокинуты разрешенные vlan`ы, в зависимости от прохождения канала связи.
Да, в транзитном трафике есть и broadcast и multicast, снимали дампы, фиксировали протоколы типа MDNS , LLMNR, SSDP в большом количестве с назначением multicast.
 

interface GigabitEthernet3/6

description

switchport trunk allowed vlan 2,36,37,131,141,217,262,425,760,1200,1201,1627

switchport trunk allowed vlan add 1628,3003,3004,3009-3014,3018-3022,3026,3029

switchport trunk allowed vlan add 3032,3036-3040,3049-3053,4002

switchport mode trunk mtu 9000

storm-control broadcast include multicast storm-control broadcast level 10.00

no cdp enable

 

@stnx спасибо, так и сделаем

[alibek]

В 02.11.2022 в 08:44, Илья В. сказал:

Да, в транзитном трафике есть и broadcast и multicast, снимали дампы, фиксировали протоколы типа MDNS , LLMNR, SSDP в большом количестве с назначением multicast.

Было бы хорошо весь этот транзит туннелировать во что-нибудь юникастовое (MPLS, например).

Часто настройки фильтрации и изоляции привязываются даже не к VLAN, а к портам. И соответственно, для работы транзита придется отключать часть функций, которые бы в нормальном случае способствовали улучшению контроля сети.

[Илья В.]

@alibek 

В 02.11.2022 в 17:47, alibek сказал:

Было бы хорошо весь этот транзит туннелировать во что-нибудь юникастовое (MPLS, например).

нюанс по транзиту:
он приходит из одного интерфейса,  а уходит в разные интерфейсы вместе с абонентскими и сервисными vlan`ами.
Но идею понял, спасибо.

Подскажите еще по работе мультикаста на сети:
я сейчас заметил что на уровне доступа настроен и MVR и igmp snooping, но я не уверен что snooping должен быть включен вместе с MVR.
у меня сейчас в голове картина по работе мультикаста следующая, поправьте меня, если я ошибаюсь:
уровень доступа - настроен MVR 
|
уровень агрегации - настроен igmp snooping только для IPTV vlan
|
уровень локального ядра - настроен igmp snooping только для IPTV vlan
|
уровень ядра - настроен igmp snooping только для IPTV vlan и querier
|
стример
 

[alibek]

На доступе MVR, в остальной сети igmp snooping (в мультикастовом VLAN).

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

 

В 02.11.2022 в 12:23, Илья В. сказал:

я сейчас заметил что на уровне доступа настроен и MVR и igmp snooping, но я не уверен что snooping должен быть включен вместе с MVR.

От оборудования зависит. Где-то нужно использовать или одно, или другое. А где-то mvr подразумевает, что так же нужен  включенный igmp snooping.

[Negator]

Хотел что то добавить, а добавить и нечего. Все уже написано.

Сами ушли от мультикаста тоже пару лет назад, несколько десятков абонентов еще работают по старой памяти.

 

Добавлю ко всему вышенаписанному то, что нужно решить все проблемы (возможные потери, узкие места, буферы на коммутаторах  и все прочее) на сети доступа и агрегации.

Т.к. любая самая мелкая проблема вылезет в рассыпание картинки.

Я бы еще посмотрел в сторону QOS для мультикаста и MVR влана если позволяет оборудование.

[Илья В.]

@alibek 

В 03.11.2022 в 02:07, alibek сказал:

мы ушли с мультикаста года два назад.

Подскажите почему решили отказаться от мультикаста?

@Negator 

 

В 03.11.2022 в 02:46, Negator сказал:

нужно решить все проблемы (возможные потери, узкие места, буферы на коммутаторах  и все прочее) на сети доступа и агрегации

Да, понимание этого есть. Больше вопросов было к корректной настройке  работы мультикаста.

 

В 03.11.2022 в 02:46, Negator сказал:

Я бы еще посмотрел в сторону QOS для мультикаста и MVR влана если позволяет оборудование.

Про QOS с инженерами обсуждали необходимость, задача масштабная,не дошли руки пока.

Про MVR - настройка есть, сейчас проверим коррекность работы и присутствие лишних настроек.

 

В 03.11.2022 в 02:46, Negator сказал:

Сами ушли от мультикаста тоже пару лет назад

Аналогичный вопрос, расскажите почему ушли от мультикаста?
 

[alibek]

В 03.11.2022 в 03:25, Илья В. сказал:

Подскажите почему решили отказаться от мультикаста?

Мультикаст хорош только для прямого вещания.

Сейчас люди все больше уходят в просмотр архивов (с перемоткой рекламы) и VoD.

Ну и требования к сети для мультикаста гораздо выше. Хотя с другой стороны это было системой раннего оповещения о проблемах в сети - началось сыпаться, значит нужно искать, где возникла проблема.

[YuryD]

В 03.11.2022 в 17:24, alibek сказал:

Мультикаст хорош только для прямого вещания.

Сейчас люди все больше уходят в просмотр архивов (с перемоткой рекламы) и VoD.

Ну и требования к сети для мультикаста гораздо выше. Хотя с другой стороны это было системой раннего оповещения о проблемах в сети - началось сыпаться, значит нужно искать, где возникла проблема.

+100. Мулитикаст хорош и дешев в единичном сегменте, типа видеонаблюдения в доме. Все остальное оставим монстрам с архивами и VoD.

[Negator]

И добавить нечего. Все так и есть.

 

[Ivan_83]

Мультикаст отличное решение пока вы его гоняете где то у себя в небольшом технологическом сегменте где вы на 100% всё контролируете и администрируете.

Я бы шёл в сторону решения где у вас мультикаст ходит где то по отдельному влану куда смотрят стримеры с msd, а абоненты уже забирают с msd.

Вместо мсд можно и другой софт.

 

В целом же формат броадкастингового контента умирает в виду того что VoD (ютуп тот же, онлайн кинотеатры и пр) намного удобнее.

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