Using NTP to Send Periodic Broadcast Time Updates
Problem
You want to set up your router to use the NTP broadcast mode so that devices do not need to query periodically for the time.
Solution
Use the NTP broadcast interface configuration command to enable server-side NTP broadcasts:
Router1#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router1(config)#clock timezone EST -5
Router1(config)#clock summer-time EDT recurring
Router1(config)#ntp server 172.25.1.1
Router1(config)#ntp server 172.25.1.2
Router1(config)#interface FastEthernet0/0
Router1(config-if)#ntp broadcast
Router1(config-if)#end
Router1#
To enable a NTP broadcast client on the router, enter the following:
Router2#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router2(config)#clock timezone EST -5
Router2(config)#clock summer-time EDT recurring
Router2(config)#ntp broadcastdelay 4
Router2(config)#interface Ethernet0
Router2(config-if)#ntp broadcast client
Router2(config-if)#end
Router2#
Discussion
Usually NTP associations are configured in a master/slave relationship, but the server (router) can also send periodic time updates using broadcast messages. This is useful on LAN segments that contain a large number of devices requiring NTP synchronization. Instead of responding to a large number of unicast NTP packets through a single interface, the router can simply send a single broadcast packet at a regular interval.
NTP devices configured to accept NTP broadcast messages can synchronize their internal clocks without ever sending a single NTP request packet. However, this simplicity comes at the cost of reduced timing accuracy, since the traffic is one-way only. The accuracy improves slightly by configuring an estimated broadcast delay on the client side, using the ntp broadcastdelay configuration command, as in the client configuration example above.
Devices whose clocks are synchronized with NTP broadcasts are usually accurate to within a few hundreds of milliseconds. This is more than adequate for most client workstations. If some of the devices on the LAN require more accuracy, then you can configure these devices with regular NTP associations, as discussed in Recipes 14.5, 14.6, and 14.7. NTP broadcast mode does not prevent normal NTP client/server relationships from occurring as well, if required.
The example below shows a router configured as a NTP broadcast client that has synchronized its internal clock to a broadcast server:
Router2>show ntp associations detail
172.16.2.1 dynamic, our_master, sane, valid, stratum 3
ref ID 172.25.1.3, time C03A9BAB.5A1E7119 (22:46:51.352 EST Wed Mar 13 2003)
our mode bdcast client, peer mode bdcast, our poll intvl 64, peer poll intvl 64
root delay 116.56 msec, root disp 46.39, reach 376, sync dist 108.398
delay 5.19 msec, offset -0.3381 msec, dispersion 1.14
precision 2**16, version 3
org time C03A9C11.5A2376B6 (22:48:33.352 EST Wed Mar 13 2003)
rcv time C03A9C11.5B0B9E6E (22:48:33.355 EST Wed Mar 13 2003)
xmt time 00000000.00000000 (19:00:00.000 EST Thu Dec 31 1899)
filtdelay = 5.19 5.19 5.19 5.19 5.19 5.19 5.19 5.19
filtoffset = -0.34 -0.53 -0.19 -0.18 -0.27 -0.32 -0.26 -0.34
filterror = 0.99 1.97 2.94 3.92 4.90 5.87 6.85 7.83
Router2>
Note that the ntp broadcast commands are interface configuration-level commands, configured on the interface that is sending or receiving the NTP broadcasts. However, the ntp broadcastdelay command is a global configuration command affecting all interfaces that use NTP broadcast features.