我覺得這篇文章不錯 所以加來進來喔
作者
[email protected] (We did start the fire.), 看板 linux
標題 Re: Linux 上使用 NAT 達到網路頻寬分享: 三思而後玩
時間 台大計中椰林風情站 (Sun Jan 28 14:07:32 2001)
────────────────────────────[←離開] [PgUp] [PgDn]
實在太多posts關於多重internet link,個人心得請指教:
1. "load balancing" between two different IP routes:
There is ECMP(equal cost multi path) in after Linux 2.2 Kernel.
However, in many cases you would not be pleased with the results.
It might be wise not to implement this for corporate usage.
2. The reasons that the result might be bad:
a. MTU(maximum transfer unit) of the paths might be different.
b. Variable latency of different paths. Packs tend to arrive even
more out-of-order. When 3 or more packts are received before a
"late" packet, TCP starts the fast-retransmit mode. This will consume
extran bandwidth, and possibly cause more packet loss.
c. Traceroute/ping may be less reliable for debugging.
3. What is needed:
a. an implementation which follows RFC2991 in minimizing active flows
affected by adding/deleting of next-hop.
3. What is needed:
a. an implementation which follows RFC2991 in minimizing active flows
affected by adding/deleting of next-hop.
b. the routing has to work for multicast, which need to have a single
next-hop route until the rendezvous point.
Today, the timeouts are not propagated to the routing code in 2.2 Kernel, so
you will have to do a ifconfig down to be able to switch to a second route
in the case of a down next-hop.
In plain English: If you have two route, and you pull one cable, your Linux
won't switch to the second automatically. Some people are writing daemons to
detect if the hext-hop is active.
You may want to read the 2.4 kernel code.
If you run a routed/gated to resolve the routing problem, you still need to
check if it RFC2991 compliant, for the sake of your network.
Regards,
abe