Всем здрасте. Вообще письмо писал в тех саппорт, решил продублировать на форум, для обсуждения, ну и может кому будет полезно.

Ex-3300-24T
Junos 12.1R2.9

Трабл 1 (основной и очень важный).
IGMP snooping + MSTP + Topology Change (TCN)

У нас большая плоская L2 сеть.
root Catalyst 6606e
везде конфиг следующий
spanning-tree mst configuration
name ru.fcomm
revision 1
instance 1 vlan 1-79
instance 2 vlan 80-95, 130-150
instance 3 vlan 96-129, 151-199
instance 4 vlan 200-699
instance 5 vlan 700-799
instance 6 vlan 800-4094
!
spanning-tree mst 0-6 priority 0

в instance 3 vlan 96-129, 151-199 вланы домашних сетей, в которых
кроме всего прочего работает IGMP Snooping для iptv

Ex-3300-24T взяли на замену гиговому 3560 на аггрегацию в крупном
микрорайоне.

схема примерно такая 6506e-ex3300-2970/2960/2950(аггрегация более мелокго уровня)-2960/2950(доступ)

только пока для теста 3560 оставили и ex3300 поставили за ним.

Смысл такой, что когда в STP меняется топология, stp root шлет всем
коммутаторам TCN, после которого коммутатор чистит CAM таблицу, и, что
самое главное для нас, igmp snooping флудит всем что у него есть во все
порты в течении некоторого времени.

Так вот в cisco есть механизм, для того что бы менять время этого
флуда, либо просто запрещать его
http://www.cisco.com....html#wp1049520

мы просто на портах смотрящих в абонентскую сторону используем команду
no ip igmp snooping tcn flood.

Так вот в junos я не нашел не одного такого механизма.
Есть команда no-default-flooding в секции igmp-snooping, но она вообще
не документирована! Замучем гугл, я не нашел что она делает. А её
нахождение, или отстутствие в конфиге ни как не влияет на работу iptv.

вот конфиг

j-dong# show protocols igmp-snooping
vlan all {
robust-count 2;
no-default-flooding;
interface ge-0/0/23.0 {
multicast-router-interface;

В итоге, что бы я не делал, когда приходит TCN - iptv лагает. Т.к.
сеть большая, то приходят TCN регулярно, тв не возможно смотреть.

Т.к. на данный момент это наша основная услуга, ради которой мы
расширяем до 10G магистрали и пытаемся максимально повысить её
качество. То получается что juniper пока только ей вредит.

Прошу помочь решить эту проблему, т.к. не можем поставить железку в
сеть.

p.s. может флуд тут и не причем, но косяк точно в TCN, т.к. когда
поставил на вышестоящем каталисте bpdu-filter проблемы за джунипером
сразу прекратились. За любыми циско каталистами таких проблем нет.

Трабл 2.

Catalyst 6506e по совместительству является dhcp-сервером. Во всей
сети используется dhcp-snooping.

вот пример с каталиста

c2950-TKD14:4#show ip dhcp snooping
Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs:
100,110
Insertion of option 82 is enabled
Interface Trusted Rate limit (pps)
------------------------ ------- ----------------
FastEthernet0/1 no 150
FastEthernet0/2 no 150
FastEthernet0/3 no 150
FastEthernet0/4 no 150
FastEthernet0/5 no 150

на juniper

secure-access-port {
interface ge-0/0/19.0 {
no-dhcp-trusted;
}
interface ge-0/0/23.0 {
dhcp-trusted;
}
vlan 102 {
examine-dhcp;
}
vlan 109 {
examine-dhcp;
}
vlan 110 {
examine-dhcp;
}
vlan 99 {
examine-dhcp;
}

так вот, при схеме указанной при опсании трабла-1, за портом 23 на
juniper работает каталист 2950 и абоненты подключенные к нему не
получали настройки по dhcp пока на 2950 не было выключено добавление
опции 82 no ip dhcp snooping information option

c2950-office#show ip dhcp snooping
Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs:
97,102-103,110
Insertion of option 82 is disabled
Interface Trusted Rate limit (pps)
------------------------ ------- ----------------
FastEthernet0/1 no 30
FastEthernet0/2 no 30
FastEthernet0/3 no 30

после чего клиенты начали получать адреса. с
цисками/длинками/зайкселями такого не было.

Как быть, везде выключать опцию 82, а если понадобится?

Трабл-3

При включении в сеть, пока у Juniper сходятся все протоколы и
поднимаются все процессы, он на некоторое время (2-4 мин) провозглашает себя
шпьз-snooping mrouter-ом и querier-ом, что на это время приводит к
дикой деградации TV, т.к. в порт смотрящий в jun устремляется траффик
всех igmp групп. Пришлось на вышестоящем каталисте фильтровать
некоторые igmp-пакеты.

Трабл-4

Опять Spanning-tree

Когда происходт смена топологии, где-либо в сети. по всей сетке
пробегает TCN, так вот на цисках можно смотреть откуда он пришел
cat3560g-dong#sh spanning-tree detail | begin last
Number of topology changes 10560 last change occurred 00:00:19 ago
from GigabitEthernet0/24

Так удобно искать флапающие порты и глючащие железяки.

Так вот, когда мы ставили jun то все железяки думали что все TCN
пришли с него и на него указывали, хотя это явно было не так. А сам
джун показывал естественно на другие железяки. Опять же такое в первый
раз с цисками/длинками/зайкселями такого небыло.

Прошу помочь с решением выше указанных проблем и поделитсья опытом.