Беспроводные сети : Контроллеры беспроводной локальной сети Cisco серии 4400

Расследуйте легкую точку доступа, не присоединяющуюся к радио диспетчер LAN

26 декабря 2014 - Машинный перевод
Другие версии: PDF-версия:pdf | Перевод, выполненный профессиональным переводчиком (14 мая 2010) | Английский (26 сентября 2014) | Отзыв


Содержание


Введение

Этот документ дает обзор Процесса Открытия и Соединения Радио диспетчера LAN (WLC). Этот документ также предоставляет информацию о некоторых проблемах, почему Легкая точка доступа (LAP) не присоединяется к WLC и как расследовать проблемы.

Предпосылки

Требования

Cisco рекомендует иметь знание этих тем:

  • Элементарные знания конфигурации LAPs и Cisco WLCs

  • Элементарные знания Легкого Протокола Точки доступа (LWAPP)

Соглашения

Направьте в Cisco Технические Соглашения Подсказок для получения дополнительной информации о соглашениях документа.

Обзор процесса открытия и соединения Радио диспетчера LAN (WLC)

В Cisco Объединенная Беспроводная сеть LAPs должен сначала обнаружить и присоединиться к WLC, прежде чем они смогут обслужить беспроводных клиентов.

Первоначально, диспетчеры только управляли в Слое 2 способами. В Слое 2 способа LAPs требуется, чтобы быть на той же самой подсети как управленческий интерфейс и Слой 3 менеджера AP способа, интерфейс не присутствует на диспетчере. LAPs общается с диспетчером, использующим Слой 2 герметизации только (герметизация Ethernet), и не делает Динамического протокола конфигурации хозяина (DHCP) IP-адрес.

. Когда Слой, 3 способа на диспетчере были развиты, новый интерфейс Layer 3, названный менеджером AP был введен, в Слое 3 способа LAPs был бы DHCP IP-адрес сначала, и затем отправьте их запрос открытия к управленческому интерфейсу использование IP-адресов (Слой 3). Это позволило LAPs быть на различной подсети, чем управленческий интерфейс диспетчера. Слой 3 способа является доминировать способом сегодня. Некоторые диспетчеры и LAPs могут только выполнить Слой 3 способа.

Однако это представило новую проблему: как LAPs находил управленческий IP-адрес диспетчера, когда это было на различной подсети?

В Слое 2 способа они были обязаны быть на той же самой подсети. В Слое 3 способа, диспетчер и LAP по существу играют игру в прятки в сети. Если вы не говорите LAP, где диспетчер через выбор DHCP 43, разрешение DNS "Cisco-lwapp-controller@local_domain", или статически формируйте его, LAP не знает где в сети находить управленческий интерфейс диспетчера.

В дополнение к этим методам LAP действительно автоматически считает местную подсеть для диспетчеров с 255.255.255.255 местными передачами. Кроме того, LAP помнит управленческий IP-адрес любого диспетчера, к которому он присоединяется через перезагрузки. Поэтому при помещении LAP сначала на местную подсеть управленческого интерфейса она найдет, что управление диспетчера соединяет и помнит адрес. Это называют воспламенением. Это не помогает найти диспетчера при замене LAP позже. Поэтому, Cisco рекомендует использовать выбор DHCP 43 или методы DNS.

Когда LAPs обнаруживает контроллер, они не знают, находится ли диспетчер в Слое 2 способа или Слой 3 способа. Поэтому, LAPs всегда соединяется с управленческим адресом интерфейса диспетчера сначала с запросом открытия. Диспетчер тогда говорит LAP, какой способ это находится в ответе открытия. Если диспетчер находится в Слое 3 способа, ответ открытия содержит Слой 3 IP-адреса менеджера AP, таким образом, LAP может отправить запрос соединения к интерфейсу менеджера AP затем.

Примечание: По умолчанию и управление и интерфейсы менеджера AP оставляют нетеговыми на их VLAN во время конфигурации. В случае, если они помечены, удостоверьтесь, что они помечены к тому же самому VLAN для надлежащего получения открытия и ответа соединения от WLC.

AP LWAPP проходит этот процесс на запуске для Слоя 3 способа:

  1. Ботинки LAP и DHCPs IP-адрес, если этому ранее не назначили статический IP-адрес.

  2. LAP отправляет запросы открытия диспетчерам через различные алгоритмы открытия и строит список диспетчера. По существу LAP узнает, что как можно больше управленческого интерфейса обращается для списка диспетчера через:

    1. Выбор DHCP 43 (хороший для международных компаний, где офисы и диспетчеры находятся на различных континентах),

    2. Вход DNS для cisco-capwap-controller (хороший для местных компаний - может также использоваться для нахождения, где совершенно новый соединения APs),

      Примечание: при использовании CAPWAP удостоверьтесь, что существует вход DNS для cisco-capwap-controller.

    3. Управленческие IP-адреса диспетчеров LAP помнят ранее

    4. Слой 3 трансляции на подсети

    5. По обеспечивающему воздуху

    6. Статически формируемая информация

    Из этого списка самый легкий метод для использования для развертывания должен иметь LAPs на той же самой подсети как управленческий интерфейс диспетчера и позволить Слою LAP’s 3 передачи для нахождения диспетчера. Этот метод должен использоваться для компаний, которые имеют маленькую сеть и не владеют местным сервером DNS.

    Следующий самый легкий метод развертывания должен использовать вход DNS с DHCP. У вас могут быть многократные записи того же самого имени DNS. Это позволяет LAP обнаруживать многократные контроллеры. Этот метод должен использоваться компаниями, которые имеют всех их диспетчеров в единственном местоположении и владеют местным сервером DNS. Или, если компания имеет многократные суффиксы DNS, и диспетчеры являются отдельными суффиксом.

    Выбор DHCP 43 используется крупными компаниями для локализации информации через DHCP. Этот метод используется крупными предприятиями, которые имеют единственный суффикс DNS. Например, Cisco владеет зданиями в Европе, Австралии и Соединенных Штатах. Чтобы гарантировать, чтобы LAPs только присоединился к диспетчерам в местном масштабе, Cisco не может использовать вход DNS и должна использовать выбор DHCP 43 информации для сообщения LAPs, каков управленческий IP-адрес их локального контроллера.

    Наконец, статическая конфигурация используется для сети, которая не имеет сервера DHCP. Можно статически формировать информацию, необходимую для присоединения к диспетчеру через порт пульта и CLI AP. Для получения информации о том, как статически формировать информацию о диспетчере с помощью AP CLI, отошлите к ручному Формированию информации о Диспетчере Используя Точку доступа CLI.

    Для подробного объяснения на различных алгоритмах открытия, что использование LAPs для нахождения диспетчеров обратитесь к Регистрации LAP с WLC.

    Для получения информации о формировании выбора DHCP 43 на сервере DHCP, обратитесь к DHCP OPTION 43 для Легкого Примера Конфигурации Точек доступа Cisco Aironet.

  3. Отправьте запрос открытия каждому диспетчеру в списке и ждите ответа открытия диспетчера, который содержит имя системы, IP-адреса менеджера AP, число APs, уже приложенного к каждому интерфейсу менеджера AP и полной избыточной мощности для диспетчера.

  4. Смотрите на список диспетчера и отправьте запрос соединения диспетчеру в этом заказе (только если AP получил ответ открытия от него):

    1. Основное имя системы Диспетчера (ранее формируемый на LAP)

    2. Вторичное имя системы Диспетчера (ранее формируемый на LAP)

    3. Третичное имя системы Диспетчера (ранее формируемый на LAP)

    4. Основной диспетчер (если LAP ранее не формировался ни с какими Основными, Вторичными, или Третичными именами диспетчера. Используемый, чтобы всегда знать, который диспетчер совершенно новое соединение LAPs)

    5. Если ни одно из вышеупомянутого не замечено, загружает баланс через диспетчеров, использующих стоимость избыточной мощности в ответе открытия.

      Если два диспетчера имеют ту же самую избыточную мощность, то отправляют запрос соединения первому диспетчеру, который ответил на запрос открытия с ответом открытия. Если у единственного диспетчера есть многократные менеджеры AP в многократных интерфейсах, выберите взаимодействие менеджера AP с наименьшим количеством числа APs.

      Диспетчер ответит на все запросы открытия, не проверяя верительные грамоты AP или свидетельства. Однако запросы соединения должны иметь действительное свидетельство для получения ответа соединения от диспетчера. Если LAP не получит ответ соединения от его выбора, то LAP будет судить следующего диспетчера в списке, если диспетчер не будет формируемым (Основным/Вторичным/Третичным) диспетчером.

  5. Когда это получает ответ соединения, проверки AP, чтобы удостовериться, что это имеет то же самое изображение того из диспетчера. В противном случае AP загружает изображение от диспетчера и перезагрузок для погрузки нового изображения и начинает процесс снова и снова с шага 1.

  6. Если это имеет то же самое изображение программного обеспечения, это просит конфигурацию от диспетчера и перемещается в зарегистрированное государство на диспетчере.

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

Отладка от диспетчера

Существует несколько команд отладки на диспетчере, которого можно использовать для наблюдения этого всего процесса на CLI.

  • lwapp события отладки позволяют — Показывает пакеты открытия и пакеты соединения.

  • lwapp пакет отладки позволяет — Показывает информацию об уровне пакета пакетов соединения и открытия.

  • отладьте пополудни pki, позволяют — Показывает процесс проверки свидетельства.

  • отладка отключает - все — Выключают отладки.

С предельным применением, которое может захватить продукцию к файлу системного журнала, пульту в или обеспечить раковину (SSH) / TELNET вашему диспетчеру и войти в эти команды:

    config session timeout 120
    config serial timeout 120
    show run-config     (and spacebar thru to collect all)
 
    debug mac addr <ap-mac-address>
    (in xx:xx:xx:xx:xx format)
    debug client <ap-mac-address>

    debug lwapp events enable
    debug lwapp errors enable
    debug pm pki enable

После завоевания отладок, использования отладка отключают - вся команда для выключения всех отладок.

Когда LAP регистрируется в диспетчере, следующие секции показывают продукцию этих команд отладки.

lwapp события отладки позволяют

Эта команда предоставляет информацию о событиях LWAPP и ошибках, которые происходят во время открытия LWAPP и процесса соединения.

Это - отладка lwapp, события позволяют продукцию команды для LAP, который имеет то же самое изображение того из WLC:

Примечание: Некоторые линии продукции были перемещены во вторую линию, должную сделать интервалы между ограничениями.

debug lwapp events enable

Wed Oct 24 16:59:35 2007: 00:0b:85:5b: fb:d0 Received LWAPP DISCOVERY REQUEST from 
AP 00:0b:85:5b: fb:d0 to 00:0b:85:33:52:80 on port '2'  

!---  LWAPP discovery request sent to the WLC by the LAP.

Wed Oct 24 16:59:35 2007: 00:0b:85:5b:fb:d0 Successful transmission of 
LWAPP Discovery-Response to AP 00:0b:85:5b:fb:d0 on Port 2 

!--- WLC responds to the discovery request from the LAP.

Wed Oct 24 16:59:46 2007: 00:0b:85:5b:fb:d0 Received LWAPP JOIN REQUEST from 
AP 00:0b:85:5b:fb:d0 to 00:0b:85:33:52:81 on port '2' 

!--- LAP sends a join request to the WLC.

Wed Oct 24 16:59:46 2007: 00:0b:85:5b:fb:d0 AP ap:5b:fb:d0: 
txNonce  00:0B:85:33:52:80 rxNonce  00:0B:85:5B:FB:D0
Wed Oct 24 16:59:46 2007: 00:0b:85:5b:fb:d0 LWAPP Join-Request MTU path from 
AP 00:0b:85:5b:fb:d0 is 1500, remote debug mode is 0
Wed Oct 24 16:59:46 2007: 00:0b:85:5b:fb:d0 Successfully added NPU Entry for 
AP 00:0b:85:5b:fb:d0 (index 55) Switch IP: 10.77.244.211, Switch Port: 12223, intIfNum 2, 
vlanId 0 AP IP: 10.77.244.219, AP Port: 49085, next hop MAC: 00:0b:85:5b:fb:d0
Wed Oct 24 16:59:46 2007: 00:0b:85:5b:fb:d0 Successfully transmission of 
LWAPP Join-Reply to AP 00:0b:85:5b:fb:d0 

!--- WLC responds with a join reply to the LAP.

Wed Oct 24 16:59:46 2007: 00:0b:85:5b:fb:d0 Register LWAPP event for 
AP 00:0b:85:5b:fb:d0 slot 0 -- LAP registers with the WLC
Wed Oct 24 16:59:48 2007: 00:0b:85:5b:fb:d0 Received LWAPP CONFIGURE REQUEST from 
AP 00:0b:85:5b:fb:d0 to  00:0b:85:33:52:81 

!--- LAP requests for the configuration information from the WLC.

Wed Oct 24 16:59:48 2007: 00:0b:85:5b:fb:d0 Updating IP info for 
AP 00:0b:85:5b:fb:d0 -- static 1, 10.77.244.219/255.255.255.224, gtw 10.77.244.220
Wed Oct 24 16:59:48 2007: spamVerifyRegDomain RegDomain set for 
slot 0 code 0 regstring -A regDfromCb -AB
Wed Oct 24 16:59:48 2007: spamVerifyRegDomain RegDomain set for 
slot 1 code 0 regstring -A regDfromCb -AB
Wed Oct 24 16:59:48 2007: Send AP Timesync of 1193245188 source MANUAL
Wed Oct 24 16:59:48 2007: spamEncodeDomainSecretPayload:Send domain secret 
TSWEBRET<0d,59,aa,b3,7a,fb,dd,b4,e2,bd,b5,e7,d0,b2,52,4d,ad,21,1a,12> to 
AP 00:0b:85:5b:fb:d0
Wed Oct 24 16:59:48 2007: 00:0b:85:5b:fb:d0 Successfully transmission of 
LWAPP Config-Message to AP 00:0b:85:5b:fb:d0 

!--- WLC responds by providing all the necessary configuration information to the LAP.

Wed Oct 24 16:59:48 2007: Running spamEncodeCreateVapPayload for SSID 'eap fast'
Wed Oct 24 16:59:48 2007: Running spamEncodeCreateVapPayload for SSID 'WPA'
Wed Oct 24 16:59:48 2007: Running spamEncodeCreateVapPayload for SSID 'webauth'
Wed Oct 24 16:59:48 2007: Running spamEncodeCreateVapPayload for SSID 'eap fast'
Wed Oct 24 16:59:48 2007: Running spamEncodeCreateVapPayload for SSID 'WPA'
Wed Oct 24 16:59:48 2007: Running spamEncodeCreateVapPayload for SSID 'webauth'
.
.
.
Wed Oct 24 16:59:48 2007: 00:0b:85:5b:fb:d0 Successfully transmission of 
LWAPP Change-State-Event Response to AP 00:0b:85:5b:fb:d0
.
.
Wed Oct 24 16:59:48 2007: 00:0b:85:5b:fb:d0 Received LWAPP Up event for 
AP 00:0b:85:5b:fb:d0 slot 0! 

!--- LAP is up and ready to service wireless clients.


Wed Oct 24 16:59:48 2007: 00:0b:85:5b:fb:d0 Received LWAPP CONFIGURE COMMAND RES from 
AP 00:0b:85:5b:fb:d0
.
.
.
Wed Oct 24 16:59:48 2007: 00:0b:85:5b:fb:d0 Received LWAPP RRM_CONTROL_RES from 
AP 00:0b:85:5b:fb:d0 

!--- WLC sends all the RRM and other configuration parameters to the LAP.

Как упомянуто в предыдущей секции, когда-то LAP регистрируется в WLC, он проверяет, чтобы видеть, имеет ли он то же самое изображение диспетчера. Если изображения на LAP и WLC отличаются, LAPs загружает новое изображение с WLC сначала. Если LAP имеет то же самое изображение, оно продолжает загружать конфигурацию и другие параметры от WLC.

Вы будете видеть, что эти сообщения в отладке lwapp события позволяют продукцию команды, если LAP загружает изображение от диспетчера как часть процесса регистрации:

Wed Oct 24 17:49:40 2007: 00:0b:85:5b:fb:d0 Received LWAPP IMAGE_DATA_RES from 
AP 00:0b:85:5b:fb:d0
Wed Oct 24 17:49:40 2007: 00:0b:85:5b:fb:d0 Received LWAPP IMAGE_DATA_RES from 
AP 00:0b:85:5b:fb:d0  
Wed Oct 24 17:49:40 2007: 00:0b:85:5b:fb:d0 Received LWAPP IMAGE_DATA_RES from 
AP 00:0b:85:5b:fb:d0

Как только загрузка изображения завершена, LAP будет перезагружать и управлять открытием и присоединяться к алгоритму снова.

отладьте пополудни pki, позволяют

Как часть процесса соединения, WLC подтверждает подлинность каждого LAP путем подтверждения, что его свидетельство действительно.

Когда AP отправляет Запрос Соединения LWAPP к WLC, он включает свое свидетельство X.509 в области сообщения LWAPP. AP также производит случайную сессию ID, который также включен в Запрос Соединения LWAPP. Когда WLC получает Запрос Соединения LWAPP, он утверждает подпись свидетельства X.509 с помощью открытого ключа AP и проверяет, что свидетельство было выпущено центром сертификации, которому доверяют.

Это также смотрит на срок начала работы и время для интервала законности свидетельства AP и сравнивает ту дату и время к его собственной дате и время (следовательно, часы диспетчера должны быть установлены в близко к текущей дате и время). Если свидетельство X.509 утверждено, WLC производит случайный ключ шифрования AES. WLC устанавливает вертикально ключ AES в свой crypto двигатель так, чтобы это могло зашифровать и расшифровать будущие сообщения Контроля LWAPP, обмененные с AP. Обратите внимание на то, что пакеты данных посылают в ясном в тоннеле LWAPP между LAP и диспетчером.

Отладка пополудни pki позволяет шоу команды процесс проверки сертификации, который происходит во время фазы соединения на диспетчере. Отладка пополудни pki позволяет команду, также покажет ключ мешанины AP во время процесса соединения, если AP создаст самоподписанное свидетельство (SSC) конверсионная программа LWAPP. Если AP будет иметь Произведенное установленное свидетельство (MIC), то вы не будете видеть ключ мешанины.

Примечание: Все APs, произведенные после июня 2006, имеют MIC.

Вот продукция отладки пополудни pki, позволяют команду, когда LAP с MIC присоединяется к диспетчеру:

Примечание: Некоторые линии продукции были перемещены во вторую линию, должную сделать интервалы между ограничениями.

Thu Oct 25 13:52:59 2007: sshpmGetIssuerHandles: locking ca cert table 
Thu Oct 25 13:52:59 2007: sshpmGetIssuerHandles: calling x509_alloc() for user cert
Thu Oct 25 13:52:59 2007: sshpmGetIssuerHandles: calling x509_decode() 
Thu Oct 25 13:52:59 2007: sshpmGetIssuerHandles: <subject> C=US, ST=California, 
L=San Jose, O=airespace Inc, CN=000b8591c3c0, MAILTO=support@airespace.com 
Thu Oct 25 13:52:59 2007: sshpmGetIssuerHandles: <issuer>  C=US, ST=California, 
L=San Jose, O=airespace Inc, OU=none, CN=ca, MAILTO=support@airespace.com 
Thu Oct 25 13:52:59 2007: sshpmGetIssuerHandles: Mac Address in subject is 
00:0b:85:91:c3:c0
Thu Oct 25 13:52:59 2007: sshpmGetIssuerHandles: Cert is issued by Airespace Inc. 
Thu Oct 25 13:52:59 2007: sshpmGetCID: called to evaluate <bsnDefaultCaCert> 
Thu Oct 25 13:52:59 2007: sshpmGetCID: comparing to row 0, CA cert >bsnOldDefaultCaCert< 
Thu Oct 25 13:52:59 2007: sshpmGetCID: comparing to row 1, CA cert >bsnDefaultRootCaCert< 
Thu Oct 25 13:52:59 2007: sshpmGetCID: comparing to row 2, CA cert >bsnDefaultCaCert< 
Thu Oct 25 13:52:59 2007: sshpmGetCertFromCID: called to get cert for CID 2d812f0c 
Thu Oct 25 13:52:59 2007: sshpmGetCertFromCID: comparing to row 0, certname 
>bsnOldDefaultCaCert< 
Thu Oct 25 13:52:59 2007: sshpmGetCertFromCID: comparing to row 1, certname 
>bsnDefaultRootCaCert< 
Thu Oct 25 13:52:59 2007: sshpmGetCertFromCID: comparing to row 2, certname 
>bsnDefaultCaCert< 
Thu Oct 25 13:52:59 2007: ssphmUserCertVerify: calling x509_decode()  
Thu Oct 25 13:52:59 2007: sshpmGetCID: called to evaluate <bsnOldDefaultCaCert> 
Thu Oct 25 13:52:59 2007: sshpmGetCID: comparing to row 0, CA cert >bsnOldDefaultCaCert< 
Thu Oct 25 13:52:59 2007: sshpmGetCertFromCID: called to get cert for CID 20f00bf3 
Thu Oct 25 13:52:59 2007: sshpmGetCertFromCID: comparing to row 0, certname 
>bsnOldDefaultCaCert< 
Thu Oct 25 13:52:59 2007: ssphmUserCertVerify: calling x509_decode() 
Thu Oct 25 13:52:59 2007: ssphmUserCertVerify: user cert verfied using 
>bsnOldDefaultCaCert< 
Thu Oct 25 13:52:59 2007: sshpmGetIssuerHandles: ValidityString (current): 
2007/10/25/13:52:59
Thu Oct 25 13:52:59 2007: sshpmGetIssuerHandles: AP version is 0x400d900, 
sending Cisco ID cert...
Thu Oct 25 13:52:59 2007: sshpmGetCID: called to evaluate <cscoDefaultIdCert> 
Thu Oct 25 13:52:59 2007: sshpmGetCID: comparing to row 0, CA cert >bsnOldDefaultCaCert< 
Thu Oct 25 13:52:59 2007: sshpmGetCID: comparing to row 1, CA cert >bsnDefaultRootCaCert< 
Thu Oct 25 13:52:59 2007: sshpmGetCID: comparing to row 2, CA cert >bsnDefaultCaCert< 
Thu Oct 25 13:52:59 2007: sshpmGetCID: comparing to row 3, CA cert >bsnDefaultBuildCert< 
Thu Oct 25 13:52:59 2007: sshpmGetCID: comparing to row 4, CA cert >cscoDefaultNewRootCaCert<  
Thu Oct 25 13:52:59 2007: sshpmGetCID: comparing to row 5, CA cert >cscoDefaultMfgCaCert< 
Thu Oct 25 13:52:59 2007: sshpmGetCID: comparing to row 0, ID cert >bsnOldDefaultIdCert< 
Thu Oct 25 13:52:59 2007: sshpmGetCID: comparing to row 1, ID cert >bsnDefaultIdCert< 
Thu Oct 25 13:52:59 2007: sshpmGetCID: comparing to row 2, ID cert >bsnSslWebadminCert< 
Thu Oct 25 13:52:59 2007: sshpmGetCID: comparing to row 3, ID cert >bsnSslWebauthCert<  
Thu Oct 25 13:52:59 2007: sshpmGetIssuerHandles: Airespace ID cert ok; sending it... 
Thu Oct 25 13:52:59 2007: sshpmGetCID: called to evaluate <bsnOldDefaultIdCert> 
Thu Oct 25 13:52:59 2007: sshpmGetCID: comparing to row 0, CA cert >bsnOldDefaultCaCert< 
Thu Oct 25 13:52:59 2007: sshpmGetCID: comparing to row 1, CA cert >bsnDefaultRootCaCert< 
Thu Oct 25 13:52:59 2007: sshpmGetCID: comparing to row 2, CA cert >bsnDefaultCaCert< 
Thu Oct 25 13:52:59 2007: sshpmGetCID: comparing to row 3, CA cert >bsnDefaultBuildCert< 
Thu Oct 25 13:52:59 2007: sshpmGetCID: comparing to row 4, CA cert >cscoDefaultNewRootCaCert< 
Thu Oct 25 13:52:59 2007: sshpmGetCID: comparing to row 5, CA cert >cscoDefaultMfgCaCert< 
Thu Oct 25 13:53:03 2007: sshpmGetCID: comparing to row 0, ID cert >bsnOldDefaultIdCert< 
Thu Oct 25 13:53:03 2007: sshpmGetCertFromHandle: calling sshpmGetCertFromCID() 
with CID 0x156af135 
Thu Oct 25 13:53:03 2007: sshpmGetCertFromCID: called to get cert for CID 156af135 
Thu Oct 25 13:53:03 2007: sshpmGetCertFromCID: comparing to row 0, 
certname >bsnOldDefaultCaCert< 
Thu Oct 25 13:53:03 2007: sshpmGetCertFromCID: comparing to row 1, 
certname >bsnDefaultRootCaCert< 
Thu Oct 25 13:53:03 2007: sshpmGetCertFromCID: comparing to row 2, 
certname >bsnDefaultCaCert< 
Thu Oct 25 13:53:03 2007: sshpmGetCertFromCID: comparing to row 3, 
certname >bsnDefaultBuildCert< 
Thu Oct 25 13:53:03 2007: sshpmGetCertFromCID: comparing to row 4, 
certname >cscoDefaultNewRootCaCert< 
Thu Oct 25 13:53:03 2007: sshpmGetCertFromCID: comparing to row 5, 
certname >cscoDefaultMfgCaCert< 
Thu Oct 25 13:53:03 2007: sshpmGetCertFromCID: comparing to row 0, 
certname >bsnOldDefaultIdCert< 
Thu Oct 25 13:53:03 2007: sshpmGetCertFromHandle: calling sshpmGetCertFromCID() 
with CID 0x156af135 
Thu Oct 25 13:53:03 2007: sshpmGetCertFromCID: called to get cert for CID 156af135 
Thu Oct 25 13:53:03 2007: sshpmGetCertFromCID: comparing to row 0, 
certname >bsnOldDefaultCaCert< 
Thu Oct 25 13:53:03 2007: sshpmGetCertFromCID: comparing to row 1, 
certname >bsnDefaultRootCaCert< 
Thu Oct 25 13:53:03 2007: sshpmGetCertFromCID: comparing to row 2, 
certname >bsnDefaultCaCert<  
Thu Oct 25 13:53:03 2007: sshpmGetCertFromCID: comparing to row 3, 
certname >bsnDefaultBuildCert< 
Thu Oct 25 13:53:03 2007: sshpmGetCertFromCID: comparing to row 4, 
certname >cscoDefaultNewRootCaCert< 
Thu Oct 25 13:53:03 2007: sshpmGetCertFromCID: comparing to row 5, 
certname >cscoDefaultMfgCaCert< 
Thu Oct 25 13:53:03 2007: sshpmGetCertFromCID: comparing to row 0, 
certname >bsnOldDefaultIdCert< 
Thu Oct 25 13:53:03 2007: ssphmPublicKeyEncrypt: called to encrypt 16 bytes 
Thu Oct 25 13:53:03 2007: ssphmPublicKeyEncrypt: successfully encrypted, out is 192 bytes 
Thu Oct 25 13:53:03 2007: sshpmPrivateKeyEncrypt: called to encrypt 196 bytes 
Thu Oct 25 13:53:03 2007: sshpmGetOpensslPrivateKeyFromCID: called to get key for 
CID 156af135 
Thu Oct 25 13:53:03 2007: sshpmGetOpensslPrivateKeyFromCID: comparing to row 0, 
certname >bsnOldDefaultIdCert< 
Thu Oct 25 13:53:03 2007: sshpmGetOpensslPrivateKeyFromCID: match in row 0 
Thu Oct 25 13:53:03 2007: sshpmPrivateKeyEncrypt: calling RSA_private_encrypt with 
172 bytes 
Thu Oct 25 13:53:03 2007: sshpmPrivateKeyEncrypt: RSA_private_encrypt returned 192 
Thu Oct 25 13:53:03 2007: sshpmPrivateKeyEncrypt: calling RSA_private_encrypt with 
24 bytes 
Thu Oct 25 13:53:03 2007: sshpmPrivateKeyEncrypt: RSA_private_encrypt returned 192 
Thu Oct 25 13:53:03 2007: sshpmPrivateKeyEncrypt: encrypted bytes: 384 
Thu Oct 25 13:53:03 2007: sshpmFreePublicKeyHandle: called with 0xae0c358 
Thu Oct 25 13:53:03 2007: sshpmFreePublicKeyHandle: freeing public key

Для LAP с SSC отладка пополудни pki позволяет продукцию команды, будет похож на это. Заметьте, что мешанина SSC также замечена в этой продукции.

Примечание: Некоторые линии продукции были перемещены во вторую линию, должную сделать интервалы между ограничениями.

(Cisco Controller) > debug pm pki enable

Mon May 22 06:34:10 2006: sshpmGetIssuerHandles: getting (old) aes ID cert handle...
Mon May 22 06:34:10 2006: sshpmGetCID: called to evaluate <bsnOldDefaultIdCert>
Mon May 22 06:34:10 2006: sshpmGetCID: comparing to row 0, CA cert >bsnOldDefaultCaCert<
Mon May 22 06:34:10 2006: sshpmGetCID: comparing to row 1, CA cert bsnDefaultRootCaCert<
Mon May 22 06:34:10 2006: sshpmGetCID: comparing to row 2, CA cert >bsnDefaultCaCert<
Mon May 22 06:34:10 2006: sshpmGetCID: comparing to row 3, CA cert >bsnDefaultBuildCert<
Mon May 22 06:34:10 2006: sshpmGetCID: comparing to row 4, CA cert >cscoDefaultNewRootCaCert<
Mon May 22 06:34:10 2006: sshpmGetCID: comparing to row 5, CA cert cscoDefaultMfgCaCert<
Mon May 22 06:34:10 2006: sshpmGetCID: comparing to row 0, ID cert >bsnOldDefaultIdCert<
Mon May 22 06:34:10 2006: sshpmGetIssuerHandles: Calculate SHA1 hash on Public Key Data
Mon May 22 06:34:10 2006: sshpmGetIssuerHandles: 
Key Data  30820122 300d06092a864886 f70d0101 
Mon May 22 06:34:10 2006: sshpmGetIssuerHandles: 
Key Data  01050003 82010f003082010a 02820101 
Mon May 22 06:34:10 2006: sshpmGetIssuerHandles: 
Key Data  00c805cd 7d406ea0cad8df69 b366fd4c 
Mon May 22 06:34:10 2006: sshpmGetIssuerHandles: 
Key Data  82fc0df0 39f2bff7ad425fa7 face8f15 
Mon May 22 06:34:10 2006: sshpmGetIssuerHandles: 
Key Data  f356a6b3 9b87625143b95a34 49292e11 
Mon May 22 06:34:10 2006: sshpmGetIssuerHandles: 
Key Data  038181eb 058c782e56f0ad91 2d61a389 
Mon May 22 06:34:10 2006: sshpmGetIssuerHandles: 
Key Data  f81fa6ce cd1f400bb5cf7cef 06ba4375 
Mon May 22 06:34:10 2006: sshpmGetIssuerHandles: 
Key Data  dde0648e c4d63259774ce74e 9e2fde19 
Mon May 22 06:34:10 2006: sshpmGetIssuerHandles: 
Key Data  0f463f9e c77b79ea65d8639b d63aa0e3 
Mon May 22 06:34:10 2006: sshpmGetIssuerHandles: 
Key Data  7dd485db 251e2e079cd31041 b0734a55 
Mon May 22 06:34:14 2006: sshpmGetIssuerHandles: 
Key Data  463fbacc 1a61502dc54e75f2 6d28fc6b 
Mon May 22 06:34:14 2006: sshpmGetIssuerHandles: 
Key Data  82315490 881e3e3102d37140 7c9c865a 
Mon May 22 06:34:14 2006: sshpmGetIssuerHandles: 
Key Data  9ef3311b d514795f7a9bac00 d13ff85f 
Mon May 22 06:34:14 2006: sshpmGetIssuerHandles: 
Key Data  97e1a693 f9f6c5cb88053e8b 7fae6d67 
Mon May 22 06:34:14 2006: sshpmGetIssuerHandles: 
Key Data  ca364f6f 76cf78bcbc1acc13 0d334aa6 
Mon May 22 06:34:14 2006: sshpmGetIssuerHandles: 
Key Data  031fb2a3 b5e572df2c831e7e f765b7e5 
Mon May 22 06:34:14 2006: sshpmGetIssuerHandles: 
Key Data  fe64641f de2a6fe323311756 8302b8b8 
Mon May 22 06:34:14 2006: sshpmGetIssuerHandles: 
Key Data  1bfae1a8 eb076940280cbed1 49b2d50f 
Mon May 22 06:34:14 2006: sshpmGetIssuerHandles: Key Data  f7020301 0001
Mon May 22 06:34:14 2006: sshpmGetIssuerHandles: SSC Key Hash is 
9e4ddd8dfcdd8458ba7b273fc37284b31a384eb9 

!--- This is the actual SSC key-hash value.

Mon May 22 06:34:14 2006: LWAPP Join-Request MTU path from AP 00:0e:84:32:04:f0 is 1500, 
remote debug mode is 0

Отладка от LAP

Если отладки диспетчера не указывают на запрос соединения, можно отладить процесс от LAP, пока LAP имеет порт пульта. Вы видите, что LAP загружает процесс с этими командами, но необходимо сначала войти, позволяют способ (пароль по умолчанию является Cisco):

  • отладьте деталь dhcp — Показывает выбору DHCP 43 информации.

  • отладьте IP udp — Показывает пакеты соединения/открытия диспетчеру, а также DHCP, и вопросы DNS (все они являются пакетами UDP. Порт 12223 является исходным портом диспетчера).

  • отладьте lwapp событие клиента — Показывает события LWAPP для AP.

  • не отладьте все — Отключают отладки на AP.

Вот является пример продукции от 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 связанные проблемы

LAPs, который использует DHCP для нахождения IP-адреса, прежде чем они начнут процесс открытия WLC, мог бы испытать затруднения при получении адреса DHCP из-за неверной конфигурации связанных параметров DHCP. Эта секция объясняет, как работы DHCP с WLCs и обеспечивают некоторые лучшие методы, чтобы избежать, чтобы DHCP связал проблемы.

Для DHCP диспетчер ведет себя как маршрутизатор с адресом помощника IP. Таким образом, это заполняет IP-адрес ворот и вперед запрос через unicast пакет непосредственно к серверу DHCP.

Когда предложение DHCP возвращается диспетчеру, оно изменяет IP-адрес сервера DHCP на свой действительный IP-адрес. Причина это делает это, состоит в том, потому что, когда Windows бродит между APs, первая вещь, это делает попытаться связаться с сервером DHCP и возобновить адрес.

С адресом сервера DHCP, являющимся 1.1.1.1 (типичный действительный IP-адрес на диспетчере), диспетчер может перехватить тот пакет и быстро ответить на Windows.

Это также, почему действительный IP-адрес является тем же самым на всех диспетчерах. Если ноутбук Windows будет бродить к AP на другом диспетчере, то он попытается связаться с действительным интерфейсом на диспетчере. Из-за события подвижности и передачи контекста, у нового диспетчера, к которому бродил клиент Windows уже, есть вся информация для ответа на Windows снова.

Если вы хотите использовать внутренний сервер DHCP на диспетчере, все, что необходимо сделать, помещен управленческий IP-адрес как сервер DHCP в динамическом интерфейсе, который вы создаете для подсети. Тогда назначьте тот интерфейс на WLAN.

Причина диспетчер нуждается в IP-адресе на каждой подсети, так, это может заполнить адрес ворот DHCP в запросе DHCP.

Это некоторые пункты для запоминания при формировании серверов DHCP для WLAN:

  1. IP-адрес сервера DHCP не должен находиться в пределах никакой динамической подсети, которая находится на диспетчере. Это будет заблокировано, но может быть отвергнуто с этой командой:

    config network mgmt-via-dynamic-interface on version 4.0 only
    		(command not available in version 3.2)
  2. Диспетчер отправит DHCP через unicast от его динамического интерфейса (в более позднем кодексе) использование его IP-адреса в том интерфейсе. Удостоверьтесь, что любой брандмауэр позволяет этому адресу достигать сервера DHCP.

  3. Удостоверьтесь, что ответ от сервера DHCP может достигнуть динамического адреса диспетчера на этом VLAN через любые брандмауэры. Звон динамический интерфейсный адрес от сервера DHCP. Звон сервер DHCP с исходным IP-адресом адреса ворот динамического интерфейса.

  4. Удостоверьтесь, что VLAN AP позволен на выключателях и маршрутизаторах, и что их порты формируются как стволы так пакеты (включает DHCP), теговый с VLAN, позволены через зашитую сеть.

  5. Гарантируйте, что сервер DHCP формируется для назначения IP-адреса на VLAN AP. Можно также формировать WLC как сервер DHCP. Для получения дополнительной информации о том, как формировать сервер DHCP на WLC, пошлите к Использованию GUI Формировать раздел DHCP Радио Cisco диспетчер LAN КОНФИГУРЭЙШН Гид, Выпуск 5.0.

  6. Проверьте, что IP-адрес диспетчера в его динамическом интерфейсе будет находиться в пределах одного из объемов DHCP на сервере DHCP.

  7. Наконец, проверьте, что вы не используете сервер DHCP, который не отвечает на unicast DHCP запросы, такие как PIX.

Если вы не можете решить свой вопрос DHCP, существует 2 решения:

  • Попробуйте внутренний сервер DHCP. Формируйте адрес сервера DHCP в динамическом интерфейсе, чтобы быть управленческим IP-адресом и затем внутренним бассейном DHCP. Если объем DHCP позволен, он должен работать.

  • Проверьте, что нет никакого ответа на запрос DHCP путем отправки в продукции на CLI (пульт или SSH) от этих отладок:

    0. debug mac addr <mac address>
    1. debug dhcp message enable
    2. debug dhcp packet enable

    Это должно указать, что пакет DHCP был отправлен, но диспетчер не получал ответ.

Наконец, из-за безопасности на диспетчере, это не, рекомендуют поместить VLAN или подсеть на диспетчере, который также содержит LAPs, если это не находится на управленческой подсети интерфейса.

Примечание: сервер RADIUS или сервер DHCP не должны быть ни на одной из динамических интерфейсных подсетей диспетчера. Безопасность заблокирует пакеты возвращения, которые пытаются общаться с диспетчером.

Используя серверы Syslog для поиска неисправностей процесса соединения LAP

Выпуск 5.2 программного обеспечения Controller позволяет вам формировать APs для отправки всех CAPWAP-связанных ошибок в syslog сервер. Вы не должны позволять команды отладки на диспетчере, потому что все сообщения об ошибках CAPWAP могут быть рассмотрены от самого syslog сервера. Для получения дополнительной информации об этой особенности и командах, используемых для предоставления возможности его, прочитайте секцию, Расследующую Процесс Соединения Точки доступа Радио Cisco гида конфигурации диспетчер LAN КОНФИГУРЭЙШН Гид, Выпуск 5.2.

LAP не присоединяется к диспетчеру, почему?

Проверьте основы сначала

  • Может AP и WLC общаются?

  • Удостоверьтесь, что AP добирается, адрес от DHCP (проверьте арендные договоры сервера DHCP на Мак адрес AP).

  • Попытайтесь свистеть AP от диспетчера.

  • Проверьте, сделана ли конфигурация STP на выключателе правильно так, чтобы не были заблокированы пакеты к VLANs.

  • Если свистит, успешны, гарантируют, что AP имеет по крайней мере один метод который к открытию, по крайней мере, единственный Пульт WLC или telnet/ssh в диспетчера для управления отладками.

  • Каждый раз перезагрузки AP, это начинает последовательность открытия WLC и пытается определить местонахождение AP. Перезагрузите AP и проверку, если она присоединяется к WLC.

Вот некоторые обычно замечаемые проблемы, из-за которых LAPs не присоединяется к WLC.

Проблема 1: время диспетчера вне интервала законности свидетельства

Закончите эти шаги для поиска неисправностей этой проблемы:

  1. Выпустите отладку lwapp, ошибки позволяют и отлаживают пополудни pki, позволяют команды.

    Отладка lwapp событие позволяет шоу продукции команды отладку сообщений свидетельства, которые переданы между AP и WLC. Продукция ясно показывает сообщение, что отклонено свидетельство.

    Примечание: Удостоверьтесь, что объяснили Скоординированное Среднее гринвичское время (UTC) погашение.

    Это - продукция отладки lwapp, события позволяют команду на диспетчере:

    Примечание: Некоторые линии продукции были перемещены во вторую линию, должную сделать интервалы между ограничениями.

    Thu Jan  1 00:09:46 1970: 00:0b:85:5b:fb:d0 Received LWAPP DISCOVERY REQUEST 
    from AP 00:0b:85:5b:fb:d0 to ff:ff:ff:ff:ff:ff on port '2' 
    Thu Jan 1 00:09:46 1970: 00:0b:85:5b:fb:d0 Successful transmission of 
    LWAPP Discovery-Response to AP 00:0b:85:5b:fb:d0 on Port 2 
    Thu Jan  1 00:09:57 1970: 00:0b:85:5b:fb:d0 Received LWAPP JOIN REQUEST 
    from AP 00:0b:85:5b:fb:d0 to 00:0b:85:33:52:81 on port '2' 
    Thu Jan  1 00:09:57 1970: 00:0b:85:5b:fb:d0 LWAPP Join-Request does not 
    include valid certificate in CERTIFICATE_PAYLOAD from AP 00:0b:85:5b:fb:d0.
    Thu Jan  1 00:09:57 1970: 00:0b:85:5b:fb:d0 Unable to free public key 
    for AP  00:0B:85:5B:FB:D0 
    Thu Jan  1 00:09:57 1970: spamProcessJoinRequest : spamDecodeJoinReq failed

    Это - продукция от отладки пополудни pki, позволяют команду на диспетчере. Эта продукция следует за процессом для проверки свидетельства.

    Примечание: Некоторые линии продукции были перемещены во вторую линию, должную сделать интервалы между ограничениями.

    Thu May 25 07:25:00 2006: sshpmGetIssuerHandles: locking ca cert table
    Thu May 25 07:25:00 2006: sshpmGetIssuerHandles: calling x509_alloc() for user cert
    Thu May 25 07:25:00 2006: sshpmGetIssuerHandles: calling x509_decode()
    Thu May 25 07:25:00 2006: sshpmGetIssuerHandles: <subject> C=US, ST=California, 
    L=San Jose, O=Cisco Systems, CN=C1200-001563e50c7e, MAILTO=support@cisco.com
    Thu May 25 07:25:00 2006: sshpmGetIssuerHandles: <issuer>  O=Cisco Systems, 
    CN=Cisco Manufacturing CA
    Thu May 25 07:25:00 2006: sshpmGetIssuerHandles: Mac Address in subject 
    is 00:15:63:e5:0c:7e
    Thu May 25 07:25:00 2006: sshpmGetIssuerHandles: Cert is issued by Cisco Systems.
     .........................
     .........................
     .........................
     ..........................
     Fri Apr 15 07:55:03 2005: ssphmUserCertVerify: calling x509_decode() 
     Fri Apr 15 07:55:03 2005: ssphmUserCertVerify: user cert verfied using   
    >cscoDefaultMfgCaCert<
     Fri Apr 15 07:55:03 2005: sshpmGetIssuerHandles: ValidityString (current): 
    2005/04/15/07:55:03
     Fri Apr 15 07:55:03 2005: sshpmGetIssuerHandles: Current time outside 
    AP cert validity interval: make sure the controller time is set.
     Fri Apr 15 07:55:03 2005: sshpmFreePublicKeyHandle: called with (nil)

    Эта информация ясно показывает, что время диспетчера вне интервала законности свидетельства LAP. Поэтому, LAP не может зарегистрироваться в диспетчере. Свидетельства, установленные в LAP, имеют предопределенный интервал законности. Время диспетчера должно быть установлено таким способом, которым это в пределах интервала законности свидетельства свидетельства LAP’s.

  2. Выпустите выставочную команду времени от диспетчера CLI, чтобы проверить, что набор даты и времени на вашем диспетчере находится в пределах этого интервала законности. Если время диспетчера выше или ниже, чем этот интервал законности свидетельства, то измените время диспетчера для нахожений в пределах этого интервала.

    Примечание: Если время не установлено правильно на диспетчере, выберите Команды> Время Набора в диспетчере способ GUI или выпустите config команду времени в диспетчере CLI для урегулирования времени диспетчера.

  3. На LAPs с доступом CLI проверьте свидетельства с шоу crypto приблизительно команда свидетельств от AP CLI.

    Эта команда позволяет вам проверять набор интервала законности свидетельства в AP. Это - пример:

    AP0015.63e5.0c7e#show crypto ca certificates
     ............................................
     ............................................
     .............................................
     ................................................
    Certificate
    Status: Available
    Certificate Serial Number: 4BC6DAB80000000517AF
    Certificate Usage: General Purpose
     Issuer:
     cn=Cisco Manufacturing CA
     o=Cisco Systems
     Subject:
     Name: C1200-001563e50c7e
     ea=support@cisco.com
     cn=C1200-001563e50c7e
     o=Cisco Systems
     l=San Jose
     st=California
     c=US
     CRL Distribution Point:
     http://www.cisco.com/security/pki/crl/cmca.crl
     Validity Date:
     start date: 17:22:04 UTC Nov 30 2005
     end   date: 17:32:04 UTC Nov 30 2015
     renew date: 00:00:00 UTC Jan 1 1970
     Associated Trustpoints: Cisco_IOS_MIC_cert
      ..................................
      ....................................
      ......................................

    Вся продукция не перечислена, поскольку может быть много интервалов законности, связанных с продукцией этой команды. Необходимо считать только интервал законности определенным Связанным Trustpoint: Cisco_IOS_MIC_cert с соответствующим AP называют в области имени. В этом примере ouput, это - Name: C1200-001563e50c7e. Это - фактический интервал законности свидетельства, который рассмотрят.

Проблема 2: Несоответствие в Регулирующей области

Вы видите, что это сообщение в отладке lwapp события позволяет продукцию команды:

Примечание: Некоторые линии продукции были перемещены во вторую линию, должную сделать интервалы между ограничениями.

Wed Oct 24 17:13:20 2007: 00:0b:85:91:c3:c0 Received LWAPP DISCOVERY REQUEST 
from AP 00:0b:85:91:c3:c0 to 00:0b:85:33:52:80 on port '2'
Wed Oct 24 17:13:20 2007: 00:0e:83:4e:67:00 Successful transmission of 
LWAPP Discovery-Response to AP 00:0b:85:91:c3:c0 on Port 2
Wed Oct 24 17:13:46 2007: 00:0b:85:91:c3:c0 Received LWAPP JOIN REQUEST 
from AP 00:0b:85:91:c3:c0 to 00:0b:85:33:52:81 on  port '2'
Wed Oct 24 17:13:46 2007: 00:0b:85:91:c3:c0 AP ap:91:c3:c0: 
txNonce  00:0B:85:33:52:80 rxNonce  00:0B:85:91:C3:C0 
Wed Oct 24 17:13:46 2007: 00:0b:85:91:c3:c0 LWAPP Join-Request MTU path 
from AP 00:0b:85:91:c3:c0 is 1500, remote debug mode is 0
Wed Oct 24 17:13:46 2007: 00:0b:85:91:c3:c0 Successfully added NPU Entry 
for AP 00:0b:85:91:c3:c0 (index 48)
Switch IP: 10.77.244.211, Switch Port: 12223, intIfNum 2, vlanId 0
AP IP: 10.77.246.18, AP Port: 7228, next hop MAC: 00:17:94:06:62:88
Wed Oct 24 17:13:46 2007: 00:0b:85:91:c3:c0 Successfully transmission 
of LWAPP Join-Reply to AP 00:0b:85:91:c3:c0
Wed Oct 24 17:13:46 2007: 00:0b:85:91:c3:c0 Register LWAPP event 
for AP 00:0b:85:91:c3:c0 slot 0
Wed Oct 24 17:13:46 2007: 00:0b:85:91:c3:c0 Register LWAPP event 
for AP 00:0b:85:91:c3:c0 slot 1
Wed Oct 24 17:13:47 2007: 00:0b:85:91:c3:c0 Received LWAPP CONFIGURE REQUEST 
from AP 00:0b:85:91:c3:c0 to  00:0b:85:33:52:81
Wed Oct 24 17:13:47 2007: 00:0b:85:91:c3:c0 Updating IP info for AP 00:0b:85:91:c3:c0 -- 
static 0, 10.77.246.18/255.255.255.224, gtw 10.77.246.1
Wed Oct 24 17:13:47 2007: 00:0b:85:91:c3:c0 Updating IP 10.77.246.18 ===> 10.77.246.18 
for AP 00:0b:85:91:c3:c0
Wed Oct 24 17:13:47 2007: spamVerifyRegDomain RegDomain set for 
slot 0 code 21 regstring -N regDfromCb -AB
Wed Oct 24 17:13:47 2007: 00:0b:85:91:c3:c0 AP 00:0b:85:91:c3:c0: 80211a Regulatory Domain 
(-N) does not match with country (US )  reg. domain -AB for the slot 0 
Wed Oct 24 17:13:47 2007: spamVerifyRegDomain RegDomain set for 
slot 1 code 21 regstring -N regDfromCb -AB
Wed Oct 24 17:13:47 2007: 00:0b:85:91:c3:c0 AP 00:0b:85:91:c3:c0: 80211bg Regulatory 
Domain (-N) does not match with country (US )  reg. domain -AB for the slot 1 
Wed Oct 24 17:13:47 2007: spamVerifyRegDomain AP RegDomain check for the country US failed
Wed Oct 24 17:13:47 2007: 00:0b:85:91:c3:c0 AP 00:0b:85:91:c3:c0: Regulatory Domain 
check Completely FAILED The AP will not be allowed to join
Wed Oct 24 17:13:47 2007: 00:0b:85:91:c3:c0 apfSpamProcessStateChangeInSpamContext: 
Deregister LWAPP event for AP 00:0b:85:91:c3:c0 slot 0
Wed Oct 24 17:13:47 2007: 00:0b:85:91:c3:c0 apfSpamProcessStateChangeInSpamContext: 
Deregister LWAPP event for AP 00:0b:85:91:c3:c0 slot 1
Wed Oct 24 17:13:47 2007: 00:0b:85:91:c3:c0 Deregister LWAPP event 
for AP 00:0b:85:91:c3:c0 slot 0
Wed Oct 24 17:13:47 2007: 00:0b:85:91:c3:c0 Deregister LWAPP event 
for AP 00:0b:85:91:c3:c0 slot 1

Сообщение ясно указывает, что существует несоответствие в регулирующей области LAP и WLC. WLC поддерживает многократные регулирующие области, но каждая регулирующая область должна быть отобрана, прежде чем LAP может присоединиться от той области. Например, WLC, который использует регулирующую область-A, может только использоваться с APs, которые используют регулирующую область-A (и так далее). Когда вы покупаете APs и WLCs, гарантируете, чтобы они разделили ту же самую регулирующую область. Только тогда может LAPs регистрироваться в WLC.

Примечание: И 802.1b/g и 802.11a радио должен быть в той же самой регулирующей области для единственного LAP.

Проблема 3: AP сообщения об ошибке не может присоединиться, потому что достигнуто максимальное количество APs в интерфейсе 2

Когда AP пытается присоединиться к диспетчеру, вы могли бы видеть это сообщение об ошибке:

Fri May 19 16:18:06 2006  [ERROR] spam_lrad.c 1553: spamProcessJoinRequest :
spamDecodeJoinReq failed 
Fri May 19 16:18:06 2006  [ERROR] spam_lrad.c 4498: AP cannot join 
because the maximum number of APs on interface 2 is reached.

По умолчанию 4400 Серийных Диспетчеров могут поддержать до 48 APs за порт. Когда вы пытаетесь соединить больше чем 48 APs на диспетчере, вы получаете это сообщение об ошибке. Однако можно формировать 4400 Серийных Диспетчеров для поддержки большего количества APs в единственном интерфейсе (за порт) использование одного из этих методов:

  • Скопление связи (для диспетчеров в Слое 3 способа)

  • Многократный менеджер AP взаимодействует (для диспетчеров в Слое 3 способа)

  • Соединение дополнительных портов (для диспетчеров в Слое 2 способа)

Для получения дополнительной информации пошлите к Формированию 4400 Серийных Диспетчеров Поддержать больше чем 48 Точек доступа.

Примечание: Cisco ввела 5500 рядов WLCs для корпоративных пользователей с дополнительными возможностями. Это не имеет никакого ограничения на число APs за порт. Отошлите к Выбору Между Скоплением Связи и Многократной группой менеджеров AP Интерфэйсеза Радио Cisco диспетчера LAN КОНФИГУРЭЙШНА Выпуск 6.0 Гида для получения дополнительной информации.

Проблема 4: С SSC APs, отключена политика AP SSC

Если политика SSC отключена на диспетчере, вы видите это, сообщения об ошибках на диспетчере от отладки lwapp события позволяют и отлаживают пополудни pki, позволяют продукцию команды:

Wed Aug 9 17:20:21 2006 [ERROR] spam_lrad.c 1553: spamProcessJoinRequest :
spamDecodeJoinReq failed 
Wed Aug 9 17:20:21 2006 [ERROR] spam_crypto.c 1509: Unable to free public key for  
AP 00:12:44:B3:E5:60 
Wed Aug 9 17:20:21 2006 [ERROR] spam_lrad.c 4880: LWAPP Join-Request does not 
include valid certificate in CERTIFICATE_PAYLOAD from AP 00:12:44:b3:e5:60.
Wed Aug 9 17:20:21 2006 [CRITICAL] sshpmPkiApi.c 1493: Not configured to 
accept Self-signed AP cert

Закончите эти шаги для поиска неисправностей этой проблемы:

Выполните одно из этих двух действий:

  • Выпустите выставочную команду подлинного списка в диспетчере CLI, чтобы проверить, формируется ли диспетчер для принятия APs с SSCs.

    Это - типовая продукция:

    #show auth-list
    
             Authorize APs against AAA ....................... disabled
             Allow APs with Self-signed Certificate (SSC) .... enabled
    
    
              
              Mac Addr                  Cert Type    Key Hash
              -----------------------   ----------   ------------------------------------------
    
              00:09:12:2a:2b:2c         SSC          1234567890123456789012345678901234567890
  • Выберите безопасность> политика AP в GUI.

    1. Проверьте, позволен ли флажок Accept Self Signed Certificate. В противном случае позвольте его.

    2. Выберите SSC в качестве типа свидетельства.

    3. Добавьте AP к списку разрешения с Мак адресом и ключевой мешаниной.

      Эта ключевая мешанина может быть получена из продукции отладки пополудни pki, позволяют команду. Посмотрите проблему 6 для получения информации о получении стоимости ключевой мешанины.

Проблема 5: список разрешения AP позволен на WLC; LAP не в списке разрешения

В таких случаях вы будете видеть, что это сообщение на диспетчере в продукции отладки lwapp события позволяет команду:

Wed Sep 12 17:42:39 2007: 00:0b:85:51:5a:e0 Received LWAPP DISCOVERY REQUEST 
from AP 00:0b:85:51:5a:e0 to 00:0b:85:33:52:80 on port '1'
Wed Sep 12 17:42:39 2007: 00:0b:85:51:5a:e0 Successful transmission of 
LWAPP Discovery-Response to AP 00:0b:85:51:5a:e0 on Port 1
Wed Sep 12 17:42:39 2007: 00:0b:85:51:5a:e0 Received LWAPP DISCOVERY REQUEST 
from AP 00:0b:85:51:5a:e0 to ff:ff:ff:ff:ff:ff on port '1'
Wed Sep 12 17:42:39 2007: 00:0b:85:51:5a:e0 Successful transmission of 
LWAPP Discovery-Response to AP 00:0b:85:51:5a:e0 on Port 1
Wed Sep 12 17:42:50 2007: 00:0b:85:51:5a:e0 Received LWAPP JOIN REQUEST 
from AP 00:0b:85:51:5a:e0 to 00:0b:85:33:52:80 on port '1'
Wed Sep 12 17:42:50 2007: 00:0b:85:51:5a:e0 AP ap:51:5a:e0: txNonce  00:0B:85:33:52:80 
rxNonce  00:0B:85:51:5A:E0 
Wed Sep 12 17:42:50 2007: 00:0b:85:51:5a:e0 LWAPP Join-Request MTU path from 
AP 00:0b:85:51:5a:e0 is 1500, remote debug mode is 0
Wed Sep 12 17:42:50 2007: spamRadiusProcessResponse: AP Authorization failure
for 00:0b:85:51:5a:e0

Если вы будете использовать LAP, который имеет порт пульта, то вы будете видеть это сообщение при издании отладки lwapp ошибочная команда клиента:

AP001d.a245.a2fb#
*Mar  1 00:00:52.267: LWAPP_CLIENT_ERROR_DEBUG: spamHandleJoinTimer: Did not receive the
Join response
*Mar  1 00:00:52.267: LWAPP_CLIENT_ERROR_DEBUG: No more AP manager IP addresses remain.

Это снова - ясный признак, что LAP не является частью списка разрешения AP на диспетчере.

Можно рассмотреть статус списка разрешения AP с помощью этой команды:

(Cisco Controller) >show auth-list

Authorize APs against AAA ....................... enabled
Allow APs with Self-signed Certificate (SSC) .... disabled

Для добавления LAP к списку разрешения AP используйте config подлинный список, добавляет микрометр <Мак адрес AP> команда. Для получения дополнительной информации о том, как формировать разрешение LAP, отошлите к Разрешению Легкой точки доступа (LAP) в Cisco Объединенный Пример Конфигурации Беспроводной сети.

Проблема 6: мешанина открытого ключа SSC является неправильной или недостающей

Закончите эти шаги для поиска неисправностей этой проблемы:

  1. Выпустите отладку lwapp, события позволяют команду.

    Это проверяет, что AP пытается присоединиться.

  2. Выпустите выставочную команду подлинного списка.

    Эта команда показывает мешанину открытого ключа, что диспетчер имеет в хранении.

  3. Выйдите отладка пополудни pki позволяют команду.

    Эта команда показывает фактическую мешанину открытого ключа. Фактическая мешанина открытого ключа должна соответствовать мешанине открытого ключа, которую диспетчер имеет в хранении. Несоответствие вызывает проблему. Это - типовая продукция этого сообщения отладки:

    Примечание: Некоторые линии продукции были перемещены во вторую линию, должную сделать интервалы между ограничениями.

    (Cisco Controller) > debug pm pki enable
    
    Mon May 22 06:34:10 2006: sshpmGetIssuerHandles: getting (old) aes ID cert handle...
    Mon May 22 06:34:10 2006: sshpmGetCID: called to evaluate <bsnOldDefaultIdCert>
    Mon May 22 06:34:10 2006: sshpmGetCID: comparing to row 0, 
    CA cert >bsnOldDefaultCaCert<
    Mon May 22 06:34:10 2006: sshpmGetCID: comparing to row 1, 
    CA cert bsnDefaultRootCaCert<
    Mon May 22 06:34:10 2006: sshpmGetCID: comparing to row 2, 
    CA cert >bsnDefaultCaCert<
    Mon May 22 06:34:10 2006: sshpmGetCID: comparing to row 3, 
    CA cert >bsnDefaultBuildCert<
    Mon May 22 06:34:10 2006: sshpmGetCID: comparing to row 4, 
    CA cert >cscoDefaultNewRootCaCert<
    Mon May 22 06:34:10 2006: sshpmGetCID: comparing to row 5, 
    CA cert cscoDefaultMfgCaCert<
    Mon May 22 06:34:10 2006: sshpmGetCID: comparing to row 0, 
    ID cert >bsnOldDefaultIdCert<
    Mon May 22 06:34:10 2006: sshpmGetIssuerHandles: Calculate SHA1 hash on 
    Public Key Data
    Mon May 22 06:34:10 2006: sshpmGetIssuerHandles: 
    Key Data  30820122 300d06092a864886 f70d0101 
    Mon May 22 06:34:10 2006: sshpmGetIssuerHandles: 
    Key Data  01050003 82010f003082010a 02820101 
    Mon May 22 06:34:10 2006: sshpmGetIssuerHandles: 
    Key Data  00c805cd 7d406ea0cad8df69 b366fd4c 
    Mon May 22 06:34:10 2006: sshpmGetIssuerHandles: 
    Key Data  82fc0df0 39f2bff7ad425fa7 face8f15 
    Mon May 22 06:34:10 2006: sshpmGetIssuerHandles: 
    Key Data  f356a6b3 9b87625143b95a34 49292e11 
    Mon May 22 06:34:10 2006: sshpmGetIssuerHandles: 
    Key Data  038181eb 058c782e56f0ad91 2d61a389 
    Mon May 22 06:34:10 2006: sshpmGetIssuerHandles: 
    Key Data  f81fa6ce cd1f400bb5cf7cef 06ba4375 
    Mon May 22 06:34:10 2006: sshpmGetIssuerHandles: 
    Key Data  dde0648e c4d63259774ce74e 9e2fde19 
    Mon May 22 06:34:10 2006: sshpmGetIssuerHandles: 
    Key Data  0f463f9e c77b79ea65d8639b d63aa0e3 
    Mon May 22 06:34:10 2006: sshpmGetIssuerHandles: 
    Key Data  7dd485db 251e2e079cd31041 b0734a55 
    Mon May 22 06:34:14 2006: sshpmGetIssuerHandles: 
    Key Data  463fbacc 1a61502dc54e75f2 6d28fc6b 
    Mon May 22 06:34:14 2006: sshpmGetIssuerHandles: 
    Key Data  82315490 881e3e3102d37140 7c9c865a 
    Mon May 22 06:34:14 2006: sshpmGetIssuerHandles: 
    Key Data  9ef3311b d514795f7a9bac00 d13ff85f 
    Mon May 22 06:34:14 2006: sshpmGetIssuerHandles: 
    Key Data  97e1a693 f9f6c5cb88053e8b 7fae6d67 
    Mon May 22 06:34:14 2006: sshpmGetIssuerHandles: 
    Key Data  ca364f6f 76cf78bcbc1acc13 0d334aa6 
    Mon May 22 06:34:14 2006: sshpmGetIssuerHandles: 
    Key Data  031fb2a3 b5e572df2c831e7e f765b7e5 
    Mon May 22 06:34:14 2006: sshpmGetIssuerHandles: 
    Key Data  fe64641f de2a6fe323311756 8302b8b8 
    Mon May 22 06:34:14 2006: sshpmGetIssuerHandles: 
    Key Data  1bfae1a8 eb076940280cbed1 49b2d50f 
    Mon May 22 06:34:14 2006: sshpmGetIssuerHandles: Key Data  f7020301 0001
    Mon May 22 06:34:14 2006: sshpmGetIssuerHandles: 
    SSC Key Hash is 9e4ddd8dfcdd8458ba7b273fc37284b31a384eb9 
    
    !--- This is the actual SSC key-hash value.
    
    Mon May 22 06:34:14 2006: LWAPP Join-Request MTU path from 
    AP 00:0e:84:32:04:f0 is 1500, remote debug mode is 0
    Mon May 22 06:34:14 2006: spamRadiusProcessResponse: 
    AP Authorization failure for 00:0e:84:32:04:f0
    

Закончите эти шаги для решения проблемы:

  1. Скопируйте мешанину открытого ключа с отладки пополудни pki, позволяют продукцию команды и используют его для замены мешанины открытого ключа в списке идентификации.

  2. Выйдите config подлинный список добавляют ssc AP_MAC AP_key команда для добавления Мак адреса AP и ключевой мешанины к списку разрешения.

    Это - пример этой команды:

    Примечание: Эта команда была перемещена во вторую линию, должную сделать интервалы между ограничениями.

    (Cisco Controller)>config auth-list add ssc 00:0e:84:32:04:f0  
    9e4ddd8dfcdd8458ba7b273fc37284b31a384eb9
    

Проблема 7: на AP существует коррупция свидетельства или открытого ключа

LAP не присоединяется к диспетчеру из-за проблемы свидетельства.

Выпустите отладку lwapp, ошибки позволяют и отлаживают пополудни pki, позволяют команды. Вы видите сообщения, которые указывают на свидетельства или ключи, которые испорчены.

Примечание: Некоторые линии продукции были перемещены во вторые линии, должные сделать интервалы между ограничениями.

Tue Aug 12 17:36:09 2008: 00:0f:24:a9:52:e0
 LWAPP Join Request does not include valid certificate in CERTIFICATE_PAYLOAD
 from AP 00:0f:24:a9:52:e0.
Tue Aug 12 17:36:09 2008: 00:0f:24:a9:52:e0
 Deleting and removing AP 00:0f:24:a9:52:e0 from fast path
Tue Aug 12 17:36:09 2008: 00:0f:24:a9:52:e0 Unable to free public key for AP

Используйте один из этих двух вариантов для решения проблемы:

  • MIC AP — Просите разрешение материалов возвращения (RMA).

  • SSC AP — Понизьте к Cisco выпуск 12.3 (7) IOSΠSoftware JA.

    Если это - AP с SSC, преобразовывают его назад в IOS с помощью кнопки MODE. Тогда используйте инструмент модернизации lwapp снова для преобразования назад в LWAPP. Это должно создать свидетельство снова.

Закончите эти шаги для понижения:

  1. Используйте выбор кнопки сброса.

  2. Очистите параметры настройки диспетчера.

  3. Управляйте модернизацией снова.

Для получения дополнительной информации о понижении LAP обратитесь к Модернизации Автономной Cisco Aironet Точки доступа к Легкому Способу.

Если у вас есть WCS, можно выдвинуть SSCs к новому WLC. Для получения дополнительной информации о том, как формировать APs использование WCS, обратитесь к разделу Точек доступа Формирования Путеводителя Конфигурации Системы управления Радио Cisco, Выпуска 5.1.

Проблема 8: диспетчер мог бы работать в Слое 2 способа

Закончите этот шаг для поиска неисправностей этой проблемы:

Проверьте режим работы диспетчера. Преобразованные APs только поддерживают Слой 3 открытия. Преобразованные APs не поддерживают Слой 2 открытия.

Закончите эти шаги для решения проблемы:

  1. Установите WLC быть в Слое 3 способа.

  2. Перезагрузка и формирует интерфейс менеджера AP.

    Если у вас есть сервисный порт, такой как сервисный порт на 4402 или 4404, у вас должен быть он в различной суперсети, чем управленческие интерфейсы и менеджер AP.

Проблема 9: Вы получаете это сообщение об ошибке на AP после преобразования в LWAPP

Вы видите это сообщение об ошибке:

*Mar 1 00:00:23.535: %LWAPP-5-CHANGED: LWAPP changed state to DISCOVERY 
*Mar 1 00:00:23.550: LWAPP_CLIENT_ERROR_DEBUG: lwapp_crypto_init_ssc_keys_and_certs 
no certs in the  SSC Private File 
*Mar 1 00:00:23.550: LWAPP_CLIENT_ERROR_DEBUG: 
*Mar 1 00:00:23.551: lwapp_crypto_init: PKI_StartSession failed 
*Mar 1 00:00:23.720: %SYS-5-RELOAD: Reload requested by LWAPP CLIENT. 
Reload Reason: FAILED CRYPTO INIT. 
*Mar 1 00:00:23.721: %LWAPP-5-CHANGED: LWAPP changed state to DOWN

AP перезагружает после 30 секунд и начинает процесс снова.

Закончите эти шаги для решения этой проблемы:

  1. У вас есть AP SSC. Преобразуйте назад в автономное изображение IOS.

  2. Очиститесь конфигурация путем издания писания стирают команду и перезагружают. Не экономьте конфигурацию при перезагрузке.

Проблема 10: Диспетчер получает сообщение открытия AP на несправедливости VLAN (вы видите отладку сообщения открытия, но не ответ),

Вы видите, что это сообщение в отладке lwapp события позволяет продукцию команды:

Received a Discovery Request with subnet broadcast with wrong AP IP address (A.B.C.D)!

Это сообщение означает, что диспетчер получил запрос открытия через IP-адрес вещания, который имеет исходный IP-адрес, который не находится ни в каких формируемых подсетях на диспетчере. Это также означает, что диспетчер уронил пакет.

Проблема состоит в том, что AP не отправляет запрос открытия к управленческому IP-адресу. Диспетчер сообщает о запросе открытия вещания от VLAN, который не формируется на диспетчере. Это, как правило, происходит, когда потребительские стволы позволили VLANs вместо того, чтобы ограничить их беспроводным VLANs.

Закончите эти шаги для решения этой проблемы:

  1. Если диспетчер находится на другой подсети, APs должен быть запущен для IP-адреса диспетчера, или APs должен получить IP-адрес диспетчеров с помощью любого из методов открытия.

  2. Выключатель формируется для разрешения некоторых VLANs, которые не находятся на диспетчере. Ограничьте позволенный VLANs на стволах.

Проблема 11: 1250 LAP, который не в состоянии присоединиться к WLC

Установка состоит из 2106 WLC, который управляет версией 4.1.185.0. Cisco 1250 AP не в состоянии присоединиться к диспетчеру.

Вход в систему WLC показывает это:

Mon Jun 2 21:19:37 2008 AP with MAC f0:2x:cf:2x:1d:3x (APf02x.cf2x.1d3x) is unknown. 
Mon Jun 2 21:19:37 2008 AP Associated. Base Radio MAC: f0:2x:cf:2x:1d:3x  
Mon Jun 2 21:19:26 2008 AP Disassociated. Base Radio MAC:f0:2x:cf:2x:1d:3x 
Mon Jun 2 21:19:20 2008 AP with MAC f0:2x:cf:2x:1d:3x (APf02x.cf2x.1d3x) is unknown. 
Mon Jun 2 21:19:20 2008 AP Associated. Base Radio MAC: f0:2x:cf:2x:1d:3x  
Mon Jun 2 21:19:09 2008 AP Disassociated. Base Radio MAC:f0:2x:cf:2x:1d:3x 
Mon Jun 2 21:19:03 2008 AP with MAC f0:2x:cf:2x:1d:3x (APf02x.cf2x.1d3x) is unknown. 

Решение: Это вызвано тем, что ряд LAP Cisco 1250 не поддержан на версии 4.1. Cisco Aironet 1250 Ряд AP поддержана от версий диспетчера 4.2.61 и позже. Для устранения этой проблемы модернизируйте программное обеспечение диспетчера до 4.2.61.0 или позже.

Проблема 12: AP, который не в состоянии присоединиться к WLC, брандмауэр, блокирующий необходимые порты

Если брандмауэр используется в корпоративной сети, гарантируйте, что следующие порты позволены на брандмауэре для LAP быть в состоянии присоединиться и общаться с диспетчером.

Необходимо позволить эти порты:

  • Позвольте эти порты UDP для движения LWAPP:

    • Данные - 12222

    • Контроль - 12223

  • Позвольте эти порты UDP для движения подвижности:

    • 16666 - 16666

    • 16667 - 16667

  • Позвольте порты UDP 5246 и 5247 для движения CAPWAP.

  • TCP 161 и 162 для SNMP (для Беспроводной системы управления [WCS])

Эти порты являются дополнительными (в зависимости от ваших требований):

  • UDP 69 для TFTP

  • TCP 80 и/или 443 для HTTP или HTTPS для доступа GUI

  • TCP 23 и/или 22 для TELNET или SSH для доступа CLI

Проблема 13: Двойной IP-адрес в сети

Это - другой общий вопрос, который замечен, когда AP пытается присоединиться к WLC. Когда AP пытается присоединиться к диспетчеру, вы могли бы видеть это сообщение об ошибке.

No more AP manager IP addresses remain

Одна из причин этого сообщения об ошибке - когда существует двойной IP-адрес в сети, которая соответствует менеджеру по AP IP-адрес. В таком случае LAP держит езду на велосипеде власти и не может присоединиться к диспетчеру.

Отладки покажут, что WLC получает запросы открытия LWAPP от APs и передает ответ открытия LWAPP на APs. Однако WLCs не получают запросы соединения LWAPP от APs.

Для поиска неисправностей этой проблемы свистите менеджер по AP от зашитого хозяина на той же самой подсети IP как менеджер по AP. Затем проверьте тайник ARP. Если двойной IP-адрес найден, демонтируйте устройство с двойным IP-адресом или измените IP-адрес на устройстве так, чтобы это имело уникальный IP-адрес в сети.

AP может тогда присоединиться к WLC.

Проблема 14: если сеть MTU составляет меньше чем 1500 байтов, LWAPP APs не присоединяются к WLC

Это из-за ошибки ID CSCsd94967 Cisco. LWAPP APs мог бы не присоединиться к WLC. Если запрос соединения LWAPP больше, чем 1500 байтов, LWAPP должен фрагментировать запрос соединения LWAPP. Логика для всего LWAPP APs - то, что размер первого фрагмента составляет 1500 байтов (включая IP и заголовок UDP), и второй фрагмент составляет 54 байта (включая IP и заголовок UDP). Если сеть между LWAPP APs и WLC имеет размер MTU меньше, чем 1500 (как мог бы быть столкнут при использовании протокола туннелирования, такого как IPsec VPN, GRE, MPLS, и т.д.), WLC не может обработать запрос соединения LWAPP.

Вы столкнетесь с этой проблемой при этих условиях:

  • WLC, который управляет программным обеспечением вариантов 3.2 или ранее

  • Сетевой путь MTU между AP и WLC составляет меньше чем 1500 байтов

Для решения этого вопроса используйте любой из этих вариантов:

  • Модернизируйте до программного обеспечения WLC 4.0, если платформа поддерживает его. В версии 4.0 WLC эта проблема решена, позволяя тоннелю LWAPP повторно собрать до 4 фрагментов.

  • Увеличьте сетевой путь MTU до 1500 байтов.

  • Используйте 1030 REAPs для местоположений, достижимых через низкие пути MTU. REAP связи LWAPP с 1030 APs был изменен для обработки этой ситуации путем сокращения MTU, используемого для способа REAP.

Проблема 15: 1142 ряда LAP, не присоединяющийся к WLC, сообщению об ошибке на WLC: lwapp_image_proc: неспособный открыть файл смолы

Ряды 1142 года LAPs поддержаны только с выпуском 5.2 WLC и позже. При управлении версиями WLC ранее, чем 5.2 вы не можете зарегистрировать LAP Диспетчеру, и вы будете видеть сообщение об ошибке, подобное этому:

*Mar 27 15:04:38.596: %LWAPP-5-CHANGED: CAPWAP changed state to DISCOVERY
*Mar 27 15:04:38.597: %CAPWAP-5-CHANGED: CAPWAP changed state to DISCOVERY
*Mar 27 15:04:38.606: %LWAPP-3-CLIENTERRORLOG: not receive read response(3)
*Mar 27 15:04:38.609: lwapp_image_proc: unable to open tar file
Mar 12 15:47:27.237 spam_lrad.c:8317 LWAPP-3-IMAGE_DOWNLOAD_ERR3: 
Refusing image download request from AP 0X:2X:D0:FG:a7:XX - unable to open 
image file /bsn/ap//c1140

Для регистрации LAPs 1140 года к WLC модернизируйте программируемое оборудование на WLC к 5.2 или более поздние версии.

Проблема 16: 1000 рядов LAPs, который не в состоянии присоединиться к Радио диспетчер LAN, WLC управляет версией 5.0

Это вызвано тем, что выпуск 5.0.148.0 программного обеспечения WLC или позже не совместим с рядом Cisco Aironet 1000 APs. Если у вас есть ряд LAP Cisco 1000 в сети, которая управляет версиями WLC 5.0.48.0, 1000 рядов, LAP не присоединяется к диспетчеру и вы видите это сообщение ловушки на WLC.

"AP with MAC xx:xx:xx:xx:xx:xx is unkown"

Проблема 17: LAPs с изображением Петли, которое не в состоянии присоединиться к WLC

Легкая Точка доступа не регистрируется в WLC. Регистрация показывает это сообщение об ошибке

AAA Authentication Failure for UserName:5475xxx8bf9c User
	 Type: WLAN USER

Если Легкая Точка доступа была отправлена с изображением петли и находится в способе Моста, это может произойти. Если бы LAP был заказан с программным обеспечением петли на нем, то необходимо добавить LAP к списку разрешения AP. Выберите безопасность> политика AP и добавьте AP к Списку Разрешения. AP должен тогда присоединиться, загрузить изображение от диспетчера, затем зарегистрироваться в WLC в способе моста. Тогда необходимо изменить AP на местный способ. LAP загружает изображение, перезагрузки и регистрируется назад диспетчеру в местном способе.

Проблема 18: сообщение об ошибке - Понижение основного запроса открытия от AP XX:AA:BB:XX:DD:DD - максимальный APs присоединилось к 6/6

Существует предел числу LAPs, который может быть поддержан WLC. Каждый WLC поддерживает определенное число LAPs, который зависит от модели и платформы. Это сообщение об ошибке замечено на WLC, когда это получает запрос открытия после того, как это достигло своей максимальной способности AP.

Вот число LAPs, поддержанного на различной платформе WLC и моделях:

  • Серийный диспетчер 2100 года поддерживает до 6, 12, или 25 LAPs. Это зависит от модели WLC.

  • 4402 поддержки до 50 LAPs, в то время как 4404 поддержки до 100. Это делает его идеальным для предприятий крупных размеров и приложений большой плотности.

  • Катализатор 6500 Модулями Series Wireless Services (WiSM) является интегрированный Катализатор 6500 выключателей и две Cisco 4404 диспетчера, который поддерживает до 300 LAPs.

  • Серийный WiSM Cisco 7600 Маршрутизатора является интегрированным маршрутизатором Cisco 7600 и двумя Cisco 4404 диспетчера, который поддерживает до 300 LAPs.

  • Cisco 28/37/38xx Маршрутизатор Series Integrated Services является интегрированным 28/37/38xx маршрутизатором и контроллером Cisco модуль сети, который поддерживает до 6, 8, 12, или 25 LAPs, в зависимости от версии сетевого модуля. Версии, которые поддерживают 8, 12, или 25 APs и NME-AIR-WLC6-K9 версия с 6 точками доступа, показывают высокоскоростной процессор и больше встроенной памяти, чем NM-AIR-WLC6-K9 версия с 6 точками доступа.

  • Катализатор 3750G Интегрированным Выключателем WLC является интегрированный Катализатор 3750 выключателей и серийный контроллер Cisco 4400, который поддерживает до 25 или 50 LAPs.

Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.


Соответствующая информация


Document ID: 99948