Transit Links Ether-channel?

[shinakuma123]

Currently our router in office A has a 1 gig circuit connecting it to router in office B, (L3 link, office A and Office B routers are BGP neighbors)

I want to increase link bandwidth capacity but also have carrier redundancy, is it possible to purchase another 1 gig circuit with another carrier and bundle both these links into a port channel, giving 2 gig capacity and if 1 carrier fails, the 1 gig remains up in the port channel, as long as both carriers don't flop at the same time. would that work with these being L3 and from different carriers?

How would such config look like?

Please advise

thanks

[Jon Marshall]

To be honest I don't know as I have never done that.

There could be issues if the links had different latencies I guess.

But I don't see why you need etherchannel. If you had two links at the same speed then your routing protocol should see equal cost paths so it will do per destination load sharing so you would achieve the same thing in effect.

And if one link failed all traffic would go over the other as well.

If you are were using statics you might need to use IP SLA but personally I would run a dynamic routing protocol.

Jon

[shinakuma123]

Am worried from a Link saturation point of view.... if bundled that makes 2gbps, if not a port-then its essentially 2 x 1gig pipes.

Running BGP, is there a way to manually hardcode BGP to load balance equally between these 2 links? essentially traffic going across these 2 links will be destined to 2 subnets, a /21 and a /22... 

Jon can you advise on methods i can deploy to achieve a 50/50 load-balance at all times

thanks

[Jon Marshall · Accepted solution]

You can get BGP to use multiple paths but it requires more configuration because it doesn't do it by default.

The problem with BGP or etherchannel is you can never guarantee 50/50 at all times because you don't now how much traffic there is per flow however that flow is determined ie.

with BGP it would based on the destination IP

with etherchannel you have more options (or you do with L2 etherchannel, not sure about L3).

Neither of the above methods takes into account link utilisation.

So you may have 3 flows or conversations and 1 of them is on one link transferring a very large file while the other 2 are on the other link browsing web pages which means the utilisation of the links is very different even though there are more flows on the less utilised link.

If you had an idea of which flows generated the most traffic you could manipulate your routing but this is really hard to do and it is not dynamic in nature in terms of adapting to different flows.

There is a technology called PfR that may be better at this but I can't really comment as I have never used it although there is a regular poster in these forums who has so maybe he will see this and add his comments.

Edit - just to clarify as I didn't make it clear even if you bundled the links into an etherchannel for any given flow it will use the same link within the etherchannel and what it can't do is spread the same flow across both links in any one direction.

Jon

[Jon Marshall]

Just one final point.

If you use per packet load sharing with two L3 links and a routing protocol then you would probably get a lot closer to sharing both links evenly.

The main issue with it is packets arriving out of order at the other end which can cause performance issues.

A number of  posters on these forums recommend against it using in general because of this.

Jon

[shinakuma123]

interesting, so I guess this will only apply to UDP traffic right and will affect things like Voice and Video traffic? since tcp sequences and re-orders packets with SYN/ACK?

Why would packets arrive out of sequence if both links have the same cost, go the same length and are the same speed ? I would have thought if one of the two links had different properties then this may happen...

[Jon Marshall]

TCP can also suffer from out of order packets because it can cause a lot of retransmissions which can degrade the performance quite severely.

Packets could arrive out of sequence because of latency on the link, how may packets are already queued to be placed on the link etc. Again even with per packet load sharing there is no real concept of link utilisation ie. just that every other packet is placed on the other link.

There is absolutely no guarantee that your packets arrive at the destination host in the exact order they were sent.

Whereas with per destination load sharing in general they should because they have to be queued in order to be transmitted onto the link and they are received in that order by the other end.

Jon