Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1
RSS
uniFy APs убивают сервер, UniFi Network
 
Я что-то не так делаю? Мы купили 20 точек доступа UniFi для нашей больницы. Установили управляющее ПО на один из серверов и пользовались им примерно две недели. В нашей конфигурации мы вручную прописали IP-адреса для точек доступа из основного диапазона, последовательно: 192.168.6.90 ... 192.168.6.119. В нашей сети MS, DNS и PDC-машина имеют IP 192.168.6.20. 192.168.6.21 — это наш шлюз, на котором установлен TMG. ПО UBNT установлено на одном из серверов приложений с адресом 192.168.6.28.

Для обычного обслуживания мы выключили машину с TMG. После перезагрузки связь с ней пропала. Через некоторое время обнаружили конфликт IP. Одна из точек UniFi решила стать новым шлюзом (я вообще не понимаю, почему и кто позволил этой чёртовой точке за 100 долларов решать свою роль и IP в корпоративной сети). Пришлось бегать по всему зданию, чтобы отключить все точки доступа — это заняло около получаса. Мы запустили сервер и снова подключили точки. На форуме нашли похожий совет: установить шлюз точки доступа на сервер с управляющим сервисом, так мы и сделали.

Прошлой ночью мы выключили один из серверов (на котором тоже работает UBNT host), чтобы подключить новый HBA. После перезагрузки, как обычно, возникли проблемы с IP. Начали отключать, перезагружать, подключать — бла-бла, это заняло еще час. Сегодня мы просто запустили Windows, чтобы установить драйвер, и снова та же история.

Я собираюсь оставить поле шлюза пустым на точках доступа. Если снова начнутся проблемы, я выброшу все UniFi и куплю Zyxel. Ребята, отличная работа, честное слово.
 
@melmer20: Поскольку этот топик твой, давай используем только его, ок? То же самое прошу и у всех, кто отвечает @melmer20. Вот ссылка: forum.ubnt.com/showthread.php?t=60360&page=2
 
Пожалуйста, предоставьте текст для перевода.
 
Всем привет.
 
Ну, похоже, проблема возникает только когда кто-то использует IP-адрес контроллера в качестве шлюза для AP. Это было единственным общим во всех случаях. Отправлено с моего iPad через Tapatalk
 
Кто-нибудь вообще когда-нибудь сделает захват пакетов и выяснит, в чём настоящая проблема? Или это "проблема" будет возникать снова и снова, как видения Элвиса? <--- Вот он!!!!!
 
Спасибо за подсказку насчёт Uplink Connectivity Monitor. Мы используем Unify уже около двух месяцев. Я не знал, что версия прошивки меняется так быстро. Мы обновились до 2.3.8. На следующей неделе сделаю тест, чтобы проверить, решена ли проблема.
 
Какую версию ПО UniFI вы используете? Я собираюсь протестировать здесь с версией 2.3.6.  
Правка:  
Статично задал IP на Unifi AP, который подключён к тому же свитчу, что и мой ноутбук, затем отключил uplink к остальной сети.  
Точка доступа осталась на заданном IP, как и ожидалось.  
Даже перезагрузил AP, единственное, что изменилось после перезагрузки — она потеряла IP-интерфейс на гостевой VLAN (который, скорее всего, получен по DHCP).  

BZ.v2.3.6# ifconfig br0  
br0       Link encap:Ethernet  HWaddr 00:27:22:F2:0F:1A  
         inet addr:192.168.6.15  Bcast:192.168.6.255  Mask:255.255.255.0  
         UP BROADCAST RUNNING ALLMULTI MULTICAST  MTU:1500  Metric:1  
         RX packets:662 errors:0 dropped:0 overruns:0 frame:0  
         TX packets:311 errors:0 dropped:0 overruns:0 carrier:0  
         collisions:0 txqueuelen:0  
         RX bytes:59392 (58.0 KiB)  TX bytes:47839 (46.7 KiB)  

Таблица маршрутизации ядра IP  
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface  
192.168.6.0     0.0.0.0         255.255.255.0   U     0      0        0 br0  
0.0.0.0         192.168.6.1     0.0.0.0         UG    0      0        0 br0
 
Режим мониторинга можно отключить в версии 2.3x. Снимите галочку с пункта «Uplink Connectivity Monitor» в разделе «settings > system». Это должно предотвратить изоляцию точки доступа, если шлюз окажется офлайн. Дело не в том, что точка доступа нуждается в работающем шлюзе, чтобы функционировать, а в том, что система пытается быть умной и выключает точки доступа, если шлюз теряется. Идея в том, что если точка доступа не может связаться со шлюзом, то, скорее всего, и подключённым к ней клиентам связи тоже не будет.

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

Конечно, если вы используете VLAN, то может возникнуть ситуация, когда шлюз для управляющего VLAN станет недоступен, а шлюз для клиентского VLAN будет по-прежнему доступен.
 
Endyilmaz, я согласен, что назначение статических IP-адресов точкам доступа не должно быть проблемой. И ты уже привёл несколько весомых причин для этого. Если только служба поддержки Ubiquiti не подключится сюда и не внесёт ясность, боюсь, нам остаётся только догадываться, что именно происходит. Если хочешь исключить статический IP или DHCP как возможную причину, вот что я предлагаю: 1. Назначь окно техобслуживания для своих пользователей. 2. Сделай точки доступа DHCP-клиентами. 3. Перезагрузи сервер. Если после этого проблемы с сервером исчезнут, можешь создать специальный DHCP-диапазон (с адресами только для твоих точек доступа) с резервированными адресами на основе MAC-адресов. Если это сработает, объяснения почему не будет, но, по крайней мере, проблема решится. С уважением.
 
Ну, это должно решать администратор. AP должны работать в двух режимах, как и положено. Мы назначаем всем активным сетевым устройствам и серверам статические IP-адреса. У нас есть пул адресов для них. Так что если по какой-то причине, например, во время обслуживания DHCP-сервер не работает, мы не теряем с ними связь. Этот пул выделен вне зоны DHCP. Поэтому у нас никогда не было конфликтов.

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

Есть хорошие советы, например, очищать ARP-кэш. Но зачем мне это делать при каждом перезапуске хоста? Также другие двое пользователей пишут, что у них такая же проблема. И у них, как я вижу, сеть даже проще, а проблема всё равно та же.

Я понимаю, что изолированный режим может быть полезен, особенно если AP работают в WAN-среде или если используется гостевой доступ в интернет. Но он действительно ни к чему, если AP нужны просто как точки доступа. Мы не пользуемся никакими такими функциями. Мы выбрали Unify только из-за централизованного управления. В нашем случае большинство беспроводных пользователей даже не выходят в интернет — они просто подключаются по Wi-Fi к нашей LAN, используя беспроводные SIP-телефоны, планшеты и прочие мобильные устройства для работы с внутренними сервисами. Поэтому мы хотим, чтобы AP оставались активными даже при отсутствии интернет-соединения или когда шлюз недоступен.

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

Раньше я работал с Cisco, DLink, Linksys и Zyxel. Впервые вижу точку доступа, которая требует адрес шлюза для работы. По сути, AP — это мост, устройство второго уровня, которое должно работать без вмешательства в сеть третьего уровня, если это нужно. Ему даже не нужен собственный IP-адрес, кроме как для интерфейса конфигурации. Я ошибаюсь?
 
Согласен. Раньше я вел Excel-файл с названием точки доступа, местоположением, IP, моделью, MAC-адресом, версией прошивки и прочим для всех точек. Полная трата времени, с UniFi вся эта информация прямо в контроллере. Это сильно экономит время и избавляет от ошибок! Сейчас все мои точки работают через DHCP.
 
Мне нужно задать самый очевидный вопрос. Зачем вы тратите силы на назначение статических адресов UniFi-точкам доступа, если у вас есть консоль для их управления? В этом и прелесть системы — не нужно тратить время на индивидуальную настройку каждого устройства. За годы работы с сетями, сталкиваясь с проблемами из-за чужих DHCP-серверов, могу сказать, что это одни из самых неприятных и сложных для диагностики сетевых проблем. Симптомы могут быть неочевидными, и можно потратить уйму времени, прежде чем случится «ага»-момент, когда понимаешь, что другой DHCP-сервер объясняет эти симптомы.

При этом Windows-серверы очень вежливы и отключают свою службу DHCP, если в сети выявляют ещё один DHCP-сервер. Вы сказали, что ваш сервер выдаёт DHCP, но не уточнили, какой именно сервер. На Windows-сервере служба DHCP остановится, если в сети появится другой DHCP-сервер.

Также мне кажется странным, что когда ваш шлюз offline, UniFi-точка доступа «забирает» этот адрес. Обязательно очищайте ARP-кэш при проверке любых предположений о том, кто и что делает в сети. Вы ещё упомянули, что меняли шлюз на точках доступа, назначая ему адрес контроллера, и когда он был offline, они получали именно этот адрес. Очень странное поведение. Ещё раз повторюсь — будьте поосторожнее и очищайте всё, что может искажать информацию об адресах в сети.
 
Мое подозрение — это проблема с сетевыми настройками Windows. Именно Windows сообщает о конфликте IP-адресов, но, судя по тому, что описывали пользователи с этой проблемой, нет никаких доказательств, что сами точки доступа действительно сбрасываются на «конфликтующий» IP-адрес.
 
Сначала я установил ПО на тот же ПК/Kerio GatewayInternet с DHCP-сервисом, где и получил сообщение. Потом установил только на другой ПК и выставил другой диапазон IP:  
IP сервера: 10.10.5.1  
IP точек доступа: 10.10.5.x  
Но сообщение о дублировании IP всё равно появляется.

Подробности:  
Привет, gsloop, да, это именно моя настройка.  
Интернет <-> Роутер/NAT/ПК/Сервер <-> Свитч APC/Unifi сервер <-> Свитч A.  
Свитч A <-> Свитч B <-> Unifi AP 1 и AP 2.  
Свитч A <-> Свитч C <-> Unifi AP 3 - AP 7.  

Я назначил статические IP для UniFi сервера и всех точек доступа.  
Windows выдает на том ПК всплывающее сообщение о дублировании IP.

Ответ на первый вопрос:  
Свитч неуправляемый.  
ПК/UniFi сервер: 10.10.5.1  
Настройки UniFi AP: 10.10.5.2 - 10.10.5.8  
Маска: 255.255.255.0  
Шлюз: 10.10.5.1

Ответ на второй вопрос:  
DHCP-сервер: IP: 192.168.100.1, Scope Options: 192.168.100.0/255.255.255.0, шлюз: 192.168.100.1, DNS: 200.48.225.130  
Gateway Internet ПК имеет IP: 192.168.100.1 с Kerio Control.  
Других подключенных устройств нет.  
Я не использую VLAN, у меня нет свитча уровня 3.
 
Да, похоже, некоторые используют IP контроллера в качестве адреса шлюза. Не понимаю, зачем так делать. Я всегда указываю в качестве шлюза настоящий адрес роутера.
 
Я никогда не настраивал систему таким образом, но не думаю, что есть какое-то запретительное правило, которое мешало бы сделать это так. Что касается того, что у нескольких человек одна и та же проблема — возможно. Но все просьбы подробно описать настройки до сих пор игнорировались. Я делал множество настроек с разными версиями, и другие тоже — намного больше меня, — и никто из тех, кто успешно настраивал UniFi, никогда не сталкивался с чем-то подобным. При неправильной настройке сети легко получить такие проблемы — и очень просто допустить небольшую ошибку, из-за которой все заработает не так, как ожидаешь, с результатами, которые вполне могли бы выглядеть как описанные симптомы. Так что я скептически настроен.  
- Greg
 
Похоже, у некоторых тоже есть эта «проблема» (atnet640 и melmer). Возможно, я неправильно понимаю ваши сообщения, так что, может, вы вдвоём поможете прояснить ситуацию. Я пытаюсь найти общую черту: вы, ребята, используете Windows-сервер как шлюз для этих AP? То есть не реальное аппаратное устройство? (Кстати, это вообще нормально для Ubiquiti AP? Извиняюсь, если вопрос новичка).
Страницы: 1
Читают тему (гостей: 1)