qelso Опубликовано 27 ноября, 2017 · Жалоба Доброго времени суток, всем! Стал замечать что у клиентов ветке в часы пик возрастает количество ошибок, картинка рассыпается. В полку по трафику не упираюсь. Предположил что не верно настроил igmp snooping, поделитесь, пожалуйста, лучшей практикой для igmp snooping на SNR-S2990G-24FX SNR-S2990G-24FX используется в качестве агрегации. Мультикаст влан 4040 1/0/28 - uplink, 1/0/22 - downlink в ветку В качестве igmp querier - ядро. Мой конфиг: cpu-rx-ratelimit protocol IGMP 2000 cpu-rx-ratelimit protocol PIM 2000 ! ip igmp snooping no ip igmp snooping proxy ip igmp snooping vlan 4040 ip igmp snooping vlan 4040 limit group 512 ip igmp snooping vlan 4040 mrouter-port interface Ethernet1/0/28 ! vlan 4040 name iptv ! Interface Ethernet1/0/22 description branch spanning-tree mst 0 rootguard spanning-tree portfast bpdufilter rate-violation broadcast 74404 rate-violation control shutdown recovery 0 switchport mode trunk switchport trunk allowed vlan 526;3509;3517;4040 ! Interface Ethernet1/0/28 description uplink spanning-tree portfast bpdufilter switchport mode trunk Дополнительный вопрос: есть ли у snr аналог цискового igmp snooping report message suppression? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Victor Tkachenko Опубликовано 28 ноября, 2017 · Жалоба qelso, доброго! Конфигурация igmp snooping у вас типичная, что-то менять смысла нет. Более того, проблемы в igmp snooping наверняка не вызвали бы рассыпания, так как он контролирует только подписки и таблицу продвижения мультикаста, но не сами потоки. Даже если по графикам трафик далек от полки, не исключено, что имеется кратковременная переутилизация канала, так как трафик может быть очень неравномерен даже в пределах одной секунды. Имеет смысл снять дамп с конечного устройства в момент рассыпаний картинки и проанализировать его, например с помощью I/O Graph в Wireshark. 15 часов назад, qelso сказал: Дополнительный вопрос: есть ли у snr аналог цискового igmp snooping report message suppression? Да ip igmp snooping vlan <vlan_id> report suppression Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ShumBor Опубликовано 28 ноября, 2017 · Жалоба У меня предположение, судя по куску конфига, что не включено доверие заголовкам DSCP. Но это предположение, т.к. не знаю как вы qos на тв пакеты формируете у себя. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
qelso Опубликовано 28 ноября, 2017 · Жалоба Ребят, спасибо за советы! Утилизация в сторону тестируемой ветки ~50Мб\с, в на аплинке ~150Мб\с. Учитывая порты не меньше 1G, то настройки QoS (CoS,DSCP) тут не причем. На агрегации QoS дефолтный. На ядре тоже. Думаю может что-то криво настроено на ядре (Juniper MX80), юзаем несколько месяцев поэтому опыта работы с ним мало. На других ядрах (Cisco 7600) вроде норм. Спрошу в другой ветке форума у джуноводов по поводу igmp+pim. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pppoetest Опубликовано 29 ноября, 2017 · Жалоба Достаточно покрасить у источника, и сохранять метки до потребителя. 17 часов назад, qelso сказал: Учитывая порты не меньше 1G, то настройки QoS (CoS,DSCP) тут не причем. Не согласен, покраска влияет на мультикаст, даже на ненагруженном канале. По крайней мере у нас сыпалось именно из-за не сохранения меток DSCP. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Victor Tkachenko Опубликовано 29 ноября, 2017 · Жалоба Все дело в том, что недогрузка линка по графикам еще не говорит об отсутствии переутилизации линка/буфера вообще. Трафик, приходя на коммутатор через 10G порт, будет передаваться в 1G с той же скоростью, с которой пришел. То есть за короткий промежуток времени (например, 125мкс) через 10G порт в буфер может залететь до 10 раз больше, чем от туда выдергивается 1G портом за то же время, а череда таких событий в совокупности со всем остальным трафиком на коммутаторе переполнит буфер, в результате чего часть трафика будет отброшена. Аналогичная картина на доступе при передаче из 1G в 100M. Увидеть это на графиках в cacti или zabbix не удастся, нужно анализировать дампы. Отмечу, что это не просто теория, а жестокая реальность, с которой я лично сталкивался, получив жалобу на рассыпающуюся картинку от абонента. Приоритезация в таких случаях обязательна, но и она на 100% не спасет. Для IPTV наверняка поможет выравнивание потоков, конечно, если это еще не cbr. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
qelso Опубликовано 30 ноября, 2017 (изменено) · Жалоба ShumBor, pppoetest, Victor Tkachenko, спасибо за советы! На данный момент поднял 1G линк (отдельным волокном) между snr и другим ядром. И забираю по нему только мультикаст. На mx80 убрал 4040 и igmp. Ошибки упали в разы, клиенты довольны. Схема временная. На 7600 ядрах QoS настроен, на Juniper нет, не дошли руки. В другой ветке форума Джуноводы также посоветовали настроить QoS. Изменено 30 ноября, 2017 пользователем qelso Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
semop Опубликовано 30 января, 2019 · Жалоба Добрый день. Не могу понять в чем проблема. Переключал IGMP транспорт с хуавэя - на SNR. Настройки простые. Просто снупинг. 2 коммутатора собранные с VSF. ТВ ходит во влане 100. 10.44.6.248 - IP адрес управления SNR Мне необходимо прокинуть IGMP влан 100 с 1/0/14 на Port-Channel10 ! vlan 100 name ISM ! Interface Ethernet1/0/14 description TAG to SOURCEs mls qos trust dscp switchport mode hybrid switchport hybrid allowed vlan ............. tag switchport hybrid allowed vlan 100 untag switchport hybrid native vlan 100 ! Interface Ethernet1/0/11 switchport mode trunk switchport trunk allowed vlan 100 port-group 10 mode active lacp port-priority 10 ! Interface Ethernet2/0/11 switchport mode trunk switchport trunk allowed vlan 100 port-group 10 mode active lacp port-priority 10 ! Interface Port-Channel10 load-balance dst-src-mac ! ip igmp snooping no ip igmp snooping proxy ip igmp snooping vlan 100 ip igmp snooping vlan 100 mrouter-port interface Ethernet1/0/14 ip igmp snooping vlan 100 report source-address 10.44.6.248 Переключал на живом. Подписки появились. Работают. Но поведение странное: могу не подписаться с рабочего места ни к одной новой группе (которой нет на SNR) потом вдруг могу, и группа появляется в подписках. Переключаю на следующую - не работает. Дождусь таймаута и опять не могу ни к кому новому подписаться. Настало рабочее время, разбираться некогда и я просто выключил снупинг. Все заработало. Просто насквозь. SNR-S2990-16X Device, Compiled on Oct 11 10:19:13 2018 CPU Mac f8:f0:82:77:fc:92 Vlan MAC f8:f0:82:77:fc:91 SoftWare Package Version 7.5.3.0(R0016.0056) BootRom Version 7.4.6 HardWare Version 1.0.1 Где клад зарыт, друзья? === Причем подписки "долетают" до коммутатора с источниками. А на самом SNR их нет. На существующие/подписанные кем-то группы подписаться могу и вижу ТВ. Не могу понять как оно заработало на 50%. Переключение было физическое. Если бы что то было неправильно - наверно вообще ничего не заработало бы. А группы были, просто не все. Может я в ограничение какое то вляпался? Груп менее 300. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Aleksey Sonkin Опубликовано 30 января, 2019 · Жалоба @semop Добрый день! Какое количество групп было в момент проблемы? По умолчанию присутствует ограничение в 50 групп, если групп больше, нужно добавить команду: ip igmp snooping vlan <> limit group <> Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
semop Опубликовано 30 января, 2019 · Жалоба 15 минут назад, Aleksey Sonkin сказал: Добрый день! Какое количество групп было в момент проблемы? По умолчанию присутствует ограничение в 50 групп, если групп больше, нужно добавить команду: ip igmp snooping vlan <> limit group <> )))) именно 50 и было, посмотрел по логам за все время работ, выше 50 не поднималось. Спасибо, наверно это именно, то что нужно. Проверю на следующих работах. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
semop Опубликовано 28 февраля, 2019 · Жалоба Действительно сработало ограничение 50 групп. Поправил. Появилась другая непонятная проблема. Старая схема работы IGMP: Источники живут за SNR_1, Querier тоже за SNR_1. Приемники/приставки - за HWI и за DLINK. На DLINK - создан мультикаст-влан. По трассе - просто снупинг. Все прекрасно. Делаю так: Меняю на SNR_2 mrouter-port в сторону SNR_1 Убираю на старых линках влан IGMP. Переключаю на DLINKe влан в сторону SNR_2 Мультикаст заводится и показывает. Но после этого переключения наблюдаю картину, при которой любая отписка в облаке DLINK - отписывает все что на нем живет. Т.е. с двух разных портов DLINK подключены приставки. Например они смотрят одну и ту же группу и если на любой из них отключить ее/отписаться/переключить - то отпишется и первая. Конфиг DLINK для igmp не меняется. Конфиги SNRов идентичны, mrouter-port только разные: ! vlan 100 ! ip igmp snooping ip igmp snooping vlan 100 ip igmp snooping vlan 100 limit group 1024 ip igmp snooping vlan 100 mrouter-port interface Ethernet1/0/14 ! Влан проключен для каждой схемы в соответствующие порты транком, никаких петель. Фильтры пока что все убрал. Конкретика: 1 схема - если отписаться, то счетчик на коммутаторе доступа для группы обновится до default значения. Порт на DLNIK будет подписан. ТВ не прерывается. 2 схема - если отписаться, то счетчик на коммутаторе доступа для группы станет 0, группа пропадет. Но порт на DLINK останется быть подписаным. ТВ прерывается (причем у всех людей кто был к этой группе подписан) Я по началу думал fastleave где то отрабатывает не так, но это вроде не он. Схему 1 я просто увеличиваю до схемы 2 одним коммутатором, где влан ИПТВ просто проключен со снупингом, как собственно он проключен и на HWI. Схема 1 работает, схема 2 - нет. Нужна помощь. (подозреваю если отключить снупинг на SNR_2 то все будет работать, но мне так не надо) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Aleksey Sonkin Опубликовано 1 марта, 2019 · Жалоба @semop По-умолчанию на коммутаторе включен IGMP Snooping proxy. Функционал проксирует leave-запросы, по умолчанию source ip у specific query 0.0.0.0. Сталкивались с ситуацией, когда клиенты не отвечали на запросы с данным source ip. Поэтому попробуйте либо изменить source ip: ip igmp snooping vlan 100 l2-general-querier-source a.b.c.d где в качестве IP-адреса можете указать адрес коммутатора. Либо отключить проксирование: no ip igmp snooping proxy Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
semop Опубликовано 1 марта, 2019 · Жалоба 2 часа назад, Aleksey Sonkin сказал: ip igmp snooping vlan 100 l2-general-querier-source a.b.c.d На HWI есть такая команда, он тоже с 0.0.0.0 отвечал. Применил когда то давно такое у него на влане и все успокоилось: vlan 100 description ISM vlan igmp-snooping enable igmp-snooping general-query source-ip 10.253.0.1 igmp-snooping special-query source-ip 10.253.0.1 Но IP тут - Querier'а, а не коммутатора. Спасибо. Попробую аналогично на SNR. На обоих это наверно надо указывать. 2 часа назад, Aleksey Sonkin сказал: no ip igmp snooping proxy с этой командой примененной на SNR_1 (схема 1) - при включении канала, ТВ играет 2сек и картинка встает. В стоке "ip igmp snooping proxy", с ней все хорошо работает. Пробовал ее применять/отменять на SNR_2 (схема 2) - результата не дало. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
semop Опубликовано 1 марта, 2019 · Жалоба На обоих применил: ip igmp snooping vlan 100 l2-general-querier-source 10.253.0.1 Указав IP Querier'a. На SNR_2 отключил прокси (no ip igmp snooping proxy) Переехал на схему 2. Все вроде работает. Ура) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Aleksey Sonkin Опубликовано 1 марта, 2019 · Жалоба @semop Отлично! Замечу, что IP-адрес значения не имеет, а если отключен прокси то и данная команда тоже избыточна. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
semop Опубликовано 1 марта, 2019 · Жалоба Прокси отключен только на втором. Если на первом его отключить, то все ТВ стопорится. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Aleksey Sonkin Опубликовано 1 марта, 2019 · Жалоба @semop Имел ввиду, что в таком случае на втором коммутаторе избыточна. По поводу отключения на первом можно, конечно, разобраться, вероятно выше имеет место быть подобная проблема, но рекомендую использовать прокси. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
semop Опубликовано 18 февраля, 2020 · Жалоба В 01.03.2019 в 10:38, Aleksey Sonkin сказал: но рекомендую использовать прокси. Здравствуйте. Это принципиальная особенность? В схеме когда SNR = querier. Просто без прокси создается впечатление что SNR как то криво отвечает на REPORT. Вот смотрите: схема SNR(querier=proxy) - SNR Включил группу на ноутбуке и ПК. SNR_CORE#sh ip igm sn vlan 100 gr 239.195.7.3 IGMP Snooping Connect Group Membership Note:*-All Source, (S)- Include Source, -Exclude Source Groups Sources Ports Exptime SrcMac System Level 239.195.7.3 * Ethernet1/0/14 00:05:05 00:15:17:27:08:34 V2 Ethernet1/0/14 00:05:05 00:21:91:7B:A7:0D V2 Port-Channel1 00:06:20 50:E5:49:29:DB:AC V2 Port-Channel1 00:06:20 00:0F:3D:CE:49:80 V2 Port-Channel10 00:05:08 00:1A:79:16:F1:0A V2 Отключил группу (на 49:80) SNR_CORE#sh ip igm sn vlan 100 gr 239.195.7.3 IGMP Snooping Connect Group Membership Note:*-All Source, (S)- Include Source, -Exclude Source Groups Sources Ports Exptime SrcMac System Level 239.195.7.3 * Ethernet1/0/14 00:05:04 00:15:17:27:08:34 V2 Ethernet1/0/14 00:05:04 00:21:91:7B:A7:0D V2 Port-Channel1 00:01:16 50:E5:49:29:DB:AC V2 Port-Channel10 00:05:07 00:1A:79:16:F1:0A V2 Отправил leave. Получил specific-query, отправил report что хочу ее дальше смотреть. И ждем ждем ждем. SNR_CORE#sh ip igm sn vlan 100 gr 239.195.7.3 IGMP Snooping Connect Group Membership Note:*-All Source, (S)- Include Source, -Exclude Source Groups Sources Ports Exptime SrcMac System Level 239.195.7.3 * Ethernet1/0/14 00:04:44 00:15:17:27:08:34 V2 Ethernet1/0/14 00:04:44 00:21:91:7B:A7:0D V2 Port-Channel1 00:00:56 50:E5:49:29:DB:AC V2 Port-Channel10 00:04:47 00:1A:79:16:F1:0A V2 Таймер рандомно может дойти и до 10сек до конца, и порт переподпишет, а может и быстро за 10 сек переподписать, а может даже до 00, и удалить порт само собой. == Поднял тайминг коэффициентом robustness: Igmp snooping information for vlan 100 Igmp snooping L2 general querier :Yes(COULD_QUERY) Igmp snooping query-interval :125(s) Igmp snooping max response time :10(s) Igmp snooping specific-query max response time :25(s) Igmp snooping robustness :3 Igmp snooping mrouter port keep-alive time :380(s) Igmp snooping query-suppression time :380(s) Вроде успевает переподписываться. Но есть включить прокси, то этой проблемы вообще нет. Переподписывает порт махом. Но с прокси тоже есть одна непонятная вещь. Кусок таблицы: Port-Channel1 00:03:01 00:1A:79:22:98:E7 V2 239.195.0.2 * Ethernet1/0/14 00:00:44 00:15:17:27:08:34 V1 Ethernet1/0/14 00:00:44 00:1A:79:20:F4:EC V1 Port-Channel1 00:02:56 0C:80:63:1C:1C:49 V2 239.195.0.4 * Ethernet1/0/14 00:03:02 00:15:17:27:08:34 V1 Ethernet1/0/14 00:03:02 84:79:73:DF:8F:9D V2 239.195.0.5 * Ethernet1/0/14 00:02:59 00:15:17:27:08:34 V1 239.195.0.7 * Ethernet1/0/14 00:00:46 00:15:17:27:08:34 V1 Port-Channel10 00:03:05 00:1A:79:16:CC:D0 V2 239.195.0.8 * Ethernet1/0/14 00:00:50 00:15:17:27:08:34 V1 239.195.0.14 * Ethernet1/0/14 00:02:58 00:15:17:27:08:34 V1 239.195.0.18 * Ethernet1/0/14 00:03:04 00:15:17:27:08:34 V1 239.195.0.26 * Ethernet1/0/14 00:03:03 00:15:17:27:08:34 V1 239.195.0.29 * Ethernet1/0/14 00:03:05 00:15:17:27:08:34 V1 Ethernet1/0/14 00:03:05 00:21:91:7B:AA:C5 V1 Ethernet1/0/14 00:03:05 00:1A:79:15:F8:85 V1 Port-Channel10 00:02:58 00:21:91:7B:A6:E4 V2 239.195.0.37 * Ethernet1/0/14 00:02:59 00:15:17:27:08:34 V1 Port-Channel1 00:03:03 00:1A:79:21:9D:96 V2 239.195.0.41 * Ethernet1/0/14 00:03:02 00:15:17:27:08:34 V1 Ethernet1/0/14 00:03:02 00:21:91:7B:AC:BE V1 Port-Channel10 00:03:05 C4:6E:1F:E2:B0:7D V2 239.195.0.52 * Ethernet1/0/14 00:03:01 00:15:17:27:08:34 V1 Ethernet1/0/14 00:03:01 00:1A:79:20:D9:DA V1 Ethernet1/0/14 00:03:01 00:21:91:7B:B0:90 V1 Port-Channel10 00:03:04 00:1A:79:2B:6B:83 V2 239.195.0.57 * Ethernet1/0/14 00:03:04 00:15:17:27:08:34 V1 Port-Channel1 00:04:18 00:0F:3D:CE:49:80 V2 239.195.0.58 * Ethernet1/0/14 00:03:00 00:15:17:27:08:34 V1 Ethernet1/0/14 00:03:00 00:21:91:7B:AA:53 V1 Port-Channel10 00:02:57 00:21:91:7B:AB:89 V2 239.195.0.81 * Ethernet1/0/14 00:03:03 00:15:17:27:08:34 V1 239.195.0.86 * Ethernet1/0/14 00:03:04 00:15:17:27:08:34 V1 239.195.0.96 * Ethernet1/0/14 00:03:02 00:15:17:27:08:34 V1 Port-Channel10 00:02:57 B0:BE:76:7F:09:11 V2 239.195.1.1 * Ethernet1/0/14 00:03:21 00:1A:79:11:A8:AB V2 Ethernet1/0/14 00:03:21 00:16:E8:83:49:2E V1 Ethernet1/0/14 00:03:21 00:1A:79:09:3E:CB V1 Ethernet1/0/14 00:03:21 00:15:17:5E:A9:2D V1 Ethernet1/0/14 00:03:21 00:21:91:7B:B0:7C V1 Ethernet1/0/14 00:03:21 00:15:17:27:08:34 V1 Port-Channel1 00:03:05 00:1A:79:22:C5:AC V2 Port-Channel1 00:03:05 0C:80:63:89:CF:39 V2 Port-Channel10 00:03:01 00:1A:79:32:D4:7F V2 Port-Channel10 00:03:01 00:21:91:7B:A7:32 V2 Port-Channel10 00:03:01 00:21:91:7B:B1:4D V2 Port-Channel10 00:03:01 00:21:91:7B:AC:97 V2 Port-Channel10 00:03:01 00:1A:79:16:F8:AD V2 239.195.1.7 * Port-Channel10 00:03:00 00:21:91:7B:A9:F2 V2 Port-Channel10 00:03:00 00:1A:79:16:F8:AD V2 Querier отвечает на IGMP v1. В этом случае на мультикасте может происходит непонятно что. Но тут есть один момент. Я подозреваю что проблема может быть в хосте (00:15:17:27:08:34) это сервер *каста, который получает по IGMP группы и дальше их гонит в сторону кабельного ТВ сегмента. В принципе почти ничего страшного, но хотелось бы выпилить V1. А так же по Querier PROXY - прокси необходим, или что то не так настроено возможно? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Aleksey Sonkin Опубликовано 18 февраля, 2020 · Жалоба @semop Цитата Просто без прокси создается впечатление что SNR как то криво отвечает на REPORT. Нужны 'sh run' и 'sh ver' полные, предлагаю решить вопрос в рамках support, а тут отпишем по результату. Цитата В принципе почти ничего страшного, но хотелось бы выпилить V1. Такой возможности нет. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...