iBGP route preferred over OSPF, different results with the same setup

[rw13]

Our leaf set up is fairly straight forward. We have two routers at each leaf site for redundancy that receive a default route from our hub router via eBGP. Router1 is the "primary",  we use local preference of 200 on it. Router2 is the "secondary",  we use local preference of 100 on that. Both routers have OSPF for the igp for iBGP reachability, they are directly connected and peer with their loopbacks. OSPF is configured on both routers to advertise a default route via default-information-originate with metric-type 1 for the downstream L3 distribution switches. Here's where things get strange and we have this deployed at many sites....

-At some sites Router2 will prefer the default advertised from Router1 via iBGP.
-At some sites Router2 will prefer the default advertised from Router1 via OSPF.

In the configs nothing has been changed to tweak a routing protocols admin distance. There is not PBR or any otherwise config that would cause this. They are identical configurations aside from IP addresses quite literally.

I would expect that Router2 prefers the default route from Router1's OSPF advertisement since local preference on Router1 is higher, this iBGP route is the preferred BGP path on Router2. The iBGP (200 AD) route would not be installed in the routing table since there is OSPF route available (110 AD). With that said I can't imagine any scenario that would cause the iBGP route to be preferred over OSPF at some sites, especially when I look at the tables they look nearly identical aside from the ones preferring OSPF show a rib failure in BGP which is to be expected. What's going on here or have I forgotten something about OSPF and BGP's relationship?

Example, SiteA (iBGP preferred)

router1# show ip route
Gateway of last resort is (eBGP neighbor) to network 0.0.0.0
B* 0.0.0.0/0 [20/0] via (eBGP neighbor), 8d16h

router1#show ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 0.0.0.0 (eBGP neighbor) 200 0 65001 65002 i

router2#show ip route
Gateway of last resort is (iBGP Neighbor) to network 0.0.0.0
B* 0.0.0.0/0 [200/0] via (iBGP Neighbor), 8d16h

router2#show ip bgp
Network Next Hop Metric LocPrf Weight Path
*>i 0.0.0.0 (iBGP Neighbor) 0 200 0 65001 65002 i
*                (eBGP neighbor) 100 0 65000 65002 i

Example Site B, (OSPF preferred)

router1#show ip route
Gateway of last resort is (eBGP neighbor) to network 0.0.0.0
B* 0.0.0.0/0 [20/0] via (eBGP neighbor), 6w4d

router1#show ip bgp
Network Next Hop Metric LocPrf Weight Path
*> 0.0.0.0 (eBGP neighbor) 200 0 65001 65002 i

router2#show ip route
Gateway of last resort is (router1) to network 0.0.0.0
O*N1 0.0.0.0/0 [110/12] via (router1), 6w4d, TenGigabitEthernet0/1/0

router2#show ip bgp
Network Next Hop Metric LocPrf Weight Path
r>i (iBGP Neighbor) 0 200 0 65001 65002 i
r 0.0.0.0 (eBGP neighbor) 100 0 65000 65002 i

[Kanan Huseynli]

Hi,

do you have chance to do debug ip ospf sfp external (with access-list, access-list 1 permit 0.0.0.0 0.0.0.0 works and shows only default route prefix information) ? You should also somehow force recalculation by either clearing ospf process (clear ip ospf process) or enforcing SFP recalculation (clear ip ospf force-sfp). In this case, SFP runs and debug shows sfp calculation for external 0.0.0.0/0 route (when it discards should indicate the reason).

Please note that, it may result temporary lose of connectivity, better to do when maintenance or time that can be done this test.

[paul driver]

Hello
The switch will be learning the default two ways - BGP/OSPF
ThIs issue can occur if/when the EBGP route is installed in the IP routing table first with an AD of 20 which means the OSPF 110 prefix is not then not installed into the rtrs rib

However with the OSPF peering's lets say wan rtr2, the OSPF learnt default is now entered into the rib because it’s being redistributed from BGP into OSPF via wan rtr 1 which is preferred over the default via the IBGP peering between wan rtr 1/2. that has an admin distance of 200,  which is higher then ospf 110.

Now if/when the EBGP peering on wan rtr 2 is lost and comes back the default is again received but without any weight,  but wan rtr1 is still advertising its default over IBGP with a higher Local Preference and Admin Distance so the redistributed default via OSPF is still being preferred, i don't believe you would see this happening if you were not traffic engineering between the IBGP peers in this instance with LP.

I would say if you simply add a default weight to either wan rtr EBGP peering higher than the default 32768 both wan rtrs will prefer BGP default over OSPF

wan rtr(s)
neighbor <ISP> weight 50000
end
clear ip bgp * soft