EIGRP on ASR1000 has conflict between Distribute-List Route-map out and offset-list out

cedar_lee · ‎01-02-2015

Hi,

What we want to accomplish here is, on the same route,

1. Set a route tag and get it advertised out by EIGRP from two interfaces

2. The routes advertised out by EIGRP from the two interfaces need to have different metrics

We have successfully achieved this goal on ISR 2900 routers with IOS 15.1(4)M code. However, same configuration does not work for ISR 2900 with other IOS versions and ASR 1000 with any IOS-XE version either.

Please see the following for the configuration we have.

router eigrp 4
...........
distribute-list route-map rmap-routefilter-and-settag out Tunnel41
distribute-list route-map rmap-routefilter-and-settag out Tunnel42
...........
offset-list acl-offset-tun42 out 768000 Tunnel42
..........
!
route-map rmap-routefilter-and-settag permit 10
match ip address prefix-list-any
set tag 41
!

ip access-list standard acl-offset-tun42

permit any

!

We found out a bug CSCur22501 saying that EIGRP metric is not changed via an offset-list when a distribute-list is present for those routes.

And we verified what it says is true. Offset-list worked after Distribute-list got removed.

After tried many different versions of IOS-XE and different EIGRP mode (classic mode and name mode), I lost the hope that Cisco has any IOS-XE with this bug fixed.

Alternatively, I am looking for any other configuration that could achieve the same goal.

Please let me know if you have any good advice. Appreciate it!

Cedar

Peter Paluch · ‎01-02-2015

Hi Cedar,

It seems that there is currently no workaround for this bug. However, you are trying to combine both the distribute-list and offset-list on the same router toward a particular neighbor over a tunnel interface. Do you think it would be possible to let one of the routers do the distribute-list and the other do the offset-list? Assuming this is a point-to-point GRE tunnel, it should be fairly easy to do the distribute-list on one router at one end of the tunnel, and the offset-list on the router at the other tunnel end. While the configuration would not be as neatly placed on one router only, it would at least accomplish your needs.

Best regards,
Peter

cedar_lee · ‎01-05-2015

Hi Peter,

Thanks for your reply.

The configuration is on a spoke router of DMVPN. The idea is to let the spoke sites to control the EIGRP routing path preferences so that the goal of zero touch on the hubs when adding new spokes can be achieved.

I did try to remove the offset-list and add a set metric command to the route-map. However, it set either tag or metric but not both at the same time.

route-map rmap-routefilter-and-settag permit 10
match ip address prefix-list-any
set tag 41

route-map rmap-routefilter-and-settag permit 20
match ip address prefix-list-any
set metric 1000000 100000 255 1 1500

Look forward to hear any other suggestions.

Thanks

Cedar

Peter Paluch · ‎01-05-2015

Cedar,

It seems that the route-map was not configured properly. You have configured the route-map with two blocks but similar to an ACL, in a route-map, the first match is always used and the evaluation of the route-map then stops. Correctly, the route-map should have just a single block and use both set commands in the same block, like this:

route-map rmap-routefilter-and-settag permit 10
 match ip address prefix-list-any
 set tag 41
 set metric 1000000 100000 255 1 1500

Can you please try this out?

Best regards,
Peter

cedar_lee · ‎01-06-2015

We did try both but neither was working. It seems like route-map will allow to set either tag or metric but not both at the same time.

Thanks,

Cedar

Peter Paluch · ‎01-06-2015

Cedar,

Okay. Let's try it differently...

Are the networks to be advertised capable of summarization? If so, you could advertise them out one Tunnel interface as non-summarized (that is, more specific), while out the other interface, you would summarize them. Because of longest prefix match, the path toward the more specific networks would always be preferred, and if they stopped to be advertised, the path toward the summary would be used. This way, you could do away with the metric manipulation - provided, however, that you can afford configuring the summary.

Would this work for you?

Best regards,
Peter

cedar_lee · ‎01-07-2015

Hi Peter,

We do want route summarization from spokes on all DMVPN tunnels.

I found another workaround. It's the similar idea as you mentioned earlier by removing the offset-list out commands from the spokes and adding match tag and set metric in commands to the hubs. In order to do that, I need to set multiple tags for different routes on the same tunnel of the same spoke router, which was not allowed by route-map with match prefix-list commands. After used match access-list commands in route-map, I am able to set multiple tags on the same tunnel interface.

Thanks for the ideas.

Cedar