HSRP address suitable for NTP?

CSCO10631105 · ‎04-06-2009

Hi all, is it OK to point a Windows 2003 server at a HSRP address for its Windows time address? I once heard there were bugs in doing this, can someone confirm this?

Clearly my router is acting as a client/server, getting its time from our core network and a few GPS receivers.

Joe Clarke · ‎04-06-2009

It is not recommended to use an HSRP virtual IP address as an NTP server address. Here is the reasoning:

HSRP supplies a method of providing nonstop path redundancy

for the Internet Protocol (IP) by sharing protocol and Media Access

Control (MAC) addresses between redundant gateways.

HSRP address is not a physical address, but it's logical and can't be configured to reply

to UDP communication like NTP uses. When you send something to the HSRP address, it will

forward it to the active physical address and

this one will reply directly. So when the packet gets back, the source won't recognize

having requested something to the physical address and will ignore it.

This is normal behavior for the HSRP address and this is why it can't be set up like this.

It is not developed to be virtual NTP server.

So we don't recommend NTP server using HSRP virtual address.

It may not have any problem, but we won't support it.

If you want to use redundancy, configure making the NTP source a loopback IP. This way, if multiple interfaces go down on the device, but a route to the loopback is still available, then the server will still get its time update.

cisco24x7 · ‎04-06-2009

"HSRP address is not a physical address, but it's logical and can't be configured to reply

to UDP communication like NTP uses. When you send something to the HSRP address, it will

forward it to the active physical address and

this one will reply directly. So when the packet gets back, the source won't recognize

having requested something to the physical address and will ignore it.

This is normal behavior for the HSRP address and this is why it can't be set up like this. "

Not sure I agree with this statement. How do you explain this:

[Expert@P1-NGx]# ntpdate 10.250.97.1

6 Apr 21:07:31 ntpdate[6491]: adjust time server 10.250.97.1 offset -0.001195 sec

[Expert@P1-NGx]#

[Expert@P1-NGx]# tcpdump -nnni eth2 port 123

tcpdump: listening on eth2

21:05:27.390103 10.109.114.9.123 > 10.250.97.1.123: v4 client strat 0 poll 4 prec -6 (DF)

21:05:27.390663 10.250.97.1.123 > 10.109.114.9.123: v4 server strat 3 poll 4 prec -18 [tos 0xc0]

21:05:27.390700 10.109.114.9.123 > 10.250.97.1.123: v4 client strat 0 poll 4 prec -6 (DF)

21:05:27.391155 10.250.97.1.123 > 10.109.114.9.123: v4 server strat 3 poll 4 prec -18 [tos 0xc0]

21:05:27.391175 10.109.114.9.123 > 10.250.97.1.123: v4 client strat 0 poll 4 prec -6 (DF)

21:05:27.391646 10.250.97.1.123 > 10.109.114.9.123: v4 server strat 3 poll 4 prec -18 [tos 0xc0]

21:05:27.391664 10.109.114.9.123 > 10.250.97.1.123: v4 client strat 0 poll 4 prec -6 (DF)

21:05:27.392137 10.250.97.1.123 > 10.109.114.9.123: v4 server strat 3 poll 4 prec -18 [tos 0xc0]

interface FastEthernet0/1

description LAB interface

ip address 10.250.97.2 255.255.255.0 secondary

ip address 192.168.15.1 255.255.255.0

ip helper-address 192.168.3.10

no ip redirects

ip accounting output-packets

ip flow ingress

ip pim dense-mode

ip route-cache flow

load-interval 30

duplex full

speed 100

standby 40 ip 10.250.97.1

standby 40 timers 10 45

standby 40 priority 105

standby 40 preempt

standby 40 name vip_4

end

Joe Clarke · ‎04-06-2009

The reasoning was given a while back (before we even had support for NTP v4), and may have changed. However, the recommendation is still to use a loopback address for the NTP source.

cisco24x7 · ‎04-06-2009

Again, I would like to know where you based this information from because ntp works fine with NTP version 2 and version 3:

[Expert@NG-lab-1]# ntpdate -o 2 10.250.97.1

6 Apr 18:25:40 ntpdate[27876]: adjust time server 10.250.97.1 offset -0.001132 sec

[Expert@NG-lab-1]# ntpdate -o 3 10.250.97.1

6 Apr 18:25:44 ntpdate[27877]: adjust time server 10.250.97.1 offset 0.000789 sec

[Expert@NG-lab-1]#

[Expert@NG-lab-1]# tcpdump -nnni eth0 port 123

tcpdump: listening on eth0

18:25:40.014151 10.109.114.9.123 > 10.250.97.1.123: v2 client strat 0 poll 4 prec -6 (DF)

18:25:40.014724 10.250.97.1.123 > 10.109.114.9.123: v2 server strat 3 poll 4 prec -18 [tos 0xc0]

18:25:40.014921 10.109.114.9.123 > 10.250.97.1.123: v2 client strat 0 poll 4 prec -6 (DF)

18:25:40.015497 10.250.97.1.123 > 10.109.114.9.123: v2 server strat 3 poll 4 prec -18 [tos 0xc0]

18:25:40.015547 10.109.114.9.123 > 10.250.97.1.123: v2 client strat 0 poll 4 prec -6 (DF)

18:25:40.016153 10.250.97.1.123 > 10.109.114.9.123: v2 server strat 3 poll 4 prec -18 [tos 0xc0]

18:25:40.016223 10.109.114.9.123 > 10.250.97.1.123: v2 client strat 0 poll 4 prec -6 (DF)

18:25:40.016808 10.250.97.1.123 > 10.109.114.9.123: v2 server strat 3 poll 4 prec -18 [tos 0xc0]

18:25:44.532455 10.109.114.9.123 > 10.250.97.1.123: v3 client strat 0 poll 4 prec -6 (DF)

18:25:44.532994 10.250.97.1.123 > 10.109.114.9.123: v3 server strat 3 poll 4 prec -18 [tos 0xc0]

18:25:44.533110 10.109.114.9.123 > 10.250.97.1.123: v3 client strat 0 poll 4 prec -6 (DF)

18:25:44.533690 10.250.97.1.123 > 10.109.114.9.123: v3 server strat 3 poll 4 prec -18 [tos 0xc0]

18:25:44.533741 10.109.114.9.123 > 10.250.97.1.123: v3 client strat 0 poll 4 prec -6 (DF)

18:25:44.534181 10.250.97.1.123 > 10.109.114.9.123: v3 server strat 3 poll 4 prec -18 [tos 0xc0]

18:25:44.534228 10.109.114.9.123 > 10.250.97.1.123: v3 client strat 0 poll 4 prec -6 (DF)

18:25:44.534796 10.250.97.1.123 > 10.109.114.9.123: v3 server strat 3 poll 4 prec -18 [tos 0xc0]

16 packets received by filter

0 packets dropped by kernel

[Expert@NG-lab-1]#

It really depends on your environment, using the loopback as NTP source may not be the best solution for your environment.

Joe Clarke · ‎04-06-2009

This data comes from an internal Cisco recommendation. The data is three years old, but I did not see a more recent recommendation other than using the loopback.

Strictly speaking, NTP has redundancy built in (i.e. you can specify multiple clock sources), so using the HSRP virtual IP is still probably not the best idea. Instead, you can specify multiple NTP servers (e.g. the physical IP addresses of each HSRP peer), and the client can decide on the best and most accurate clock source.

CSCO10631105 · ‎04-07-2009

Thanks for the replies. My 'ntp' clients is actually the Windows Time service. The reason I wated to use the HSRP is because from Windows clock GUI you can only specify one target address. I think it may be possible to put multiple addresses via the registry but I wanted to avoid that otherwise I'd use the loopbacks. NTP is important to us hence the need for redundancy. I have also heard that its possible for Windows machines (acting as a NTP server) to override the higher stratum source my routers are pointing at. We had a strange problem the other evening where we jumped 1hr and Im trying to get to the bottom of it. (the random 1hr jump wasn't GMT>BST, but 8 days later...)