Server : eth0 - internet DSL eth1 - LAN wlan0 - wireles LAN I want server to share bandwith from eth0 evenly for users on eth1 and wlan0. How can i make it ? Is it possible ? As far as i know htb splits outgoing bandwith on one device only. ---------------------------------------------------- Grypa? Damy radę! Sprawdź jak jej zapowbiegać, a jeśli już za późno ...jak leczyć - grypa.wp.pl http://klik.wp.pl/?adr=www.grypa.wp.pl&sid=636
Hariett Jones wrote:> I want server to share bandwith from eth0 evenly for users on eth1 > and wlan0. How can i make it ? Is it possible ? As far as i know htb > splits outgoing bandwith on one device only.This is the most braindead defect of Linux (IMHO): You can''t, because you can only shape outgoing traffic on an interface. However, some people have found that it works just fine if only Linux would allow it, but due to the rule that "You can only shape outgoing traffic on an interface" you have to make an intermediate fake device where the traffic shaping can take place. The Intermediate Message Queue (IMQ) is a patch for 2.4 and 2.6 and will allow you to take all the traffic coming in from eth0 and pipe it via imq0 before routing so you can traffic shape IMQ0. For kernel 2.6.16 there is a new feature called IFB which does the same thing (in this context anyway) as IMQ, so if you can upgrade your kernel, then this might be the best choice.
Flemming Frandsen schrieb:> Hariett Jones wrote: > >> I want server to share bandwith from eth0 evenly for users on eth1 >> and wlan0. How can i make it ? Is it possible ? As far as i know htb >> splits outgoing bandwith on one device only. > > This is the most braindead defect of Linux (IMHO): You can''t, because > you can only shape outgoing traffic on an interface.Yes, you can. Easily. And you don''t need IMQ/IFB. eth1->eth0 and wlan0->eth0 are easy. Classical outgoing shaping. eth0->eth1 and eth0->wlan0 are similar. Outgoing shaping on eth1 and wlan0 each with a limit of half the incoming bandwidth of eth0. I had to learn that Linux can perform most of the tasks people claim are impossible. Some involve a lot of iproute2 trickery and even the standard Howtos may tell you the problems can''t be solved. However, there are some cases where IMQ/IFB is useful. I don''t want to bash these intermediary devices, they''re just abused too many times. Regards, Carl-Daniel -- http://www.hailfinger.org/
>> This is the most braindead defect of Linux (IMHO): You can''t, because >> you can only shape outgoing traffic on an interface. > > Yes, you can. Easily. And you don''t need IMQ/IFB. > > eth1->eth0 and wlan0->eth0 are easy. Classical outgoing shaping. > eth0->eth1 and eth0->wlan0 are similar. Outgoing shaping on eth1 and > wlan0 each with a limit of half the incoming bandwidth of eth0.This is exactly what I''m doing now, and it''s not an optimal solution. It''s a rather stupid hack that gets worse each time you add an interface. My gatway has 3 internal interfaces and I absolutely detest that I can''t use more than 1/3 of the lines download capacity on each of these three networks because of the poor design of Linux traffic shaping. Currently (pre-2.6.16) you can only attach a real traffic shaper to the the output of a device, but why not allow a traffic shaper to be attached to the input of a device, without any of the IMQ/IFB nonsense? I think the problem is that attaching the trafficshaper to the output queue is easy whereas attaching it to the input is hard as there is no queue there to build from, so noone bothered to write it. Luckily we can just upgrade to 2.6.16 at some point and this problem will mostly be solved.> However, there are some cases where IMQ/IFB is useful. I don''t want > to bash these intermediary devices, they''re just abused too many > times.Well, shaping incoming traffic correctly is exactly what IMQ/IFB was written for, so it''s hardly abuse. -- Flemming Frandsen, NrVissing.Net administrator.
On Mon, 16 Jan 2006, Flemming Frandsen wrote:> Currently (pre-2.6.16) you can only attach a real traffic shaper to the > the output of a device, but why not allow a traffic shaper to be attached > to the input of a device, without any of the IMQ/IFB nonsense? > > I think the problem is that attaching the trafficshaper to the output > queue is easy whereas attaching it to the input is hard as there is no > queue there to build from, so noone bothered to write it.No, attaching to the input is just as easy as to the output. The reason that isn''t implemented is that it wouldn''t really be useful. Say you''re sharing bandwidth between 2 users, A and B. Suppose A is sending more agressively than B; then, you can throw away A''s overage packets, giving A and B equal shares of your upstream bandwidth. Some LAN bandwidth is wasted by A, but this isn''t much if A is running a good TCP. No uplink bandwidth is wasted. On the other hand, say A and B are downloading large files, and A''s server is sending more than B''s server. The router at your ISP is going to send you whatever gets there first, so that''ll mostly be A''s traffic. If you now shape this on input, you''ll be throwing away packets that have already gotten to you, and took up downlink bandwidth. By throwing out packets going to A, you can make A and B have "fair" shares of the bandwidth; but B''s share won''t actually increase (and A''s share will get smaller) unless A''s server starts sending slower. (This is why A''s server should be running ECN.) The only way to do downlink shaping without wasting your bandwidth would be at the ISP - the other end of your weakest link to the net. Unfortunately, I don''t know of any ISP that will do shaping for you. Alexey
Alexey Toptygin wrote:> No, attaching to the input is just as easy as to the output. The reason > that isn''t implemented is that it wouldn''t really be useful.You are full of it. What everybody who asks for shaping want is mainly ingress shaping and it works just fine. When TCP starts to notice that packets are getting lost it will throttle down and transmit slower, just like any non-idiotic protocol, because that''s the way the Internet works. You are right that the packets that have already traversed the DSL line have consumed bandwidth that can never be reclaimed, but the point is that once you start dropping packets then fewer will follow and the situation will stabilize. The fact remains that ingress shaping is immensely useful and that it works. Linux traffic shaping doesn''t support it out of the box (pre 2.6.16) and that''s because it was hard(er) to implement, not because it''s not useful it is in the real world.
Flemming Frandsen schrieb:> The fact remains that ingress shaping is immensely useful and that it > works.I agree. Ingress shaping, when done properly, is very useful. According to my experience, one of the main characteristics of traffic control (both ingress and egress) is that its effects are often counter-intuitive and you only realize it after seeing it in action. The "obvious things" turn out to be plainly wrong. Yours sincerely, Peter -- http://www.shurdix.org - Linux distribution for routers and firewalls
Flemming Frandsen schrieb:> Alexey Toptygin wrote: > >> No, attaching to the input is just as easy as to the output. The >> reason that isn''t implemented is that it wouldn''t really be useful. > > > You are full of it.If "it"=="knowledge", then you''re probably right.> What everybody who asks for shaping want is mainly ingress shaping and > it works just fine. > > When TCP starts to notice that packets are getting lost it will throttle > down and transmit slower, just like any non-idiotic protocol, because > that''s the way the Internet works. > > You are right that the packets that have already traversed the DSL line > have consumed bandwidth that can never be reclaimed, but the point is > that once you start dropping packets then fewer will follow and the > situation will stabilize. > > The fact remains that ingress shaping is immensely useful and that it > works. > > Linux traffic shaping doesn''t support it out of the box (pre 2.6.16) and > that''s because it was hard(er) to implement, not because it''s not useful > it is in the real world.Please check your facts. Since you only talk about dropping packets and never about queues, the following has been available for years in mainline kernels: http://lartc.org/howto/lartc.adv-filter.policing.html Regards, Carl-Daniel
>>> No, attaching to the input is just as easy as to the output. The >>> reason that isn''t implemented is that it wouldn''t really be useful. >> You are full of it. > > If "it"=="knowledge", then you''re probably right.No, I was aiming more for BS.> Since you only talk about dropping packets and never about queues,Well, naturally the way to decide what packets to drop is to have it go though various queues, but in the end it''s all about dropping packets.> the following has been available for years in mainline kernels: > http://lartc.org/howto/lartc.adv-filter.policing.htmlYes, but that doesn''t change the fact that it''s useless, there is no way to set up a HTB tree and assign SFQ''s to each leaf like you can on the outbound traffic. On my network I have 41 subnets, each a /24 and each subnet needs to get a fair share of both inboud and outbound bandwidth. The 41 subnets are accessed from the gateway via 3 different network interfaces. Outbound shaping is easy and correct, there is just one HTB tree with an SFQ for each subnet. Inbound shaping is ugly and incorrect, because I have to have 3 different HTB trees (one for each internal interface) that each has to get 1/3 (actually weighted by number of subnets behind each interface) of the total bandwidth. That means that max downstream is 800kb/s for the users where it ought to be 1600kb/s, which sucks because most traffic to the users is very bursty. It would have been a much nicer design to be able to put the 3 inbound HTB trees into one inbound tree on the external interface, just like the outbound tree. Ingress shaping *is* very useful and it''s a pity that Linux has taken this long to gain support for it. -- Flemming Frandsen, NrVissing.Net administrator.
Samuel Díaz García wrote:> Try IMQ (Intermediate Message Queue) http://www.linuximq.net.I''ve seen it and tried it, but for some reason the imq module I built on another machine than the router (it boots from flash, so no gcc) didn''t work, the module loaded correctly, but I couldn''t initialize the imq0 device. I''m going to have to build a new router with the same specs soon anyway, so that one will have 2.6.16 and thus IFB, once that works I''ll upgrade the existing router and all will be well.