[c-nsp] ASR1001X additional EBGP peer

Mark Tinka mark.tinka at seacom.mu
Sun Mar 8 06:02:03 EDT 2020



On 8/Mar/20 09:48, james list wrote:

> We'd like to add a new EBGP peering on the same router (with full routing
> received from a second carrier) in order to load balance traffic (mainly in
> output).
> The question is: do you see any issue in terms of
> performance/memory/whatelse in adding a new EBGP peering ?
> Which is the best way to try to load balance in output ?

The ASR1001-X ships with 8GB RAM. That's more than enough to hold 2 full
tables.

Load balancing on egress for BGP is not like load balancing for ECMP.
Your router will decide which of your upstreams has the best path toward
a destination. This is not always an exact science as it will depend on
if you are buying from a large global carrier or mid-size global
carrier, a large local/regional carrier or a mid-size local/regional
carrier.

BGP always chooses one best path. So if both of your upstreams announce
the same path, only one of them will be used. You can use features like
BGP Multipath to load balance egress traffic over the two upstreams, but
this isn't the default BGP behaviour, and you'll have to turn it on and
confirm it does what you want.

The good news is that the upstream with the best path toward a
destination will always be used, so your customers will be happy about
that. But it may not result in equal sharing of traffic. You might have
to tweak a number of BGP bits about to get it to close to 50/50 as
possible, if that is your desire.

For us, we connect to a ton of transit providers and peers. Our
motivation isn't to load balance traffic (in either direction), but to
provide shortest path routing as well as redundancy. Often times, we've
had to manually prefer certain egress destinations via specific upstream
providers than what the default chose, as BGP doesn't typically take
things like latency into account.

Mark.





More information about the cisco-nsp mailing list