如何判断静态路由不可达 接口down ？ 路由递归查找



【原文链接】:

http://blogbt.net/index.php/2013/11/recursive-lookup/

I know I haven’t posted in a while – there is a reason for that! I am currently organising and preparing a series of blogs on Multicast which will, hopefully, put this topic to bed – at least conceptually. In the meantime, I came across a scenario at work where, knowing the dynamics of static routes, actually, did help a lot.

This blog will answer the following questions:

1. What is a recursive lookup?
2. When is a recursive lookup performed?
3. What has a recursive lookup to do with static routes?
4. Why and When would a static route stay/disappear from the routing table?

Obviously, I will not match the work scenario exactly; the topology will however illustrate the concept, pretty well I think. So let’s get to work.

The topology:

Here we have 3x routers – R2 can reach 192.168.1.0 range via two paths: a static route pointing to 10.0.12.0 (R1) and via the EIGRP path (R3, R1)

NOTE: A recursive process comprises of several steps whereby each step, depends on the next – so the parent process  must  wait on the child process to finish. You could also have multiple levels of recursion.

Every time a router has to do a route lookup, a recursive lookup will be performed – unless the destination is directly connected. For instance, let’s look at the routing table on R2:

R2#sh ip route
Codes: C – connected, S – static, R – RIP, M – mobile, B – BGP
D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area
N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2
E1 – OSPF external type 1, E2 – OSPF external type 2
i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2
ia – IS-IS inter area, * – candidate default, U – per-user static route
o – ODR, P – periodic downloaded static route

Gateway of last resort is not set

10.0.0.0/31 is subnetted, 3 subnets
C 10.0.12.0 is directly connected, FastEthernet0/0
D 10.0.13.0 [90/30720] via 10.0.23.1, 00:48:24, FastEthernet0/1
C 10.0.23.0 is directly connected, FastEthernet0/1
S 192.168.1.0/24 [1/0] via 10.0.12.0
R2#

Based on the routing table above, when the router tries to forward a packet to destination 192.168.1.0, it looks in the routing table and finds it should go via 10.0.12.0 IP address, as a next hop. Then the recursion starts … it will try next to find out how to get to 10.0.12.0 – so it looks again in the routing table and finds out that 10.0.12.0 is a directly connected interface, Fa0/0.

NOTE: In reality, the router won’t use the routing table for forwarding! Using the same principle explained above, the router will build the CEF table first, based on the information available in the routing table. It will then use the CEF table for forwarding.

Now think of what happens when we bring the switch interface down (the one facing router R1) – strictly considering our topology, once you shut down the switch interface, R1′s interface will also go physically down. The R2′s interface will also go (protocol) down. Following up, when router R2 tries to route packet to network 192.168.1.0, it looks in the routing table – but now the static route is not there anymore! Why?

When the state of the interface changes, a process is triggered so the routes in the routing table are validated – this happens very fast! So eventually, the static route gets validated following (very generically) the following process:

1. A 1st lookup is done for the 192.168.1.0 network – the router then finds the next-hop

2. A 2nd lookup is then done for the next-hop of 10.0.12.0 – this is when the router finds the next-hop is actually directly attached

3. But wait – that interface is now down!

Now, here is a question for you? Is the static route going to be removed? If not, why not?

4. But there is another route to the next-hop – remember EIGRP is running, right?

5. So the router then installs a route to 10.0.12.0 – at this stage, the static route got its next-hop back! Even if, it’s not directly connected Next-Hop!

6. Router marks the static route as a healthy route – so the route stays in the routing table!

R2#sh ip route
Codes: C – connected, S – static, R – RIP, M – mobile, B – BGP
D – EIGRP, EX – EIGRP external, O – OSPF, IA – OSPF inter area
N1 – OSPF NSSA external type 1, N2 – OSPF NSSA external type 2
E1 – OSPF external type 1, E2 – OSPF external type 2
i – IS-IS, su – IS-IS summary, L1 – IS-IS level-1, L2 – IS-IS level-2
ia – IS-IS inter area, * – candidate default, U – per-user static route
o – ODR, P – periodic downloaded static route

Gateway of last resort is not set

10.0.0.0/31 is subnetted, 3 subnets
D 10.0.12.0 [90/33280] via 10.0.23.1, 00:02:33, FastEthernet0/1
D 10.0.13.0 [90/30720] via 10.0.23.1, 01:08:59, FastEthernet0/1
C 10.0.23.0 is directly connected, FastEthernet0/1
S 192.168.1.0/24 [1/0] via 10.0.12.0
R2#

So let’s now traceroute to 192.168.1.10 from R2:

R2#traceroute 192.168.1.10 probe 1

Type escape sequence to abort.
Tracing the route to 192.168.1.10

1 10.0.23.1 24 msec
2 10.0.13.1 36 msec
R2#

 

CONCLUSION: The bottom line is that a next-hop doesn’t need to be directly connected; the next-hop is just an IP address part of a specific network. Therefore, the router must be able to reach this network – either through a directly connected interface, or through a recursive lookup. Should the next-hop not be reachable, the route is declared invalid!

Next time someone tells you that a static route is removed when the interface goes down, be clever and say: well, actually, that is not the case! The route will only be removed should the next-hop not be reachable, regardless the interfaces are up or down!