Resending...
Juniper MX5
root@YYY.XXXXXX.net> show ntp status
status=06a4 leap_none, sync_ntp, 10 events, event_peer/strat_chg,
version="ntpd 4.2.0-a Thu Mar 13 08:29:55 UTC 2014 (1)",
processor="powerpc", system="JUNOS12.3R6.6", leap=00, stratum=3,
precision=-18, rootdelay=90.375, rootdispersion=20.620, peer=29748,
refid=208.75.88.4,
reftime=d94c5338.ac6565a8 Sat, Jul 11 2015 22:45:12.673, poll=7,
clock=d94c55ad.b634aa52 Sat, Jul 11 2015 22:55:41.711, state=4,
offset=-0.428, frequency=2.394, jitter=3.505, stability=0.004
Juniper EX4200:
root@YYYY> show ntp status
status=c011 sync_alarm, sync_unspec, 1 event, event_restart,
version="ntpd 4.2.0-a Sat Jan 5 18:41:34 UTC 2013 (1)",
processor="powerpc", system="JUNOS11.4R6.6", leap=11, stratum=16,
precision=-18, rootdelay=0.000, rootdispersion=656381.655, peer=0,
refid=INIT, reftime=00000000.00000000 Thu, Feb 7 2036 1:28:16.000,
poll=4, clock=d94c5a40.fa58e5f0 Sat, Jul 11 2015 23:15:12.977, state=0,
offset=0.000, frequency=0.000, jitter=0.004, stability=0.000
Dovid,
Thanks, and I'm kinda stunned that folks are running such ancient
versions of NTP.
https://support.ntp.org/bin/view/Dev/ReleaseTimeline
4.2.0 was EOL'd in June of 2006, and we've fixed about 3,000 issues in
the codebase since then.
H
You would need to ask Juniper that....
We will. But we're going to be asking them for support for network
time. Folks like you are probably paying them for support. They'll
listen more to people like you.
This goes to *all* vendors who embed NTP in their products, we're not
interested in in picking on anybody here.
H
Juniper have recently (15.1, still not out for all platforms) rebased JunOS on a slightly less ancient FreeBSD release, and nothing I have in my lab has it released yet, and I can't be bothered to go spelunking in the install image for what version of NTP it's running.
Harlan Stenn writes:
We will. But we're going to be asking them for support for network
time. Folks like you are probably paying them for support. They'll
listen more to people like you.This goes to *all* vendors who embed NTP in their products, we're not
interested in in picking on anybody here.
Network Time doesn't *only* need support from network equipment
providers.
If accurate time is important to you, or you and your customers, please
pitch in.
I've probably strayed offtopic here. Sorry about that. But help us anyway.
H
I used to do a lot of work with embedded software years ago in my career. What I remember is that when a piece of code was ported to the embedded product, the only time the port was repeated was when there was a revenue-impacting issue. So if there was something in those 3,000 issues that would adversely affect the containing product to the point where it would be reflected in sales, I wouldn't hold your breath.
When the porting process is trivial, then it can be a different story. But remember that there is a Q/A impact on incorporating the new code from upstream, so it's the same deal.
If you would like the vendors to update, you need to make a strong case for doing so.
ntpd - NTP daemon program - Ver. 4.2.6
Colins-iMac:~ colinj$ uname -a
Darwin Colins-iMac.home 15.0.0 Darwin Kernel Version 15.0.0: Sun Jun 28 00:25:56 PDT 2015; root:xnu-3247.1.36~7/RELEASE_X86_64 x86_64
(10.11 osx el capitan)
-bash-4.2$ uname -a
Linux oraclelinux 3.8.13-68.1.2.el7uek.x86_64 #2 SMP Mon Mar 30 11:45:57 PDT 2015 x86_64 x86_64 x86_64 GNU/Linux
ntpd - NTP daemon program - Ver. 4.2.6p5
2015:07:11-01:05:57 cloudsophosvm ntpd[17219]: ntpd 4.2.6p5@1.2349 Tue Feb 4 13:03:59 UTC 2014 (1)
Sophos UTM 9.313-3
Colin
* Julien Goodwin
Juniper have recently (15.1, still not out for all platforms) rebased
JunOS on a slightly less ancient FreeBSD release, and nothing I have in
my lab has it released yet, and I can't be bothered to go spelunking in
the install image for what version of NTP it's running.
FWIW:
root@lab-ex4200:RE:1% ntpq -c rv
status=06f4 leap_none, sync_ntp, 15 events, event_peer/strat_chg,
version="ntpd 4.2.0-a Fri May 29 07:45:35 2015 (1)",
processor="powerpc", system="JUNOS15.1R1.8", leap=00, stratum=3,
precision=-18, rootdelay=8.087, rootdispersion=52.195, peer=32436,
refid=87.238.33.2,
reftime=d94c85fa.7b317b80 Sun, Jul 12 2015 8:21:46.481, poll=10,
clock=d94c8669.9b6e8a47 Sun, Jul 12 2015 8:23:37.607, state=4,
offset=-1.039, frequency=-32.350, jitter=0.445, stability=0.040
It seems they've pulled the 15.1 release though, at least I can't
download it anymore.
Tore
:Thanks, and I'm kinda stunned that folks are running such ancient
:versions of NTP.
I suggest you get accustomed to being stunned.
:https://support.ntp.org/bin/view/Dev/ReleaseTimeline
:
:4.2.0 was EOL'd in June of 2006, and we've fixed about 3,000 issues in
:the codebase since then.
4.2.0 may have been EOL'd in 2006, but it was still shipping as the
default in FreeBSD until 2009.
Out of those 3000 issues, only a tiny fraction are security-related
that would apply to JunOS. I expect that they backport security and
other fixes as necessary, until some bigger engineering effort and|or
headache calls for a forklift/mass upgrade of things.
I’m currently running a scan of the internet and querying NTP versions.
I’ll publish the results of it on Github and mail them in here 
This is not surprising at all, nor should you be surprised to find xntp3
still in use because of the even older software on decrepit but still
functional hardware. I.e., in addition to the issues Stephen Satchell
mentioned as to why vendors might not be keeping up, users may have
similar needs keeping them from using the latest releases of device
software. And then there are those that never even check for updates so
long as their device keeps them happy.
/mark
Are you using Nmap or masscan?
Also I'd be interested in what switches and settings you are using.
I’m currently running a scan of the internet and querying NTP versions.
I’ll publish the results of it on Github and mail them in here
Please don't.
Please see http://openntpproject.org/
A polite ask would get you data specifically about
ntpd versions. Note that some korean CPEs had their firmware all
built in KST:
38645 ntpd 4.1.1c-rc1@1.836 Mon Mar 30 16:45:15 KST 2015 (12)
26508 ntpd 4.1.1c-rc1@1.836 Tue Jan 6 15:54:39 KST 2015 (40)
23111 ntpd 4.1.1c-rc1@1.836 Thu Apr 16 23:42:15 KST 2015 (33)
16715 ntpd 4.1.1c-rc1@1.836 Mon Sep 3 11:11:56 KST 2012 (413)
15033 ntpd 4.2.4p6@1.1549 Tue Jan 5 17:30:09 UTC 2010 (1)
14307 ntpd 4.1.1c-rc1@1.836 Tue Dec 30 11:06:17 KST 2014 (26)
14247 ntpd 4.1.0 Thu May 22 08:58:17 KST 2003 (26)
12104 ntpd 4.2.4p5-a (1)
10802 ntpd 4.1.1c-rc1@1.836 Mon Mar 30 16:30:53 KST 2015 (9)
8236 ntpd 4.1.1c-rc1@1.836 Tue Apr 12 02:17:55 KST 2011 (471)
8130 ntpd 4.1.1c-rc1@1.836 Wed Aug 8 14:37:46 KST 2012 (361)
5599 ntpd 4.1.1c-rc1@1.836 Fri Nov 19 10:37:40 KST 2010 (414)
4591 ntpd 4.1.1@1.786 Thu Sep 20 21:30:08 KST 2012 (1)
3822 ntpd 4.1.0 Fri Sep 3 21:16:13 KST 2010 (1)
3642 ntpd 4.1.1c-rc1@1.836 Mon Apr 13 16:30:44 KST 2015 (12)
3557 ntpd 4.1.1c-rc1@1.836 Fri Feb 7 13:59:35 KST 2014 (3)
3411 ntpd 4.1.1@1.786 Sat Mar 20 23:54:04 KST 2004 (71)
3287 ntpd 4.1.1@1.786 Tue Jan 26 16:44:08 KST 2010 (1)
3280 ntpd 4.1.1c-rc1@1.836 Wed Apr 8 13:32:51 KST 2015 (25)
2892 ntpd 4.1.1@1.786 Wed Oct 20 16:50:38 KST 2010 (1)
2698 ntpd 4.1.1@1.786 Mon Jul 21 19:56:22 KST 2014 (32)
2590 ntpd 4.2.6p2@1.2194 Tue Jul 17 09:08:49 UTC 2012 (1)
2415 ntpd 4.2.6p2@1.2194 Mon Dec 22 02:40:05 UTC 2014 (1)
2393 ntpd 4.1.1c-rc1@1.836 Mon Sep 3 10:59:53 KST 2012 (412)
2357 ntpd 4.1.1c-rc1@1.836 Wed Nov 12 17:35:24 KST 2014 (5)
2303 ntpd 4.1.0 Fri Nov 26 19:21:49 KST 2010 (28)
2299 ntpd 4.1.1@1.786 Sat May 16 01:59:28 CST 2009 (1)
2072 ntpd 4.1.1@1.786 Thu Nov 21 15:27:20 KST 2013 (1)
1943 ntpd 4.1.1@1.786 Thu Dec 15 16:09:31 KST 2011 (1)
1846 ntpd 4.2.6p5@1.2349 Mon Dec 2 09:52:06 UTC 2013 (37)
1827 ntpd 4.1.1a@1.791 Wed Feb 5 17:54:41 PST 2003 (42)
1782 ntpd 4.2.6p5@1.2349 Tue Jul 22 08:19:36 UTC 2014 (1)
1773 ntpd 4.2.6p5@1.2349-o Wed Apr 1 08:17:37 UTC 2015 (1)
1772 ntpd 4.2.4p4@1.1520 Tue Feb 19 10:06:54 UTC 2008 (1)
1760 ntpd 4.1.1c-rc1@1.836 Wed Jan 4 19:51:13 KST 2012 (564)
1657 ntpd 4.2.6p5@1.2349-o Mon Mar 16 14:53:03 UTC 2015 (1)
1632 ntpd 4.1.1c-rc1@1.836 Fri Jan 25 16:54:43 KST 2013 (411)
1531 ntpd 4.1.1@1.786 Thu Oct 7 21:30:18 KST 2010 (19)
1482 ntpd 4.1.1c-rc1@1.836 Mon Jan 28 18:56:40 KST 2013 (2)
1448 ntpd 4.1.1@1.786 Mon Dec 9 17:42:42 KST 2013 (12)
1415 ntpd 4.1.1c-rc1@1.836 Fri Jan 25 16:35:27 KST 2013 (411)
1337 ntpd 4.2.0-r Thu Aug 11 12:41:19 CDT 2005 (1)
1317 ntpd 4.2.7p440@1.2483-o Fri Aug 15 12:50:53 UTC 2014 (1)
1281 ntpd 4.2.8p2@1.3265-o Thu Apr 9 14:13:40 UTC 2015 (1)
1263 ntpd 4.1.1@1.786 Tue Nov 26 10:21:44 KST 2013 (7)
1236 ntpd 4.2.6p5@1.2349 Fri May 16 02:16:26 UTC 2014 (1)
1193 ntpd 4.1.0-a Wed Oct 9 12:19:42 GMT 2002 (1)
1103 ntpd 4.1.1@1.786 Fri Apr 10 11:45:44 KST 2015 (1)
1062 ntpd 4.2.5p113@1.1720-o Wed Aug 27 15:20:28 UTC 2014 (1)
1055 ntpd 4.1.1c-rc1@1.836 Fri May 7 14:34:37 KST 2010 (416)
1051 ntpd 4.2.6p2@1.2194 Fri Dec 27 03:51:03 UTC 2013 (2)
1038 ntpd 4.2.6p3@1.2290 Wed May 25 02:36:25 UTC 2011 (1)
1018 ntpd 4.1.1c-rc1@1.836 Wed Nov 16 17:52:53 KST 2011 (120)
-- snip --
trimmed past 1k
He obviously didn't see my post a few weeks back about hosts that were
looking for an NTP server that went out of service back in 1999. And yes,
some were still using NTP v1 and v2.
There's a *lot* of stuff on very serious autopilot out there....
I did see it, and I was assuming it was a "local" configuration problem.
This is "death by 1,000 cuts" and when I wrote my recent query I was
looking for the big offenders.
To me this situation goes hand-in-hand with the problems getting bcp38
deployed, and what Dan Geer talked about in his keynote speech at Black
Hat 2014:
http://www.youtube.com/watch?v=nT-TGvYOBpI
I get that some folks have real problems with their build systems and
it's hard to upgrade software tools in that environment. I know it's
can be expensive to solve that problem. I'd love to find a way to have
the "versioned tool chain" stuff that I implemented at Cisco/Andiamo be
generally available, but I haven't found that many folks willing to
support it yet and I just don't have the spare cycles to add that to my
"do it for free" pile.
I do know that if more companies were to use this sort of tool that the
argument of "we can't patch older releases because we don't have those
tools anymore and the Q/A process becomes horribly expensive" goes
away. And that also means that it's far less expensive and therefore
far more profitable to offer maintenance support on older software
releases for much longer periods of time. But I must be missing
something here as well, as I was never able to make headway with this
idea when I was at Cisco.
The problem is people like Cisco don't make it easy
to configure these protocols at all. You can only insert an IP address
and their configuration system is all fire-and-forget additive causing
config bloat. What's the harm in putting in a few more NTP lines if it
just works.
The NTP software does a lot of very esoteric things that don't
matter much to those outside the super-time-geek space. This isn't blame,
but it makes it harder for the upstream systems to injest them. Take
JunOS which is effectively a type of FreeBSD port. The FreeBSD devs
have very strict ideas of what should be part of the core OS, quality
and ideas that prevent injesting something that isn't marked "full release".
The release-early and release-often mantra comes to mind for me. If
you do that, it's much easier for downstream people to package your latest
upstream package. They take the idea of what you consider stable seriously
and many developers i know don't like issuing a release because they know
it does or might have some bugs. Sometimes that means rapid iterations
which is much better than having stale software for N years where N is
quite large like it is here.
- Jared
Hi Harlan,
> I know that Cisco, for example, uses NTP in around 10 different
> product lines, but I don't know what versions of NTP are in current
> use.
At least with the equipment with which I'm familiar they weren't using
the reference implementation and as such, they didn't implement all the
bells and whistles. So monlist and all the mode 6/7 stuff for instance
isn't something you get with typical cisco gear, nor any ntp specific
version number. Their implementation may be "older" in that sense, but
perhaps safer, because it is "simpler" too. I had once heard the ntp
code in ios was based on ntpd v3 (the code and protocol) and was
relatively robust, done by a very capable coder. An authoritative
voice on what the current state is would be helpful of course.
Nonetheless, there are lots of cisco devices with ntp on them.
Presumably most of them are using roughly the same code.
> I'm also curious about the answers here for Juniper and other
> network gear providers. That would include routers, switches, and
> other types of gear.
JUNOS roughly follows FreeBSD and the reference implementation, but
they have lagged behind a bit of what is generally available of
course. You can easily find ntp running on JUNOS5 if that is any
indication of what is in the wild.
Jared probably has as good as any source of this data, but we have some
too that might go back a little further. If you need anything more
specific than the above, let me know.
John