Failback issue with redistribution in BGP from OSPF

[gruttepier]

I have been banging my head against a routing issue for some days now. I'm probably breaking some basic routing rule, but unable to find which one.

The drawing below is part of a bigger network, but I feel this is a nice balance between keep it readable and enough information. Any questions let me know.

The subnet 10.99.0.0/16 (from further away in the network) enters the OSPF area from two sides; via router B and C. By adding a cost (at router C) one side (via router B) is the preferred side. This works, when route isn't received anymore from the preferred side the traffic goes via the other side. When it is received again the traffic fails back to the preferred side.

Things become interesting when I also redistribute OSPF into BGP at router B and C. This is needed as there is more behind router D which has to be able to reach 10.99.0.0/16 all the way through router C when it can't via the other side.

This works when first configuring, works when the route to 10.99.0.0/16 via router D is lost. The issue occurs when the route to 10.99.0.0/16 via router D is active again.

At this stage the route in the routing table for 10.99.0.0/16 at router B isn't replaced by the one it receives from router D. It keeps the existing OSPF route to router C via router A.

When I look at router B and D they both advertise the 10.99.0.0/16 subnet to each other. Both don't put it in the routing table. Which makes sense for router D, but for router B I don't understand why. The (eBGP) route it learns should be better then the existing OSPF route. But perhaps because router B also announces the route it doesn't update it?

I tried with a static route as a test in router B, there the same thing happened when it redistributed it into BGP. I tried filtering specific prefixes or trying to determine on metric or such. But there issue remains, if i start distributing into BGP then BGP doesn't replace the existing route on router B.

What am I doing wrong here? Is this just a clear no go because of some reason or ...?

[MHM Cisco World · Accepted solution]

cisco list this issue you need to use weight 
https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/213285-understand-the-importance-of-bgp-weight.html

MHM

[gruttepier]

Yes indeed, it felt a little different, but it is the exact issue I run into.

Adding weight on the BGP neighbour configuration for router B and C solves the issue in my lab. Lets hope that the production environment allows for such a weight option also.

Thanks a lot.

[MHM Cisco World]

You are so welcome 
MHM

[paul driver]

Hello
Glad to see you have now got a resolution.
What you experienced is not unusual, this is a well known race condition between an ebgp route and igp redistributed route into bgp, and the reason the redistributed route is preferred is by default a weight 32768 is appended to the redistributed route bgp and an ebgp route doesn't have one, as such when bgp sees the same two prefixes in its routing table, the bgp best path selection process is performed and a prefix with a weight is always preferred over a route without one or with a higher weight value.

[gruttepier]

Thanks Paul, yeah you both saw the issue pretty much instantly showing it is a known thing.

I was unable to find the correct words to search for it. If I now use yours then I find this also: https://blog.ipspace.net/2021/06/interactions-ospf-bgp.html