[afnog] IP transit and Load Balancing

[Joey ESQUIBAL]

Hi Mark,

> On Jun 10, 2015, at 10:42 AM, Mark Tinka <mark.tinka at seacom.mu> wrote:
> 
> 
> 
> On 9/Jun/15 18:45, Nishal Goburdhan wrote:
>> 
>> 
>> in general having two transit providers is a good thing.  three is
>> still ok, but more than that (ie. four and greater) becomes a
>> nightmare to deal with, so, you’re already off to a good start, if you
>> have just two;  no reason to change that!
> 
> This is a good point to note. Too much redundancy can make things difficult.
> 
> On the other hand, we, as an example, have a reasonably significant
> number of interconnects to transit provider (a lot more than 4), but are
> able to continue announcing consistently (without de-aggregating,
> prepending, e.t.c.) because we also do a lot of peering at major
> exchange points. It also helps that the interconnects to the exchange
> points and to the transit providers is always the same minimum or higher.

So the peering helped at major exchange points. But it’s actually tricky for us because the major exchange points like AMS-IX, LINX, etc. are all in Europe. This leaves me still no option to do de-aggregation.

> 
> This can work well if you take the time to carefully choose your transit
> providers, and also work hard on peering most of your transit traffic away.
> 
> But I do realize that this might not be possible for everyone to do, for
> various reasons. If you find yourself in this scenario, then choosing
> providers who can offer you BGP communities that allow you to influence
> how they treat your traffic will go a long way to ensuring you maximize
> both your transit and backbone bandwidth. There a lot of good transit
> providers out there that can offer you this capability. And of course,
> keep them down to two; three at the most if you must.

Might be the right idea to ask here but I’ll ask anyway about transit providers you can recommend else you may send it to me directly.

> 
> Mark.
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.afnog.org/pipermail/afnog/attachments/20150611/65fb134e/attachment.html>