The Network Time Protocol

Time based ACLs are great, but if the routers involved aren’t keeping the same time and calendar (don’t have a synchronized time and don’t have synchronized dates) , the ACLs are unlikely to work as we had planned.

So that’s a small problem that can come in and there are some bigger problems too.

It’s vital for our routers and switches to have a central time source that allows our network devices to synchronize their clocks. Doing so allows our syslog timestamps to have accurate and synched time throughout the network, making troubleshooting a lot less frustrating.

what I’ve done in previous sections is left the time stamps out! I turned them off because I wanted to be able to concentrate on the message. The time stamps can get pretty long. But I’m going to run them in this particular section and you’ll see exactly what I’m talking about. If you take the logs from two different routers and you’re trying to compare and say: “OK this event happened on R2 then this happened on R3”,  you can do that if the time is synchronized.

Synched time is critical for digital certificate operation as well. They’re not going to work unless the routers are synched.

are many other security and accounting features that rely on synchronized times or at the network. So having sinked time in our network is not a luxury it is a necessity.

And that’s what the “Network Time Protocol” is all about.

NTP allows us to specify time sources for our network devices,  whether that time source be another device(router or multilayer switch) in the same network or it could be a external time source (outside of our network) and in real world networking you’re usually going to have a combination of that.

You’ll have one device (a perimeter router) where all your traffic is going to that the internet goes out through that particular router, that router is probably getting its official time from another device and then we configure the network. So once that router has the correct time from an outside source, all the other routers in our network are getting it from an inside source. 

An NTP is set up as a hierarchy. It’s really a pyramid.

At the very top of our NTP hierarchy are stratum-0 devices,  (and that sounds like something radioactive but it simply means that our device are the devices at the top of the hierarchy), typically atomic clocks. That number in stratum 0 refers to the number of hops or layer away from the top a particular devices, and if it’s stratum 0 it’s 0 hops away from the top! It is the top!

These are typically atomic clocks and you cannot configure a Cisco router or a device to get its time directly from a stratum 0 server.

These are not stratum zero clocks:

These are just clocks.

This is an atomic clock:

This is the atomic clock the alternate master clock actually at the United States Naval Observatory in Colorado.

This is actually an NTP stratum 0 server, and this is the alternate master clock.

You don’t want to see what the real one looks like or the main one.

But I think you could see this has a little more horsepower than your average Cisco router switch. So this is the kind of device we’re talking about at the top of the NTP hierarchy.

Now as far as that goes where can we get our time?

Well again I’ve got a reminder here we’re talking about the number in stratum being the number of hops away the devices from stratum 0.

It is not an indicator of reliability. we’re not saying that stratum 5 is twice as reliable as stratum 10 or anything like that.

Stratum 1 servers are usually called time servers (sometimes Authoritative time servers) and we can configure a Cisco router to get its time from a stratum 1 device.  That’s usually what you’re going to do with your outside router.

It is strongly recommended that your network’s “outside” router receive it’s time from a public NTP time server.

For the latest IP addresses of those servers, just run a search on the term public NTP servers.

(It’s not something you need to do for the exam) And here’s a port you should watch out for.

Be sure not to block UDP port 123 on any of the routers in your network —  because that is the port NTP uses.

(if you’re shutting down a bunch of ports and you do that and accidentally forget to allow it then all of a sudden your time is going to become unsynched.)

There are several different types of relationships we can set up in our network with NTP.

Cisco routers can serve as NTP servers, clients, or peers.

They can also depend on NTP broadcasts for the correct time.

The NTP server-client relationship is as you’d expect, with the server giving the correct time to clients.

Here, a multilayer switch in the role of NTP Server is sending the correct time to an NTP client.

Clients accept the time synch message from the server, and set their internal clock accordingly.

Clients do NOT send NTP time sync messages back to the server.

We’re not limited to the traditional Server/Client relationship with NTP. NTP peers send NTP messages to each other, and either peer can send time synch messages to the other.

It looks like something like this:

First we had our NTP server and that’s a multilayer switch.That is our master. That’s the actual command. It sends the time to an NTP client.

You can then make that client a peer of another router and they’re going to exchange two way time sync messages.

So that’s actually what we’re going to configure. we’re going to use our routers 1 2 and 3 but we’re going to configure something very much like this.

In our lab, we’ll configure R1 as our NTP server, with R2 as its only client.

In our lab، we’ll configure R1 as our NTP server,  with R2 as it’s only client

You always have to check the clock of a device that you’re going to make an NTP master.

For R1, that is the correct time, but R2 needs to be up to date.

Let’s go to R1 and start making that happen.

One small disappointment here you cannot make a Cisco router into an atomic clock with the command ‘ntp master 0” because there is no command ‘ntp master 0’!!.

We are limited to the stratums 1 through 15 here on a Cisco router and notice that this is a legal command by itself. So I think we’ll leave it at the legal command there without specifying a stratum number and that way we’ll see what the defaults are. This is the only command we actually need to make this an ntp master device.

Let’s go down to R2 and have a look at our commands here

One commands you won’t see here is ‘ntp client’ even though R2 is going to be an NTP client. So what command do we use?

We actually use NTP server here. Technically iOS help is correct. It’s a little misleading when it says configure NTP server. I’m not actually configuring the server. I am pointing this client to the server.

And really here we’re done!  I want to show you one option here and that’s ‘prefer’. We love redundancy and we would love it if R2 had three NTP servers to choose from on our network.

You can configure multiple servers. You could just put an NTP server and again they would be separate commands and you don’t put them all on one line, but you just put in 123.1 then 123.3 then 123.4 wherever the servers are. But you may have one that you want to prefer over the others and that’s where the “prefer” option came in. So if I had another NTP server here i.e 172.12.123.3  but I prefer to use 123.1 here, I would simply put ‘prefer’ right there.

Let me introduce you to a couple of really important NTP commands:

The first one is ‘show ntp associations’

This is the master device, so when we look at what NTP devices is associated with, when you see 127.127.1.1, that’s the loop back here. That means the association is with this device. The reference clock gives you a huge hint (LOCL stands for local).

Notice the stratum here is 7.

What we always need when it comes to our client-server relationships in NTP including the server, is to see these two symbols  ‘*’ and ‘~’ next to the address before we know our job is done.

You want to see  ‘system peer’ and in this particular case you want to see ‘configured’ because we did configure it with the NTP master command.

On the master itself  you’re going to see it really quick because the association is with itself, but with the other devices (with our clients) It may not be as quick.

Let’s run ‘show ntp status’. This is our second command.

The key phrase is : ‘clock is synchronized’. That’s what we want to see.

Notice here is says stratum 8. That’s the default stratum of the router itself.

And remember this stratum is 7 because that’s the internal clock.

So the router itself is seen as one layer down from its own internal clock on a master.

when you see 127.127.1.1 we know that reference is a loopback clock. That’s this device.

So on R1 everything’s good.

Now we need to go to our client and check things out and we will start with show ntp status’

First thing we see is ‘clock is unsynchronized’  so this does take a while

When you see stratum of 16 that’s another huge clue that things are not as they should be and ‘no reference clock at all’ ! that’s not good either.

Let’s run ‘show ntp associations’

 and starting to look good here…

Now notice that we do see our two symbols(*~) next to the ntp device we’re associated with which is 123.1 , So that’s good. We’re getting somewhere.

The reference clock and the stratum information here is the information of the associated device not the local device. So that’s why we’re seeing 127.127.1.1 because this is such a powerful command it’s even showing us where the associated device is getting it’s time from…and also what stratum it is. So progress has been made.

What we’ve got to do though is wait for ‘show ntp status’ to sync up…

you can see our last last update was three seconds ago.

And we are sync up now.

You can see ‘clock is synchronized’ and  notice the stratum is 9 so we’re seeing that hierarchy in action.

The hardware clock on R1 is a stratum 7. The router itself at stratum 8 and now R2 at stratum 9 and there’s the reference.

Let’s go ahead and run ‘show ntp associations’

and we see everything we expect to see. We’re actually seeing that before as far as the address reference clock and stratum.

And of course the most important thing is ‘show clock’ and you can see now that it has indeed updated and we are synched up with R1

What we’re going to do next is set up a peering between routers two and three and start flowing the correct time throughout the rest of our network.

Peering Lab

Time to add R3 to the mix and routers two and three are going to be communicating over the 172.23.0 /24 network. R3 is not on the serial network in this LAB

 So it’s go ahead. I did do a couple of tests here before we started just to make sure everything was still in place… and it is…

You can see R2 still associated with 123.1 and is still getting its time from that device so were set there.

The two devices can ping.

So let’s go ahead and run ‘show clock’ while we’re at it

and you can see that R3 isn’t quite as behind the times as R2 was earlier. But still we need to get that sync up and get R3 up to date.

We’re going to set up a peering here just for fun instead of setting up another server client relationship … We’ll start on R2

And we’re going to put 172.12.23.3 there.

That’s all there is to it.

You can do a ‘Prefer’ on peerings as well if you want to, but for our purposes this is the only thing we really need

You’re all set.

All good…

The reference point being the device we’re getting at the time from (172.12.23.2) and everything looks good.

Let’s run ‘show ntp assoc’

We see where the associated device is getting its time from (which is 123.1)… The associated device Is stratum 9.

So we are all set there… we’ll do a quick ‘show clock’ because that’s what it’s all about.

And we see that the time has synced up.

Broadcast Mode

I want you to see NTP broadcast mode in action… not complicated at all but one classic little gotcha you got to watch out for.

We still have R1 and R2 up and running over the 172.12.123.0 network.

I did take the NTP server command off of R2 (as a matter of fact I took all the NTP commands off of R2).

So right now NTP isn’t even running on R2… Router one is still a master.

And what we’re going to do instead of setting up a unicast communication is set up the master device to broadcast NTP information out a given interface and the reason I say a given interface is that this is an interface level command.

So if you start looking for it within NTP ios, it’s not going to work.

What you need to do instead is go this way and use NTP ios help here

 and under the interface we have broadcast.

And then we have some options and the <cr>, so we know this is a legal command by itself.

Here’s a little Gotcha I imagine…  NTP broadcast is for your master devices and NTP broadcast client is for your clients.

I know that seems obvious but I’m saying it anyway.

Because if you just put NTP broadcast on everything, when you’ve got a master device and some devices you want as clients but you’re using broadcast, then you’re just going to be sitting there for a long time. Because the conflict will not work. It will be accepted by the routers but it won’t work.

So we’ll go with NTP broadcast there and then down on R2, on the serial interface, it’s ‘ntp broadcast client’

and as you would expect, we have to wait for a minute or two while R2 syncs up…

R2 still has the correct time.

However I did get rid of the association but it still had its time it got from router 1 in a previous lab.

So after a while when the association is up and running, we are all set.

R2 at ‘show ntp Association’ is showing everything we were expect to see and even more importantly ‘show ntp status’ shows the clock is synchronized.

One small difference here you might look over the red cycle and say OK where’s my “~” ?

Well you have to have both of those if you have an actual server client relationship configured.

But here we didn’t do that. R1 is sending NTP broadcast out its serial interface.

We enabled R2 to listen to that  in the role of a client, but we didn’t say NTP server 172.12.123.1. So since the little squiggly(~) stands for it configured, we do not see one over here. This address was learned via a broadcast.