EIGRP

You are currently browsing articles tagged EIGRP.

EIGRP – Part 3

So if you haven’t, read my first two EIGRP posts here and here.  In this post, I want to walk through some of the EIGRP related show commands, and work in some of the other EIGRP features along the way.  As we discussed, there are two tables specific to EIGRP.

The Neighbor table
Once two EIGRP neighbors become ‘adjacent’ each router makes a neighbor entry for the adjacent router in the neighbor table.  The neighbor table can be examined by using the ‘show ip eigrp neighbor’ command…

image

The neighbor tables us some rather expected information.  For instance, the IP of the neighbor, the interface on which the neighbor lives (in this case a SVI on the switch), the current hold time, and neighbor total uptime.  However, there are a couple of other fields of interest that you might not know what they mean. 

The far left column shown as ‘H’.  While I have absolutely no idea why it’s called ‘H’ and what it stands for (some people seem to think it stands for ‘Handle’), I can tell you that it indicates the order in which the neighbors became associated with the router.  In this case, 10.0.0.2 became a neighbor first and 10.0.0.6 became a neighbor sometime after that. 

The SRTT(ms) column indicates Smooth Round Trip Time.  This is calculated based on the observed delay between updates and ACKs as perceived by this router.  It was interesting for me to see the SRTT be so high on one neighbor but from what I can discern it’s not something to worry about. 

The RTO column stands for Retransmission Time Out.  This is the amount of time the router will wait before resending a message that it didn’t receive an ACK for.  This is calculated based off of the SRTT but I’m not sure exactly how.

The ‘Q Cnt’ column represents the current EIGRP packet queue.  That is, messages that are in queue waiting to be sent out.  A high number (any for that matter) is usually something to look into right away.

The ‘Seq Num’  field indicates the current (last) sequence number heard from that particular neighbor.  Recall that sequence numbers are used for EIGRP communication that the router expects an ACK for.  To reply to the ACK, the neighboring router must reply with the same sequence.  If we add another route and distribute it into EIGRP (cause for a multicast update message to be sent) we can see this in action…

image

Note that not only did the sequence number column increase, but we also see that the SRTT and the RTO fields update as well.  Since we sent an update and received an ACK those fields can once again be updated with the more current time based on the delay in response. 

The Topology Table
We already spent a fair amount of time looking at the topology table in the previous posts, so I’m not going to dig into it again.  However, I do want to talk a little bit more about how the entries in the topology table impact EIGRP. 

Recall from the last post that EIGRP uses a query process to find a successor route in the case that it loses a path to a given prefix.  This query process involves contacting neighbors to see if any of them have a path to the prefix.  While not clearly stated in the last post, the query process can impact more than just the directly connected routers.  For instance, if you query all directly connected routers and none of them have a successor or feasible successor for a route, they will in turn query their neighbors.  When they do this, they wait for a reply from their query before sending an ACK to the initial query.  This process can take some time to complete as the query process can extend multiple hops away. 

Jeremy Stretch over at PacketLife has a great write up on the entire query process here.

There are two recommended methods used to combat what could become a ‘query’ storm.  First, use proper route summarization.  If a router receives a summary prefix from one of it’s peers, and then later receives a query for a more specific prefix from the same peer, it will immediately reply with a poison reverse response (infinity metric) and not propagate queries.  Let’s take a look at what I mean by that…

 image

In this case, router3 and router4 are advertising a summary /16 address up to router1 and router2.  This is being done with EIGRP’s manual summarization commands that are applied on the interfaces facing router1 and rourter2 as shown below…

interface FastEthernet0/0.30
encapsulation dot1Q 30
ip address 10.0.0.14 255.255.255.252
ip summary-address eigrp 1 10.64.0.0 255.255.0.0 6
no snmp trap link-status

interface FastEthernet0/0.40
encapsulation dot1Q 40
ip address 10.0.0.18 255.255.255.252
ip summary-address eigrp 1 10.64.0.0 255.255.0.0 6
no snmp trap link-status

This command tells EIGRP to manually summarize anything in the 10.64.0.0/16 network out of this interface.  This will include the 10.64.32.0/24 prefix.  A quick look at router1’s topology table confirms the summarization is working…

image

As you can see, it only knows about the /64 prefix, not the /24.  Router2’s topology tables shows a similar story…

image

Let’s also look at router4’s topology table since that’s where we’ll be running this experiment…

image

Note that the only path router4 has for the 10.64.32.0/24 is down through router5.  Let’s cut that link and see what happens.  Since router5 is the only successor for the prefix, router4 needs to go active on that prefix.  When it does this, it sends out queries to all connected neighbors.  In this case, the only neighbor it has is router2.  We can see the query going out here…

image

Router2 (10.0.0.17) will ACK the query…

image

Since it doesn’t have the 10.64.32.0/24 prefix in it’s topology table, it would generally go active on the prefix.  In this case, it doesn’t.  Rather it sends a reply directly back to router4 stating that for that prefix it has an infinite metric…

image

In this case, summarization effectively limited the query scope to just router2. 

The second method to limiting query storms is to use stub areas.  Stub areas don’t reply to queries since there isn’t any real sense in querying them at all.  If we modify our topology again slightly, we can show this quite simply…

image

In this case, we are going to configure switch1 as an EIGRP stub router.  This is done with the following configuration…

router eigrp 1
redistribute static
eigrp stub connected summary
network 10.0.0.1 0.0.0.0
network 10.65.0.1 0.0.0.0

This command defines switch1 as a stub router and tells it to still advertise it’s connected routes as well as summary routes (accomplished with the ‘eigrp stub’ command).  A look at the output of the ‘show ip eigrp neighbor detail’ on router2 shows us that it knows switch1 is a stub.  It also knows to suppress queries…

image

A sample of the query process on router 2 was taken before the stub configuration.  A query for an unknown prefix that reached router2 went to both router1 as well as switch1…

image

image

After the stub configuration, we only see it going to router1…

image

So those are two ways to limit the query scope in EIGRP.

There are 2 more things I want to talk about before we wrap up this series of EIGRP posts. 

Variance
EIGRP is unique in the fact that it has support for ‘unequal cost’ load balancing.  Normally, for more than one route to be installed in the forwarding table the metrics for the routes need to be identical.  EIGRP has a handy feature called ‘variance’ that allows you to use unequal cost routes at the same time.  It should be noted that this only applies to feasible successor routes in EIGRP.  Adding additional routes that don’t match the feasibility condition could cause loops.  Let’s take a look at an example to see…

image

After some interface delay tweaking, we can see that the prefix 10.0.0.12 /30 now has a successor and feasible successor route.  Looking at the routing table we can see that only one of these routes is present (as expected)…

image

Currently we only have the route pointing to the 10.0.0.25 router.  By making a simple change we can add the feasible successor route to the forwarding table as well…

router5(config)#router eigrp 1
router5(config-router)#variance 2

The ‘variance 2’ command instructs the router to add any route to the forwarding table that has a feasible distance (metric) that is less than or equal to 2 times the feasible distance of the successor route.  After adding the command we can see the immediate result in the forwarding table…

image

The path to 10.0.0.12 now lists both the successor as well as the feasible successor route.  In our case, the feasible distance for the successor route was 58880 and the feasible distance of the second route was 64000.  Since 64000 is less than or equal to 117760 (58880 x 2) we install the feasible successor route as well. 

There are a couple of other commands that apply to this load balancing configuration…

maximum paths <1 – 6> – This command sets how many EIGRP unequal cost paths can be added to the forwarding table.  The default is 4. 

traffic share – I found this set of command rather interesting.  EIGRP allows you to tune how you want traffic distributed across the multiple paths.  Initially, I had thought that once EIGRP offered the routes up to the CEF table that CEF would handle the forwarding either on a per destination or per packet basis based on your CEF configuration.  Not the case with EIGRP.  Let’s look at a couple of examples…

image

The ‘balanced’ mode appears to be the default configuration.  It determines the correct proportion based on metric and sets the traffic share based on that. 

image

The CCIE book claims that there is a ‘min’ as well as ‘min across-interfaces’ command but I found that my router’s only have ‘the across-interfaces version.  This tells the router to only use one path with the lowest metric.  If the metric is the same for two routes on different interfaces use those as well.  Seems to sort of defeat the purpose but I can think of a couple of use cases for that.

The book also claims that putting in the ‘no traffic-share’ command will cause the router to equally balance across both paths without any regard to metric.  My router’s don’t have that option again…

image

Distribute Lists
Like any good routing protocol, EIGRP allows the configuration of different types of lists to perform different tasks.  Let’s take a quick look at configuring distribute lists in order to influence which router’s are advertised and learned through particular neighbors.

Let’s go back to our summary address example to look at how distribute lists apply to neighbors…

image
Distribute lists are used to allow only certain prefixes in or out.  In this example, we’ll use the ‘in’ method on the left for router1 and ‘out’ method on the right for router4.   Before we start let’s reset things and look at router1’s topology table…

image

We first configure the prefix list to use to filter the summary address.

image

Then we apply the required ‘distribute-list’ configuration to the EIGRP process…

image

Here we are saying only allow prefixes that match prefix-list Summary to come in through interface Fa0/0.30 (interface facing router3).  Now if we examine the topology table of router1, we’ll see that things have changed slightly…

image

Note that besides the connected interface, the only route we see heading towards router3 is the summary address.  Now, let’s do the same config in the opposite direction on router4…

image

image

I’ve essentially done the same thing just in the opposite direction (out).  I also added a second prefix-list and second distribute-list command so that you can see how you can apply more than one of the distribute-list commands based on interface.  If you were to use the distribute-list command without specifying the interface, you could only do one ‘in’ and one ‘out’ command and it would apply to all neighbors. A look at router1’s topology table now shows…

image

Note how we only see the summary address now and all of the ‘southern’ prefixes are no longer listed. 

So I think that’s it for EIGRP for now.  I’m anxious to move on but I’m sure we’ll have some more posts on EIGRP coming up in the future!

Tags: , ,

EIGRP – Part 2

In the first post, we talked about some of the basics of EIGRP.  Terminology, metrics, neighbors, etc.  In this post, I want to talk about how EIGRP neighbors interact with each other.

Neighbors and Timers
First lets start by solidifying the requirements for two routers to become neighbors, or to become adjacent. 

-The routers must be in the same EIGRP AS (AKA router eigrp 1)
-Routers must share a common subnet (Primary interfaces are on the same subnet, secondary interfaces don’t count).
-The interfaces must not be in the passive list
-The K values, if changed from the defaults, need to match

That’s not a terribly long list considering that I listed some rather obvious ones in there.  The big hitter is the K values for the metric calculation must match. 

If all of these items are in order, a adjacency will be allowed to form.  Routers will first start off by exchanging hello packets with each other.  Hello packets are sent ,by default, every 5 seconds and every 60 seconds on T1 and slower WAN links.  It should be noted here that there is also a hold timer that is ,by default, 3 times that of the hello timer.  If the hold timer expires, it means that the router has lost connectivity to its peer router.  It should also be noted that these timers do NOT need to match in order for an adjacency to form.  Hellos are Multicast to the address of 224.0.0.10.

Sharing routes
So once an adjacency forms, the routers need to exchange routing information with each other.  This is done through the use of update packets.  Let’s take a look at the initial peering of two EIGRP routers and then see how they exchange routes.  Let’s use the same topology as last time…

image
Now, we’ll start with the 10.0.0.26 interface on router5 being shutdown.  If we look at the traffic on that segment, we’ll see router4 sending its regular hello messages out onto the segment…

image

Note that they are occurring every 5 seconds and that they are being sent to the multicast address of 224.0.0.10.  Now, let’s bring the interface back online and see what happens…

image

Let’s walk through this one packet at a time to get an understanding of what happened…

Note: I’m filtering out some packets because of the way the lab is setup, hence some of the packets sequence orders in the capture aren’t consecutive.

Packet 205
The normal hello that router4 had been generating…

image

Note that the only real EIGRP data in the packets are the K values, the EIGRP AS, and the type of packet (hello).

Packet 210
The first hello that router5 is sending out onto the segment once it’s interface came up.  Looks very similar to the one that router4 had been generating…

image 

Packet 211
Another hello from router4, very much the same as packet 205.

Packet 212
Shows router4 responding to the hellos from router5.  The response is an update packet with the flag of ‘Init’ set.  Note that this is unicast directly to router5 from router4.  Also note the EIGRP sequence number used is 62.
image 

Packet 213
Another hello from router5.  I’m assuming this this just got on the wire before it heard the response from router4.  (Duplicate of packet 210)

Packet 217
Router4 responding with the update and the init flag set.  (Duplicate of packet 212).

Packet 218
Router5 replies to router4 with an update, init flag set, as well as the acknowledge field set to 62…

image

At this point, we’ve completed a three way handshake between the routers. Router4 responded to router5’s multicast hello by sending an unicast update with the init bit set to router5. Router5 then responded with an update packet that had the init bit set as well as the sequence number router4 used in the initial update.

Packet 219
Packet 219 shows router4 sending an update packet to router 4 including all of the prefixes in it’s topology table…

image

Packet 220
Packet 220 shows router5 replying by telling router4 about all of the prefixes in it’s topology table…

image

But hold on a second, there are more then 2 prefixes in the topology table right?…

image

So what gives?  Why are we only telling router4 about the 10.0.0.20 and the 10.0.0.12 prefixes?  The reason is simple, it’s basic split horizon.  Don’t tell a routing peer about routes that he already told you about.  However, we can tell router4 about prefixes he told us about if we have a better metric to get to those prefixes.  So at this point, the routers are still in the process of sorting out the best path.

Packet 221
Recall that EIGRP uses ACKs to make sure that other routers get the updates that are being sent.  Packet 221 is router4 ack’ing the updates it heard in packet 220…

image

We can tell because the acknowledge field of this hello (ack) packet is set to 73 which was the sequence number of packet 220. 

Packet 222
This packet shows router5 sending a multicast route update.  The update is being sent as multicast since some of the route’s that router5 had have now changed.  Multicast update packets are used for route metric changes and unicast update packets are used (generally) for talking to new neighbors…

image

Note that the prefixes in this update only include the ones that router5 decided to go through router4 for.  (See the topology output show in packet 220 to confirm this).  Since the rest of the topology table hasn’t changed on router5, there is no need to update any of the other routers about those prefixes.

Packet 223
This packet shows router4 ack’ing the multicast update sent in packet 222.  This can be determined by checking the acknowledge field and seeing it shows the sequence number of 74 (packet 222’s sequence).

image

Packet 224
This packet shows router4 doing it’s multicast update for route’s that have changed…

image

We can see by checking router4’s topology table that the two route’s sent in it’s update are now being forwarded through (have a successor route pointing at) router5…

image

Packet 225
This packet shows router5 ack’ing the update router4 sent in packet 224.

image

The rest of the packets..
The rest of the packets show the router’s going back to their normal multicast hello process.  The routes have been exchanged and topologies have been updated. 

Now that we’ve seen a neighbor peer and exchange routes, lets talk about what happens in the case of a router failure.  For instance, let’s assume that router5 dies.  Looking at the topology table from router4 again…

image

We can see that is has two prefixes that head towards router5 (10.0.0.26).  When router5 stops responding, router4 will need to find replacement paths for each one of those prefixes.  Let’s see what happens…

image

The process is actually sort of neat.  Once the hold timer expires for a neighbor, EIGRP will query any of it’s existing neighbors to see if they know how to get to a specific prefix.  You can see that the last hello we saw from router5 was at packet 13.  Approximately 15 seconds later, the hold timer expires, and router 4 instantly reaches out to router2 to see if he has a path to any of the prefixes.  We can see this in the query packet…

image

Note that router4 is only asking for a path to the 10.0.0.20/30 prefix.  This is because he already had two paths to the 10.0.0.12 prefix so he’ll just remove the one going through router5 from the topology.  The next packet shows router2 ack’ing the query back to router4.  This piece seems a little unnecessary to me but it does ensure that each packet gets received…

image

Next we see router2 reply to router4 with a route update for the 10.0.0.20 /30 prefix…

image

The next packet is router4 ack’ing back to router2…

image

The next packet is router 4 sending out it’s multicast route update including the changed prefix…

image

Router 2 acks…

image

And the process is complete.  Things go back to the normal multicast hellos.  What’s interesting about this process is that the router will only send a query if does not have a second successor, or a feasible successor.  It only looks to replace paths that it can no longer reach. 

It’s important to note that the topology table here should list all of the routes as being ‘passive’ when the topology is stable.  This is indicated by the ‘P’ to the left of the prefix in the table…

image

Passive implies that the route is reachable and that EIGRP is fully converged.  If a route changes to the Active state, it means that the router has lost any successor or feasible successor path to the prefix.  This is what forces the router to send query packets to it’s remaining neighbors.  Since the query process is rather fast, routes should never stay in the active state for very long.  If they are, its indicative of a problem or unstable network topology. 

Recall that EIGRP wants an ACK for everything it does.  This can cause some interesting problems in the query process. For instance, if a router queries it’s neighbors for a new path but doesn’t get a reply the route will stay active.  This is referred to as being ‘stuck in active’ (SIA).  The router MUST hear back from all of the router’s it queries within 3 minutes (by default).  If it doesn’t, the route goes SIA and the neighbor relationship for the router and it the peer that didn’t reply get’s reset. 

This post is getting a little long, so it looks like I’ll have one more EIGRP post coming out soon that covers some of the other EIGRP features.

Tags: ,

EIGRP – Part 1

EIGRP is my favorite IGP (don’t hate me just yet, I have a good reason).  I’ll elaborate more on that comment later, but for now, let’s jump right into a topology so we can start playing with EIGRP…

image

In my lab, I’m using 1841 routers and since they only have two Ethernet interfaces, I’m going to be utilizing sub interfaces in this example.  The initial config involves configuring the interfaces on each router and ends with each router being able to ping it’s directly connected neighbor. I’m not going to run through that config since it’s pretty straight forward.

The bottom router (Router5) has a 10.64.32.0 /24 network behind it which we want to be reachable by all the routers.  The top switch (Switch1) has the 0’s route behind it which we also want to be reachable by all of the routers.  Let’s put a base configuration on each router to get EIGRP up and running and see what it does.  The base configuration will look like this…

<DEVICE>#config t
Enter configuration commands, one per line.  End with CNTL/Z.
<DEVICE>(config)#
router eigrp 1
<DEVICE>(config-router)#network <Physical Interface IP> 0.0.0.0
REPEAT ABOVE COMMAND FOR EACH INTERFACE
<DEVICE>(config-router)#
end
<DEVICE>#

So for instance, the switch configuration would look like this…

image

Once, that’s done on all of the routers, let’s look at the routing table on router5…

image

You’ll note that we have two routes that have dual paths to the destination prefix.  Those are the 10.0.0.8/30 prefix as well as the 10.0.0.0/29 prefix.  Looking at the topology again, this makes sense since the paths to each of those prefixes from router 5 would truly be equal cost. 

No other real surprises here.  The rest of the /30’s are listed in the routing table as we would expect since all of the routers successfully joined EIGRP.  Let’s talk a quick second to talk about route selection.  As you know (or should know, read this if you don’t) EIGRP has an admin distance of 90.  Any route to the same destination with a higher admin distance will get squashed by the EIGRP route.  The admin distance of 90 is for what are called ‘internal’ EIGRP routes.  There are also ‘external’ EIGRP routes that have an admin distance of 170.  External EIGRP routes would be routes leaked into a EIGRP AS from a different EIGRP AS through route distribution.

However, what we don’t know is how EIGRP decides which route it is going to pick to get to each prefix.  For instance, we see above that to get to 10.0.0.8/30 router5 had two paths to the destination.  That’s because these two paths are equal cost so EIGRP can safely insert them both into the FIB and let CEF handle the load balancing between the two next hops.  However, since router5 is dual homed, it does have two paths to get to each and everyone of the other prefixes as well.  So where are those?

Before we go too far down the rabbit hole, let’s define some EIGRP terminology that should help us stay on track…

Adjacency
The goal of every EIGRP router is to form an adjacency with a neighboring EIGRP router.  Once this adjacency has been formed, the router will receives EIGRP updates from it’s peer router.  The updates can then be processed ,along with the metric to get to the peering router, to determine a distance to the prefix learned in the advertisement.

Feasible Distance (FD)
Of all of the paths learned to each given prefix, one will be picked as the ‘best’ path.  This metric associated with this best path is known as the ‘feasible distance’.  Basically, the router just picks the lowest cost path and makes that the FD. 

Advertised Distance (AD)
The advertised distance is the metric from the neighbor advertising the prefix, to the prefix.  That is, the feasible distance minus the cost to get to the neighbor you heard the advertisement from. 

Feasibility Condition (FC)
The feasibility condition states that a route may become a feasible successor route if the advertised distance is less than the feasible distance. 

Successor
A successor is the best route to a prefix

Feasible Successor
A feasible successor is a route that matches the feasibility condition and can be used as a backup route. 

Unfortunately, we need to go a little but further down the rabbit hole to fully understand EIGRP. To do that, we need to understand the metric that EIGRP uses. The metric itself is rather complicated, but if you assume the use of default values, one can size the formula down to this…

image

Let’s take a look at our example to clarify things.  So here is the output of the EIGRP topology table on router5…

image

Using that formula, let’s make sure we understand where the metric are coming from that EIGRP is reporting.  For instance, let’s examine the prefix 10.0.0.0 /29.  Note that the EIGRP topology table is showing 2 successors for the prefix, with two next hops that have matching metrics.  If the metrics weren’t a dead match for each other, we wouldn’t have 2 successors (in most cases, more on that later).  The topology table is reporting a feasible distance of 33280 and a advertised distance of 30720 for both paths to that prefix.  Let’s break down the math to see where that comes from.

Recall, we really only need to come up with two variables to solve the equation, the minimum bandwidth along the entire path and the sum of all interface delays.  Our lab topology currently uses fast Ethernet interfaces with the default delay and speed configuration, so the path looks something like this…

 image

The information on the delay as well as the interface speed can be shown using the ‘show interface <interface>’ command.  Here we see the speed and delay of an interface on router5…

image

Note: The delay can be statically set on an interface (we’ll do that later).  However, when you set the delay you are setting it in ‘tens of microseconds’ which are not the same as the usec metric.  If you set the delay to 50 on an interface, it will be 500 usec.  It’s good practice to verify what was set with the show interface command to make sure it’s what you think you configured. 

So, we can see here the the minimum bandwidth is 100 meg (100000 Kb) on any of the given links.  So there is out first variable, our second variable is the sum of the interface delays which we can see would equal 300 usecs.  Plug those into the formula…

image 

and we get a metric of 33280.  So that’s our feasible distance, how about our advertised distance?  Recall that the advertised distance is the metric a router hears advertised by it’s neighbor not including the cost to get to the neighbor.  In this case, that would mean that we’d just remove the delay of router5’s interface and run the equation again…

image

Which gives us an advertised distance of 30720 like we saw in the output above. 

Now, let’s look at a prefix that only has one entry in the topology table.  For instance, let’s look at the prefix 10.0.0.12 /30.  The EIGRP topology table shows only one path to that prefix…

image

And why is that? The answer is simple, all other paths must fail the feasibility condition.  Let’s look at the other paths to prove this…

image 
The path highlighted in orange is obviously the shortest path to the prefix, but let’s look at the purple path to prove why it can’t be a feasible successor.   The metric for the orange path is 30720 which is the prefixes feasible distance.  Let’s compute the metric for the purple path.  The minimum bandwidth on that path is 100000 Kbps but the delay is 400 usec.  That would gives us a metric of 35840 for the purple path.  The feasibility condition states that a route may become a feasible successor route if the advertised distance is less than the feasible distance. Since 35840 is not less than 30720, the route is not a feasible successor to the existing successor.  Let’s shut down the link between router3 and router5 to prove that our metric calculation was valid…

image

I show the use of a very handy command here.  The ‘show ip eigrp topology <prefix>’ command is very handy in determining the metric and the means in which it was calculated.  As you can see, we started wit the FD of 30720 (orange path) and after shutting down the interface, we came up with a FD of 35480 (purple path). 

Hopefully, at this point, EIGRP is starting to make a little more sense to you.  To mix things up a bit (and show us some other features) let’s manipulate some of the interfaces to change things up a little bit…

image 
Notice that we’ve manipulated the delay on the links between router1, router3, and router5.  A look at the topology table on router5 now shows us…

 image

2 prefixes to the 10.0.0.12 /30 subnet.  Let’s do the math on each of these to figure out how this happened. 

The Orange Path Feasible Distance
image 

The Purple Path Feasible Distance
image 

The winner in this case turns out to be the purple path since it has a lower metric.  However, the advertised distance of the orange path turns out to be 281600 which happens to be less than the feasible distance of the purple path.  When this happens the route becomes a feasible successor.  The output of the topology table confirms this for us…

image

Taking a close look at the topology table, we can tell that we are dealing with a feasible successor…

image

Note that the table says it has 1 successor, but there are two entries.  Only the first entry will show up in the forwarding table of the router…

image

Since there is a second entry, we know that EIGRP is using the second route as a feasible successor.  If EIGRP is going to insert both routes into the routers routing table, it will tell you that you have 2 successors as we saw above with the 10.0.0.0 /29 prefix…

Topology Table
 image

Router’s routing Table
image

I think that’s enough for now.  There are a few more aspects of EIGRP I’d like to cover in my next post but I think this is enough to get started.  Look for post 2 coming up next!

Tags: , , ,