Перейти к содержимому
Калькуляторы

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

Ответить

-Ars-   

-Ars-
Опубликовано · Жалоба
Дсламы в основном сконфигурены в режиме igmp proxy

Так если отписка не прошла с клиента и DSLAM, который тоже должен опрашивать клиентов, по какой-то причине "залип" (не люблю я использовать такую терминологию, но мы же о глюках ;) ), то он, возможно, будет продолжать отвечать каталисту, что подписка активна. Кстати, DSLAM случаем не Zyxel? На маленьких моделях (IS-1000, что ли) я встречал всяческие глюки с мультикастом. Точно не опишу, давно это было, да и сеть у нас все же не провайдерская, но доверие к ним несколько подорвало :)

Кстати, а почему на одном и том же порту сидит и "нормальный" адрес DSLAM-а и сомнительный 192.168.1.1?

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

tehmeh   

tehmeh
Опубликовано (изменено) · Жалоба

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

Коммутатор с igmp snooping по-идее хранит актуальную базу подписок на группы и просто не пропустит leave выше, если у него отписывается только один из нескольких downstream-портов c этой же группой. Это как минимум.

 

то при отписке одного из них - трафик в группу сразу прекратится и канал погаснет сразу у всех, не надолго - до след. репорта от живого абонента

Если предположить, что в схеме есть только querier, но нет устройства со snooping'ом, получив leave, querier сделает серию group specific query на адрес этой группы, серия настраивается непосредственно на L3-интерфейсе (Robustness или как-то так). Выход из группы только одного члена еще не означает, что маршрутизатор должен перестать передавать трафик этой группы через интерфейс, получив Leave Group, маршрутизатор должен выяснить, остались ли его интерфейсом другие члены данной группы. Поэтому трафик не должен прерываться, как вы пишите.

 

Но настраивать fast leave не за портом доступа - глупо, согласен.

Изменено пользователем tehmeh

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

uk2558   

uk2558
Опубликовано · Жалоба
Дсламы в основном сконфигурены в режиме igmp proxy

Так если отписка не прошла с клиента и DSLAM, который тоже должен опрашивать клиентов, по какой-то причине "залип" (не люблю я использовать такую терминологию, но мы же о глюках ;) ), то он, возможно, будет продолжать отвечать каталисту, что подписка активна. Кстати, DSLAM случаем не Zyxel? На маленьких моделях (IS-1000, что ли) я встречал всяческие глюки с мультикастом. Точно не опишу, давно это было, да и сеть у нас все же не провайдерская, но доверие к ним несколько подорвало :)

Кстати, а почему на одном и том же порту сидит и "нормальный" адрес DSLAM-а и сомнительный 192.168.1.1?

Была похожая проблема с BDCom 3310, настроенным в режим igmp proxy. По default у него были какие то адские timeout. Можно было положить весь upstream простым перещелкиванием каналов. Уменьшил timeout и все нормализовалось.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Azamat   

Azamat
Опубликовано · Жалоба

immediate/fast leave на то и немедленный, что при первом же leave снимает группу с порта, откуда он прилетел, без дополнительных запросов на живых подписчиков этой же группы. Поэтому, если ниже на этом же транке подписаны на эту же группу неважно сколько живых абонентов - у всех на небольшое время пропадет канал, который они смотрят. Даже если этот параметр будет только на received порту в сторону конкретного абонента, а у того несколько stb и если на всех stb смотрят один и тот же канал - при переключении с канала любой stb на всех приставках ненадолго будет черный экран.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

survivor   

survivor
Опубликовано · Жалоба

-Ars-

Кстати, DSLAM случаем не Zyxel? На маленьких моделях (IS-1000, что ли) я встречал всяческие глюки с мультикастом

У меня как раз Zyxel IES1248 :)

попробую перевести в режим snooping

 

Кстати, а почему на одном и том же порту сидит и "нормальный" адрес DSLAM-а и сомнительный 192.168.1.1

сам не пойму, не должно быть так

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

-Ars-   

-Ars-
Опубликовано · Жалоба
Zyxel IES1248

:)

Ну, да, это модуль, а шасси - вроде 1000.

Прошивка самая последняя? Они там много чего чинили

И, это, у него, если меня склероз не обманывает, дефолтный management ip address 192.168.1.1.

Короче, завтра буду на работе - посмотрю. Сверим, такскать, часы :)

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

tehmeh   

tehmeh
Опубликовано · Жалоба

immediate/fast leave на то и немедленный

Мы видимо не поняли друг друга, я имел ввиду, что другие порты будут получать поток. Ни разу не встречал, чтобы fast leave настраивался для портов не последней мили.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

survivor   

survivor
Опубликовано (изменено) · Жалоба

Итак, проблема легко воспроизводится на столе. Без дсламов.

 

Берем один L3 каталист, поднимаем на нем pim. Подключаем к нему второй каталист (доступ), настраиваем MVR. К каталисту доступа подключаем STB и смотрим один канал:

На L3 приходит 3-5 мегабит, уходит в сторону каталиста доступа тоже 3-5 мегабит.

 

Переключаем каналы на STB:

Теперь на L3 приходит под 100 мегабит, хотя в сторону доступа - по прежнему 3-5 мегабит.

 

Снял дебаги c L3 каталиста

 

Switch#sh ip pim neighbor 
10.112.55.9       Vlan55                   00:10:44/00:01:19 v2    1 / S P

Switch#sh ip mr
(*, 239.XXX.XXX.149), 00:01:08/00:02:59, RP 10.100.1.9, flags: SC
 Incoming interface: Vlan55, RPF nbr 10.112.55.9
 Outgoing interface list:
   Vlan59, Forward/Sparse-Dense, 00:00:53/00:02:21, H

Switch#sh ip igmp snooping groups 
Vlan      Group             Version     Port List
------------------------------------------------------------
59        239.XXX.XXX.149   v2          Fa0/24

Пока все Ok. Один канал. Регулярно приходят:

00:12:43: IGMP(0): Send v2 general Query on Vlan59
00:12:47: IGMP(0): Received v2 Report on Vlan59 from XXX.XXX.49.1 for 239.XXX.XXX.149
00:12:47: IGMP(0): Received Group record for group 239.XXX.XXX.149, mode 2 from XXX.XXX.49.1 for 0 sources
00:12:47: IGMP(0): Updating EXCLUDE group timer for 239.XXX.XXX.149
00:12:47: IGMP(0): MRT Add/Update Vlan59 for (*,239.XXX.XXX.149) by 0

Начинаем переключать каналы.

00:17:52: IGMP(0): Received Group record for group 239.XXX.XXX.100, mode 2 from XXX.XXX.49.1 for 0 sources
00:17:52: IGMP(0): WAVL Insert group: 239.XXX.XXX.100 interface: Vlan59Successful
00:17:52: IGMP(0): Switching to EXCLUDE mode for 239.XXX.XXX.100 on Vlan59
00:17:52: IGMP(0): Updating EXCLUDE group timer for 239.XXX.XXX.100
00:17:52: IGMP(0): MRT Add/Update Vlan59 for (*,239.XXX.XXX.100) by 0

00:17:52: IGMP(0): Received v2 Report on Vlan59 from XXX.XXX.49.1 for 239.XXX.XXX.99
00:17:52: IGMP(0): Received Group record for group 239.XXX.XXX.99, mode 2 from XXX.XXX.49.1 for 0 sources
00:17:52: IGMP(0): WAVL Insert group: 239.XXX.XXX.99 interface: Vlan59Successful
00:17:52: IGMP(0): Switching to EXCLUDE mode for 239.XXX.XXX.99 on Vlan59
00:17:52: IGMP(0): Updating EXCLUDE group timer for 239.XXX.XXX.99
00:17:52: IGMP(0): MRT Add/Update Vlan59 for (*,239.XXX.XXX.99) by 0

00:17:53: IGMP(0): Received v2 Report on Vlan59 from XXX.XXX.49.1 for 239.XXX.XXX.48
00:17:53: IGMP(0): Received Group record for group 239.XXX.XXX.48, mode 2 from XXX.XXX.49.1 for 0 sources
00:17:53: IGMP(0): WAVL Insert group: 239.XXX.XXX.48 interface: Vlan59Successful
00:17:53: IGMP(0): Switching to EXCLUDE mode for 239.XXX.XXX.48 on Vlan59
00:17:53: IGMP(0): Updating EXCLUDE group timer for 239.XXX.XXX.48
00:17:53: IGMP(0): MRT Add/Update Vlan59 for (*,239.XXX.XXX.48) by 0

После этого на аплинке видим:

Switch#sh int fastEthernet 0/23

30 second input rate 77323000 bits/sec, 7079 packets/sec

На линке в сторону каталиста доступа:

Switch#sh int fastEthernet 0/24

30 second output rate 4865000 bits/sec, 443 packets/sec

Через несколько минут (!!!) начинается:

00:20:43: IGMP(0): Send v2 general Query on Vlan59
00:20:45: IGMP(0): Switching to INCLUDE mode for 239.XXX.XXX.162 on Vlan59
00:20:45: IGMP(0): MRT delete Vlan59 for (*,239.XXX.XXX.162) by 0
00:20:46: IGMP(0): Switching to INCLUDE mode for 239.XXX.XXX.176 on Vlan59
00:20:46: IGMP(0): MRT delete Vlan59 for (*,239.XXX.XXX.176) by 0
00:20:46: IGMP(0): Switching to INCLUDE mode for 239.XXX.XXX.145 on Vlan59
00:20:46: IGMP(0): MRT delete Vlan59 for (*,239.XXX.XXX.145) by 0
00:20:47: IGMP(0): Switching to INCLUDE mode for 239.XXX.XXX.165 on Vlan59
00:20:47: IGMP(0): MRT delete Vlan59 for (*,239.XXX.XXX.165) by 0
00:20:47: IGMP(0): Switching to INCLUDE mode for 239.XXX.XXX.175 on Vlan59
00:20:47: IGMP(0): MRT delete Vlan59 for (*,239.XXX.XXX.175) by 0
00:20:48: IGMP(0): Switching to INCLUDE mode for 239.XXX.XXX.91 on Vlan59
00:20:48: IGMP(0): MRT delete Vlan59 for (*,239.XXX.XXX.91) by 0

 

После чего outgoing interface становится Null:

Switch#sh ip mr     
(*, 239.XXX.XXX.98), 00:03:15/00:02:46, RP 10.100.1.9, flags: SP
 Incoming interface: Vlan55, RPF nbr 10.112.55.9
 Outgoing interface list: Null

(*, 239.XXX.XXX.127), 00:05:23/00:01:35, RP 10.100.1.9, flags: SP
 Incoming interface: Vlan55, RPF nbr 10.112.55.9
 Outgoing interface list: Null

(*, 239.XXX.XXX.91), 00:03:22/00:02:39, RP 10.100.1.9, flags: SP
 Incoming interface: Vlan55, RPF nbr 10.112.55.9
 Outgoing interface list: Null

И траффик на обоих интерфейсах выравнивается.

Изменено пользователем survivor

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

survivor   

survivor
Опубликовано · Жалоба

А вот так выглядит debug ip pim:

 

Во время переключения каналов:

00:51:37: PIM(0): Check RP 10.100.1.9 into the (*, 239.XXX.XXX.175) entry
00:51:37: PIM(0): Building Triggered (*,G) Join / (S,G,RP-bit) Prune message for 239.XXX.XXX.175
00:51:37: PIM(0): Insert (*,239.XXX.XXX.175) join in nbr 10.112.55.9's queue
00:51:37: PIM(0): Building Join/Prune packet for nbr 10.112.55.9
00:51:37: PIM(0):  Adding v2 (10.100.1.9/32, 239.XXX.XXX.175), WC-bit, RPT-bit, S-bit Join
00:51:37: PIM(0): Send v2 join/prune to 10.112.55.9 (Vlan55)
00:51:37: PIM(0): Check RP 10.100.1.9 into the (*, 239.XXX.XXX.176) entry
00:51:37: PIM(0): Building Triggered (*,G) Join / (S,G,RP-bit) Prune message for 239.XXX.XXX.176
00:51:37: PIM(0): Insert (*,239.XXX.XXX.176) join in nbr 10.112.55.9's queue
00:51:37: PIM(0): Building Join/Prune packet for nbr 10.112.55.9
00:51:37: PIM(0):  Adding v2 (10.100.1.9/32, 239.XXX.XXX.176), WC-bit, RPT-bit, S-bit Join
00:51:37: PIM(0): Send v2 join/prune to 10.112.55.9 (Vlan55)
00:51:38: PIM(0): Check RP 10.100.1.9 into the (*, 239.XXX.XXX.145) entry
00:51:38: PIM(0): Building Triggered (*,G) Join / (S,G,RP-bit) Prune message for 239.XXX.XXX.145
00:51:38: PIM(0): Insert (*,239.XXX.XXX.145) join in nbr 10.112.55.9's queue
00:51:38: PIM(0): Building Join/Prune packet for nbr 10.112.55.9
00:51:38: PIM(0):  Adding v2 (10.100.1.9/32, 239.XXX.XXX.145), WC-bit, RPT-bit, S-bit Join
00:51:38: PIM(0): Send v2 join/prune to 10.112.55.9 (Vlan55)
00:51:39: PIM(0): Check RP 10.100.1.9 into the (*, 239.XXX.XXX.162) entry
00:51:39: PIM(0): Building Triggered (*,G) Join / (S,G,RP-bit) Prune message for 239.XXX.XXX.162
00:51:39: PIM(0): Insert (*,239.XXX.XXX.162) join in nbr 10.112.55.9's queue
00:51:39: PIM(0): Building Join/Prune packet for nbr 10.112.55.9
00:51:39: PIM(0):  Adding v2 (10.100.1.9/32, 239.XXX.XXX.162), WC-bit, RPT-bit, S-bit Join
00:51:39: PIM(0): Send v2 join/prune to 10.112.55.9 (Vlan55)

00:51:39: PIM(0): Received RP-Reachable on Vlan55 from 10.100.1.9
00:51:39: PIM(0): Received RP-Reachable on Vlan55 from 10.100.1.9
00:51:39:      for group 239.XXX.XXX.162

00:51:46: PIM(0): Received RP-Reachable on Vlan55 from 10.100.1.9
00:51:46: PIM(0): Received RP-Reachable on Vlan55 from 10.100.1.9
00:51:46:      for group 239.XXX.XXX.91

00:51:54: PIM(0): Received RP-Reachable on Vlan55 from 10.100.1.9
00:51:54: PIM(0): Received RP-Reachable on Vlan55 from 10.100.1.9
00:51:54:      for group 239.XXX.XXX.50

00:51:59: PIM(0): Received RP-Reachable on Vlan55 from 10.100.1.9
00:51:59: PIM(0): Received RP-Reachable on Vlan55 from 10.100.1.9
00:51:59:      for group 239.XXX.XXX.165

 

Перед тем как все устаканивается:

00:53:36: PIM(0): Send v2 join/prune to 10.112.55.9 (Vlan55)
00:53:37: PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 239.XXX.XXX.145
00:53:37: PIM(0): Insert (*,239.XXX.XXX.145) join in nbr 10.112.55.9's queue
00:53:37: PIM(0): Building Join/Prune packet for nbr 10.112.55.9
00:53:37: PIM(0):  Adding v2 (10.100.1.9/32, 239.XXX.XXX.145), WC-bit, RPT-bit, S-bit Join
00:53:37: PIM(0): Send v2 join/prune to 10.112.55.9 (Vlan55)
00:53:38: PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 239.XXX.XXX.162
00:53:38: PIM(0): Insert (*,239.XXX.XXX.162) join in nbr 10.112.55.9's queue
00:53:38: PIM(0): Building Join/Prune packet for nbr 10.112.55.9
00:53:38: PIM(0):  Adding v2 (10.100.1.9/32, 239.XXX.XXX.162), WC-bit, RPT-bit, S-bit Join
00:53:38: PIM(0): Send v2 join/prune to 10.112.55.9 (Vlan55)


00:55:34: PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 239.XXX.XXX.165
00:55:34: PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 239.XXX.XXX.145
00:55:35: PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 239.XXX.XXX.162
00:56:30: PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 239.XXX.XXX.50
00:56:31: PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 239.XXX.XXX.175
00:56:32: PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 239.XXX.XXX.165
00:56:33: PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 239.XXX.XXX.145
00:56:33: PIM(0): Building Periodic (*,G) Join / (S,G,RP-bit) Prune message for 239.XXX.XXX.162

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

survivor   

survivor
Опубликовано · Жалоба

Вообщем если опустить детали...

PIM каталист отправляет наверх к точке рандеву "S-bit Join" даже после того как от этого канала уже отписались. Только спустя несколько минут - он отправляет наверх "S-bit Prune" и все нормализуется. Что с этим делать пока не знаю, но так оставлять нельзя конечно.

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

survivor   

survivor
Опубликовано · Жалоба

Нашел проблему... в сторону end-юзера висел безобидный ACL который оказался не таким уж безобидным, так как фильтровал исходящий от абонента igmp на 224.0.0.0/24. Самое веселое - то, что один и тот же каталист, отлавливая на L2 igmp запросы прекрасно понимал что данный абонент отписался от канала, и при этом этот же каталист из-за acl'а на interface vlan не видел leave и ПОЭТОМУ не отправлял prune наверх, до тех пор пока не приходила пора отправить periodic prune, в котором он благополучно отказывался (так как знал об этом) от канала, от которого отказался ранее абонент.

Все, теперь, все работает как надо )) Спасибо всем за поддержку!

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

s.lobanov   

s.lobanov
Опубликовано · Жалоба

а вот если бы бабушка была дедушкой сразу бы показали конфиг, то кто-нибудь обязательно это заметил и не пришлось бы снимать дебаги

Поделиться сообщением

Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.

×
Подписчики 0
Перейти к списку тем Активное оборудование Ethernet, IP, MPLS, SDN/NFV...