[semop]

Из документации:

 

ip igmp snooping vlan interface (ethernet | port-channel|) IFNAME limit {group | source } strategy (replace | drop)

no ip igmp snooping vlan interface (ethernet | port-channel|) IFNAME limit group source strategy

 

Configure the number of groups which are allowed joining and the maximum of the source in each group under the IGMP Snooping port. Configure the strategy when it is up to the upper limit, including “replace” and “drop”. No command configures as “no limitation”

 

no limit = limit default = limit 40?

 

SNR_CORE(config)#ip igmp snooping vlan 100 limit group 1024 source ?
  <1-65535>  Value of limitation 
 

Этой одна команда справедлива двум отдельным?:

SNR_CORE(config)#ip igmp snooping vlan 100 limit group ?   
  <1-65535>  Value of limitation 

SNR_CORE(config)#ip igmp snooping vlan 100 limit source ?
  <1-65535>  Value of limitation 
 

 

[vurd]

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

Из документации:

 

ip igmp snooping vlan interface (ethernet | port-channel|) IFNAME limit {group | source } strategy (replace | drop)

no ip igmp snooping vlan interface (ethernet | port-channel|) IFNAME limit group source strategy

 

Configure the number of groups which are allowed joining and the maximum of the source in each group under the IGMP Snooping port. Configure the strategy when it is up to the upper limit, including “replace” and “drop”. No command configures as “no limitation”

 

no limit = limit default = limit 40?

 

SNR_CORE(config)#ip igmp snooping vlan 100 limit group 1024 source ?
  <1-65535>  Value of limitation 
 

Этой одна команда справедлива двум отдельным?:

SNR_CORE(config)#ip igmp snooping vlan 100 limit group ?   
  <1-65535>  Value of limitation 

SNR_CORE(config)#ip igmp snooping vlan 100 limit source ?
  <1-65535>  Value of limitation 
 

 

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

И на 2995 нет возможность управлять стратегией, работает как drop. По крайней мере команда не показывает такое дополнение как strategy в случае vlan.

[Victor Tkachenko]

@vurd, не исключаю такой вариант, но и для подтверждения данных мало. Установка 65535 вам наверняка не принесет никаких проблем, это может быть чревато только переполнением таблиц при транзите нескольких vlan с большим количеством подписчиков или при наличии аномальной активности от клиентов.

 

@semop, то описание не глобальных ограничений, а для отдельных интерфейсов.

[semop]

Понял) Спасибо.

 

В default (ничего не применяя) получается работает так - ip igmp snooping vlan 100 limit group 50 source 40?

Значит железная команда FULL - ip igmp snooping vlan 100 limit group 65535 source 65535?

[Victor Tkachenko]

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

В default (ничего не применяя) получается работает так - ip igmp snooping vlan 100 limit group 50 source 40?

Верно.

 

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

Значит железная команда FULL - ip igmp snooping vlan 100 limit group 65535 source 65535?

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

[vurd]

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

@vurd, не исключаю такой вариант, но и для подтверждения данных мало. Установка 65535 вам наверняка не принесет никаких проблем, это может быть чревато только переполнением таблиц при транзите нескольких vlan с большим количеством подписчиков или при наличии аномальной активности от клиентов.

 

@semop, то описание не глобальных ограничений, а для отдельных интерфейсов.

Проверил.

Настройки

ip igmp snooping

no ip igmp snooping proxy

ip igmp snooping vlan 1751

ip igmp snooping vlan 1751 limit groups 65535 source 65535

 

Сразу же поймал невозможность подписаться на одну из групп. На картинке лог действий.

 

 

 

Просто тупо не появляется подписка на 2995, то-ли пакет рейт-лимится чем-то, то-ли еще что. Но как только гасишь снупинг - сразу влёт подписывается.

 

В лабе прошел 200+ каналов - нет такого, всё нормально. Такое ощущение, что именно при большом количестве клиентов возникает. У меня есть небольшие сегменты на 2995, там не было замечено, а как только в нагруженный воткнул - в первый же день.

 

[semop]

Вот прямо именно такую штуку я наблюдал, пока не поставил лимит 1024.

Тут что то непонятное тогда.

 

А полная таблица igmp групп больше 50?

Если да, то строчка по идее рабочая получается.

 

@vurd 

Для информации.

У нас такая схема IGMP на ядре до агрегаций.

 

 

Единственное что я не понял когда запускался, это было включение igmp proxy на первом SNR.

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

На следующем SNR, да и вообще везде proxy выключен.

 

Это я наблюдал уже после того, как была решена проблема с лимитом 50 групп.

++ ip igmp snooping vlan 100 l2-general-querier-source <IP querier>

Добавил на всех SNR.

[vurd]

Я читал вашу тему. Мое мнение, не использовать igmp proxy mode никогда, т.к. это костыль. В нормальном мальтикаст домене у вас есть querier, он же держит PIM с вышестоящим. Всё. Снупинг сам должен водить жалом на предмет куда там кого включить, кого отключить, исходя из летящих мимо него пакетов. По вашей схеме нужно нудно сидеть от хоста к хосту с дебагом и искать почему так происходит.

 

У меня тут еще мысль появилась. Может быть попробовать использовать MVR? Нет? Плохая идея? Он может в теге отдавать трафик вообще?

[darkagent]

13 часов назад, vurd сказал:

Может быть попробовать использовать MVR? Нет? Плохая идея?

если ты их брал на l3, то почему бы не попробовать с них сразу pim отдавать? ;)

[vurd]

24 минуты назад, darkagent сказал:

если ты их брал на l3, то почему бы не попробовать с них сразу pim отдавать? ;)

Сам знаешь. Я уже тут описывал, что думаю о реализации PIM-а в теме про S300. Там нет механизме expire при отписке последнего клиента. Точнее он есть, но выполнен наоборот:

1. Клиент подписан. group, source, 250s.

2. Клиент подписан. group, source, 125s.

3. Клиент отписан, group, NULL, HOLD_TIME 3s.

 

Т.е. в циске, например, последний цикл выглядит как "Клиент отписан, group, source, HOLD_TIME", коммутатор держит источник до последнего на протяжении >200 секунд. В DCN решили, что это слишком логично и сделали через жопу, они после лива ставят источник в NULL и на протяжении HOLD_TIME подписка на группу невозможна. Этот HOLD_TIME регулируется ip unresolved-что-то-там, можно сократить до секунды. Но всё равно, за кой хрен так делать мне совершенно непонятно.

Ну бери циску, смотри как там и копируй. НЕТ, авторское решение, млять. Защищают мой "роутер" от лишних 5 мегабит в течение 300 секунд...

 

Ну и так то да, я брал на L3 и буду переезжать, но сегменты были в L2, поэтому первый этап было тупо заменить железо в ту же топологию.

 

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

[vurd]

@Victor Tkachenko, имеет смысл открывать тикет-то, учитывая, что поймать на столе я этого не могу?

Я сниму один свитч в зип, погоняю на нем, но надежд мало.

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

[Victor Tkachenko]

@vurd, да, смысл есть. Опишите топологию и конфигурацию устройств в проблемном сегменте, в том числе параметры querier и версия IGMP у подписчиков.

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

[vurd]

В 05.04.2019 в 22:43, Victor Tkachenko сказал:

@vurd, да, смысл есть. Опишите топологию и конфигурацию устройств в проблемном сегменте, в том числе параметры querier и версия IGMP у подписчиков.

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

Я нашел проблему. Иногда таймер снупинга не обновляется. Я вижу как улетает general query, я вижу как на него отвечают коммутаторы, стоящие за 2995, но из-за реализации протокола на eltex, который работает как igmp proxy, я не вижу отвечает ли он. Скорее всего он отвечает, так как проблема вылезла после замены 3120 на 2995. Будем считать, что он отвечает корректно и report отправляется.

 

Отсюда у меня возникает ряд вопросов:

1. Может ли коммутатор рейтлимитить пакеты igmp report? Это бы объяснило, почему счетчик не обновился.

2. Коммутатор мог дропнуть входящий пакет по какой-то другой причине? Переполнение буфера или еще что-то подобное.

3. Можно ли увеличить exptime в таблице igmp snooping-а? Сейчас там какое-то магическое число в 260 секунд (4 минуты 20 секунд).

 

Пока я решил проблему снизив время рассылки general query со 125 секунд до 60-и. Таким образом на 2995 гарантировано прилетает report как минимум 3 раза. 

 

 

Вроде как сейчас стало нормально. Но я продолжаю видеть пропуски в обновлении таймера. Тестовую лабу вижу как свитч в роли igmp querirer сверху, 2995 в середине и клиента внизу. По идеи если задать небольшой интервал рассылки, включить дебаг igmp, то можно будет отследить пропуск.

 

Еще такой момент. Я точно ловил подобное поведение на S300, но там другой аппаратный чип, что наталкивает меня на мысли о софтовой проблеме.

 

Прокомментируйте, пожалуйста.

 

[Victor Tkachenko]

@vurd

 

1. Может - `show cpu-rx protocol IGMP`.

2. Не исключено, но рейтлимит cpu-rx наверняка сработает раньше.

3. Время жизни высчитывается по формуле (interval*robustness + mrsp), по умолчанию это 260с. Значение берутся из полей IGMP Query. Обратили внимание, что на текущей версии ПО S2995 таймер не изменяются, с этим разберемся. После исправления для увеличения надежности можно повысить robustness Querier`а до 3-4.

 

Подобных массовых случаев не регистрировали, сталкивались лишь с падением производительности при большом количестве подписок и pps IGMP (подписки удалялись/добавлялись с задержкой в пару секунд при наличии ~250 уникальных групп в таблице и >15pps IGMP).

 

Сохранились подробности проблемы на S300?

[semop]

Планирую на след. неделе реконструкцию мультикаста и переместить querier на SNR-S2990-16X

Работает у кого-то на таком? Все ли хорошо?

700мбит телевизора

[semop]

Переехал сегодня ночью на SNR-querier.

 

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

Никому ничего не сказал), провел эксперимент. Ни одного звонка за утро/день. В принципе это по большому счету показатель. Иначе сразу начинался звон.

 

Ура. Я доволен. Можно налить кофеечек...

[semop]

Прошу консультации.

Чтоб не думалось, верно ли я все сделал относительно покраски мультикаста?

 

Схема:

 

SWITCH_1 - к нему подключены источники, он собирает мультикаст в кучу и отдает в порт SNR_stack(это 2 SNR коммутатора соединенных VSF)

IGMP выключен, просто влан. QOS нет. Порт - транк.

 

SNR_stack - 1:10 подключен к свичу с источниками. Порт - транк.

Включен только IGMP и QUERIER. Покрашен влан 100 (влан мультикаста). 

class-map mcast
 match vlan 100
!
policy-map mcast
 class mcast
 set ip dscp 56
 set internal-priority 7
 exit
!
interface ethernet 1/0/10
service-policy input mcast
!
interface Vlan100
 ip address 10.253.0.1 255.255.0.0
!
ip igmp snooping
ip igmp snooping vlan 100
ip igmp snooping vlan 100 limit group 1024
ip igmp snooping vlan 100 l2-general-querier
ip igmp snooping vlan 100 l2-general-querier-version 2
ip igmp snooping vlan 100 l2-general-querier-source 10.253.0.1
ip igmp snooping vlan 100 mrouter-port interface Ethernet1/0/10
ip igmp snooping vlan 100 report source-address 10.253.0.1

 

SWITCH_a / SWITCH_b - коммутаторы агрегаций. От них подключен доступ. Включен IGMP и MULTICAST-VLAN.

Это Д-линки. Крашу на них так (в принципе должно было хватить dscp trust, но я покрасил еще раз чтоб если что....):

config dscp trust all state disable
config dscp trust 1:1-1:24 state enable

create access_profile profile_id 1 profile_name 1 ip destination_ip_mask 255.255.224.0 dscp 
config access_profile profile_id 1 add access_id auto_assign ip destination_ip 239.195.0.0 mask 255.255.224.0 dscp 56 port 1:1-1:24 permit priority 7 replace_priority replace_dscp 56 

create access_profile profile_id 2 profile_name 2 ip destination_ip_mask 255.255.0.0 dscp 
config access_profile profile_id 2 add access_id auto_assign ip destination_ip 224.57.0.0 mask 255.255.0.0 dscp 56 port 1:1-1:24 permit priority 7 replace_priority replace_dscp 56 

create access_profile profile_id 3 profile_name 3 ip destination_ip_mask 255.255.0.0 dscp 
config access_profile profile_id 3 add access_id auto_assign ip destination_ip 224.59.0.0 mask 255.255.0.0 dscp 56 port 1:1-1:24 permit priority 7 replace_priority replace_dscp 56 

 

==

Интересует полнота конфига для QOS на коммутаторах SNR.

Покрасил весь влан, а не группы. И конфиг только на порту, к которому подключен коммутатор с источниками.

 

С рабочего места через агрегацию вайр-шарк говорит, что покрашено (dscp 56 / prio 7)

 

Но это может быть перекраска на агрегации.

 

И второй вопрос: как с доверием меток у коммутаторов в стеке? 

VSF собран, и не конфигурился со времени запуска. Фактически там пусто на портах.

 

switch convert mode vsf
vsf member 2
vsf priority 32
vsf port-group 1
 vsf port-group Interface Ethernet2/0/15
 vsf port-group Interface Ethernet2/0/16
!
vsf auto-merge enable
!
Interface Ethernet1/0/15
!
Interface Ethernet1/0/16
!
...
!
Interface Ethernet2/0/15
!
Interface Ethernet2/0/16
!

SNR_CORE#sh cpu-rx protocol igmp
--------------------------Slot : member 1, slot 1----------------------
Type                Rate-limit    TotPkts        DropPkts       DelayCount     CurState      StatusChg      
IGMP                200           23122186       0              0              allowed       0              
TOTAL-LIMIT         2000                         
--------------------------Slot : member 2, slot 1----------------------
Type                Rate-limit    TotPkts        DropPkts       DelayCount     CurState      StatusChg      
IGMP                200           256929974      291083         0              allowed       0              
TOTAL-LIMIT         2000                         
SNR_CORE#

 

Коммутатор с источниками подключен к 1.

IGMP распространяется с обоих. Ошибки только на 2ом.

 

ПС: какой-то ярковыраженной разницы в качестве телевизора между агрегациями - нет. Хотя по большому счету я даже пока не представляю как это отследить, по причине того, что агрегации подключены к SNR'ам - по LACP. Т.е. где именно физически группа живет я не знаю)

Поэтому это не совсем честный тест.

Идеальный вариант - это видимо подключиться к каждому SNR'у по очереди напрямую коммутатором доступа и посмотреть что там.

[semop]

По результатам сегодняшних тестов.

 

Собрал несколько схем.

 

На SNR конфиг:

SNR_CORE#sh mls qos interface e1/0/10 queuing 
Ethernet1/0/10:

Egress Internal-Priority-TO-Queue map: 
INTP:  0   1   2   3   4   5   6   7 
 -----------------------------------------
Queue: 0   1   2   3   4   5   6   7   

Queue Algorithm: WRR
Queue weights:
Queue      1     2     3     4     5     6     7     8 
 ------------------------------------------------------
WrrWeight  1     2     3     4     5     6     7     8     
WdrrWeight 1     2     4     8     16    32    64    64    

Bandwidth Guarantee Configuration:
Queue    1       2       3       4       5       6       7       8 
 ------------------------------------------------------------------
MinBW(K) 0       0       0       0       0       0       0       0       
MaxBW(K) 0       0       0       0       0       0       0       0       

class-map mcast
 match vlan 100
!
policy-map mcast
 class mcast
 set ip dscp 56
 set internal-priority 7
 exit
!
interface ethernet 1/0/10
service-policy input mcast
!
interface Vlan100
 ip address 10.253.0.1 255.255.0.0
!
ip igmp snooping
ip igmp snooping vlan 100
ip igmp snooping vlan 100 limit group 1024
ip igmp snooping vlan 100 l2-general-querier
ip igmp snooping vlan 100 l2-general-querier-version 2
ip igmp snooping vlan 100 l2-general-querier-source 10.253.0.1
ip igmp snooping vlan 100 mrouter-port interface Ethernet1/0/10
ip igmp snooping vlan 100 report source-address 10.253.0.1

Очереди вообще не сконфигурены. Заводские значения. Алгоритм WRR.

 

Тестовый коммутатор SWITCH_A - полностью сброшен. Проключен влан офисной сети и создан мультикаст влан. Никаких QOS/ACL нет.

Вайр-шарк в обоих случаях показал, что трафик покрашен.

 

Я вообще то ждал, что будет метка 0. Доверия на SWITCH_A не настроено. Как он пропустил покрашеный, не глядя на метки?

У коммутатора в конфиге полный дефолт :

# QOS

config scheduling_mechanism strict
config scheduling 0 weight 1 
config scheduling 1 weight 2 
config scheduling 2 weight 4 
config scheduling 3 weight 8 
config 802.1p user_priority 0 1
config 802.1p user_priority 1 0                                                
config 802.1p user_priority 2 0
config 802.1p user_priority 3 1
config 802.1p user_priority 4 2
config 802.1p user_priority 5 2
config 802.1p user_priority 6 3
config 802.1p user_priority 7 3
config cos tos value 0 class 0
config cos tos value 1 class 0
config cos tos value 2 class 0
config cos tos value 3 class 0
config cos tos value 4 class 0
config cos tos value 5 class 0
config cos tos value 6 class 0
config cos tos value 7 class 0
config dscp_mapping dscp_value 0 class 0
config dscp_mapping dscp_value 1 class 0
config dscp_mapping dscp_value 2 class 0
config dscp_mapping dscp_value 3 class 0
config dscp_mapping dscp_value 4 class 0
config dscp_mapping dscp_value 5 class 0
config dscp_mapping dscp_value 6 class 0
config dscp_mapping dscp_value 7 class 0                                       
config dscp_mapping dscp_value 8 class 0
config dscp_mapping dscp_value 9 class 0
config dscp_mapping dscp_value 10 class 0
config dscp_mapping dscp_value 11 class 0
config dscp_mapping dscp_value 12 class 0
config dscp_mapping dscp_value 13 class 0
config dscp_mapping dscp_value 14 class 0
config dscp_mapping dscp_value 15 class 0
config dscp_mapping dscp_value 16 class 0
config dscp_mapping dscp_value 17 class 0
config dscp_mapping dscp_value 18 class 0
config dscp_mapping dscp_value 19 class 0
config dscp_mapping dscp_value 20 class 0
config dscp_mapping dscp_value 21 class 0
config dscp_mapping dscp_value 22 class 0
config dscp_mapping dscp_value 23 class 0
config dscp_mapping dscp_value 24 class 0
config dscp_mapping dscp_value 25 class 0
config dscp_mapping dscp_value 26 class 0
config dscp_mapping dscp_value 27 class 0
config dscp_mapping dscp_value 28 class 0
config dscp_mapping dscp_value 29 class 0                                      
config dscp_mapping dscp_value 30 class 0
config dscp_mapping dscp_value 31 class 0
config dscp_mapping dscp_value 32 class 0
config dscp_mapping dscp_value 33 class 0
config dscp_mapping dscp_value 34 class 0
config dscp_mapping dscp_value 35 class 0
config dscp_mapping dscp_value 36 class 0
config dscp_mapping dscp_value 37 class 0
config dscp_mapping dscp_value 38 class 0
config dscp_mapping dscp_value 39 class 0
config dscp_mapping dscp_value 40 class 0
config dscp_mapping dscp_value 41 class 0
config dscp_mapping dscp_value 42 class 0
config dscp_mapping dscp_value 43 class 0
config dscp_mapping dscp_value 44 class 0
config dscp_mapping dscp_value 45 class 0
config dscp_mapping dscp_value 46 class 0
config dscp_mapping dscp_value 47 class 0
config dscp_mapping dscp_value 48 class 0
config dscp_mapping dscp_value 49 class 0
config dscp_mapping dscp_value 50 class 0
config dscp_mapping dscp_value 51 class 0                                      
config dscp_mapping dscp_value 52 class 0
config dscp_mapping dscp_value 53 class 0
config dscp_mapping dscp_value 54 class 0
config dscp_mapping dscp_value 55 class 0
config dscp_mapping dscp_value 56 class 0
config dscp_mapping dscp_value 57 class 0
config dscp_mapping dscp_value 58 class 0
config dscp_mapping dscp_value 59 class 0
config dscp_mapping dscp_value 60 class 0
config dscp_mapping dscp_value 61 class 0
config dscp_mapping dscp_value 62 class 0
config dscp_mapping dscp_value 63 class 0
config 802.1p default_priority 1-28 0
config cos mapping port 1-28  ethernet 802.1p  

 

А в боевую я конфигурю доступ так (25-28 транки):

 

config dscp trust 25-28 state enable

config dscp_mapping dscp_value 56 class 3
config cos mapping port 25-28 port_mapping ethernet 802.1p ip dscp 
create access_profile  ip  destination_ip 255.255.0.0   dscp  profile_id 4
config access_profile profile_id 4  add access_id 1  ip  destination_ip 239.195.0.0      port 1-28 permit priority 7 rx_rate no_limit 
config access_profile profile_id 4  add access_id 2  ip  destination_ip 224.57.0.0      port 1-28 permit priority 7 rx_rate no_limit 
config access_profile profile_id 4  add access_id 3  ip  destination_ip 224.59.0.0      port 1-28 permit priority 7 rx_rate no_limit 

Не понял почему так вышло. Можете прокомментировать?

Вайр-шарк показал 56/7 как настроено на SNR.

 

Зачем вот это все тогда?)

[semop]

Опытным путем выяснилось что на доверие меток почему то всем пофик.

При таком конфиге настроенный DSCP на SNR разлетается по всей сети, даже если trust отключить.

А менять/перекрашивать можно ACL'ами на агрегациях или доступе.

 

Оставил конфиг по покраске только на SNR. И на порту который смотрит в источники.

Дальше всю трассу вычистил от ACL и trust. На конце свича доступа получил покрашеный SNR'ом мультикаст.

 

Еще больше перестал понимать эту штуку. Не так же должно. Нет?

Самое непонятное это почему DSCP без trust на uplink порту пробрасывается.

 

ПС: с VSF все ок. Между свичами крашеный трафик.

[vurd]

Долго читать, но схема действий должна быть такой:

1. Красим как можно ближе к источнику, прямо на порте приёма.

2. На снр очереди на портах переводить в режим strict.

3. На цепочке от аплинка к даунлику включаем доверие dscp.

 

Без этого на 2995 у вас будет гарантированно подсыпать при разношерстном трафике.

[semop]

26 минут назад, vurd сказал:

Долго читать, но схема действий должна быть такой:

1. Красим как можно ближе к источнику, прямо на порте приёма.

2. На снр очереди на портах переводить в режим strict.

3. На цепочке от аплинка к даунлику включаем доверие dscp.

 

Без этого на 2995 у вас будет гарантированно подсыпать при разношерстном трафике.

Именно так и было всегда настроено.

Я это проверял аналогично вайр-шарком.

 

Потом переключил квэриер на СНР. И оно пашет со всей краской даже без этих настроек.

Почему то.

Канал ХД при включеном спидтесте без ограничения просаживает тарифный план инета, но зато ТВ при этом не сыпет.

Вот у меня и возник вопрос почему оно работает без trust'а на портах.

[semop]

В 05.04.2019 в 09:37, vurd сказал:

косяк со снупингом какой-то

Тоже обнаружил что-то нехорошее.

 

Суть в том, что когда, глядя по VLC на своем ПК группу, когда кто-то ее ливует, через таймер от квэриера прилетает igmp specific query.

И именно в этот момент падает поток. Группа в подписках остается, а поток в ноль. 1-4сек и поток опять пошел.

 

На всем доступе fastleave отключен. immediately-leave тоже не работает.

Квэриер - SNR 2990.

 

Igmp snooping information for vlan 100

Igmp snooping L2 general querier                  :Yes(COULD_QUERY)
Igmp snooping query-interval                      :60(s)
Igmp snooping max response time                   :10(s)
Igmp snooping specific-query max response time    :25(s)
Igmp snooping robustness                          :2
Igmp snooping mrouter port keep-alive time        :125(s)
Igmp snooping query-suppression time              :125(s)

 

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

Зарылся в дебаг SNR'a.......может report кривой где-то.

 

Ну блин и как обычно) Этого - не было, каст никто не конфигурил.

 

ПС:

Конфиг квэриера

 

ip igmp snooping
ip igmp snooping vlan 100
ip igmp snooping vlan 100 limit group 2048 source 2048
ip igmp snooping vlan 100 l2-general-querier
ip igmp snooping vlan 100 l2-general-querier-version 2
ip igmp snooping vlan 100 l2-general-querier-source 10.253.0.1
ip igmp snooping vlan 100 query-interval 60
ip igmp snooping vlan 100 query-mrsp 25
ip igmp snooping vlan 100 specific-query-mrsp 25
ip igmp snooping vlan 100 mrouter-port interface Ethernet1/0/10

 

Включен proxy.

 

[semop]

Нашел.

 

Вопщем у нас выключен report suppression на доступе. Очень давно выяснилось что функционал пашет некорректно почему то.

Перелопатил весь доступ, все свичи, нашел 2 свичика с включенным repport suppression. Отключил. Проблема ушла.

 

елки палки, такая фигня и такой вал на всем касте из-за этого...

[Aleksey Sonkin]

@semop О каких коммутаторах доступа идет речь?

[semop]

@Aleksey Sonkin доступ dlink, ядро snr.

Но все уже нормально.

 

Просто насторожило, что именно после прилетающего пакета specific query от SNR мультикаст отваливался при подписанной группе.

 

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

 

ПС: так кстати и не разобрался почему растут счетчики на cpu igmp у SNR стека.

Причем у member-2 их больше.

rate-limit'ы дефолтные. qos настроен. Мультикаст не сыпет. А все равно что-то дропает.

 

SNR_CORE#sh cpu-rx protocol igmp
--------------------------Slot : member 1, slot 1----------------------
Type                Rate-limit    TotPkts        DropPkts       DelayCount     CurState      StatusChg      
IGMP                200           82470434       13439          0              allowed       0              
TOTAL-LIMIT         2000                         
--------------------------Slot : member 2, slot 1----------------------
Type                Rate-limit    TotPkts        DropPkts       DelayCount     CurState      StatusChg      
IGMP                200           193910121      181529         0              allowed       0              
TOTAL-LIMIT         2000