cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
9002
Views
0
Helpful
10
Replies

Static Routes and recursive routing

pblume
Level 1
Level 1

I have a remote site with two Cisco routers. One router has an Internet connection with a VPN tunnel configured back to my hub site and the other router has a frame relay PVC back to my hub site. The remote site PCs are all set up with a default gateway of the router connected to the frame relay PVC.

I want to force some non-critical traffic over the VPN tunnel, so I configured a static route in the frame conencted router such as:

ip route 10.2.2.50 255.255.255.255 192.168.255.1

where

10.2.2.50 is the IP address of the server at the hub site for non-critical traffic

192.168.255.1 is a loopback address configured at the hub site that is only learned via the VPN tunnel and advertised to the frame relay router over the remote site LAN

Therefore, the static route in the frame relay router forces the non-critical traffic over to the VPN tunnel router. The VPN tunnel router than routes the traffic up to the hub site.

If the VPN tunnel fails, the loopback address goes away and the non-critical traffic is routed via the normal IP route table over the frame PVC to the hub site.

I now want to use my remote VPN tunnel router for a local Internet connection. In my remote frame relay router, I want to configure the following static route:

ip route 0.0.0.0 0.0.0.0 10.3.3.2

where

10.3.3.2 is the IP address of the VPN router LAN port.

Question:

1) Will this new static route for 0.0.0.0 screw up my failover for non-critical traffic to the frame PVC if the tunnel fails? In other words, will the first static route

(ip route 10.2.2.50 255.255.255.255 192.168.255.1) use the second static route

(ip route 0.0.0.0 0.0.0.0 10.3.3.2) (i.e., recursive routing) to make it believe that it can still use the VPN router to get to the 192.168.255.1 loopback address via the VPN router. Therefore, continuing to route non-critical traffic to the VPN router even though the VPN tunnel is down? Or will the first static route get deleted from the IP route table?

I have done a decent amount of research on recursive routing and its a little confusing. How many times can the IP route table be consulted before it finds a directly connected interface. For example, in my above question, when the VPN tunnel fails, will the IP route table of the frame relay router be consulted the first time to find the first static route

(ip route 10.2.2.50 255.255.255.255 192.168.255.1), then be consulted to find the second static route

(ip route 0.0.0.0 0.0.0.0 10.3.3.2), and then be consulted a third time to find that the 10.3.3.0 subnet is directly connected via the ethernet0 interface (thus incorrectly forwarding the non-critical traffic to the VPN router when the VPN tunnel is down)?

Or are recursive route lookups limited to 2 lookups? If this is the case, I would think that the addition of the second static route (ip route 0.0.0.0 0.0.0.0 10.3.3.2) would not effect my failover since it is configured with a next hop IP address as opposed to the ethernet0 interface.

Would the answer be any different if the default static route for Internet conenctivity was configured using the frame relay router LAN port instead of a next hop of the VPN router LAN port (ip route 0.0.0.0 0.0.0.0 ethernet0)?

Thanks

10 Replies 10

rlcarr
Level 1
Level 1

No the route for 2.50 via 192.168.255.1 will get pulled from the table.

You mention the frame router learns the route? OSPF, EIGRP??

So why can't he advertise it to the frame router??

I'm not a big fan of static so I would use an Inbound filter so that the 2.50 is the only route the VPN advertises. then use ospf cost to make his route(s) look better than the frame.

http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120limit/120s/120s24/routmap.htm

Happy Routing,

ron

CCNP, CCDA, CNE

The rule for static routes and recursion is: If the best route for the next hop also covers the entire address space of the static, the route won't be installed. In this case, the route to the next hop (0/0) will also cover the entire address space of the static route itself, so the recursion will fail, and the route won't be installed. You gave the right answer, I just wanted to give the reason. :-)

On the second part, it's easier to filter the routes at the receiving end (the frame router) using a route map, than it is to filter them at the transmitting end (the "hub" router, I suppose), if you're using OSPF or IS-IS. There are ways of filtering the LSA/P advertised, but the simpler way, in this situation, would be to put filtering on the frame (remote?) router to prevent the routes _other_ than the route to the loopback from being installed.

If you're using EIGRP or RIP, then you could filter it at either place.

Russ.W

Given the rule you mentioned, can you explain why recursive route lookups for static route next-hop addresses are done in classful mode? It seems to me (I could be missing something) that this rule would always prevent a default route from resolving a static route next-hop address, yet I've read that these recursive lookups are done in classful mode to accomplish this. Hence, I think I unconsciously drew the conclusion that the above rule didn't apply to default routes.

Perhaps the piece of this that I'm missing is when the next-hop resolving route points to an interface rather than a next-hop of its own, as my understanding is that the above rule doesn't apply in this case. Is the purpose of these recursive lookups being classful, then, to limit the effect that a default route pointing to only an interface can have on next-hop reachability?

Thanks! This makes sense with some testing results done by one of my peers. I just couldn't understand it without this explanation. I was going to try and re-test it so I could see the results for myself. Is there ANY place on the Cisco web page this recursion rule is documented?

Part of my initial confusion/concern started because of a tech paper on the Cisco Web page at the following URL:

http://www.cisco.com/en/US/customer/tech/tk365/tk80/technologies_tech_note09186a00800ef7b2.shtml

This paper basically says that default routes WILL cause static routes with numerical next hop addresses to stay in the IP route table. This just didn't make sense to me since static routes with a numerical next hop address = the far end WAN link (a typical configuration)would NEVER be deleted from a route table if a default route was present. Can you help explain the inaccurate test results/conclusions from this paper?

Thanks

I just tested their scenerio in the lab, and it doesn't look like it works the way it's written up in the doc. I'll have to go bug the documentation guy to get that pulled. I think it's just an older doc--there was a time when this worked the way it's described there. :-)

Russ.W

Is there any specific reason for having the rule where, "If the best route for the next hop also covers the entire address space of the static, the route won't be installed". I want to understand  the possilbe impact if this rule if not implemented.

vijay

tbaranski
Level 4
Level 4

My understanding is that recursive route lookups are done in classful mode for this exact reason -- to prevent a default route from causing all static route next-hop addresses to be resolvable.

However, classful route table lookups only ignore the default route when some portion of the associated major network is already in the routing table. So in your case, the answer to your question depends on whether or not there is at least one other route in the Frame Relay router's routing table that is part of the 192.168.255.0/24 network. If not, then it seems to me that the default route will be used, and failover will not occur.

If you're in this boat, the easiest resolution may be to pick an unused IP in that subnet and route it to null0 on the Frame router. I assume this would have the effect of ensuring that a portion of 192.168.255.0/24 is always present in the routing table, hence preventing the default route from ever being used to resolve 192.168.255.1. But there are probably better ways, one of which might be the combination of a routing protocol advertising the default route over the VPN tunnel, and a floating static default route on the Frame router (pointing out the FR interface) for failover.

Well, with this configuration:

ip classless

ip route 0.0.0.0 0.0.0.0 7.1.12.1

ip route 7.7.7.0 255.255.255.0 7.1.12.1

ip route 144.1.2.0 255.255.255.0 Null0

ip route 208.0.100.0 255.255.255.0 144.1.1.1

I get this:

2651D#sho ip route

....

Gateway of last resort is 7.1.12.1 to network 0.0.0.0

C 208.0.14.0/24 is directly connected, Serial0/3

7.0.0.0/24 is subnetted, 2 subnets

S 7.7.7.0 [1/0] via 7.1.12.1

C 7.1.12.0 is directly connected, FastEthernet0/1

C 208.0.10.0/24 is directly connected, Serial0/0

144.1.0.0/24 is subnetted, 1 subnets

S 144.1.2.0 is directly connected, Null0

C 208.0.6.0/24 is directly connected, FastEthernet0/0

C 208.0.19.0/24 is directly connected, Serial0/1

S* 0.0.0.0/0 [1/0] via 7.1.12.1

So, the existance of 144.1.2.0/24 doesn't impact whether or not 144.1.1.1 is found in looking up the next hop for 208.0.100.0.... I think this all applied when the routing table was "more classful," but most of that code has been cleared out, as far as I know. The lookup, based on the my view into the code someplace in 12.3T, is purely longest prefix match. What we do right now is:

if (nexthop == 0.0.0.0)

.just install it

find route to nexthop

.if connected

..just install it

.if not connected

..if route to nexthop covers static, don't install

..if route to nexthop doesn't cover static, recurse

I think that logic is right, anyway. So, there are special cases for routes to connected interfaces (we'll install them pretty much no matter what), and for routes set specifically to a next hop of 0.0.0.0, which we'll install pretty much no matter what.

Russ.W

Hmm. If I understand your example correctly, it appears to illustrate the "don't install a static route if the route to its next-hop covers its entire address space" rule. The next-hop to 208.0.100.0 -- 144.1.1.1 -- is resolved by the default route which covers everything, so the route to 208.0.100.0 isn't installed because its addition wouldn't change any forwarding behavior: the (final) next-hop and outbound interface are the same for both routes.

To test the "are recursive lookups classful?" question, I think the default route above would need to point to an interface (f0/1 in this case) rather than a next-hop. This, per my understanding, would prevent the aforementioned rule from coming into play, since the route to 208.0.100.0, despite being overlapped by the default, now has a next-hop of its own which will be used when traffic following this route is forwarded (because the default route doesn't have its own next-hop). This differentiates it from the default route from a forwarding standpoint: packets following the route to 208.0.100.0 are forwarded out f0/1 with a next-hop of 144.1.1.1, while each packet following the default route is forwarded out f0/1 with a next-hop of its destination address.

So, if the default route were changed to point to f0/1, it looks to me like the route to 208.0.100.0 would not be installed if recursive lookups are classful (because the presence of 144.1.2.0/24 prevents the default route from being used to resolve 144.1.1.1), but would be installed if recursive lookups are classless.

But in any case, this is mostly academic at this point and I know you have plenty of other things going on. That recursive lookups were/are classful made sense to me before I knew that "the rule" applied to default routes, but now I can't think of a good reason for classful lookups to be used other than to confuse people. ;-)

Ah, yes, that could be true... I would have to rework the lab configs to see. I wonder if ip classless being configured would have anything to do with it? It might, since that mostly impacts the way that lookups are done in the routing table.

:-)

Russ.W

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: