I have several NetVanta 3305 routers at remote facilities that I am trying to setup with NTP out their WAN interfaces to the Internet drain at the main facility. They are running: ADTRAN, Inc. OS version 18.02.01.00. In order to keep the routing table on the firewall small and not have to put all of the small routing subnet links into the routing table and into the outbound firewall rules, I put in the command ntp source ethernet 0/1 so that the source IP on the NTP packets should be the LAN interface at the remote facility which are already allowed out the Internet.
RUR-RT-StateLine#sh run | i ntp
no ip sntp server
ntp source ethernet 0/1
ntp server 0.us.pool.ntp.org
ntp server 1.us.pool.ntp.org
RUR-RT-StateLine#sh ip inter brief
Interface IP Address Status Protocol
eth 0/1 10.2.0.1 UP UP
eth 0/2 10.0.5.2 UP UP
eth 0/1 = LAN
eth 0/2 = WAN via MetroEthernet solution
When I configure NTP, I get the following message: 2013.08.28 15:52:59 NTP Frequency format error in .ntp.drift.
A packet capture on the firewall shows:
351.164486 port1 in 10.0.5.2.123 -> 69.167.160.102.123: udp 48
370.346095 port1 in 10.0.5.2.123 -> 204.2.134.162.123: udp 48
417.622237 port1 in 10.0.5.2.123 -> 69.167.160.102.123: udp 48
433.715793 port1 in 10.0.5.2.123 -> 204.2.134.162.123: udp 48
Any idea why the ntp source interface command is not working?
- Quazar66
Thank you for asking this question in the support community. I believe this issue was included in the release notes for 18.2.03:
At the time of this post, ADTRAN is recommending firmware version R10.5.3. I hope that makes sense, but let me know if you have any additional questions or information.
Levi
You may not have a route to the destination sourced from eth 0/1.
The packet may contain the eth 0/1 IP internally but its source is going to be from the WAN-facing interface as that's the route out to the Internet.
If you show IP route, on which subnet is the 0.0.0.0/0 default route?
You might have to install static routes or use local policy routing if indeed your NTP server is reachable out the other interface.
Does ip route 69.167.160.102 255.255.255.255 10.2.0.xxx <- next hop out eth 0/1 make it work?
Local policy routing will look like:
ip local policy route-map local-ntp-map
route-map local-ntp-map permit 10
match ip address local-ntp-list
set ip next-hop 10.2.0.xxx ! <- Next hop on eth 0/1 subnet
set interface eth 0/1
route-map local-ntp-map permit 20
ip access-list extended local-ntp-list
permit udp host 10.2.0.1 any eq ntp
Alternatively, configure one or more of your edge devices as a local NTP server synced to your outside stratum 1 or 2 clock and sync all of your inside devices to it.
This keeps all of your network synchronized locally and is friendlier to the public time servers.
Jayh,
Since all the client behind the eth 0/1 interface can get to the internet, routing is not an issue. According to the AOS command reference:
ip sntp source-interface <interface>
Use the ip sntp source-interface command to specify a source interface for Simple Network Time
Protocol (SNTP) traffic originated by the unit. The IP address of the specified interface will be used to
source all SNTP traffic.
As can be clearly seen, the traffic arrives at the firewall with a source IP of the eth 0/2 interface.
Since the hardware is a mix of Cisco/Adtran/HP, I'm not sure that I can use one of them to sync all the others, but thanks for the suggestion...
quazar66 wrote:
Jayh,
Since all the client behind the eth 0/1 interface can get to the internet, routing is not an issue.
The question is how does it get to the Internet. If the default route to the Internet is via eth 0/2 then that's the route it will take unless you take steps to manipulate it. What does a traceroute from the box to the IP of the public time server look like?
quazar66 wrote:
Since the hardware is a mix of Cisco/Adtran/HP, I'm not sure that I can use one of them to sync all the others, but thanks for the suggestion...
For certain Cisco and Adtran can do it as well as any Linux box. NTP is standard-based and not vendor proprietary.
Adtran syntax:
ntp master <stratum> where <stratum> is a number from 1 through 15. Lower numbers are more trusted so make it something like 4 and then sync that device to a stratum 1 or 2 external clock. If you don't specify a stratum and the box is synchronized to an external time server then it should increment the stratum of its lowest-numbered peer by one.
It is considered inconsiderate to have a large number of devices on the same network syncing against a public time server. Having a local server for your network also ensures that if the external time server becomes unreachable the local devices will agree with each other even if the absolute time drifts. You could have two devices sync to the authoritative clocks and then treat both of them as local masters.
show ntp asso will display synchronization status to your external sources as well as their strata.
quazar66 wrote:
When I configure NTP, I get the following message: 2013.08.28 15:52:59 NTP Frequency format error in .ntp.drift.
Actually, if this is the only error it should correct itself once NTP has been running for a while. See Unix fast food for thought: February 2005
Does show ntp asso indicate that the box is synchronized?
The default route is out eth 0/2. The command "ntp source <interface> should use the IP on the interface as the source IP in the packet. From the Command reference:
ntp source <interface>
Use the ntp source command to specify the source interface for the Network Time Protocol (NTP) packets.
While NTP is a standard, not all vendors assume that a device can act as both a NTP client AND NTP server. HP switches work just fine as an NTP client, but do not reply to NTP requests from other devices. Since this client has HP switches, Adtran routers (4) and Windows servers, I will have to add the routes and subnets to the firewall for each of the WAN links, or try and setup one of the windows servers as an NTP server.
Just wish that the "ntp source <interface>" command worked as documented
It could be that the code looks at a locally-sourced packet leaving eth 0/2 and logically assigns that source IP to it. Interface eth 0/1 isn't the exit path to the destination.
If you configure a loopback address on the box, does the ntp source-interface command work as expected specifying the loopback?
Thank you for asking this question in the support community. I believe this issue was included in the release notes for 18.2.03:
At the time of this post, ADTRAN is recommending firmware version R10.5.3. I hope that makes sense, but let me know if you have any additional questions or information.
Levi
Levi,
Thanks for the info. I missed that in the release notes. I will try the upgrade.