Load balancing multihomed BGP default routes

Paul Boz

What are the options one has when multihoming BGP with default routes from different ISPs? I understand how multihoming for the purpose of backup connections works fine, but I don't understand how one can load-balance across the BGP links when given default routes though. Can someone provide insight into how this can be done?

I thought about it and I think you could do it by segmenting the network into different areas within the IGP, using a different default route to each ISP, but it doesn't really solve the question of how to establish load balancing.

Anyone? Thanks.

networker050184

When connected to two different ISPs your best bet is to just let BGP choose the best paths through either ISP. That is the only way you will have optimal routing. If you just ballance the traffic equally some traffic may take a longer path through one ISP then it would through another.

Paul Boz

Right but if you're receiving two default routes, one from each ISP, you have no way of doing any sort of best-path routing from your network. You need at least partial or full bgp tables to do that. If one is using two default routes I don't think suboptimal internet routing is really a big deal. Wasting an entire link's worth of bandwidth, on the other hand, is.

EdTheLad

If you want to use default routes you would config and advertise them locally in your AS, why would you want to receive bgp default routes? Doesn't make sense,this is not what bgp is for.

Paul Boz

I'm just going over some scenarios in my BSCI book. It references three BGP configuration options.

1.) BGP Default routes (no bgp routing table, for smaller routers, etc). The ISPs in this scenario just pass a default route via BGP to the customer.

2.) Partial BGP routes - Receiving only the routes advertised by the ISPs

3.) Full BGP.

I'm familiar with full BGP in practice. I have never seen either of the other two options. My perspective is from the service provider so I don't know if having default routes is something corporations do or whatever. The book makes it seem like its a big deal for the corporate network so I thought I'd ask.

I figured segmenting the network into areas that receive different default routes is the best way to do it.

networker050184

Just configure static routes and you router will automatically load balance on them. There would really be no advantage of running BGP just to receive a default route.

Paul Boz

I figured as much but its in the book so I studied it.

Turgon

Paul

You may be overthinking things. If you are using default routes to get to each ISP then your router will loadbalance outbound connections using each in turn.

Humper

I would highly recommend reading Internet Routing Architectures, by Basam Halabi. It is an excellent read, the best BGP book I've read so far. The first chapter or two I believe explain why you should or shouldn't use BGP.

apd123

networker050184 wrote: »

Just configure static routes and you router will automatically load balance on them. There would really be no advantage of running BGP just to receive a default route.

You will blackhole traffic if the interface stays up but the circuit is dead. With BGP the peering would drop and you would failover.

networker050184

apd123 wrote: »

You will blackhole traffic if the interface stays up but the circuit is dead. With BGP the peering would drop and you would failover.

True, or you could use an SLA to remove the static route.

kpjungle

Isnt there a way to use IOS track-object feature to monitor if it can reach a certain address, and if not, deem a static route as down? or even take the internet facing interface down, which would make the next hop route go down, and remove the static route, again making the IGP not advertise the default route.

networker050184

kpjungle wrote: »

Isnt there a way to use IOS track-object feature to monitor if it can reach a certain address, and if not, deem a static route as down? or even take the internet facing interface down, which would make the next hop route go down, and remove the static route, again making the IGP not advertise the default route.

Yes using the SLA with a track on the route. You can ping the other side of the link or another address and if it stops responding the route will be removed. The route will then be readded to the routing table when the link comes back up.

apd123

Next issue is if the providers are statically pinning up the route to you then both providers will continue to advertise the route even when connectivity is lost similar to earlier.

kpjungle

apd123 wrote: »

Next issue is if the providers are statically pinning up the route to you then both providers will continue to advertise the route even when connectivity is lost similar to earlier.

True, but the only way to get around that, is if you have a full peering relationship with your ISP, and assuming they dont do any further summary to their peers, which i guess they do? If they just announce a summary for a bunch of their customers, all packets destined for you will still get "caught" by their summary, and a client would send packet destined for your net to the ISP even when your route is advertised to be down with bgp.

Dont know enough about ISP behavior to completely know the details of implementation.

kryolla

Next issue is if the providers are statically pinning up the route to you then both providers will continue to advertise the route even when connectivity is lost similar to earlier.

yeah it just reversed
If I am reading this correctly
you have no control if the ISP black holes traffic inbound to you. All you can do is open a trouble ticket and let them fix it. I would just be concerned about my own network, you can't just start giving out advice on how they should fix their own issues if you want to keep a good relationship with them. Plus that would of been discovered during test and turn up unless you want to answer to upper management during an outage on how come this wasn't discovered when you brought up the circuit.

My 2 cents

apd123

kpjungle wrote: »

True, but the only way to get around that, is if you have a full peering relationship with your ISP, and assuming they dont do any further summary to their peers, which i guess they do? If they just announce a summary for a bunch of their customers, all packets destined for you will still get "caught" by their summary, and a client would send packet destined for your net to the ISP even when your route is advertised to be down with bgp.

Dont know enough about ISP behavior to completely know the details of implementation.

There are two situations one in which you own your own block of IP's and the other in which you are using a subnet of the providers IP space. In the first case you just need to make sure that they will accept your address block and advertise it on to their neighbors. The second situation is more complex because the provider that is giving you IP's will be summarizing so they will have to punch a hole so their advertisement of your subnet can match the other peer.

kpjungle

apd123 wrote: »

There are two situations one in which you own your own block of IP's and the other in which you are using a subnet of the providers IP space. In the first case you just need to make sure that they will accept your address block and advertise it on to their neighbors. The second situation is more complex because the provider that is giving you IP's will be summarizing so they will have to punch a hole so their advertisement of your subnet can match the other peer.

Yep, thats what i thought regarding the summarization. If they give you a "slice" of their block, when they summarize it to other neighbors, then other neighbors will still try to send traffic to that summarization even if the slice you own is down.

In the first scenario, where you own the block yourself (generally a small ISP or large enterprise), then i guess its up to the SLA with your provider, that they not summarize to prevent these cases from happening.

kryolla

how picky can you be with SLA between you and the provider besides a guaranteed uptime and QOS.