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 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
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
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
Thats very helpful, thanks very much Laz.
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
Hi,
I was just wondering if an EIGRP stub can be used as a transit area. I understand the idea of EIGRP stubs.
But some licences only allow for EIGRP to run as a stub on switches.
So if I formed an eigrp neighbourship between my stub and another switch and then just used static routes on the Stub between it and some other switches not running eigrp and used commands “EIGRP stub connected static redistribute” and “redistribute static” on the stub then could it work ? ie. could I use the stub as a “transit” switch allowing traffic to flow back and forth through it to other switches/ devices running static routes.
I hope it makes sense.
I know its not ideal but basically I’m just wondering if an EIGRP stub can be used as a “transit” switch if I use static routes between it and other downstream networks and if it will allow traffic to pass through it back and forth from those downstream non EIGRP neighbour networks to its one and only EIGRP network neighbour.
Thanks.
Hello Sean
The quick answer to your question is yes, you can make an EIGRP stub function as a transit area. As stated in the lesson, there are four “flavors” or “permutations” of EIGRP stub networks. These are:
In order to make it a transit area, you can use any of the stub types except for receive-only
. That’s the only one that will disallow transit traffic to traverse the stub. That’s simply because the stub router will not advertise any networks “behind” it to the rest of the network, so no routers will know of any paths to any networks behind and beyond the stub router.
Remember, even if you create a receive-only stub network, you can always “override” the routing established by EIGRP by redistributing static routes. So although as stub EIGRP router will not advertise networks behind it, static routing may be configured and redistributed into EIGRP on other routers that will direct transit traffic to that stub router, thus essentially establishing transit traffic through a stub network.
I hope this has been helpful!
Laz
Hi,
In this lesson, When you configure default stub behaviour and shut down loopback0 in R2 ,
how R1 knows that 2.2.2.0 has gone and sends query? Shouldn’t R2 tell this to R1 beforehand?