Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. If you'd prefer to explore, try our test area to get started. And see here for current known issues.

New Member

BGP controlled OSPF default route advertisement

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

  • Other Network Infrastructure Subjects
15 REPLIES
New Member

Re: BGP controlled OSPF default route advertisement

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

Silver

Re: BGP controlled OSPF default route advertisement

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.

New Member

Re: BGP controlled OSPF default route advertisement

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

Re: BGP controlled OSPF default route advertisement

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

Re: BGP controlled OSPF default route advertisement

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

Silver

Re: BGP controlled OSPF default route advertisement

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.

New Member

Re: BGP controlled OSPF default route advertisement

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

New Member

Re: BGP controlled OSPF default route advertisement

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.

Re: BGP controlled OSPF default route advertisement

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

413
Views
0
Helpful
15
Replies
This widget could not be displayed.