Привет, я столкнулся с повторяющейся проблемой с mesh AP, работающими на UniFi Network Application 9.1.120 (также наблюдается с версии 9.1.x) в гибридной среде, где:
* AP подключаются через беспроводной линк (mesh),
* Их единственный Ethernet-порт используется для предоставления доступа к сети LAN для подключенных устройств (т.е., мостинг LAN),
* У AP нет действительного upstream-соединения через Ethernet, только питание и физический линк-импульс.
В такой конфигурации AP изначально подключается корректно через mesh и предоставляет мост Ethernet-клиентам. Однако после короткого периода AP сбрасывает соединение из-за неудачной проверки линка. После восстановления mesh и моста цикл повторяется.
Что мне удалось выяснить:
Проблема, похоже, связана с тем, что IP мониторинга (target ping uplink) проверяется только через eth0, если:
* Активна SSID, которая помещает AP в ту же сетевую зону (subnet), что и LAN по умолчанию,
* AP обнаруживает живой физический линк Ethernet (через PoE-инжектор или неконтролируемый коммутатор),
* Логика контроллера затем назначает eth0 в качестве предполагаемого интерфейса линка, независимо от фактической работоспособности маршрута.
Поскольку интерфейс Ethernet физически активен, но не имеет маршрута к IP мониторинга, ping завершается неудачей. Затем AP сбрасывает линк, даже если mesh-путь работоспособен и изначально работал. Это приводит к:
* Прерывистому отключению клиентов на Ethernet-мосте,
* Повторным подключениям mesh,
* Ложному предположению, что Ethernet предпочтителен из-за перекрытия subnet.
Ожидаемое поведение:
AP должен:
* Оценивать все активные интерфейсы для достижения IP мониторинга, а не только eth0,
* Или, по крайней мере, уважать фактические метрики маршрута при определении пути линка,
* Продолжать использовать mesh-линк, когда Ethernet присутствует, но не имеет маршрута.
Обходные пути (проверены и работают):
* Отключение всех SSID на mesh AP предотвращает его переключение на eth0-линк.
* Изменение IP мониторинга на один, находящийся за пределами локальной LAN subnet (принудительно направляя маршрут через mesh-путь), стабилизирует конфигурацию.
* В качестве альтернативы, отключение eth0 с помощью ifconfig или использование кабеля только для PoE предотвращает ложное обнаружение, но это — хаки.
Запрос функции:
Пожалуйста, рассмотрите возможность реализации одного или обоих из следующего:
* Агностичные интерфейсы проверки работоспособности линка — ping из всех потенциальных интерфейсов или из того, у которого лучше маршрут.
* Заблокировка интерфейса линка, определенная пользователем, позволяющая администраторам принудительно использовать только mesh-операцию, даже если Ethernet физически подключен.
Это значительно улучшит поддержку гибридных mesh-развертываний, где Ethernet используется для доступа к клиентам, а не для линка.
* AP подключаются через беспроводной линк (mesh),
* Их единственный Ethernet-порт используется для предоставления доступа к сети LAN для подключенных устройств (т.е., мостинг LAN),
* У AP нет действительного upstream-соединения через Ethernet, только питание и физический линк-импульс.
В такой конфигурации AP изначально подключается корректно через mesh и предоставляет мост Ethernet-клиентам. Однако после короткого периода AP сбрасывает соединение из-за неудачной проверки линка. После восстановления mesh и моста цикл повторяется.
Что мне удалось выяснить:
Проблема, похоже, связана с тем, что IP мониторинга (target ping uplink) проверяется только через eth0, если:
* Активна SSID, которая помещает AP в ту же сетевую зону (subnet), что и LAN по умолчанию,
* AP обнаруживает живой физический линк Ethernet (через PoE-инжектор или неконтролируемый коммутатор),
* Логика контроллера затем назначает eth0 в качестве предполагаемого интерфейса линка, независимо от фактической работоспособности маршрута.
Поскольку интерфейс Ethernet физически активен, но не имеет маршрута к IP мониторинга, ping завершается неудачей. Затем AP сбрасывает линк, даже если mesh-путь работоспособен и изначально работал. Это приводит к:
* Прерывистому отключению клиентов на Ethernet-мосте,
* Повторным подключениям mesh,
* Ложному предположению, что Ethernet предпочтителен из-за перекрытия subnet.
Ожидаемое поведение:
AP должен:
* Оценивать все активные интерфейсы для достижения IP мониторинга, а не только eth0,
* Или, по крайней мере, уважать фактические метрики маршрута при определении пути линка,
* Продолжать использовать mesh-линк, когда Ethernet присутствует, но не имеет маршрута.
Обходные пути (проверены и работают):
* Отключение всех SSID на mesh AP предотвращает его переключение на eth0-линк.
* Изменение IP мониторинга на один, находящийся за пределами локальной LAN subnet (принудительно направляя маршрут через mesh-путь), стабилизирует конфигурацию.
* В качестве альтернативы, отключение eth0 с помощью ifconfig или использование кабеля только для PoE предотвращает ложное обнаружение, но это — хаки.
Запрос функции:
Пожалуйста, рассмотрите возможность реализации одного или обоих из следующего:
* Агностичные интерфейсы проверки работоспособности линка — ping из всех потенциальных интерфейсов или из того, у которого лучше маршрут.
* Заблокировка интерфейса линка, определенная пользователем, позволяющая администраторам принудительно использовать только mesh-операцию, даже если Ethernet физически подключен.
Это значительно улучшит поддержку гибридных mesh-развертываний, где Ethernet используется для доступа к клиентам, а не для линка.