LARTC - Jan 2006 - qdisc''s useless in my case?

Hi!

First, thanks for this great howto! Second, sorry for my english, it''s
not
the best!
I have a question about the Linux qdisc. My configuation in short:

Linux Box with 4 100Mbit ethernet inferfaces:
- eth0 goes to a switch with ~60 PC''s connected wo use the internet  
connection. (192.168.1.200)
- eth1 goes to an cable Modem with 5Mbit transfer speed
- eth2 connects the 2. cable modem.
- eth3 is a 100Mbit Cable to the next router, with the subnet  
192.168.2.0/24 (same thing as this one) (192.168.5.1)

With your howto I managed it to balance the traffic from eth0 over the two
cable modems to the internet:

router:~# ip route show
192.168.5.0/24 dev eth3  proto kernel  scope link  src 192.168.5.1
192.168.2.0/24 via 192.168.5.2 dev eth3
62.143.132.0/24 dev eth1  proto kernel  scope link  src 62.143.132.84
62.143.132.0/24 dev eth2  proto kernel  scope link  src 62.143.132.156
192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.200
default
         nexthop via 62.143.132.1  dev eth1 weight 1
         nexthop via 62.143.132.1  dev eth2 weight 1

Works fine! Then I wend on reading your howto and came to the chapter
"Queueing Disciplines for Bandwidth Management". Sometimes an
''expert''
in the group of users starts some kind of P2P-Software without an  
upload-limit wich
then slows down all connections very badly. To lessen this effect I  
thought of
adding the SFQ-qdisc to the interfaces eth1 & eth2. In the description of  
SFQ
I read "disallows any single conversation from drowning out the rest".

Now what I worry about ist if this has any effect at all. Maybe the kernel  
sends
all the Packets from the LAN (from eth0) to the to cable-modems, which are
connected via 100Mbit crossover-cable and the modem queues the packets  
itself
and drops the ones exceeding the maximum upload rate. With an constant  
empty
queue in the kernel it would make no differences if fifo_fast or sfq is  
the qdisc, right?

So my question is: Am I right? Is it useless to assign sfq to eth1 & eth2?  
What would
be an alternative solution?

PS: I read seph''s mail from Thu Jan 5 17:02:10 CET 2006. I had the same
problem. Solution:
Use a kernel > 2.6.11 (don''t know exactly when this was fixed) but
with
2.6.14.3 and 2.6.15
this "MASQUERADE: Route sent us somewhere else." never appeared again!
And: assure that
CONFIG_IP_ROUTE_MULTIPATH_CACHED is not set, it throws a spanner in the  
works!

  Thanks,

   André

André Matuschek wrote:
> Now what I worry about ist if this has any effect at all. Maybe the 
> kernel  sends
> all the Packets from the LAN (from eth0) to the to cable-modems, which are
> connected via 100Mbit crossover-cable and the modem queues the packets  
> itself
> and drops the ones exceeding the maximum upload rate. With an constant  
> empty
> queue in the kernel it would make no differences if fifo_fast or sfq is  
> the qdisc, right?
> 
> So my question is: Am I right? Is it useless to assign sfq to eth1 & 
> eth2?  What would
> be an alternative solution?
Yes you are right. You need to use htb/hfsc/cbq on both eths and limit 
the traffic headed for the internet to < each cable rate. You could use 
sfq as part of the setup, it is better to try and seperate interactive 
traffic from bulk and only use sfq on the bulk. You could also limit 
inbound traffic by shaping on the lan facing eth (if it goes to both lan 
eths then it''s more complicated but possible).

Andy.