[arseniy]

Доброго дня!

имеется проблема такого рода:

Имеется группа свитчей SNR-S2995G-24FX, связанных между собой 10G портами, сквозь которые идет влан с мульткастом в другие свитчи, подключенные к SNR. Мультикаст разливается во все порты SNR, что недопустимо, т.к. трафика мульткаст очень много.

Есть ли на SNR аналог команд " filtering_unregistered_group", как это реализовано на D-Link, который запрещает трансляцию трафика в порты просто так, без подписчиков?

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

 

Изменено 31 марта, 2019 пользователем arseniy

[Aleksey Sonkin]

Добрый день!

Рекомендуем использовать IGMP Snooping.

[arseniy]

При использовании настроек:

ip igmp snooping
ip igmp snooping vlan 28
ip igmp snooping vlan 28 mrouter interface ethernet 1/0/23

no ip igmp snooping proxy

перестает нормально отрабатывать переключение каналов на клиентских свитчах.

влан 28 - тот самый, где идет мультикаст.

в 23й порт включен свитч-querier

[Aleksey Sonkin]

@arseniy

33 минуты назад, arseniy сказал:

перестает нормально отрабатывать переключение каналов на клиентских свитчах.

Уточните, пожалуйста, проблему.

[arseniy]

При переключении каналов на STB подписка на переключаемый канал не появляется, на приставке нет картинки, но не все каналы, а хаотично.

[semop]

Так а наверное тоже ограничение на кол-во мультикаст групп, которое надо конфигурить.

 

У нас так работает:

 

ip igmp snooping
no ip igmp snooping proxy
ip igmp snooping vlan 100
ip igmp snooping vlan 100 limit group 1024
ip igmp snooping vlan 100 l2-general-querier-source 10.253.0.1
ip igmp snooping vlan 100 mrouter-port interface Port-Channel1

 

Без строчки limit group - дефолтно изучается 50 групп. Это видно по sh ip igmp snooping vlan

Правда у нас свич 2990 

 

Подсказали здесь на форуме.

 

 

 

[arseniy]

Поставил ограничения в 1024. Будем наблюдать. 

[arseniy]

Наблюдения таковы:

при настройках на свитчах SNR:

!
ip igmp snooping
no ip igmp snooping proxy
ip igmp snooping vlan 28
ip igmp snooping vlan 28 limit group 1024
ip igmp snooping vlan 28 mrouter-port interface Ethernet1/0/23(подключен querier) и 

ip igmp snooping vlan 28 mrouter-port interface Ethernet1/0/28(на остальных)
!
есть ошибки в ТВ-потоках, по 9-20 ошибок за 5 минут. Схема такая:

des-3120(querier)>SNR>SNR>SNR>железка, на которой уже есть ошибки.

но, хотя бы, мультикаст не разливается во все порты SNRов

в схеме

des-3120(querier)>SNR>des-3120(агрегация)>железка, ошибок нет

аплинки на SNR заняты на 10%

[semop]

Можно попробовать покрасить мультикаст на магистральных портах, если на физике каких нибудь СРС нет.

[arseniy]

Ошибок нет, смотрели на них в первую очередь. А как подкрасить мультикаст, не подскажете? поверхностный гугл внятного ничего не дал.

[semop]

 

Самый первый запрос в гугле кстати)))

[arseniy]

т.е. начинать красить надо еще на свитче с querier? но зачем? сквозь первый SNR, к которому подключен querier и свитчи агрегации все ок...

[semop]

преимущественно траффик красится от начала и до конца.

Иначе это все равно что построить дорогу 100км ровную как стол, а дальше 500км гравийки. Или наоборот.

[vurd]

В 01.04.2019 в 12:07, arseniy сказал:

При переключении каналов на STB подписка на переключаемый канал не появляется, на приставке нет картинки, но не все каналы, а хаотично.

Абсолютно такая же проблема. Заменил два свитча 3120 на 2995 - все выходные мудохался со снупингом и рассыпаниями.

 

1. Снупинг работает как в анекдоте "или встречу или нет". В режиме прокси, без режима прокси наплевать - результат один.

 

 

 

2. Буферов не хватает от слова совсем, пока qos не включил - лагало адово на трафике меньше гига. Выше график за начало дня в выходной, видно что сыпет ошибками, и эта ситуация уже после trust dscp. После этого я уже перевел в режим strict и вроде стало нормально. Вот график в ЧНН от вчера.

 

 

3. Если объединять в кольцо vlan с мультикастом, то stp начинает перестраиваться постоянно. Видимо фильтруется bpdu, точнее не фильтруется, а криво снупится. Без снупинга сводить кольца не пробовал, надеюсь ок. Со снупингом валит в кольцевой порт, хотя там некому просить группы.

 

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

И к тому же у меня висит примерно такое же обращение по S300, там тоже какие-то косяки и тоже работаю без снупинга уже год - продвижений никаких нет. В общем, я ОЧЕНЬ разочарован, заменил ради L3 и 4 портов 10г беспроблемно годами работающие 3120 и хапнул кучу проблем по телику. Лучше было бы поставить 3420 в RI редакции. К сожалению dcn и multicast это слова из двух разных предложений, в одном они звучать не должны.

 

[arseniy]

У меня ко всему прочему поток просто пропадает, выглядит это так:

Apr 02 12:08:28: INFO: Bitrate: 1189 Kbit/s
Apr 02 12:08:29: INFO: Bitrate: 198 Kbit/s
Apr 02 12:08:30: INFO: Bitrate: 0 Kbit/s
Apr 02 12:08:31: INFO: Bitrate: 0 Kbit/s
Apr 02 12:08:32: INFO: Bitrate: 0 Kbit/s
Apr 02 12:08:33: INFO: Bitrate: 1704 Kbit/s
Apr 02 12:08:33: ERROR: CC: PID:0=1 PID:116=1 PID:216=1 PID:316=1
Apr 02 12:08:34: INFO: Bitrate: 1377 Kbit/s
Apr 02 12:08:35: INFO: Bitrate: 1377 Kbit/s
это пройдет после настройки QOS?

кстати, qos для мультка делается так:

ip multicast policy {source_ip/mask} {group_ip/mask} cos {0-7}, верно?

Уважаемый vurd, покажите ваш вариант конфига с настройкой "strict"

Изменено 2 апреля, 2019 пользователем arseniy

[vurd]

31 минуту назад, arseniy сказал:

У меня ко всему прочему поток просто пропадает, выглядит это так:

Apr 02 12:08:28: INFO: Bitrate: 1189 Kbit/s
Apr 02 12:08:29: INFO: Bitrate: 198 Kbit/s
Apr 02 12:08:30: INFO: Bitrate: 0 Kbit/s
Apr 02 12:08:31: INFO: Bitrate: 0 Kbit/s
Apr 02 12:08:32: INFO: Bitrate: 0 Kbit/s
Apr 02 12:08:33: INFO: Bitrate: 1704 Kbit/s
Apr 02 12:08:33: ERROR: CC: PID:0=1 PID:116=1 PID:216=1 PID:316=1
Apr 02 12:08:34: INFO: Bitrate: 1377 Kbit/s
Apr 02 12:08:35: INFO: Bitrate: 1377 Kbit/s
это пройдет после настройки QOS?

кстати, qos для мультка делается так:

ip multicast policy {source_ip/mask} {group_ip/mask} cos {0-7}, верно?

Уважаемый vurd, покажите ваш вариант конфига с настройкой "strict"

 

 

Ну собственно выглядит оно так и как на моем графике выше. Т.е. теряет подписку, пытается подписаться, не может, пытается, может. Почему? ХЗ. На рандомных каналах. Ну всё точно так как вы и сказали в первом посте. Кол-во групп тут не влияет, я первым делом ставил 1024, может оно фейлится еще и на "ip igmp snooping vlan <vid> limit source"? Если вы всё еще пытаетесь снупить, то попробуйте поднять это тоже.

 

Еще гляньте

show cpu-rx protocol IGMP
show cpu-rx protocol MULTICAST

Там не должно быть дропов, если есть - поднимайте.

 

По-поводу strict.

Я мечу свои потоки в dscp cs4, после включаю доверие на магистралях. В случае рассматриваемого свитча делаем так:

Interface Ethernet1/0/1
 description Client
 mls qos queue algorithm sp
!

Interface Ethernet1/0/25
 description Uplink
 mls qos trust dscp
 mls qos queue algorithm sp
!

 

В любом случае "покраску" необходимо делать сразу после источника. У меня это происходит прямо на портах стримеров, далее только доверие. Проверяется просто, вы должны видеть на тестовом клиенте в снифере значение в поле dscp ip-пакета. Это комплексный вопрос, он должен решать проблему переполнения буферов свитчей на всех уровнях иерархии. Т.е. если вам в SNR уже влетает битый поток, из-за того, что он не был приоритезирован, то покраска на SNR не поможет.

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

 

 

[semop]

Может софт?

 

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

И группы были и все было. Но как потом выяснилось, что было ограничение в 50шт. Посчитал и действительно на SNR было всего 50 групп. Естественно, если одна отпишется, то я смогу смотреть какой то новый канал. Так и было. Эту дичь я тоже не ожидал)

Групп у нас чуть более 200. Поставил 1024 и все заработало.

 

Без покраски у нас сыпало и на длинках 3120. Трафик около 2Гбит на магистралях.

Покрасил года два назад еще и просто забыл. Да даже если бы там было 100Мбит все равно бы покрасил. Этот мультикаст от каждого чоха разваливается.

Зимой переехал на SNR'ы, и тоже все покрасил сразу.

[vurd]

50 минут назад, semop сказал:

Групп у нас чуть более 200. Поставил 1024 и все заработало.

Это я уже знал по опыту с S300, сразу так и было сделано. У меня есть ощущение, что проблема возникает у меня на стыке между Eltex и DCN. Т.к. за 2995 у меня стоят LTE-8X и ловил я проблемы именно на клиентах с них. Но у меня их тупо больше чем на обычных свитчах доступа. Не могу быть уверенным в этом, но проблема точно есть, появилась после замены свитча. И проблема со сходимостью в кольце тоже, а она уже никак с элтексами не увязывается.

[arseniy]

1 hour ago, semop said:

Может софт?

Исключено, т.к. до установки SNR были линки между 3120, и все было хорошо, как только загнали мульткаст сквозь SNR - начались проблемы...

[semop]

Ох как много бы я поофтопил по этому Элтэксу)

 

По SNR сказал как есть. Но мы не на агрегации их покупали, а на ядро.

Атомные 16 портовые 10Г коммутаторы. С буффером 16МБ, чтоб блин наверняка.

Колец нет, только звезды с ЛАСП. 

 

19 минут назад, arseniy сказал:

Исключено

Ну я 2 раза на наших софт менял...

И с ДГСами так же было. Стоят два одинаковых, подключенные по порту в третий. Один работает, второй плохо работает. До кучи еще и конфиги унифицированые чуть ли не копипаст на обоих. Барахтаешься в этом бубне, а потом выясняется что прошивки разные. Совершенно не сложно взять 3120 с непофиксеной ошибкой или багом и увидеть разницу с тем, который там стоял до этого, например.

2995 аппаратно сильнее 3120. Что то не то.

В любом случае QOS это больше благо чем ненужная фигня. Когда нибудь все равно бы пришлось его настраивать.

 

До переключения на схему с SNR у меня тоже были проблемки. Были и DGS и хуавэй. Но все заработало в итоге. Трафик покрашен, прошивки свежие, командная строка человеческая в конце концов.

 

Вот тут переезжал на SNR.

 

Тут и про 50 групп и про поведение квериера. 

 

А еще где-то есть тема, где я узнал что включить dcsp trust на работающем port-channel нельзя. Его надо разобрать, применить команду, собрать обратно.

 

Вопщем это единственное с чем я столкнулся по мультикасту.

[semop]

Среди этого трафика бегает крашеное IGMP без дропов.

 

[Aleksey Sonkin]

@arseniy , если после данных Вам рекомендаций проблема сохраняется, пожалуйста, создайте обращение на support@nag.ru с приложенными 'sh run', 'sh ver' а также схемой и описанием проблемы.

[vurd]

38 минут назад, Aleksey Sonkin сказал:

@arseniy , если после данных Вам рекомендаций проблема сохраняется, пожалуйста, создайте обращение на support@nag.ru с приложенными 'sh run', 'sh ver' а также схемой и описанием проблемы.

Алексей.

А вот скажите. Есть две настройки

ip igmp snooping vlan <VID> limit source <N>

ip igmp snooping vlan <VID> limit groups <N>

 

Что имеется в виду под src? Случайно не SrcMac из таблицы снупинга? И какое значение для этих src по умолчанию? Случайно не 50?

 

[Victor Tkachenko]

@vurd, да, limit source - это ограничение количества точек входа для группы, значение по умолчанию - 40.

 

Добавлю, что на случай рассыпаний стоит включить сбор статистики QoS - `mls qos queue statistics enable`.

Если в выводе `show mls qos queue statistics interface e1/0/X` в соответствующей мультикасту очереди будут потери, то наверняка переполняется буфер и необходимо переключить хотя бы верхние очереди (включая очередь с мультикастом) в режим strict.

 

4 часа назад, vurd сказал:

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

И к тому же у меня висит примерно такое же обращение по S300, там тоже какие-то косяки и тоже работаю без снупинга уже год - продвижений никаких нет.

Действительно, нами были нарушены разумные сроки устранения, так как проблема крайне специфична и воспроизводится не в 100% случаев. Получить адекватных комментариев от производителя чипсета не удалось.

По возможности опишите, пожалуйста, проблему в support.nag.ru, думаю её вполне удастся воспроизвести в лабораторных условиях и решить.

[vurd]

3 минуты назад, Victor Tkachenko сказал:

@vurd, да, limit source - это ограничение количества точек входа для группы, значение по умолчанию - 40.

  

Добавлю, что на случай рассыпаний стоит включить сбор статистики QoS - `mls qos queue statistics enable`.

Если в выводе `show mls qos queue statistics interface e1/0/X` в соответствующей мультикасту очереди будут потери, то наверняка переполняется буфер и необходимо переключить хотя бы верхние очереди (включая очередь с мультикастом) в режим strict.

 

Действительно, нами были нарушены разумные сроки устранения, так как проблема крайне специфична и воспроизводится не в 100% случаев. Получить адекватных комментариев от производителя чипсета не удалось.

По возможности опишите, пожалуйста, проблему в support.nag.ru, думаю её вполне удастся воспроизвести в лабораторных условиях и решить.

Чем чревата установка этих показателей в groups 65535 source 65535. У меня есть предположение, что оно отрезает мне каналы из-за src. В лабе добиться этого не могу. Мои графики были выше, настройки в это время

ip igmp snooping
no ip igmp snooping proxy
ip igmp snooping vlan 1251
ip igmp snooping vlan 1251 limit group 1024

Есть ли вероятность, что не хватало настройки source и могла ли она влиять вообще? (к вопросу https://forum.nag.ru/index.php?/topic/148364-snr-s2995g-24fx-multicast/&amp;do=findComment&amp;comment=1540876 пункт 1)