This post is more than 5 years old
14 Posts
0
1716
August 28th, 2014 15:00
NS120: problems with NTP
Like the title says. As a very first step I tried to Stop, delete and re-add the NTP servers however I always see "Running, Disconnected". To be honest it would be kind of strange to see "Running, Connected" since NTP is over UDP but that being said, "Running, Disconnected" doesn't seem right either. I've already spoken with my network team and they confirmed UDP port 123 is open all the way between the storage and the NTP server. Furthermore, I have another server on the same subnet which can successfully reach the NTP server and get corrections. Stats look like this:
[nasadmin@NS120-1-CS1 ~]$ server_date ALL timesvc stats ntp
server_2 :
Time synchronization statistics since start:
hits= 0, misses= 0, first poll hit= 0, miss= 41
Last offset: 0 secs, 0 usecs
Current State: Running, disconnected, interval= 60
Time sync hosts:
XX.XX.XX.XX,
server_3 :
Time synchronization statistics since start:
hits= 0, misses= 0, first poll hit= 0, miss= 0
Last offset: 0 secs, 0 usecs
Current State: Running, disconnected, interval= 60
Time sync hosts:
XX,XX,XX,XX
I ran
tcpdump -i eth3 -nnv udp and port 123
in a screen'd session and went through the stop/delete/start routine again and I didn't see any outbound UDP traffic. TIA.
phatrik
14 Posts
0
August 29th, 2014 08:00
Problem solved, I was missing a route to the network where the NTP server resides. It looks like there's no default routes configured on the data movers (new to storage, still learning!) and as a result the datamover couldn't reach the NTP server however the CS could without any problems.
"server_route server_2 -list" allowed me to see the default route list and I was able to add a default route with "server_route server_2 -add ..."
phatrik
14 Posts
0
August 28th, 2014 17:00
Note: I was thinking about this problem and realized there's a flaw with what I said above, regarding packet capture with tcpdump. I know datamovers are their own network device so to speak, and as a result I wouldn't see any traffic doing a packet capture from the control station.
Nonetheless, I still look forward to any recommendations. I did follow all the steps under "Recommended action" in the alert e-mail that was sent out but no luck.
phatrik
14 Posts
0
August 28th, 2014 21:00
Update 2: While this doesn't do anything to find a root cause for the previous problem, in the mean time I've silenced the alerts by configuring the datamovers to sync up with the control station.
Someone suggested to me perhaps it's because the datamoers can't ping the NTP server (Even though 123/UDP is open all the way though) that the datamover had a status of "Running,disconnected". Somehow I doubt this, I know for a fact my network team has a SOP of blocking ICMP on firewalls unless the client specifically asks for an exception but this guy who made the suggestion knows way (way!) more about storage than I do (although he usually works with block-based, not Celerras) so I'm inclined to investigate his suggestion. Thoughts?
Rainer_EMC
4 Operator
•
8.6K Posts
0
August 29th, 2014 05:00
My guess – something necessary is block
I usually don’t trust the network team until I have seen myself
You can trouble shoot with a regular NTP client
Or take a packet capture from the ports the data mover uses