Solucione problemas de un AP ligero que no puede unirse a un WLC

Introducción

En este documento se describe el proceso de detección y unión del controlador de LAN inalámbrica (WLC) AireOS. 

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento sobre estos temas:

• Conocimiento básico acerca de la configuración de puntos de acceso ligeros (LAP) y WLC Cisco AireOS

• Conocimiento básico del Control y aprovisionamiento de los puntos de acceso inalámbricos (CAPWAP)

Componentes Utilizados

En este documento se describen los WLC AireOS y no incluye Catalyst 9800 aunque el proceso de unión es muy similar.

La información que contiene este documento se creó a partir de los dispositivos en un ambiente de laboratorio específico. Todos los dispositivos que se utilizan en este documento se pusieron en funcionamiento con una configuración verificada (predeterminada). Si tiene una red en vivo, asegúrese de entender el posible impacto de cualquier comando.

Convenciones

Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento.

Descripción general del proceso de detección y unión de WLC

En una red inalámbrica unificada Cisco, en primer lugar los LAPs deben detectarse y unirse a un WLC para que puedan dar servicio a los clientes de red inalámbrica.

Sin embargo, esto plantea una pregunta: ¿cómo encontraron los LAP la dirección IP de administración del controlador cuando está en una subred diferente?

Si no le indica al LAP la ubicación del controlador a través de la opción 43 del protocolo de configuración dinámica de hosts (DHCP), la resolución Domain Name System (DNS) del LAP, o lo configura estáticamente, no sabrá en qué parte de la red encontrar la interfaz de administración del controlador.Cisco-capwap-controller.local_domain

Además de estos métodos, el LAP busca automáticamente en la subred local los controladores con un broadcast local 255.255.255.255. Además, el LAP recuerda la dirección IP de administración de su controlador y los controladores presentes como peers de movilidad incluso a través de reinicios. Sin embargo, tan pronto como el AP se une a otro WLC, solamente recuerda la IP de ese nuevo WLC y sus pares de la movilidad y no los anteriores. Por lo tanto, si coloca el LAP primero en la subred local de la interfaz de administración, este encuentra la interfaz de administración del controlador y recuerda la dirección. Esto se llama impresión. Esto no ayuda a encontrar el controlador si sustituye un LAP posteriormente. Por lo tanto, Cisco recomienda el uso de los métodos de la opción 43 del protocolo DHCP o DNS.

Los LAP siempre se conectan primero a la dirección de la interfaz de administración del controlador con una solicitud de detección. A continuación, el controlador le indica al LAP la dirección IP de la interfaz del administrador del AP de capa 3 (que también puede ser la de administración de forma predeterminada) para que el LAP pueda enviar una solicitud de unión a la interfaz del administrador del AP.

El AP pasa por este proceso al inicio:

1. El LAP se inicia y asigna una dirección IP mediante DHCP, si no tenía asignada previamente una dirección IP estática.
2. El LAP envía solicitudes de detección a los controladores a través de los diversos algoritmos de detección y crea una lista de controladores. Esencialmente, el LAP aprende tantas direcciones de interfaz de administración para la lista de controladores como sea posible mediante:
   1. Opción 43 del protocolo DHCP (buena para empresas globales con oficinas y controladores en diferentes continentes).
   2. Entrada DNS para  (buena para empresas locales; también se puede usar para encontrar dónde se unen los AP nuevos). Si usa CAPWAP, asegúrese de que haya una entrada DNS para .cisco-capwap-controller cisco-capwap-controller
   3. Direcciones IP de administración de controladores que el LAP recuerda previamente.
   4. Un broadcast de capa 3 en la subred.
   5. Información configurada estáticamente .
   6. Controladores presentes en el grupo de movilidad del WLC al que el AP se unió por última vez.

   De esta lista, el método más fácil de usar para la implementación es tener los LAP en la misma subred que la interfaz de administración del controlador y permitir la difusión de capa 3 de los LAP para encontrar el controlador. Este método debe usarse para empresas que tienen una red pequeña y no poseen un servidor DNS local.

   El siguiente método de implementación más fácil es utilizar una entrada DNS con DHCP. Puede tener múltiples entradas del mismo nombre DNS. Esto permite al LAP detectar varios controladores. Las empresas que tienen todos sus controladores en una única ubicación y disponen de un servidor DNS local deben usar este método. También si la compañía tiene múltiples sufijos DNS y los controladores están segregados por sufijo.

   Las grandes empresas usan la opción 43 del protocolo DHCP para localizar la información. Este método es utilizado por las empresas grandes que tienen un solo sufijo DNS. Por ejemplo, Cisco posee edificios en Europa, Australia y los Estados Unidos. Para asegurar que los LAPs se unan solamente a controladores localmente, Cisco no puede utilizar una entrada DNS y debe utilizar información de la opción DHCP 43 para decir a los LAPs cuál es la dirección IP de administración de su controlador local.

   Finalmente, la configuración estática se utiliza para una red que no tenga un servidor DHCP. Puede configurar estáticamente la información necesaria para unirse a un controlador mediante el puerto de consola y la CLI de los AP. Para obtener información sobre cómo configurar estáticamente la información del controlador mediante la CLI del AP, use este comando:

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

   Para obtener información sobre cómo configurar la opción 43 del protocolo DHCP en un servidor DHCP, consulte el ejemplo de configuración de la opción 43 del protocolo DHCP.
3. Envíe una solicitud de detección a cada controlador de la lista y espere la respuesta de detección del controlador, que contiene el nombre del sistema, las direcciones IP del administrador del AP, el número de AP ya conectados a cada interfaz administrador del AP y el exceso de capacidad global del controlador.
4. Consulte la lista de controladores y envíe una solicitud de unión a un controlador en este orden (solamente si el AP recibió una respuesta de detección de él):
   1. Nombre del sistema del controlador principal (configurado previamente en el LAP).
   2. Nombre del sistema del controlador secundario (configurado previamente en el LAP).
   3. Nombre del sistema del controlador terciario (configurado previamente en el LAP).
   4. Controlador principal (si el LAP no se configuró previamente con ningún nombre de controlador principal, secundario o terciario. Se usa para saber siempre qué controlador es una nueva unión de LAP).
   5. Si no se da ninguna de las condiciones anteriores, se equilibra la carga entre los controladores mediante el uso del valor de exceso de capacidad en la respuesta de detección.

      Si dos controladores tienen la misma capacidad excedente, envíe la solicitud de unión al primer controlador que respondió a la solicitud de detección con una respuesta de detección. Si un solo controlador tiene varios administradores de APs en varias interfaces, elija la interfaz de administrador de APs con el menor número de APs.

      El controlador responde a todas las solicitudes de detección sin una verificación de certificado o credenciales de AP. Sin embargo, las solicitudes de unión deben tener un certificado válido para obtener una respuesta de unión del controlador. Si no recibe una respuesta de unión de su elección, el LAP lo intenta con el siguiente controlador de la lista, a menos que se trate de un controlador configurado (primario/secundario/terciario).

5. Cuando recibe la respuesta de unión, el AP comprueba que tenga la misma imagen que el controlador. Si no, el AP descarga la imagen del controlador, reinicia para cargar la nueva imagen y comienza el proceso de nuevo desde el paso 1.
6. Si tiene la misma imagen de software, pide la configuración del controlador y pasa al estado registrado en el controlador.

   Después de descargar la configuración, el AP puede volver a cargarse para aplicar la nueva configuración. Por lo tanto, una recarga adicional puede ocurrir y es un comportamiento normal.

Debug desde el Controlador

Hay algunos comandos   en el controlador que puede usar para ver este proceso completo en la CLI: debug

• debug capwap events enable: muestra los paquetes de detección y de unión.

• debug capwap packet enable: muestra información del nivel de paquete de los paquetes de detección y de unión.

• debug pm pki enable: muestra el proceso de validación del certificado.

• debug disable-all: desactiva las depuraciones.

Con una aplicación de terminal que pueda capturar la salida a un archivo del registro, consola o Secure Shell (SSH)/Telnet a su controlador, ingrese estos comandos:

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

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

Después de capturar las depuraciones, use el comando   para deshabilitar todas las depuraciones.debug disable-all

Las siguientes secciones muestran el resultado de estos comandos   cuando el LAP se registra con el controlador.debug

debug capwap events enable

Este comando proporciona información sobre los eventos y errores de CAPWAP que se producen en el proceso de detección y unión de CAPWAP.

Esta es la salida del comando   para un LAP que tiene la misma imagen que el WLC:debug capwap events enable

Nota: Algunas líneas del resultado se han movido a la segunda línea debido a restricciones de espacio.

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 se ha mencionado en la sección anterior, una vez que un LAP se registra con el WLC, éste comprueba si tiene la misma imagen que el controlador. Si las imágenes del LAP y el WLC son diferentes, los LAPs descargan la nueva imagen del WLC primero. Si el LAP tiene la misma imagen, continúa descargando la configuración y otros parámetros del WLC.

Verá estos mensajes en la salida del comando   si el LAP descarga una imagen del controlador como parte del proceso de registro:debug capwap events enable

*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

Una vez que se completa la descarga de la imagen, el LAP se reinicia, ejecuta la detección y vuelve a unirse al algoritmo.

debug pm pki enable

Como parte del proceso de unión, el WLC autentica cada LAP mediante la confirmación de que su certificado es válido.

Cuando el AP envía la solicitud de unión de CAPWAP al WLC, incorpora su certificado X.509 en el mensaje de CAPWAP. El AP también genera un ID de sesión aleatorio que también se incluye en la solicitud de unión de CAPWAP. Cuando el WLC recibe la solicitud de unión de CAPWAP, valida la firma del certificado X.509 con la clave pública del AP y comprueba que una Certificate Authority confiable haya emitido el certificado.

También mira la fecha y hora de inicio del intervalo de validez del certificado de AP y compara esa fecha y hora con las propias (por lo tanto, el reloj del controlador tiene que estar configurado cerca de la fecha y hora actuales). Si se valida el certificado X.509, el WLC genera un llave de encripción AES aleatoria. El WLC introduce las claves AES en su motor criptográfico para poder cifrar y desencriptar futuros mensajes de control de CAPWAP intercambiados con el AP. Tenga en cuenta que los paquetes de datos se envían sin cifrar en el túnel de CAPWAP entre el LAP y el controlador.

El comando   muestra el proceso de validación de la certificación que se produce en la fase de unión en el controlador.debug pm pki enable El comando    también muestra la clave de hash del AP en el proceso de unión, si el AP tiene un certificado autofirmado (SSC) creado por el programa de conversión de LWAPP.debug pm pki enable Si el AP tiene un certificado instalado fabricado (MIC), no verá una clave hash.

Nota: Todos los AP fabricados después de junio de 2006 tienen un MIC.

Esta es la salida del comando   cuando el LAP con un MIC se une al controlador:debug pm pki enable

Nota: Algunas líneas del resultado se han movido a la segunda línea debido a restricciones de espacio.

*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

Depuración del punto de acceso (AP)

Si las depuraciones del controlador no indican una solicitud de unión, puede depurar el proceso desde el AP si el AP tiene un puerto de consola. Puede ver el proceso de arranque del AP con estos comandos, pero primero debe activar el modo de habilitación (la contraseña predeterminada es Cisco).

• debug dhcp detail : muestra información de la opción 43 del protocolo DHCP.

• debug ip udp: muestra todos los paquetes UDP que el AP recibe y transmite.

• debug capwap client event : muestra los eventos capwap del AP.

• debug capwap client error: muestra los errores capwap del AP.
• debug dtls client event: muestra eventos de DTLS del AP.
• debug dtls error enable: muestra los errores de DTLS del AP.

• undebug all: deshabilita las depuraciones en el AP.

Aquí hay un ejemplo de la salida de losdebug capwapcomandos. Esta salida parcial da una idea de los paquetes enviados por el AP en el proceso de arranque para detectar y unirse a un controlador.

AP can discover the WLC via one of these 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

El LAP no se Une al Controlador, ¿Por Qué?

Comprobación Previa de los Elementos Básicos

• ¿Pueden comunicarse el AP y el WLC?

• Asegúrese de que el AP obtenga una dirección del protocolo DHCP (consulte las asignaciones del servidor del protocolo DHCP para obtener la dirección MAC del AP).

• Haga ping al AP desde el controlador.

• Verifique si la configuración de STP en el switch es correcta para que los paquetes a las VLAN no se bloqueen.

• Si los pings han sido exitosos, asegúrese que el AP tenga por lo menos un método por el cual se detecte al menos una consola o telnet/ssh del WLC en el controlador para ejecutar los debugs.

• Cada vez que se reinicia el AP, este inicia la secuencia de detección del WLC e intenta ubicar el AP. Reinicie el AP y verifique si se une al WLC.

Aquí se indican algunos de los problemas más frecuentes por los cuales los LAPs no se unen al WLC.

Aviso de problemas Caducidad del certificado: FN63942

Los certificados integrados en el hardware son válidos por un periodo de 10 años después de la fabricación. Si los AP o WLC tienen más de 10 años, los certificados vencidos pueden causar problemas para unirse a los AP. Encontrará más información sobre este problema en este aviso de campo: Aviso de problemas FN63942.

Problemas potenciales que buscar: Examples

Problema 1: La hora del controlador está fuera del intervalo de validez del certificado

Complete estos pasos para resolver este problema:

1. Emita los comandos   en el AP:debug dtls client error + debug dtls client event
   
   

   
   *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 información muestra claramente que la hora del controlador está fuera del intervalo de validez del certificado del AP. Por lo tanto, el AP no puede registrarse con el controlador. Los certificados instalados en el AP tienen un intervalo de validez predefinido. La hora del controlador debe configurarse para que esté dentro del intervalo de validez del certificado de AP.

2. Emita el comando   desde la CLI del controlador para verificar que la fecha y la hora configuradas en el controlador estén dentro de este intervalo de validez.show time Si la hora del controlador es anterior o posterior al intervalo de validez de este certificado, cambie la hora del controlador para que esté dentro de este intervalo.
   
   
   

   Nota: Si la hora no está configurada correctamente en el controlador, elijaCommands > Set Timeen el modo GUI del controlador, o ejecute el comando config time en la CLI del controlador para establecer la hora del controlador.

   
   
   

3. En los AP con acceso a la CLI, verifique los certificados con el comando   de la CLI del AP.show crypto ca certificates

   Este comando permite verificar el intervalo de validez del certificado fijado en el AP. Aquí tiene un ejemplo:

   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:
   ..................................
   ....................................
   ......................................

   La salida completa no aparece porque puede haber muchos intervalos de validez asociados con la salida de este comando. Considere únicamente el intervalo de validez especificado por el punto de confianza asociado: Cisco_IOS_MIC_cert con el nombre de AP relevante en el campo de nombre. En este resultado de ejemplo, es Name: C1200-001563e50c7e. Éste es el intervalo de validez del certificado real que se considerará.

4. Consulte  ID de error de Cisco CSCuq19142. El vencimiento del ciclo de vida del MIC o SSC del LAP/WLC causa una falla de DTL: ID de error de Cisco CSCuq19142.

Problema 2: Discordancia en el dominio regulador

Verá este mensaje en la salida del comando  :debug capwap events enable

*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 show these messages :

*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

El mensaje indica claramente que hay una incompatibilidad en el dominio reglamentario del LAP y el WLC. El WLC admite varios dominios reglamentarios, pero cada dominio reglamentario debe seleccionarse antes de que un AP pueda unirse desde ese dominio. Por ejemplo, el WLC que utiliza el dominio regulador - A se puede utilizar solamente con los APs que utilizan el dominio regulador - A (y así sucesivamente). Cuando adquiera AP, asegúrese de que compartan el mismo dominio reglamentario. Solamente entonces los AP podrán registrarse con el WLC.

Nota: Las radios 802.1b/g y 802.11a deben estar en el mismo dominio de regulación para un solo AP.

Problema 3: Lista de autorización de AP habilitada en el WLC; LAP no incluido en la lista de autorización

En tales casos, verá este mensaje en el controlador en la salida del comando    :debug capwap events enable

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

Si utiliza un LAP que tiene un puerto de consola, verá este mensaje cuando emite el comando    :debug capwap client error

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.

Nuevamente, esto es una indicación clara de que el LAP no es parte de la lista de autorización del AP en el controlador.

Puede ver el estado de la lista de autorización del AP con este comando:

(Cisco Controller) >show auth-list

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

Para agregar un LAP a la lista de autorización del AP, use el comando    .config auth-list add mic Para obtener más información sobre cómo configurar la autorización de LAP, refiérase a Ejemplo de Configuración de la Autorización del Punto de Acceso Ligero (LAP) en una Red Inalámbrica Unificada de Cisco.

Problema 4: Se han producido daños en el certificado o la llave pública en el AP

El LAP no se une a un controlador debido a un problema del certificado.

Ejecute los comandos    y  :debug capwap errors enable  debug pm pki enable Ve mensajes que indican los certificados o llaves dañados.

Nota: Algunas líneas de la salida se han movido a la segunda línea debido a limitaciones de espacio.

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

Utilice una de estas dos opciones para resolver el problema:

• AP de MIC: solicita una autorización de devolución de materiales (RMA).
• AP de LSC: vuelva a aprovisionar su certificado LSC.

Problema 5: El controlador recibe el mensaje de detección de AP en la VLAN incorrecta (ve el debug del mensaje de detección, pero no la respuesta)

Verá este mensaje en la salida del comando  :debug capwap events enable

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

Este mensaje significa que el controlador recibió una solicitud de detección por parte de una dirección IP de difusión con una dirección IP de origen que no se encuentra en ninguna subred configurada en el controlador. Esto también significa que el controlador es el que descarta el paquete.

El problema es que no es el AP el que envió la solicitud de detección a la dirección IP de administración. El controlador informa una solicitud de detección de difusión de una VLAN que no está configurada en el controlador. Esto suele ocurrir cuando los enlaces troncales permiten las VLAN y no las restringen a las VLAN inalámbricas.

Complete estos pasos para resolver este problema:

1. Si el controlador está en otra subred, los AP deben estar preparados para la dirección IP del controlador o los AP deben recibir la dirección IP de los controladores con uno de los métodos de detección.
2. El switch está configurado para permitir algunas VLAN que no están en el controlador. Restrinja las VLANs permitidas en los trunks.

Problema 6: AP incapaz de unirse al WLC, firewall bloqueando los puertos necesarios

Si se utiliza un firewall en la red empresarial, asegúrese de que estos puertos estén habilitados en el firewall para que el LAP se una al controlador y se comunique con él.

Debe habilitar estos puertos:

• Habilite los siguientes puertos UDP para el tráfico CAPWAP:

  • Datos - 5247

  • Control - 5246

• Habilite estos puertos UDP para el tráfico de movilidad:

  • 16666 - 16666

  • 16667 - 16667

• Habilite los puertos UDP 5246 y 5247 para el tráfico CAPWAP.

• TCP 161 y 162 para SNMP (para el sistema de control inalámbrico [WCS])

Los siguientes puertos son opcionales (según sus requisitos):

• UDP 69 para TFTP

• TCP 80 y/o 443 para HTTP o HTTPS para acceso a GUI

• TCP 23 y/o 22 para Telnet o SSH para acceso a CLI

Problema 7: Dirección IP duplicada en la red

Este es otro problema común que se ve cuando el AP intenta unirse al WLC. Puede ver este mensaje de error cuando el AP intenta unirse al controlador.

No more AP manager IP addresses remain

Una de las razones de este mensaje de error es que hay una dirección IP duplicada en la red que coincide con la dirección IP del administrador de APs. En tal caso, el LAP mantiene las iniciaciones del ciclo de alimentación y no puede unirse al controlador.

Las depuraciones muestran que el WLC recibe las solicitudes de detección de LWAPP de los AP y transmite una respuesta de detección de LWAPP a los AP.

Sin embargo, los WLCs no reciben la solicitud de unión LWAPP de los APs.

Para resolver este problema, haga un ping del administrador de APs desde un host cableado en la misma subred IP que el administrador de APs. Después compruebe la memoria caché de ARP. Si se encuentra una dirección IP duplicada, elimine el dispositivo con la dirección IP duplicada o cambie la dirección IP en el dispositivo para que tenga una dirección IP única en la red.

El AP puede entonces unirse al WLC.

Problema 8: Los LAP con la imagen de malla no pueden unirse al WLC

El punto de acceso ligero no se registra con el WLC. El registro muestra este mensaje de error:

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

Esto puede suceder si el punto de acceso ligero se envió con una imagen de malla y está en modo puente. Si el LAP se solicitó con el software de malla, debe agregar el LAP a la lista de autorización del AP. Elija Security > AP Policies (Seguridad > Políticas del AP) y agregue AP a la lista de autorización. El AP debe unirse, descargar la imagen del controlador y registrarse con el WLC en modo puente. A continuación, debe cambiar el AP al modo local. El LAP descarga la imagen, se reinicia y se vuelve a registrar en el controlador en modo local.

Problema 9: Dirección DHCP de Microsoft incorrecta

Los puntos de acceso pueden renovar sus direcciones IP rápidamente cuando se intenta unirse a un WLC, lo que puede hacer que los servidores DHCP de Windows marquen estas IP como BAD_ADDRESS, lo que podría agotar rápidamente el conjunto DHCP. Consulte para obtener más información en el capítulo Itinerancia del cliente de la Guía de configuración del controlador inalámbrico de Cisco, versión 8.2.

Información Relacionada

• Soporte técnico y descargas de Cisco
• Proceso de unión de AP con Catalyst 9800