MAXmks Опубликовано 30 августа, 2012 (изменено) · Жалоба Всем здрасте. Вообще письмо писал в тех саппорт, решил продублировать на форум, для обсуждения, ну и может кому будет полезно. 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
triam Опубликовано 31 августа, 2012 (изменено) · Жалоба Честно говоря, для нормально\масштабируемой и хорошо диагностируемой сети с мультикастом лучше использовать L3 линки и PIM =) Трабл 1 Должен решаться, либо отключением из STP клиентских портов, либо firewall filter применяйте =) С Траблом номер два надо детально разбираться. Думаю можно решить. Juniper специально не блочит opt82 =) Трабл-3 лечится изменением дефалтных значений на 65-й Трабл-4 Ну STP - зло =) Хотя конечно надо разбираться. Для начала надо взять рекомендуемый JTAC софт 11.4R2.14. Можно и 11.4R4 =) Изменено 31 августа, 2012 пользователем triam Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
uxcr Опубликовано 31 августа, 2012 · Жалоба Честно говоря, для нормально\масштабируемой и хорошо диагностируемой сети с мультикастом лучше использовать L3 линки и PIM =) Трабл 1 Должен решаться, либо отключением из STP клиентских портов, либо firewall filter применяйте =) Топикстартер не указал, но я сомневаюсь что клиентским портам позволено влиять на STP. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Tima Опубликовано 1 сентября, 2012 · Жалоба У нас большая плоская L2 сеть. Вы будете страдать постоянно, особенно, учитывая, что: Т.к. сеть большая, то приходят TCN регулярно, тв не возможно смотреть. Регулярность TCN не должна прямо зависеть от размера сети, а от ее стабильности. Почему у вас регулярно происходят TCN? Межузловые линки флапают регурялно? При таких условиях у вас всегда будет все разваливаться. Или оконечные порты генерируют TCN? Значит они неправильно настроены. Прошу помочь решить эту проблему, т.к. не можем поставить железку всеть. Я бы на вашем месте перепроектировал сеть на L3. Это огромная работа, но гора проблем сразу отпадет. Или хотя бы разберитесь почему у вас пачками ходят TCN'ы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MAXmks Опубликовано 1 сентября, 2012 (изменено) · Жалоба Спасибо, за обсуждения. Честно говоря, для нормально\масштабируемой и хорошо диагностируемой сети с мультикастом лучше использовать 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
triam Опубликовано 1 сентября, 2012 · Жалоба Ну и как я понял, в juniper EX 3300 нет механизма, как в циске no ip igmp-snooping tcn flood ? Нет такого нет механизма ( на сколько мне известно) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Дегтярев Илья Опубликовано 1 сентября, 2012 · Жалоба Тоже вопрос достойный отдельного обсуждения. Совсем недавно фильтровали полностью bpdu на абонентских портах, но через некоторое время наc начали парить вообще не логичные логи link-flap, голову сломали как так может быть (если смотреть на топологию и на порты между которыми мак флапал) пока не повырезал нафиг портфасты и ,бпду-фильтры. МАК-флапы перестали беспокоить но TCN приходят теперь в среднем каждые 2 минуты. К тому же многим абонентам даем транки. Короче дилема, зафильтровать BPDU Не проблема, но запарят петли и линк флапы, избавится от петель и линк-флапов тоже не сложно, но достанут TCN. Поэтому выход, который я вижу это L3 сегментация. Ну вот откуда идут такие криворукие сетестроители? Откройте любой ман от циски - portfast на пограничных портах обязателен! Можно и +bpduguard, т.е полное отключение stp для этого порта. А вот от петель со стороны абонента настраивайте dhcp snooping (с ограничение несколько запросов/сек) + DAI + IP Source guard. Абонентское оборудование никак не должно влиять на вашу работу с другими абонентами. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MAXmks Опубликовано 1 сентября, 2012 (изменено) · Жалоба Ну вот откуда идут такие криворукие сетестроители? У Вас спросить надо, Вам виднее. Откройте любой ман от циски - 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Megas Опубликовано 1 сентября, 2012 · Жалоба http://www.cisco.com/en/US/docs/switches/lan/catalyst6500/ios/12.2SX/best/practices/recommendations.html#wp1061957 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MAXmks Опубликовано 1 сентября, 2012 · Жалоба http://www.cisco.com....html#wp1061957 Вот. Configure STP PortFast only on ports that are connected to end host devices that terminate VLANsand 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 toanother 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 Это то что каталист пишет, хочу напомнить ))) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
s.lobanov Опубликовано 1 сентября, 2012 · Жалоба http://www.cisco.com....html#wp1061957 Вот. Configure STP PortFast only on ports that are connected to end host devices that terminate VLANsand 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 toanother 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MAXmks Опубликовано 4 сентября, 2012 · Жалоба По поводу трабла с интероперабилити Option 82 juniper и cisco нашел вот такой спор http://habrahabr.ru/post/113431/#comment_3646300 У кого-то есть положительная практика решения этого вопроса? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Mitya Опубликовано 5 сентября, 2012 · Жалоба >Как быть, везде выключать опцию 82, а если понадобится? Возможно это из-за giaddr = 0.0.0.0 Попробуйте на dhcp сервере: g ip dhcp relay information trust-all или if ip dhcp relay information trusted Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
MAXmks Опубликовано 5 сентября, 2012 · Жалоба Возможно это из-за 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; Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...