Отладочная информация упрощенной точки доступа
Если в отладочных сообщениях контроллера не указан запрос присоединения, то можно выполнить отладку процесса на упрощенной точке доступа при условии наличия у нее консольного порта. Следующие команды позволяют просмотреть процесс загрузки точки доступа, однако перед этим необходимо вначале войти в разрешенный режим (пароль по умолчанию – «Cisco»).
· debug dhcp detail—– отображает сведения, связанные с параметром DHCP 43.
· debug ip udp—– отображает пакеты присоединения/обнаружения, направляемые контроллеру, а также запросы DHCP и DNS (все эти данные представляют собой пакеты UDP. Порт 12223 – исходный порт контроллера).
· debug lwapp client event—– отображает события LWAPP для точки доступа.
· undebug all— отключает отладочные сообщения на точке доступа.
Ниже приведен пример выходных данных команды debug ip udp. Этот фрагмент вывода даёт представление о пакетах, которые посылаются точкой LAP во время процесса загрузки для присоединения к контроллеру.
UDP: sent src=10.77.244.199(20679), dst=10.77.244.208(12223)
!--- LWAPP Discovery Request sent to a controller to which
!--- the AP was previously registered to.
UDP: sent src=10.77.244.199(20679), dst=172.16.1.50(12223)
!--- LWAPP Discovery Request using the statically configured controller information.
UDP: sent src=10.77.244.199(20679), dst=255.255.255.255(12223)
!--- LWAPP Discovery Request sent using subnet broadcast.
UDP: sent src=10.77.244.199(20679), dst=172.16.1.51(12223)
!--- LWAPP Join Request sent to AP-Manager interface on statically configured controller.
Предотвращение проблем, связанных с DHCP
Неверная настройка параметров, связанных с DHCP, может сделать невозможным получение IP-адреса по DHCP для упрощенных точек доступа, использующих этот протокол. В этом разделе поясняется работа DHCP с контроллерами беспроводных сетей (WLC) и приводятся рекомендации, позволяющие избежать связанных с DHCP проблем.
С точки зрения протокола DHCP контроллер ведет себя как маршрутизатор со вспомогательным IP-адресом. Другими словами, он заполняет IP-адрес шлюза и переадресует запрос посредством одноадресного пакета непосредственно на DHCP-сервер.
В возвращенном предложении DHCP контроллер заменяет IP-адрес DHCP-сервера своим виртуальным IP-адресом. Это необходимо по той причине, что при переключении между точками доступа операционная система Windows первым делом пытается обратиться к DHCP-серверу для обновления адреса.
С IP-адресом DHCP-сервера 1.1.1.1 (типичный виртуальный IP-адрес на контроллере) контроллер может перехватить пакет и оперативно ответить на запрос Windows.
Из-за этого, в частности, виртуальный IP-адрес на всех контроллерах совпадает. Если ноутбук с ОС Windows будет перемещен к точке доступа на другом контроллере, то он попробует обратиться к виртуальному интерфейсу контроллера. Благодаря возникновению события подвижности и передаче контекста новый контроллер, к которому перейдет клиент Windows, уже располагает всей необходимой информацией для повторного ответа на запрос Windows.
Если на контроллере требуется использовать внутренний DHCP-сервер, то достаточно поместить IP-адрес управления DHCP-сервера на динамический интерфейс, созданный для подсети. Затем этот интерфейс нужно назначить беспроводной локальной сети (WLAN).
Причина, по которой контроллеру нужен IP-адрес в каждой подсети, – это возможность заполнить адрес шлюза DHCP в запросе DHCP.
Ниже перечислены основные моменты, которые следует иметь в виду при настройке DHCP-серверов для беспроводной локальной сети:
1. IP-адрес DHCP-сервера не должен находиться в динамической подсети, принадлежащей контроллеру. Он будет заблокирован, однако это можно отменить следующей командой:
2. config network mgmt-via-dynamic-interfaceon version 4.0 only
(command not available in version 3.2)
3. Контроллер будет пересылать DHCP-трафик в виде одноадресных пакетов со своего динамического интерфейса (в более поздних версиях программы), используя свой IP-адрес на этом интерфейсе. Следует убедиться в том, что имеющиеся межсетевые экраны пропускают трафик с этого адреса на DHCP-сервер.
4. Удостоверьтесь в том, что отклик DHCP-сервера достигает динамического адреса контроллера в этой сети VLAN через имеющиеся межсетевые экраны. Отправьте эхозапрос на динамический адрес интерфейса с DHCP-сервера. Отправьте эхозапрос на DHCP-сервер с исходным IP-адресом шлюза динамического интерфейса.
5. Убедитесь в том, что сеть VLAN точки доступа разрешена на коммутаторах и маршрутизаторах, а соответствующие порты настроены в качестве магистральных, позволяя пропускать через проводную сеть пакеты (в т.ч. пакеты DHCP), снабженные меткой этой сети VLAN.
6. Убедитесь, что сервер DHCP настроен для назначения IP-адреса сети VLAN точки доступа. Можно также настроить WLC в качестве DHCP-сервера.
7. Убедитесь в том, что IP-адрес контроллера на его динамическом интерфейсе находится в пределах одного из диапазонов DHCP на DHCP-сервере.
8. Наконец, убедитесь в том, что используемый вами сервер DHCP не относится к категории принципиально неспособных обрабатывать одноадресные DHCP-запросы, например PIX.
Если вам не удается решить проблему с DHCP, существуют 2 других решения:
· Попробуйте использовать внутренний сервер DHCP. В качестве адреса DHCP-сервера на динамическом интерфейсе настройте IP-адрес управления и затем выберите внутренний пул DHCP. Если диапазон DHCP включен, это решение должно работать.
· Проверьте отсутствие ответа на запрос DHCP, запротоколировав вывод в интерфейсе командной строки (консоли или SSH) от следующих команд:
· 0. debug mac addr <mac address>
· 1. debug dhcp message enable
2. debug dhcp packet enable
Это должно указывать на то, что пакет DHCP передан, но контроллер не получил ответ. Наши инженеры осуществляют системное администрирование только после предварительной подготовки.
Наконец, в свете безопасности контроллера не рекомендуется помещать сеть VLAN или подсеть в состав контроллера, также содержащего упрощенные точки доступа, если последний не находится в подсети интерфейса управления.
Примечание. Сервер RADIUS или DHCP-сервер не должен находиться ни в одной из динамических подсетей интерфейса контроллера. Система безопасности блокирует возвращающиеся пакеты, которые пытаются обратиться к контроллеру.
Применение серверов SYSLOG для устранения неполадок, связанных с процессом присоединения LAP
В выпуске 5.2 программного обеспечения контроллера предусмотрена возможность настройки точек доступа для отправки всех ошибок, связанных с управлением и инициализацией беспроводных точек доступа (CAPWAP), на сервер SYSLOG. В контроллере не нужно разрешать каких-либо команд отладки, поскольку все сообщения об ошибках CAPWAP можно просмотреть с сервера SYSLOG.