01-08-2004 06:56 AM - edited 03-02-2019 12:45 PM
We have a a multigiabit core network across 6500s. We have numerous distribution routers that are each connected to two core routers at physically diverse locations. Each DR router connects via a single connection to many access-layer routers. All routing is done via a single EIGRP AS.
The DR routers are learning, via EIGRP, all routes for the enterprise network via both core routers. The DRs are also propagating all routes back out to the both core routers. This creates many additional EIGRP topology table entries for for alternate paths from a core router to a DR router back to the 2nd core router. My core is very redundant and I do not want core traffic to consider bypassing the core and going through a DR to get to another core router. Also, in an error / link flapping situation etc, I am concerned that all of the extra possible paths will cause EIGRP excessive overhead and possible failure to properly recover.
Unfortunately the addressing scheme implemented here over many years, will not permit summarization.
I would love to tag the routes being advertised from the core to the DR routers and then filter any tagged routes from being readvertised back out, from the DR, to the core via it's redundant link. But EIGRP does not support route-maps for distribute lists unless we are redistributing into another routing protocol.
Is there a way to generically filter my core learned routes and still advertise all of my access-layer routes. If EIGRP supported EIGRP to EIGRP route maps / tagging, I could create two generic route-maps (one to tag and one to filter) that could be applied to all DR routers and never be bothered with again. Instead, the only way I can see to do it now is to customize very specific distribute-list ACLs for every DR. This would require modifying these ACLs each time we added or deleted a subnet at any access-layer router. Every DR would have a complex, customized ACL. This is painful and unacceptable. Does anyone have any ideas of a better way to do this? Thanks.
01-09-2004 01:14 AM
Could you just use the delay parameter to increase the EIGRP cost on the DR to core links, so their cost is far greater than the core-core links. Then no traffic should go core-dr-core unless you have a major core failure.
01-09-2004 01:49 AM
Instead of expanding EIGRP AS to access routers you can use static/default routes between access and dist. routers and for dual homed distribution routers EIGRP STUB feature can help you about preventing announcements between core routers through dist routers. This config will help limiting the queries and decreasing SIAs also. For eigrp stub:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/120newft/120t/120t7/fceigrps.htm
Best Regards.
01-09-2004 05:25 AM
Thanks for the reply. The EIGRP stub option works well for the access layer routers, but not for the distribution layer routers. This network is too dynamic and has way too many routes at the access layer routers that must be advertised to the enterprise. Static routing at the DR layer is not an option for us. That eliminates the possibility of the DRs being a stubs.
01-09-2004 05:31 AM
Thanks for the reply. Unfortunately, changing the delay will not make any difference. The Feasible distance is already higher on on the Core-DR-Core redundant uplinks. Our core is redundant enough with multiple, physically diverse paths and redundant HW. We are only trying to eliminate the many hundreds of unnecessary possible paths in the EIGRP topology table to reduce the overhead to EIGRP reconvergence during a network problem situation.
01-09-2004 10:33 AM
There are no internal tags on EIGRP routes at the moment--but it is coming. In fact, it's being coded/tested right now, so it shouldn't be too long at all. They will be similar in style and structure to BGP communities, and will be supported fully in route maps. They will also be used for site of origin information, so we can do back doors between sites communicating over an MPLS cloud and not have problems with various forms of suboptimal routing/etc.
:-)
Russ.W
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide