Este documento describe cómo verificar, resolver y resolver problemas de protocolo de tiempo de red (NTP) en un fabric de Cisco ACI. Abarca el modelo de políticas de NTP, la verificación de la configuración, los comandos de verificación operativa, un flujo de trabajo de clasificación para los síntomas comunes de NTP y los escenarios detallados de solución de problemas.
El material de este documento se extrajo de la guía Troubleshooting ACI Management and Core Services — Pod Policies, la Guía de Configuración Básica de Cisco APIC, Release 6.1(x) — Provisioning Core ACI Fabric Services y la Guía de Diseño de Cisco ACI.
La sincronización horaria es una capacidad crucial en un fabric de ACI de la que dependen las tareas de supervisión, operativas y de resolución de problemas. La sincronización del reloj garantiza un análisis adecuado de los flujos de tráfico, la correlación de las marcas de tiempo de los errores y los errores en varios nodos de fabric y el uso completo de la capacidad del contador atómico, de la que dependen las puntuaciones del estado de las aplicaciones. Una configuración de NTP inexistente o inadecuada no provoca necesariamente un fallo o una puntuación de estado baja, por lo que es importante configurar la sincronización de tiempo en una fase temprana de la implementación del fabric.
NTP en ACI se gestiona a través de una cadena de cuatro objetos de políticas:
datetimePol): define la configuración de NTP, incluidos el estado administrativo, el estado de autenticación, el estado del servidor y el modo maestro. Se encuentra en Fabric > Fabric Policies > Policies > Pod > Date and Time.datetimeNtpProv): define entradas de servidor NTP individuales (proveedores) dentro de una política de fecha y hora, incluida la IP/FQDN del servidor, selección de EPG de administración (fuera de banda o en banda), indicador preferido e intervalos de sondeo.fabricPodPGrp): hace referencia a la política de fecha y hora junto con otras políticas de nivel de POD (BGP RR, SNMP, etc.). Se encuentra en Fabric > Fabric Policies > Pods > Policy Groups.fabricPodP): asocia un grupo de políticas de grupo de dispositivos con un selector de grupo de dispositivos. Se encuentra en Fabric > Fabric Policies > Pods > Profiles.Los cuatro eslabones de esta cadena deben configurarse para que NTP se aplique a los nodos de fabric. Si se rompe cualquier link, la configuración del proveedor NTP no se enviará a los switches.
ACI admite tres esquemas de autenticación NTP: MD5, SHA-1 y AES128-CMAC. AES128-CMAC se introdujo en la versión 6.1(1) de APIC y es el esquema recomendado, ya que MD5 se considera débil e inseguro. Cuando el modo FIPS está activado, solo se admiten AES128-CMAC y SHA-1.
Los switches de hoja de ACI pueden actuar como servidores NTP para los clientes de flujo descendente (por ejemplo, servidores conectados al fabric). Esta característica está deshabilitada de forma predeterminada y debe habilitarse explícitamente mediante la opción Estado del servidor en la directiva Fecha y hora. Cuando está habilitada, los clientes pueden utilizar el switch de hoja en banda, fuera de banda, el dominio de puente SVI o la dirección IP L3Out como la dirección del servidor NTP.
Antes de solucionar problemas del estado operativo de NTP, verifique que la cadena de configuración esté completa. La configuración incorrecta es la causa principal más común de los problemas de NTP en ACI.
Navegue hasta Arrendatarios > Administración > Direcciones de administración de nodos (para asignación estática) o EPG de administración de nodos (para grupos de conectividad).
Confirme que cada APIC y nodo de switch tenga asignada una dirección IP de administración. Los nodos sin direcciones de administración no pueden comunicarse con el servidor NTP.
Como alternativa, consulte la API:
apic1# moquery -c mgmtRsOoBStNode
Vaya a Fabric > Fabric Policies > Policies > Pod > Date and Time > [Your Policy].

Confirme que al menos un proveedor NTP (servidor) esté configurado. Si existen varios proveedores, marque al menos uno como Preferido.
Verifique el proveedor NTP a través de la API:
apic1# moquery -c datetimeNtpProv # datetimeNtpProv dn : uni/fabric/time-NTP-Policy/ntpprov-10.1.1.100 name : 10.1.1.100 preferred : yes <--- at least one should be "yes" epgDn : uni/tn-mgmt/mgmtp-default/oob-default <--- management EPG minPoll : 4 maxPoll : 6 keyId : 0
Vaya a Fabric > Fabric Policies > Pods > Policy Groups > [Your Pod Policy Group].

Confirme que el campo Política de fecha y hora haga referencia a la política de fecha y hora correcta.
apic1# moquery -c fabricPodPGrp -f 'fabricPodPGrp.name=="default"'
Busque el atributo datetimePolName o la relación fabricRsTimePol asociada.
Vaya a Fabric > Fabric Policies > Pods > Profiles > [Your Pod Profile].

Confirme que el campo Fabric Policy Group haga referencia al grupo de políticas de grupo de dispositivos correcto.
Vaya a Sistema > Configuración del sistema > Fecha y hora.

Confirme que el formato de visualización (local o UTC) y la zona horaria están establecidos como se esperaba. Esta configuración es una directiva de formato de fecha y hora predeterminada independiente que no se puede eliminar ni duplicar.
Después de confirmar que la cadena de configuración es correcta, utilice los siguientes comandos para verificar que NTP funciona en tiempo de ejecución.
Este comando muestra el estado de sincronización de NTP en todos los APIC. El símbolo * indica que el servidor está seleccionado para la sincronización.
apic1# show ntpq nodeid remote refid st t when poll reach auth delay offset jitter ------ - ------------------------------ ------------------------------ -------- -- -------- -------- -------- ---- -------- -------- -------- 1 * ntp.example.com .GPS. 1 u 20 64 377 none 0.213 +0.102 0.005 2 * ntp.example.com .GPS. 1 u 6 64 377 none 0.196 +0.007 0.004 3 * ntp.example.com .GPS. 1 u 27 64 377 none 0.216 -0.008 0.006
Qué buena apariencia tiene:
* (seleccionado para la sincronización) junto al servidor remoto.alcance es 377 (octal), lo que indica que las últimas 8 encuestas se realizaron correctamente.st (estrato) está entre 1 y 15. El estrato 16 significa que el servidor no está sincronizado.el desplazamiento es bajo (normalmente menos de 100 ms para un entorno saludable).Qué mal se ve:
* junto a ningún servidor: no se ha seleccionado ningún servidor para la sincronización.reach es 0: no se han recibido respuestas de NTP.st es 16: el servidor NTP no está sincronizado con su fuente de tiempo ascendente.El desplazamiento es extremadamente grande (miles de milisegundos): el reloj está significativamente a la deriva.apic1# show clock Time : 11:24:18.391 UTC-04:00 Tue Apr 07 2026
Confirme que la hora es correcta. Compare con el tiempo esperado para detectar la desviación del reloj.
apic1# bash admin@apic1:~> date Tue Apr 7 11:24:45 EDT 2026
Verifique que el proveedor NTP se haya enviado al switch.
leaf1# show ntp peers ----------------------------------------------------------------------------- Peer IP Address Serv/Peer Prefer KeyId Vrf ----------------------------------------------------------------------------- 10.1.1.100 Server yes None management
Qué buena apariencia tiene: El IP o nombre de host del servidor NTP aparece con Serv/Peer = Server y el VRF correcto (normalmente administración para OOB).
Qué mal se ve: No se muestran pares o la IP del servidor NTP no coincide con el proveedor configurado. Esto suele indicar que la política de fecha y hora no se aplicó a través de la cadena Grupo de políticas de grupo de dispositivos/Perfil de grupo de dispositivos.
Compruebe que el servidor NTP está seleccionado para la sincronización.
leaf1# show ntp peer-status
Total peers : 1
* - selected for sync, + - peer mode(active),
- - peer mode(passive), = - polled in client mode
remote local st poll reach delay vrf
--------------------------------------------------------------------------------
*10.1.1.100 0.0.0.0 1 64 377 0.000 management
El carácter * es esencial: confirma que el servidor NTP se está utilizando para la sincronización.
Qué mal se ve:
* junto al servidor: el switch no se está sincronizando con el servidor.reach es 0: no se han recibido respuestas de NTP. Esto indica un problema de disponibilidad.st es 16: el servidor NTP no está sincronizado y no puede proporcionar una hora válida.Verifique el intercambio de paquetes NTP para confirmar la disponibilidad. Reemplace la dirección IP por la dirección del proveedor NTP para el switch afectado.
leaf1# show ntp statistics peer ipaddr 10.1.1.100 ... packets sent: 9256 packets received: 9256 ...
Qué buena apariencia tiene: los paquetes enviados y los paquetes recibidos son aproximadamente iguales e incrementales.
Qué mal se ve: los paquetes enviados aumentan, pero los paquetes recibidos son 0 o apenas aumentan: las respuestas NTP no llegan al switch.
leaf1# show clock 11:24:24.121066 EDT Tue Apr 07 2026
Vaya a Fabric > Fabric Policies > Policies > Pod > Date and Time > [Your Policy] > [NTP Provider].
La columna Estado de sincronización debe mostrar Sincronizado con servidor NTP remoto para todos los nodos. El estado de sincronización puede tardar varios minutos en converger tras la implementación inicial.
Consulte la clase datetimeNtpq para verificar la sincronización NTP en todos los APIC:
apic1# moquery -c datetimeNtpq # datetimeNtpq dn : topology/pod-1/node-1/sys/ntpq-ntp.example.com remote : ntp.example.com tally : * <--- selected for sync stratum : 1 reach : 377 <--- all recent polls successful offset : +0.102 delay : 0.213 jitter : 0.005 refid : .GPS.
Utilice este árbol de decisiones cuando se informe de un problema NTP en cualquier nodo ACI.
Inicie sesión en el switch afectado y ejecute:
leaf1# show ntp peers
leaf1# show ntp peer-status
* presente → NTP se está sincronizando. Si la hora sigue apareciendo mal, vaya a la situación 5: Desplazamiento grande / Desviación del reloj.* present → continúe con el paso 3.Verifique la columna reach en show ntp peer-status.
0 → no hay respuestas del servidor NTP. Vaya a la situación 2: Servidor NTP inalcanzable.0 pero no *→ llegan respuestas pero no se ha establecido la sincronización. Compruebe el estrato: vaya al paso 4.Síntoma: show ntp peers on the switch returns no entries.
Comprobación de configuración:
Causa raíz: Uno de los cuatro eslabones de la cadena de políticas (Política de fecha y hora → Proveedor NTP → Grupo de políticas Pod → Perfil Pod) está roto. La causa más común es que el grupo de políticas de grupo de dispositivos no está asociado con el perfil de grupo de dispositivos o que la política de fecha y hora no está seleccionada en el grupo de políticas de grupo de dispositivos.
Solución: Complete el eslabón que falta en la cadena de políticas. Asegúrese de que el perfil de grupo de dispositivos para el grupo de dispositivos afectado haga referencia a un grupo de políticas de grupo de dispositivos que contenga la política de fecha y hora correcta. Una vez aplicada, la configuración del proveedor NTP se enviará a los switches en unos minutos.
Síntoma: show ntp peer-status muestra reach = 0. show ntp statistics peer ipaddr 10.1.1.100 muestra paquetes recibidos = 0.
Comprobación de configuración: Verifique que el proveedor NTP esté asociado con el EPG de administración correcto (OOB o en banda). Si utiliza OOB, verifique que los contratos de OOB permiten el puerto UDP 123.
Comprobación operativa:
leaf1# ping 10.1.1.100 vrf management
leaf1# tcpdump -n -i eth0 dst port 123 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 16:49:01.431624 IP 10.1.20.23.123 > 10.1.1.100.123: NTPv4, Client, length 48 16:49:01.440303 IP 10.1.1.100.123 > 10.1.20.23.123: NTPv4, Server, length 48
Causa raíz: Por lo general, una de las siguientes opciones:
Solución: Resuelva el problema de disponibilidad. Asigne una dirección de administración si falta, corrija el gateway predeterminado, actualice las reglas de firewall o corrija la selección de EPG de administración en el proveedor NTP.
Síntoma: show ntp peer-status muestra stratum (st) = 16. El switch no se sincronizará con un servidor del estrato 16.
Comprobación operativa: Inicie sesión en el servidor NTP o realice una consulta desde un host externo para comprobar que está sincronizado con su propio origen de tiempo de flujo ascendente.
Causa raíz: El propio servidor NTP ha perdido la sincronización con su reloj de referencia ascendente. Un servidor con estrato 16 anuncia que no tiene una fuente de tiempo confiable.
Solución: Corrija el servidor NTP. Esto está fuera del fabric de ACI: verifique la configuración del servidor NTP y su fuente de tiempo de flujo ascendente. Si el servidor NTP no se puede corregir inmediatamente, configure un proveedor NTP alternativo en la directiva Fecha y hora.
Síntoma: show ntp peer-status muestra reach > 0 y stratum is valid, pero no * se muestra. El servidor NTP responde pero el switch no acepta la respuesta.
Comprobación de configuración:
Causa raíz: La clave de autenticación, el algoritmo o el ID de clave no coinciden entre ACI y el servidor NTP, lo que hace que el switch rechace la respuesta NTP como no autenticada.
Solución: Alinee la configuración de autenticación. Asegúrese de que se configuran el mismo ID de clave, valor de clave y algoritmo en ACI y en el servidor NTP. Se recomienda AES128-CMAC para la versión APIC 6.1(1) y posteriores.
Síntoma: El switch parece estar sincronizado (* presente, alcance = 377), pero el valor de desplazamiento en show ntp peer-status o show ntpq es muy grande (cientos o miles de milisegundos), o el reloj es visiblemente incorrecto.
Comprobación operativa:
apic1# show ntpq
Compruebe la columna de desvío. Un desplazamiento correcto suele ser inferior a 100 ms.
Causa raíz: El reloj varió significativamente antes de que se estableciera la sincronización NTP o el reloj de hardware (RTC) se restableció durante un reinicio (por ejemplo, debido a una batería CMOS inactiva). NTP corrige el reloj gradualmente a través de la rotación, que puede tomar tiempo para grandes desplazamientos.
Solución: Si el desplazamiento es muy grande y NTP se está sincronizando activamente, espere a que el reloj converja. El NTP hace girar el reloj gradualmente — los grandes desplazamientos pueden tardar horas en corregirse completamente. Si el desplazamiento no disminuye, verifique que el servidor NTP está proporcionando una hora precisa. Si el problema se repite después de cada reinicio, investigue el reloj de hardware (batería RTC/CMOS) en el nodo afectado.
Síntoma: Los fallos se generan en un APIC en espera relacionado con NTP o con la política de supervisión cuando NTP se configura para la gestión en banda.
Causa raíz: Cuando se aplica una política NTP para la administración en banda, el APIC en espera también requiere configuración en banda. Sin él, se plantean las faltas.
Solución: Configure también la administración en banda para el APIC en espera. Esto aclara los fallos.
Síntoma: Se genera un error de IP duplicado después de agregar proveedores NTP.
Causa raíz: Se agregó un FQDN como proveedor NTP y, a continuación, la dirección IP resuelta de ese FQDN se agregó como segundo proveedor NTP. ACI detecta el duplicado.
Solución: Elimine el proveedor de duplicados agregado más recientemente (la entrada de dirección IP si el FQDN se agregó primero, o viceversa). Utilice sólo una entrada por servidor NTP: FQDN o dirección IP, no ambos.
Síntoma: El proveedor NTP configurado con un nombre de host no se está resolviendo. show ntp peers no muestra la dirección IP esperada o NTP no se está sincronizando.
Comprobación de configuración:
Causa raíz: No se puede alcanzar el servidor DNS o no está configurado, lo que provoca un error en la resolución del nombre de host para el proveedor NTP.
Solución: Configure la directiva de servicio DNS, garantice la disponibilidad de DNS y aplique la etiqueta DNS correcta. También puede utilizar la dirección IP del servidor NTP en lugar del nombre de host.
A continuación se indican las condiciones relacionadas con NTP que pueden generar errores en ACI:
Considere la posibilidad de derivar al TAC de Cisco si:
show ntp peer-status muestra un comportamiento inesperado como el estrato persistente 16 en un servidor que se confirma sincronizado externamente.Al contratar al TAC, proporcione los siguientes datos:
show ntpq de todos los APIC.show ntp peers, show ntp peer-status, show ntp statistics peer ipaddr <IP> y show clock de todos los switches afectados.moquery -c datetimePol, moquery -c datetimeNtpProv y moquery -c datetimeNtpq desde el APIC.| Revisión | Fecha de publicación | Comentarios |
|---|---|---|
1.0 |
07-Apr-2026
|
Versión inicial |