NV3200 gen2 - alternate SNTP source *IP*?

[Anonymous]

Hello Adtran Fans...

I have an NV3200 gen2, with a PPP connection riding on the T1 for WAN, and a small business network on the LAN side.

It is currently running a somewhat older release (15.x) but I don't see anything in the final release for Gen2 (18.x) that will help my problem.

I'm trying to sync time on the NV3200 via SNTP (to us.pool.ntp.org), and it's failing.  "debug sntp client" shows nothing other than the attempts to hit different IP addresses.

I think the problem is the way the (WAN) PPP interface is configured.  The ISP assigns a private /30 on that interface (10.20.30.0/30 as an example), and then routes a secondary /30 to me to use for public traffic.  I have 10.20.30.2 configured as the primary interface on ppp 1, and the public IP is setup as a secondary IP  (e.g. "100.1.2.3 255.255.255.252 secondary").  Default route points to 10.20.30.1 on the ISP's side.

I can use the "ip sntp source-interface" directive to force the 3200 to use ppp 1 for the source of packets, but being a private IP address, I think it is never making it out of my ISP's network.  DNS doesn't seem to be affected because I'm using the ISP's DNS servers, which apparently can make their way back to this IP.  Is there any way to specify which IP on an interface to use after the sntp source-interface directive?

Can anyone give me a suggestion to fix this?

I already tried using the LAN interface (eth 0/1) as the source interface, but apparently the NV3200 doesn't NAT its own traffic (there is a rule in place to src-NAT LAN traffic to the public IP on the WAN side, but it doesn't seem to apply to traffic sourced from the router itself).

The only other thing I can think of would be to move the public IP to a loopback address and then use that as my source-interface, but I believe I may lose access to the NV when I do that, and I'd rather avoid a site visit.  If I can find a way to alter the config that I know 100% won't lock me out, then I could upload that and reboot it after hours... I just don't want to make a drive because of lost access.

[jayh · Accepted solution]

Your ISP is being lame.  By not giving you a public IP on the WAN side you can't remotely manage your router if the LAN fails, you can't terminate VPNs or tunnels on the device, traceroutes will break, and VoIP may get ugly if you are using the 3200 as an ALG.  IPv4 is getting scarce but /31 masks for point-to-point links have been around for well over a decade.  http://tools.ietf.org/html/rfc3021

Does anything break if you assign the public IP as primary on the link and the RFC1918 as secondary? This might be an option.

Does the LAN side have a public IP or is it also RFC1918?  If so you might be able to do some local policy routing on the device but I haven't tested this.

There are some differences between NTP and SNTP, you might try NTP. 

I'd try:

• Ask your ISP to give you a real IP on the WAN side.
• Swap primary and secondary addresses on the WAN link.
• Ask your ISP if they have a time server that will respond to queries from your WAN IP.
• Create an NTP client/server instance on your inside LAN, query a public server from it, and sync the Netvanta to your inside host.  You'll be one more stratum removed but likely not an issue.

You'll likely need to be local for the first two.

[Anonymous]

The ISP does give us a public IP, it's just not "associated" to the PPP interface.  This is a fairly old circuit and their more modern lines do use a public IP for WAN and then a second block for LAN.

Since the Adtrans are powerful enough for our needs at remote sites (basic NAT firewall), I don't use a second device behind them.  It terminates the T1 and also acts as router/firewall, so I don't really need a "LAN block" like most ISP connections use.

The LAN side is RFC1918.

I have not tried making the public IP primary and the private IP secondary.  I'm not sure if that will work since there is a PPP session involved here.  If it does, I suspect it will solve the problem since the router should then source packets from the public IP, it being the "primary" on the connection. 

However, I'm not sure of any failsafe way of testing this. Since I have to make more than one change simultaneously (swap the two IPs), the only thing I can think to do is upload a config.  Uploading a config to the unit requires a reboot to kick-in, and that means a write mem is required, which means I can't use the standard "reload in 10 / make change without saving" method to test this.

There is already a standard policy in place that is src-NAT'ing any traffic outbound from the LAN side to the public IP.  Apparently (?) this policy doesn't affect traffic originating from the router though, even if I tell it to use the LAN interface as the source of the SNTP traffic (which should originate from the LAN IP at that point, and I was hoping it would then get NAT'ed and would behave correctly).  Will policy-routing affect traffic originated by the router itself? I know that behavior here varies from vendor to vendor...

Eventually this site is going to get moved to a MPLS T1 and will change to HDLC and get a different WAN IP (ironically, our ISP actually uses public IPs in their private MPLS links, go figure).  Once that happens I can just point at my internal time servers and it's no longer an issue anyway... I was just curious to see if there was anything I could do (easily) in the meantime.

[jayh]

zprime wrote:

I have not tried making the public IP primary and the private IP secondary.  I'm not sure if that will work since there is a PPP session involved here.  If it does, I suspect it will solve the problem since the router should then source packets from the public IP, it being the "primary" on the connection.

This should work OK.  I would think that IPCP should be fine with it.  You might need peer default ip address w.x.y.z on the ppp interface config specifying the other side's primary but I doubt it.

However, I'm not sure of any failsafe way of testing this. Since I have to make more than one change simultaneously (swap the two IPs), the only thing I can think to do is upload a config.  Uploading a config to the unit requires a reboot to kick-in, and that means a write mem is required, which means I can't use the standard "reload in 10 / make change without saving" method to test this.

How do you access it remotely now?  Through the secondary IP on the WAN side?  If so, you could do your "reload in 10" then change the (primary) IP address to the public one.  If you're still in or can get back in, then add the former primary as secondary.  If not, then wait for the reload. It's certainly safest to do things on-site or with some kind of a backdoor.  Configuring the interface by which you're connected is always iffy.

There is already a standard policy in place that is src-NAT'ing any traffic outbound from the LAN side to the public IP.  Apparently (?) this policy doesn't affect traffic originating from the router though, even if I tell it to use the LAN interface as the source of the SNTP traffic (which should originate from the LAN IP at that point, and I was hoping it would then get NAT'ed and would behave correctly).  Will policy-routing affect traffic originated by the router itself? I know that behavior here varies from vendor to vendor...

"ip local policy" for manipulating traffic from the box itself.