Route flapping OSPF EIGRP redistribution

[jerem38]

Hello all,

I'm facing a route flapping issue, on a setup with redistribution.

We have OSPF running in the HQ
EIGRP running on the WAN, on top of a DMVPN setup
We have an other OSPF instance running at the partner side.

As we have 2 points of redistribution, I've implemented route tags to prevent routing loops.
From HQ to DMVPN : tag 10128
From DMVPM to HQ : tag 10

From partner to DMVPN : tag 1018
From DMVPN to partner : tag 10

The routing is not stable.
On hq-br1, routing to the partner is flapping :

hq-br1#sh ip route 10.18.113.0
Routing entry for 10.18.113.0/24
  Known via "eigrp 400", distance 170, metric 56325120
  Tag 1018, type external
  Redistributing via nhrp, eigrp 400, ospf 500
  Advertised by ospf 500 subnets route-map EIGRP-TO-OSPF
  Last update from 100.64.128.15 on Tunnel10, 00:00:04 ago
  Routing Descriptor Blocks:
  * 100.64.128.15, from 100.64.128.15, 00:00:04 ago, via Tunnel10
      Route metric is 56325120, traffic share count is 1
      Total delay is 110000 microseconds, minimum bandwidth is 1000000 Kbit
      Reliability 255/255, minimum MTU 1400 bytes
      Loading 41/255, Hops 1
      Route tag 1018
hq-br1#sh ip route 10.18.113.0
Routing entry for 10.18.113.0/24
  Known via "ospf 500", distance 110, metric 2005
  Tag 10, type extern 1
  Redistributing via nhrp, eigrp 400
  Last update from 192.168.252.109 on Port-channel2.140, 00:00:00 ago
  Routing Descriptor Blocks:
  * 192.168.252.109, from 192.168.253.15, 00:00:00 ago, via Port-channel2.140
      Route metric is 2005, traffic share count is 1
      Route tag 10

I would expect hq-br1 to always send the traffic to the DMVPN when all connections are up, but:
hq-br1 knows the destination via EIGRP with AD of 170
hq-br1 knows the destination via hq-br2 with AD of 110

The route is flapping in the routing table for like 15 mins.
Then it gets stable.

If I reload a partner router, it starts to flap again.

Partner is using ISR4000 with IOS-XE 16.9
HQ is using ASR with IOS-XE 16.3

Any clue?

thanks,
Jeremie

[Georg Pauwen]

Hello,

post the full configs of all 4 routers so we can lab this.

[Giuseppe Larosa]

Hello @jerem38 ,

your network scenario is quite complex.

However, the root cause of your issues is that the ASBR routers are two and that EIGRP AD for external routes is 170 when default AD for OSPF external routes is 110.

As a result of this each hq-brx router alternatively learns the EIGRP D EX route from DMVPN ( this is wanted) or the OSPF injected external route with tag 10 from the other ASBR because of the lower AD.

A possible workaround is to use the distance ospf command that allows to modify the AD values for intra area. inter -area and external OSPF routes.

So if on both routers hq-brx   x=1, 2

router ospf 500

distance ospf 110 110 180

This would make from the point of view of each ASBR the OSPF external routes less preferred then EIGRP D EX routes.

Warning: I'm not sure that this workaround can work for your network as this increase in AD will apply to all OSPF external routes not only those coming via EIGRP from DMVPN with route tag 10.

as an alternative for a more granular action you could use the distance command.

as explained here

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_pi/command/iri-cr-book/iri-cr-a1.html#wp2727786660

in the case of OSPF you should specify the OSPF RID of the other border router hq-bry.

router ospf 500

distance 180 <OSPF-RID-other-hq-br> 0.0.0.0

Unfortunately is not possible to change the AD with a route-map using a match route tag 10.

Hope to help

Giuseppe

[jerem38]

Hello Giuseppe,

yes, this is the point.

The AD of external EIGRP should be prefered over the OSPF one.

I noticed that if I put a summary route on the partner routers, which is advertized with an AD of 90, the routing is stable.

However I have some routes I cannot summarized, so this work arround is not a solution.

I think I have no choice but tweaking the AD. Will try your recommandations.

I will try to lab this ASAP ; and post the router's config.

thanks for your advice,

Jeremie

[jerem38]

Hi all,

I managed to lab the design with CSR1000v. Here are the config files : http://137.74.196.165/confs-lab.zip

The lab design is the following:

The routing loop is actually a normal behaviour, as we discussed.

R2 (L0 2.2.2.2) cannot ping R1 (L0 1.1.1.1) due to the loop.

debug ip routing shows the unstable routing on HQ1 for instance.

What is weird is with IOS-XE 16.3.5 we do notice the routing loop ; but with IOS-XE 16.9.5 the routing does converge, and R2 can ping R1. In this case HQ1 route 1.1.1.1 to HQ2 over OSPF, and HQ2 route 1.1.1.1 to the WAN, for any reason...

I'm trying to understand if Cisco fix something in the latest OS or... if the routing loop could come back without any filtering.

Regarding the solutions, tweaking the AD is an option, but it could be dangerous as I do have other EIGRP external routes.

In the book "CCNP Enterprise Advanced Routing ENARSI 300-410 Official Cert Guide", they talk about this looping behaviour in the "troubleshooting redistribution" chapter.

They suggest, as a second possibility, to filter the OSPF route learnt from HQ routers, using a distribute-list :

ip prefix-list PREFER_EIGRP seq 10 deny 1.1.1.1/32
ip prefix-list PREFER_EIGRP seq 20 permit 0.0.0.0/0 le 32
router ospf 100
 distribute-list prefix PREFER_EIGRP in

This is interesting, and it works in the lab. But it requires to filter plenty routes in production, and it is hard to maintain  :/

Jeremie

[paul driver]

Hello
Just like to add due to the mutual redistribution and multiple redistribution points are you negating correctly at both redistribution points any possible chance of the original prefixes being advertised back into their original routing domains.

Example:
route-map OSPFintoEIGRP deny 10
match tag 170

route-map OSPFintoEIGRP pemrit 99
set tag 110

route-map EIGRPintoOSPF deny 10
match tag 110

route-map EIGRPintoOSPF pemrit 99
set tag 170

[jerem38]

Hi Paul,

Thanks. Yes, I did implement the filters with tags, as you can see in the configs. The loop in fix!

What I try to understand is why routing converges in 16.9, with a route from EIGRP EX (AD170) prefered over the OSPF one (AD110).

This is not the case in 16.3

I've opened a TAC case to get more information about this.

Regards,

Jeremie