DUAL Queries and the EIGRP RID
We love redundancy. We love backup paths. We love backup routes. We love backups of our data. We love having backups of everything.
But every once in a while we’re going to have a situation where we may have a primary route in EIGRP and not have that backup.
It’s fine if a router has a successor for a given route without having a feasible successor – as long as the successor route is available.
In an earlier lab, we saw a feasible successor step in for a successor that was suddenly unavailable. We loved that quick cutover, but what if there’s no feasible successor to cut over to?
EIGRP uses DUAL to calculate route metrics and to query neighbouring routers in the situation described here. DUAL will first mark the route in question as active, and at first glance that sounds like a good thing.
The “active” refers to the fact that EIGRP is actively calculating the route, not that the route is active and can carry data. An EIGRP active route cannot be used for routing.
With the route marked active, DUAL will now send queries out to the router’s EIGRP neighbors. This query is basically just one neighbor asking another “Hey, do you know how to get to this network? I just lost my route to it.”
The router in the middle (the one receiving this query) is either going to say “yes I do have an alternate path for that” and then that’s the end of it. But if the router in the middle doesn’t have a route, then is it will ask its neighbors.
So the DUAL query continues to span out throughout your network until we have a router that says “yes I have a route” or finally we’ve asked everybody in the network and there’s nothing there. So that’s Hell a dual Query operates.
And once that route is found (Once a neighbor says yes) then the routes will come out of active state and go back to passive.
Routes come out of active so quickly that it’s hard to spot one, and that’s the way we like it.
Routes that are no longer being calculated by DUAL and are therefore ready to be used to route data are passive, and this is one time where passive is better than active!
Let’s talk for just a minute here about the EIGRP router ID. And the thing is we haven’t even mentioned that to this point. But for our exam we really should know what’s going on with that.
EIGRP RID Rules:
- Value set by the eigrp router-id command.
- Highest IP address on any loopback in up / up.
- Highest IP address on any physical interface in up / up.
You can spot the RID which ‘show IP protocols’ and here I’ve got this on R2:
And let me show you something very quickly before we get into that.
I prepared this router for the very next section for the lab that we’re about to do.
And the only address on this router right now is 172.12.23.2/27. That’s it. It does have an adjacency with R3 (that’s not even important right now). Right now we just want to show you with ‘show IP protocols’, we’ve got that router ID at 172.12.23.2 because it’s the only address that possibly can be.
So let’s see what happens when we change the RID in EIGRP
(You remember exactly what happened right after we changed that OSPF RID. we were told we had to either reload it or clear the process for it to take effect.)
Let’s see what happens with EIGRP: (we’ll set it to 2.2.2.2)
You could see that we had a dual neighbor change here, and it’s actually down, (the adjacency went down), and you can see ‘route configuration changed’. And if we go down here we can see that the adjacency to that router came right back up:
So that actually wasn’t a problem. And let’s go ahead verify that
We see it’s been up for 35 seconds so we’re good there
See right in the middle router ID 2.2.2.2.
Something else I want to show you:
Notice this? We didn’t put EIGRP there but it worked perfectly fine.
But you can use router ID there under the EIGRP process, but the actual official command is:
and you could just put it in whatever you want to do (I’ll just change it to 3.3.3.3 while we’re here). So in the real world sometimes you can use the router ID command under the EIGRP process. I would go ahead and put EIGRP router-id as I did here and there you have again the adjacency going down so this isn’t something you want to do while your production is going on, but you’ll also notice the adjacency came right back up.
We’ll go ahead and run show IP protocols
and you can see that it has been changed to 3 3 3 3. So again I would stick with the command ‘EIGRP router-ID’ under the EIGRP process. Even though it seems redundant. EIGRP does that sometimes, but also know that the router ID command (which is the one we used first here) worked perfectly fine.
The Five EIGRP Packet Types
Hello packets handle neighbor discovery and serve as a keepalive for established adjacencies. They’re multicast to 224.0.0.10.
Acknowledgement packets are simply hello packets that carry no data. Neither acks nor hellos use RTP, and are therefore considered unreliable.
Update packets are sent to new neighbors, allowing that neighbor to build accurate routing and topology tables. They’re also sent upon a change in the network. Update packets are generally multicast packets, but this is networking, so you know there’s an exception. More on that in just a few minutes!
Query packets are sent when a router loses a successor and has no feasible successor.
Reply packets are sent in response to query packets. It’s a happy response, because reply packets indicate a new route to the destination in question has been found! Reply packets use RTP and are considered reliable, as are update and query packets.
Note : EIGRP RTP is the Reliable Transport Protocol.
Voice and Video use something else: The Real-Time Transport Protocol… but it is not known as RTTP! It is known as RTP.
So occasionally you may hear a discussion with RTP where they’re not talking about EIGRP.
If that’s the case, then they’re talking about the real time transport protocol.
To see how many of these packet types have gone(passed) through your router, run show ip eigrp reffic.
Troubleshooting Note: If you notice your queries are continually incrementing, that’s a good sign that you’ve got instability in your network somewhere. Because we know when a query is sent out, that really should be a pretty stable number (and not be incrementing on a regular basis).
The Initial EIGRP Route Exchange
Let’s take a detailed look at the forming of an EIGRP adjacency and the route exchange that follows. There festivities begin when EIGRP is enabled on R1’s Serial interface.
EIGRP hello packets are then multicast (to 224.0.0.10) via that interface in an attempt to find potential neighbors.
R2 receives the hello, and if certain values are agreed upon by the two routers involved, R2 will respond with an update packet (the adjacency begins to form). That packet contains all the EIGRP-learned routes R2 knows. Update packets are usually multicast, but in this case the update is a unicast.
R1 now Sends an EIGRP ack back to R2, letting R2 know the routes were received. R1 will also send an update packet of its own, Removed to R2, containing all the EIGRP routes R1 knows of. R2 will respond with an EIGRP ack of its own, and the initial route exchange is complete.
This is the only time EIGRP routers exchange full routing tables. After this, only network changes are advertised
The EIGRP Hello and Hold Timers
The EIGRP hold time has the same function as OSPF dead time. They each define the amount of time in which a hello must be received in order to retain the neighbor relationship.
EIGRP Hello packets are sent every 5 seconds on high-speed links, which includes Ethernet segments (and higher variations of Ethernet like the Fast Ethernet we’re using), Frame Relay multipoint circuits running at over T1 speed, and point-to-point Serial links.
Hello packets go out every 60 seconds over slower links, including Frame Relay multipoint circuits running at or less than T1 speed. The EIGRP hold time default is three times the hello time.
A good rule of thumb for this is that your LAN time is 5 seconds and your hello packets on VANs are 60 seconds.
Unlike OSPF, the hello and hold timers in EIGRP do not have to agree between potential neighbors in order for them to become actual neighbors. We’ll prove that in the next lab, using the R2 – R3 broadcast segment from previous labs (172.12.23.0 /27)
LAB – Timers and Adjacencies
We are ready to start our lab and I already have the adjacency here between R2 & R3
and we’re picking up right where we left off with the RID. I’ll just set that back from 3.3.3.3 to 2.2.2.2
Did we ever see a place where we saw the hello and hold timers mentioned? because before we run ‘show ip eigrp neighbor’:
then you know there’s adjacencies been up for 10 seconds and we see a hold time and that does go with the theory of “the hold time is three times the hello time” because we know the hello time on a broadcast segment by default is going to be five seconds. But we don’t see it listed there. There really should be a place where we could see both of them right next to each other: show ip eigrp interface detail
If you just hit enter, it’s going to give you the detail about all of your EIGRP level interfaces (and not a particular one). That doesn’t bother me right now because I only have one running!
This is also where you can see with their split horizon is disabled or enabled on an interface.
So let’s go ahead and run that on R3 as well
We can see both on R2 and R3 the hello interval is 5 and hold time is 15.
So even though they don’t have to match, by default they are going to match. So let’s make them not match.
So I just changed the hello interval from 5 seconds to 7. Will this really have any effect on my adjacency? Let’s take a look.
And a couple of things I want you to know. First off note that the hold time did not dynamically change. So even though I set the hello interval to 7 manually, the hold time did not go up three times that to 21 by default.That’s something to watch out for.
But right now I don’t have a problem because on R2 hold time was 15 and hold time is just another way of saying dead time. So R2 is looking for a hello packet every 15 seconds or it’s going to drop the adjacency. R3 is sending a hello out every 7 seconds, so we don’t have a problem. If we run ‘show ip eigrp neighbor’ :
we’ll see that adjacency is up, and under uptime we see 03:45. So everything is perfectly fine. But what happens if we’re playing around with it and the hello time goes higher than the hold time on R3?
So here hello-interval is 30 and hold time is 15. And the adjacency hasn’t come down immediately. But there is a good chance it’s going to come down pretty surely.
There we go… R2 is looking for a hello every 15 seconds but we’re sending one every 30 from R3. But notice now that the adjacency just came back up.
So what happened was R2’s hold time hit zero. Dropped the adjacency. Then when the hello did come in from R3, the adjacency came back up. Then the timer starts again it’s going to go back down. I’m going to go ahead and get rid of this annoying thing. And I’ll just put a no in front of this…
and you can see we’ve gone back to 5 and 15.
I could have just set it back to 5 seconds but I just put no in front of the whole thing.
This is what I was talking about with a flapping adjacency(previous pic) and this can happen where you ‘ve got lesser backup connections or lesser connections period, then communications can get cut off some times and it will go up and then down than up then down then up then down. That’s what we mean by flapping. Here it’s happening to our adjacency because our timers are mismatched.
So we’re not losing the adjacency because of the timer mismatch period. Because the first mismatch we had (where R3 had the hello interval of 7 seconds and R2 have the hold time of 15), that was no problem.
So there was not a mismatch there that was causing the issue. With the second mismatch we created (when we set the hello interval to 30 seconds), causing the issue was R3 sending out a hello every half minute. Problem is R2 demands one every 15 seconds. So it would drop when the hold time on R2 hit zero, and then when the hello did come in and R2 say “hey we’re back in business.”
