There are several specialised cases where the receive-only option is useful. Some of these include:
When applying it to a dual homed stub router with more than one connection to the same EIGRP AS. In a Dual-homed scenario “receive-only” would prevent the stub router from becoming a transit router incase of link failure in your core and still have redundancy from the stubs perspective.
When using a route server connected to an eBGP network
I know this is an old post but I believe your statement to be incorrect as EIGRP stub routers do receive queries as queries are sent as multicast in the first instance. They reply to the majority of queries with an infinite metric, unless of course they are networks the stub router is allowed to advertise (summary, connected, static, redistributed or a leak-map - depending on configuration).
Thanks for bringing this up. It seems that it is an issue of terminology. You are right that a stub router will indeed receive queries from neighboring routers that lose a network. However, an EIGRP stub router will not process these queries. This, I believe, was Rene’s meaning as well. Specifically, Cisco states the following:
The stub device responds to all queries for summaries, connected routes, redistributed static routes, external routes, and internal routes with the message “inaccessible.”
This was taken from the following Cisco Documentation that contains additional information about EIGRP stub networks.
Yes this is pretty much exactly what I said in my post.
There are some specific use cases where you will need to allow a stub router to process queries (such as multihomed branch offices in a DMVPN deployment where if R1’s uplink fails, you have to reconverge through R2 etc).
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?
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?
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.
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 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
@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.
2.0.0.0/24 is subnetted, 1 subnets
D EX 2.2.2.0 [170/156160] via 192.168.12.5, 00:00:50, FastEthernet0/0
R5(config-if)#do sh run | be router
router eigrp 123
network 192.168.12.0
redistribute connected
eigrp stub redistributed
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.
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)!?
thanks
edit: or results this behaviour because of the impilcite “connected” command?
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.
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.
