eBGP route losing over OSPF E1 Type ... very confusing !!

[AJAZ NAWAZ]

Hi all

I'm aware of the common reasons why BGP routes are not installed into routing table, however I have come across a scenario which I'm struggling to understand why my ebgp prefix is not winning over ospf.

DC1CORE01#sh ip route vrf COSTA 10.3.0.0
Routing entry for 10.3.0.0/16
Known via "ospf 10", distance 110, metric 130
Tag 450, type extern 1
Advertised by bgp 65300
Last update from 10.10.14.18 on Vlan450, 00:00:11 ago
Routing Descriptor Blocks:
* 10.10.14.18, from 1.0.0.4, 00:00:11 ago, via Vlan450
Route metric is 130, traffic share count is 1
Route tag 450

DC1CORE01#sh ip route vrf COSTA 10.3.0.0
Routing entry for 10.3.0.0/16
Known via "ospf 10", distance 110, metric 130
Tag 450, type extern 1
Advertised by bgp 65300
Last update from 10.10.14.18 on Vlan450, 00:00:11 ago
Routing Descriptor Blocks:
* 10.10.14.18, from 1.0.0.4, 00:00:11 ago, via Vlan450
Route metric is 130, traffic share count is 1
Route tag 450

DC1CORE01#sh ip route vrf COSTA 10.3.0.0
Routing entry for 10.3.0.0/16
Known via "ospf 10", distance 110, metric 130
Tag 450, type extern 1
Advertised by bgp 65300
Last update from 10.10.14.18 on Vlan450, 00:06:11 ago
Routing Descriptor Blocks:
* 10.10.14.18, from 1.0.0.4, 00:06:11 ago, via Vlan450
Route metric is 130, traffic share count is 1
Route tag 450

DC1CORE01#sro
router ospf 10 vrf COSTA
router-id 1.0.0.100
log-adjacency-changes
auto-cost reference-bandwidth 40000
area 0 authentication message-digest
area 20 stub
redistribute static metric 250 metric-type 1 subnets tag 250
redistribute bgp 65300 metric-type 1 subnets tag 313

...

..

btw. 10.10.14.18 is an ospf neighbor

DC1CORE01#sh ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
1.0.0.10 0 FULL/ - 00:00:04 10.10.14.18 Vlan450
1.0.0.3 0 FULL/ - 00:00:35 10.10.14.14 GigabitEthernet1/1
1.0.0.200 20 FULL/BDR 00:00:38 10.10.15.253 Vlan30
DC1CORE01#

Any questions, please resply to post.

[Giuseppe Larosa]

duplicated post

[AJAZ NAWAZ]

duplicate since the new so called 'çloud'server moves like a tortoise, and i clicked on submit twice as I didn't know if something was happening.

[AJAZ NAWAZ]

DC1CORE01#sibvr 10.3.0.0
BGP routing table entry for 65300:10:10.3.0.0/16, version 554421
Paths: (3 available, best #1, table COSTA)
Advertised to update-groups:
1 2 3 4
Local
10.10.14.18 from 0.0.0.0 (1.0.0.100)
Origin IGP, metric 130, localpref 100, weight 32768, valid, sourced, local, best
Extended Community: OSPF DOMAIN ID:0x0005:0x0000000A0200
OSPF RT:0.0.0.0:5:0 OSPF ROUTER ID:1.0.0.100:1280,
mpls labels in/out 52/nolabel
65520 39545, (received & used)
10.10.14.89 from 10.10.14.89 (1.0.0.5)
Origin IGP, localpref 100, valid, external,
mpls labels in/out 52/nolabel
Local, (received & used)
10.10.15.253 from 10.10.15.253 (1.0.0.200)
Origin IGP, metric 140, localpref 100, valid, internal,
mpls labels in/out 52/nolabel
DC1CORE01#

[Giuseppe Larosa · Accepted solution]

Hello Ajaz,

this additional show command confims my interpretation:

you have local redistribution of OSPF PE-CE routes into BGP in place, and locally generated routes have weight 32768, this is why this BGP route is selected as best.

On the other hand you have a path from 10.10.14.89 with AS path 65520 39545 that is not best for its 0 weight.

Try to increase to 40000 the weight of neighbor 10.10.14.89 with a neighbor ... weight command.

Hope to help

Giuseppe

[AJAZ NAWAZ]

Hi Giuseppe

I get you though please can I update you on few points.

Redistribution is not mutual [as you may know] and takes place under the OSPF process as follows:

router ospf 10 vrf COSTA
router-id 1.0.0.100
log-adjacency-changes
auto-cost reference-bandwidth 40000
area 0 authentication message-digest
area 20 stub
redistribute static metric 250 metric-type 1 subnets tag 250
redistribute bgp 65300 metric-type 1 subnets tag 313
passive-interface default
no passive-interface GigabitEthernet1/1
no passive-interface Vlan30
no passive-interface Vlan450

.....

...

I am a bgp and ospf speaking router. I am receiving advertisements for two neighbors. One of the neighbors is talking OSPF with me, and the other is eBGP peer. They are sending me 10.3/16 with standard admin distance. I am redistributing the OSPF routes into my BGP process. When I lookup the 10.3/16 prefix in my RT, I see that OSPF route is winning.

I accept that redistributing OSPF routes into BGP doesn't mean those routes should appear in my RT as BGP, but I fail to understand why when I am receiving the same prefix from a eBGP speaker, that prefix doesn't win the battle to enter the RT given the 20 admin distance being more superior to 110 of OSPF.

Thanks

[AJAZ NAWAZ]

Replying to my own post here.

Thanks Giuseppe. I see whats happening now. Essentially it came down to locally originated which assigns 32768 as you mentioned. The thing is while this prefix entry wins in the BGP table, its seem the router elects to enter the prefix from it first origin which was OSPF.

btw the reason why the origin was local is because of the network cmd under bgp.

Cheer for that !

[Giuseppe Larosa]

Hello Ajaz,

>> but I fail to understand why when I am receiving the same prefix from a eBGP speaker, that prefix doesn't win the battle to enter the RT given the 20 admin distance being more superior to 110 of OSPF

The issue is just timing. The OSPF route did its trip through redistribution into BGP before the eBGP route has arrived. It is a race condition.

When the eBGP route arrives it is placed in the BGP table and it is compared to the locally generated BGP route that is the result of OSPF redistribution into BGP, and loses the comparison for its lower BGP weight.

BGP has its own table and this is part of the issue too. In that table the eBGP route is not selected as the best path and so that route is not even sent to the IP routing table mantainer.

So as I told you before if you want the eBGP route to always wins increase the BGP weight for the neighbor to 40000 or whatever value greater then 32768.

I had the same issue many years ago and I have solved in this way.

Hope to help

Giuseppe