Mario

I would suggest that you remove this line from your config:

ntp authenticate

since it does not appear that there is anything else in your config to support ntp authentication.

It might help us to find the problem if your would post the output of show ntp association detail.

Is there any kind of firewall or other security device between your router and the Internet that might be interferring with the NTP packets? Can you ping from your router to the ntp server?

HTH

Rick

Giuseppe,

The router is my border router. My ATM interface does have public address. You can't ping it because my carrier NATs me out to the Internet. I will try the link you sent and see if I can get anything from the debug. I just took off the ntp authenticate command.

Mario

Mario

I do not understand the statement that "You can't ping it because my carrier NATs me out to the Internet". If the carrier does something that interferes with ping, it seems reasonable that whatever they are doing will also impact the NTP packets. Does this suggest that you do not have IP connectivity from your border router to the public NTP servers?

HTH

Rick

We are in AT&T's VPN cloud so from site to site we are inside of a VPN cloud but when we go out into the internet we leave the VPN cloud and go through an internet router but all traffic is natted through this connection. How do I know it isn't the ntp server that isn't responding to pings. I am using a NIST and NASA server for the NTP and I can't ping either one. I don't think ping is the issue.

Here is the ntp associations output

address ref clock st when poll reach delay offset disp

~206.246.118.250 0.0.0.0 16 - 64 0 0.0 0.00 16000.

~198.123.30.132 0.0.0.0 16 - 64 0 0.0 0.00 16000.

* master (synced), # master (unsynced), + selected, - candidate, ~ configured

Mario

I am not sure that I fully understand how being in the AT&T VPN cloud impacts your connectivity. But it sounds more and more like this may be the problem with your NTP.

The NTP output that you posted is somewhat helpful. For both configured servers it indicates that the reference clock is 0.0.0.0 and that indicates that you have received no response from either NTP server. I think it looks like a connectivity issue.

HTH

Rick

Hello Mario, Rick

I agree with Rick.

Your router isn't directly connected to the public internet and your provider is doing NAT, and unfortunately you don't control this NAT device.

You should ask your provider to create a static NAT entry for the NTP source address so that you can export it to the internet to achieve syncronization with public server

Hope to help

Giuseppe

Giuseppe

I will check with my service provider first and check back into the forum when I have a definate answer. Also do you recommend any ntp servers in particular? Thanks.

Mario

Rick,

First let me say the NTP is working now. Funny thing, remember I told you that we are in a VPN cloud provided by AT&T so we use a 172.0.0.0 on all of our WAN interfaces from site to site. We use a 165.0.0.0 on all of our ethernet interfaces. Well for some reason when we used the 172.0.0.0 address as the source address none of the time servers we picked would respond to that address when we used the 165.0.0.0 address as the source address the time servers responded to that address. I don't know why the time servers won't respond to the 172.0.0.0 wan interface though.

Mario

Thank you for posting back to the thread and indicating that you have NTP running now. It makes the forum more useful when people can read a discussion and can know when something does work.

My best guess about why 172.0.0.0 addresses do not work for NTP while 165.0.0.0 addresses do work is that AT&T considers the 172.0.0.0 addresses as part of the WAN infrastructure for internal use and does not translate those addresses out to the Internet, while they consider the 165.0.0.0 to be user address space which does need to access the Internet and therefore does translate (or route) those addresses to the Internet.

HTH

Rick