Introdução

Este documento fornece uma visão geral do processo de junção e detecção do Wireless LAN Controller (WLC). Este documento também fornece informações sobre alguns dos problemas porque um ponto de acesso leve (LAP) falha ao se juntar ao WLC e como solucionar esses problemas.

Pré-requisitos

Requisitos

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Conhecimento básico da configuração dos LAPs e dos WLCs da Cisco

• Conhecimento básico do protocolo de pouco peso do Access point (CAPWAP)

Convenções

Consulte as Convenções de Dicas Técnicas da Cisco para obter mais informações sobre convenções de documentos.

Visão geral do processo de junção e de detecção do Wireless LAN Controller (WLC)

Em uma rede sem fio unificada da Cisco, os LAPs devem primeiro detectar e se juntarem ao WLC para poderem atender os clientes sem fio.

Contudo, isto apresenta uma pergunta: como os regaços encontraram o endereço IP de gerenciamento do controlador quando está em uma sub-rede diferente?

Se você não diz ao REGAÇO onde o controlador é através da opção de DHCP 43, resolução de DNS de “Cisco-capwap-controller.local_domain”, ou para a configurar estaticamente, o REGAÇO não sabe onde na rede encontrar a interface de gerenciamento do controlador.

Além desses métodos, o LAP procura automaticamente na sub-rede local os controladores com um broadcast local de 255.255.255.255. Também, o LAP recorda o endereço IP de gerenciamento de qualquer controlador que tenha se juntado através de reinicializações. Portanto, se você colocar o LAP primeiro na sub-rede local da interface de gerenciamento, ele encontrará a interface de gerenciamento do controlador e lembrará o endereço. Isso é chamado de fornecimento. Isso não ajudará a encontrar o controlador se você substituir um LAP posteriormente. Portanto, a Cisco recomenda usar a opção 43 do DHCP ou os métodos DNS.

Os regaços conectam sempre ao endereço da interface de gerenciamento do controlador primeiramente com um pedido da descoberta. O controlador diz então ao REGAÇO o endereço IP de Um ou Mais Servidores Cisco ICM NT da relação do gerenciador AP da camada 3 (qual pode igualmente ser o Gerenciamento à revelia) assim que o REGAÇO pode enviar um pedido da junta à relação do gerenciador AP em seguida.

O AP atravessa este processo na partida:

1. O LAP inicializa e usa DHCPs em um endereço IP se ele não tiver sido atribuído anteriormente como um endereço IP estático.

2. O LAP envia uma solicitação de detecção para os controladores através de vários algoritmos de detecção e cria uma lista de controladores. Essencialmente, o LAP informa o máximo de endereços de interface de gerenciamento que for possível para a lista de controladores através do seguinte:

   1. Opção 43 de DHCP (boa para empresas globais em que os escritórios e os controladores estão em continentes diferentes)

   2. Entrada de DNS para cisco-capwap-controller (boa para empresas locais - também pode ser usada para localizar onde os APs totalmente novos se juntam)

      Nota: Se você usa CAPWAP, verifique se há uma entrada de DNS para cisco-capwap-controller.

   3. Endereços IP de gerenciamento dos controladores que o LAP recorda previamente

   4. Um broadcast da camada 3 na sub-rede

   5. Informações configuradas estaticamente

   6. Controladores atuais no grupo da mobilidade do WLC o AP juntado por último

   Desta lista, o método o mais fácil a usar-se para o desenvolvimento é ter os regaços na mesma sub-rede como a interface de gerenciamento do controlador e permitir que a transmissão da camada 3 dos regaços encontre o controlador. Esse método deve ser usado para empresas que possuem uma rede pequena e não possuem um servidor DNS local.

   O próximo método de implantação mais fácil é usar uma entrada de DNS com DHCP. Você pode ter entradas múltiplas do mesmo nome de DNS. Isso permite que o LAP detecte vários controladores. Esse método deve ser usado pelas empresas que têm todos os seus controladores em um único local e possuem um servidor DNS local. Ou, se a empresa tiver vários sufixos DNS e os controladores estiverem segregados por sufixo.

   A opção 43 de DHCP é usada por grandes empresas para localizar as informações através do DHCP. Esse método é usado por grandes empresas que possuem um sufixo DNS único. Por exemplo, a Cisco possui edifícios na Europa, na Austrália e nos Estados Unidos. Para garantir que os LAPS se juntem apenas a controladores localmente, a Cisco não pode usar uma entrada de DNS e deve usar as informações da opção 43 de DCHP para informar os LAPs qual é o endereço IP de gerenciamento de seu controlador local.

   Finalmente, a configuração estática é usada para uma rede que não tenha um servidor DHCP. Você pode estaticamente configurar a informação necessária juntar-se a um controlador através da porta de Console e dos AP CLI. Para obter informações sobre de como configurar estaticamente a informação do controlador usando o AP CLI, use o comando seguinte:

   AP#capwap ap primary-base <WLCName> <WLCIP>

   Para obter informações sobre de configurar a opção de DHCP 43 em um servidor DHCP, refira o exemplo de configuração da opção de DHCP 43

3. Envie uma solicitação de detecção para cada controlador na lista e aguarde a resposta de detecção do controlador que contém o nome do sistema, os endereços IP do gerenciador AP, o número de APs já anexados a cada interface do gerenciador AP e a capacidade excedente total para o controlador.

4. Veja a lista de controladores e envie uma solicitação de junção a um controlador nessa ordem (apenas se o AP recebeu uma resposta de detecção dele):

   1. Nome do sistema do controlador principal (configurado previamente no LAP)

   2. Nome do sistema do controlador secundário (configurado previamente no LAP)

   3. Nome do sistema do controlador terciário (configurado previamente no LAP)

   4. Controlador mestre (se o LAP não tiver sido configurado previamente com os nomes de controlador principal, secundário ou terciário. Usado sempre para saber a qual controlador totalmente novo que os LAPs se junta)

   5. Se nenhuma opção acima for visualizada, equilibre a carga entre os controladores usando o valor de capacidade excedente na resposta da detecção.

      Se dois controladores tiverem a mesma capacidade excedente, envie a solicitação de junção para o primeiro controlador que respondeu à solicitação de detecção com uma resposta de detecção. Se um único controlador tiver vários gerenciadores AP em várias interfaces, escolha a interface do gerenciador AP com o menor número de APs.

      O controlador responderá a todas as solicitações de detecção sem verificar os certificados ou as credenciais AP. Contudo, as solicitações de junção precisam ter um certificado válido para obter uma resposta de junção do controlador. Se o LAP não receber uma resposta de junção de sua escolha, ele tentará o próximo controlador na lista, exceto se o controlador for um controlador configurado (Principal/Secundário/Terciário).

5. Quando recebe a resposta da junção, o AP verifica se possui a mesma imagem que a do controlador. Se não tiver, o AP faz o download da imagem a partir do controlador e reinicializa para carregar a nova imagem e inicia o processo novamente a partir da etapa 1.

6. Se tiver a mesma imagem do software, ele pedirá a configuração ao controlador e mudará para o estado registrado no controlador.

   Depois que você fizer o download da configuração, o AP poderá ser recarregado novamente para aplicar a nova configuração. Portanto, um recarregamento extra poderá ocorrer. Isso é um comportamento normal.

Depurar do controlador

Existem alguns comandos de depuração no controlador que você pode usar para ver o processo completo na CLI.

• debugar pacotes de descoberta mostras do enable†dos eventos do capwap das” e junte-se a pacotes.

• debugar informação do nível do pacote mostras do enable†do pacote do capwap das” da descoberta e junte-se a pacotes.

• debugar processo de validação certificada mostras do enable†do pki pm das”.

• debugar o desabilitação-all— gerencie debuga fora.

Com um aplicativo de terminal que possa capturar a saída para um arquivo de registro, acesse o console ou secure shell (SSH)/Telnet para o controlador e insira estes comandos:

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

    debug capwap events enable
    debug capwap errors enable
    debug pm pki enable

Após a captura das depurações, use o comando debug disable-all para desligar todas as depurações.

As próximas seções mostram a saída desses comandos de depuração quando o LAP se registra com o controlador.

debugar eventos do capwap permitem

Este comando fornecem a informação nos eventos CAPWAP e os erros que ocorrem durante a descoberta CAPWAP e se juntam ao processo.

Esta é a saída do comando enable dos eventos do capwap debugar para um REGAÇO que tenha a mesma imagem que aquela do WLC:

Nota: Algumas linhas da saída foram movidas para a segunda linha devido a limitações de espaço.

debug capwap events enable

*spamApTask7: Jun 16 12:37:36.038: 00:62:ec:60:ea:20 Discovery Request from 172.16.17.99:46317

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

*spamApTask7: Jun 16 12:37:36.039: 00:62:ec:60:ea:20 Discovery Response sent to 172.16.17.99 port 46317

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

*spamApTask7: Jun 16 12:38:43.469: 00:62:ec:60:ea:20 Join Request from 172.16.17.99:46317

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

*spamApTask7: Jun 16 12:38:33.039: 00:62:ec:60:ea:20 Join Priority Processing status = 0, Incoming Ap's Priority 1, MaxLrads = 75, joined Aps =0
*spamApTask7: Jun 16 12:38:43.469: 00:62:ec:60:ea:20 Join Request from 172.16.17.99:46317

*spamApTask7: Jun 16 12:38:43.472: 00:62:ec:60:ea:20 Join Version: = 134256640

*spamApTask7: Jun 16 12:38:43.473: 00:62:ec:60:ea:20 apType = 46 apModel: AIR-CAP2702I-E-K9

*spamApTask7: Jun 16 12:38:43.473: 00:62:ec:60:ea:20 Join resp: CAPWAP Maximum Msg element len = 90

*spamApTask7: Jun 16 12:38:43.473: 00:62:ec:60:ea:20 Join Response sent to 172.16.17.99:46317
*spamApTask7: Jun 16 12:38:43.473: 00:62:ec:60:ea:20 CAPWAP State: Join


!--- WLC responds with a join reply to the LAP.
*spamApTask7: Jun 16 12:38:43.964: 00:62:ec:60:ea:20 Configuration Status from 172.16.17.99:46317

*spamApTask7: Jun 16 12:38:43.964: 00:62:ec:60:ea:20 CAPWAP State: Configure

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


*spamApTask7: Jun 16 12:38:43.964: 00:62:ec:60:ea:20 Updating IP info for AP 00:62:ec:60:ea:20 -- static 0, 172.16.17.99/255.255.254.0, gtw 172.16.16.1
*spamApTask7: Jun 16 12:38:43.964: 00:62:ec:60:ea:20 Updating IP 172.16.17.99 ===> 172.16.17.99 for AP 00:62:ec:60:ea:20
*spamApTask7: Jun 16 12:38:43.964: 00:62:ec:60:ea:20 Running spamDecodeVlanProfMapPayload for00:62:ec:60:ea:20
*spamApTask7: Jun 16 12:38:43.964: 00:62:ec:60:ea:20 Setting MTU to 1485
*spamApTask7: Jun 16 12:38:44.019: 00:62:ec:60:ea:20 Configuration Status Response sent to 172:16:17:99


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

*spamApTask7: Jun 16 12:38:46.882: 00:62:ec:60:ea:20 Change State Event Request from 172.16.17.99:46317

*spamApTask7: Jun 16 12:38:46.883: 00:62:ec:60:ea:20 Radio state change for slot: 0 state: 2 cause: 0 detail cause: 69
*spamApTask7: Jun 16 12:38:46.883: 00:62:ec:60:ea:20 Change State Event Response sent to 172.16.17.99:46317
.
.
.
.

*spamApTask7: Jun 16 12:38:46.883: 00:62:ec:60:ea:20 CAPWAP State: Run

*spamApTask7: Jun 16 12:38:46.883: 00:62:ec:60:ea:20 Sending the remaining config to AP 172.16.17.99:46317! 
.
.
.
.

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

*spamReceiveTask: Jun 16 12:38:46.897: 00:62:ec:60:ea:20 Configuration update request for RrmInterferenceCtrl payload sent to 172:16:17:99

*spamReceiveTask: Jun 16 12:38:46.897: 00:62:ec:60:ea:20 Configuration update request for RrmNeighbourCtrl payload sent to 172.16.17.99

*spamReceiveTask: Jun 16 12:38:46.897: 00:62:ec:60:ea:20 Configuration update request for RrmReceiveCtrl payload sent to 172:16:17:99

*spamReceiveTask: Jun 16 12:38:46.897: 00:62:ec:60:ea:20 Configuration update request for CcxRmMeas payload sent to 172.16.17.99


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

Como mencionado na seção anterior, quando um LAP tiver se registrado com um WLC, ele verificará para saber se tem a mesma imagem que o controlador. Se as imagens no LAP e no WLC forem diferentes, os LAPs farão o download da nova imagem a partir do WLC primeiro. Se o LAP tiver a mesma imagem, ele continuará a fazer o download da configuração e de outros parâmetros a partir do WLC.

Você verá estas mensagens no comando enable dos eventos do capwap debugar output se o REGAÇO transfere uma imagem do controlador como parte do processo de registro:

*spamApTask6: Jun 17 14:23:28.677: 00:62:ec:60:ea:20 Sending image data block of length 1324 and msgLength = 1327

*spamApTask6: Jun 17 14:23:28.677: 00:62:ec:60:ea:20 Image Data Request sent to 172.16.17.201:46318

*spamApTask6: Jun 17 14:23:28.693: 00:62:ec:60:ea:20 Image data Response from 172.16.17.201:46318

Uma vez que o download de imagem estiver concluído, o LAP será reinicializado e executará a detecção e se juntará ao algoritmo novamente.

debug pm pki enable

Como parte do processo de junção, o WLC autentica cada LAP verificando se o seu certificado é válido.

Quando o AP envia os CAPWAP juntam-se ao pedido ao WLC, ele encaixam seu certificado X.509 na mensagem CAPWAP. O AP igualmente gerencie um ID de sessão aleatório que seja incluído igualmente no CAPWAP se junte ao pedido. Quando o WLC recebe os CAPWAP juntam-se ao pedido, validam a assinatura do certificado X.509 usando a chave pública do AP e certificam-se do certificado esteja emitido por um Certificate Authority confiado.

Igualmente olha a data de início e o momento para o intervalo da validez do certificado AP e compara a aquela data e o tempo a sua própria data e hora (daqui o pulso de disparo do controlador precisa de ser ajustado perto da data atual e hora). Se o certificado X.509 for validado, o WLC gerará uma chave de criptografia AES aleatória. O WLC sonda a chave AES em sua crypto-engine de modo que possa cifrar e decifrar as mensagens futuras do controle CAPWAP trocadas com o AP. Note que os pacotes de dados estão enviados na claro no túnel CAPWAP entre o REGAÇO e o controlador.

O comando debug pm pki enable mostra o processo de validação de certificado que ocorre durante a fase de junção no controlador. O comando debug pm pki enable também exibirá a chave hash do AP durante o processo de junção se o AP tiver um certificado autoassinado (SSC) criado pelo programa de conversão do LWAPP. Se o AP tiver um certificado instalado pelo fabricante (MIC), você não verá uma chave hash.

Nota: Todos os APs que foram fabricados após junho de 2006 possuem um MIC.

Aqui está a saída do comando debug pm pki enablequando o LAP com um MIC junta-se ao controlador:

Nota: Algumas linhas da saída foram movidas para a segunda linha devido a limitações de espaço.

*spamApTask4: Mar 20 11:05:15.687: [SA] OpenSSL Get Issuer Handles: locking ca cert table

*spamApTask4: Mar 20 11:05:15.688: [SA] OpenSSL Get Issuer Handles: x509 subject_name /C=US/ST=California/L=San Jose/O=Cisco Systems/
CN=AP3G2-1005cae83a42/emailAddress=support@cisco.com
*spamApTask4: Mar 20 11:05:15.688: [SA] OpenSSL Get Issuer Handles: issuer_name /O=Cisco Systems/CN=Cisco Manufacturing CA
*spamApTask4: Mar 20 11:05:15.688: [SA] OpenSSL Get Issuer Handles: CN AP3G2-1005cae83a42
*spamApTask4: Mar 20 11:05:15.688: [SA] OpenSSL Get Issuer Handles: issuerCertCN Cisco Manufacturing CA
*spamApTask4: Mar 20 11:05:15.688: [SA] GetMac: MAC: 1005.cae8.3a42
*spamApTask4: Mar 20 11:05:15.688: [SA] OpenSSL Get Issuer Handles: openssl Mac Address in subject is 10:05:ca:e8:3a:42
*spamApTask4: Mar 20 11:05:15.688: [SA] OpenSSL Get Issuer Handles: CN AP3G2-1005cae83a42
*spamApTask4: Mar 20 11:05:15.688: [SA] OpenSSL Get Issuer Handles: issuerCertCN Cisco Manufacturing CA
*spamApTask4: Mar 20 11:05:15.688: [SA] GetMac: MAC: 1005.cae8.3a42
*spamApTask4: Mar 20 11:05:15.688: [SA] OpenSSL Get Issuer Handles: openssl Mac Address in subject is 10:05:ca:e8:3a:42
*spamApTask4: Mar 20 11:05:15.688: [SA] OpenSSL Get Issuer Handles: Cert Name in subject is AP3G2-1005cae83a42

*spamApTask4: Mar 20 11:05:15.688: [SA] OpenSSL Get Issuer Handles: Extracted cert issuer from subject name.


*spamApTask4: Mar 20 11:05:15.688: [SA] OpenSSL Get Issuer Handles: Cert is issued by Cisco Systems.

*spamApTask4: Mar 20 11:05:15.688: [SA] Retrieving x509 cert for CertName cscoDefaultMfgCaCert
*spamApTask4: Mar 20 11:05:15.688: [SA] sshpmGetCID: called to evaluate <cscoDefaultMfgCaCert>
*spamApTask4: Mar 20 11:05:15.688: [SA] sshpmGetCID: Found matching CA cert cscoDefaultMfgCaCert in row 5
*spamApTask4: Mar 20 11:05:15.688: [SA] Found CID 260e5e69 for certname cscoDefaultMfgCaCert

*spamApTask4: Mar 20 11:05:15.688: [SA] CACertTable: Found matching CID cscoDefaultMfgCaCert in row 5 x509 0x2cc7c274

*spamApTask4: Mar 20 11:05:15.688: [SA] Retrieving x509 cert for CertName cscoDefaultNewRootCaCert
*spamApTask4: Mar 20 11:05:15.688: [SA] sshpmGetCID: called to evaluate <cscoDefaultNewRootCaCert>
*spamApTask4: Mar 20 11:05:15.688: [SA] sshpmGetCID: Found matching CA cert cscoDefaultNewRootCaCert in row 4

*spamApTask4: Mar 20 11:05:15.688: [SA] Found CID 28d7044e for certname cscoDefaultNewRootCaCert
*spamApTask4: Mar 20 11:05:15.688: [SA] CACertTable: Found matching CID cscoDefaultNewRootCaCert in row 4 x509 0x2cc7c490
*spamApTask4: Mar 20 11:05:15.691: [SA] Verify User Certificate: X509 Cert Verification return code: 1
*spamApTask4: Mar 20 11:05:15.691: [SA] Verify User Certificate: X509 Cert Verification result text: ok
*spamApTask4: Mar 20 11:05:15.691: [SA] sshpmGetCID: called to evaluate <cscoDefaultMfgCaCert>
*spamApTask4: Mar 20 11:05:15.691: [SA] sshpmGetCID: Found matching CA cert cscoDefaultMfgCaCert in row 5

*spamApTask4: Mar 20 11:05:15.691: [SA] Verify User Certificate: OPENSSL X509_Verify: AP Cert Verfied Using >cscoDefaultMfgCaCert<

*spamApTask4: Mar 20 11:05:15.691: [SA] OpenSSL Get Issuer Handles: Check cert validity times (allow expired NO)
*spamApTask4: Mar 20 11:05:15.691: [SA] sshpmGetCID: called to evaluate <cscoDefaultIdCert>
*spamApTask4: Mar 20 11:05:15.691: [SA] sshpmGetCID: Found matching ID cert cscoDefaultIdCert in row 2
*spamApTask4: Mar 20 11:05:15.691: [SA] sshpmFreePublicKeyHandle: called with 0x1b0b9380

*spamApTask4: Mar 20 11:05:15.691: [SA] sshpmFreePublicKeyHandle: freeing public key

Debugar do AP

Se o controlador debuga não indique um pedido da junta, você pode debugar o processo do AP enquanto o AP tem uma porta de Console.  Você pode ver o processo ascendente da bota AP com estes comandos, mas você deve primeiramente obter no modo enable (a senha padrão é Cisco):

• debugar o detalhe DHCP: Informação da opção de DHCP 43 das mostras.

• debugar o IP udp: Mostra todos os pacotes de UDP recebidos e transmitidos pelo AP

• debugar o evento de cliente do capwap: Mostra eventos do capwap para o AP.

• debugar o erro de cliente do capwap:  Mostra erros do capwap para o AP.
• debugar o evento de cliente dos dtls: Eventos das mostras DTL para o AP.
• debugar dtls que o erro permite: Erros das mostras DTL para o AP.

• undebug todo: As inutilizações debugam no AP.

Está aqui um exemplo da saída dos comandos do capwap debugar. Estas saídas parciais dão uma ideia dos pacotes que são enviados pelo AP durante o processo de boot para descobrir e se juntar a um controlador.

AP can discover the WLC via one of the following options :

!--- AP discovers the WLC via option 43

*Jun 28 08:43:05.839: %CAPWAP-5-DHCP_OPTION_43: Controller address 10.63.84.78 obtained through DHCP
*Jun 28 08:43:15.963: %CAPWAP-3-EVENTLOG: Discovery Request sent to 10.63.84.78 with discovery type set to 2

!--- capwap Discovery Request using the statically configured controller information.

*Jun 28 08:43:15.963: %CAPWAP-3-EVENTLOG: Discovery Request sent to 10.63.84.32 with discovery type set to 1

!--- Capwap Discovery Request sent using subnet broadcast.

*Jun 28 08:43:15.963: %CAPWAP-3-EVENTLOG: Discovery Request sent to 255.255.255.255 with discovery type set to 0

!--- capwap Join Request sent to AP-Manager interface on DHCP discovered controller.

*Jun 28 08:40:29.031: %CAPWAP-5-SENDJOIN: sending Join Request to 10.63.84.78

O LAP não se junta ao controlador, por quê?

Verifique os princípios básicos primeiro

• O AP e o WLC podem se comunicar?

• Certifique-se que o AP está obtendo um endereço do DHCP (verifique os alugueres do servidor DHCP para ver se há o MAC address do AP).

• Tente executar ping no AP a partir do controlador.

• Verifique se a configuração STP no switch está correta de modo que os pacotes para as VLANs não sejam bloqueados.

• Se os pings forem bem sucedidos, assegure-se de que o AP tenha pelo menos um método pelo qual detectar pelo menos um console WLC único ou use telnet/ssh no controlador para executar a depuração.

• Cada vez que as repartições AP, ele iniciam a sequência da descoberta de WLC e a tentam encontrar o AP. Recarregue o AP e verifique se se junta ao WLC.

Aqui estão alguns dos problemas mais comuns encontrados devido aos quais os LAPs não se juntarão ao WLC.

Nota de campo: FN - 63942

https://www.cisco.com/c/en/us/support/docs/field-notices/639/fn63942.html

Problema 1: A hora do controlador está fora do intervalo de validade do certificado

Conclua estas etapas para solucionar esse problema:

1.  A edição debuga o erro de cliente dos dtls + debuga comandos do evento de cliente dos dtls no AP:
   
   

   
   *Jun 28 09:21:25.011: DTLS_CLIENT_EVENT: dtls_process_Certificate: Processing...Peer certificate verification failed 001A
   *Jun 28 09:21:25.031: DTLS_CLIENT_ERROR: ../capwap/base_capwap/capwap/base_capwap_wtp_dtls.c:509 Certificate verified failed!
   *Jun 28 09:21:25.031: DTLS_CLIENT_EVENT: dtls_send_Alert: Sending FATAL : Bad certificate Alert
   *Jun 28 09:21:25.031: DTLS_CLIENT_EVENT: dtls_client_process_record: Error processing Certificate.
   *Jun 28 09:21:25.031: DTLS_CLIENT_EVENT: dtls_disconnect: Disconnecting DTLS connection 0x8AE7FD0
   *Jun 28 09:21:25.031: DTLS_CLIENT_EVENT: dtls_free_connection: Free Called... for Connection 0x8AE7FD0
   *Jun 28 09:21:25.031: DTLS_CLIENT_EVENT: dtls_send_Alert: Sending FATAL : Close notify Alert
   
   

   Esta informação mostra claramente que o tempo do controlador é fora do intervalo da validade de certificado do AP. Consequentemente, o AP não pode registrar-se com o controlador. Os Certificados instalados no AP têm um intervalo predefinido da validez. O tempo do controlador deve ser ajustado de tal maneira que está dentro do intervalo da validade de certificado do certificado do AP.

2. Emita o comando show time a partir da CLI do controlador para verificar se a data e a hora definidas no controlador estão dentro desse intervalo de validade. Se a hora do controlador for maior ou menor do que esse intervalo de validade do certificado, altere a hora do controlador para que fique dentro desse intervalo.

   Nota: Se a hora não estiver definida corretamente no controlador, escolha Commands > Set Time no modo GUI do controlador ou emita o comando config time na CLI do controlador para ajustar a hora do controlador.

3. Em AP com acesso CLI, verifique os Certificados com o comando show crypto ca certificates do AP CLI.

   Esse comando permite que você verifique o intervalo de validade do certificado definido no AP. Este é um exemplo:

   AP00c1.649a.be5c#show crypto ca cert
   ............................................
   ............................................
   .............................................
   ................................................
   Certificate
   Status: Available
   Certificate Serial Number (hex): 7D1125A900000002A61A
   Certificate Usage: General Purpose
   Issuer:
   cn=Cisco Manufacturing CA SHA2
   o=Cisco
   Subject:
   Name: AP1G2-00c1649abe5c
   e=support@cisco.com
   cn=AP1G2-00c1649abe5c
   o=Cisco Systems
   l=San Jose
   st=California
   c=US
   CRL Distribution Points:
   http://www.cisco.com/security/pki/crl/cmca2.crl
   Validity Date:
   start date: 01:05:37 UTC Mar 24 2016
   end date: 01:15:37 UTC Mar 24 2026
   Associated Trustpoints: Cisco_IOS_M2_MIC_cert
   Storage:
   ..................................
   ....................................
   ......................................

   A saída inteira não é listada já que podem existir muitos intervalos de validade associados à saída desse comando. Você precisa considerar somente o intervalo de validade especificado pelo ponto de confiança associado: Cisco_IOS_MIC_cert com o nome do AP relevante no campo de nome. Nessa saída de exemplo, é Nome: C1200-001563e50c7e. Esse é o intervalo de validade do certificado real a ser considerado.

4. refira por favor CSCuq19142 LAP/WLC MIC ou expiração da vida de SSC causa a falha DTL:

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuq19142

Problema 2: Incompatibilidade no domínio regulatório

Você vê esta mensagem no comando enable dos eventos do capwap debugar output:

*spamApTask7: Jun 28 11:56:49.177: 00:cc:fc:13:e5:e0 AP 00:cc:fc:13:e5:e0: Country code is not configured(BE ).
*spamApTask7: Jun 28 11:56:49.177: 00:cc:fc:13:e5:e0 AP 00:cc:fc:13:e5:e0: Country code is not configured(BE ).
*spamApTask7: Jun 28 11:56:49.177: 00:cc:fc:13:e5:e0 Setting MTU to1485
*spamApTask7: Jun 28 11:56:49.177: 00:cc:fc:13:e5:e0 AP 00:cc:fc:13:e5:e0: Country code is not configured(BE ).
*spamApTask7: Jun 28 11:56:49.177: 00:cc:fc:13:e5:e0 Regulatory Domain Mismatch: AP 00:cc:fc:13:e5:e0 not allowed to join. Allowed domains: 802.11bg:-A
*spamApTask7: Jun 28 11:56:49.177: 00:cc:fc:13:e5:e0 Finding DTLS connection to delete for AP (192:168:47:29/60390)
*spamApTask7: Jun 28 11:56:49.177: 00:cc:fc:13:e5:e0 Disconnecting DTLS Capwap-Ctrl session 0x1d4df620 for AP (192:168:47:29/60390). Notify(true)
*spamApTask7: Jun 28 11:56:49.177: 00:cc:fc:13:e5:e0 acDtlsPlumbControlPlaneKeys: lrad:192.168.47.29(60390) mwar:10.63.84.78(5246)


WLC msglog will show the following :

*spamApTask5: Jun 28 11:52:06.536: %CAPWAP-3-DTLS_CLOSED_ERR: capwap_ac_sm.c:7095 00:cc:fc:13:e5:e0: DTLS connection 
closed forAP 192:168:47:28 (60389), Controller: 10:63:84:78 (5246) Regulatory Domain Mismatch

A mensagem indica claramente que há uma incompatibilidade no domínio regulatório do LAP e do WLC. Os domínios regulatório múltiplos dos apoios WLC mas cada domínio regulatório devem ser selecionados antes que um AP possa se juntar desse domínio. Por exemplo, o WLC que usa o domínio regulatório -A somente pode ser usado com APs que usam o domínio regulatório -A (e assim por diante). Quando você compra AP, assegure-se de que compartilhem do mesmo domínio regulatório. Somente assim os APs podem se registrar com a WLC.

Nota: 802.1b/g e os rádios 802.11a devem estar no mesmo domínio regulatório para um único AP.

Problema 3: Lista de autorização de AP ativada no WLC; LAP não está na lista de autorização

Nesses casos, você verá esta mensagem no controlador na saída do comando enable dos eventos do capwap debugar:

Wed Sep 12 17:42:39 2007: 00:0b:85:51:5a:e0 Received CAPWAP 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 
CAPWAP 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 
CAPWAP 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 CAPWAP 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 CAPWAP 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

Se você está usando um REGAÇO que tenha uma porta de Console, você verá esta mensagem quando você emite o comando do erro de cliente do capwap debugar:

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.

Isso novamente é uma indicação clara que o LAP não faz parte da lista de autorização de AP no controlador.

Você pode ver o status da lista de autorização de AP usando este comando:

(Cisco Controller) >show auth-list

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

Para adicionar um LAP à lista de autorização de AP, use o comando config auth-list add mic <AP MAC Address> . Para obter mais informações sobre como configurar a autorização do LAP, consulte Lightweight Access Point (LAP) Authorization in a Cisco Unified Wireless Network Configuration Example.

Problema 4: Há uma corrupção do certificado ou da chave pública no AP

O LAP não se junta a um controlador por causa de um problema de certificado.

Emita os erros do capwap debugar permitem e comandos debug pm pki enable. Você vê mensagens que indicam os certificados ou as chaves que estão corrompidos.

Nota: Algumas linhas da saída foram movidas para a segunda linha devido a limitações de espaço.

Tue Aug 12 17:36:09 2008: 00:0f:24:a9:52:e0
 CAPWAP 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

Use uma destas duas opções para resolver o problema:

• MIC AP - Peça um Return Materials Authorization (RMA).

• LSC AP com referência à disposição seu certificado LSC

Problema 5: O controlador recebe uma mensagem de detecção do AP na VLAN errada (você vê a depuração da mensagem de detecção, mas não a resposta)

Você vê esta mensagem no comando enable dos eventos do capwap debugar output:

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

Essa mensagem significa que o controlador recebeu uma solicitação de detecção através de um endereço IP de broadcast que tem um endereço IP de origem que não está em nenhuma sub-rede configurada no controlador. Isso também significa que o controlador está descartando o pacote.

O problema é que o AP não está enviando a solicitação de detecção para o endereço IP de gerenciamento. O controlador está relatando uma solicitação de detecção de broadcast de uma VLAN que não está configurada no controlador. Isso geralmente ocorre quando os troncos do cliente permitiram VLANS em vez de restringi-las a VLANS sem fio.

Conclua estas etapas para resolver o problema:

1. Se o controlador estiver em outra sub-rede, os APs devem ser desobstruídos para o endereço IP do controlador ou os APs devem receber o endereço IP dos controladores usando qualquer um dos métodos de detecção.

2. O switch é configurado para permitir algumas VLANs que não estão no controlador. Restrinja as VLANs permitidas nos troncos.

Problema 6: AP não é capaz de se juntar ao WLC, o Firewall está bloqueando as portas necessárias

Se um firewall for usado na rede empresarial, verifique se as seguintes portas estão ativadas no firewall para que o LAP possa juntar-se e comunicar-se com o controlador.

Você deve ativar estas portas:

• Permita estas portas UDP para o tráfego CAPWAP:

  • Dados - 5247

  • Controle - 5246

• Ative estas portas UDP para o tráfego de mobilidade:

  • 16666 - 16666

  • 16667 - 16667

• Ative as portas UDP 5246 e 5247 para o tráfego CAPWAP.

• TCP 161 e 162 para o SNMP (para o Wireless Control System [WCS])

Estas portas são opcionais (dependendo de seus requisitos):

• UDP 69 para o TFTP

• TCP 80 e/ou 443 para o HTTP ou o HTTPS para o acesso a GUI

• TCP 23 e/ou 22 para o Telnet ou o SSH para o acesso a CLI

Problema 7: Endereço IP duplicado na rede

Esse é um outro problema comum que é visto quando o AP tenta se juntar ao WLC. Você poderá ver essa mensagem de erro quando o AP tentar juntar-se ao controlador.

No more AP manager IP addresses remain

Uma das razões para essa mensagem de erro é quando há um endereço IP duplicado na rede que corresponde ao endereço IP do gerenciador AP. Nesse caso, o LAP mantém o ciclo de energia e não pode se juntar ao controlador.

Os depuradores mostrarão que o WLC recebe as solicitações de detecção do LWAPP a partir dos APs e transmite uma resposta de detecção do LWAPP para os APs. Contudo, os WLC não recebem solicitações de junção do LWAPP a partir dos APs.

Para solucionar esse problema, execute ping no gerenciador AP de um host com fio na mesma sub-rede IP que o gerenciador AP. Depois, verifique o cachê ARP. Se um endereço IP duplicado for encontrado, remova o dispositivo com o endereço IP duplicado ou troque o endereço IP no dispositivo de modo que tenha um endereço IP exclusivo na rede.

O AP poderá então juntar-se ao WLC.

Problema 8: Regaços com a imagem da malha não capaz de juntar-se ao WLC

O Access point de pouco peso não se registra com o WLC. O log indica este o Mensagem de Erro

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

Isto pode acontecer se o Access point de pouco peso foi enviado com uma imagem da malha e reage do modo de Bridge. Se o REGAÇO foi pedido com software da malha nele, você precisa de adicionar o REGAÇO à lista da autorização AP. Escolha a Segurança > as políticas AP e adicionar o AP à lista da autorização. O AP deve então juntar-se, transferir à imagem do controlador, a seguir do registro com o WLC no modo de Bridge. Então você precisa de mudar o AP ao modo local. O REGAÇO transfere a imagem, as repartições e os registros de volta ao controlador no modo local.

Problema 9: Endereço ruim “Microsoft DHCP”.

Os Access point podem renovar seus endereços IP de Um ou Mais Servidores Cisco ICM NT consideravelmente rapidamente ao tentar para juntar-se a um WLC, que possa fazer com que os servidores DHCP de Windows marquem estes IPs como “BAD_ADDRESS” que poderia rapidamente esgotar o conjunto de DHCP.

Verifique para ver se há mais informação: https://www.cisco.com/c/en/us/td/docs/wireless/controller/8-2/config-guide/b_cg82/b_cg82_chapter_0101000.html#dhcp-release-override-on-aps