Networking

Nexus Dashboard 4.2: DNS, NTP, and Time Sync Requirements That Will Break Your Cluster

By Travis · May 5, 2025 · 5 min read

#nexus-dashboard #dns #ntp #data-center #cisco

Why DNS and NTP Are Deployment-Critical

Nexus Dashboard is unforgiving about DNS and NTP. Unlike many platforms where these are optional or can be added later, ND requires valid, reachable DNS and NTP servers at deployment time. The guide is direct about this:

Lack of valid DNS connectivity can prevent the system from deploying or upgrading successfully, as well as impact regular services functionality.

If you point ND at an unreachable DNS server — even a placeholder IP — your deployment will fail. This isn’t always obvious because the error may not surface immediately, but it will surface.

DNS Requirements

ND Acts as Both Client and Resolver

Nexus Dashboard runs an internal CoreDNS server that handles DNS resolution for internal services. It also functions as a DNS client reaching out to your external DNS servers for external hostname resolution. Both directions must work.

Hard Requirements

DNS servers must be reachable from the management network
Both TCP and UDP must be allowed to DNS servers on port 53
DNS servers with wildcard records are not supported — ND will not function correctly with wildcard DNS

What Breaks Without DNS

A non-functional DNS configuration causes:

Cluster deployment failures (bootstrap wizard will not complete)
Upgrade failures — upgrades validate DNS before proceeding
Service disruptions after deployment if DNS becomes unreachable
Inability to reach external integrations (Intersight, Smart Licensing)

Recommendation

Use at least two DNS servers for redundancy. If your primary DNS is internal and your secondary is external (e.g., 8.8.8.8), ensure the external DNS is reachable through your firewall. Enter both servers during the Configuration page of the Cluster Bringup wizard.

NTP Requirements

Timing Matters — Literally

NTP is not optional for Nexus Dashboard. The cluster nodes use NTP for synchronization, and there is a hard requirement:

Nexus Dashboard nodes must be in synchronization with the NTP server; however, there can be latency of up to 1 second between the Nexus Dashboard nodes. If the latency is greater than or equal to 1 second between the Nexus Dashboard nodes, this may result in unreliable operations on the Nexus Dashboard cluster.

NTP Accuracy Requirements

Parameter	Requirement
Delay	< 100 ms
Offset	± 25 ms
Jitter	< 10 ms

These are not soft guidelines — exceeding them leads to etcd and Kubernetes instability within the cluster.

Disable VMware Tools Time Sync

This is one of the most commonly missed steps in VMware ESX deployments. If VMware Tools periodic time synchronization is left enabled, it will override ND’s NTP configuration and cause time drift between nodes.

Before powering on each ND VM:

vCenter:

Right-click VM → Edit Settings → VM Options tab
Expand VMware Tools
Uncheck “Synchronize time periodically”

Direct ESXi:

Right-click VM → Edit Settings → VM Options tab
Expand VMware Tools
Uncheck “Synchronize guest time with host”

Both options disable the same behavior — VMware Tools overriding the guest NTP configuration.

Don’t Use Windows as NTP Server

The Cisco guide specifically calls this out:

We recommend that you do not use a Windows server as the NTP server.

Windows NTP implementations often have accuracy issues that can cause offset violations. Use a dedicated NTP appliance, a network device serving NTP (router or switch), or a public stratum-2 server (pool.ntp.org) if internet access is available.

If using ntpd, use version 4.2.8p12 or later.

NTP Authentication (Optional but Recommended)

ND 4.2 supports NTP authentication using symmetrical keys. This prevents a rogue NTP server from poisoning your cluster’s time. Supported authentication types:

MD5
SHA (SHA1)
AES128CMAC — recommended for highest security

Key Format Requirements

Key Type	Maximum Length	Format Constraint
SHA1 / MD5	40 characters	Under 20 chars: any ASCII except `#` and spaces. Over 20 chars: hexadecimal only
AES128CMAC	32 characters	Same format constraints

Key ID Requirements

Key IDs must be in the range 1–65535
Each key must have a unique ID
If you configure keys for any one NTP server, you must configure keys for all NTP servers

Configuration Rules

Keys must be configured identically on both the NTP server and ND — same ID, auth type, and passphrase
Multiple NTP servers can share the same key
Keys must be marked as Trusted in ND — untrusted keys will fail authentication
You can mark specific NTP servers as Preferred — ND will prioritize them when estimating server quality

IPv6 and NTP

If you’re configuring dual-stack IPv6 and the node you’re logged into only has an IPv4 management address, entering an IPv6 NTP server address during bootstrap will trigger a validation error. This is expected — the node doesn’t have an IPv6 address yet at that point. Enter the NTP configuration and proceed to the node details step where IPv6 addresses will be assigned.

Verifying Time Sync Post-Deployment

After cluster formation, verify NTP is working on each node:

# SSH into a node as rescue-user
ssh rescue-user@<node-mgmt-ip>

# Check NTP sync status
acs health

# Check NTP specifically (may vary by ND release)
chronyc tracking
chronyc sources

Expected chronyc tracking output when healthy:

Reference ID    : <ntp-server-ip>
Stratum         : 3
Ref time (UTC)  : ...
System time     : 0.000012345 seconds fast of NTP time
Last offset     : +0.000008765 seconds
RMS offset      : 0.000010234 seconds
Frequency       : 2.543 ppm slow
Residual freq   : -0.001 ppm
Skew            : 0.012 ppm
Root delay      : 0.023456 seconds
Root dispersion : 0.001234 seconds
Update interval : 64.2 seconds
Leap status     : Normal

If offset exceeds ±25ms or jitter exceeds 10ms, investigate your NTP server connectivity and configuration before proceeding with fabric onboarding.

Pre-Deployment DNS and NTP Checklist

Before starting the Cluster Bringup wizard:

DNS server IP(s) confirmed and reachable from ND management network
DNS TCP and UDP port 53 allowed through firewall
DNS servers do not use wildcard records
NTP server IP(s) confirmed and reachable
NTP server is NOT a Windows server
NTP server delay < 100ms, offset within ±25ms
VMware Tools time synchronization disabled on all ND VMs before powering on
If using NTP auth: keys configured on NTP server with matching ID, type, and passphrase
NTP UDP port 123 allowed outbound from ND management network

Getting DNS and NTP right before deployment means you can focus on cluster configuration instead of troubleshooting time-sync failures at 2am after a three-hour deployment window.