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…
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…
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…
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…
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…
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.
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…
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…
Packet 220
Packet 220 shows router5 replying by telling router4 about all of the prefixes in it’s topology table…
But hold on a second, there are more then 2 prefixes in the topology table right?…
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…
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…
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).
Packet 224
This packet shows router4 doing it’s multicast update for route’s that have changed…
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…
Packet 225
This packet shows router5 ack’ing the update router4 sent in packet 224.
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…
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…
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…
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…
Next we see router2 reply to router4 with a route update for the 10.0.0.20 /30 prefix…
The next packet is router4 ack’ing back to router2…
The next packet is router 4 sending out it’s multicast route update including the changed prefix…
Router 2 acks…
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…
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.