BGP Multihoming 2 providers full or partial?

Joseph Jackson jjackson at aninetworks.net
Sun May 31 11:41:18 UTC 2015


Can your devices support a full table?  

You can load balance  outbound traffic easily with out doing a full table.   THo that won't be the shortest AS path.  In regards to cost savings how were you thinking of doing so?  Does one provider charge more?  Just use the cheaper provider.

-----Original Message-----
From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of Maqbool Hashim
Sent: Friday, May 29, 2015 3:37 AM
To: nanog at nanog.org
Subject: BGP Multihoming 2 providers full or partial?

Hi,


We are an enterprise that are eBGP multihoming to two ISPs. We wish to load balance in inbound and outbound traffic thereby using our capacity as efficiently as possible. My current feeling is that it would be crazy for us to take a full Internet routing table from either ISP. I have read this document from NANOG presentations:


https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0CCoQFjAA&url=https%3A%2F%2Fwww.nanog.org%2Fmeetings%2Fnanog41%2Fpresentations%2FBGPMultihoming.pdf&ei=cyRnVb--FeWY7gbq4oHoAQ&usg=AFQjCNFsMx3NZ0Vn4bJ5zJpzFz3senbaqg&bvm=bv.93990622,d.ZGU


The above document reenforces my opinion that we do not need full routing tables. However I was seeking some clarity as there are other documents which suggest taking a full routing table would be optimal. I "guess" it depends on our criteria and requirements for load balancing:


- Just care about roughly balancing link utilisation

- Be nice to make some cost savings


We have PI space and two Internet routers one for each ISP. Either of our links is sufficient to carry all our traffic, but we want to try and balance utilisation to remain within our commits if possible. I am thinking a "rough" approach for us would be:


- Take partial (customer) routes from both providers

- Take defaults from both and pref one


Maybe we can refine the above a bit more, any suggestions would be most welcome!


Many Thanks




More information about the NANOG mailing list