Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1 2 След.
RSS
[Решено] Устройства U7 Pro Max работают некорректно., UniFi Network
 
Привет, у нас установлено 4 AP U7 Pro Max, но проблемы возникают с 3 из них (сейчас). 2 случайным образом перезагружаются (они некоторое время отображаются как отключенные, потом возвращаются и их время безотказной работы сбрасывается до 0). Они не работают больше часа, иногда даже меньше, прежде чем это происходит. Оба питаются от одного PoE+ коммутатора. Ранее мы использовали 4 других AP, питаемые от этого же коммутатора, без каких-либо проблем, и эти 2 их заменили. Все 4 старые AP отключены, остались только эти 2 новых U7. Эти два также сильно нагреваются во время работы.

Третий модуль вообще не запускается до конца, похоже. Он питается от отдельного PoE+ коммутатора и работал после нашей первоначальной установки. Но на следующий день он просто мигает белым (1 раз в секунду) в течение 10-15 секунд, выключается, включается снова, мигает белым, и так по кругу.

Все 3 модуля были обновлены до последней прошивки, которую показывает Network Application: 8.0.19. Четвертый модуль мы только сегодня установили и оставили на его текущей прошивке, 7.0.48. Он также питается от другого PoE+ коммутатора, отличного от остальных, но пока что он не работал достаточно долго, чтобы сказать, испытывает ли он те же проблемы или нет.

У кого-нибудь есть какие-нибудь мысли?

--------------------------------

Редактировано: Проблемы решены. Первоначальные проблемы, с которыми мы столкнулись, были связаны с коммутаторами Aruba (модели 2540 и 2930F, оба PoE+), которые не определяли правильно подключенные устройства и резервировали слишком низкое значение потребляемой мощности. Хотя у коммутаторов была запасная мощность, когда AP пытались потреблять больше мощности, чем зарезервировано коммутатором, это вызывало ошибку перегрузки на коммутаторе, отключая питание AP и вызывая перезагрузки.

Решением было зайти в конфигурацию Aruba (использовал веб-интерфейс) в раздел Interface -> POE, выбрать порт, к которому подключен AP, и затем отредактировать его, изменив настройку "power reserved by" на "value". Затем я вручную ввел значение 25 (в интерфейсе Aruba это не очень понятно, но это "value" — это количество резервируемой мощности в ваттах). Вполне вероятно, что установка 30 не повредит, если хотите быть в безопасности, но коммутаторы, похоже, резервировали больше мощности, чем введено, предположительно, чтобы компенсировать любые потенциальные потери в линии.

Еще одна проблема, с которой мы столкнулись при устранении неполадок, заключалась в том, что несколько AP были обнаружены Network Application через Mesh, потому что они не получали IP-адреса (моя вина). Как только я решил проблему с IP, Application не обновлялся и все равно хотел подключить AP через Mesh. Application также не позволял мне удалить AP из списка, даже когда они были выключены, не приняв их сначала, но при этом не удавалось принять их через Mesh.

Решением было, с выключенными AP, перезапустить службу Unifi на сервере. Когда служба снова заработает, AP, с которыми она не может связаться, останутся в автономном состоянии, что позволит удалить их из Application. После этого AP можно включить, чтобы они были повторно обнаружены по IP-адресу и приняты правильно.

Я хочу выразить благодарность всем, кто написал в этой ветке и помог мне разобраться во всем этом.
 
Для тех, кто интересуется: я пока не смог как следует протестировать коммутаторы Cisco из-за некоторых VLAN и других настроек, которые у меня, видимо, пока не получаются идеальными. Но в кратком тесте, который я всё же провёл с одним из этих AP, подключённым к коммутатору, заметил, что коммутатор, кажется, резервирует для порта целых 30 ватт.

Потребуется несколько недель, прежде чем у нас будут все коммутаторы настроены и установлены как следует: мы закончим с развёртыванием AP, а затем нам нужно будет настроить с нуля (чтобы убрать кучу лишнего на Aruba) коммутаторы Cisco и сделать это всё за одну ночь (8 коммутаторов), как только убедимся, что настройки в порядке.
 
Отлично!
 
Этот самый AP, который с самого начала зацикливался в перезагрузках? Я вручную подключил его к PoE-порту, настроенному на 25W, и он включился без проблем. 😒 Сделал заводской сброс, и он снова появился в Network Application, готовый к добавлению. Ну, хотя бы это улажено. 😆 Теперь интересно, как Cisco switches будут справляться с этими...
 
Ура! Получилось!! Избавил меня от необходимости лезть на лестницу. 😝 Спасибо тебе за всю помощь в этом!
 
Ну, я попробовал это, пока ждал возможности зайти в офис этого человека. И тот девайс, который я физически отключил, теперь отображается как оффлайн, и мне предлагают его удалить. Хм, интересно, если я отключу PoE для второго устройства, перезапущу сервис, то он тоже покажет себя оффлайн и позволит мне его убрать? А потом включу питание обратно и, возможно, он нормально подключится? Стоит попробовать…
 
Может, попробую это, как только появится возможность заменить другое устройство. Но оно сейчас в чьем-то офисе, так что придется ждать, пока у этого человека появится пара свободных минут, чтобы выгнать его оттуда.
 
Иногда перезагрузка контроллера может помочь ускорить процесс удаления.
 
Ну вот, получилось. Попробовал с другим устройством – там все отображается нормально в Network Application и успешно зарегистрировано. Старое устройство все еще висит в списке, но удалить его нет возможности. Похоже, придется делать то же самое и с остальными, а потом посмотреть, отвалятся ли они сами через неделю...
 
Окей, вижу свою ошибку. Прошивка 8.x, а не программное обеспечение, так что у вас всё в порядке. Кажется, проблема в настройке управления VLAN.
 
Я использую последнюю версию, доступную для скачивания на момент месяца назад: 9.1.120, дата релиза 23 апреля 2025 года. Хотя, они только вчера выпустили новую версию, оказывается. К тому же, когда я проверяю наличие обновлений AP, там показывает, что последняя доступная версия – 8.0.19.
 
Понял, что твоё сетевое приложение довольно старое и этим точкам доступа (APs) нужна версия 8.2.x, чтобы они могли поддерживать новые функции?
 
Ну, два проблемных AP, но по одной и той же причине: Network Application пытается принять их через mesh. Скорее всего, потому что именно так они были приняты изначально, когда у них не было IP-адресов.

Статус: Не приняты (http://unifi:8080/inform)

"unifi" в этом URL должно быть в порядке... Я создал DNS-запись, чтобы она указывала на сервер, на котором работает Network Application, и 4 других устройства успешно приняли участие. Тем не менее, я пытался подключиться к ним по SSH, сделал сброс к заводским настройкам на одном и использовал "set-inform http://ip-of-host:8080/inform" на обоих (заменив "ip-of-host" на реальный IP-адрес нашего сервера с ПО). Всё равно показывает в Network Application без IP-адресов и настаивает на включении mesh для принятия. Единственное, что я смог найти онлайн о том, как их удалить (в попытке дать ему возможность снова их обнаружить), — это либо держать их в автономном режиме не менее 7 дней, и они сами отключатся, либо скачивать копию MongoDB и вручную редактировать БД (пост 5-летнего Spiceworks под названием "Remove Ubiquiti UniFi AP stuck in adoption failure loop"). Думаю, я заменю тот, к которому проще добраться, другим устройством (мы купили 16 штук) и убедюсь, что он правильно подключается.

Редактирую: Ах да, для управления VLAN – да, но он помечен. Итак, AP сначала получают IP-адрес из той же сети, что и компьютеры, затем я принимаю их в Network Application, затем я переопределяю сетевые настройки и назначаю VLAN, который я настроил в приложении. Перезагружается, а затем получает IP-адрес в области управления сетью. Как я уже говорил, так работало хорошо для 4 устройств. Идея здесь была в том, чтобы я мог подключить их к любому свободному порту на коммутаторе, и всё "просто работало", хотя, очевидно, эта проблема с питанием этому помешала. Вздыхаю
 
Отлично! Так, у нас остался один проблемный AP. Залогинься через SSH и проверь статус inform. Странно, что ты можешь пинговать его, но контроллер думает, что его нужно связать в mesh. Звучит как сетевая проблема. Ты не используешь единую VLAN для управления?
 
Окей, сегодня на месте и визуально проверяю два устройства, которые не показывают IP-адреса в Network Application. Пока успел посмотреть только одно, и, кажется, "исправил" – была ошибка в конфигурации свича, которую я упустил. Теперь получает IP-адрес, согласно нашему DHCP-серверу, и я могу его пинговать… но он всё ещё отображается как не имеющее IP в списке устройств Network Application и просит меня включить мешинг для его добавления. Как мне сбросить (или, наверное, правильнее сказать "удалить") это устройство в Network Application, чтобы оно могло переидентифицировать его или что-то вроде того? И, я предполагаю, придётся сделать то же самое с другим устройством, как только я разберусь с его проблемой.

Редактирование: Проблема со вторым устройством, которое не получало IP, решена. Оказывается, оно изначально подключалось к полному диапазону DHCP (я даже не подумал проверить это раньше…) прежде чем его конфигурация изменилась. Расширил диапазон, теперь оно получает IP через DHCP и его можно пинговать, но всё равно отображается как не имеющее IP в Network Application и просит меня снова включить мешинг для добавления.

Редактирование 2: Ну и да, под "пинговать" я имею в виду с сервера, на котором работает Network Application.
 
Да, об этом я тоже подумал потом, хотя другой переключатель, который я установил на 30, показывает "зарезервировано 30", так что... 🤷В любом случае, оба теперь работают лучше после внесённых изменений. Просто нужно помнить об этом для коммутаторов Cisco, на случай, если они неправильно определят требования к питанию AP. Следующий шаг — разобраться, почему эти два AP не получают IP-адрес. Я уже несколько раз проверял конфигурацию, и она выглядит нормально, так что завтра нужно будет проверить физически и действовать, исходя из этого.
 
Возможно, 25w будет на PD, а бронь 29.3 — на PSE.
 
Ну что, пока что всё хорошо. Я решил сделать то же самое для порта AP #2 на другом свитче, хотя решил попробовать значение 25 (максимальная потребляемая мощность U7 Pro Max указана как 25W). Заметил, что хотя показывает, что я ввел 25, оно резервирует 29.3W. Ну ладно, как знаешь. Посмотрим, как будет себя вести второй AP, потому что он точно перезагружался. Заметка себе: Over Current Count на этом порту сейчас 80, а последняя перезагрузка была чуть больше 22 минуты назад.
 
Ах, опция "распределение мощности по" имеет параметр "value", в чем я не был на 100% уверен, но я поковырялся в ней и, установив значение 30, она теперь резервирует 30W для этого порта. Посмотрим, станет ли лучше! Заметка для себя: Счетчик превышения тока на этом порту сейчас 716, а последная перезагрузка была чуть больше 8 минут назад.
 
Да, не знаю, но решил попробовать. С настройкой "распределение мощности по" установленной в значение "класс", теперь резервируется 14,8 Вт на двух коммутаторах и 15,2 Вт на третьем (который 2540-й, такая же модель, как один из них, резервирующий только 14,8 Вт). Что всё равно кажется мне странным, если PoE+ должен выдавать более 30 Вт. 🫤В любом случае, первые два AP всё ещё перезагружаются (второй из них хотя бы продержался всю выходную неделю без перезагрузки, но перезагрузился как минимум 10 раз (по данным счётчика превышения тока) с тех пор, как я впервые проверил его сегодня утром), а вот #4 (с зарезервированным питанием 15,2 Вт) работает нормально. Хм, спасибо. Ну, не совсем то же самое, но всё ещё может быть связано. К сожалению, у нас нет инжекторов для проверки, но есть несколько новых коммутаторов Cisco PoE+ (серии C1200). Я начал настраивать один из них в четверг, перед тем как ушёл с работы, но не успел закончить. Займусь этим завтра, установлю в стойку и переведу на него один из AP (скорее всего, #1, так как он, кажется, перезагружается чаще всего) и посмотрю, что произойдёт.
Страницы: 1 2 След.
Читают тему (гостей: 1)