How to Fix “NTP Server Dropped: Strata Too High” Error When Syncing with Stratum 16 Devices


2 views

When trying to synchronize with an internal NTP server (192.168.92.82) that's actually a firewall device, you encounter the critical error:

192.168.92.82: Server dropped: strata too high
server 192.168.92.82, port 123
stratum 16, precision -19, leap 11, trust 000

In NTP hierarchy:

  • Stratum 0: Atomic clocks/GPS time sources
  • Stratum 1: Directly connected to Stratum 0
  • Stratum 2: Syncs with Stratum 1 servers
  • ...
  • Stratum 15: Lowest valid stratum
  • Stratum 16: Indicates unsynchronized state

Technical constraints prevent NTP clients from syncing with Stratum 16 servers because:

  • They provide no reliable time reference
  • Accepting their time would propagate errors
  • RFC 5905 explicitly prohibits this behavior

When you must sync with an internal device that has no upstream NTP source:

Option 1: Configure the Firewall as NTP Server

# On Linux firewall:
sudo apt install ntp
sudo nano /etc/ntp.conf

# Add these lines:
server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org

# Restart NTP
sudo service ntp restart

Option 2: Local NTP Server Setup

# On a local server (not the firewall):
sudo apt install ntp
sudo nano /etc/ntp.conf

# Configure with public NTP servers
server 0.us.pool.ntp.org iburst
server 1.us.pool.ntp.org iburst
server 2.us.pool.ntp.org iburst

# Allow internal clients
restrict 192.168.0.0 mask 255.255.0.0 nomodify notrap

After configuration, verify with:

ntpq -pn
ntpstat
timedatectl status

Sample output should show stratum ≤15:

remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*203.0.113.1     .GPS.      1 u   12   64  377    0.923   -0.107   0.042

When you absolutely must sync time immediately without NTP:

# Set time manually (Linux):
sudo date -s "2023-06-15 14:30:00"

# Or use rdate (older systems):
sudo rdate -s time.nist.gov

The error message "Server dropped: strata too high" occurs when your NTP client (ntpdate) attempts to sync with a server that has stratum 16 - which in NTP terms means the server is completely unsynchronized and shouldn't be used as a time source.

Many network devices (like firewalls) run NTP services but don't actually sync with external sources by default. They boot with:

stratum 16
leap indicator: 11 (not synchronized)
reference ID: often shows the device's IP or manufacturer code

In your case, the firewall's NTP status shows:

stratum 16, precision -19, leap 11, trust 000
refid [73.78.73.84] (ASCII "SNIT")

While you technically could force synchronization using:

ntpdate -b 192.168.92.82  # -b allows sync with stratum 16

This is strongly discouraged because:

  • You'd be syncing to an untrusted time source
  • The firewall's clock drift could be substantial
  • This violates NTP protocol standards

Option 1: Configure the Firewall Properly

The firewall should sync with reliable external sources first:

# Example configuration for Cisco ASA
ntp server pool.ntp.org
ntp server time.google.com

Option 2: Bypass the Firewall

Configure your server to sync directly with external NTP servers:

# Example /etc/ntp.conf entries
server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org

Option 3: Use Chrony (Modern Alternative)

For systems with unreliable network conditions:

# Install chrony
sudo apt install chrony

# Sample /etc/chrony/chrony.conf
pool pool.ntp.org iburst
makestep 1.0 3

After implementing any solution, verify with:

ntpq -p
     or
chronyc sources -v

Look for stratum values between 1-15 and leap indicator 0 (normal synchronization).

If you absolutely must sync with an unsynchronized source (for testing/lab environments), consider:

# Using rdate instead of NTP
rdate -n 192.168.92.82

# Or force ntpdate with timestamp checking disabled
ntpdate -B -d 192.168.92.82

Remember these methods compromise time accuracy and should never be used in production.