Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1
RSS
Странный конфликт IP 0.0.0.0, UniFi Network
 
Всем привет! У нас клиент, который использует UniFi. Сегодня утром они отключили и снова включили брандмауэр на ISA-сервере — в общем, дело обычное, но он стал постоянно сообщать о конфликте IP на внутреннем интерфейсе, при этом с IP 0.0.0.0.  

Потом выяснилось, что это связано с одним из UniFi AP — его отключили, но затем другой UniFi AP тоже якобы вызвал конфликт с IP 0.0.0.0.  

Все UniFi AP отключили, система восстановилась, что интересно, она продолжила работать и после того, как AP снова подключили.  

Это известная проблема с UniFi? Есть ли решение? Спасибо 😀
 
Привет, у меня точно такая же проблема с конфликтом IP 0.0.0.0. Ты решил свою проблему? С уважением,
 
Забавно, но не помогает 🙁
 
Рад, что помог... Не переживай... Отметь как решённое или поставь плюс каждому, кто помог... С уважением.
 
Обновил версию до 2.4.3 http://www.ubnt.com/download#UniFi:AP Ошибок нет уже 3 часа...
 
Для меня это решение проблемы не решает 😠
 
Обходное решение: отключите «Uplink Connectivity Monitor»  
UniFi controller -> Settings -> System -> «Uplink Connectivity Monitor»  

Использовать шлюз по умолчанию  
Когда «Uplink Connectivity Monitor» включен, точка доступа ищет шлюз по умолчанию и отправляет ARP-запрос с «Sender ip address 0.0.0.0».  
Что за черт?  
Когда «Uplink Connectivity Monitor» выключен, точка доступа ищет шлюз по умолчанию и отправляет ARP-запрос с «Sender ip address ap_ip_address».
 
не решено
 
Потеря связи с контроллером или с DHCP-сервером? Межсетевой экран блокирует запрос к DHCP-серверу? VLAN?
 
Спасибо за ответы. Я снял трафик на LAN-интерфейсе шлюза и приложил файл (см. выше). На картинке — UniFi AP PRO. Наш AP: UniFi AP (без PRO, только один FE-порт). Я написал: «Gateway: Win7 + UniFiController2.3.9 + FireWall». Сейчас: шлюз — сервер с Windows 7 и программой FireWallController, DHCP — на другом сервере в локальной сети. Вижу конфликт с разными точками доступа. Также наблюдаю эту проблему в другом объекте (сеть с другим шлюзом и точками доступа). P.S. Волшебной кнопки нет... Я знаю, это отстой. 😉
 
Окей, как говорил Ганнибал Каннибал, давайте разберём вопрос по частям... Шлюз — это что? Cisco? Фаервол? DHCP-сервер? Если можешь, просто поменяй его на другой шлюз и протестируй. В моём другом сообщении я писал — сделай wireshark с вторичного подключения в AP… с помощью wireshark. Подключи основной порт к свитчу, вторичный — к ноутбуку. Запусти wireshark. Если не работает — сделай сброс до заводских настроек... переадоптируй AP. В мире компьютеров нет волшебной кнопки, нужна только терпеливость и поэтапное исключение вариантов, пока не найдёшь и не решишь проблему. Извини, я больше помочь не могу... :(
 
Извините, я вас не понимаю. 😳 «ручно пинговать точки доступа — плохая примета...» Где? У интерфейса GW lan статический IP. Точки доступа получают правильный IP с DHCP-сервера. Проверьте кабели... хороший ИБП... Кабель — в порядке, питание — в порядке. Но моя проблема серьёзнее, чем на первом уровне OSI: у меня конфликт адресов, default-GW и точек доступа. Почему?
 
Окей, дело не в контроллере, а в пути к контроллеру. Измени IP с ручного на DHCP, остальное есть в моём предыдущем сообщении.
 
Я перенёс контроллер с GW на другой сервер в локальной сети. Это не помогло.
 
Проблема скорее всего в контроллере... или в DHCP. Думаю, тебе нужно вручную включить DHCP — пинговать точки доступа — плохая примета, на мой взгляд. Подключись к одной через ноутбук, присоедини кабель к вторичному порту и запусти Wireshark. Там должна быть строка вроде «broadcast 255.255.255.0», а в следующей строке ты найдешь проблему. Точка доступа должна найти контроллер и пинговать его, а также посылать heartbeat. Точка доступа должна быть подключена либо к PoE-коммутатору, либо к PoE-адаптеру (я их не люблю). Проверь стабильность питания и лучше подключи устройства к нормальному ИБП. Проверь кабели — они должны быть Cat5e, а не Cat5, иначе будут проблемы.
 
Конфликт IP на локальном интерфейсе шлюза => Win7 автоматически генерирует IP-адрес 169.**.**.** => локальная сеть не общается с интернетом и другими сетями, AP не может подключиться к контроллеру и т.д. Наша локальная сеть — один широковещательный домен. Все AP имеют IP. AP с MAC-адресом 00:27:22:e8:52:76 настроен с IP 192.168.61.116/24, шлюз по умолчанию 192.168.61.254.
 
+1 AP UniFi и GatewayGatway: Win7 + UniFiController2.3.9 + FireWall. Локальный IP интерфейса сети 192.168.61.254/24. После перезагрузки GateWay — конфликт IP на локальном интерфейсе. Когда я меняю IP локального интерфейса, а потом снова ставлю 192.168.61.254, я вижу (сниффинг локального сетевого интерфейса на GW): файл WireShark в приложении, системный лог.
Страницы: 1
Читают тему (гостей: 1)