320 NTP issues

Having an issue with the sm's on my 320 network updating the time from the NTP server. I have tried several servers both public and private but can not seem to make the sm's update the time. This causes the clients to have connection issues. When I lof into the sm and update the time the issues go away for a week or two.

Any ideas????????

I'm assuming 8.1.4 firmware and that the units have a workable route to the internet.  On our network I deployed a stratum-1 NTP server (RaspberryPi+GPS) and actively discourage NTP traffic past the border, and have had zero problems since then.

Do you have CMMs in the network?  You can point CPEs at the CMMs for NTP as well. (IF they share a subnet or can otherwise route to each other)

j

6.5.1 firmware on all units. We do not use NAT or layer3 so we saw no need to go past 6.5.1.

All cpe's use private addresses and are not on the same subnet as the cmm4. Yes we are using the cmm4, three of them because we have three towers.

I can put the cmm4's on the same IP group and subnet as the cpe's if you think that will solve the problem.

Thanks for the help.

Well, I can't say whether it will solve the problem or not. We've been using 8.1.4 since a month or two after its release, so a couple years I guess.  But I don't have any reason to think 8.1.4 v 6.1.9.22 matters in this.

On our network we were seeing what may have been the same thing - one of the field techs swore that every time he got a service call he checked the radio first, and if the clock was wrong that fixing it resolved the customer's troubles.

I don't know the official word, but I suspect the CPE wasn't happy with our original local timeserver: being stratum2-stratum3 (depending on upstream sources) may have made it 'unreliable' enough that the CPE didn't trust it some times.  

Since deploying the RPi+GPS solution last year (which is NTP stratum1 - the 'most trusted' level for an NTP server - since its time comes directly from the multiple-satellite-synced GPS chip which is treated as a stratum0 Reference Clock) and pointing every piece of equipment on our network (radios, routers, SCADA, workstations, and handed out with DHCP) we don't see the same problems.

Now, because it derives its timing straight from GPS hardware, (and offers NTP service) a CMM will also be a stratum1 server.  So if my reasoning above holds any water (uncertain but seems reasonable to me) then pointing all the CPEs at their respective CMMs would have the same outcome. (and being 'closer', more reliable than routing to [or beyond] the edge of the network)

j

No issues here either (well, with NTP anyway).

We are on 8.1.4 running Layer 2 mode with PPPoE run by customer routers. NTP is sourced in-house by simple ntpd servers that suck down from Stratum 1 and 2 public servers and provide local service.

I'd strongly consider an upgrade.

any issues with 8.1 other than the NTP?

Not sure what you mean - we don't have any issues with 8.1.4 that aren't interference-related.

Sorry, that is what I ment. The only issues we are seeing with 6.5.1 is the NTP. What firmware are you using on the AP?

What interference issues are you seeing? Are there other providers in your area using 365??

Thanks for the help.

Haha sorry it's been so long since I did PMP320 software work that I forgot the AP has a different load! 2.3 is what we're running.

Yes there are other operators here running in the 3.65 GHz band. One of them we can sort of cooperate with, the other runs 3.5 GHz gear that defaults to somewhere in the 3.65 band when first powered on... Whenever we've had interference problems (or other weird RF issues) every version of software has always been the same.