The NTP or Network Time Protocol is a KEY function of all of your network equipment. If I have said it once and you’re annoyed that I’m saying it again then be annoyed because trust me, if you don’t do this then one day you will regret your decision. Find an NTP host, point at it, synchronise yourself and make sure you keep it going.

So lets start from the beginning here.

NTP is a protocol running on UDP port 123....easy to remember that yeah? 123 easy like...123...also it remind me of the time 1 o’clock, 2 o’clock 3 o’clock. You know, the NTP port number feels to me like one of the obvious exam questions. Anyway NTP, lets think about it.

Imagine you have a system and it has a problem. Maybe you are logging the issue locally on the device and are also capturing logs from other devices on a syslog server. So you want to find out what happened across all of this kit to see if there are any common starting points but they don’t match. Crucially you have forgotten to synchronise their times so the logs don’t match - you are hosed because you can’t see any commonality. NTP would be your answer here. The NTP protocol (and services which use it) would automatically synchronise the time between all of these devices...bliss.

Remember NTP updates use the UTC or Universal Time Constant which is disassociated with any world time-zone (but is the same as GMT). We will need to set the correct time-zone as a final step to make sure we’ve got the correct local time....we’ll do that last. First lets get NTP running.

So how do we enable this for JunOS? First of all login and go into configuration mode. The NTP configuration is all done under the ‘system > ntp’ subtree.

edit system ntp

Lets take a look at the available options

set system ntp ?

We are an NTP client and we are going to point at an NTP peer on the internet. A quick Google for ‘public ntp servers’ found this list for me - I’m in the UK but you want to choose a list of stratum 2 public NTP servers need you.

list of NTP sratum 2 servers in the UK

I’ve chosen two servers from this list for me and I’l have a primary (the most trusted) and a secondary NTP server in case the primary fails. Lets use ntp2c.mcc.ac.uk and ntp2.sandvika.net. Do you notice that the list includes both the hostname and the IP address? Well I always like to use the hostname for the configuration in case they change the server IP address. We’ll need to setup the DNS lookup server on the Juniper router so we can resolve the IP address from the domain name.

enabled DNS lookup in JunOS

I’ve chosen to use the Google public DNS servers but you can use any.

Now lets check we can lookup the IP address by using ping.

ping www.google.com

Perfect - DNS lookups are working.

Right lets configure the NTP peers then. First mcc - notice the ‘prefer’ keyword so we like this one the most.

set system ntp peer

Now for sandvika - we don’t prefer this one.

set system ntp peer

Ouch - thats not worked - no such hostname. Right lets have a look at ExNet then.

Screen shot 2011-06-22 at 21.45.34set system ntp peer

Ok great that went in - lets commit the candidate configuration now

Screen shot 2011-06-22 at 21.46.14

Lets drop out of configuration now to run some ‘show’ commands to see it build the association and synchronise the time.

show ntp associations

We’re not sync’d yet - notice we see stratum 16? There are 15 strata but mostly you sit at 2 or 3. Personally I wouldn’t ever wish to sync myself to anything less than a stratum 3 time source. The higher the number the less trustworthy the source. Lets take a look where we are now...we’ve left it for another 30 seconds...

show ntp associations

Great, we see we have sync’d to three stratum 2 time sources. Why three I hear you cry...well honestly I think the mcc time sources run a round-robin DNS so we got two different IP end hosts. Well thats it, we’re sync’d now. A few other ‘options’ you may wish to explore. What about if the remote time source is expecting you to be coming in from say your loopback address. This is normally for security reasons. Imagine each of your routers has two resilient links to the network and you are running an IGP so ca reach the NTP source from multiple links. If that source is trying to restrict the hosts talking to it you may wish to allow connectivity only form one remote IP address. If you have two links to it then there are two sources...so we use the loopback address.

Lets go through that now.

First we create the loopback address. We’ll use 3.3.3.3/24 (remember JunOS uses CIDR notation).

confgure junos loopback interface

Now we set the source for our NTP packets to the loopback IP address. Now the remote server only needs one line in it’s security filter rather than two...nice.

set junos NTP source

There are way more things we can do including setting ourselves up as an NTP time source but thats for another time.

One final thing for me though, living in the UK means that I have to consider my time-zone and more specifically British Summer Time (Dayiight Savings Time). At two times int eh year we all put our clocks forwards one hour and then backwards again. Historically this is meant to allow our farmers to do more work...not that they don’t already huh.

To set the timezone we type ‘set system time-zone’. If you wish to know what time-zone choices you have then just use the ‘?’ or context sensitive help. Here is the output for the first few lines:

set junos NTP time-zone

I already said I’m in the UK and we run on GMT or Greenwich Mean Time but more specifically I wish to support BST or British Summer Time which operates a ‘Daylights Savings Time’ +1 hour and -1 hour at two points in the calendar. Now I’ve looked and looked and cannot find any command to support this. In IOS you would use the ‘clock’ command to set a recurring adjustment (see NTP post). In this case we could maybe go for GMT+1 which would do the same sort of thing but I fear that when the clock goes back again I’d have to change this again to GMT.

set junos NTP time-zone

So thats it for this time.

Thanks for reading and good luck with your studies.
View Comments
Working on an EX recently we came across this rather curious issue. One of the checks the JunOS loader does as it extracts the new firmware is the CRC and validity checks on the package. To our great surprise we found this installation balked at us about time. Apparently we were installing a file which hadn’t been built until 25963681 seconds (300days) in the future!

Clearly the administrators had been a little lax in their approach to time keeping and certainly could do with a quick look at NTP. Anyway, without further ado lets have a look at the work we did:

First lets upgrade the stack. We’ll be using FTP to transfer the file from our FTP server running on IP address 10.15.100.75.
 
network@EX_STACK> request system software add ftp://10.15.100.75/jloader-ex3242-11.3I20110326_0802_hmerge-signed.tgz
 
Checking pending install on fpc1
 
Checking pending install on fpc0
Fetching package...
Pushing bundle to fpc1
 
Validating on fpc1
 
Validating on fpc0
Done with validate on all virtual chassis members
 
fpc1:
tar: +CONTENTS: time stamp Mar 26 12:18 2011 is 25963681 s in the future
tar: +COMMENT: time stamp Mar 26 12:18 2011 is 25963680 s in the future
tar: +DESC: time stamp Mar 26 12:18 2011 is 25963679 s in the future
tar: +INSTALL: time stamp Mar 26 12:18 2011 is 25963678 s in the future
tar: jloader-ex-3242-11.3I20110326_0802_hmerge.tgz: time stamp Mar 26 12:06 2011 is 25962920 s in the future
tar: jloader-ex-3242-11.3I20110326_0802_hmerge.tgz.md5: time stamp Mar 26 12:18 2011 is 25963673 s in the future
tar: jloader-ex-3242-11.3I20110326_0802_hmerge.tgz.sha1: time stamp Mar 26 12:18 2011 is 25963672 s in the future
tar: jloader-ex-3242-11.3I20110326_0802_hmerge.tgz.sig: time stamp Mar 26 12:18 2011 is 25963672 s in the future
tar: certs.pem: time stamp Mar 26 08:02 2011 is 25948330 s in the future
verify-sig: cannot validate ./certs.pem
certificate is not yet valid: /C=US/ST=CA/L=Sunnyvale/O=Juniper Networks/OU=Juniper CA/CN=PackageDevelopment_11_3_0/emailAddress=ca@juniper.net
 
{master:0}

HA this is perfect. OK so lets configure NTP so we don’t see this ever again (of course we could always just use ‘set date’ to do a quick fix but we’re not going to do that right?

... OK maybe just a sneaky look at setting the time manually.

At the command prompt enter the following command to set the time and date to 10:10:00 on May 27th 2011

network@EX_STACK> set date 201105271010.00

OK now we’ve had some fun there lets setup NTP. This guide assumes you have chosen a suitable NTP server. We’re going to use one of Manchester University hosts because I’ve been using it since 1996 (you can find a list of public NTP servers here)

Firstly lets tell JunOS to synchronise it’s time with the NTP server. In the past JunOS needed to be within 128 seconds of the NTP server time or else it would never sync up. Remember, if you are going to use the DNS hostname in this configuration (and we are) then you should make sure you have a DNS lookup configured. In our setup we’ve configured DNS lookup against the Google DNS hosts.

Screen shot 2011-05-27 at 22.26.05

So lets syncronise our server manually by initiating an NTP ‘get’

Screen shot 2011-05-27 at 22.34.26

Hey thats pretty good - we were only 1 second out already!

Right now we’ll setup the NTP client process so lets go into configuration mode:

Screen shot 2011-05-27 at 22.35.27

Now add in the ntp configuration command

Screen shot 2011-05-27 at 22.35.19

Lets just check it took this in the configuration

Screen shot 2011-05-27 at 22.35.14

Now commit it to flash and pop back to exec mode with the ‘commit-and-quit’ command

So we’re out of configuration mode lets check out the ntp associations and status...

Screen shot 2011-05-27 at 22.35.41

Right well we’ve got a stratum (st) of 16 here which means we’re not totally ready yet and either out router (R1) can’t talk to the remote NTP server or they cant talk to us. Lets wait...and wait...

Screen shot 2011-05-27 at 22.36.23

Great. It took about 10 seconds but now we see that we have syncronised with a stratum 2 server called ‘turnip’. I guess the hostname ntp2d is a CNAME.

All good, all in sync. Now we performed the upgrade again and it all went perfectly. Well done Juniper.

Thanks for reading.
View Comments
When there is a technical error with the device or you need to troubleshoot a failure the most important thing is time. Recently we were onsite troubleshooting a denial of service attack (DoS) on a web server for a client. They informed us that it had taken place sometime between 22:00 and 22:10 on a certain date. We asked for the web logs and then for the router/firewall logs for the period concerned. We spent time looking though the logs and noticed no commonality with the customers experience and the logs we were looking at. Indeed there appeared to be some difference even with the log files we had been given. For example a very clear HTTP GET request on the web server had no matching event on the firewall...

You guessed it, not only was the time wrong on the web server but it was also wrong on the firewall. Worse still the timezone was wrong so even if the time setting was correct we were at best an hour out as we were operating in BST.

Setting the time on the web server to point to the cisco switch (Catalyst 4500) to obtain it’s time was the first stage. The timezone was setup correctly and we were to use the windows time service using NTP. Here are the steps we took to setup the Cisco switch to set it’s timezone, to setup the correct British Summer Time skew plus the NTP daemon function so that the Cisco device to collect the correct time information from the internet and also allow the windows server to collect the time information.

First we setup the timezone so that the switch knew where in the world it was:

Screen shot 2011-04-10 at 21.24.37

Now we need to setup the NTP daemon itself. We need to find an NTP source out there to deal with us. There are different tiers of NTP service called ‘strata’. We don’t really need to be hugely accurate so we chose a stratum 2 NTP source. Here are a list of the UK NTP servers we used.

Screen shot 2011-04-10 at 21.28.18

The prefer keyword is just to say to IOS “if this one is available then we’d like you to trust this one most”. We also want to make sure our log data on the switch is given a timestamp.

Screen shot 2011-04-10 at 21.24.47

So lets just make sure it’s all working. Type “show ntp associations”

Screen shot 2011-04-10 at 21.25.16
View Comments
© 2011 defaultrouteuk.com

Cisco, IOS, CCNA, CCNP, CCIE are trademarks of Cisco Systems Inc.
JunOS, JNCIA, JNCIP, JNCIE are registered trademark of Juniper Networks Inc.