NTP is one of those things that really keeps messing with my head.
To break it down, what does it do for us?
Simple. It provides the correct time of the day.
How does it accomplish this? Now this is where it gets interesting.
Lets assume that you have a router which is already synchronized. Since it is already synchronized with a time source, it itself can become a time source. How does it perform this new role?
NTP supports different modes of distributing the time. Take a look at these:
NTP Broadcast
NTP Multicast
NTP Server
NTP Peer
NTP broadcast is pretty self-explanatory. It works by sending out broadcasts from a time source which is synchronized. On the client, you simply tell it to be an NTP broadcast client, and on the server you tell it to broadcast the NTP packets.
NTP multicast follows the same school of thought. You want to have a time source sending out time to multiple clients. This is exactly the same as it would be for a video multicast. One source, many receivers.
NTP peering is a bit of a special one. Basically both your peers must be synchronized. They will then try and synchronize the time in between them. Since this is not a topic i have done enough research into, i will leave this mode of operation for a later post.
However, i do want to cover some other modes with an example. Specifically i want to take a look at broadcast and multicast distribution of time. Take a look at the topology below:
In this topology we have 4 routers. Ranging from R1 to R4. We have 2 subnets, mainly 172.16.100.0/24 and 192.168.100.0/24. We are running an IGP, which is OSPF. All in area 0 for simplicity.
What we want to do is setup our underlying multicast network. Make sure that everything is working there. After that has been completed, we want to make R1 into our company’s authoritative time source. We have 3 other routers that needs the correct time-of-day information.
R2 and R3 are pretty new routers which have no problem using a multicast source. R4 however, is an older router, and the guy in charge of this router would really appreciate if you could broadcast the information to this router instead. Being the nice guys/girls we are, we have agreed. So stated simply:
Deliver time to R2 and R3 through multicast, and deliver time to R4 using broadcasts.
Lets get started.
First off, lets configure R1, R2 and R3 for using multicast. In this scenario i will be using BSR which is part of the PIMv2 specification. I will be operating in sparse-mode only. I will use R2 as my RP and my BSR router. After this has been completed, i want to see both R1 and R3 using R2 as the RP.
On R1:
On R2:
On R3:
After a while we should check out to see if we get our RP information.
on R1:
On R2:
Everything looks good. Now we are ready to setup our NTP multicast on R1:
Lets verify we have an authoritative source on R1:
And after a wait:
From this we can see that we are sending to the multicast group that we specified under the interface command.
Lets configure R2 to receive the multicast traffic.
We do this in interface mode, facing R1:
Again, after a while (remember that NTP is really slow compared to other technologies you might be used to!):
Great! we can now see that we are synchronized with R1. Just as you would see in “server” mode, the stratum number has increased by one “hop”.
Lets check out the mroute table on R2:
Whats interesting is that R1 itself is joining the group (239.1.1.1) as you can see from the (*, 239.1.1.1). And sure enough, checking IGMP groups on R1 reveals:
What can also be seen from the mroute output is that we have a source (R1 (172.16.100.1)) sending data to the 239.1.1.1 group.
Now lets take it one step further and head on over to R3 and configure it to receive the NTP time:
Again…. we wait.
But in the meantime, lets check out the mroute table on R3 and R2:
R3:
R2:
What we see here, is that we are indeed joining the 239.1.1.1 group on R3 and that R2 sees the join and has R3 in its OIL.
After our wait:
Please note that the “hop” count has not increased as we really just pass along the information through R2.
Now, imagine that all of a sudden we have had a request from the guys who are administrating R3. They require authenticating any time source they receive. Hmm. How do we go about accomplishing this?
Well, lets configure authentication on R3 and we’ll work from there.
Basically this tells the router to authenticate time sources. We have setup key 1 with a string of cisco. Also we explicitly tells the router to trust key 1.
Failure to do the last part would result in (debug ntp authentication):
Back to our time source, we need to tell it the authentication information as well:
On R1, we also create our key. Ofcourse these need to match each other. the “ntp authenticate” command seems odd here, and i agree. In older versions of IOS, its said you dont really need this when the router itself is the time source. The command is historically used for authenticating other time sources. However, after some experience i have learned to turn it on. Just to avoid any misconfigurations. We then explicitly trust key 1.
The only alteration of our interface based command is to append the key we want to use for this multicast stream. Only one key per multicast stream is supported.
Lets verify on R3 (please note that the time has shifted since i wrote this post over multiple days):
Great! everything is working.
At the end of the day, R4 also need the correct time, but it only supports broadcast, so lets setup this feature. We will be doing that on R2 which itself is receiving the multicast stream (without authentication):
And on R4:
Lets do a final verification of everything:
R1:
R2:
R3:
R4:
It would seem that our small network can all agree on the time. Thats all for this time folks. Hope it was worth your time!