Is it platform specific
generic
Importance or Severity
High
Description of the bug
When chrony is configured to start in the mgmt vrf, it needs to be ordered after interfaces-config.service, since that's the service that sets up the mgmt vrf. Since no such ordering dependency exists today, a race condition exists; if chrony starts before the mgmt vrf is set up, it fails to set up valid connections and therefore fails to ever sync. You can restart chrony to get bring it back online as a workaround.
Note that this issue assumes #25726 has been resolved (otherwise chrony will fail when configured in the mgmt VRF unconditionally).
Steps to Reproduce
Start with NTP configured for the mgmt VRF, and the mgmt VRF enabled:
$ show mgmt-vrf | head -2
ManagementVRF : Enabled
$ show ntp --verbose
Command: sudo ip vrf exec mgmt chronyc -n tracking
Reference ID : 0AFA36FE (10.250.54.254)
Stratum : 5
Ref time (UTC) : Fri Feb 27 09:33:26 2026
System time : 0.000001452 seconds slow of NTP time
Last offset : -0.000003191 seconds
RMS offset : 0.000003191 seconds
Frequency : 11.260 ppm fast
Residual freq : +0.085 ppm
Skew : 0.204 ppm
Root delay : 0.006934130 seconds
Root dispersion : 0.001427774 seconds
Update interval : 2.0 seconds
Leap status : Normal
Command: sudo ip vrf exec mgmt chronyc -n sources
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* 10.250.54.254 4 6 17 2 -1662ns[-4853ns] +/- 4887us
Reload the device:
$ sudo config reload -y
Acquired lock on /etc/sonic/reload.lock
Disabling container and routeCheck monitoring ...
Stopping SONiC target ...
Running command: /usr/local/bin/sonic-cfggen -j /etc/sonic/init_cfg.json -j /etc/sonic/config_db.json --write-to-db
Running command: /usr/local/bin/db_migrator.py -o migrate
Running command: /usr/local/bin/sonic-cfggen -d -y /etc/sonic/sonic_version.yml -t /usr/share/sonic/templates/sonic-environment.j2,/etc/sonic/sonic-environment
Restarting SONiC target ...
Wait a bit to make sure NTP is up and then check that it's syncing:
$ sleep 5
$ show ntp --verbose
Command: sudo ip vrf exec mgmt chronyc -n tracking
Reference ID : 00000000 ()
Stratum : 0
Ref time (UTC) : Thu Jan 01 00:00:00 1970
System time : 0.000000001 seconds fast of NTP time
Last offset : +0.000000000 seconds
RMS offset : 0.000000000 seconds
Frequency : 11.260 ppm fast
Residual freq : +0.000 ppm
Skew : 0.000 ppm
Root delay : 1.000000000 seconds
Root dispersion : 1.000000000 seconds
Update interval : 0.0 seconds
Leap status : Not synchronised
Command: sudo ip vrf exec mgmt chronyc -n sources
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^? 10.250.54.254 0 6 0 - +0ns[ +0ns] +/- 0ns
Restart chrony and observer that it comes up correctly:
$ sudo systemctl restart chrony
$ sleep 5
$ show ntp --verbose
Command: sudo ip vrf exec mgmt chronyc -n tracking
Reference ID : 0AFA36FE (10.250.54.254)
Stratum : 5
Ref time (UTC) : Fri Feb 27 09:35:57 2026
System time : 0.000000633 seconds fast of NTP time
Last offset : +0.000003306 seconds
RMS offset : 0.000003306 seconds
Frequency : 11.260 ppm fast
Residual freq : -0.428 ppm
Skew : 0.210 ppm
Root delay : 0.006950619 seconds
Root dispersion : 0.001525881 seconds
Update interval : 2.0 seconds
Leap status : Normal
Command: sudo ip vrf exec mgmt chronyc -n sources
MS Name/IP address Stratum Poll Reach LastRx Last sample
===============================================================================
^* 10.250.54.254 4 6 17 5 +13us[ +16us] +/- 4986us
Actual Behavior and Expected Behavior
Expected:
chrony should run smoothly after reload when configured for the mgmt VRF.
Actual:
chrony occasionally fails to come up after reload when configured for the mgmt VRF.
Relevant log output
Output of show version, show techsupport
Attach files (if any)
No response
Is it platform specific
generic
Importance or Severity
High
Description of the bug
When chrony is configured to start in the mgmt vrf, it needs to be ordered after interfaces-config.service, since that's the service that sets up the mgmt vrf. Since no such ordering dependency exists today, a race condition exists; if chrony starts before the mgmt vrf is set up, it fails to set up valid connections and therefore fails to ever sync. You can restart chrony to get bring it back online as a workaround.
Note that this issue assumes #25726 has been resolved (otherwise chrony will fail when configured in the mgmt VRF unconditionally).
Steps to Reproduce
Start with NTP configured for the mgmt VRF, and the mgmt VRF enabled:
Reload the device:
Wait a bit to make sure NTP is up and then check that it's syncing:
Restart chrony and observer that it comes up correctly:
Actual Behavior and Expected Behavior
Expected:
chrony should run smoothly after reload when configured for the mgmt VRF.
Actual:
chrony occasionally fails to come up after reload when configured for the mgmt VRF.
Relevant log output
Output of
show version,show techsupportAttach files (if any)
No response