BGP Multihoming

[rush2amol]

Hi,

We have two service providers and three Apnic ranges of /24. We are planning to install a 3825 router to connect the two service providers. I guess BGP would be an ideal solution if both service providers be connected in load balancing. I have checked a document (Document ID: 23675) in context to BGP for same purpose.

My question is will this type of configuration mentioned in the document would serve my purpose of load balancing with two service providers, and would all my apnic ranges would be reachable if i have either one of the service provider failing.

Also kindly let me know if there is any other better alternative to this.

Appreciated.

Thx,

Amol.

[adrian.chadd]

The document outlines the kinds of things you'll need to do.

If you're multihoming to the internet then you may wish to ignore filtering the received routes from your upstreams and instead accept all the routes they advertise (ie, take a full BGP feed from both.)

If you wish to run a pair of full BGP feeds then you'll probably need quite a bit of ram (at least 256mb at the very least.)

You'll also want to read a few BGP tutorials. Its easy to mess your BGP configuration up and cause grief down the track, even in simple BGP setups.

I can't comment on whether your /24's will be reachable without knowing what they are. Generally only legacy /24's allocated before AUNIC was rolled into APNIC are in the right IP space(s) to be useful for multihoming. (Ie, they're legacy "PI" space, or provider independant.) If they're allocated to you by one of your providers and they've come out of a larger IP allocation to that provider then it won't work.

[rush2amol]

Well i guess i need to configure BGP first and check how it goes.

As for the APNIC concern its not been allocated from any of the providers share, so i beleive it would be still reachable if any one goes down, provided the configs work perfectly.

Please share some configuration or related document on this topic.

Help Appreciated.

Thx

Amol.

[adrian.chadd]

Well, I currently multihome with APNIC space, so I know whats involved in getting it all working.

I'd first test this all in a lab environment with two routers so you understand how BGP works.

Here's my configuration. Notice that the configuration is very simplistic as I only have a small network and thus I can just nail the announced routes down with static routes. Things are slightly different in a larger network.

router bgp xxxx

no sync (should be default)

! This tells BGP which network (and subnets) to import into the BGP routing protocol

network 203.56.168.0 mask 255.255.255.0

neighbor x.x.x.x remote-as yyyy

neighbor x.x.x.x next-hop-self

! This allows you to make changes to your BGP config and then 'clear ip bgp nei soft' to process the changes without flapping your BGP session

neighbor x.x.x.x soft-reconfig inbound

! This locks down which prefixes are announced

neighbor x.x.x.x distribute-list LOCAL out

! This locks down which AS paths are accepted

neighbor x.x.x.x filter-list 11 in

! This locks down which AS paths are announced

neighbor x.x.x.x filter-list 10 out

!

! This AS path is used for announcing just the networks that originates from your AS.

ip as-path access-list 10 permit ^$

ip as-path access-list 10 deny .*

! This AS path is used to accept everything

ip as-path access-list 11 permit .*

! This AS path is used to accept everything with AS 7606 in the path.

ip as-path access-list 12 permit _7606_

ip as-path access-list 12 deny .*

! This controls which networks you advertise.

ip access-list standard LOCAL out

permit 203.56.168.0 0.0.0.255

deny any

!

! then, nail down the 'network' statements above with static routes which will always exist; this way the BGP doesn't flap announcements based on the reachability of those prefixes.

! Yes, this is only useful for a small network with one upstream point. if you have multiple physical sites with multiple physical upstreams then you need to plan your IGP use a lot more carefully as it'll influence your BGP announcements.

! It has a high cost to allow it to be overridden by any other learnt route. In this case its learnt via OSPF.

ip route 203.56.168.0 255.255.255.0 null0 254

HTH!