BGP controlled OSPF default route advertisement

[jdedon]

I am a bit confused with the process. Following a scenario from Halabi, I setup OSPF and BGP in a similar situation. I have two border routers both receiving a default route via bgp from different providers. I have these two border routers running iBGP with each other. Both router use a conditional default-originate command under OSPF. The backup router is setup to use local preference to choose to accept the default from the primary router via iBGP as opposed to using the default learned through eBGP.

This works partially. When the iBGP neighbor relationship breaks, the backup router starts advertising the default and all is well. The problem starts when the primary comes back and re-establishes the neighbor. When this happens, the backup router does not stop advertising the default route even though a look at his routing table shows that he is learning a default via iBGP. This is very bad because all the traffic traversing the nearest downstream router learns this router and forwards traffic to this router which in turn forward it back causing a continous loop. I am not sure exactly how to fix this. Can someone help?

eBGP eBGP

| |

primary ---iBGP--- backup

| |

| |

rtr-------------------------rtr---rtr

| OSPF

rtr

[jdedon]

sorry for the diagram....it appears that the editor removes whitespace.

Here are some relevant config details

Primary outbound router

default-information originate route-map SEND_DEFAULT_IF

neighbor 172.16.255.9 update-source Loopback0

neighbor 172.16.255.9 next-hop-self

access-list 11 permit 0.0.0.0

access-list 12 permit 157.130.xxx.xxx

route-map SEND_DEFAULT_IF permit 10

match ip address 11

match ip next-hop 12

_________________________________________________________________________

Backup outbound router

default-information originate route-map SEND_DEFAULT_IF

neighbor 172.16.255.1 update-source Loopback0

neighbor 172.16.255.1 next-hop-self

neighbor 172.16.255.1 route-map setlocalpref in

route-map setlocalpref permit 10

set local-preference 300

access-list 1 permit 0.0.0.0

access-list 2 permit 12.117.xxx.xxx

route-map SEND_DEFAULT_IF permit 10

match ip address 1

match ip next-hop 2

[jackyoung]

Did you check if the primary recover, will the BGP default route available in BGP table ? I suspect there may be some redistribution issue in OSPF, e.g. type, internal, external.

Please provide routing protocol config. and related access-list.

Moreoever, if you issue a clear ip route or clear ip ospf, clear ip bgp, what is the result ?

Hope this helps.

[jdedon]

The default gets put into the OSPF process as an E2 route. The backup router has default learned from the primary until the iBGP neigh relationship breaks.

It then has a default learned from eBGP in its table.

The backup does not advertise a default at all as long as the ibgp connection is alive. When this breaks, the backup will advertise via ospf the default route it now has learned via eBGP. The problems occur when the iBGP neighbor comes back and the backup sees the default coming from iBGP. It puts that route back in its table, but the internal router connected below it still has the default that was previously advertised in its table. This results in a loop. This internal router does not refresh the routing table with the new default route learned from the primary.

Unfortunealty, I do not have lab equipment to test theories on. I did notice that I did not have a complete iBGP mesh between the routers directly involved in the path. I corrected that, but haven't been able to test yet.

The relevant details are in another post on this thread. I think I tried clear ip route, not clear ospf or clear bgp. I think last time this happened to me I had to go remove default-information orginate command from backup and then clear ip route.

Live environments make wonderful testbeds ;0

[sundar.palaniappan]

Hi,

To identify/isolate the problem you need to check a few things when the problem is happening. When the backup BGP router learns the default route again via IBGP does it continue to redistribute the route via OSPF i.e by ignoring the route-map condition that is supposed to suppress the route (possibly due to a bug:). show ip route, show ip bgp and show ip ospf database (external) should provide you the clues to identify where the process is broken assuming all configuration is correct.

When the problem is experiencing on the downstream OSPF router issue the 'show ip ospf database external' command and you should be seeing the default route LSA learnt from both BGP routers. Look at the age of the default route that it learnt from the backup router and if the age isn't older than the time of IBGP connection restoration then the backup router appears to be causing the problem by continuing to redistribute the router when it shouldn't be doing that. If the age of the router is older than the time the IBGP connection got restored then something in the OSPF process is probably broken.

Any determination we make has to be based on facts. Hence, the best way to deal with this is to capture all relevant output and analyze it.

Hope that helps!

Regards,

Sundar

[sundar.palaniappan]

Reposting it after correcting a few typos.

Hi,

To identify/isolate the problem you need to check a few things when the problem is happening. When the backup BGP router learns the default route again via IBGP does it continue to redistribute the route via OSPF i.e by ignoring the route-map condition that is supposed to suppress the route (possibly due to a bug:). show ip route, show ip bgp and show ip ospf database (external) should provide you the clues to identify where the process is broken assuming all configuration is correct.

When the problem is happening, on the downstream OSPF router issue the 'show ip ospf database external' command and you should be seeing the default route LSA learnt from both BGP routers. Look at the age of the default route that it learnt from the backup router and if the age isn't older than the time of IBGP connection restoration then the backup router appears to be causing the problem by continuing to redistribute the default route when it shouldn't be doing that. If the age of the route is older than the time the IBGP connection got restored then something in the OSPF process is probably broken.

Any determination we make has to be based on facts. Hence, the best way to deal with this is to capture all relevant output and analyze it.

Hope that helps!

Regards,

Sundar

[jackyoung]

I agreed on Sundar's proposal. Collect more information to analyze the problem.

Seems it is the downlink router not update the routing table. You have to check the reason is the downlink router have higher priority of the default route, so the ISP connected router do not advertise its default to it or the ISP connected router do advertise the default to downlink router but downlink router have the higher priority of existing default route.Compare those metric, cost will help.

Hope this helps.

[jdedon]

Thanks for the comments. I'll try those suggestions when I can get a window to test. I am pretty sure that the problem is with the Backup router. It does not stop advertising a default once it starts. On the surface it appears like an order of operation thing, by this I mean, the local preference set in the bgp connection makes it choose what default to accept and put into its routing table. The conditional default originate causes it to advertise only when this default is learned via the eBGP neighbor. When the iBGP re-establishes, the backup applies the local preference again and changes the default in the routing table, but it does not apply the conditional default originate again even though the default in the routing table is not pointing toward the eBGP neighbor resulting in a default continuing to be advertised to the downstream router.

I will test again and try to get more exact information as to what is in ospf, bgp and routing tables at the time before, during, and after the failure of the primary.

Thanks again

[jdedon]

Ok, guys. I just had a network failure on the primary again so everything got sent into action again. I was not able to collect all the information required regarding comparing the iBGP up time to the OSPF LSA on the down stream router. I did get something however. When the primary came back up, the backup did as expected and replaced its eBGP default route with the one learned from the primary.

The downstream router was still receiving a default from the backup at this point. A clear IP route on the Backup caused the advertisement to stop and the downstream router immediately learned the default via ospf from the primary.

I did get a look at the ospf database on the downstream router briefly and it had two default routes in it during the period that the primary was down but the one learned from the primary was the oldest.

I have some info captured but not enough since this was not a scheduled outage and the rule of the day was to reestablish service asap.

[sundar.palaniappan]

Hi,

Based on your post it appears something in the BGP-OSPF redistribution process is broken on the backup BGP router. Given the fact, the age of the external LSA is new on the downstream router it clearly indicates the problem is with redistribution on the backup router. Research for bugs on the code you are running and if you are unable to find one then you may have to open up a TAC case.

Hope that helps! Good Luck!

Regards,

Sundar

[jdedon]

Hi Sundar,

I looked up a couple of bugs that may be the culprit

CSCsb18260 is one that defines the problem pretty close and the two others are listed as similar.

The only workaround they suggest is to use the bgp redistribute internal command.

I am not sure I understand how this will help and if so, I assume that I would have to filter this so that it only attempts to redistribute the default route learned via the IGP.

I attached a file that shows the bgp table with a rib failure for the default when both bgp exit routers are up. The resaon given for the rib failure is Higher administrative distance.

[sundar.palaniappan]

Johny,

Actually, you may be hitting this bug, CSCsa98059. It clearly states the problem happens when the BGP admin distance is higher than OSPF. In your case IBGP has an admin distance of 200 whereas OSPF's admin distance is 110. There appears to be no workaround for this. I am afraid IOS upgrade may be your only choice.

Hope that helps!

Regards,

Sundar

P.S. Pls. rate helpful posts.

[Harold Ritter]

I would recommend a simpler technique that consists of always originating the dafault network from both the primary and secondary. The only twist is that you originate it as an external type 1 on the primary side and as an E2 on the backup side.

This is very straightforward and has always been my preferred way to do it.

Hope this helps,

[Harold Ritter]

Just as a precision, this technique doesn't require iBGP between the primary and backup routers making it even more simple.

Hope this helps,

[jdedon]

Ok, this I think I understand. Since an OSPF type I route is always prefered over a type II route, then the downstream routers, even the ones directly connected to the ASBRs will prefer the type I route and insert it into their routing table. In the event the type I route dissapears, then the type II route will be used. Small caveat I see is the backup router without iBGP will install the eBGP learned default in its table and therefore will not use the default learned via the IGP. Not a great problem for this router since it does not have any networks that it directly routes for (exit/entry router only). I guess a workaround for that problem if needed would be to change the admin cost of eBGP so that it is lower than OSPF and it then would not advertise a default as long as it was learning one via the IGP.

Any thougnts?