New managed Netgear switch won't sync to time server (stays on “local” not “SNTP”). What settings should I be using?

Question

This is nuts, I know. But I cannot get my new Netgear switch, to pick up the time from the time server used on the LAN. I've tried both CLI and GUI, I can't work out what it needs.

The LAN has a dedicated NTP server, which is working. I've tried every combination of settings to get the switch to pick up time from it, and followed Netgear guides as well as pages found online, but it sits at "local" and doesn't sync to the time server whatever I seem to do.

I'm not sure if that is because the local time server is NTP not SNTP, but all the examples show it syncing to a normal NTP pool, so it's probably fine. Ideally I would have thought it would autodetect the NTP settings and server from LAN DHCP params when it checks DHCP, but it isn't doing that either.

When I enter the settings, I can get a long "waiting" screen, but it always shows "local" even after waiting many minutes.

The setup I have would simply need a broadcast NTP request (the NTP server just has an IP, which could vary in future; there's no DNS on this LAN subnet). Surely it's not that complicated but I just can't find what it needs to make it work.

Rather than posting things that failed, I'd like to just ask what I have to do, to make it work.

This is the current config pages:

UPDATE 1

After @Ramhound's comment below (which was helpful, thank you!), I have come to the conclusion that the issue could be that the setting "routing mode" is incorrect. My basis for this is that although it's on the correct subnet/broadcast domain NTP broadcasts just aren't reaching the NTP server, and "ping" on the switch to the NTP server isn't getting a reply either.

(However it managed to send a DHCP request and reply without issue to the exact same server, no problem there? The switch and NTP/DHCP server are also definitely on the same subnet - I just rechecked - so broadcast should work?)

I think that might imply it doesn't know how to send packets to the server for NTP/PING purposes and so it isn't trying to send them (or is sending on the wrong ports), probably that would be a routing issue? But if so, why did DHCP work but NTP/PING not? I don't know. There's probably a good reason. I don't understand the "routing mode" setting enough to know if it should be enabled or disabled. Right now it's disabled, the switch default.

Answer 1

Following @Ramhound's very useful comment to the OP, I was able to find the solution.

There were two issues. First, the switch needs to be set from "switching mode" to "routing mode". It auto-reboots. After restarting, this immediately let PING (from the "troubleshooting" menu) work. That suggested that time sync would also begin to work.

The other issue is the GUI. I had to click a couple of times to get a screen which showed that the setting was clearly being set (Netgear's web GUI has a couple of minor issues in that area). But it still didn't seem to have done anything, because nothing changes until the next poll (anything up to 10 mins later, or 6 mins later by default). But as I browsed the system pages and SNTP config info, I suddenly noticed after a few minutes it was showing "success" and the correct date/time. I had to use unicast to get it to work. It might have worked with broadcast but I didn't retest with broadcast, I was just glad something worked!

So clearly it's 4 things:

• Enable "routing mode" not "switching mode".
• Set up SNTP and add some data properly. Try unicast and ensure there's an entry for at least one NTP server if needed. An ordinary NTP server will do, it doesn't have to be an SNTP server, and can be an IP not a domain.
• Go to the SNTP config and switch from "local" to "SNTP" and choose "unicast" or "broadcast" (start with unicast and a fixed IP/host, might be easier). Repeat doing it until the GUI looks like it's doing some serious config setting.
• Wait and occasionally watch the status pages to see if it shows "success" or the correct time.
• If not, ping the NTP server or other LAN devices in the same subnet, and do some packet capture, to check packets are actually getting to the NTP server, and suspect the routing if either of these don't work.

Answer 2

The assertion that routing mode needs to be set is not correct. Given that there's a step of "just sit and wait," it's understanding that you might have attributed success to the unnecessary step.

The entire issue is that the "clock source" configuration option will continue to show "Local" until the first NTP refresh. This is a bad UI design issue.

I've just tested to confirm, and the steps to enable NTP from a factory refresh (all options reset) on a GS724Tv4 are:

1. Log in
2. Ensure DNS has been configured
3. Add an NTP server - if you don't have one, consult http://support.ntp.org/bin/view/Servers/NTPPoolServers for a pool that's appropriate for your continent
4. Change "clock source" to NTP and ignore that the confirmation page shows "local" again
5. Optional: Reboot your device. This will make the next refresh come sooner, but it's not mandatory
6. Enjoy a cup of coffee or anything else that consumes 10 minutes, or just sit and occasionally click the "refresh" button on the ntp server settings page if you're anxious

After you see that a successful ntp server update has occurred, return to the "clock source" setting and you'll observe that it has switched back to "ntp" on its own.

Note: Newer Netgear models have addressed the UI issue, or default to automatic NTP configuration. Sadly they haven't addressed this in subsequent firmware updates for older models.