The Feasible And Reported Distances
We’ve been working with the typology table for a while now, and you’ve certainly taken notice of the two numbers in parenthesis following each next-hop IP address.
and we’re using this particular network right now (something very familiar to us)… 172.12.123 is our frame and then Fast Ethernet segment 172.12.23.0/27. I put a loopback 0 on each one with a 24 bit mask using the router number four times.
Here are the EIGRP topology table entries for 172.12.23.0/27 on R1: (Our broadcast segment connecting R2 & R3 with a switch)
The first number, 2172416, is the route’s feasible distance. This is the full metric of the route to the destination network. A route’s feasible distance also appears in the routing table, right next to the administrative distance of that same route.
The second number, 28160, is the route’s reported distance. Nothing complicated here – it’s just the metric from the next-hop router to the destination network. The RD is visible only in their EIGRP topology table.
We better know exactly what’s going on with each one that’s feasible. Distance is the full metric of the route to the destination.
So you could look at these two(the pic) and you know what the feasible distance of those two paths are going to be on R2 & R3 respectively. It’s going to be 28160.
Something to remember: We know that as far as our successor routes go, they appear in both the routing and topology table. That’s true of the feasible distance of any route you’re going to see it in the round table. But the only place that you’ll see the reported distance of a route, is in the EIGRP typology table.
So why don’t we do all of these? Why do we have two distances? Well we talk about paths being valid and loop-free, and what we mean by that is that we don’t want to be going in circles when we’re sending packets to a destination. We want to make sure that there are no possible routing loops in there before we start sending packets.
For the path to be considered loop-free, the reported distance must be less than the feasible distance. This routing loop prevention mechanism ensures the next-hop router is closer to the destination than the local router.
Applying The Feasibility Condition
These distances are also used by EIGRP to determine the feasible successors.
Let’s walk through this important process using R1’s topology entries for 3.3.3.0/24.
Just a quick refresher: We know R1 has two paths to get to R3’s look back. It could send packets through the clouds straight to R3, and then they’re there at the loopback.
We can also send them through the cloud down the R2, and R2 forwards them across the broadcast segment, and then they’re at R3… so there we go.
We’re probably going to have a successor there and a potential feasible successor.
We look at this table entry and we see the routes are close, but they’re not the same since no equal costs load balancing going on.
Does this table actually tell you which route is the successor?
It sure doesn’t, but it’s pretty easy to figure it out. You just got to be careful because most of the time the successor is the first entry here (but not every time).
Here, when it lists the F.D. there, it’s telling you this is the feasible distance of the successor (2297856)… So we have our successor.
Now how did EIGRP determine that this other route should be in the topology table and would be a feasible successor?
EIGRP uses the feasibility condition… all we’re doing is comparing the reported distance of a candidate feasible successor to the feasible distance of the successor.
(you’re comparing the second number in the brackets of the candidate feasible successor to the first number in the brackets and the successor).
The path through 172.12.123.2 is a feasible successor, since its RD of 156160 is less than the FD of the successor, 2297856.
That’s the feasibility condition in a nutshell!
Let’s get some practice in with the feasibility condition using some slightly smaller numbers. We’ll assume a successor route and three possible feasible successors.
Successor: FD 5, RD 4
Possible FS 1: FD 9, RD 7 -> 7 is greater than 5 -> NO
Possible FS 2: FD 8, RD 6 -> 6 is greater than 5 -> NO
Possible FS 3: FD 6, RD 4 -> 4 is smaller than 5 -> YES
Now we’re going to get some practicing with this particular network:
and we’re going to answer all the questions ourselves:
Which route from one to three would be the successor?
Which one or ones of the remaining two routes would be feasible successors? And why?
From R1’s point of view, the FD and RD of each path:
R1 – R4 – R3: FD 40, RD 20
R1 – R2 – R3: FD 70, RD 20
R1 – R5 – R3: FD 115, RD 75
Just a hint from an exam veteran here: You really want to watch this whenever you see one number a little out of whack maybe indicating a slower link that kind of thing.
75 is pretty big for this little model because most of the values are 20s and then we got a 40 and a 50. But then all the sudden we got a 75… bit of a red flag there…
The R1-R2-R3 path’s RD is 20, and 20 is less than 40, so that route passes the feasibility condition and becomes a feasible successor. The R1-R5-R3 path’s RD is 75, which is larger than the successor’s FD, so that route is not a feasible successor.
R1 – R4 – R3 : successor
R1 – R2 – R3 : feasible successor
R1 – R5 – R3 : neither
You know we may not even pay much attention to it. Do we really need to know this for the real world.
The Feasibility Condition and Variance
It’s a great idea to write out the FD and RD of all routs in your network before deciding on the variance value and to determine whether all of the desired paths can actually be used in unequal-cost load balancing… as in the following!
How can I use the variance command to get as much unequal-cost load sharing here as I possibly can?
The path from 1-2-5 is going to have an overall FD of 40, and 1-4-5 it’s going to be 55 and 1-3-5 it’s going to be 115. we’re using the feasible distance when it comes to variance for all three routes.
What’s the lowest value number multiplied by 40 greater than 115. Answer: 3.
That means that we have unequal cost load sharing going on over all three links.
Important Exception: If a path does not meet the feasibility condition it cannot take part in a load sharing.
So lets go through that process one more time and see what’s going on.
R1 – R2 – R5: FD 40, RD 20
R1 – R4 – R5: FD 55, RD 35
R1 – R3 – R5: FD 115, RD 75
R1-R2-R5 path is going to be the successor, because it has the lowest feasible distance of the three.
R1-R4-R5 meets the feasibility condition and it’s the feasible successor, since its RD of 35 is less than the FD of the successor (40)
R1-R3-R5 path does not meet the feasibility condition because it’s RD of 75 is larger than the successor’s FD. You could actually set variance to 2 on R1 in this situation(to bring the 1-4-5 path in for unequal-cost load sharing) , which could allow unequal-cost load sharing over the single feasible successor.
Whatever your variance is (3 or 155 or…) you could never bring the 1-3-5 path in to unequal-Cost load sharing because it’s failing the feasibility condition.
The Triple Threat: EIGRP Administrative Distances
With OSPF, you have one basic Administrative Distance: 110.
Regular OSPF route? AD is 110. OSPF route learned by redistribution? AD is 110. OSPF E1 route? AD is 110. OSPF E2 route? AD is 110.
This is one area where OSPF and EIGRP differ greatly. We actually have three different EIGRP administrative distances:
Internal routes, introduced to EIGRP with the network command, have an AD of 90 and a routing table code of “D”. (“E” was already in use by EGP, the External Gateway Protocol.)
External routes, introduced to EOGRP via route distribution, have an AD of 170 and a routing table code of “D EX”
Summary routes, the result of manual route summarization, have an AD of 5. (NOT in Exam)
I’ve got to a loop back on R1 and we have an adjacency to R2 through cloud (the same 172.12.123.0/24 network. And right now R2 doesn’t have anything in its table.
because we don’t have any EIGRP routes (I changed everything and erased it for the next lab)
I’m going to introduce the loopback on R1 in two different ways so you can see the differences.
So right now under the eigrp, we will use the network command as we have before.
(And that’s the IP address I have in the loop back on R1)… we go to R2:
And there’s the route… We got an AD of 90 and a code of D.
So let’s go up to R1, we’re going to take that out, and now we’re going to do a redistribute connected. And what it will do, it will redistribute our connected networks on R1 into EIGRP but watch the difference here:
and we’ve got redistribute connected. Let’s do a ‘show ip eigrp’:
You can see the difference in the table right there. D EX is the routing table code and it has an AD of 170.
So in future more advanced studies you will get into reasons why on occasion you would want to use the redistribution instead of the network command.
