Доброго времени суток.
Подскажите пожалуйста, нет ли в DES-3828 ограничения на максимальное количество конфигурируемых точек встречи (речь о протоколе PIM/SM)?

После некоторого времени прыжков с бубном возле очередного подключенного к данному коммутатору сервера, всё больше утверждаюсь в мысли, что коммутатор просто-напросто не позволяет создать более десяти записей в таблице pim rpset:

Одиннадцатая запись не желает появляться. Даже попытка создать её статически не приводит к положительному результату (хотя никакого сообщения об ошибке не появляется):


Но запись в таблице не создаётся:

Т.е. как было 10 записей, так 10 и осталось

Инфо о коммутаторе:
Boot PROM Version : Build 0.00.008
Firmware Version : Build 4.05.B09
Hardware Version : 1A1

По поводу кол-ва записей RP я уточню. Как только будут новости сразу сообщу. В любом случае советую использовать прошивку которую я Вам выслал как последнюю стабильную в плане L3.

Подскажите пожалуйста:
1) Зачем вы делаете столько статических RP на одном коммутаторе?
2) Зачем вообще создали столько групп?

2 Magnum72
Если вы повнимательней глянете на приведённый лог, вы увидите, что группы как раз не статические, а совсем даже наоборот. Ну что ж поделать, если в сети сейчас уже имеется 10 PIM-маршрутизаторов :)
А вот с одиннадцатым незадача - не "вливается" в коллектив :)
Вот просто хотелось поинтересоваться, не есть ли корень проблемы в оганичении на количество rendez-vous points.

2 Demin Ivan
Спасибо за прошивочку. Сегодня вечерком начну её тестировать на своих студентах. Надеюсь, что эта бета ещё более стабильная, чем та, что работает у нас сейчас, и эксперимент не станет кровавым :))

Упс Ну хорошо, а зачем в сети 10 PIM маршрутизаторов? на сколько я понимаю лучшее место для RP PIM это место самое близкое к разделению потоков, а не к источнику мультикаста?
У меня в сети при 20 3627G в PIM только один (к которому у каждого
есть линк) является RP и BSR, остальные получают группы от него. даже через чур получают... сволочи... мультикаст валится в их сторону даже если они его не просят, при этом если на каком нибудь из 20 3627G нет поднятых каких либо групп он не знает что делать с этим мультикастом и начинает втуплять до 30%. есть предложение посадить каждый в совй влан и наплодить на центральном 20 интерфейсов, но жалко блин его маршрутизацией нагружать.

Ну так вот вы и сами практически ответили на свой же вопрос :))
То "безобразие", которое я наваял - не от хорошей жизни.
Так или иначе всё это есть workarounds по проблемам софта DES-3828. Слава богу, что сейчас его firmware уже стала чертовски хороша, а вот к примеру с третьим релизом (3.0.57) попытка создать единственную точку встречи в самом коммутаторе (а уж поверьте, именно с этого я и начинал) приводила к загрузке его CPU на 100% уже при маршрутизации потока всего-то около 1000 мультикаст-пакетов в секунду.
Сейчас же работает всё просто идеально. 60 телевизионных и 30 радио-каналов мультикастом. СтУденты давольны. Всё только по запросу. И CPU практически незагружен.

Конечно, если 10 rps для DES3828 - это аппаратный предел, то буду думать над очередным workaround'ом. Мне не привыкать :))

Это грабли на которые я еще не наступил У меня ситуация похуже, все понятно изза чего но не понятно как красиво лечить.

Допустим есть 3 DGS3627G

[===A===]
| |
[==B==] [==C==]
b1 c1

А - PR
B,C - подключены к нему выполняют роль L2 агрегации
b1,c1 - клиенты в соответствующих клиентских ipif на B,C
Все коммутаторы находятся в одном системном влане.

ситуация следующая: A является BSR и единственным RP с группой 234.1.1.1/24

Загрузка на всех коммутаторах 0 до тех пор пока например на B не появляется клиент смотрящий канал 234.1.1.129, сразу после этого на коммутаторе С появляется загрузка ровно 30%, и держится до тех пор пока на С не появится клиент который будет смотреть тот же канал что и клиент b1.

т.е. когда A кидает поток в сторону B он зачем то кидает его и в сторону С, (вообще то зачем кидает тоже понятно) в виду того что в порт на коммутаторе A в который подключен С становится Router Port.
Все это собственно логично, но непонятно какого фига коммутатор С не находя у себя IGMP групп начинает тупить, и как сделать чтобы он этот трафик тупо дропал.

Есть еще вариант предложенный китайцами: сделать отдельные вланы и интерфейсы между A-B и A-C, тогда проблема железно решается, но я попадаю на маршрутизацию локального трафика.

Что я делал: пробовал разбить подсеть 234.1.1.0/24 на более мелкие сети и анонсить группы отдельно, после 5 групп коммутатору А поплохело да и не помогло собственно
Пробовал прописать все что можно статикой, да и все остальное тоже пробовал, даже то что заведомо не должно было помочь, так для успокоения.

Собственно нужны просто идеи я бы попробовал, а то у меня фантазия кончилась...
ЗЫ Может я банально подсеть фиговую выбрал?

А версия прошивки у вас сейчас какая?

Build 2.40-B72

2 Magnum72
Ага, ясна-панятна :))
К сожалению, у меня пока в арсенале нету DGS36xx, поэтому абсолютно точного рецепта не дам, но ситуация мне знакома. Очччень хорошо знакома :))

Значит так:
1) если в текущем функционале DGS3627G имеется router_port_forbidden, то ставьте его на те порты коммутатора A (по вашей схеме), которые смотрят в сторону B и C
2) если router_port_forbidden отсутствует, тогда такой "хитрый ход лошадью": на коммутаторе А включаете IGMP_snooping, глобально и в том VLAN'e, в котором у вас висят порты, смотрящие в сторону B и C, и в этом же VLAN'e на коммутаторе A рисуете нечто типа:
config igmp_snooping <vlan_name> router_timeout 1
Тем самым уменьшаете время жизни непрошенных роутер-портов до одной секунды.
Конечно, полностью вы проблему не решите, но существенное облегчение наступить непременно должно.

Владимир пришлите пожалуйста по проблеме с RP графическую схему сети с указанием портов подключения и конфиги устройств в топологии.

это есть такой функционал, проблема в том что у мну там OSPF ходит и вроде как когда я включал все это дело у меня оно немного падало или я включал это на аплинках B и C ....

Попробуйте пожалуйста прошивку которую я вам выслал.

Это Вы к кому обращались? если ко мне то ничего не пришло

Выслал повторно.