[janhelly]

Появилась проблема при приложенной снизу схеме подключения. На Роутере C в течении последнего дня наблюдаем загрузку CPU в 70%, в логах ничего нету, на роутерах B и A средняя загрузка 20% CPU.

Данная схема отображает только подключение роутеров B и C, на деле же таких роуетров несколько десятков, но проблема проявляется только на роутере C.

При этом на роутере C при выполнении команды

show igmp_snooping groups

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

 

Что пробовали делать:

• выключали pim
  
• отключали SNMP
  
• включали mirroring порта с extreme на роутер B - ничего подозрительного не обнаружили
  

Помогло только отключение PIM и IGMP SNOOPING одновременно, но мы не можем оставить наших абонентов без IPTV

 

На всех роутерах версия прошивки:

Firmware Version : Build 2.81.B03

DGS-3612G

 

 

Настройки:

 

Роутер А

create vlan iptv_uplink tag 10
create ipif iptv_uplink z.z.z.z/30 iptv_uplink state enable
create vlan to_router_b tag 21
create ipif to_router_b y.y.y.1/30 to_router_b state enable

enable igmp_snooping

enable pim
config pim ipif iptv_uplink state enable hello 30 jp_interval 1 mode sm dr_priority 1
config pim ipif to_router_b state enable hello 30 jp_interval 1 mode sm dr_priority 1
create pim static_rp group 234.0.0.0/8 rp z.z.z.z

 

Роутер B

create vlan from_router_a tag 21
create ipif from_router_a y.y.y.2/30 from_router_a state enable
create vlan ism_to_abon tag 2004
create ipif ism_to_abon a.a.0.0/16 ism_to_abon state enable

enable pim
config pim ipif from_router_a state enable hello 30 jp_interval 60 mode sm dr_priority 1
config pim ipif ism_to_abon state enable hello 30 jp_interval 60 mode sm dr_priority 1
create pim static_rp group 234.0.0.0/8 rp z.z.z.z

create ipmroute z.z.z.z/32 rpf_address y.y.y.1/30

config igmp ipif ism_to_abon version 3 query_interval 125 max_response_time 10 robustness_variable 2 state enable

enable igmp_snooping
config igmp_snooping vlan ism_to_abon state enable fast_leave disable
config igmp_snooping querier vlan ism_to_abon query_interval 125 max_response_time 10 robustness_variable 2 last_member_query_interval 1 state disable version 3

 

Роутер C полностью аналогичен роутеру B

 

Может быть кто то подскажет, как это можно диагностировать? Всплесков трафика в периоды высокой загрузки CPU обнаружено не было, с конфигами так же никто не работал.

 

PS: пока писали пост нагрузка сама по себе нормализовалась

[DVM-Avgoor]

Э. DGS-3612:

а) НЕ РОУТЕР

б) СВИТЧ ОН ТОЖЕ Г-НО

в) многие операции через CPU

г) уберите create pim static_rp group 234.0.0.0/8 rp z.z.z.z

Насчет "г" я не уверен, но статик группы почти во всех свитчах автоматом вызывают проваливание трафика в CPU. Даже у цисок.

Тем более зачем это? Имитация PIM-dense?

 

Метод 2 (кардинальный):

Убираете весь PIM & Snooping с 3612, и делаете мультикаст-роутером экстрим (хотя он тоже не подарок, но цпу там сочнее). У вас так или иначе везде на оконечке MVR (ISM VLAN), для чего эти танцы с PIM если можно просто пропустить влан до свитчей доступа?

[Butch3r]

на B и C у вас один и тотже влан или разные?

 

У меня высокий кпу на 3612 наблюдался вот в такой схеме: /24 сеть, в ней сидят l3 свичи. Между ними всеми поднят ospf и pim. 3120/3620 без проблем пережевывает такую схему, а у 3612 всё это дело валилось на cpu. Но у меня и схема другая: 3750->3612->3612. Так вот последнему постоянно было плохо. После того, как сделал /30 на каждый свич всё стало норм

[darkagent]

г) уберите create pim static_rp group 234.0.0.0/8 rp z.z.z.z

Насчет "г" я не уверен, но статик группы почти во всех свитчах автоматом вызывают проваливание трафика в CPU. Даже у цисок.

Тем более зачем это? Имитация PIM-dense?

Это аналог команды ip pim rp-address на кошках, и никакой нагрузки на cpu оно не добавляет само по себе. не путайте с igmp static join - вот там реальная задница.

Собсна задание static_rp необходимо там, где нет возможности получения rp mapping через bsr.

 

Больше всего меня смущает igmp v3, с которым у длинков вобще все печально, а на 3612 и того убого.

[DVM-Avgoor]

Это аналог команды ip pim rp-address на кошках, и никакой нагрузки на cpu оно не добавляет само по себе. не путайте с igmp static join - вот там реальная задница.

 

Понял, не имел дел с 3612/27 уже 5 лет, ошибся.

[DVM-Avgoor]

У 3612/27 тупейшая архитектура местами, особенно с широковещательными пакетами. В моменты таких всплесков поглядите ARP-таблицу ism_to_abon. Все-таки /16 очень нехилая маска, может кто-то зафлудил, и свитчик потерял способности адекватно мыслить.

[MaLblsH]

Э. DGS-3612:

а) НЕ РОУТЕР

б) СВИТЧ ОН ТОЖЕ Г-НО

в) многие операции через CPU

г) уберите create pim static_rp group 234.0.0.0/8 rp z.z.z.z

Насчет "г" я не уверен, но статик группы почти во всех свитчах автоматом вызывают проваливание трафика в CPU. Даже у цисок.

Тем более зачем это? Имитация PIM-dense?

 

Метод 2 (кардинальный):

Убираете весь PIM & Snooping с 3612, и делаете мультикаст-роутером экстрим (хотя он тоже не подарок, но цпу там сочнее). У вас так или иначе везде на оконечке MVR (ISM VLAN), для чего эти танцы с PIM если можно просто пропустить влан до свитчей доступа?

 

Вот ну не совсем я с Вами согласен по а) и б): всё таки с обязанностями он справляется. Не всё конечно гладко, но справляется. Стараемся больше 1К абонентов не держать на 36-ой серии (новую 3620 пока не тестировали). В любом случае 12-ые будут в относительно скором времени поменяны на 27.

 

По г) - собственно это в результате того, что мы не могли организовать mBGP с IPTV-uplink'ом, поэтому пришлось статикой создать.

 

По методу 2 - к этому всё идёт. Медленно, но уверенно.

Как минимум мысли есть перекинуть PIM на Extreme, а с него уже ISM на доступ, даже тему создавал. Изначально (08 или 09 год) схема "родилась" на форуме Dlink, в которой сотрудник Руслан Бигаров, используя свои старые тестовые схемы, помогал настроить. В итоге имеем то, что имеем :) Это пока... руки не дошли до перепрошить Extreme и скормить ему Core лицензию.

 

на B и C у вас один и тотже влан или разные?

 

У меня высокий кпу на 3612 наблюдался вот в такой схеме: /24 сеть, в ней сидят l3 свичи. Между ними всеми поднят ospf и pim. 3120/3620 без проблем пережевывает такую схему, а у 3612 всё это дело валилось на cpu. Но у меня и схема другая: 3750->3612->3612. Так вот последнему постоянно было плохо. После того, как сделал /30 на каждый свич всё стало норм

 

В нашей схемы VLAN'ы до B и C разные.

p.s. вообще это уже второй или третий случай, и пока только 3612G страдали.

 

У 3612/27 тупейшая архитектура местами, особенно с широковещательными пакетами. В моменты таких всплесков поглядите ARP-таблицу ism_to_abon. Все-таки /16 очень нехилая маска, может кто-то зафлудил, и свитчик потерял способности адекватно мыслить.

 

Коллега забыл уточнить про ARP таблицу - она на всём устройстве занимала ~540 записей. Опять же по сравнению с другими не много. + пробовали чистить и её и даже FDB.

 

 

Больше всего меня смущает igmp v3, с которым у длинков вобще все печально, а на 3612 и того убого.

 

А вот кстати да. Сейчас проверил на остальных роутерах - там выставлена версия 2. Вчера уже глаза очевидного не видели :(

[DVM-Avgoor]

Вот ну не совсем я с Вами согласен по а) и б): всё таки с обязанностями он справляется. Не всё конечно гладко, но справляется. Стараемся больше 1К абонентов не держать на 36-ой серии (новую 3620 пока не тестировали). В любом случае 12-ые будут в относительно скором времени поменяны на 27.

 

 

Вы любите строить сети на EOL железе? Я понимаю что "научится готовить" можно любой продукт. Только вот в 3612/27 это никакого смысла не имеет. Он в зависимости от ревизии ведет себя совершенно непредсказуемо в разнообразных сценариях. Это плохой Л3-коммутатор и очень не выгодный Л2-коммутатор.

[MaLblsH]

Вот ну не совсем я с Вами согласен по а) и б): всё таки с обязанностями он справляется. Не всё конечно гладко, но справляется. Стараемся больше 1К абонентов не держать на 36-ой серии (новую 3620 пока не тестировали). В любом случае 12-ые будут в относительно скором времени поменяны на 27.

 

 

Вы любите строить сети на EOL железе? Я понимаю что "научится готовить" можно любой продукт. Только вот в 3612/27 это никакого смысла не имеет. Он в зависимости от ревизии ведет себя совершенно непредсказуемо в разнообразных сценариях. Это плохой Л3-коммутатор и очень не выгодный Л2-коммутатор.

 

Я не пытаюсь доказать, что Dlink классное оборудование и не призываю к его повсеместному использованию.

Деньги на оборудование я достаю не из своего кармана и работаю с тем, что есть.

Устраивать рекурсию

 

- Dlink *авно

- Но работает

- Но при это всё равно *авно

- Да, но работает

...

 

тоже не вижу смысла ибо само по себе название Dlink стало уже почти что именем нарицательным :)

 

А с заменой 12 на 27 я всё же погорячился - 27ые и в продаже найти тяжело. Я конечно же хотел написать про 3620-28.

[DVM-Avgoor]

Я бы на вашем месте попробовал 3610-26, может сильно удивить.

 

ПС. Я не говорил "dlink говно", я сказал 3612/27 - говно. Он конкретно вот говно, не смотря на то что местами работает. Мы от них массово избавлялись 3-4 года назад, ввиду разнообразия особенностей с Л3 и даже Л2.

[MaLblsH]

Я бы на вашем месте попробовал 3610-26, может сильно удивить.

 

ПС. Я не говорил "dlink говно", я сказал 3612/27 - говно. Он конкретно вот говно, не смотря на то что местами работает. Мы от них массово избавлялись 3-4 года назад, ввиду разнообразия особенностей с Л3 и даже Л2.

 

3610 лежит у нас до сих пор. Мы его купили году так в 2009 в качестве ядра сети, где он и простоял около года и довольно хорошо себя вёл. Не подружился он у нас с CWDM-ными модулями, в то время как 3627 скушал и не подавился. Времени экспериментировать не было, оставили 27. Теперь Extreme.

[DVM-Avgoor]

3610 лежит у нас до сих пор. Мы его купили году так в 2009 в качестве ядра сети, где он и простоял около года и довольно хорошо себя вёл. Не подружился он у нас с CWDM-ными модулями, в то время как 3627 скушал и не подавился. Времени экспериментировать не было, оставили 27. Теперь Extreme.

 

 

У мен CWDM модули работают в 3610.