Solved: OSPF wins over BGP

rich_harris · ‎01-09-2006

I have a remote site with 2 wan connection back to head office.

1. MPLS using BGP (Serial 1)

2. GRE tunnel over internet using OSPF (Serial 2)

For some reason where both protocols are advertising the same route ospf wins

even though ospf has a cost and distance of 110/67 and the bgp route has 20/0, the router chooses ospf.

If I filter ospf for a specific route, the router then uses bgp (20/0).

What am I missing? Surely bgp should over write ospf.

Config...

router ospf 3

log-adjacency-changes

redistribute static

network 10.4.2.0 0.0.0.255 area 0

network 10.3.2.0 0.0.0.255 area 0

network 10.1.0.0 0.0.255.255 area 0

network 10.2.0.0 0.0.255.255 area 0

default-information originate

distribute-list ospf-ny in

!

router bgp 3

no synchronization

bgp log-neighbor-changes

network 10.1.0.0 mask 255.255.0.0

network 10.2.0.0 mask 255.255.0.0

redistribute ospf 3 metric 790 match internal external 1 external 2

neighbor xxx.xxx.xxx.xxx remote-as 5000

no auto-summary

mheusinger · ‎01-09-2006

Hello,

first the announcement of a network will for sure be faster through OSPF than through BGP. Once you have the OSPF route in the routing table you redistribute it into BGP. Now BGP learns the network through AS 5000.

At this point BGP path selection determines which of the two is the better path. And the winner is: locally redistributed route! (Do a show ip bgp to check this!). With this one BGP does NOT win against OSPF - actually where it comes from.

Administrative distance does not play a role in BGP path selection.

So you would need a route-map with the redistribution in case you would like to change this.

router bgp 3

redistribute ospf 3 metric 790 match internal external 1 external 2 route-map OSPF2BGP

route-map OSPF2BGP permit 10

match ip addess 100

set weight 0

set local preference 50

access-list 100 permit ...networks...

This will do the trick. But be extremely careful this way you might generate a routing loop easily (OSPF->BGP->MPLS->BGP->OSPF and round and round it goes ;-). So you need to include some sort of filter to prevent this.

Did this help? Please rate all posts.

Martin

View solution in original post

pkhatri · ‎01-09-2006

Hi,

Just to expand on Martin's post....

When BGP injects a local route into the BGP table, it gives it a weight of 32768, by default. In your case, it is the OSPF-learned route that is getting injected into BGP with a weight of 32768. The same route is also being learned via EBGP. EBGP routes, by default, will be given a weight of 0 and a local preference of 100. Now, the BGP table will have two routes for the same prefix - which you will see if you enter in 'sh ip bgp '. Since weight is the highest ranked parameter in the BGP best path selection process, the locally-injected route will take preference and will be selected as the best route. Therefore, as far as the routing table is concerned, the best BGP path for that prefix is the locally-injected route (which was learned via OSPF). That is why you see that the installed route is an OSPF route.

The AD does not come into the picture as far as BGP path selection goes (although a distrinction between EBGP and IBGP learned routes is made further down the BGP best path selection process).

However, if you had had a situation where you were not redistributing the OSPF route into BGP, the BGP table would only have a single path for this prefix, the one learned via EBGP. This would then be compared against the OSPF route and since EBGP has an AD of 20, the EBGP route would have been installed.

The alternative, as per Martin's post, is to redistribute the OSPF route into BGP, but to make it less attractive to the BGP best path selection process by making its weight the same as the EBGP route but give it a local preference that is lower than the EBGP route.

Hope that helps,

Paresh.

View solution in original post

mheusinger · ‎01-09-2006

Hello,

first the announcement of a network will for sure be faster through OSPF than through BGP. Once you have the OSPF route in the routing table you redistribute it into BGP. Now BGP learns the network through AS 5000.

At this point BGP path selection determines which of the two is the better path. And the winner is: locally redistributed route! (Do a show ip bgp to check this!). With this one BGP does NOT win against OSPF - actually where it comes from.

Administrative distance does not play a role in BGP path selection.

So you would need a route-map with the redistribution in case you would like to change this.

router bgp 3

redistribute ospf 3 metric 790 match internal external 1 external 2 route-map OSPF2BGP

route-map OSPF2BGP permit 10

match ip addess 100

set weight 0

set local preference 50

access-list 100 permit ...networks...

This will do the trick. But be extremely careful this way you might generate a routing loop easily (OSPF->BGP->MPLS->BGP->OSPF and round and round it goes ;-). So you need to include some sort of filter to prevent this.

Did this help? Please rate all posts.

Martin

pkhatri · ‎01-09-2006

Hi,

Just to expand on Martin's post....

When BGP injects a local route into the BGP table, it gives it a weight of 32768, by default. In your case, it is the OSPF-learned route that is getting injected into BGP with a weight of 32768. The same route is also being learned via EBGP. EBGP routes, by default, will be given a weight of 0 and a local preference of 100. Now, the BGP table will have two routes for the same prefix - which you will see if you enter in 'sh ip bgp '. Since weight is the highest ranked parameter in the BGP best path selection process, the locally-injected route will take preference and will be selected as the best route. Therefore, as far as the routing table is concerned, the best BGP path for that prefix is the locally-injected route (which was learned via OSPF). That is why you see that the installed route is an OSPF route.

The AD does not come into the picture as far as BGP path selection goes (although a distrinction between EBGP and IBGP learned routes is made further down the BGP best path selection process).

However, if you had had a situation where you were not redistributing the OSPF route into BGP, the BGP table would only have a single path for this prefix, the one learned via EBGP. This would then be compared against the OSPF route and since EBGP has an AD of 20, the EBGP route would have been installed.

The alternative, as per Martin's post, is to redistribute the OSPF route into BGP, but to make it less attractive to the BGP best path selection process by making its weight the same as the EBGP route but give it a local preference that is lower than the EBGP route.

Hope that helps,

Paresh.

rich_harris · ‎01-10-2006

Hi

Many thanks to both of you, the solution worked perfectly.

Rich

baibeg · ‎11-06-2006

Not always IGP wins over EGP, even when there is distribution.

If the route or prefix for any reason disappears from the IGP, the EGP route will be immediately injected in the routing table with an AD of 20 if it is eBGP.

Then when the IGP recovers, since the eBGP route is already established in the routing table, IGP will not participate in the EGP path selection. Therefore it will not be selected.

The only way to make it work is 'clear ip bgp *', which basically resets BGP and clears the routing table from all BGP entries. This is a manual process and I would not recommend it.

Does anybody know a trick to overcome this limitation or 'feature'?

albersj · ‎12-11-2019

If route is known via OSPF and BGP and you want to prefer BGP -- that 'should' mean the route doesn't belong to the OSPF domain. If that is the case, the OSPF route should be external (because some other BGP device learned the route and put it into OSPF. If you don't want other BGP devices to prefer the OSPF route, then don't redis that route back into bgp (ie don't use redist ospf x match external'.)

You could also tag routes when redist B2O then filter that tag when doing O2B..

And you could set weight for eBGP peer to higher than 32768..

I think it is important to reiterate what is explained above by others. This is order of operations dependent. The O2B redist can't happen if the eBGP route is present and valid. BGP would only ingest the OSPF route (and set weight to 32768 / prefer) if the device loses the eBGP route for some reason. Then if the eBGP route returned it wouldn't be selected as best because the O2B route has higher weight.