EIGRP Stub Explained

Hello, I have a question about the example with just R1 and R2.

If I’m not mistaken…
When R1 is not a stub and you shut down R2’s loopback, R2 sends a query to R1. However when R1 is a stub and you shut down R2’s loopback, R1 sends a query to R2.

Why does R1 send a query when it is a stub, but not when it isn’t?

Thanks for any help!


One more question, sorry.

Perhaps IOS has changed since this post was created, but when I enable ‘eigrp stub redistributed’, it doesn’t also enabled connected and summary. I just appears in ‘show run’ as ‘eigrp stub redistributed’. Is that odd, or just a change in IOS?

Hello Jeremy

This is a great question and it brings up some subtle points of how EIGRP functions. Queries are subject to the split horizon rule just like advertisements are. If you get a query for a network from an interface, you never send out a query for that same network from that interface.

So in the first case, when R2 lost connectivity to the loopback network, it sent a query to R1 for an alternate route to that destination. This is because in this case, R1 is not a stub. Because R1 got a query from R2, it did not send a query back to R2 via that interface due to the split horizon rule.

Now 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, so it can send a query to R2 without breaking the split horizon rule.

I hope this has been helpful!


1 Like

Thank you so much Laz, that totally makes sense now. I didn’t realize that split-horizon applies to queries too, but it makes sense that it does.

1 Like

Hi Lazaros
If i configure Stub redistributed, as Rene has said that it includes Connected and Summary,
Can we do:

R1 (config-router)#eigrp stub redistributed 
R1 (config-if)#ip summary-address eigrp 12

Hello Muhammad

Actually, the eigrp stub redistributed command includes routes learned from other sources, including other routing protocols, directly connected, as well as summary routes. If you then configure the ip summary-address command on a particular interface, then this information will indeed be advertised into the stub.

I hope this has been helpful.


Hello Rene,

I took some time to lab this “eigrp stub redistributed” out and found some interesting parts (if only “redistributed” is in it without “connected” and “summary”)
The Stub router will only advertise if you use the eigrp “redistribute” command with an foreign routing protocol or another EIGRP AS it wont advertise the route if you use “redistribute connected” or “redistribute static” you need to manually type “stub connected redistributed static” to do that.

Update: I just did a “show version” and it’s IOS release 12.4

Best regards,


Does stub redistributed configuration include static routes??

No It Doesn’t , I’ve tested it now in GNS3 :slight_smile:

1 Like

I too can confirm that when labbing the redistributed stub that only redistributed routes are advertised. This was running 15.2(4)M7 in GNS3

1 Like

@ReneMolenaar I lab this, and when i put the eigrp stub redistributed it did’nt add the connected summary, and the router redistributed the connected routes fine. I have a loopback in R5 being redistributed. is subnetted, 1 subnets
D EX [170/156160] via, 00:00:50, FastEthernet0/0
R5(config-if)#do sh run | be router
router eigrp 123
 redistribute connected
 eigrp stub redistributed

Hello Erick

According to the Cisco IOS Command Reference, using the redistributed keyword will only advertise routes learned via other routing protocols. Specifically, there are five keywords that can be used to determine what kinds of routes will be advertised. These are described like so in the above-mentioned Cisco documentation:

  • The connected keyword permits the EIGRP stub routing feature to send connected routes. If the connected routes are not covered by a network statement, it may be necessary to redistribute connected routes with the redistribute connected command under the EIGRP process. This option is enabled by default.
  • The static keyword permits the EIGRP stub routing feature to send static routes. Without the configuration of this option, EIGRP will not send any static routes, including internal static routes that normally would be automatically redistributed. It will still be necessary to redistribute static routes with the redistribute static command.
  • The summary keyword permits the EIGRP stub routing feature to send summary routes. Summary routes can be created manually with the summary address command or automatically at a major network border router with the auto-summary command enabled. This option is enabled by default.
  • The redistributed keyword permits the EIGRP stub routing feature to send other routing protocols and autonomous systems. Without the configuration of this option, EIGRP will not advertise redistributed routes.
  • The leak-map keyword permits the EIGRP stub routing feature to reference a leak map that identifies routes that are allowed to be advertised on an EIGRP stub router that would normally have been suppressed.

So each type of route is advertised using a different keyword. You can use any combination of the above five in the command, such as eigrp stub static connected redistributed for example.

According to the documentation, the redistribute keyword does indeed advertise ONLY routes learned from other protocols.

I hope this has been helpful!


1 Like

Hello Laz,

the sentence “R1 will only send queries IF one of its connected networks go down.” irritates me. I thought R1 (or any other Router) will send a query for each network that he probably lost (from his routing table). Your answer sound as if a query would only send if a directly connected network goes down (topology table)!?


edit: or results this behaviour because of the impilcite “connected” command?

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.


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:

EIGRP: Received QUERY on FastEthernet0/0 nbr

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.


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!


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,

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:

   Handling TLV: 242 42 for 0 route:
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:
EIGRP: Received QUERY on FastEthernet0/0 nbr
  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:

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!


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,

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!


1 Like