do distribute-lists have a similar function to a stub configuration ?

[Reprovoid]

  HI.

   I was wondering how much overlap there Is between configuring a router as a stub and using a distribute-list.Are there cases where a stub configuration can perform the same function as a distribute-list?

[Edison Ortiz · Accepted solution]

Are we talking about EIGRP or OSPF as the stub function on either protocol varies.

With that said, stub performs global filtering (all or nothing) while distribute-list you have a greater control of traffic being filtered. Also note; distribute-list is basically useless in OSPF since you can't filter LSA which such command.

[Reprovoid]

Hi.

Thank you!That's basically what I wanted to know.I was referring to EIGRP yes.

[Peter Paluch · Accepted solution]

Hello,

Principially, EIGRP Stub is a different mechanism than a distribute list. You could construct a distribute list that resembles the effects of EIGRP Stub but their underlying logic is different:

• An EIGRP stub router informs its neighbors about its stub status. As a result, neighbors will never send a query to a stub router. This functionality can not be replicated by distribute lists.
• Even if an EIGRP stub router receives a query, it immediately responds with infinite metric, without forwarding the query further. Distribute lists are somewhat more complex in this aspect. An inbound distribute list does not modify the processing of an incoming query or replying to it, i.e. the received query is propagated further according to normal rules (at least according to my short experiments - anyone feel welcome to correct me here!). An outbound distribute list causes the query for the denied network to be processed normally and forwarded further if necessary but the reply will always contain an infinite metric. Read more about the process here. The net result is that distribute lists do not decrease the query propagation depth.
• An EIGRP stub router never advertises routes it learned itself via EIGRP. This behavior can be achieved with a distribute list provided that you know the addresses of EIGRP-learned routes.

So with respect to filtering routes, yes, distribute lists can be tweaked to allow advertising precisely the same set of routes as would be, in a given situation, advertised by an EIGRP stub router. However, there is more to the EIGRP Stub functionality that distribute lists cannot cover.

Best regards,

Peter

[Reprovoid]

Hi.

Thanks.That makes things clearer !

[dslice]

One very minor correction to what Peter said. It's not really that important, but I thought Peter would appreciate the true implementation.

"Even if an EIGRP stub router receives a query, it immediately responds with infinite metric, without forwarding the query further"

This isn't actually right. An EIGRP stub router doesn't modify his own behavior as far as Queries and Replies are concerned. If he were to receive a Query and both had the prefix and didn't have a successor/feasible successor, he would send a Query to any non-stub peers. The power of stub comes from the fact that the majority of the time he will never receive the Query in the first place. Peter was absolutely correct in that regard.

Extra credit to whoever knows when it's appropriate for a stub router to receive a Query. :^)

Sent from Cisco Technical Support iPad App

[Peter Paluch]

Hello Don,

 It's not really that important, but I thought Peter would appreciate the true implementation.

You bet I do! Thank you VERY much!

What you wrote is actually very interesting. It tends to slightly contradict this document:

http://www.cisco.com/en/US/technologies/tk648/tk365/technologies_white_paper0900aecd8023df6f.html

It particularly says: "If an older version of code is deployed on the hub  router, it will ignore the stub TLV and continue to send QUERY packets  to the stub router. However, the stub router will immediately reply  "inaccessible" to any QUERY packets, and will not continue to propagate  them."

So you are saying that this is not exactly right?

Extra credit to whoever knows when it's appropriate for a stub router to receive a Query. :^)

I would think of the following scenarios:

• Older EIGRP peer not recognizing the stub TLV
• In case of dual spoke branches when using leak-map to allow branch spokes to mutually advertise appropriate EIGRP-learned networks WRONG: These routers would recognize themselves as stubs and would never send Queries to each other.
• I am not sure about having stub and non-stub routers on a common multiaccess segment (so far, documentation indicates that this is not supported but what exactly "unsupported" means here? )

Do I miss anything?

Best regards,

Peter

[dslice · Accepted solution]

It particularly says: "If an older version of code is deployed on the hub  router, it will ignore the stub TLV and continue to send QUERY packets  to the stub router. However, the stub router will immediately reply  "inaccessible" to any QUERY packets, and will not continue to propagate  them."

So you are saying that this is not exactly right?

This is probably referring to the "normal" stub use which also includes summarization from the hub to the spoke.  When someone implements stub in a hub and spoke environment, there is almost never a reason to send many of the prefixes to the spoke and summarization is used in order to limit the knowledge of the specific routes.  In that case, the statement above is true.  This, of course, has nothing directly to do with it being defined as a stub.  :-)  There is nothing inherent to Stub behavior that makes it Reply any differently if it has knowledge.  I could argue that we could have made this change as well, since a Reply doesn't really make sense in most cases, but that's not what we did.

• Older EIGRP peer not recognizing the stub TLV
  • True
• In case of dual spoke branches when using leak-map to allow branch spokes to mutually advertise appropriate EIGRP-learned networks WRONG: These routers would recognize themselves as stubs and would never send Queries to each other.
  • Strangely enough, this is the case I was referring to.  We put a check that if all peers on that interface are stub (including the router making the decision) and leaking is in place, let the Query fly.  That's the only way we could converge to a prefix learned through the other "leaking" router.
• I am not sure about having stub and non-stub routers on a common multiaccess segment (so far, documentation indicates that this is not supported but what exactly "unsupported" means here?
  • This was implemented using the sequence TLV and conditional receive to send a Query to a subset of peers.  Of course you could say that this meets the criteria of receiving the Query but then it discards it because it is told to based on the CR bit.

Nice work!

[Giuseppe Larosa]

Hello Donald, Peter

thanks for providing  deeper information about the EIGRP stub feature.

The way the feature is usually described leads to think of a stub router answering to a query with a reply with infinite metric as suggested by Peter.

Rated as it deserves.

Best Regards

Giuseppe

[Peter Paluch]

Hello Don,

This is awesome! Rated as deserved - huge thanks!

Best regards,

Peter