[MLB-WIRELESS] ADSL / CABLE Channel Bonding
mr-russ at pws.com.au
Mon Oct 26 15:19:16 EST 2009
Todd Hubers wrote:
> Hi Russel,
> That's helpful - thanks. The instructions I found were
> http://www.cyberciti.biz/tips/linux-bond-or-team-multiple-network-interfaces-nic-into-single-interface.html and
> created a virtual interface, and seemed to have very low level control
> over the upstream links - interacting with MII messages (which enable
> it to detect when a link is down). One of the modes stripes per
> packet, and therefore I understand that this would be impossible
> unless the links being bonded where configured for this (as the Cable
> and ADSL are from two ISPs this is far from possible). Other modes may
> be possible, but your suggestion of using iproute and iptables looks
> like the most likely choice. I see that a TCP stream would need to
> stay linked to a single channel (except for fail over).
Yes, bonding is not what you want.
> The iptables look good for redirecting all RDP traffic automatically.
Well, it will get you a lot further than just the above. Looking at all
the requirements below, most could be fulfilled with a good script and
some monitoring of iptables. But if you suggest that the spill over is
1 minute, is it really worth it? Aren't you better to just put a token
bucket filter on the link. Anything that is big can go into a low
priority low bandwidth queue. That will keep your interactive traffic
quick and the 1G download can chug along with all the leftover
bandwidth. Again you use iptables to tag traffic and iproute to
proiritize it on the link. So iptables will mark TCP sessions larger
than say 2Meg for the low priority queue. What you would see as
somebody downloading, is the first 2M arrives quickly, then it all slows
to whatever is available.
> As for spill-over the ultimate setup would:
> * Watch throughput on eth0 (being the ADSL2+ link with heaps of volume
> in the plan)
> * May also watch the number of TCP sessions - and maybe limit eth0
> to 50 TCP sessions or 80% of bandwidth, which ever comes first
> * Most traffic would be HTTP and therefore TCP sessions would be short
> * When throughput reaches say 80% of a predefined limit for eth0,
> redirect new streams to eth1
> * The "spill over" would be a rare occurance, maybe totalling one
> minute of traffic a day
> I'm not sure if Linux has such scope for that functionality
> out-of-the-box, or whether a custom/third-party application or driver
> would be required.
Hope that helps a little.
More information about the Melbwireless