At 08:27 PM 7/13/98 -1000, John Engelhart wrote:
>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.
I can definitely see this happening if you have two completely separate
routes,
but if you have two links between two routers, the packets should remain
(relatively) in order. For instance, the situation where you have two POPs
connected via two T1s. Even if they arrive out of order, they should be close
enough to not cause retransmits.
>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.
Agreed. I personally use flow switching whenever I load balance, but I'm
always looking for better solutions.
>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.
I have a downstream who tried MPPP on T1s with a 3640 without even doing BGP.
The results were abysmal. Granted, an RSP4 has much more power, but if just
two T1s kills a 3640, I think it would suck enough power out of an RSP4 to
make
it useless for things like customer links and BGP updates.
The IMUX/FT3 solution is, of course, the best. But unfortunately the bean
counters tend to get in the way of good engineering. ;)
TTFN,
patrick
**************************************************************
Patrick W. Gilmore voice: +1-650-482-2840
Director of Operations, CCIE #2983 fax: +1-650-482-2844
PRIORI NETWORKS, INC.
<http://www.priori.net/>http://www.priori.net
"Tomorrow's Performance.... Today"
**************************************************************
This archive was generated by hypermail 2b29 : Sun Aug 04 2002 - 04:13:13 EDT