EIGRP really hates the querying process so it always preferred to have a backup route in case the link to a destination is unreachable. And, that backup route is the feasible successor. A feasible successor is a backup path used in the event the successor route disappears. It can be seen in the EIGRP topology table and because of this, the router doesn’t need to recalculate the metric. It automatically chooses the feasible successor when successor route fails.

Now that you know the feasible successor, automatically you know what the successor is. The successor is the best route to the destination. Unlike feasible successor that can only be seen in the topology table, it is seen in the routing table. Of course, the routing table has the best routes.

So what is reported distance? Is it the same with advertised distance? Actually, they are just the same. Reported distance / advertised distance is the cost from the next hop router to the destination.

Once you know the reported distance, you’ll find it easy to know the feasible distance (FD). It is the route with the lowest metric in each network. It is the total cost from the local router to the destination.

Since the idea of the successor, feasible distance, reported distance, and the feasible successor is clear to you, let me introduce the feasibility condition. Not all successors have a feasible successor. This is because of the feasibility condition.

Here is the formula:

FC = AD of FS < FD of S

The feasible successor route will not be entered into the topology table if its AD is greater than the FD of the successor.

Let’s take a look at these three routers: Nettle, Porpita, and Cannonball. Let’s verify the FD.

Checking the interfaces:

What is inside Nettle’s topology?

Let us pick the 192.168.203.0 network. There are 2 routes to go to 192.168.203.0 network. The first route is via the 192.168.102.2 of Porpita on the S2/0 or via the 192.168.103.3 of Cannonball on the s2/1 interface. As you noticed, both have the same FD of 41024000. Both are installed in the topology table and since they have the same FD both will be installed in the routing table.

Let’s check Cannonball’s topology table:

Look at 192.168.2.0 network. There is no feasible successor for this route. Wonder why? Because the AD of 192.168.203.2 is equal to the FD of 192.168.103.1 which is 40640000. Remember, that in order to become a feasible successor it should meet the feasibility condition where its AD should not be greater than or equal to the successor’s FD. You can see the AD of 192.168.203.2 by using the “show ip eigrp topology 192.168.2.0/30” command.

But just putting the command without the “ifs”, it made me realize that there is something I need to understand about this.

The “no auto-summary” command is configured under the EIGRP process. It prevents the auto-summarization of networks. Without enabling this command, the routes from its interfaces will be advertised as classful A, B or C networks to its neighbours.

Let’s say we have three routers: Trapdoor, Ebo and Huntsman. Ebo and Huntsman are connected to Trapdoor via serial links and they are connected to each other via FastEthernet links with 192.168.2.0/24 network.

Looking at the “show ip interface brief” of Trapdoor, loopback has been configured. These loopbacks should be accessible by Huntsman and Ebo.

After configuring basic eigrp configuration:

Trapdoor(config)#router eigrp 10
Trapdoor(config-router)#network 172.32.0.0
Trapdoor(config-router)#network 192.168.32.0
Trapdoor(config-router)#end
Trapdoor#

Let’s take a look at what happens to the routing table of each router after advertising the 172.32.0.0 network and 192.168.32.0 networks:

Ebo and Huntsman do not learn the loopbacks of Trapdoor.
Let’s try to enable the “no auto-summary” command:

Trapdoor(config)#router eigrp 10
Trapdoor(config-router)#no auto-summary
Trapdoor(config-router)#end

Take a closer look at Ebo and Huntsman’s routing table:

Both Ebo and Huntsman learned Trapdoor’s loopback address via EIGRP. The pings are also successful on all routers:

To make sure that “no auto-summary” command is configured, you can do “show ip protocols.”

Using the show ip protocol, we can see that automatic network summarization is not in effect.