[MAXmks]

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

 

Ex-3300-24T

Junos 12.1R2.9

 

Трабл 1 (основной и очень важный).

IGMP snooping + MSTP + Topology Change (TCN)

 

У нас большая плоская L2 сеть.

root Catalyst 6506e

везде конфиг следующий

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

 

 

в instance 3 vlan 96-129, 151-199 вланы домашних сетей, в которых

кроме всего прочего работает IGMP Snooping для iptv

 

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

микрорайоне.

 

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

 

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

 

Смысл такой, что когда в STP меняется топология, stp root шлет всем

коммутаторам TCN, после которого коммутатор чистит CAM таблицу, и, что

самое главное для нас, igmp snooping флудит всем что у него есть во все

порты в течении некоторого времени.

 

Так вот в cisco есть механизм, для того что бы менять это поведение, либо просто запрещать его

http://www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.1/12ew/configuration/guide/multi.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, за портом 19 на

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 мин) провозглашает себя

igmp-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

пришли с него и на него указывали, хотя это явно было не так. А сам

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

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

 

 

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

Изменено 30 августа, 2012 пользователем MAXmks

[triam]

Честно говоря, для нормально\масштабируемой и хорошо диагностируемой сети с мультикастом лучше использовать L3 линки и PIM =)

Трабл 1

Должен решаться, либо отключением из STP клиентских портов, либо firewall filter применяйте =)

С Траблом номер два надо детально разбираться. Думаю можно решить. Juniper специально не блочит opt82 =)

Трабл-3 лечится изменением дефалтных значений на 65-й

Трабл-4 Ну STP - зло =) Хотя конечно надо разбираться.

 

Для начала надо взять рекомендуемый JTAC софт 11.4R2.14. Можно и 11.4R4 =)

Изменено 31 августа, 2012 пользователем triam

[uxcr]

Честно говоря, для нормально\масштабируемой и хорошо диагностируемой сети с мультикастом лучше использовать L3 линки и PIM =)

Трабл 1

Должен решаться, либо отключением из STP клиентских портов, либо firewall filter применяйте =)

 

Топикстартер не указал, но я сомневаюсь что клиентским портам позволено влиять на STP.

[Tima]

У нас большая плоская L2 сеть.

 

 

Вы будете страдать постоянно, особенно, учитывая, что:

 

 

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

 

 

Регулярность TCN не должна прямо зависеть от размера сети, а от ее стабильности.

Почему у вас регулярно происходят TCN?

Межузловые линки флапают регурялно? При таких условиях у вас всегда будет все разваливаться.

Или оконечные порты генерируют TCN? Значит они неправильно настроены.

 

 

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

сеть.

 

 

Я бы на вашем месте перепроектировал сеть на L3. Это огромная работа, но гора проблем сразу отпадет.

Или хотя бы разберитесь почему у вас пачками ходят TCN'ы.

[MAXmks]

Спасибо, за обсуждения.

Честно говоря, для нормально\масштабируемой и хорошо диагностируемой сети с мультикастом лучше использовать L3 линки и PIM =)

 

Я бы на вашем месте перепроектировал сеть на L3. Это огромная работа, но гора проблем сразу отпадет.

 

Да, все верно, именно для этого и был взят Jun. Сейчас ожидаю advanctd feature лицензию (pim, igmp, routing) и буду думать как это делать. Это будет первый сегмент переведенный на L3 с ядром. У нас все осложняется неоднородностью услуг, есть линковые сетки для юрлиц, есть L2 VPN. Так же пока не понял как с брасами поступать, видимо хорошо, что в свое время решил не один большой и сильный а много 7201, т.к. сейчас понимаю, что часть надо будет из ядра переносить в распределение (существуют ли механизмы типа pppoe helper пока не знаю). Пока думаю, что в L3 сегменте надо изолировать виланы физиков с pppoe, dhcp и igmp-snooping, виланы юриков с pppoe, а виланы с линковыми сетками и l2 vpn все также терминировать в ядре. Сложность в том как все это сделать прозрачно для нескольких тысяч абонентов с voip и телевидением.

 

Трабл 1

Должен решаться, либо отключением из STP клиентских портов,

STP - зло =)

Топикстартер не указал, но я сомневаюсь что клиентским портам позволено влиять на STP.

Регулярность TCN не должна прямо зависеть от размера сети, а от ее стабильности.

Почему у вас регулярно происходят TCN?

Межузловые линки флапают регурялно? При таких условиях у вас всегда будет все разваливаться.

Или оконечные порты генерируют TCN? Значит они неправильно настроены.

Или хотя бы разберитесь почему у вас пачками ходят TCN'ы.

 

Тоже вопрос достойный отдельного обсуждения. Совсем недавно фильтровали полностью bpdu на абонентских портах, но через некоторое время наc начали парить вообще не логичные логи mac-flap, голову сломали как так может быть (если смотреть на топологию и на порты между которыми мак флапал) пока не повырезал нафиг портфасты и ,бпду-фильтры. МАК-флапы перестали беспокоить но TCN приходят теперь в среднем каждые 2 минуты. К тому же многим абонентам даем транки. Короче дилема, зафильтровать BPDU Не проблема, но запарят петли и линк флапы, избавится от петель и линк-флапов тоже не сложно, но достанут TCN. Поэтому выход, который я вижу это L3 сегментация.

 

К стати вот насущный вопрос по MSTP. Если TCN пришел в одном определенном instance (как правило он пройдет и в MST0) будет ли это означать mac-flap и TCN-flood в другом instance? Т.е. стоит ли увеличивать количество instace (как бы сегментировать), что бы уменьшить количество TCN в отдельном взятом instace, либо это даст обратный эффект?

 

либо firewall filter применяйте =)

 

Страшно ))) Вы же сами сказали, что STP - зло )) Что будет если повырезать из STP TCN bpdu и оставить только configuration bpdu, как это все работать будет? Не удивит ли меня потом?

 

Ну и как я понял, в juniper EX 3300 нет механизма, как в циске no ip igmp-snooping tcn flood ?

Изменено 13 ноября, 2013 пользователем MAXmks

[triam]

Ну и как я понял, в juniper EX 3300 нет механизма, как в циске no ip igmp-snooping tcn flood ?

Нет такого нет механизма ( на сколько мне известно)

[Дегтярев Илья]

Тоже вопрос достойный отдельного обсуждения. Совсем недавно фильтровали полностью bpdu на абонентских портах, но через некоторое время наc начали парить вообще не логичные логи link-flap, голову сломали как так может быть (если смотреть на топологию и на порты между которыми мак флапал) пока не повырезал нафиг портфасты и ,бпду-фильтры. МАК-флапы перестали беспокоить но TCN приходят теперь в среднем каждые 2 минуты. К тому же многим абонентам даем транки. Короче дилема, зафильтровать BPDU Не проблема, но запарят петли и линк флапы, избавится от петель и линк-флапов тоже не сложно, но достанут TCN. Поэтому выход, который я вижу это L3 сегментация.

 

Ну вот откуда идут такие криворукие сетестроители?

Откройте любой ман от циски - portfast на пограничных портах обязателен! Можно и +bpduguard, т.е полное отключение stp для этого порта.

А вот от петель со стороны абонента настраивайте dhcp snooping (с ограничение несколько запросов/сек) + DAI + IP Source guard.

Абонентское оборудование никак не должно влиять на вашу работу с другими абонентами.

[MAXmks]

Ну вот откуда идут такие криворукие сетестроители?

У Вас спросить надо, Вам виднее.

 

Откройте любой ман от циски - portfast на пограничных портах обязателен!

Ссылку плизз на такой ман от циски, где я увижу что что portfast обязателен.

 

Можно и +bpduguard

 

Нелья, т.к. саппорт только и будет обьяснять абоненту какого его порт ушел в errdisible. У нас IPTV, у абона, как правило, есть девайс, который может отправить bpdu.

 

bpduguard, т.е полное отключение stp для этого порта

 

Отключение stp это скорее bpdufilter, а bpduguard это запрет на доступ в сеть девайсу с stp.

 

А вот от петель со стороны абонента настраивайте dhcp snooping (с ограничение несколько запросов/сек) + DAI + IP Source guard.

 

Спасибо, используем там где можем. Только к сожалению в 99% случаев на доступе у нас 2950, а на распределении 2970G, которые ни DAI ни IPSG не поддерживают.

 

Абонентское оборудование никак не должно влиять на вашу работу с другими абонентами.

 

Согласен, но, исходя из имеющихся услуг и оборудования, решения у меня пока нет. Посоветуете что-то?

Изменено 1 сентября, 2012 пользователем MAXmks

[Megas]

http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/best/practices/recommendations.html#wp1061957

[MAXmks]

http://www.cisco.com....html#wp1061957

 

Вот.

Configure STP PortFast only on ports that are connected to end host devices that terminate VLANs

and from which the port should never receive STP BPDUs, such as:

– Workstations

– Servers

– Ports on routers that are not configured to support bridging

 

On any trunk port that connects to a device that propagates VLANs (for example, a port that connects to

another switch or a port that connects to a router that is configured to support bridging), disable

STP PortFast

 

У нас второй случай, т.к. у абона либо свитч, либо какой-нить wifi с lan портами, которые он с удовольствием периодически соединяет с соседскими, судя по тому как ругается dhcp-snoop в лог о мак-флаппинге.

 

%Warning: portfast should only be enabled on ports connected to a single

host. Connecting hubs, concentrators, switches, bridges, etc... to this

interface when portfast is enabled, can cause temporary bridging loops.

Use with CAUTION

 

Это то что каталист пишет, хочу напомнить )))

[s.lobanov]

http://www.cisco.com....html#wp1061957

 

Вот.

Configure STP PortFast only on ports that are connected to end host devices that terminate VLANs

and from which the port should never receive STP BPDUs, such as:

– Workstations

– Servers

– Ports on routers that are not configured to support bridging

 

On any trunk port that connects to a device that propagates VLANs (for example, a port that connects to

another switch or a port that connects to a router that is configured to support bridging), disable

STP PortFast

 

У нас второй случай, т.к. у абона либо свитч, либо какой-нить wifi с lan портами, которые он с удовольствием периодически соединяет с соседскими, судя по тому как ругается dhcp-snoop в лог о мак-флаппинге.

 

%Warning: portfast should only be enabled on ports connected to a single

host. Connecting hubs, concentrators, switches, bridges, etc... to this

interface when portfast is enabled, can cause temporary bridging loops.

Use with CAUTION

 

Это то что каталист пишет, хочу напомнить )))

 

Ну отлично, только это относится к КСПД, а не к ISP. С точки зрения ISP там клиент, который может мусорить всякими bpdu и т.п. и весь этот мусор надо дропнуть.

 

Вообще говоря, полноценное решение от петель, мак-флаппинга/спуфингов и т.п. это C-Vlan + ISG-like BRAS(в котором всё "пляшет" от сессии). В S-Vlan вам нужно что-то с этими бяками делать(и чем больше у вас L2-сегмент, тем больше проблем), стандартные приёмы это порт-изоляция, snooping, dai, source guard(это фактически динамический acl), всяческие static acl(в явном и неявном виде), storm-control. Всё что работает в ASIC можете смело использовать, а вот такие вещи как dhcp snooping,dai и ip source guard могут вам доставить больше проблем, чем пара кул-хацкеров, если софт на ваших свитчах кривой или нет возможности защитить cpu

[MAXmks]

По поводу трабла с интероперабилити Option 82 juniper и cisco нашел вот такой спор http://habrahabr.ru/post/113431/#comment_3646300

 

У кого-то есть положительная практика решения этого вопроса?

[Mitya]

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

Возможно это из-за giaddr = 0.0.0.0

Попробуйте на dhcp сервере:

g ip dhcp relay information trust-all

или

if ip dhcp relay information trusted

[MAXmks]

Возможно это из-за giaddr = 0.0.0.0

Попробуйте на dhcp сервере:

g ip dhcp relay information trust-all

или

if ip dhcp relay information trusted

 

Спасибо!

Правда протестировать не успел, сделал L3 и поднял на Джуне свой dhcp сервер. Теперь клиенты, которые сидят за 2950 включенный напрямую в untrusted порт Джуна настройки по DHCP получают. Но на Джуне не заполняется таблица dhcp snooping binding и не собирается статистика.

 

...@j-dong> show dhcp snooping binding

 

{master:0}

...@j-dong> show dhcp snooping statistics

DHCP Snoop Persistence statistics

Successful Remote Transfers: 0 Failed Remote Transfers: 0

Successful Record Reads : 0 Failed Record Reads : 0

Successful Record Writes : 0 Failed Record Writes : 0

 

Нашел аналогичную команду для того что бы доверять пакетам option 82 с giaddr 0, но результат следующий:

///@j-dong# set trust-option-82

 

{master:0}[edit forwarding-options dhcp-relay overrides]

///@j-dong# show

##

## Warning: statement ignored: unsupported platform (ex3300-24t)

##

trust-option-82;