Support Support Downloads Knowledge Base Juniper Support Portal Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[Archive] SRX is unable to sync the clock with lower end ScreenOS devices via NTP



Article ID: KB21399 KB Last Updated: 06 Jul 2020Version: 7.0

This article describes the issue of SRX being unable to sync its clock with a SSG5/SSG20/SSG140/SSG300 device via NTPD.



SSG20 works as a NTP server. SRX210 is configured to use SSG20 as a NTP server.

To do this on the SRX210 device, the set date ntp <ssg20_ip> command is run to sync the clock with the SSG20. However, the SRX210 device is unable to automatically sync the clock with the SSG20 device. When a SSG5/140/300 device is used as the NTP server, the same result occurs.

root@SRX210> show ntp associations no-resolve
remote refid st t when poll reach delay offset jitter
============================================================================== .LOCL. 1 - 899 1024 377 31.785 5284.02 3.517

root@SRX210> show ntp status no-resolve
status=c011 sync_alarm, sync_unspec, 1 event, event_restart,
version="ntpd 4.2.0-a Fri Feb 12 18:09:42 UTC 2010 (1)",
processor="mips", system="JUNOS10.1R1.8", leap=11, stratum=16,
precision=-17, rootdelay=0.000, rootdispersion=1037.715, peer=0,
refid=INIT, reftime=00000000.00000000 Thu, Feb 7 2036 14:28:16.000,
poll=4, clock=d19ab9dc.f8b95362 Thu, Jun 9 2011 11:17:48.971, state=1,
offset=0.000, frequency=17.164, jitter=0.008, stability=0.000

However, when a SSG550M is used as a NTP server, the SRX210 device is able to automatically sync the clock via NTP.



The set date ntp command uses the /usr/sbin/ntpdate application. However, the set system ntp server command uses the /usr/sbin/ntpd daemon. This is why different results occur for the same NTP server (SSG5/20/140/300).

The NTPD in the client decides whether to update its local clock, according to a virtual distance between the NTP server and the local NTP client. The virtual distance can be expressed as vd = fun(precision, packet_delay,?.). Precision is obtained from the NTP server by the NTP response packet. Packet_delay is the roundtrip delay (from NTP request to NTP response).

Increasing precision can decrease vd value. Decreasing packet_delay can also decrease vd value. If the vd value is less than a constant value, NTPD assumes that the NTP server is a fit server and updates its local clock, according to the NTP response packet information.

The network-topology and the device performance can impact the packet_delay value. In the same network-topology, SSG500 has less packet_delay value than SSG20, due to its high performance.

If you are going to configure the SSG device as a NTP server for the SRX device, use a higher-precision external NTP source, such as the SSG500 device, instead of other SSG platforms.


Modification History:

2020-07-06: EOL HW involved ( SSG); article can be moved to [Archive]


Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search