cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
9040
Views
7
Helpful
46
Replies

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

rw13
Level 1
Level 1

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

rwsummers13_0-1678922341884.png

 

46 Replies 46

because it dont have same prefix learn from other lower IGP routing protocol, so it accept the route and inject it from BGP table into RIB. 

There's no filtering within the topology that would stop R2 from receiving the default from R1 via OSPF though.

I will check case and run lab see where is error here. 

Get same result as you, 
the R2 show prefix learn from O E2 even if it learn from R3 (ebgp) directly. 
I check now solution. 

Screenshot (408).png

 

Screenshot (409).png

only make weight for any prefix learn from eBGP Peer higher that default value which is 32768
I make it 65535 and immediate the router now learn the prefix direct from eBGP not from iBGP neighbor via OSPF (O E2)
thanks 
MHM 
Screenshot (410).png

Thanks MHM but that's not really my point... I need to know why R2 is preferring the default via iBGP in some cases instead of OSPF with the configuration. eBGP preference/weight does not need to change.

make link to eBGP down and up again you will see same behave in other site. 
cisco have doc. about this issue please check below 
https://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/213285-understand-the-importance-of-bgp-weight.html

Thanks again, that is a good read but we are not doing mutual redistribution. You can see the weight of the installed default route in BGP is 0 for both received paths on both routers, they aren't locally originated routes.

please share the following 
show ip bgp 0.0.0.0 <<- 

still waiting your answer  

Site A (bgp preferred)

router1#show ip bgp 0.0.0.0
BGP routing table entry for 0.0.0.0/0, version 5905
Paths: (2 available, best #1, table default)
Multipath: eBGP
Advertised to update-groups:
2
Refresh Epoch 1
65001 65002
(hub1 peer) from (hub1 peer) (hub1 router id)
Origin IGP, localpref 200, valid, external, best
rx pathid: 0, tx pathid: 0x0
Refresh Epoch 1
65001 65002, (received-only)
(hub1 peer) from (hub1 peer) (hub1 router id)
Origin IGP, localpref 100, valid, external
rx pathid: 0, tx pathid: 0


router 2#show ip bgp 0.0.0.0
BGP routing table entry for 0.0.0.0/0, version 6052
Paths: (2 available, best #1, table default)
Multipath: eBGP
Not advertised to any peer
Refresh Epoch 1
65001 65002, (received & used)
(R1 iBGP peer) (metric 11) from R1 iBGP peer (R1 iBGP peer)
Origin IGP, metric 0, localpref 200, valid, internal, best
rx pathid: 0, tx pathid: 0x0
Refresh Epoch 1
65000 65002, (received-only)
(hub1 peer) from (hub1 peer) (hub1 router id)
Origin IGP, localpref 100, valid, external
rx pathid: 0, tx pathid: 0

 

Site A (OSPF preferred)

router1#show ip bgp 0.0.0.0
BGP routing table entry for 0.0.0.0/0, version 2433
Paths: (2 available, best #1, table default)
Multipath: eBGP
Advertised to update-groups:
30
Refresh Epoch 1
65001 65002
(hub1 peer) from (hub1 peer) (hub1 router id)
Origin IGP, localpref 200, valid, external, best
rx pathid: 0, tx pathid: 0x0
Updated on Feb 11 2023 12:04:13 UTC
Refresh Epoch 1
65000 65002, (received-only)
(hub2 peer) from (hub2 peer) (hub2 router id)
Origin IGP, localpref 100, valid, external
rx pathid: 0, tx pathid: 0
Updated on Feb 11 2023 12:04:13 UTC

router2#show ip bgp 0.0.0.0
BGP routing table entry for 0.0.0.0/0, version 1997
Paths: (2 available, best #2, table default, RIB-failure(17))
Multipath: eBGP
Not advertised to any peer
Refresh Epoch 1
65000 65002
(hub2 peer) from (hub2 peer) (hub2 router id)
Origin IGP, localpref 100, valid, external
rx pathid: 0, tx pathid: 0
Updated on Mar 16 2023 07:04:48 UTC
Refresh Epoch 1
65001 65002, (received & used)
(R1 iBGP peer) (metric 11) from R1 iBGP peer (R1 iBGP peer)
Origin IGP, metric 0, localpref 200, valid, internal, best
rx pathid: 0, tx pathid: 0x0
Updated on Feb 11 2023 12:04:13 UTC

router 2#show ip bgp 0.0.0.0
BGP routing table entry for 0.0.0.0/0, version 6052
Paths: (2 available, best #1, table default)
Multipath: eBGP
Not advertised to any peer
Refresh Epoch 1
65001 65002, (received & used)
(R1 iBGP peer) (metric 11) from R1 iBGP peer (R1 iBGP peer)
Origin IGP, metric 0, localpref 200, valid, internal, best
rx pathid: 0, tx pathid: 0x0
Refresh Epoch 1
65000 65002, (received-only) <<- there is prefix list config that effect this prefix 
(hub1 peer) from (hub1 peer) (hub1 router id)
Origin IGP, localpref 100, valid, external
rx pathid: 0, tx pathid: 0

router2#show ip bgp 0.0.0.0
BGP routing table entry for 0.0.0.0/0, version 1997
Paths: (2 available, best #2, table default, RIB-failure(17))
Multipath: eBGP
Not advertised to any peer
Refresh Epoch 1
65000 65002 <<- there is no filter effect this prefix 
(hub2 peer) from (hub2 peer) (hub2 router id)
Origin IGP, localpref 100, valid, external
rx pathid: 0, tx pathid: 0
Updated on Mar 16 2023 07:04:48 UTC
Refresh Epoch 1
65001 65002, (received & used)
(R1 iBGP peer) (metric 11) from R1 iBGP peer (R1 iBGP peer)
Origin IGP, metric 0, localpref 200, valid, internal, best
rx pathid: 0, tx pathid: 0x0

They use the same route-map inbound for the default on R1. There is no filter on R2 in or out

!
route-map local_pref_200 permit 10
match ip address 10
set local-preference 200
!
access-list 10 permit 0.0.0.0

dont use access-list for filter always use prefix list. 

The drawing is very helpful. Initially in your post it looked like you said that R1 and R2 have eBGP peering's to the HUB but in your drawing R2 has only iBGP peerings with R1 and the Hub. That changes some things.

On R2 router that has chosen iBGP as the default best route can you issues the command:

show ip bgp 0.0.0.0/0 bestpath - and show the output

-David