Question about load sharing (3 isp)

[CATYO]

Hello guys.

One question about load sharing.

We have one edge-router with 3 different ISP circuits.

(2G , 200M, 200M)

all 3 ISPs provide the default gateway only.

Is there any way to use these circuits effectively? I want to use three circuits at the same time with its full bandwidth as possible as I can .

I am thinkg to enable bgp bestpath as-path multipath-relax but not sure whether this is the best solution or not.

Thank you.

Regards,

[Deepak Kumar]

Hi,

there are multiple options for load balancing on wan interfaces as

1. With static route configuration and assign a command "ip load-sharing per-packet" under the all wan port. 

example: ip route 0.0.0.0 0.0.0.0 8.8.8.8 <your wan gateway>

              ip route 0.0.0.0 0.0.0.0 9.9.9.9

              ip route 0.0.0.0 0.0.0.0 10.10.10.10

Inter gig 0/0

des wan 1

ip load-sharing per-packet

inter gig 0/1

des wan 2

ip load-sharing per-packet

inter gig 0/0

des wan 3

ip load-sharing per-packet

2. Use the PFR as blow link

http://docwiki.cisco.com/wiki/PfR:Solutions:BasicLoadBalancing

3. Use the BGP.

4. With NAT and route-map configuration.

https://www.cisco.com/c/en/us/support/docs/ip/network-address-translation-nat/100658-ios-nat-load-balancing-2isp.html

Regards,

Deepak Kumar

[Richard Burts]

Be very careful about using the load share per packet. I had an experience with a customer who was having performance problems with an application that shared data between two sites. They wanted to improve its performance. So they installed a second link between sites and enabled load share per packet to get full utilization of both links. They found that performance of the application got WORSE with load sharing per packet. The issue was that load share per packet was producing out of order packets and the application reacted badly to out of order packets. We changed load share to per session (the default) and arranged the routing so that this application used one of the circuits and all other applications used the other circuit. This did improve performance of the application.

HTH

Rick

[CATYO]

Thanks for your reply.

How did you tune the routing or policy to meet its goal?

If per packet is not good, I'd like to implement to load sharing by using session base.

[Richard Burts]

In this case there was a server at site 1 that refreshed a data base by receiving large volumes of data from a repository at site 2. So we were able to configure a host specific static route at site 1 for the repository and a host specific route at site 2 for the server. The more general solution would be to use Policy Based Routing to identify the traffic and to set the appropriate next hop.

Yes if you are configuring load balancing you would be safer to use the default of session based sharing since that would put all traffic for a particular session on the same circuit and would eliminate out of order packets.

HTH

Rick

[Joseph W. Doherty]

Rick is spot on with his caution!

Using per-packet load sharing, should show a very nice equal balance of load across its links, but applications can often be adversely impacted. (Some of the new nice load balanced traffic might also be TCP re-transmits.)

As you're probably aware, TCP will handle out-of-order delivery, but depending on the TCP implementation, many will begin to re-transmit packets if the TCP sender "sees" several dup ACKs. This can be mitigated if the threshold for this is increased on the TCP sender.

Other than TCP flows, may, or may not, tolerate much in out-of-order delivery.

The OP situation would probably be one of the best examples of when not to use per-packet load sharing as the links go to different ISPs and they are not all the same bandwidth. (Both attributes would likely yield different times for packet transit between the same source and destination.) Possibly the best situation would be between a pair of devices.

[Joseph W. Doherty]

Possibly the best solution might be PfR since it can proportionally and dynamically load balance.

[CATYO]

Thanks for your reply.

I will consider PfR !