Forum Discussion

janlaw_195243's avatar
janlaw_195243
Icon for Nimbostratus rankNimbostratus
Jul 23, 2015

NTP: BigIP LB Upable to sync

Hi All,

I am new to F5 ltm bip, hope can get some help from here. I have 2LB which is a HA. Both of the LB is unable to sync.

For your information:

Version : BIG-IP 11.6.0

ntp server : 8.8.8.8

Using port 2.1 to sync the self ip of lb : 1.1.1.1

I did a tcpdump to check the ntp traffic : tcpdump -npi 0.0:nnn host 8.8.8.8

I did a restart : restart /sys service ntpd

Shutting down ntpd: [ OK ]

Starting ntpd: [ OK ]

The result at the tcpdump :

  • 12:58:10.198548 IP 1.1.1.1.9218 > 8.8.8.8.ntp: NTPv4, Client, length 48

  • 12:58:10.199531 IP 8.8.8.8.ntp > 1.1.1.1.9218: NTPv4, Server, length 48

  • 12:58:10.199572 IP 1.1.1.1.169 > 8.8.8.8: ICMP 1.1.1.1 udp port 9218 unreachable, length 36

I did a ntpq -np

 remote           refid      st t when poll reach   delay   offset  jitter

==============================================================================

8.8.8.8 .INIT. 16 u - 64 0 0.000 0.000 0.000

There is a firewall in the middle so it block the icmp from the LB to ntp server. The ntp traffic did reply but both of my LB unable sync.

What Should i do?

Thanks.

1 Reply

  • THi's avatar
    THi
    Icon for Nimbostratus rankNimbostratus
    Jul 23, 2015

    Clock differences may be a cuplrit in this case. Certainly there may be other possibilities for the sync problem. Sometimes we have been able to sort out with reconfiguring the ha.

     

    As you can see from the ntpq -np command there is a failed ntp connection. The ntp daemon is still in initialization phase. What is interesting is that you can see ntp traffic to and from the BIG-IPs. See SOL10240: Verifying NTP peer server communications, sample of a failed ntp connection.

     

    We have seen something similar a couple of times (with two different customers) where the ntp traffic went via wrong interface and failed. The ntp server(s) were behind a routed connection from management interface. One of the BIG-IPs in the pair tried to reach ntp via data plane (TMM interface) and the other via management plane, even though the configs were identical in this respect. TMM ntp connection failed, and also resulted problems in config syncing.

     

    In our case the suspect seemed to be a bug (or feature) explained in SOL10239: Traffic originating from management processes may not use the intended management address or management routes. Adding a static route for the ntp servers to the management routing table corrected the problem in those cases.