[vman]

Купили новый MikroTik CCR1072-1G-8S+ поставили на узел, несколько раз в неделю сам перезагружается.

В логах ошибок нет.

Прошивка последняя 6.36.3

Кто нибудь сталкивался с таким багом? Как его вылечить?

[nkusnetsov]

chaosduality, попробуйте сменить прошивку на ветку "bugfix only"

[SolarW]

Бодался с подобной проблемой на CCR1009 более года.

Когда проблема только проявилась (на актуальных на то время версиях ROS) было совсем плохо - роутер не перегружался а повисал, приходилось питание дергать.

Учитывая, что стоял он в ДЦ - было не совсем удобно, или сапорт напрягать или самому через полгорода бежать.

В конце концов пришлось поставить пингалку, которая дергала питание при повисании.

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

Потом, начиная уже с какой версии не помню, стало чуть легче - действительно роутер стал перегружаться внутренним ватчдогом.

Все это время проходило в бесплодной переписке с поддержкой - ничем помочь так и не смогли.

За это время на что только не грешил:

- OSPF

- петли в топологии

- RSTP в настройках бриджа

- и т.д и т.п...

Нашел даже последовательность действий которая позволяла воспроизвести проблему - надо было на периферии своей сети перезагрузить некий SXT работающий в режиме Р2Р, центральный маршрутизатор сдыхал через 1-2 секунды после подачи команды ребут на SXT.

 

Решение пришло неожиданно - по идее с этого или еще какого-то форума отключил MAC-сервер, ту штуку что позволяет телнетится на роутер по МАСу и т.д.

Оказалось этот сервис фильтруя все приходящие на интерфейс пакеты в поисках предназначенных для него иногда нарывался на такую комбинацию поступающих данных которая валила полностью сетевую подсистему.

 

Причем это свойство именно моделей CCR - у себя пробовал в 3-4 часа ночи, когда нагрузка на сеть минимальна, подменять CCR на RB2011 с аналогичной конфигурацией, на нем такого эффекта не было.

 

В общем отключение MAC-сервера на CCR в моем случае полностью решило проблему.

 

P.S. chaosduality, если поможет - отпишитесь пожалуйста.

Изменено 18 сентября, 2016 пользователем SolarW

[EShirokiy]

SolarW, случаем - это не связано с "зависанием" vlan-интерфейсов? Когда через виланы перестает ходить трафик, но стоит вилан вручную включить/выключить, как он сразу же начинает работать.

[SolarW]

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

С консоли частичное управление сохранялось но стоило дать какую-то "неудачную" команду (любую связанную с сетью или system reboot) как помирала и консоль тоже...

При этом присоединенные к нему другие устройства сигнализировали о том, что порт лег и неактивен.

[Saab95]

Это проблема не верного дизайна сети, когда сводят много всего по L2 в центр. Если так делаете, то на пограничном коммутаторе нужно фильтровать все лишнее, и тот же MAC-server можно закрыть.

[SolarW]

Это проблема не верного дизайна сети

А я то думал что сетевого стека (драйверов) под Tilera... ;-)

когда сводят много всего по L2 в центр

В пределах 2 десятков VLAN/EoIP через арендованные у других операторов каналы.

Местами эти каналы удлиняются с помощью радио.

До десятка мелких маршрутизаторов "на выносе", которые через вышеупомянутые каналы по OSPF видят центральный CCR (на некоторые по пару каналов приходит для надежности, в т.ч. EoIP через инет). Потребители с фиксированными айишниками за этими выносными маршрутизаторами.

В общем очень небольшая сеть, менее 40 точек потребления всего.

[vman]

Бодался с подобной проблемой на CCR1009 более года.

Когда проблема только проявилась (на актуальных на то время версиях ROS) было совсем плохо - роутер не перегружался а повисал, приходилось питание дергать.

Учитывая, что стоял он в ДЦ - было не совсем удобно, или сапорт напрягать или самому через полгорода бежать.

В конце концов пришлось поставить пингалку, которая дергала питание при повисании.

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

Потом, начиная уже с какой версии не помню, стало чуть легче - действительно роутер стал перегружаться внутренним ватчдогом.

Все это время проходило в бесплодной переписке с поддержкой - ничем помочь так и не смогли.

За это время на что только не грешил:

- OSPF

- петли в топологии

- RSTP в настройках бриджа

- и т.д и т.п...

Нашел даже последовательность действий которая позволяла воспроизвести проблему - надо было на периферии своей сети перезагрузить некий SXT работающий в режиме Р2Р, центральный маршрутизатор сдыхал через 1-2 секунды после подачи команды ребут на SXT.

 

Решение пришло неожиданно - по идее с этого или еще какого-то форума отключил MAC-сервер, ту штуку что позволяет телнетится на роутер по МАСу и т.д.

Оказалось этот сервис фильтруя все приходящие на интерфейс пакеты в поисках предназначенных для него иногда нарывался на такую комбинацию поступающих данных которая валила полностью сетевую подсистему.

 

Причем это свойство именно моделей CCR - у себя пробовал в 3-4 часа ночи, когда нагрузка на сеть минимальна, подменять CCR на RB2011 с аналогичной конфигурацией, на нем такого эффекта не было.

 

В общем отключение MAC-сервера на CCR в моем случае полностью решило проблему.

 

P.S. chaosduality, если поможет - отпишитесь пожалуйста.

 

Отключили mac сервер будем наблюдать

Хорошая идея спасибо

 

Еще есть странность:

Одно ядро постоянно загружено на 100% (см.рисунок)

Из нагрузки:

3 БГП поднято 2 из них ФВ

НАТ и PPPoE на 1000 учеток

Изменено 19 сентября, 2016 пользователем chaosduality

[SolarW]

Еще есть странность:

Одно ядро постоянно загружено на 100% (см.рисунок)

Какая-то из ваших задач не поддерживает распараллеливание по ядрам.

К примеру задача "Bandwitch test" только одно ядро умеет использовать.

С версии 6.0 до 6.36 поддержку многоядерности вроде как много куда добавили но еще не везде...

Это проблема не верного дизайна сети

Не могу не поделится еще одной проблемой "из-а неправильных настроек" ;-)

У меня в качестве удаленных маршрутизаторов трудятся много где RB750.

Учитывая что их задача простой роутинг по OSPF без NAT'а/FW/и т.д. - там где каналы в пределах 50-80 Мбит/с их вполне хватало.

Но вот пришел северный пушной зверек в виде внезапных повисаний и перезагрузок и к ним.

Изучение ситуации показало что проблеме подвержены все имеющиеся у меня подшефные маршрутизаторы с 32 мб оперативной памяти.

Устойчиво повторялась проблема на RB750, RB450, U-5HnD.

Проблема выглядела следующим образом - после перезагрузке на маршрутизаторе доступно 14 мб оперативки.

В течении 30-50 минут количество свободной оперативки плавно уменьшалось до 4-5 мб и маршрутизатор или повисал или уходил на перезагрузку.

В особо злостных случаях приходилось питание дергать (опять едучи через весь город в места где некак было это сделать удаленно).

 

 

На графике потребления памяти все наглядно видно - нарастание потребления, отказ отвечать на SNMP-запросы, загрузка процессора в 100%, перезагрузка, пошло все по новой...

Пытался откатываться на предыдущие версии (дошел до 6.30.4 на подшефном устройстве), переходить на багфиксонли версии, на последние RC - ничего не помогало.

 

Попутно пробовал максимально отключать лишний функционал, пакеты и т.д.

 

Помогло (сегодня сообразил, до этого недели 3-4 мучался) отключение сервисов WWW/Telnet/FTP.

То ли у этих сервисов самих по себе память текла, то ли из-за попыток подбора пароля - пока не понятно, буду еще наблюдать.

 

P.S. Стрелка на графике - момент отключения сервисов и перезагрузка маршрутизатора (для чистоты эксперимента).

 

P.P.S. Техническая поддержка Микротика опять ничем не смогла помочь. От них получил только просьбу прислать supout.rif созданный когда на маршрутизаторе остается примерно 4 мб свободной оперативки (в созданном сразу после перезагрузке ничего не видели проблемного).

К сожалению сделать этого так и не смог - когда оставалось мало памяти создание supout.rif вешало маршрутизатор и он уходил на перезапуск...

Или если не уходил (один раз часа три ждал глядя на загрузку проца в 100%) - файлик создавался минимального размера и без содержимого...

Изменено 19 сентября, 2016 пользователем SolarW

[SolarW]

Был неправ, анализируя присланные мной файлы autosupout.rif оставшиеся после перезагрузок техподдержка микротика пришла к тем же выводам - "течет" память в телнет-сервере, особенно когда к нему пытаются подобрать пароль.

Hello,

 

The last autosupout.rif file contained signs that memory leak was caused by telnet program and it looks like some kind of attack. We cannot provide a fast fix for that therefore you should check if there are other ways to protect your routers.

You should check the incoming traffic, especially, port 23 with a Torch tool to see what amount of traffic is sent to router, probably, you need to add additional firewall rules to limit rate or connections. Capturing packets with Sniffer could help to get more information about this problem.

Another option would be setting different Telnet port in IP services.

 

Best regards,

Janis B.

[Saab95]

В пределах 2 десятков VLAN через арендованные у других операторов каналы.

 

Посмотрите торчем или снифером какие пакеты порой приходят по этим каналам, можно много чего интересного увидеть - порой залетают совсем чужие данные из чужих вланов. Отсюда проблемы.

 

Какая-то из ваших задач не поддерживает распараллеливание по ядрам.

К примеру задача "Bandwitch test" только одно ядро умеет использовать.

 

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

 

Помогло (сегодня сообразил, до этого недели 3-4 мучался) отключение сервисов WWW/Telnet/FTP.

 

Эти сервисы нужно отключать, либо указывать диапазон IP с которых разрешено подключаться.

 

Был неправ, анализируя присланные мной файлы autosupout.rif оставшиеся после перезагрузок техподдержка микротика пришла к тем же выводам - "течет" память в телнет-сервере, особенно когда к нему пытаются подобрать пароль.

 

Телнет вообще устаревший протокол, нужно использовать SSH - с ним подобных проблем нет.

[myth]

Телнет вообще устаревший протокол

)))))))))

[SolarW]

Посмотрите торчем или снифером какие пакеты порой приходят по этим каналам, можно много чего интересного увидеть - порой залетают совсем чужие данные из чужих вланов. Отсюда проблемы.

Мнэээ... Ну и? Приходят данные, разные - это разве повод маршрутизатору раком становится?

Эти сервисы нужно отключать, либо указывать диапазон IP с которых разрешено подключаться.

Да я то в курсе какими методами надо защищаться.

Осталось дело за малым - кое-кому научится писать софт так, чтобы десяток неудачных коннектов по телнету не вываливали насмерть маршрутизатор ;-)

[Saab95]

Мнэээ... Ну и? Приходят данные, разные - это разве повод маршрутизатору раком становится?

 

Так если mac-telnet слушает эти данные, то почему бы? На цисках и софтроутерах такой плюшки нет, а многие его на микротиках не отключают.

[SolarW]

Так если mac-telnet слушает эти данные, то почему бы?

Почему-то кажется что если ПО пишут не студенты в виде курсача а организация претендующая на некоторую серьезность - то само собой подразумевается некоторая проверка валидности передаваемых на обработку данных, призванная исключать описанные выше ситуации.

На цисках и софтроутерах такой плюшки нет, а многие его на микротиках не отключают.

Так себе аргумент... Хорошо, конечно, что на микротике есть такая возможность.

Теперь бы еще было неплохо чтобы она работала без глюков :-)

Причем как уже отметил выше - "радость" такая с глюками именно с CCR серией приключилась, которые совсем не в SOHO применяются...

[myth]

На цисках и софтроутерах такой плюшки нет

в линуксе есть.

[vman]

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

В результате экспериментов выяснили что грузит одно из ядер на 100% 2 аплинка БГП ФВ.

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

 

купили новый MikroTik CCR1072 поставили с тем же конфигом и прошивкой смотрим дальше

[kosmich7]

На графике потребления памяти все наглядно видно - нарастание потребления, отказ отвечать на SNMP-запросы, загрузка процессора в 100%, перезагрузка, пошло все по новой...

Пытался откатываться на предыдущие версии (дошел до 6.30.4 на подшефном устройстве), переходить на багфиксонли версии, на последние RC - ничего не помогало.

Подскажите пожалуйста, кеш ДНС случайно не заполнялся под завязку ?

[EShirokiy]

chaosduality, у CCR проц не рассчитан на FV BGP. Поменяйте на х86 с нормальным процом.

[WY6EPT]

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

В результате экспериментов выяснили что грузит одно из ядер на 100% 2 аплинка БГП ФВ.

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

 

купили новый MikroTik CCR1072 поставили с тем же конфигом и прошивкой смотрим дальше

 

Засматривался на эти железяки :( теперь пришло осознание, что лучше сервак на это дело поставить, там и процы быстрей и частоты одного ядра выше.

Замена решила проблему с бгп?

[Nik0n]

Замена решила проблему с бгп?

Не решит!

Используем два CCR1036 только для BGP (NAT и conntrack выключены). Принимаем ~3.5М префиксов (аплинки имеют по два роутсервера).

Наблюдаем точно такую же проблему - постоянно один CPU 100%.

Но остальное все работает без замечаний. Зависаний ни разу не было за 9 месяцев эксплуатации, практически на всех прошивках 6.33+.

ЗЫ Рестарты были по причинам питания и физического переноса.

[EShirokiy]

Наблюдаем точно такую же проблему - постоянно один CPU 100%.

на x86, какой то восьмиядерный проц (скорее всего core i7 или xeon), одно ядро на 100 продолжительностью не более 1-2 секунды, примерно раз в пол минуты. Полтора миллиона префиксов.

[Nik0n]

на x86, ...

Много кто уже на форуме рассуждал что на x86 лучше Linux/FreeBSD (чем ROS) и я полностью это поддерживаю !!!

[kosmich7]

на x86, ...

Много кто уже на форуме рассуждал что на x86 лучше Linux/FreeBSD (чем ROS) и я полностью это поддерживаю !!!

ROS позволяет выстрелить себе в ногу, по этой причине, приходится ее использовать. :=)

[Sonne]

Нет никаих проблем BGP и загрузкой одного ядра 100% год как уже! С вирсии около 6.14 все нормально работает!

 

Говорю постоянно всяким идиотам - ставьте на бордер отдельную железку ВСЕГДА! Нет денег на Cisco ASR или Juniper MX80, так хоть купите железку CCR1009 за 500 баксов.

 

Просто Микротик - реально дешевое железо, во всяких навороченных конфигурациях его мало кто использует. Критерии разработчика - побыстрее и подешевле. Когда на него пытаются навернуть навороты, начинаются проблемы. На эти проблемы - всем насрать.