Cisco Support Community
Showing results for 
Search instead for 
Did you mean: 

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

EIGRP route filtering via tagging

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.

New Member

Re: EIGRP route filtering via tagging

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.

Re: EIGRP route filtering via tagging

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:

Best Regards.

New Member

Re: EIGRP route filtering via tagging

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.

New Member

Re: EIGRP route filtering via tagging

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.


Re: EIGRP route filtering via tagging

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.