Dear folks, Here goes my bandwidth manager: INTERNET | |eth0 202.14.41.1 BW.Manager | | | +----eth1----192.168.1.0/24 | +------eth2----192.168.2.0/24 Total incoming bandwidth to eth0 is 1024kbps should be shared to eth1 and eth2, which mean each get 512Kbps and burstable to 1024Kbps if other host is idle. My question is how do i apply HTB to these situation ? As far as i know eth1 and eth2 should be define as parent and cannot be as children. Regards, Rio Martin. -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ . _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Thursday 03 July 2003 10:56, rio@martin.mu wrote:> Dear folks, > Here goes my bandwidth manager: > > INTERNET > > |eth0 202.14.41.1 > > BW.Manager > > | +----eth1----192.168.1.0/24 > > +------eth2----192.168.2.0/24 > > Total incoming bandwidth to eth0 is 1024kbps > should be shared to eth1 and eth2, which mean each get 512Kbps and > burstable to 1024Kbps if other host is idle. > > My question is how do i apply HTB to these situation ? > As far as i know eth1 and eth2 should be define as parent and cannot be as > children.Indeed. What you can do is use imq and add a imq device to your eth0. Redirect all incoming traffic to it and a htb qdisc to the imq device. Create 2 classes : one for eth1 and one for eth2. And voila, eth1 and eth2 can share 1024 kbps. You can have a problem splitting the traffic in the classes because you don''t know the src address when the packets enters your shaper. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Well this can be done easily You have to define a class having rate and ceiling 1024 kbps ( Kilobytes if you want kilobits make its kbits ) in order not to exceed this limit. Then you have to create two subclasses for the two networks by having as rate 512 and ceiling 1024. Then you must make the apropriate filters that will classify the traffic in the right flows. All theese for eth0. So when the 192.168.1.0 is idle 192.168.2.0 will allocate all the 1024 kbps bandwidth but when both will have traffic then they will take 512 each. rio@martin.mu wrote:>Dear folks, >Here goes my bandwidth manager: > >INTERNET >| >|eth0 202.14.41.1 >BW.Manager >| | >| +----eth1----192.168.1.0/24 >| >+------eth2----192.168.2.0/24 > >Total incoming bandwidth to eth0 is 1024kbps >should be shared to eth1 and eth2, which mean each get 512Kbps and >burstable to 1024Kbps if other host is idle. > >My question is how do i apply HTB to these situation ? >As far as i know eth1 and eth2 should be define as parent and cannot be as >children. > >Regards, >Rio Martin. > > > >-------------------------------------------------------------------- >mail2web - Check your email from the web at >http://mail2web.com/ . > > >_______________________________________________ >LARTC mailing list / LARTC@mailman.ds9a.nl >http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > >_______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
you probably need IMQ if eth0 is input for your case On Thu, 3 Jul 2003, rio@martin.mu wrote:> Dear folks, > Here goes my bandwidth manager: > > INTERNET > | > |eth0 202.14.41.1 > BW.Manager > | | > | +----eth1----192.168.1.0/24 > | > +------eth2----192.168.2.0/24 > > Total incoming bandwidth to eth0 is 1024kbps > should be shared to eth1 and eth2, which mean each get 512Kbps and > burstable to 1024Kbps if other host is idle. > > My question is how do i apply HTB to these situation ? > As far as i know eth1 and eth2 should be define as parent and cannot be as > children. > > Regards, > Rio Martin. > > > > -------------------------------------------------------------------- > mail2web - Check your email from the web at > http://mail2web.com/ . > > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > > >_______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
It wont work.. eth0 only for public ip traffic. It wont handle private network traffic. Traffic to private network can be manage through eth1 & eth2 I guess the answer is IMQ .. i''ll try .. Documentation please, or perhaps docum.org already have documentation regarding IMQ ? Regards, Rio Martin. Original Message: ----------------- From: ???????? ????? skekes@pylones.gr Well this can be done easily You have to define a class having rate and ceiling 1024 kbps ( Kilobytes if you want kilobits make its kbits ) in order not to exceed this limit. Then you have to create two subclasses for the two networks by having as rate 512 and ceiling 1024. Then you must make the apropriate filters that will classify the traffic in the right flows. All theese for eth0. So when the 192.168.1.0 is idle 192.168.2.0 will allocate all the 1024 kbps bandwidth but when both will have traffic then they will take 512 each. -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ . _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
On Thursday 03 July 2003 11:38, rio@martin.mu wrote:> It wont work.. > eth0 only for public ip traffic. It wont handle private network traffic. > Traffic to private network can be manage through eth1 & eth2 > > I guess the answer is IMQ .. i''ll try .. > Documentation please, or perhaps docum.org already have documentation > regarding IMQ ?Not much. I never had the time to try imq my self. But it''s easy. With imq you can create virtual devices and you can redirect any traffic to with iptables. So you can redirect all incoming traffic to eth0 to the virutal device. Shaping the traffic can be done by adding a htb qdisc to the imq device. But in your case you will have a filter problem because you don''t know the src address when a packet enter eth0. Stef -- stef.coene@docum.org "Using Linux as bandwidth manager" http://www.docum.org/ #lartc @ irc.oftc.net _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Hi martin, Lot of linux users are using imq. But i dont have time to use it. But yes You can do one thing. Your case etho----wan port 202.14.41.1 eth1---- 192.168.1.0/24 eth1:0---192.168.2.0/24 If you this 2 network connected within the same switch or hub then u can use eth1 for both network if u have different switch or hub for this network then y dont u put the cross cable between this two network and connect it and then manage the bandwidth on both network. give 192.168.1.0/24 bw 512 give 192.168.2.0/24 bw 512 and ceil it both to 512 and u know what u want to do ...when this network is not using the bandwidth allow the other network. its easy u dont need to put the eth2 ..remove it...if u use the about example Joel ----- Original Message ----- From: <rio@martin.mu> To: <lartc@mailman.ds9a.nl> Sent: Thursday, July 03, 2003 1:56 AM Subject: [LARTC] HTB burstable for 2 interface , how ? Dear folks, Here goes my bandwidth manager: INTERNET | |eth0 202.14.41.1 BW.Manager | | | +----eth1----192.168.1.0/24 | +------eth2----192.168.2.0/24 Total incoming bandwidth to eth0 is 1024kbps should be shared to eth1 and eth2, which mean each get 512Kbps and burstable to 1024Kbps if other host is idle. My question is how do i apply HTB to these situation ? As far as i know eth1 and eth2 should be define as parent and cannot be as children. Regards, Rio Martin. -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ . _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> INTERNET> | > |eth0 202=2E14=2E41=2E1 > BW=2EManager > | | > | +----eth1----192=2E168=2E1=2E0/24 > | > +------eth2----192=2E168=2E2=2E0/24 > > Total incoming bandwidth to eth0 is 1024kbps > should be shared to eth1 and eth2, which mean each get 512Kbps and > burstable to 1024Kbps if other host is idle=2E This doesn''t make sense to me. The fact that an internal host is idle does not justify not sending traffic TO it. The suggestions to use IMQ+HTB seem to miss the problem that if someone sends 1024 to eth1 then nobody has a chance to even begine to send anything to eth2. I think you want to allow "borrowing" only as long as the total incoming rate from eth0 is sufficiently less than 1024 to be sure that those sending to the lesser used internal interface can speed up. In effect I think you have to sacrifice some part of your 1024 to make sure the shaping is done at your machine. I''m not sure how much you have to sacrifice. But suppose it''s 24K, so you then have two htb classes that have rate 500, ceil 1000. And the parent class also has ceil 1000. That''s critical. That means that if we send at full rate to eth1 then we still have room for someone to start sending to eth2. Then when someone does start sending, he initially gets 24K to eth2. At that point HTB reduces the traffic to eth1 by 24K in order to stay below total 1000. Then the guy sending to eth2 can increase by 24K which will cause eth1 to drop another 24, etc. As you can see, the amount you "reserve" (you might say "waste") also limits how fast the traffic equalizes. Does this make sense to everyone out there? _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Hi, Don: > INTERNET > | > |eth0 202=2E14=2E41=2E1 > BW=2EManager > | | > | +----eth1----192=2E168=2E1=2E0/24 > | > +------eth2----192=2E168=2E2=2E0/24 > > Total incoming bandwidth to eth0 is 1024kbps > should be shared to eth1 and eth2, which mean each get 512Kbps and > burstable to 1024Kbps if other host is idle=2E > This doesn''t make sense to me. > The fact that an internal host is idle does not justify not sending > traffic TO it. > > The suggestions to use IMQ+HTB seem to miss the problem that > if someone sends 1024 to eth1 then nobody has a chance to even > begine to send anything to eth2. Why not? Ignore those bandwidth controller devices for a moment. TCP flows compete to cope the available bandwidth. If your link capacity is 1024kbit and you start sending 1024kbit to the interface eth1 and sometime later (the time you want) begin to send 1024 kbit to interface eth2, you can be truly sure that when flows stabilize each of them will be try to cope 50% of the available bandwidth defined by the link capacity. Finally each flow will be 512kbit. Now put on your controller devices. They can control the upper level of the flows but no the flows themselve. TCP is always testing the bandwidth availability trying to get more share from it. What stop this? When a packet is dropped the inner congestion control mechanism is fired and TCP reduce automatically its rate. Finally the fight converge to every flow sharing the upper level defined by the controller device, as soon as those flows have enough packets to reclaim it. Conclusion: use your bandwidth controllers but never forget the TCP natural behavior. Best regards, Leonardo Balliache _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
Hi, Don: At 08:34 p.m. 07/07/03 -0700, you wrote:>The point is that if X sends 1024 and Y tries to send 1 but fails, >the firewall cannot tell and therefore can''t do anything about it.Which firewall? In case of having it doesn''t have anything to do here. Let''s put aside any coercive device to concentrate in TCP behavior.>I''m not nearly as confident as you in the tcp mechanisms. First, >the upstream routers might favor one flow over another for whatever >reason. Second, even if tcp works as you''d like, the convergence will >be much faster if there''s some unused bandwidth.Perhaps you are right, perhaps you are not. Who knows? TCP behavior is a funny game with very clear rules. One of them is: first one that loses a packet has to cut its rate by half. Who''s lucky? Do you know? Packets are dropped by routers in a random selection process. TCP flows are always fighting to increase their shares. Sometime one of them is ahead, but, it loses a packet. Like Monopoly. Walk back seven step, man!! you are castigated.>But I think that things really are stacked against the new flow.Why? Are the routers conspiring against it?>First the old one is going fast, and if it happens to lose a packet >to the new one, it will probably barely notice, just receiving a sack >and not slowing down.** to the new one ** I going to understand ** to the old one **. Is not as easy. In fact TCP congestion algorithms are far away for being easy. Simplifying, the game is: if you lose a packet you have to cut your sending window by a half. Check your new congestion window, check your outstanding packets, check your peer advertising window, and depending of this, calculate how many packets you can send, if you can send any, at all.>However, in the reverse case, the new flow is >starting slow, and if it loses a packet it waits for a timeout to send >another one, then if it loses another it waits a longer timeout. >Eventually, when the new flow tries to speed up it''s always bumping >against the old one, causing it to slow down again.Probably the first flow has a higher probability to lose a packet because it has more packets flowing out there. And if it happens, it has to cut its window by a half. At this moment the second flow is at slow-start, its window is increasing almost geometricaly (it doubles each time it receives an ack). Again, who knows? The fight is fighting. Timeout is an extreme case. Probably a duplicate ack advertises the flow that one packet has been lost. Then slow-start is not the answer, just fast retransmit and fast recovery and then congestion avoidance. What about if the routers are RED routers. RED routers conspire (they if fact are designed to conspire!!) against stronger flows, those that maintain more packets in the router queue. Then the first flow has to walk with care. Someone out there is tring to kill one of its packets.>Are you really sure the system is guaranteed to converge to 50-50, or >even to converge at all? I''m not. Please convince me. >In any case, the firewall here is clearly not contributing to this >since it''s not dropping any packets, or even slowing them down.Again any firewall doesn''t matter. I did some work to try to convince you. Have a look at http://opalsoft.net/qos/TCPvsTCP.htm. Finally, to close this pleasing conversation, don''t forget that when you configure your "controller devices" you are not controlling TCP, you are just conspiring against it by killing some packets and using the simple rule, "if you lose a packet, cut your window", to put under control the average throughput. Best regards, Leonardo Balliache _______________________________________________ LARTC mailing list / LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/