DHCP проблемы на точках доступа
 

Гуру, посоветуйте, пожалуйста.

Опишу ситуацию:
Имеется сеть (предположим 192.168.0.0/24);
В сети установлены и настроены две беспроводных точки доступа TP-LINK TL-WA701ND (обозначу их TP1 с адресом 192.168.0.200 и TP2 с адресом 192.168.0.220);
TP1 стоит на 1м этаже TP2 соответственно на 2м;
Точки доступа находятся на разных этажах здания и ходят в интернет так: точка доступа -> общий свич (подключены этажи) -> шлюз предприятия -> провайдер;
На обеих точках доступа работает DHCP (TP1 раздает адреса с 201 по 219, TP2 раздает адреса с 221 по 239);
На обеих точках доступа включен режим АР;
Между собой по вафле точки друг друга не видят - между ними железобетонное перекрытие, соответственно и клиенты видят только одну точку.


Проблема:
При попытке подключить клиента к точке TP2 происходит линк, как и положено. Проверяю состояние подключения на клиенте и обнаруживаю адрес, принадлежащий диапазону DHCP точки TP1. Хотя клиент видит SSID точки TP2 и подключение идет именно к ней. Проверяю на точке TP2 арендованные адреса - подключенного клиента нет. Он оказывается в списке арендованных адресов на точке TP1.


Что сделано/испытано:
Отключил DHCP на точке TP1. Подключаю клиента к TP2 - адрес выдается верный, из ее диапазона.
Включаю DHCP на точке TP1. Переподключаю клиента к TP2 - опять прокидывает и выдает адрес из чужого диапазона.

Оставил включенным DHCP на обеих точках. На TP2 прописываю правило резервирования адреса по MAC. При этом резервируемый адрес беру из диапазона DHCP данной точки. Переподключаю клиента к TP2 - прокидывает и выдает адрес из чужого диапазона.

Оставил включенным DHCP на обеих точках. На TP2 прописываю правило резервирования адреса по MAC. При этом резервируемый адрес беру НЕ из диапазона DHCP данной точки. Переподключаю клиента к TP2 - точка выдает адрес, прописанный в правилах резервирования по MAC. Но это тоже не дело.

Вопрос:
Как исправить ситуацию, чтобы точка доступа TP2 присваивала клиентам свой диапазон адресов DHCP? Мне нужно, чтоб точка по-честному отдавала адреса без вот таких "костылей", потому как на шлюзе у меня прописаны отдельные правила и доступные протоколы для выхода в интернет для диапазонов DHCP этих точек. И "вылавливание" MAC адресов клиентов лишено смысла, так как к точкам коннектятся посетители организации.

у вас ещё есть DHCP сервер в сети? какой у него диапазон адресов?

DHCP сервера работают только на указанных точках доступа (на каждой свой). Остальная сеть - статика.

Похоже DHCP на ТР1 просто быстрее отвечает на запрос клиента, так как все соединено через общий свитч. Проверьте может на ТР2 задержка какая выставлена?

grapher, не занимайтесь кулибинством. Сделайте единый DHCP-сервер, а на точках отключите.

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

Для uel
Там и настроек то особо нет, все стандартно: SSID, LAN, WLAN, DHCP. Ну и мониторинг в виде лога. Хотя вот надо лог покурить

сделайте резервацию по MAC адресам для каждого клиента.

exo,

Vexel, значит нужно этот смысл найти.

grapher, сделайте как советует Angry Demon , а шлюз какой?

uel, Шлюз Kerio Control 7.2

стоп стоп стоп, как я укажу единому DHCP серверу, что адреса отдать той или иной точке доступа? или мне копать в сторону настроек на шлюзе?

ИМХО здесь нужно копать в сторону VLAN. Но как я понял у вас этой возможности нет. Я бы на вашем месте взял дешевенький свитч, одну ТД отключил от общего свитча и воткнул в дешевый, на шлюз добавил еще одну сетевую, задал диапазон из другой подсети, на шлюзе разрулил бы Traffic policy и HTTP policy для двух подсетей. Вроде несложный и дешевый вариант.

Здравствуйте, может быть я чего-то недопонимаю, но DHCH транслирует адреса целиком на подсеть "предположим 192.168.0.0/24"
По этому может Вам стоит включить ТД в режим Bridge, а DHCP kerio (или че то там) будет раздавать IP адреса по указанным Вами MAC адресам. Или, как посоветовал Вам uel делить сеть на vlan (если конечно это необходимо).

Всем спасибо за отзывы! Видимо пока придётся поделить сеть на VLAN.