Добрый день, уважаемые форумчане.

Занимаюсь инсталляцией с 2 контроллерами AIR-WLC4402-12-K9 и точками AIR-LAP1142N-E-K9.

Хочу сделать, чтобы точки и интерфейс контроллера были в разных маршрутизируемых L2 сетях.

Чтобы передать точкам адрес контроллера - делаю все как здесь написанно:
http://www.cisco.com/en/US/tech/tk722/t ... 14fe.shtml

Т.е. пытаюсь передать адрес контроллера через dhcp опцию:
ip dhcp pool LAP
vrf VRF-WIRELESS-INFR
network 172.22.89.0 255.255.255.128
default-router 172.22.89.1
option 43 hex f104.ac16.598d //последние 4 октета - адрес контроллера 172.22.89.141

При этом точки успешно получают адреса.
Связь между этими сетями есть - и точки из сети контроллера пингуются.
Но ни в какую не хотят регистрироваться...

Самое интересной - по такой схеме у меня уже успешно работает аналогичная инсталляция с более старыми точками 1242/1311.

Как только помещаю точки в один vlan с контроллером - они сразу регистрируются без всяких опций.
Т.е. проблема совмесимости оси и модели точек - исключена.

Может кто сталкивался с такой проблемой? Всю голову себе сломал...
Буду очень признателен за помощь

О, какие-то похожие грабли были...

По-моему, там какой-то более хитрый формат адреса контроллера. Вот убей не помню, откуда мы снифанули, что точки шлют для поиска контроллера, но то ли в "" надо, толи чего-то еще добавить.

Кстати, на форуме всплывала похожая тема (там имя файла передавалось). Может проблема похожая?

Так и не поборол((((

Запустил на контроллере дебаг, и выяснилось, что dhcp настройки контроллер вполне видит - он просто не хочет регистрировать чере L3...

Что значит *spamReceiveTask: ?
Почему он игнорирует?

(Cisco Controller) >debug capwap events enable
(Cisco Controller) >*spamReceiveTask: Jan 20 14:30:17.359: f0:25:72:13:df:50 Discovery Request from 72.22.89.67:18947
*spamReceiveTask: Jan 20 14:30:17.445: f0:25:72:7c:81:f0 Discovery Request from 172.22.89.66:64945
*spamReceiveTask: Jan 20 14:30:27.360: f0:25:72:13:df:50 Discovery Request from 172.22.89.67:18947
*spamReceiveTask: Jan 20 14:30:27.446: f0:25:72:7c:81:f0 Discovery Request from 172.22.89.66:64945
*spamReceiveTask: Jan 20 14:30:37.361: f0:25:72:13:df:50 Discovery Request from 172.22.89.67:18947
*spamReceiveTask: Jan 20 14:30:37.447: f0:25:72:7c:81:f0 Discovery Request from 172.22.89.66:64945
*spamReceiveTask: Jan 20 14:30:47.363: f0:25:72:13:df:50 Discovery Request from 172.22.89.67:18947
*spamReceiveTask: Jan 20 14:30:47.448: f0:25:72:7c:81:f0 Discovery Request from 172.22.89.66:64945
*spamReceiveTask: Jan 20 14:30:57.364: f0:25:72:13:df:50 Discovery Request from 172.22.89.67:18947
*spamReceiveTask: Jan 20 14:30:57.449: f0:25:72:7c:81:f0 Discovery Request from 172.22.89.66:64945
*spamReceiveTask: Jan 20 14:31:32.870: f0:25:72:13:df:50 Discovery Request from 172.22.89.68:18947

В общем выяснилось следующее:

С DHCP опцией все хорошо.

Проблема была в том, что managamenеt интерфейс и ap-managament с точками - были в разных VRF-х.
А для того, что бы точки регистрировались через L3 - необходимо чтобы точки видели оба интерфейса managamenеt и ap-managament.

Самое удивительное в этой истории - если точки в одной L2 сети с ap-managament - managament интерфейс им нафиг не нужен. Этот факт ввел меня в заблуждения, и я долгое время не пробовал загнать их в общий vrf.

Вот такой вот не логичный бред. Зачем для регистрации точек нужен интефейс, который сделан для управления веб-мордой?

Тему полагаю можно закрывать.