×

Warning message

  • Cisco Support Forums is in Read Only mode while the site is being migrated.
  • Cisco Support Forums is in Read Only mode while the site is being migrated.

EIGRP Stub Feature

Answered Question
Jun 30th, 2003
User Badges:

Hello all :)


I have a stub router that has one LAN, connected back to the HQ and world network via a serial line and ISDN. I have two options for the routing table on the stub router :-

eigrp stub routing or a default network static route with floating over the ISDN.


If I use eigrp stub, you still have to summarise on the HQ router's serial interface a default route correct as eigrp stub routing does not stop routes from passing over to the stub router.


Is this correct? if so, and i put an eigrp summary route on the serial in HQ, this would create a default route to null0. if I have a GOLR, this is not a good idea?


Is this correct?



Correct Answer by ruwhite about 14 years 1 month ago

No, that isn't true... Think of your typical dual homed remote router:


A---B---C---D


Assume that C is the remote router, B and D are the distribution (hub) routers, and A is some other router in the core of the network. Assume the links between B and C and D and C are low speed "dirty" links. A also has some link to D, so it's not really a straight line like this, but it's hard to draw using ascii here. :-)


What would normally happen when A loses its route to some destination, say a locally configured loopback? It would send a query to B, which would then send a query to C, and C would then send a query to D. If the two links to C are low speed dirty links, A would be waiting on the query from B to C, then on the query from C to D, to clear its active state.


However, if C is a stub, B will simply not send this query--it will reply to A's query stating it has no other way to reach the destination which has disappeared. Once A has received this reply, it will send a following update telling B that it has lost reachability to this destination. B will then send an update to C with this information, as well.


Now, let's look at what happens at C. The remote router may or may not have an alternate route to this loopback on A. Suppose it doesn't--it knows about D, but it doesn't know that the loopback on A is reachable through that neighbor. If the link from A to B has failed, rather than the loopback failing on A, then how would C ever know about this reachability? It has to send a query to D to find out if there is an alternate path.


By the way, the odds of C not knowing about an alternate path through D to A's loopback are pretty slim.... Split horizon is the primary reason that any router in an eigrp network doesn't know about some alternate path, and in this situation, if C is a stub, it will never advertise A's loopback to D, so D would never split horizon an advertisement for A's loopback to C (!). The only other options would be summarization at D towards C, in which case any query C sends to D is going to have a reply of not reachable this direction, or filtering at D towards C, which will have the same result. The only reason you're seeing the query here is because there is no alternate path.


Anyway, this is the query you are seeing. But go back to how stubs work, and consider this: Stubs can never be transits. So, D could not have ever heard about A's loopback through C, correct? Therefore, C couldn't have ever been a valid path to A's loopback at D. When you consider this, you realize that D could never go active because of this query from C. Either D is already active, looking for another path to A's loopback, in which case it will hold on to C's query until it receives the other responses it is waiting on (but it will never wait on a response from C), or it will know a good alternate path, and answer immediately, or it will not know about the destination at all, and will answer immediately.


In short, there's no way for D to go stuck in active waiting on C, and the dirty/slow C to D link, under any circumstances. The query is there, from C to D, and C could go stuck in active waiting on D, but this will have little to no impact on the network, since C doesn't transit any traffic between B and D. But it's impossible for the distribution layer to be impacted through a stuck in active because of problems at C.


I know it's complicated, it took us a lot of hours on the whiteboard to go through all of the situations, and decide to leave the stub to distribution queries in. In the lab, we see stubs allowing a router to have just about four times as many neighbors on a single link in most situations, and when stubs were introduced, the sia calls into tac fell considerably. With the sia rewrite rolling out, it's actually rare to see tac cases on sia's any longer.


Hope that helps.... If I can ever get my butt in gear on the eigrp white paper rewrite, I'll make certain this is all explained with real diagrams there.


Russ.W

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
thisisshanky Mon, 06/30/2003 - 08:16
User Badges:
  • Purple, 4500 points or more

You can use a distribute list and and access list configuration to filter out all routes, except a default route to the remote.


If you put a summary route on the serial, EIGRP automatically creates the same summary route, pointed to null 0. This is to route all packets to a pit bucket (thrash the packets), in case the packet is destined for a network X, which is specific network within the summary, and that network X is down, and not present in the routing table.


EIGRP doesnt create a route pointing to null 0 in case of a GOLR injection to remote.

ruwhite Mon, 06/30/2003 - 09:35
User Badges:
  • Gold, 750 points or more

No, EIGRP stub will not autogenerate the default, or any other route, and push it towards the stub router. You can use a summary route to generate a default towards the stub, but you will have to watch out for the discard route (the route to null 0 your post and the first response talks about) overriding other legitimate routes in your network.


Another option would be to configure a floating static route for 0/0 to null0, and redistribute this to the remotes only. You could then build a distribution list so the remotes will only receive a 0/0; the normal defualt would be advertised to them if it exists, but the locally configured static would be redistributed to them otherwise.


Finally, you could use some summary that covers all of your internal networks, but is not a default route. This would allow you to advertise a single summary for all of your internal networks, and a default learned from some other source.


Hope this helps.


Russ.W

kfarrington Mon, 06/30/2003 - 23:54
User Badges:

Many thx to both of you for your responses.


So if I have a gateway of last resort route on the router pointing towards the GOLR, and this is a valid route, I cannot generate a


ip summary-address eigrp 1 0.0.0.0 0.0.0.0


on an interface facing the stub as this will create a route to null0 and override the GOLR. so rather than packets that should go to the GOLR, ie internet packets, these packets would get binned.



If this is the case, rather than eigrp stub routing, a default route on the stub network would be the best solution, and just have a static on the non-stub (ie distribution) back to the stub router LAN.


Please can you advise one more time :))


Regards,

Ken


ruwhite Tue, 07/01/2003 - 04:33
User Badges:
  • Gold, 750 points or more

The stub feature is not designed to solve the problem of making certain you always have the right routing information on the stub remote router.... Instead, the eigrp stub feature is meant to enhance network stability by decreasing query range through the network, and improve convergence times. So, you should use the stub feature for remote routers regardless of what solution you choose to providing routing information to those stub routers.


There are three ways you can provide the default route to the remote stub routers:


-- Use a summary configured at the distribution layer router to provide the default. This will override any locally learned default routes on the distribution router, however, causing problems.


-- Use a floating static for 0/0 to null0 on the distribution router, and then use a distribution list to block all but the 0/0 out to the remote stub router, and another distirbution list to block the 0/0 from making it back into the core of your network.


-- Configure floating statics on the remote router, pointing back towards the distribution routers. These the floating statics will take over if you lose the 0/0 being advertised by the distribution routers.


Russ.W

jawad1979 Tue, 07/01/2003 - 05:43
User Badges:

EIGRP will not generate a summary route unless it finds an entry in the routing table that match the summary, the automatic creation of Null0 route with administrative distance of 5 can override default routes (on the summarizing router). The problem is that "ip summary-address eigrp x 0.0.0.0 0.0.0.0" command will search for any route with 0.0.0.0 but it will find NONE even though you have manually entered the default route. Why??????

Because this route is not a part of the eigrp process, it is a static route and it will not be advertised unless redistribution (as the Cisco Systems guy wrote) or the network 0.0.0.0 0.0.0.0 of the eigrp process are present. Usually, you summarize subnets, but not a default route!! you can also use stub commands. But why? Probably just to decrease the chain of queries generated by the eigrp process as much as possible to improve the convergence time and the stability of the network. But what I really can not understand is, why would the router at the HQ send a default route if your router isn't really a stub with one exit interface? If you don't have an authority on it, then you can filter the default routes out, or even, turn off the eigrp process, remember, you have only one LAN :)


Good Luck

kfarrington Tue, 07/01/2003 - 05:55
User Badges:

Hi there. Sorry, more clarification :)


The HQ router has an EIGRP derived GOLR with an admin dist of 170


D*EX 0.0.0.0/0 [170/28672] via x.x.x.x, 3w2d, Vlan807

[170/28672] via y.y.y.y, 3w2d, Vlan707


but I want to summarise a default route to a stub router off this HQ router's serial interface, but i dont want to overwrite the GOLR with a summary route to null0 as this commnad will do


interface s0/0

ip address 1.1.1.1 255.255.255.252

ip summary-address eigrp 1 0.0.0.0 0.0.0.0



Many thx indeed for you response :)

Erick Bergquist Tue, 07/01/2003 - 21:20
User Badges:
  • Silver, 250 points or more

Hello,


If you are using IOS 12.0(4)T or later you can change admin distance on the summary route so it doesn't override the exisiting one you're using.


interface s0/0

ip summary-address eigrp 1 0.0.0.0 0.0.0.0 200


Erick


ruwhite Wed, 07/02/2003 - 03:24
User Badges:
  • Gold, 750 points or more

Yes, you can do this, but it's only useful if the remote stub router is not dual homed. I'll be publishing a tech note on CCO at some point explaining this, probably in the next couple of weeks. I'll try and remember to repply to this thread with a pointer to it when it's published.


Russ.W

kfarrington Fri, 07/04/2003 - 04:17
User Badges:

OK, So I have tested this in my lab at home :)


rtr0------(ethernet)--------rtr1-------(serial)---------rtr2


I have a loopback100 interface on rtr0 and I have eigrp stub running on rtr2.


I shut down lo100 (on rtr0) and I have debug running on rtr2 for eigrp queries and updates.


As you can see, I get an update from my neighbor first, but then the router enqueues a query back over the serial interface. Surely this is not correct? as the whole point is not to rely on a query timeout on the stub router (rtr2)




ccie-rtr2#sh debug

EIGRP:

EIGRP Packets debugging is on

(UPDATE, QUERY)

ccie-rtr2#

ccie-rtr2#

01:40:24: EIGRP: Received UPDATE on Serial0 nbr 192.168.1.225

01:40:24: AS 200, Flags 0x0, Seq 242/111 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/r

ely 0/0

01:40:24: EIGRP: Enqueueing QUERY on Serial0 iidbQ un/rely 0/1 serno 1529-1529

01:40:24: EIGRP: Enqueueing QUERY on Serial0 nbr 192.168.1.225 iidbQ un/rely 0/0

peerQ un/rely 0/0 serno 1529-1529

01:40:24: EIGRP: Sending QUERY on Serial0 nbr 192.168.1.225

01:40:24: AS 200, Flags 0x0, Seq 112/242 idbQ 0/0 iidbQ un/rely 0/0 peerQ un/r

ely 0/1 serno 1529-1529

ccie-rtr2#

ccie-rtr2#

ccie-rtr2#

ccie-rtr2#

ccie-rtr2#


ruwhite Fri, 07/04/2003 - 04:25
User Badges:
  • Gold, 750 points or more

This is the correct behaviour.... Declaring rtr2 as a stub keeps rtr1 from querying it, it doesn't prevent rtr2 from querying rtr1. Otherwise, there would be no way for rtr2 to learn about alternate paths through another upstream if it were dual homed.


The idea behind stub is to keep the distribution layer routers from having to do the work of building and sending all of those queries out to remotes, and to prevent the remotes from becoming transit paths.


:-)


Russ.W

kfarrington Fri, 07/04/2003 - 04:36
User Badges:

Hi Russ,


So the EIGRP Stub function will not reduce the amount of SIAs that could occur, as if a low and saturated link was between the stub and distribution, the remote is going to send a query, possibly not get a reply from the dist router, create an SIA on the remote router and reset the eigrp adj ?


Is that correct? if it is? then I should use a default route on the remote stab router.


I know it's only a small function of eigrp, just want to get it right fella :))


cheers,

Correct Answer
ruwhite Fri, 07/04/2003 - 05:59
User Badges:
  • Gold, 750 points or more

No, that isn't true... Think of your typical dual homed remote router:


A---B---C---D


Assume that C is the remote router, B and D are the distribution (hub) routers, and A is some other router in the core of the network. Assume the links between B and C and D and C are low speed "dirty" links. A also has some link to D, so it's not really a straight line like this, but it's hard to draw using ascii here. :-)


What would normally happen when A loses its route to some destination, say a locally configured loopback? It would send a query to B, which would then send a query to C, and C would then send a query to D. If the two links to C are low speed dirty links, A would be waiting on the query from B to C, then on the query from C to D, to clear its active state.


However, if C is a stub, B will simply not send this query--it will reply to A's query stating it has no other way to reach the destination which has disappeared. Once A has received this reply, it will send a following update telling B that it has lost reachability to this destination. B will then send an update to C with this information, as well.


Now, let's look at what happens at C. The remote router may or may not have an alternate route to this loopback on A. Suppose it doesn't--it knows about D, but it doesn't know that the loopback on A is reachable through that neighbor. If the link from A to B has failed, rather than the loopback failing on A, then how would C ever know about this reachability? It has to send a query to D to find out if there is an alternate path.


By the way, the odds of C not knowing about an alternate path through D to A's loopback are pretty slim.... Split horizon is the primary reason that any router in an eigrp network doesn't know about some alternate path, and in this situation, if C is a stub, it will never advertise A's loopback to D, so D would never split horizon an advertisement for A's loopback to C (!). The only other options would be summarization at D towards C, in which case any query C sends to D is going to have a reply of not reachable this direction, or filtering at D towards C, which will have the same result. The only reason you're seeing the query here is because there is no alternate path.


Anyway, this is the query you are seeing. But go back to how stubs work, and consider this: Stubs can never be transits. So, D could not have ever heard about A's loopback through C, correct? Therefore, C couldn't have ever been a valid path to A's loopback at D. When you consider this, you realize that D could never go active because of this query from C. Either D is already active, looking for another path to A's loopback, in which case it will hold on to C's query until it receives the other responses it is waiting on (but it will never wait on a response from C), or it will know a good alternate path, and answer immediately, or it will not know about the destination at all, and will answer immediately.


In short, there's no way for D to go stuck in active waiting on C, and the dirty/slow C to D link, under any circumstances. The query is there, from C to D, and C could go stuck in active waiting on D, but this will have little to no impact on the network, since C doesn't transit any traffic between B and D. But it's impossible for the distribution layer to be impacted through a stuck in active because of problems at C.


I know it's complicated, it took us a lot of hours on the whiteboard to go through all of the situations, and decide to leave the stub to distribution queries in. In the lab, we see stubs allowing a router to have just about four times as many neighbors on a single link in most situations, and when stubs were introduced, the sia calls into tac fell considerably. With the sia rewrite rolling out, it's actually rare to see tac cases on sia's any longer.


Hope that helps.... If I can ever get my butt in gear on the eigrp white paper rewrite, I'll make certain this is all explained with real diagrams there.


Russ.W

jawad1979 Tue, 07/01/2003 - 06:25
User Badges:

Are you sure that the default route is not already in the routing table of the stub router?

Actions

This Discussion