Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1 2 След.
RSS
Серьёзные проблемы с UniFi Security Gateway 3P — зависает каждый день!, UniFi Network
 
Хорошо, за последние несколько лет я действительно влюбился в Ubiquiti. Их беспроводные продукты просто потрясающие и всегда как будто на шаг впереди всех остальных. У меня профиль в IT-сетях, и по умолчанию я фанат Cisco (у меня Cisco CCNP). Но решил, что пора что-то менять, и теперь моя квартира полностью на Ubiquiti! Вот насколько я люблю эту компанию!

Единственная серьёзная проблема — это Security Gateway 3P. Каждый день он “зависает” (лучше слова не придумал) и становится недоступен для других устройств, включая контроллер. Точнее, он виден, но не отвечает.

Вот моя конфигурация:
(1) Ubiquiti Cloud Key (UC-CK)
(1) Ubiquiti Security Gateway 3P (USG-3P)
(1) Ubiquiti 16 портовый PoE коммутатор (US-16-150W)
(2) Ubiquiti AP-AC-Lite точки доступа (UAP-AC-LITE)

Всё это управляется контроллером на выделенном Cloud Key, который всегда включён в сеть (питается от 16-портового PoE коммутатора). Всё в одной VLAN (одно подсеть), интернет у меня кабельный — публичный IP приходит на шлюз. В целом, ничего сложного, обычная обычная сетевая схема.

И всё отлично работает — пока.gateway не зависает, а это каждый день. Чтобы исправить проблему, нужно физически перезагрузить шлюз, и всё снова отлично. Но конечно, делать это каждый день не хочется. К счастью, весь интернет-трафик по-прежнему проходит через шлюз, хоть добраться до него и невозможно при зависании. На панели состояние WAN отображается как “отключено”, а в списке устройств он висит в статусе “Adopting”. Причём шлюз уже был принят в сеть. Как я уже сказал, после перезагрузки всё в порядке.

Что же происходит???

Кто-нибудь сталкивался с таким раньше? Это сводит с ума. Ниже я бы приложил скриншоты, как это выглядит, когда он “зависает”, но когда я пытаюсь вставить картинки, мой пост почему-то помечают как спам.

Помогите, если есть идеи!
 
Та же самая проблема, последнее сообщение было 9 месяцев назад, есть какие-нибудь новости или решение?
 
У меня 3 устройства, и на 2 из них одинаковая проблема.
 
Проблема была в флешке — внутри стоит ужасный USB-накопитель. Просто замените её на какую-нибудь получше и запишите образ любой версии ОС из интернета.
 
Решил зайти, раз я тот, кто начал эту тему несколько месяцев назад. Мне пришлось перейти на 4P (Pro) Gateway, и тогда всё сразу наладилось. А тем, кто говорит, что мой 3P был неисправен — нет, он работал отлично. Последние пару месяцев он у моей мамы без проблем. Он подключён к моему UniFi контроллеру, так что я мог следить, если что-то зависнет, но оба устройства показывали стабильную работу.

В итоге, 3P просто не предназначен для сетей с большим количеством устройств. Печальная правда. И большинство из нас не пользуются крохотными сетями. У меня сеть не сильно большая, но и не маленькая. В среднем у меня онлайн около 50 клиентов одновременно. А у мамы всегда примерно 6–7 устройств подключены. Для 3P это большая нагрузка, он с ней не справлялся.

Мои последние проблемы связаны с 10-гигабитным свитчем от Ubiquiti, который я недавно купил. Он не такой мощный, как я ожидал. У меня ещё есть 16-портовый 10-гигабитный свитч QNAP, и, честно говоря, он работает гораздо лучше моего US-16-XG. Может, обновление прошивки что-то исправит.

Но в целом сейчас всё стабильно, и уже давно. Для меня это главное.

Вот моя нынешняя конфигурация:  
(1) Ubiquiti Cloud Key (UC‑CK)  
(1) Ubiquiti Security Gateway 4P (USG-4P-Pro)  
(1) Ubiquiti 16 портовый PoE свитч (US‑16‑150W)  
(1) Ubiquiti 16 портовый 10Gb свитч (US-16-XG)  
(2) Ubiquiti AP-AC-HD точки доступа (UAP‑AC‑HD)
 
У меня были серьёзные проблемы с роутером USG Unifi — зависал, не загружался после прошивки, полгода мучился с этим, пока USG полностью не «умёр». НО «умёр» оказался ТОЛЬКО USB-флешка внутри! Пожалуйста, проверьте вашу USB-флешку, вставленную в роутер USG! Прошивка полностью сломалась. Я скачал img-образ прошивки и записал его через DMDE на новый USB-накопитель, и теперь мой USG снова отлично работает! https://dl.ubnt-ut.com/cmb/USG-4_2_0-shipped.img.bz2
 
У меня такая же проблема. Увы, это с USG Pro,, установленным для финансовой компании, к которой прикреплено небольшое кафе. Выгляжу полным профаном, ведь этот хлам Huawei-модем стоимостью около $4.27 работает лучше, чем тысячи долларов оборудования Unify. Ещё хуже то, что меня там нет, я не могу подключиться удалённо, и сеть нельзя перезагрузить. Очень досадно... Это совсем не внушает мне уверенности продолжать использовать USG. Z...
 
Сегодня утром я копнул глубже… Пролистал 3 мегабайта логов. Вот повторяющаяся схема.  
Ключевая проблема вот в чем:  
[2019-01-12 10:32:20,529] <inform-25> INFO dev - saveDeviceAttr(): device[fc:ec:da:d7:07:3c][ip]=0.0.0.0 (orig=24.16.30.7)
[2019-01-12 10:32:20,534] <inform-25> INFO dev - [state] dev[fc:ec:da:d7:07:3c] UNKNOWN->CONNECTED, state_expire=0
Есть у кого-нибудь еще в логах такие строки? (Ищите по “<inform-25> INFO dev - saveDeviceAttr(): device”)  
Добавил комментарии как >>> КОММЕНТАРИИ ЗАГЛАВНЫМИ >>> ПРАВИЛЬНЫЙ WAN АДРЕС (Я ИЗМЕНИЛ ЕГО)  

[2019-01-12 10:29:26,039] <inform-35> INFO inform - from [fc:ec:da:d7:07:3c](net-vsh-usg, UGW3, 4.4.36.5146617): state=UNKNOWN, last_inform=40, ext/stun_ip=10.70.1.1, dev_ip=24.16.30.7, up=3029
>>> ТАКИХ МНОГО  

[2019-01-12 10:29:34,185] <pool-6-thread-1> INFO AwsIotConnection - Connection is being retried
[2019-01-12 10:29:34,201] <MQTT Con: b340d6e3-89ae-4658-92f8-b0143e12cbc1> WARN AwsIotMqttConnectionListener - Connect request failure
MqttException (0) - java.net.UnknownHostException: xxxxxxxxxxxxxxxxxx.iot.us-west-2.amazonaws.com  
at org.eclipse.paho.client.mqttv3.internal.ExceptionHelper.createMqttException(ExceptionHelper.java:38)  
at org.eclipse.paho.client.mqttv3.internal.ClientComms$ConnectBG.run(ClientComms.java:664)  
at java.lang.Thread.run(Unknown Source)  
Caused by: java.net.UnknownHostException: xxxxxxxxxxxxxxxxxx.iot.us-west-2.amazonaws.com  
at java.net.AbstractPlainSocketImpl.connect(Unknown Source)  
at java.net.PlainSocketImpl.connect(Unknown Source)  
at java.net.SocksSocketImpl.connect(Unknown Source)  
at java.net.Socket.connect(Unknown Source)  
at sun.security.ssl.SSLSocketImpl.connect(Unknown Source)  
at org.eclipse.paho.client.mqttv3.internal.TCPNetworkModule.start(TCPNetworkModule.java:70)  
at org.eclipse.paho.client.mqttv3.internal.SSLNetworkModule.start(SSLNetworkModule.java:86)  
at org.eclipse.paho.client.mqttv3.internal.ClientComms$ConnectBG.run(ClientComms.java:650)  
... 1 more  

[2019-01-12 10:29:34,205] <pool-6-thread-1> INFO AwsIotConnection - Connection temporarily lost
[2019-01-12 10:30:04,206] <pool-6-thread-1> INFO AwsIotConnection - Connection is being retried
[2019-01-12 10:30:04,234] <pool-6-thread-1> INFO AwsIotConnection - Connection temporarily lost
[2019-01-12 10:30:34,237] <pool-6-thread-1> INFO AwsIotConnection - Connection is being retried
[2019-01-12 10:30:34,273] <pool-6-thread-1> INFO AwsIotConnection - Connection temporarily lost
[2019-01-12 10:31:04,275] <pool-6-thread-1> INFO AwsIotConnection - Connection is being retried
[2019-01-12 10:31:15,324] <pool-6-thread-1> INFO AwsIotConnection - Connection temporarily lost
[2019-01-12 10:31:45,325] <pool-6-thread-1> INFO AwsIotConnection - Connection is being retried
[2019-01-12 10:31:56,377] <pool-6-thread-1> INFO AwsIotConnection - Connection temporarily lost

>>> ПОСЛЕ МНОГОКРАТНЫХ ПОВТОРОВ IP, ПРИШЕДШИЙ ОТ USG INFORM, СТАНОВИТСЯ 0.0.0.0  

[2019-01-12 10:32:20,528] <inform-25> INFO inform - from [fc:ec:da:d7:07:3c](net-vsh-usg, UGW3, 4.4.36.5146617): state=UNKNOWN, last_inform=174, ext_ip=10.70.1.1, dev_ip=0.0.0.0, up=155
>>> USG БЕРЕТ ТО, ЧТО БЫЛО ВАЛИДНЫМ IP-АДРЕСОМ И СОХРАНЯЕТ 0.0.0.0 КАК ВАЛИДНЫЙ. ЯВНО ПЛОХО, УЧИТЫВАЯ, ЧТО СЕТЕВОЕ СОЕДИНЕНИЕ НА САМОМ ДЕЛЕ РАБОТАЕТ.  

[2019-01-12 10:32:20,529] <inform-25> INFO dev - saveDeviceAttr(): device[fc:ec:da:d7:07:3c][ip]=0.0.0.0 (orig=24.16.30.7)
[2019-01-12 10:32:20,534] <inform-25> INFO dev - [state] dev[fc:ec:da:d7:07:3c] UNKNOWN->CONNECTED, state_expire=0
>>> ПОСЛЕ ТОГО, КАК 0.0.0.0 ЗАКРЕПЛЯЕТСЯ, USG СЧИТАЕТ СЕБЯ ПОДКЛЮЧЕННЫМ И ВЕДЕТ СЕБЯ СООТВЕТСТВЕННО ДАЛЬШЕ.  

[2019-01-12 10:32:20,536] <inform-25> INFO event - [event] Gateway[fc:ec:da:d7:07:3c] был подключен
[2019-01-12 10:32:21,106] <inform-27> INFO inform - from [fc:ec:da:d7:07:3c](net-vsh-usg, UGW3, 4.4.36.5146617): state=CONNECTED, last_inform=1, ext_ip=10.70.1.1, dev_ip=0.0.0.0, up=160
>>> НО ПОДКЛЮЧЕНИЯ К IOT ПРОДОЛЖАЮТ ПАДАТЬ ПО ОЧЕВИДНЫМ ПРИЧИНАМ (ПЫТКА ПОДКЛЮЧИТЬСЯ К 0.0.0.0).  

[2019-01-12 10:32:26,379] <pool-6-thread-1> INFO AwsIotConnection - Connection is being retried
[2019-01-12 10:32:37,419] <pool-6-thread-1> INFO AwsIotConnection - Connection temporarily lost
[2019-01-12 10:32:37,449] <inform-91> INFO inform - from [fc:ec:da:d7:07:3c](net-vsh-usg, UGW3, 4.4.36.5146617): state=CONNECTED, last_inform=6, ext/stun_ip=10.70.1.1, dev_ip=0.0.0.0, up=176
 
Я беру роутер Netgate с pfSense в качестве резервного варианта, чтобы попробовать. Долго пользовался Untangle — отлично работал, пока мой девайс не сломался. Сейчас пробую UniFi, посмотрю, как пойдёт. Немного скучаю по всем тем функциям, которые были в Untangle.
 
У меня та же история. Купил три и четыре (Pro). На версии 4.4.36.5146617 они теряют соединение с WAN каждые 3-4 часа. Скорее всего, верну оба устройства, учитывая такой тренд, который тут наблюдается. Для сравнения, мои коробки с pfSense работают месяцами подряд, подключены в доме и на даче, и через них идёт видеотрансляция с камер безопасности.
 
Я обновил один nano до версии 4.4.36, и после этого точка доступа несколько раз отключалась на несколько часов подряд — уже 2-3 раза с момента обновления. У меня включён IPS.
 
Я уже несколько месяцев работаю на версии 4.4.22, и у меня полная стабильность. Также согласен с теми, кто считает, что проблема связана с IDS/IPS. Кто-нибудь обновлялся до 4.4.36? Если да, то насколько она стабильна? Заранее спасибо.
 
Привет! У меня похожая проблема. С версией 4.4.29 и включённым обнаружением IPS шлюз работает примерно неделю. После этого он зависает так, что проводные подключения в основном продолжают работать, а беспроводное соединение пропадает. Странная вещь в том, что в логах шлюза не появляется никакой информации. В какой-то момент запись логов останавливается, и толком нельзя понять, что именно идёт не так. Если отключить обнаружение IPS, то, кажется, шлюз работает нормально. Так что, по моему скромному мнению, бета-версия IPS и вызывает эти проблемы. Надеюсь, это поможет.
 
Я пытался опубликовать это раньше, но не уверен, куда оно делось. В любом случае, у меня началась такая проблема прошлой ночью на версии 4.4.29. Мой USG не мог держаться включённым больше 5-10 минут, и, похоже, это происходило из-за того, что USG падал при получении большого количества martian-пакетов. На USG и ER-X настроен их лог. Я следовал инструкциям по этой ссылке, и, кажется, это решило проблему. https://community.ui.com/questions/8112e18b-433e-4846-8dd1-44e8db1755c6 Мне пришлось применить оба способа: сначала изменить настройки во время работы, а потом заменить net.ipv4.conf.all.log_martians=1 на net.ipv4.conf.all.log_martians=0 в файле /etc/sysctl.d/30-vyatta-router.conf на USG. Вот похожая тема: https://community.ui.com/questions/bfae11f8-b860-4562-84fc-26250f1f7e54, а ещё есть пост на reddit про логирование martian-пакетов и зависания USG.
 
Версия 4.4.22 у меня и у многих других вызывала утечку памяти. Я откатился аж до 4.4.18 — и теперь всё отлично.
 
Неясно, читает ли кто-нибудь из Ubnt эти сообщения. Я обращался в службу поддержки по этому вопросу, но они не ответили ни с какой срочностью или пониманием проблемы.
 
Возможно, это та же проблема, с которой я столкнулся здесь: https://community.ui.com/questions/bfae11f8-b860-4562-84fc-26250f1f7e54. В моём случае отключение логирования martian-пакетов, кажется, стабилизировало ситуацию. Обычно у меня регистрируется сравнительно небольшое количество martian-пакетов, но по какой-то причине их количество резко выросло прошлой ночью, и я не понимаю, почему. Внезапно прошлой ночью USG не мог проработать больше 10 минут, после чего зависал, и приходилось физически перезагружать устройство.

Мне пришлось выполнить шаги, описанные здесь: https://community.ui.com/questions/8112e18b-433e-4846-8dd1-44e8db1755c6, чтобы отключить логирование martian-пакетов. В одном из ответов в треде советуют изменить строку

# Log packets with impossible addresses to kernel log  
net.ipv4.conf.all.log_martians=1

на 0 в файле /etc/sysctl.d/30-vyatta-router.conf, но это не помогло. Всё равно пришлось выполнить именно первые шаги для отключения. Без выполнения обоих действий ситуация не исправлялась постоянно.

Вот ещё одна публикация на похожую тему: https://www.reddit.com/r/Ubiquiti/comments/9f09le/martian_packets_crash_edgerou­terx/.

Система работает стабильно уже около 10 часов. Это невероятно раздражает, и прошлой ночью меня чуть не пробило швырнуть свой USG через улицу. У меня стоит версия 4.4.29 на двух объектах.
 
Та же проблема у меня. С версией v4.4.29 USG зависает через несколько дней. Прошивка, похоже, совсем нестабильная. Я понаблюдаю еще несколько дней, а потом откатлюсь на предыдущую версию. Unifi, пожалуйста, отреагируйте!
 
У меня была такая же проблема. Вот как я её решил: отключил автоматическое обновление прошивки, затем откатился до версии 4.4.22. После понижения версии полностью выключил всё, потом включил — сначала модем, потом роутер, потом коммутаторы. Это должно исправить ошибки конфигурации. Обязательно оставляйте автообновление отключённым, иначе система снова обновится до 4.4.29 и проблемы повторятся.
 
откатиться на прошивку 4.4.22
Страницы: 1 2 След.
Читают тему (гостей: 1)