Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

How is NTP reply routed when requesting router uses loopback as source address

The Cisco NTP Best Practices White Paper and DISA STIGs recommend setting the NTP source address to a loopback interface (e.g. "ntp source loopback0").

But this only seems to work if the requesting (NTP client) router is the default gateway for the NTP server. 

Specifically, the NTP server will attempt to reply to the requesting router's loopback-based source address (taken from the NTP request packet).  Since that address will always be non-local from the perspective of the NTP server, the NTP server will encapsulate the reply in a Layer 2 frame addressed to its default gateway.  If the gateway was the source of the original NTP request, that should work.  But in most other situations that gateway won't know how to reach a loopback-based address, and will discard the reply.

I have verified this in tests with routers running both 12.4 and 15.1 releases (and NTP debugging enabled).  When the NTP source is a loopback address, NTP replies never reach the requesting router.  With the default NTP source address (i.e. based on the exit interface) everything works fine.

Obviously, you could employ workarounds, such as static routes or injecting loopback addresses into your routing protocols.  But that seems uglier than leaving NTP source addresses at their defaults.

Why is this "best practice" so commonly advocated without mention of some significant caveats regarding routing?  Am I missing something? 

Thanks,

  Mark

Everyone's tags (3)
1 ACCEPTED SOLUTION

Accepted Solutions
Hall of Fame Super Silver

How is NTP reply routed when requesting router uses loopback as

Mark

In my perspective it makes a difference whether the relationship of NTP client and NTP server is through internal network connectivity (both client and server are within the Enterprise network)  or involves external connectivity (client is within the Enterprise network and server is in the Internet). If both client and server are within the Enterprise network then I would hope that the loopback interface address was  reachable via the Enterprise IGP. If the client in inside the Enterprise and the server is external then certainly this needs the NTP source to not be the (internal) loopback address.

HTH

Rick

4 REPLIES

How is NTP reply routed when requesting router uses loopback as

Mark,

The only reason for using the loopback as the NTP source is that it makes you independent of any physical interfaces that might be down.

Of course this means that the routing has be able to find its way between the IP addresses of the 2 hosts involved.

If the NTP server (or its default gateway) does not have a route to the loopback address of the NTP client, or if this route is a static route, via an interface that is down, then the router (default gateway) will discard the packet (destination unreachable).

If you have the connectivity setup correct from a routing perspective (check with ping) and it still does not work then you may have found an IOS bug.

Cheers,

Michel

New Member

How is NTP reply routed when requesting router uses loopback as

Michel:

Thanks for the response.  Actually, I understand what kind of routing workarounds could allow NTP to function in spite of this "best practice."  But I am mystified as to why a Cisco "NTP best practice" paper (http://www.cisco.com/en/US/tech/tk869/tk769/technologies_white_paper09186a0080117070.shtml) and various security policies would call for setting a loopback address as the NTP source when that practice will often cause more problems than it solves.

The stability of a loopback address is nice when that address is used to uniquely identify the platform for a routing protocol or syslog.  A loopback-based source address can also simplify ACL management, since that address won't change if an interface or link failure forces the router to send traffic from a different interface.  But I keep seeing security configuration guides/policies that call for also using a loopback address as the source for two-way protocols, such as FTP and NTP. That just doesn't make sense to me when you balance the routing implications against the limited security benefits (stable device identification, simplified ACL maintenance, and obfuscation of device addresses).

I was hoping to learn that some obscure command might allow me to control which NTP exchanges use the loopback-based source address.  For example, the loopback source address would work fine on outgoing NTP broadcasts (and probably in replies from NTP servers).  But I would prefer that NTP client requests use a source address based on the exit interface. That way replies can be routed back to the client without cluttering up routing tables with routes to loopback addresses.

So far, it looks like I'll need to chalk this up to poor coordination between the network security and network administration communities.

Thanks again,

  Mark

Hall of Fame Super Silver

How is NTP reply routed when requesting router uses loopback as

Mark

In my perspective it makes a difference whether the relationship of NTP client and NTP server is through internal network connectivity (both client and server are within the Enterprise network)  or involves external connectivity (client is within the Enterprise network and server is in the Internet). If both client and server are within the Enterprise network then I would hope that the loopback interface address was  reachable via the Enterprise IGP. If the client in inside the Enterprise and the server is external then certainly this needs the NTP source to not be the (internal) loopback address.

HTH

Rick

New Member

How is NTP reply routed when requesting router uses loopback as

Rick:

Thanks, I agree.

  Mark

2606
Views
0
Helpful
4
Replies