Cisco 7206VXR Router NTP - Cannot Sync Time From External Internet Time Sources

[Richard H. Shores]

Hello!

I have a Cisco 7206VXR router with a NPE-400 (512mb RAM) and I/O-2FE/E. I am trying to get the router to sync NTP time from external stratum 1 servers on the Internet. These are known good time servers according to the NIST.

I am using IOS 15.0M10 Advanced Enterprise Services. Interface fa0/0 is pointing to the Internet. I am using IOS Firewall and I have access to the NTP servers in my access list for traffic to return to the router from the Internet on fa0/0:

.....

access-list 101 remark Allow access to time servers

access-list 101 permit udp host 64.250.177.145 any eq ntp

access-list 101 permit udp host 98.175.203.200 any eq ntp

access-list 101 permit udp host 207.223.123.18 any eq ntp

.....

I have the source servers setup as follows:

.....

ntp server 64.250.177.145 source FastEthernet0/0

ntp server 207.223.123.18 source FastEthernet0/0

ntp server 98.175.203.200 source FastEthernet0/0

.....

I am using NAT on the router as well and there is a NAT trans between the router interface fa0/0 IP address and checking the hits on the access list, and running debug on NTP, NTP requests and responses, there are no issues with the router reaching the external NTP servers.

However, the router never syncs or if it does sync, it takes hours to sync, then after it syncs, it will randomly lose sync after a time and never resync. I have a Catalyst 3560G that syncs with the above time servers within minutes and never loses sync.

I am at a loss why the router will not sync. The only thing I can think of is the I/O controller may be bad.

Any advice would be greatly appreciated.

Richard H. Shores

[Richard Burts]

Richard

One thing I notice is that in your access list that you are specifying the IP address of the source and the port number of the destination. A lot of the time this will work fine because a lot of the time both the source host and the destination server are both using UDP 123 as the port number. But I have seen instances where a source host will use some other port number as the source port which results in a destination port on the incoming packet that is not UDP 123. I wonder if the behavior would be any different if you re-write your access list and specify ntp as the source port rather than the destination port.

Beyond questions of the access list there may be some possibility of a hardware issue. I have also seen a couple of issues where my customer was having issues with stability of sync with NTP servers that was resolved when they changed to a different version of IOS. It might be worth trying a different version of IOS and see if the behavior changes.

HTH

Rick

[Richard H. Shores]

Hi Rick!

Thanks for your valuable input! I changed the access-list as you suggested and the problem still exists. I also changed IOS trains (15.1M6 and 15.2M4) as you suggested and that did not fix the problem. I performed a debug on NTP and the router is sending and receiving NTP messages, so the access list is working as it should.

I am going to swap out the I/O controller to see if that fixes the problem.

Many thanks,

Richard S.

[masmith0324]

have you tried dropping the ACL and see if ntp syncs?

Sent from Cisco Technical Support iPad App

[Richard Burts]

Richard

Thank you for trying my suggestions. I am sorry that they did not produce a better result. This situation does remind me of an issue that I encountered with one of my customers. So I have a couple more suggestions. Would you post the output of show ntp association detail? In it look for the values in dispersion. The issue that I encountered we found that dispersion calculated for the particular NTP server we were using was high enough to cause problems. We never did determine what was causing the high dispersion, but we did find that if we used a different NTP server that it worked just fine. So my other suggestion would be to try a different NTP server (or 2 or 3) and see if you get better results with a different server.

HTH

Rick

[Richard H. Shores]

Hello Rick!

I tried your suggestion to change the NTP servers. I was able to sync, but the router failed to resync after about an hour but longer than before.

But I found a solution...finally! I I decided to try using a loopback interface instead of using the interface facing the Internet. Voila...it worked! I am now getting solid sync for several hours. Here is the changes I made:

Original

ntp server 64.250.177.145 source FastEthernet0/0

ntp server 207.223.123.18 source FastEthernet0/0

ntp server 98.175.203.200 source FastEthernet0/0

Changed to:

ntp source Loopback0

ntp update-calendar

ntp server 129.6.15.30

ntp server 64.236.96.53

ntp server 12.10.191.251

If you will reply to this message and include the text here, I can close this out with the correct answer so that others that may run into this will not have to wreck their brain as I did to find a solution.

Thanks for all of your input and suggestions.

Best regards,

Richard H.

[Richard Burts · Accepted solution]

Richard

I am delighted that you found a solution and glad that my suggestions sort of pointed in the direction even if they did not provide the solution.

Thank you for posting back to let us know that you have a solution. This has been an interesting discussion and a very subtle problem. I hope that other readers of the forum will benefit from this.

HTH

Rick

[Richard H. Shores]

Dropping the ACL does not work. Thanks for your input!

Richard S.

[jawad-mukhtar]

Have you added your fa 0/0 its in inbound or outbout direction

Jawad

[Richard H. Shores]

Dear Jawad:

Yes, the access list applied to the correct interface. Thanks for your input!

Richard S.