Forum Discussion
Sathish_Kumar_S
Nimbostratus
NimbostratusNTP Sync problem after BIG IP LTM system restarted
Hi,
We have upgraded our LTM system to 11.5 in Feb2015 and restarted the system. After that we didnt notice NTP sync got stuck, during our recent preventive maintenance check for "Leap Second" n...
You said, Seems like after restart it uses other VLAN (say my internal LAN) rather than mgmt (eth0). In our shop we have always used a management route for NTP, if not it will use the TMM default gateway your ingress/egress interface which may or may have port lockdown enabled.
Sathish_Kumar_SNimbostratus
NimbostratusSeems like after restart it uses other VLAN (say my internal LAN) rather than mgmt (eth0).
[root@slb101:Active:In Sync] log netstat -rn | tail -12
0.0.0.0 10.32.22.174 0.0.0.0 UG 0 0 0 internal 0.0.0.0 172.20.129.174 0.0.0.0 UG 0 0 0 eth0
172.20.129.160 0.0.0.0 255.255.255.240 U 0 0 0 eth0 172.20.129.160 0.0.0.0 255.255.255.240 U 0 0 0 eth0 [root@slb101:Active:In Sync] log
As you can see, after reboot the system is trying to reach NTP server with Gw as "10.32.22.172" but it suppose to catch 172.20.129.174. So we have temporarily added a static route to fix as of now.
eg: route add -net 172.16.2.237 netmask 255.255.255.255 gw 172.20.129.174 route add -net 172.16.3.238 netmask 255.255.255.255 gw 172.20.129.174
And now it is synced properly with NTP server.
[root@slb101:Active:In Sync] log ntpq -p
remote refid st t when poll reach delay offset jitter
*172.16.2.237 0.0.0.0 1 u 51 64 377 2.887 6.614 2.086 +172.16.3.238 0.0.0.0 1 u 39 64 377 10.444 5.905 2.102 [root@slb101:Active:In Sync] log
But still, i know the system was very well working without these static route initially. Dont know why it took different GW after reboot.
Anyways issue got fixed.
Thanks Sathish