EIGRP Stub Explained

Hello Thomas

EIGRP is a distance vector routing protocol that is characterized by the fact that it sends incremental updates, and only when an actual change in the network has occurred.

My statement was written in order to emphasize the fact that EIGRP will send an update only when there is a change in the network (and not periodically like RIP does for example). Now the question that was asked was about a specific topology and about a very specific failure. That’s why I used the example of the loopback failing.

To clarify, yes it is true that EIGRP routers will send updates about any changes that occur in the network, whether directly connected, or learned via EIGRP updates from other routers.

The very first update will be sent by the router which is directly connected to the failed link, but that change will propagate from router to router until the whole network is informed, and alternative routes to destinations are calculated.

Thanks for mentioning it, and I hope this has clarified my statement.

Laz

Hi Laz,

I think I’m still missing something. Regarding the second case, how does R2 know that R1 is a stub?

You say that R2 doesn’t send a Query, but the output shows otherwise:

R1#
EIGRP: Received QUERY on FastEthernet0/0 nbr 192.168.12.2

I’ve tried to lab it up, but, in the second case, none of the routers sent a Query. Could be an issue with the emulator perhaps.

Thanks,
LP

Hello Luis

When R1 is configured as a stub router, R2 is informed of this via EIGRP communication. R2 knows that R1 is a stub. This means that R2 will never send a query to R1 if it loses connectivity to some other network. As stated in Cisco documentation:

Any neighbor that receives a packet informing it of the stub status will not query the stub device for any routes, and a device that has a stub peer will not query that peer. The stub device will depend on the distribution device to send proper updates to all peers.

This means that R1 will wait for normal updates to find out that a particular network is down. This is why you see in the debug of R2 that R2 did not send a query.

Now you mention that you see an incoming query on R1. This is most likely a typo, and I’ll talk to @Rene so he can take a look, and unless I am mistaken, he will confirm and correct it.

I hope this has been helpful!

Laz

1 Like

Hi Laz,

I’ve done the lab again and, if R1 is a stub and R2 loses the route, R2 will send an Update with an infinite delay, for that route. R1 will then respond with an Ack.

Best regards,
LP

Hi @ribeiro.luis,

Which IOS image did you use? This sentence shouldn’t be there so I removed it:

I just tried this debug again on two different IOS images. When I use 15.6(3)M2, I don’t see anything at all. R1 doesn’t send a query to R2.

When I use 15.1(4)M10, I do see the query:

R1# 
   Handling TLV: 242 42 for 0 route: 2.2.2.0/24
EIGRP: Enqueueing QUERY on FastEthernet0/0 tid 0 iidbQ un/rely 0/1 serno 7-7
EIGRP: Sending QUERY on FastEthernet0/0 tid 0
  AS 12, Flags 0x0:(NULL), Seq 9/0 interfaceQ 0/0 iidbQ un/rely 0/0 serno 7-7
   Handling TLV: 242 42 for 0 route: 2.2.2.0/24
R2#
EIGRP: Received QUERY on FastEthernet0/0 nbr 192.168.12.1
  AS 12, Flags 0x0:(NULL), Seq 9/0 interfaceQ 0/0 iidbQ un/rely 0/0 peerQ un/rely 0/0
   Handling TLV: 242 42 for 0 route: 2.2.2.0/24

So somewhere in between these IOS versions, they decided to change the behavior of EIGRP. I added a note in the lesson in case anyone else runs into this.

Thanks for taking the time to test this and let us know!

Rene

Hi Rene,

I’m using version 15.4(2)T4, so I guess you’re right.

To be honest, I think that this new behavior makes more sense. The router loses the route and immediately informs its neighbors.

With IOS 15.1(4)M10, I don’t really understand what triggers R1’s query.

Best regards,
LP

Hello Luis

In order for the stub router to send out a query, it must first be informed of a change. This information must come from R2 in a normal scheduled update. Because R1 is a stub, queries will not be sent to it, but normal updates are. Once that update is sent to R1, it will respond with a query (in the IOS versions that function in that manner).

That’s what triggers it, but after doing some research, I have found that documentation is lacking in this area for the particular reason for the query. Others have been asking the question too, but I haven’t seen a sufficiently satisfactory answer. Maybe @ReneMolenaar has something more substantial?

I hope this has been helpful!

Laz

1 Like

Hi Rene
On the 3 routers example, when R2 was made into stub router , it stop receiving query message from R3, does it also stop receiving query message from R1.
thank
Lam Soon

Hello Lam

With the application of the stub configuration on R2, R2 does not stop receiving query messages from R3 but it stops sending them to R3. In the same way, R1 will also stop receiving query messages from R2.

In the examples with the three router topology, whenever the stub configuration is applied to R2, the results are applied in both directions. In the examples, Rene examines how the command affects the routing table of R3. However, if you were to look at the routing table of R1 as well, you would see a similar situation. So it works in both directions.

I hope this has been helpful!

Laz

Hello Laz

Thank

Regards,

Tan Lam Soon

@lagapidis "in the second case R2 knows that R1 is a stub so it doesn’t sent a query for the lost network. When R1 learns of the lost connectivity to the network (via updates etc), it hasn’t received a query for that network."

According to above statement , Even if the router is configured stub still it will send the query if there is a failure in non-stub routers but it will not receive the query , but the major concern is that , if the stub router is sending the query it means its expecting the reply so if the reply does not come within 3min then the neighbor-ship will be broken , is not it ??..then whats the benefit of stub here .??

Another thing is that , before ios12.x the stub router was generating the query if there is failure in non-stub routers network but since 15.x ,if the router is configured as stub then it will not generate the query ??..isn’t it ??

Hello Narad

When we talk about stub routers and their suppression of queries, we’re talking about the origination of queries, and not their replies.

In the particular topology, we’re talking about, R1 is the stub router and R2 is not. In the lesson, you can see that if R2 loses the 2.2.2.0/24 network, it won’t send a query to R1 asking for an alternate route. At the same time, R1 has also lost the route to 2.2.2.0/24, and R1 will send a query to R2 for an alternate route, which is fine since R2 is not a stub. Note, these queries are both originated by each router, and are not replies, so there is no issue with stuck in active.

Can you share where you found this info so we can respond more approrpiately?

I hope this has been helpful!

Laz

Thank you for this Rene! You cleared up anxiety about what “stubs” are! I thank you very much

1 Like

I think 3.3.3.3 should be in the routing table of R2 when R1 is eigrp stub receive-only.
I am not sure if loopback 0 is configured on R3 yet, but the routing configuration seems to imply that it is.

Hello Justin

Yes, because the 3.3.3.0/24 network is being advertised on R3, and we assume that the loopback has been created, we should see that network appearing in the routing table of R2. I will let Rene know to make the appropriate clarification.

Thanks for pointing that out!

Laz

Hi,
As Rene says the options for stub are as follows:

Receive-only: The stub router will not advertise any network.
Connected: allows the stub router to advertise directly connected networks.
Static: allows the stub router to advertise static routes (you have to redistribute them).
Summary: allows the stub router to advertise summary routes.
Redistribute:allows the stub router to advertise redistributed routes.

I just have a quick question.
If I have for example a stub with connected and summary only.
And lets say I create a static route and redistribute it into eigrp on that same stub router with redistribute static.
Will this be enough for eigrp to advertise that static route to the rest of the eigrp network or is it an absolute must that I have to add word “static” to the already Eigrp stub connected and summary ?

Hello Sean

Just to be sure, I labbed this one up.

If you have a static route configured on the stub router and you redistribute that static route into EIGRP, that stub router will NOT advertise it to the rest of the EIGRP network. You must use the static keyword to have the stub router advertise that network.

I hope this has been helpful!

Laz

1 Like

Thats very helpful, thanks very much Laz.

1 Like

Please can explain about the “Stub Site Function”. I could not find it in EIGRP Section. This is discussed in ENARSI official Cert Guide.

Hello PK10

The stub-site function you mention is part of what is known as EIGRP IWAN simplification. It is a method of employing the EIGRP stub feature in a DMVPN environment making it simpler to deploy than the conventional way. For more information about it, take a look at the following Cisco documentation:

If you would like to suggest a lesson based on this particular feature, feel free to make your suggestions on the member ideas page below:

There you will see the suggestions made by others as well, and you may find that others have made similar suggestions to yours, and you can add your voice to theirs.

I hope this has been helpful!

Laz

1 Like