RIP - > OSPF redistribution issues with flapping routes

[switched switch]

Hi All,

Doing some testing tonight and having issues with route redistirbution between RIP and OSPF. In the example, R1 R3 and R4 are running RIP. Routers R5 R3 and D4 are running OSPF.

R3 and R4 are running HSRP on the RIP side, acting as failover for the R2 node.

There is redistribution on R3 from RIP into OSPF, and also on R4 there is RIP into OSPF redistribution.

What I see is that the 192.168.1.0, 192.168.2.0, and 192.168.3.0 keeps getting added and removed from the routing table of R5 and the route is flapping. R5 doesnt have a stable route. It flaps via R3 and then via R4.

Please see configs below. What am I missing to allow HSRP to failover and support the RIP to OSPF redistribution?

*Feb 9 21:39:39.027: RT: del 10.10.10.0 via 10.10.13.1, ospf metric [110/1]
*Feb 9 21:39:39.027: RT: delete subnet route to 10.10.10.0/30
*Feb 9 21:39:39.043: RT: updating ospf 192.168.1.0/24 (0x0) via 10.10.12.1 Fa0/0.10
*Feb 9 21:39:39.047: RT: del 192.168.1.0/24 via 10.10.13.1, ospf metric [110/1]
*Feb 9 21:39:39.047: RT: add 192.168.1.0/24 via 10.10.12.1, ospf metric [110/10]
*Feb 9 21:39:39.051: RT: updating ospf 192.168.2.0/24 (0x0) via 10.10.12.1 Fa0/0.10
*Feb 9 21:39:39.051: RT: del 192.168.2.0/24 via 10.10.13.1, ospf metric [110/1]
*Feb 9 21:39:39.055: RT: add 192.168.2.0/24 via 10.10.12.1, ospf metric [110/10]
*Feb 9 21:39:39.055: RT: 
R5#debug ip routingupdating ospf 192.168.3.0/24 (0x0) via 10.10.12.1 Fa0/0.10
*Feb 9 21:39:39.059: RT: del 192.168.3.0/24 via 10.10.13.1, ospf metric [110/1]
*Feb 9 21:39:39.059: RT: add 192.168.3.0/24 via 10.10.12.1, ospf metric [110/10]
*Feb 9 21:39:39.075: RT: del 192.168.1.0 via 10.10.12.1, ospf metric [110/10]
*Feb 9 21:39:39.075: RT: delete network route to 192.168.1.0/24
*Feb 9 21:39:39.075: RT: del 192.168.2.0 via 10.10.12.1, ospf metric [110/10]
*Feb 9 21:39:39.075: RT: delete network route to 192.168.2.0/24
*Feb 9 21:39:39.075: RT: del 192.168.3.0 via 10.10.12.1, ospf metric [110/10]
*Feb 9 21:39:39.075: RT: delete network route to 192.168.3.0/24
R5#debug ip routing
*Feb 9 21:40:00.203: RT: updating ospf 10.10.10.0/30 (0x0) via 10.10.13.1 Fa0/0.5
*Feb 9 21:40:00.203: RT: add 10.10.10.0/30 via 10.10.13.1, ospf metric [110/1]
*Feb 9 21:40:00.243: RT: updating ospf 192.168.1.0/24 (0x0) via 10.10.13.1 Fa0/0.5
*Feb 9 21:40:00.247: RT: add 192.168.1.0/24 via 10.10.13.1, ospf metric [110/1]
*Feb 9 21:40:00.247: RT: updating ospf 192.168.2.0/24 (0x0) via 10.10.13.1 Fa0/0.5
*Feb 9 21:40:00.251: RT: add 192.168.2.0/24 via 10.10.13.1, ospf metric [110/1]
*Feb 9 21:40:00.251: RT: updating ospf 192.168.3.0/24 (0x0) via 10.10.13.1 Fa0/0.5
*Feb 9 21:40:00.255: RT: add 192.168.3.0/24 via 10.10.13.1, ospf metric [110/1]
R5#debug ip routing
*Feb 9 21:40:05.243: RT: del 10.10.10.0 via 10.10.13.1, ospf metric [110/1]
*Feb 9 21:40:05.243: RT: delete subnet route to 10.10.10.0/30
*Feb 9 21:40:05.275: RT: del 192.168.1.0 via 10.10.13.1, ospf metric [110/1]
*Feb 9 21:40:05.275: RT: delete network route to 192.168.1.0/24
*Feb 9 21:40:05.275: RT: del 192.168.2.0 via 10.10.13.1, ospf metric [110/1]
*Feb 9 21:40:05.275: RT: delete network route to 192.168.2.0/24
*Feb 9 21:40:05.275: RT: del 192.168.3.0 via 10.10.13.1, ospf metric [110/1]
*Feb 9 21:40:05.275: RT: delete network route to 192.168.3.0/24
R3#u all

R1 Config:

!
interface Loopback1
 ip address 192.168.1.1 255.255.255.0
 !
!
interface Loopback2
 ip address 192.168.2.1 255.255.255.0
 !
!
interface Loopback10
 ip address 192.168.3.1 255.255.255.0
 !
!
interface FastEthernet0/0
 ip address 10.10.10.1 255.255.255.252
 duplex auto
 speed auto
 ! 
router rip
 version 2
 network 10.0.0.0
 network 192.168.1.0
 network 192.168.2.0
 network 192.168.3.0
!

R2 Config:

interface FastEthernet0/0
 ip address 10.10.10.2 255.255.255.252
 duplex auto
 speed auto
 !
!
interface FastEthernet0/1
 ip address 10.10.11.1 255.255.255.0
 duplex auto
 speed auto
 !
!
router rip
 version 2
 network 10.0.0.0

R3:

interface FastEthernet0/0
 ip address 10.10.11.3 255.255.255.0
 duplex auto
 speed auto
 standby version 2
 standby 1 ip 10.10.11.2
 !
!
interface FastEthernet0/1
 ip address 10.10.13.1 255.255.255.0
 ip ospf 1 area 0
 duplex auto
 speed auto
 !
!
router ospf 1
 log-adjacency-changes
 redistribute rip metric 1 subnets route-map rip_into_ospf
!
router rip
 version 2
 passive-interface default
 no passive-interface FastEthernet0/0
 network 10.0.0.0
 no auto-summary

ip prefix-list rip_into_ospf seq 5 permit 9.9.9.9/32

route-map rip_into_ospf deny 10
 match ip address prefix-list rip_into_ospf
!
route-map rip_into_ospf permit 20
!

R4:

interface FastEthernet0/0
 ip address 10.10.11.4 255.255.255.0
 duplex auto
 speed auto
 standby version 2
 standby 1 ip 10.10.11.2
 !
!
interface FastEthernet0/1
 ip address 10.10.12.1 255.255.255.0
 ip ospf 1 area 0
 duplex auto
 speed auto
 !
!
router ospf 1
 log-adjacency-changes
 redistribute rip metric 10 subnets route-map rip_into_ospf
!
router rip
 version 2
 passive-interface default
 no passive-interface FastEthernet0/0
 network 10.0.0.0
 no auto-summary
! 
ip prefix-list rip_into_ospf seq 5 permit 9.9.9.9/32

route-map rip_into_ospf deny 10
 match ip address prefix-list rip_into_ospf
!
route-map rip_into_ospf permit 20

R5:

interface FastEthernet0/0.5
 encapsulation dot1Q 5
 ip address 10.10.13.2 255.255.255.0
 ip ospf 1 area 0
!
interface FastEthernet0/0.10
 encapsulation dot1Q 10
 ip address 10.10.12.2 255.255.255.0
 ip ospf 1 area 0
!

[paul driver]

Hello
Mutual redistribution can cause looping if you not careful due to the traffic you originally advertised being reintroduced, So Its best to negate such issues arising by tagging your redistributed traffic.

Example:

route-map Rip-into-Ospf deny 10
match tag 110
route-map Rip-into-Ospf permit 99
set tag 120

route-map Ospf-into-Rip deny 10
match tag 120
route-map Ospf-into-Rip permit 99
set tag 110

router ospf x
redistribute rip subnets route-map Rip-into-Ospf

router rip
redistribute ospf 1 route-map Ospf-into-Rip metric 5

res
Paul

[switched switch]

Hi Paul,

Thanks for the reply. In the above case there is no two-way redistribution. We are only redistributing RIP into OSPF.

the RIP network is a stub network, it is a replica of an existing network and the RIP networks essentially get to R3 and R4. In the example I have R1 listed, but in reality R1 doesnt exist - R2 has RIP routes off it directly.

Therefore there is only one path out of the network, and that is via R3/R4 and out to R5 when the rest of the production network resides.

The issue appears to be that BOTH R3 and R4 both are taking the RIP learnt routes from R1/R2 and redistributing them into OSPF, and R5 is flapping the redistributed between the path via R3 and R4.

What I am trying to achieve, is have R3 and R4 in HSRP with RIP redistribution on both, such that R3 and R4 can be failed over.

[willwetherman · Accepted solution]

Hi,

When you redistribute RIP into OSPF on R3, the native RIP routes will be preferred in OSPF on R4 as the AD of OSPF (110) is lower than that of RIP (120). Note that it may be the opposite with the native RIP routes preferred in OSPF on R3 if R4 redistributed the RIP routes first. This will result in inefficient routing.  

Let’s say that R3 redistributed the RIP routes into OSPF first which means that R4 will prefer the native RIP routes in OSPF with an AD of 110. For R4 to reach 192.168.1.1 it will take the path R5 -> R3 -> R2 -> R1. Although the result of this is not ideal, and something that is advisable to fix, the topology should stabilise and you shouldn’t see the route flapping that you are observing on R5.

To try and identify the cause of the issue, can you first try and configure RIP with a lower AD on R3 and R4? This will ensure that R3 and R4 always prefer the RIP routes advertised by R2 and not via OSPF.

On R3 and R4 configure the following

router rip
 distance 109

Edit: Actually I have just thought and it’s very possible that R3 and R4 both learn the RIP routes from R2 and redistribute them into OSPF at the exact same time. The result would be that R3 and R4 would learn the RIP routes via OSPF at the same time and erasing the original RIP routes from the routing tables. As the RIP routes are flushed, so will the routes that are redistributed into OSPF. The process continues and will result in the flaps that you are observing. The suggested configuration above should fix the issue.

[switched switch]

Thanks for your reply.

You are correct, R3 and R4 were seeing the path via OSPF path through R5 - this is what i recall from memory.

I believe you are right and that it was a race condition to enter the routes into OSPF.

For some reason I would have assumed that the difference in redistribution costs would not make this an issue, i.e. R3 has lower redistribution than R4.As it turns out it was preferring the path via the alternate router.

I have changed the distance to 109 on R3 and R4 and so far, everything is stable - no issues. I will keep testing and give you an update.

Thanks to everyone for responding

[willwetherman · Accepted solution]

Yes please let me know how you get on. I'm deep into studying redistribution issues at the moment so I'm interested to know the final outcome :-)

Also please mark the answer as correct and rate if it has helped you. This will allow others to find this solution if they have had a similar issue.

Thanks

[switched switch]

marking as correct as no issues since the changes applied.

Just confirming - is this the only way to tackle it? I was thinking we could apply a filter as well to filter the inbound routes maybe on each router? Maybe another way to address the issue you are aware of?

[willwetherman]

Yes there are a few ways to tackle this

1) Change the RIP AD to be lower than OSPF as we have already tested.

2) Change the OSPF External AD to be higher than RIP. On R3 and R4 configure the following:

router ospf 1

 distance ospf external 121

3) Tag the RIP routes when redistributing into OSFP and then filter inbound in OSPF on R3 and R4.

On R3 and R4 configure the following:

router ospf 1

 r

edistribute rip subnets route-map RIP->OSPF
 distribute-list route-map FILTER in

!

route-map RIP->OSPF permit 10
 set tag 120
!
route-map FILTER deny 10
 match tag 120
!
route-map FILTER permit 20

[paul driver]

Hello

Glad to gear you have sorted the flapping issue out by decreasing the RIP AD to be lower than opsf - However..

trying to achieve, is have R3 and R4 in HSRP with RIP redistribution on both, such that R3 and R4 can be failed over.

Without a interconnect between R4/R5 in ospf and also adverting the ospf  routes into rip  you will end up having R5 as transit rtr and also the rip routers wont see any subnets advertised from ospf apart from the connected routes.-

So I guess some sort advertisement between the routing processes either by mutual redistribution or static routing needs to be done eventually - Now when this is done and with the rip AD being decreased the advertised opsf routes into rip will be seen by R3/R4 as rip routes and not ospf.

So with your current design it is possible you could with an additional ospf interconnect between R3/R4 negate the flapping issue and eventually perform mutual redistribution (with tagging) without even decreasing the AD of rip and have resiliency also.

res
Paul

[paul driver]

Hello 

Can you try changing the redistribution of the preferred path with a metric-type 1 and the less preferred default to metric-type 2

example:

redistribute rip subnets route-map xxx metric-type 1

res

paul

[switched switch]

Hi Paul.,

Thanks - I originally had the redistribution as metric-type 1 and no good. Tried changing to metric-type 2 and no change.