Why router is preferring an OSPF route over an eBGP route?

[michael.mastropaolo]

I have an odd issue that is a bit confusing to me at the moment.  I'll try to post as much details.  I have two core routers (CORE-A & B) which is learning it's default route from another core router (CORE-D).  

I have two Agg Routers (AGG-A and AGG-B) that uplink to core routers.  ABB-B uplinks to CORE-B, and AGG-A uplinks to another core router not mentioned; we'll go with CORE-C.

AGG-B learns it's default route from CORE-B, which it should.  AGG-A on the otherhand, which has a cross-connection to AGG-B, SHOULD learn its default route from CORE-C, but instead, learns it via OSPF from AGG-B.  Why?  The default route from CORE-C is an eBGP peer so its AD is 20, where as OSPF is 110.  I'm not understanding why this is happening.  Here is some output and i'll add a picture to illustrate this as well.

AGG-A#sh ip bgp 0.0.0.0
BGP routing table entry for 0.0.0.0/0, version 4052328
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Advertised to update-groups:
1 3
64601, (received & used)
10.252.4.145 from 10.252.4.145 (10.252.66.29)
Origin IGP, localpref 100, valid, external
64601, (received & used)
10.252.4.149 (metric 2) from 10.252.38.62 (10.252.70.133)
Origin IGP, metric 0, localpref 100, weight 110, valid, internal, best

AGG-A#sh ip ro 0.0.0.0
Routing entry for 0.0.0.0/0, supernet
Known via "ospf 33650", distance 110, metric 1, candidate default path
Tag 33650, type extern 2, forward metric 1
Last update from 10.252.38.62 on TenGigabitEthernet3/2, 00:02:38 ago
Routing Descriptor Blocks:
* 10.252.38.62, from 10.252.70.133, 00:02:38 ago, via TenGigabitEthernet3/2
Route metric is 1, traffic share count is 1
Route tag 33650

The dotted lines are logical peerings.  Solid is physical.

Between CORE-A and B and the AGG's, there is OSPF as well.

Basically, my task for this project is to fix this horrible design.  I attempted to today and blackholed some traffic because the default routes and the routing in general went crazy.  I had to revert back and I feel if I fix this one issue on AGG-A with getting the default route from the eBGP peer rather than the OSPF from AGG-B, that will fix my issue I had today when I go to migrate the links.

Sorry if this is a bit confusing.  Any help would be appreciated.

FYI, there's more to this design than meets the eye so if you question "well how can this get the Default Route from that" or whatever, it's in details that are not explained here.  Just an FYI.

[Peter Paluch · Accepted solution]

Michael,

I believe that this is the clue:

AGG-A#sh ip bgp 0.0.0.0
BGP routing table entry for 0.0.0.0/0, version 4052328
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Advertised to update-groups:
1 3
64601, (received & used)
   10.252.4.145 from 10.252.4.145 (10.252.66.29)
   Origin IGP, localpref 100, valid, external
64601, (received & used)
   10.252.4.149 (metric 2) from 10.252.38.62 (10.252.70.133)
   Origin IGP, metric 0, localpref 100, weight 110, valid, internal, best

It seems that your BGP configuration is assigning a weight of 110 to the default route as learned from 10.252.38.62. Because the external route is not assigned a weight, and a weight is a local-only attribute, the external route is considered as having a weight of 0. Conequently, the internal route wins because of higher weight. Now, because this route is internal, it has an AD of 200, and so OSPF beats it.

You will need to inspect the configuration of your BGP on Agg-A to check for any weight commands, either in BGP configuration directly, or in a route-map.

When modifying BGP configuration, caution is always called for - you've learned that the hard way today. I am not familiar with your network setup so I cannot just blindly recommend you to do or not to do something - that's up to you. I've only tried to explain why your BGP-learned default route doesn't make it into your routing table.

Of course, please feel welcome to ask further!

Best regards,
Peter

[michael.mastropaolo]

I'm actually down that path, working on that as we speak.  Thanks for the reply Peter.  

I guess where i'm getting confused is why is OSPF sending the default route across (hence the AD of 110, and that's why the internal best route of ibgp is getting beat).  I think it is because of this lovely default-information originate on AGG-B.  I'm most certain actually.

Now here is another question if this is the case.  This default-information originate is needed for the second tier AGG routers which are uplinked to AGG-A and B.  Would the preferred method here be to block the default route from being advertised out of the OSPF process on those cross-links?

This is one hell of a complex network I stepped on :)  I certainly love it though...even though my head hurts haha.

[Peter Paluch]

Hi Michael, Sam,

Hey, what a fine group of people discussing the wonders of complex routed environments :)

Michael, according to the outputs you have posted, the OSPF default route originates at a router whose OSPF RouterID is 10.252.70.133. That OSPF router is most probably configured with default-information originate command - you've mentioned you saw that command on Agg-B.

Would the preferred method here be to block the default route from being advertised out of the OSPF process on those cross-links?

In OSPF, you cannot perform route filtering on links. OSPF, like any link-state routing protocol, only allows to filter routes at area boundaries.

But I am not entirely sure what cross-links you have in mind, and what exactly you want to achieve - can you reexplain yourself a little?

Best regards,
Peter

[JRDIAZ758]

i got this exact same issue, but in this case im talking ebgp to my ISP and ospf to my internal network. 

BGP

OSPF

EIGRP

Site MPLS router(10.8.0.0)------ ISP--------MPLS-router-------core----------vpn-ROUTER---------Site-VPN-rotuer(10.8.0.0)

MPLS-ROUTER#sh ip bgp 10.8.0.0
BGP routing table entry for 10.8.0.0/0, version 4052328
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Not avertised to any Peer
Refresh epoch
7029 65005, (received & used)
   40.135.119.41 from  40.135.119.41 (169.130.66.137)
   Origin IGP, localpref 100, valid, external
LOCAL
   10.215.5.9  from  0.0.0.0 (10.215.0.5)
   Origin Incomplete, metric 20, localpref 100, weight 32728, valid, sourced, best

[sabibby]

Lots of variables, but when you instruct OSPF to generate the default route it floods this information via the LSA database throughout the area. So blocking the default route from begin advertised would not work peruse, you either flood it everywhere or no where*

If it is truly not needed on AGG-A but is needed downstream then you could filter it from being installed into the RIB on the Agg router. However doing so will stop AGG-B from using this route via AGG-A if the BGP path ever fails.

If you truly want the default to go via core-C & want to maintain a redundant design I would check your local policies & remove the default route via iBGP from getting the the higher weight value assigned, or set a higher weight value for the default learned via eBGP.

Many ways to skin a cat, not all are very humane.

-Sam

[michael.mastropaolo]

Thank you all for the replies.  What we have right now, which is working, although going to dive deeper to see how ideal it is, is the following:

We created a prefix-list to deny 0.0.0.0 and added it into the ospf process of both AGG routers, inbound.  Since there is an iBGP peering between these two guys, now there are two valid paths.  AGG-A has its valid/best going to CORE-C and AGG-B has its valid/best to CORE-B, with the redundant backup paths going across between the AGG's.

There was weight all over the place so we had to finagle with that.  The lesson I learned today is that when you change weight, you have to hard reset the bgp peering, as soft wouldnt rip that weight out.  I never knew that.  Whether that's a bug or not, I am not sure.

[Peter Paluch]

Michael,

The lesson I learned today is that when you change weight, you have to hard reset the bgp peering, as soft wouldnt rip that weight out.  I never knew that.

And you shouldn't know that. That must be a bug. Any change to any BGP path attribute you can accomplish by a route-map or a per-neighbor command must be fully applicable after a clear ip bgp neighbor in command. If this command didn't help and a hard BGP session reset did, something is wrong.

Best regards,
Peter

[sabibby]

Hey Mike,

Agg-A is learning the route from both Core-C & Agg-B, one is via iBGP the other is via eBGP. When Agg-A compares the two iBGP is winning due tio having a better weight: (check your BGP configs for a policy that sets weight from routes coming in from AGG-B):

Advertised to update-groups:
1 3
64601, (received & used)
10.252.4.145 from 10.252.4.145 (10.252.66.29)
Origin IGP, localpref 100, valid, external
64601, (received & used)
10.252.4.149 (metric 2) from 10.252.38.62 (10.252.70.133)
Origin IGP, metric 0, localpref 100, weight 110, valid, internal, best

As the iBGP route is preferred over eBGP, the admin cost assigned to this is 200. Therefore the comparison is iBGP coast of 200 vs OSPF cost of 110.

It's likely there were some policy's that dictated the exit point in the network is via Agg-B, so weight has been used. The weight value is pretty much the first comparison done in BGP, so it trumps all else. 

Happy to help,

-Sam B

[michael.mastropaolo]

Hi Sabibby, 

Wouldn't an eBGP route (AD of 20) be preferred over an iBGP route (AD of 200)?

[leogal777]

Hi Michael

not if You configured primary router for example with better local preference and the route with better LP will come via Ibgp. In that case the ibgp route will be preferred to ebgp. Check the attributes of both routes, follow the bgp best path selection process step by step and you will eventually find the reason. 
Leo