Зависает Микрот

[Hypnodisk]

Добрый день.

Имеется микротик CRS354-48P-4S+2Q+. С периодичностью раз в 4 дня, в разное время происходит зависание. Питание есть, порты горят, но устройства за ним и сам мироктик отваливается от сети. В Winbox его не видно, пинг не идет. На устройстве к которому подключен микротик порт не падает. В расширенных логах никаких ошибок не видно. Решается только ребутом по питанию, но всего на 4 дня( Может кто сталкивался с таким и подскажет решение проблемы?

[gmx]

1. Как вы посмотрели логи? После перезагрузки? Это не актуально. Попробуйте настроить syslog в сети, чтобы видеть все логи.
2. Если в момент зависания к нему подойти с ноутбуком, включится в свободный порт, то winbox его не увидит? Проверьте настройки свободного порта заранее. То есть проверьте, пока он работает нормально, чтобы ноутбук его видел со свободного порта. А потом проверьте в момент проблемы. Иными словами обеспечьте управление с другого порта и другого сегмента сети, для контроля.
3. Что с версией рос? Она актуальна и проверьте версию firmware. Все обновлено??
4. Все это очень похоже на работу RSTP... или каких-то скриптов. Надо искать объективную проблему. Петля? Программные блокировки?
5. Ну и последнее. Самое трудоемкое, но чтобы уж убедится на 100%. Сделать export конфига. Удалить конфиг. Перезагрузить. И заново, вручную каждую строчку, со знанием дела, с пониманием для чего она - все восстановить. И вот если и после этого все будет зависать - ну тогда искать деньги и покупать новый.
6. Еще есть момент - возможно проблема во встречном устройстве. Надо поглядеть там, что с портом, что в логах. Для эксперимента между ними поставить еще один свич. Поглядеть, как будет все работать.

[Hypnodisk]

1. Смотрели как раз через настроенный syslog. Скидывали логи на удаленный сервер. Вот в них есть записи, но ничего подозрительного не происходит. Прекращаются записи как раз момент зависания и следующая запись уже о ребуте по питанию.
2. Не пробовали, можно проверить.
3. У нас несколько точно таких же устройств в сети (6 шт.), у и них такая же версия прошивки. (7.6 Stable) Проблем с ними не было.(
4. RSTP дефолтные настройки (из коробки), скриптов нет. Петля была бы видна в логах (?) и в логах на родительском микроте (?). Про программные блокировки можно подробнее?
5. Ждем очередного отключения, для этих манипуляций)) Конфиг там минимальный, используется как L2 коммутатор.
6. До этого на месте проблемного микротика стоял микротик CRS328-24P-4S+, проблем не было, нужно было побольше портов заменили на 48 портовый и началось...

Кстати по поводу прошивки, можно ли использовать в сети устройства с разной версией прошивок? Стараемся все микроты разных моделей и держать на версии 7.6 Stable, или не принципиально и лучше устанавливать последние доступные версии прошивок?

[Hypnodisk]

4. Все это очень похоже на работу RSTP... или каких-то скриптов. Надо искать объективную проблему. Петля? Программные блокировки?

Вы были правы, это STP. Получилось так, что мы сняли и подключили "сломанный" микротик (1й) в другом месте. На его место вернули 24 портовый микротик (2й). И тут внезапно (через 5 дней), отключается вообще 3й Микротик. И 3й и 2й подключены в один рутовый коммутатор. В логах рутового коммутатора увидели ошибки:

bridge,stp sfp-sfpplus22 discarding
bridge,stp sfp-sfpplus22 learning
bridge,stp sfp-sfpplus22 forwarding

и так по кругу...Уже ранее был (перед проблемой, когда все работало) назначен на bridge рутового микротика меньший приоритет чем на остальных. Остальные его видят как рут.. Подскажите, что в этом случае делать?

[gmx]

Ох ёлки... В общем и целом, я вижу три исхода:

1. Например, петля реально появляется и не обязательно физическая, она может быть и программная. Но она намного ниже, по отношению к с основному коммутатору и поэтому он видит ее не совсем петлей.
2. Есть проблемы в настройке rstp. И это самое сложное. То есть вы реально используете несколько физических линков и вы понимаете, что это вам нужно. Не знаю, у меня был случай, когда, коммутаторы разных вендоров никак не хотели работать вместе по rstp. Тут надо жкспериментировать, перебирать настройки и оборудование. На действующей сети это сложно. Иногда проще все поменять на одного производителя и сделать все заново.
3. Все нормально, но на коммутаторе заложено пароноидальное поведение rstp. Я такое видел только на хувей и на микротике на rb260. Тут все просто - выключаете rstp и радуетесь жизни. Но нужно помнить, что если проблемы реально есть, то они в одночасье, положат всю вашу сеть...

Что делал бы я? Я всегда исхожу из того, что "чудес не бывает", а значит проблема реальная и это, скорее всего петля. Я бы включал loop protect на всех коммутаторах, где только возможно. И пытался бы локализовать проблему.
Легко не получится...

[Hypnodisk]

Тк проблема еще сохраняется, подниму тему, может что то еще подскажете.

Заметил что на коммутаторе, который зависает, порт по которому он подключен sfp-sfpplus1 становится на паузу т.е во вкладке TX Stats, значение TX Pause = 1. Так же на порту вышестоящего коммутатора, к которому подключен проблемный коммутатор на вкладке RX Stats также видна пауза, значение RX Pause = 1. Соответственно думаю, что в этом и заключается проблема. Нагуглил, что такое может происходить при переполнении буфера коммутатора. Чтобы избавиться от проблемы рекомендуют отключить Flow control, но этот параметр отключен на обоих коммутаторах на uplinkaх.

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

[Hypnodisk]

Помогла прошивка 7.13.1, если кто столкнется - обновляйте.

[gmx]

Ну вот и отлично!