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…
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…
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…
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…
As you can see, it only knows about the /64 prefix, not the /24. Router2’s topology tables shows a similar story…
Let’s also look at router4’s topology table since that’s where we’ll be running this experiment…
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…
Router2 (10.0.0.17) will ACK the query…
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…
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…
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…
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…
After the stub configuration, we only see it going to router1…
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…
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)…
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…
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…
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.
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…
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…
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…
We first configure the prefix list to use to filter the summary address.
Then we apply the required ‘distribute-list’ configuration to the EIGRP process…
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…
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…
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…
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!