Recursive Lookup in static routing?

[rommel.bulan]

Do you recommend using of recursive lookup in a static routing? What is the disadvantage and advantages of it.

I have a static route and the next hop is not directly connected to it. The next hop IP address was learned via EIGRP and it is currently in load balance in the routing table. That static route is used to reach the tunnel destination of our GRE tunnel point to point.

May I know if this kind of implementation is ok?

Do you recommend using of recursive lookup in a static routing? What is the disadvantage and advantages of it.

Thank you

[Peter Paluch]

Hi,

In your case, the next hop address of the static route does not fall under a directly connected network but, as you indicated, it is resolved through an EIGRP-learned route.

Technically, this configuration works nicely, and contrary to many textbooks, it does not incur any routing performance penalty. The reason is that all recent IOS-based routers run Cisco Express Forwarding (CEF) by default to speed up the routing performance, and all recursion present in the routing table is resolved as the CEF contents are built. For static routes referring to next hop IP addresses, this specifically means that the route to the next hop is completely resolved to the egress interface and the nearest neighboring router in the CEF, and a single lookup is sufficient.

However, the situation of the next hop address being resolved by another remotely learned route is, in my opinion, slightly volatile. You have based the usability of this static route on the presence of the EIGRP-learned route. If the route disappears, so will the static route. Perhaps worse, however, there can be a situation in which the EIGRP-learned route disappears and some other, less specific, route in the routing table still matches the next hop IP. In that case, the static route will remain present in the routing table but the routing will follow the path towards the other network that matched the next hop IP. Depending on situation, this may be what you want, but it also may constitute suboptimal routing, traffic blackholing or even routing loops.

Please note that the default route is never used to resolve a static route's next hop IP address. However, any other more specific route can be used. Whether such situation can arise in your network and whether that can be harmful can be discussed only after knowing your network in detail.

If your network is stable and the current configuration works for you then I do not think you need to worry. Usually, though, static routes are configured with a next hop that resides on a directly connected network, so the reachability of the static route depends exclusively on the directly connected interface that is used to reach the next hop. Basing the static route on next hops located in remote (i.e. not directly connected) networks makes these static routes being dependent on the reachability of those remote networks first. That makes static routes more subjected to the overall network state. That is not necessarily a bad thing, though - BGP does that all the time.

The resume is: technically, you can do it if you are aware of these consequences and you are fine with them.

Best regards,

Peter

[rommel.bulan]

Thanks Peter.

You are saying that the implementation of our GRE tunnel is OK. So, it is better to have static route recursive lookup of next hop of the tunnel destination rather than next hop directly connected because the tunnel will depends to overall network state.

Can you give me your insights or documentations for best practices in implementing point to point GRE tunnels.

[Peter Paluch]

Hi,

You are saying that the implementation of our GRE tunnel is OK. So, it  is better to have static route recursive lookup of next hop of the  tunnel destination rather than next hop directly connected because the  tunnel will depends to overall network state.

It would be probably better if stopped talking in general terms, as that can get confusing for both of us. Can you post the exact configuration of the static route you are using, and the show ip route X.X.X.X output where X.X.X.X is the next hop IP address of this static route? Thank you!

Best regards,

Peter

[Richard Burts]

I would like to focus on this sentence from the original post

"The next hop IP address was learned via EIGRP and it is currently in load balance in the routing table."

If I am understanding correctly the static route next hop is remote and there are 2 paths toward that address. In this case it provides the static route with redundancy that you would not obtain with a more usual static route with a connected next hop. In that case I would think that there is positive value in the recursive lookup.

I would also like to comment on part of the discussion from Peter. He suggests that it might be problematic if the original EIGRP route is withdrawn and some other route (less desirable) is able to resolve the next hop address. He says that it might result in sub optimal routing. I would ask whether some viable route that provides continued connectivity (even if less optimal) is not better than losing connectivity.

HTH

Rick

[Peter Paluch]

Hi Rick,

Thank you for joining!

If I am understanding correctly the static route next hop is remote and  there are 2 paths toward that address. In this case it provides the  static route with redundancy that you would not obtain with a more usual  static route with a connected next hop.

This is absolutely true. Then again, if the two paths differ in the next hop, they can equivalently be expressed by configuring two static routes for the same destination, each of them pointing towards a different next hop.

He suggests that it might be problematic if the original EIGRP route is  withdrawn and some other route (less desirable) is able to resolve the  next hop address. He says that it might result in sub optimal routing. I  would ask whether some viable route that provides continued  connectivity (even if less optimal) is not better than losing  connectivity.

Obviously, answering this question would depend on whether the shorter-prefix match route still provides a viable path towards the true next hop. There is no guarantee that the route truly leads towards the next hop just because a shorter-prefix match route matches the next hop.

Think of default routing injected as 0.0.0.0/1 and 128.0.0.0/1 through different border routers to provide for load balancing. If the EIGRP-learned route (from somewhere inside your AS) to a particular next hop disappears from the routing table, one of these /1 routes will undoubtedly match the next hop from the static route - and lead to internet, outside your AS, where the next hop is not truly located.

So that is why I wrote: Depending on situation, this may be what you want, but it also may constitute suboptimal routing, traffic blackholing or even routing  loops.

Best regards,

Peter

[rommel.bulan]

Hi, Please see below:

R1

!

interface Tunnel1

ip address 10.125.7.5 255.255.255.252

tunnel source 10.7.246.254

tunnel destination 10.8.246.254

!

show ip int br

Interface                  IP-Address      OK? Method Status                Protocol

FastEthernet0/0            10.7.252.11     YES NVRAM  up                    up     

FastEthernet0/1            172.18.8.133    YES NVRAM  up                    up     

Loopback10                 10.7.246.254    YES manual up                    up        

Tunnel1                   10.125.7.5      YES manual up                    up     

show ip route of tunnel destination:

S        10.8.246.254/32 [1/0] via 10.7.252.9

R2

interface Tunnel1

ip address 10.125.7.6 255.255.255.252

tunnel source 10.8.246.254

tunnel destination 10.7.246.254

show ip int br

GigabitEthernet0/0         10.8.240.13     YES manual up                    up     

GigabitEthernet0/1         172.18.8.137    YES manual up                    up     

GigabitEthernet0/2         10.8.241.13     YES manual up                    up     

Loopback10                 10.8.246.254    YES manual up                    up      

Tunnel1                 10.125.7.6      YES manual up                    up     

show ip route of tunnel destination:

S        10.7.246.254/32 [1/0] via 10.8.246.19 --> 10.8.246.19 is not directly connected.

show ip route of 10.8.246.19

D        10.8.246.16/29 [90/3072] via 10.8.241.14, 3w1d, GigabitEthernet0/2

                        [90/3072] via 10.8.240.14, 3w1d, GigabitEthernet0/0

[Peter Paluch]

Hello,

Thank you for the outputs - they confirm my initial understanding.

My personal opinion on this: while this is not a typical way of configuring static routes, it is nevertheless perfectly legal and usable. If it works for you, there is no reason to redo it "just because it is not typically done this way".

One thing that is not related to the static route here: I see that both the Tunnel interface and the tunnel endpoints belong to the 10.0.0.0/8 network. Is there a routing protocol running over the Tunnel? If so, you must make absolutely sure that the endpoint addresses (tunnel source and tunnel destination) are never advertised in the routing protocol that runs over the tunnel. Otherwise, you would possibly create a scenario in which the tunnel endpoint is learned and thought to be reachable via the tunnel interface itself, leading to an infinite recursive routing entry in your routing table.

Best regards,

Peter

[quirosrolo]

Hi,

Do you have a Cisco reference for this please?: "Please note that the default route is never used to resolve a static route's next hop IP address."

Thank you

[Peter Paluch]

Hello,

Sadly, there does not seem to be any documentation regarding this. But I've checked the IOS source code, and I can safely state this - even correcting myself to a certain extent:

• If the default route is static itself and specified using the outgoing interface (in other words, it must be treated as a directly connected network), such as
  ip route 0.0.0.0 0.0.0.0 Serial2/0
  it will be used to recursively resolve the next hops of other routes.
• In all other cases, such as a default route configured using a next-hop IP address or learned from a dynamic routing protocol, it will not be used to resolve the next hops of other routes.

Best regards,
Peter

[rommel.bulan]

Thank you for your support.