On Mon, 13 Jul 1998, Patrick W. Gilmore wrote:
> At 10:33 PM 7/13/98 +0000, brad wrote:
>
> >> BTW, if you do decide to use load balancing, I *highly* recommend
> >> flow-switching. Otherwise your load balancing can get a bit... uneven. ;)
> >> Even with flow-switching, you'll find it's not perfect. I hear you can do
> >> per-packet load balancing with DCEF and not hit your main proc, but I
> >> haven't tried it. Does anyone know if that will kill the VIP proc? And if
> >> so, what rate will it handle?
> >>
>
> A "4 tuple load share hash" can easily become uneven when you have a small
> pipes - which is common if you are load balancing. Suppose I have two T1s
> to a
> POP out of which I have sold three T1s. I can easily get a significant load
> (say 25 to 50%) on the two upstream T1s from two of the downstream T1s. Then
> someone on the third T1 decides to download a big file and notices that he
> never gets more than 50% of his bandwidth. Per-packet load balancing would
> solve this problem.
As a general rule of thumb, per packet load balancing is discouraged.
This causes a lot of packet reordering, which plays hell with TCP stacks
that implement RFC 2001 (fast retransmit and recovery). This has a way of
killing TCP throughput.
The better solution is to do what was originally quoted. The older
route-cache solutions (fast, sse, cbus, autonumous, etc) would balance on
a per desitination basis. Netflow switching tends to load interfaces much
better because it balances per flow.
So while per packet offers the best granularity for loading your
interfaces, you'll might end up kissing away alot of the gains due to
retransmitted packets and slow-starts. YMMV.
You might want to consider something that keeps packet order. I haven't
tried MPP in this situation, but that'd do it. I can't say what type of
overhead 3 T1's using MPP would put on the CPU. Probably not good. Or
use an IMUX. Or a FT3.
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:13:13 EDT