EIGRP STUB challenge
I would like to invite all my readers to participate to this EIGRP challenge which highlight the EIGRP STUB feature. As you may already know EIGRP use the query/reply process to find an alternate path for a route that it has lost if no feasible successor are present in the topology table. This process can slow down EIGRP convergence. To improve this behavior which is inherent to EIGRP (distance vector protocol, only knows routes being advertised by neighbors, unlike OSPF which has a full overview over the topology) there are 2 solutions. The goal of these 2 solutions is to reduce the query domain.
- The first solution is to use summarization. When a router lose a route it sends a query to all its connected neighbors to ask for an alternate path. If one of the neighbor has a summary route containing the more specific prefix lost by the neighbor, the query process will stop and the neighbor will send a reply back to the querier router telling him that it has no route for this prefix. The query will not go further. If summarization was not configured the query will have propagated through the network until it eventually reach a last hop router.
- The second solution is to use the EIGRP STUB feature. When a router is configured as a EIGRP STUB it will annonce itself as so to its connected neighbors. Then these neighbors will know that he is the last hop router and hence will not send query to him.
In this challenge I would use the EIGRP STUB feature to demonstrate what could be the consequence of using this feature in the wrong place in the network. Please consider the following topology:
In this example we will test the reachability to the loopback of R5 (10.10.10.10) from R1. R2 which is the HUB of the frame relay network is configured as an EIGRP STUB with a Leak map advertising all prefixes. Design-wise it does not make sense to configure R2 as a STUB but in this case it is for the purpose of testing and highlighting the EIGRP STUB feature.
All the router in the topology are configured with the following K values under the routing process: “metric weights 0 0 0 1 0 0“. By default EIGRP uses bandwidth and delay to calculate its composite metric but in this example for simplicity we will only use K3 which means that the routers will only use the delay to calculate the metric. The result metric will therefore be: 10 s of microseconds scaled by 256. X tens of microseconds equals Y microseconds divided by 10. So 5000 microseconds equals 500 tens of seconds. The delay under network interface is expressed in microseconds.
So if we look at R1 routing table first here is the output:
Now let´s see how the EIGRP topology looks like on R2 for 10.10.10.0/24:
As we can see from this output R2 has 1 successor and 1 feasible successor for 10.10.10.0/24 . The successor is R4 while the feasible successor is R3. R3 is elected feasible successor because its advertised distance (153600) to reach 10.10.10.0/24 network is less than the feasible distance of the successor (642560) to reach 10.10.10.0/24 network. The advertised distance is the metric reported by the neighbor to reach this network. So basically R2 is sure that no loop will occur when choosing this alternate path. Actually the delay of the R4 LAN interface has been changed to be lower than R3 LAN interface so R4 will result as the preferred path to reach 10.10.10.0/24.
How to calculate the metric:
For example let´s take the case of R3. If we do a show interface loopback10 on R5 it shows 5000 microseconds delay. Now if we do the same on the interface of R3 connecting to 184.108.40.206/24 network it shows 1000 microseconds. So the feasible distance (that is to say the total distance) to reach 10.10.10.0/24 from R3 perspective will be: (500+100)*256=153600. Let´s see the show topology output of R3 for 10.10.10.0/24:
As you can see from the output the second entry in the topology table to reach 10.10.10.0/24 is via 220.127.116.11 which is R2. This entry will not be considered a feasible successor because the advertised distance or reported distance to reach 10.10.10.0 /24 from R2 perspective is 642560 which is higher than the feasible distance of the current successor(153600) R5. That means that R3 will not use this alternate path if the path to R5 is lost and therefore will send query to all its neighbors. The advertised distance reported by R2 to reach 10.10.10.0/24 tells R3 that R2 is further away from R5 so choosing this alternate path could potentially create a loop.
Actually you may wonder why the path through R2 is present in the topology table of R3. That is because the Frame Relay interface of R2 has split-horizon disabled so when R2 receives an update for 10.10.10.0/24 from R3 it sends this update back to R3. Due to the feasible condition of EIGRP, R3 will never use this path to route traffic to 10.10.10.0/24.
So we know that to reach 10.10.10.0/24 R2 will use R4 as the primary path and if R2 lose the path to R4 it will use R3 as the secondary path without sending any queries to its neighbors because R3 is considered a feasible successor.
So let´s try to traceroute from R1 to 10.10.10.10 to confirm that:
So the traffic to 10.10.10.10 is taking the correct path.
Now here comes the challenge;-) What will happen when the LAN interface of R4 is shutdown as we are pinging 10.10.10.10 from R1?
Post your answers. I will write the solution later.