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

BGP, OSPF and default routes

Currently our ISP injects a defualt route into our IGP using OSPF. Due to plans to migrate to AT&T's IPFR service, our IGP will be replaced by BGP. I've been simulating the new environment in a lab and have run into an issue with the default route whenever I simulate a failure of the link to the internet router (such as shutting down the appropriate interface). Everything fails over to the backup site but does not recover after I restore the connection.

Here's the configration of our internal router that I'm currently using.

router ospf 101

network 10.0.0.0 0.255.255.255 area 0

area 0 range 10.0.0.0 255.0.0.0

!

router bgp 64615

network 10.15.0.0 mask 255.255.0.0

network 10.253.15.0 mask 255.255.255.252

network 10.254.0.15 mask 255.255.255.255

network 0.0.0.0

neighbor 10.253.15.2 remote-as 13979

no auto-summary

Here's the default route information from show ip bgp before the test. The selection of the default route based on the weight is to the ISP's router at 10.15.1.5.

Network Next Hop Metric LocPrf Weight Path

* 0.0.0.0 10.253.15.2 0 13979 64612 i

*> 10.15.1.5 1 32768 i

Here's the default route information from show ip bgp after the ISP connection is severed. Which is as I expected.

Network Next Hop Metric LocPrf Weight Path

*> 0.0.0.0 10.253.15.2 0 13979 64612 i

After "recovering" from the outage, the default route via 10.15.1.5 does not reappear until a "clear ip bgp *" is issued.

So what am i missing?

thanx in advance.

7 REPLIES
Bronze

Re: BGP, OSPF and default routes

Not sure how the primary site works without a neighbor statement. That might be why it doesnt recover.

Community Member

Re: BGP, OSPF and default routes

Hi,

Try giving the command

neighbor 10.253.15.2 soft-reconfiguration inbound

Rgds

Abey

Gold

Re: BGP, OSPF and default routes

I wouldn't use soft reconfiguration.... That should only be used when you are using filtering of some type, and change the filtering fairly regularly, and route refresh has pretty much replaced soft reconfiguration for this function in the field, anyway.

I would start by taking the network 0.0.0.0 command out, you shouldn't need that if you're not originating the 0/0 at this router (which you aren't). I assume you are running iBGP with the backup site, correct? And you're probably running a network statement for 0/0 there, as well? I would kill that one, too.

If this doesn't solve the problem, then try setting up a filter so you only advertise locally orignated routes towards the ISP.

ip as-path access-list 100 permit ^$

!

router bgp xxx

neighbor x.x.x.x filter-list 100 out

Should do the trick. This will prevent you from advertising that 0/0 back out to the isp, which will stop them from accepting your default as their best path (which they shouldn't be doing, anyway, and your router shouldn't be using your iBGP learned route as it's bestpath over the eBGP learned route from the ISP), and not advertising the default back to you, if that's what's happening.

Try taking the network statement out, first, then the filter, and let us know if they do or don't work.

Russ.W

Community Member

Re: BGP, OSPF and default routes

I think there is some confusion concerning the network infrastructure, it may be on my part but I'll try to clarify my earlier post.

As the network exists today, BGP is not employed anywhere in the network. We're accepting a default route from our ISP's router via OSPF. OSPF is also the routing protocol used between our hub sites and branch offices. ie:

isp router <==> fw <==> internal router <===> remote site

| <====== OSPF =======> | <==== OSPF ==== > |

The offices are inter-connected via a traditional frame-relay network. In the near future, these frame-relay connections will be replaced with AT&T's IP enabled frame-relay service. The migration to the IPFR service will allow any office to communicate with any other office without first traversing a hub site. The trade-off is that OSPF can no-longer be used as our interior routing protocol. The choice was between BGP or static routes. The decision was made to utilize eBGP between our routers and AT&T's. The network topology becomes

isp router <==> fw <==> internal router <===> AT&T Routers <===> remote site

| <====== OSPF =======> | <== BGP ===> | | <== BGP ==> |

The plan is to maintain how the default route is injected into our network by our ISP. The problem that I encountered in the lab arises after I simulate the loss of the default route from our ISP and then recover. After recovering, my expection is that the default route would once again be announced by BGP. This does not happen until I issue a clear ip bgp * command.

The method that I'm using to announce a default route, is by using the network 0.0.0.0 command under the BGP process. My understanding is that BGP will only announce a network if the network is specified under the BGP process and the router has learned about the network via an IGP or some other manner. In my case I want each of the sites with an Internet connection to announce the default network, if and only if the router learns of the default route from the ISP's router via OSPF. This prevents me from using the default-originate command within the BGP process.

So, what am I missing? Is it something obvious?

thanx again.

Gold

Re: BGP, OSPF and default routes

Could you post the output of a show ip route while the ospf connection is down? Are you learning a default from someplace else while OSPF is down?

What version of code is this on? I actually tried this in the lab, and it worked, but all my routers are on the latest T train, for the most part. It could be related to CSCdw54107, maybe.

This configuration just seems odd to me because you're using OSPF as an EGP, and BGP as your IGP, for all practical purposes. If you had a lot of remotes, using BGP for connectivity to all of them could be a real pain.

Russ.W

Community Member

Re: BGP, OSPF and default routes

I've changed the order of your questions.

>What version of code is this on? I actually tried this in the lab, and it worked,

>but all my routers are on the latest T train, for the most part. It could be

>related to CSCdw54107, maybe.

It may very well be the case that what I'm seeing is a bug in the code on the lab routers. I hadn't thought to check the bug tracker. The lab routers are running 11.3.6 and I think that CSCdk68558 describes the problem that I have encountered. Shouldn't the default route learned via BGP be considered inferior to the default route learned via OSPF. Before simulating the failure, a show ip bgp lists the weight of the default route learned via OSPF as 32768.

>This configuration just seems odd to me because you're using OSPF as an EGP,

> and BGP as your IGP, for all practical purposes. If you had a lot of remotes, using

> BGP for connectivity to all of them could be a real pain.

I agree that using BGP for the remote sites is a pain but with AT&T's IPFR service the only other option would be to use static routes. Then any time a change is made at an office, a work order would have be placed with AT&T to update/add the appropriate static route. AT&T would also statically define the default routes.

>Could you post the output of a show ip route while the ospf connection is down?

>Are you learning a default from someplace else while OSPF is down?

To answer the the second question first, yes I am. We actually have multiple hub sites. For the lab simulation I have configured 3 routers as hub sites, a router as one of our branch offices, another router as AT&T's IPFR network and 3 other routers simulating the ISP's routers. The desire is to have each of the hub sites inject a default route into our WAN if the link to the ISP is functioning.

Here's the output of show ip route hub 1 before the ospf connection is downed.

1ub_site_1#show ip route

Gateway of last resort is 10.15.1.5 to network 0.0.0.0

10.0.0.0/8 is variably subnetted, 25 subnets, 4 masks

B 10.10.0.0/16 [20/0] via 10.253.15.2, 12:37:57

B 10.8.0.0/16 [20/0] via 10.253.15.2, 12:37:57

B 10.9.0.0/16 [20/0] via 10.253.15.2, 12:37:57

B 10.14.0.0/16 [20/0] via 10.253.15.2, 12:37:57

C 10.15.0.0/16 is directly connected, Ethernet0

B 10.12.0.0/16 [20/0] via 10.253.15.2, 12:37:57

B 10.13.0.0/16 [20/0] via 10.253.15.2, 12:37:57

B 10.1.0.0/16 [20/0] via 10.253.15.2, 12:37:57

B 10.25.0.0/16 [20/0] via 10.253.15.2, 12:37:57

B 10.98.0.0/16 [20/0] via 10.253.15.2, 12:37:57

C 10.254.115.0/24 is directly connected, Serial1.12

B 10.254.0.25/32 [20/0] via 10.253.15.2, 12:37:59

C 10.254.25.0/24 is directly connected, Serial1.25

B 10.253.25.0/30 [20/0] via 10.253.15.2, 12:37:59

B 10.254.0.1/32 [20/0] via 10.253.15.2, 12:37:59

B 10.253.1.0/30 [20/0] via 10.253.15.2, 12:37:59

B 10.254.0.12/32 [20/0] via 10.253.15.2, 12:37:59

C 10.253.15.0/30 is directly connected, Serial1.500

B 10.253.12.0/30 [20/0] via 10.253.15.2, 12:37:59

C 10.254.15.0/24 is directly connected, Serial1.1

C 10.254.0.15/32 is directly connected, Loopback0

O*E1 0.0.0.0/0 [110/100] via 10.15.1.5, 12:38:18, Ethernet0

And the output from show ip bgp. 10.253.15.2 is the IP assigned to AT&T's IPFR router.

hub_site_1#show ip bgp

BGP table version is 57, local router ID is 10.254.0.15

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal

Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path

* 0.0.0.0 10.253.15.2 0 13979 64601 i

*> 10.15.1.5 100 32768 i

*> 10.1.0.0/16 10.253.15.2 0 13979 64601 i

*> 10.8.0.0/16 10.253.15.2 0 13979 64612 i

*> 10.9.0.0/16 10.253.15.2 0 13979 64612 i

*> 10.10.0.0/16 10.253.15.2 0 13979 64612 i

*> 10.12.0.0/16 10.253.15.2 0 13979 64612 i

*> 10.13.0.0/16 10.253.15.2 0 13979 64612 i

*> 10.14.0.0/16 10.253.15.2 0 13979 64612 i

*> 10.15.0.0/16 0.0.0.0 0 32768 i

*> 10.25.0.0/16 10.253.15.2 0 13979 64625 i

*> 10.98.0.0/16 10.253.15.2 0 13979 64612 i

*> 10.253.1.0/30 10.253.15.2 0 13979 64601 i

*> 10.253.12.0/30 10.253.15.2 0 13979 64612 i

*> 10.253.15.0/30 0.0.0.0 0 32768 i

*> 10.253.25.0/30 10.253.15.2 0 13979 64625 i

*> 10.254.0.1/32 10.253.15.2 0 13979 64601 i

*> 10.254.0.12/32 10.253.15.2 0 13979 64612 i

*> 10.254.0.15/32 0.0.0.0 0 32768 i

*> 10.254.0.25/32 10.253.15.2 0 13979 64625 i

And the output after the OSPF connection is downed by using the passive-interface command on the ISP router.

hub_site_1#show ip route

Gateway of last resort is 10.253.15.2 to network 0.0.0.0

10.0.0.0/8 is variably subnetted, 21 subnets, 4 masks

B 10.10.0.0/16 [20/0] via 10.253.15.2, 12:59:02

B 10.8.0.0/16 [20/0] via 10.253.15.2, 12:59:02

B 10.9.0.0/16 [20/0] via 10.253.15.2, 12:59:02

B 10.14.0.0/16 [20/0] via 10.253.15.2, 12:59:02

C 10.15.0.0/16 is directly connected, Ethernet0

B 10.12.0.0/16 [20/0] via 10.253.15.2, 12:59:02

B 10.13.0.0/16 [20/0] via 10.253.15.2, 12:59:02

B 10.1.0.0/16 [20/0] via 10.253.15.2, 12:59:02

B 10.25.0.0/16 [20/0] via 10.253.15.2, 12:59:02

B 10.98.0.0/16 [20/0] via 10.253.15.2, 12:59:02

C 10.254.115.0/24 is directly connected, Serial1.12

B 10.254.0.25/32 [20/0] via 10.253.15.2, 12:59:03

C 10.254.25.0/24 is directly connected, Serial1.25

B 10.253.25.0/30 [20/0] via 10.253.15.2, 12:59:05

B 10.254.0.1/32 [20/0] via 10.253.15.2, 12:59:05

B 10.253.1.0/30 [20/0] via 10.253.15.2, 12:59:05

B 10.254.0.12/32 [20/0] via 10.253.15.2, 12:59:05

C 10.253.15.0/30 is directly connected, Serial1.500

B 10.253.12.0/30 [20/0] via 10.253.15.2, 12:59:05

C 10.254.15.0/24 is directly connected, Serial1.1

C 10.254.0.15/32 is directly connected, Loopback0

B* 0.0.0.0/0 [20/0] via 10.253.15.2, 00:00:08

Thanx again.

-john

Gold

Re: BGP, OSPF and default routes

Email me off line....

:-)

Russ

riw@cisco.com

152
Views
0
Helpful
7
Replies
CreatePlease to create content