Support Support Downloads Knowledge Base Case Manager My Juniper 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

[EX/ScreenOS] EX 2200 series switch is unable to automatically update it’s clock via with SSG 5 via NTP.

0

0

Article ID: KB26198 KB Last Updated: 09 Nov 2012Version: 1.0
Summary:
This article describes the issue of the EX 2200 series switch being unable to automatically update its clock with SSG5 via NTP. However, the clock can be manually updated.
Symptoms:
  • SSG5 is working as the NTP server and the EX2200 series switch is working as a NTP client.

  • When the switch tries to manually update its clock with SSG5, it works normally; but does not get automatically updated with SSG 5.

  • If SSG5 is removed, then the switch is automatically updated with another NTP server.

Output of the show ntp association and show ntp status commands on the EX2200 switch, after being automatically updated:

It gets stuck in the following state:
E047NSS-00101> show ntp associations
remote refid st t when poll reach delay offset jitter
========================================================
5.47.223.1 .LOCL. 1 - 957 1024 377 30.181 -493.45 1.331
^
syntax error, expecting <command>.
remote@E047NSS-00101> show ntp status
status=c011 sync_alarm, sync_unspec, 1 event, event_restart,
version="ntpd 4.2.0-a Sat Aug 25 04:35:48 UTC 2012 (1)",
processor="arm", system="JUNOS11.4R5.5", leap=11, stratum=16,
precision=-16, rootdelay=0.000, rootdispersion=921.540, peer=0,
refid=INIT, reftime=00000000.00000000 Thu, Feb 7 2036 6:28:16.000,
poll=4, clock=d41fa0c8.d4366082 Wed, Oct 10 2012 7:22:48.828, state=1,
offset=0.000, frequency=-22.210, jitter=0.015, stability=0.000
remote@E047NSS-00101>
A manual NTP update seems to work normally:

Output of show ntp status after manual sync:
j265790@E047NSS-00101> set date ntp 5.47.223.1
29 Oct 15:57:36 ntpdate[53843]: step time server 5.47.223.1 offset
-3.039872 sec
j265790@E047NSS-00101> show ntp status
status=c011 sync_alarm, sync_unspec, 1 event, event_restart,
version="ntpd 4.2.0-a Sat Aug 25 04:35:48 UTC 2012 (1)",
processor="arm", system="JUNOS11.4R5.5", leap=11, stratum=16,
precision=-16, rootdelay=0.000, rootdispersion=0.240, peer=0,
refid=INIT, reftime=00000000.00000000 Thu, Feb 7 2036 7:28:16.000,
poll=4, clock=d43917f0.e1e0eef1 Mon, Oct 29 2012 15:57:52.882, state=1,
offset=0.000, frequency=-22.210, jitter=0.015, stability=0.000
If a NTP server from the internal network (not SSG) is used, it work normally and the following state is generated:
E047NSS-00101# run show ntp associations
remote refid st t when poll reach delay offset jitter
============================================================
*5.252.47.133 4.247.8.14 3 - 12 64 377 15.253 -3.180 3.628

[edit]
remote@E047NSS-00101# run show ntp status
status=0664 leap_none, sync_ntp, 6 events, event_peer/strat_chg,
version="ntpd 4.2.0-a Sat Aug 25 04:35:48 UTC 2012 (1)",
processor="arm", system="JUNOS11.4R5.5", leap=00, stratum=4,
precision=-16, rootdelay=36.143, rootdispersion=48.451, peer=3724,
refid=5.252.47.133,
reftime=d41eaf78.6066a170 Tue, Oct 9 2012 14:13:12.376, poll=6,
clock=d41eaff2.5cea6e91 Tue, Oct 9 2012 14:15:14.362, state=4,
offset=-3.180, frequency=-22.294, jitter=2.621, stability=0.032
Cause:

Solution:
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/SSG20/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,?.). The 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 the precision can decrease the vd value. Decreasing packet_delay can also decrease the vd value. If the vd value is less than a constant value, NTPD assumes the NTP server as 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 SSG5/20, due to its high performance.

If you are going to configure the SSG as a NTP server for EX Series, use a higher-precision external NTP source, such as the SSG500, instead of the other SSG platforms.
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