NTP and modes of operation.
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:
R1(config)#int s0/0 R1(config-if)#ip pim sparse-mode
On R2:
R2(config)#int loo0 R2(config-if)#ip pim sparse-mode R2(config-if)#int s0/0 R2(config-if)#ip pim sparse-mode R2(config-if)#int f0/0 R2(config-if)#ip pim sparse-mode R2(config-if)#ip pim rp-candidate loo0 R2(config)#ip pim bsr-cand loo0
On R3:
R3(config)#int f0/0 R3(config-if)#ip pim sparse-mode
After a while we should check out to see if we get our RP information.
on R1:
R1#sh ip pim rp map PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 2.2.2.2 (?), v2 Info source: 2.2.2.2 (?), via bootstrap, priority 0, holdtime 150 Uptime: 00:14:02, expires: 00:02:20
On R2:
R2#sh ip pim rp map PIM Group-to-RP Mappings This system is a candidate RP (v2) This system is the Bootstrap Router (v2) Group(s) 224.0.0.0/4 RP 2.2.2.2 (?), v2 Info source: 2.2.2.2 (?), via bootstrap, priority 0, holdtime 150 Uptime: 00:15:23, expires: 00:01:57 And finally on R3: R3#sh ip pim rp map PIM Group-to-RP Mappings Group(s) 224.0.0.0/4 RP 2.2.2.2 (?), v2 Info source: 2.2.2.2 (?), via bootstrap, priority 0, holdtime 150 Uptime: 00:14:39, expires: 00:01:43
Everything looks good. Now we are ready to setup our NTP multicast on R1:
R1#clock set 16:53:00 january 25 2011 R1#conf t R1(config)#ntp master R1(config-if)#int s0/0 R1(config-if)#ntp multicast 239.1.1.1
Lets verify we have an authoritative source on R1:
R1#sh ntp status Clock is synchronized, stratum 8, reference is 127.127.7.1 nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**24 reference time is D0E97060.1DB4F76E (16:53:04.116 CET Tue Jan 25 2011) clock offset is 0.0000 msec, root delay is 0.00 msec root dispersion is 15875.02 msec, peer dispersion is 15875.02 msec R1#sh ntp ass address ref clock st when poll reach delay offset disp *~127.127.7.1 127.127.7.1 7 4 64 3 0.0 0.00 7875.0 * master (synced), # master (unsynced), + selected, - candidate, ~ configured As we can see, we are locally the source, with a stratum of 7 (our own time is actually stratum 8 as can be seen in the sh ntp status command) Lets turn on debug on R1 to see if any NTP packets are being sent: R1#debug ntp packets NTP packets debugging is on
And after a wait:
R1# Jan 25 15:56:20.115: NTP: xmit packet to 239.1.1.1: Jan 25 15:56:20.119: leap 0, mode 5, version 3, stratum 8, ppoll 64 Jan 25 15:56:20.123: rtdel 0000 (0.000), rtdsp 1E002 (1875.031), refid 7F7F0701 (127.127.7.1) Jan 25 15:56:20.123: ref D0E97120.1DB4633F (16:56:16.116 CET Tue Jan 25 2011) Jan 25 15:56:20.127: org 00000000.00000000 (01:00:00.000 CET Mon Jan 1 1900) Jan 25 15:56:20.131: rec 00000000.00000000 (01:00:00.000 CET Mon Jan 1 1900) Jan 25 15:56:20.135: xmt D0E97124.1DB56218 (16:56:20.116 CET Tue Jan 25 2011)
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:
R2(config)#int s0/0 R2(config-if)#ntp multicast client 239.1.1.1
Again, after a while (remember that NTP is really slow compared to other technologies you might be used to!):
R2#sh ntp status Clock is synchronized, stratum 9, reference is 172.16.100.1 nominal freq is 250.0000 Hz, actual freq is 249.9999 Hz, precision is 2**18 reference time is D0E971E4.242B0107 (15:59:32.141 UTC Tue Jan 25 2011) clock offset is 3.9845 msec, root delay is 10.42 msec root dispersion is 16005.00 msec, peer dispersion is 15875.99 msec R2# R2#sh ntp ass address ref clock st when poll reach delay offset disp * 172.16.100.1 127.127.7.1 8 36 64 6 10.4 3.98 15876. * master (synced), # master (unsynced), + selected, - candidate, ~ configured
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:
R2#sh ip mroute IP Multicast Routing Table (*, 239.1.1.1), 00:22:07/00:03:00, RP 2.2.2.2, flags: SJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: Serial0/0, Forward/Sparse, 00:02:25/00:03:00 (172.16.100.1, 239.1.1.1), 00:22:04/00:02:22, flags: PLT Incoming interface: Serial0/0, RPF nbr 172.16.100.1 Outgoing interface list: Null
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:
R1#sh ip igmp groups IGMP Connected Group Membership Group Address Interface Uptime Expires Last Reporter Group Accounted 239.1.1.1 Serial0/0 00:23:31 stopped 172.16.100.1 224.0.1.40 Loopback0 00:27:16 00:02:55 1.1.1.1
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:
R3(config)#int f0/0 R3(config-if)#ntp multicast client 239.1.1.1
Again…. we wait.
But in the meantime, lets check out the mroute table on R3 and R2:
R3:
(*, 239.1.1.1), 00:00:45/stopped, RP 2.2.2.2, flags: SJPCL Incoming interface: FastEthernet0/0, RPF nbr 192.168.100.2 Outgoing interface list: Null (172.16.100.1, 239.1.1.1), 00:00:08/00:02:57, flags: PLTX Incoming interface: FastEthernet0/0, RPF nbr 192.168.100.2 Outgoing interface list: Null
R2:
(*, 239.1.1.1), 00:26:35/00:03:26, RP 2.2.2.2, flags: SJCL Incoming interface: Null, RPF nbr 0.0.0.0 Outgoing interface list: FastEthernet0/0, Forward/Sparse, 00:01:33/00:02:55 Serial0/0, Forward/Sparse, 00:06:53/00:03:26 (172.16.100.1, 239.1.1.1), 00:26:32/00:02:39, flags: LT Incoming interface: Serial0/0, RPF nbr 172.16.100.1 Outgoing interface list: FastEthernet0/0, Forward/Sparse, 00:01:33/00:03:15
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:
R3#sh ntp status Clock is synchronized, stratum 9, reference is 172.16.100.1 nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**18 reference time is D0E9732B.C4229C68 (16:04:59.766 UTC Tue Jan 25 2011) clock offset is 8.4141 msec, root delay is 58.76 msec root dispersion is 15883.45 msec, peer dispersion is 15875.02 msec R3# R3#sh ntp ass address ref clock st when poll reach delay offset disp * 172.16.100.1 127.127.7.1 8 49 64 6 58.8 8.41 15875. * master (synced), # master (unsynced), + selected, - candidate, ~ configured
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.
R3(config)#ntp authenticate R3(config)#ntp authentication-key 1 md5 cisco R3(config)#ntp trusted-key 1 R3(config)#int f0/0
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):
NTP: Authentication Failure, Peer not Created
Back to our time source, we need to tell it the authentication information as well:
R1(config)#ntp authentication-key 1 md5 cisco R1(config)#ntp authenticate R1(config)#ntp trusted-key 1 R1(config-if)#ntp multicast 239.1.1.1 key 1
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):
R3#sh ntp status Clock is synchronized, stratum 9, reference is 172.16.100.1 nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**18 reference time is D0EC1678.FC8323A2 (16:06:16.986 UTC Thu Jan 27 2011) clock offset is 21.7590 msec, root delay is 15807.82 msec root dispersion is 420.44 msec, peer dispersion is 398.65 msec R3# R3#sh clock 16:07:10.854 UTC Thu Jan 27 2011
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):
R2(config)#int f0/0 R2(config-if)#ntp broadcast
And on R4:
R4(config)#int f0/0 R4(config-if)#ntp broadcast client
Lets do a final verification of everything:
R1:
R1#sh ntp status Clock is synchronized, stratum 8, reference is 127.127.7.1 nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**24 reference time is D0EC1786.020A9F87 (17:10:46.007 CET Thu Jan 27 2011) clock offset is 0.0000 msec, root delay is 0.00 msec root dispersion is 0.02 msec, peer dispersion is 0.02 msec R1#sh clock 17:11:29.315 CET Thu Jan 27 2011
R2:
R2#sh ntp status Clock is synchronized, stratum 9, reference is 172.16.100.1 nominal freq is 250.0000 Hz, actual freq is 250.0002 Hz, precision is 2**18 reference time is D0EC17B9.046FE035 (17:11:37.017 CET Thu Jan 27 2011) clock offset is -9.2216 msec, root delay is 20.20 msec root dispersion is 21.61 msec, peer dispersion is 12.34 msec R2#sh clock 17:11:41.873 CET Thu Jan 27 2011
R3:
R3#sh ntp status Clock is synchronized, stratum 9, reference is 172.16.100.1 nominal freq is 250.0000 Hz, actual freq is 250.0001 Hz, precision is 2**18 reference time is D0EC17B8.FE0523BB (17:11:36.992 CET Thu Jan 27 2011) clock offset is 15.8446 msec, root delay is 15807.82 msec root dispersion is 46.46 msec, peer dispersion is 30.59 msec R3#sh clock 17:11:52.937 CET Thu Jan 27 2011
R4:
R4#sh ntp status Clock is synchronized, stratum 10, reference is 192.168.100.2 nominal freq is 250.0000 Hz, actual freq is 250.0000 Hz, precision is 2**18 reference time is D0EC17A7.DB439C93 (17:11:19.856 CET Thu Jan 27 2011) clock offset is -50.7573 msec, root delay is 3914.61 msec root dispersion is 1951.51 msec, peer dispersion is 1869.75 msec R4#sh clock 17:12:07.041 CET Thu Jan 27 2011
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!