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é
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
