Helo, I have a 4096Kbit / 1024Kbit (Download / Upload). I have about 100 users connected to my firewall. I would like to shape all traffic, and I think about one queue per user with bandwidth limit and priority, so I created about 200 queues (100 per upload and 100 per download). Below is a only scrap of my configuration. - tcdevices eth0 100000kbit 100000kbit #LAN eth1 4000kbit 900kbit #WAN - tcclasses #INTERFACE MARK RATE CEIL PRIORITY OPTIONS eth1 101 128kbit 512kbit 4 eth0 101 512kbit 2048kbit 4 - tcrules 101 eth0:192.168.0.101/32 0.0.0.0/0 all - 101:F eth1:0.0.0.0/0 192.168.0.101/32 all - Do You think it is a good idea to shape traffic with this kind of limitations? I have no enough experience with bandwidth limitations. Can someone rate this configuration? Should I improve this shaping ? Thank you a lot, Best regards, K. ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword
Snmpget wrote:> Helo, > I have a 4096Kbit / 1024Kbit (Download / Upload). I have about 100 > users connected to my firewall. I would like to shape all traffic, and > I think about one queue per user with bandwidth limit and priority, so > I created about 200 queues (100 per upload and 100 per download). > Below is a only scrap of my configuration. > > - tcdevices > eth0 100000kbit 100000kbit #LAN > eth1 4000kbit 900kbit #WAN > > - tcclasses > #INTERFACE MARK RATE CEIL PRIORITY OPTIONS > eth1 101 128kbit 512kbit 4 > eth0 101 512kbit 2048kbit 4 > > - tcrules > 101 eth0:192.168.0.101/32 0.0.0.0/0 all - > 101:F eth1:0.0.0.0/0 192.168.0.101/32 all - > > > Do You think it is a good idea to shape traffic with this kind of > limitations?No. a) There is nothing wrong with a single user using all available bandwidth if that user is the only one using the network. b) What I prefer is to assign priorities, guarantees and maximums based on the TYPE of traffic (web, mail, p2p, etc) rather than by IP address. It scales *much* better. c) In addition to HTB, Shorewall configures each interface to use SFQ which guarantees fairness among traffic with the same priority. So one user can''t monopolize the traffic if you take my approach. d) What you are doing is a pain to set up and configure and forces each packet through your firewall to pass through 200 rules! In the xtables addons, there is an IPMARK target which will do what you are doing in a single rule; but you would need to use it out of a Shorewall extension script. e) You have 100 users which you are guaranteeing 128kbit each for upload. So your total outgoing guarantee on eth1 is > 12800kbit even though the total capacity of the link is only 900kbit. So your configuration will work miserably. ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword
> No. > > a) There is nothing wrong with a single user using all available > bandwidth if that user is the only one using the network. > > b) What I prefer is to assign priorities, guarantees and maximums based > on the TYPE of traffic (web, mail, p2p, etc) rather than by IP address. > It scales *much* better. > > c) In addition to HTB, Shorewall configures each interface to use SFQ > which guarantees fairness among traffic with the same priority. So one > user can''t monopolize the traffic if you take my approach. > > d) What you are doing is a pain to set up and configure and forces each > packet through your firewall to pass through 200 rules! In the xtables > addons, there is an IPMARK target which will do what you are doing in a > single rule; but you would need to use it out of a Shorewall extension > script. > > e) You have 100 users which you are guaranteeing 128kbit each for > upload. So your total outgoing guarantee on eth1 is > 12800kbit even > though the total capacity of the link is only 900kbit. So your > configuration will work miserably.Thank you for your answer. I read again documentations about shaping and HTB and I decided to change ma queues according to your propositions. Below is a simple configurations: tcrules: 1:F 0.0.0.0/0 0.0.0.0/0 icmp echo-request 1:F 0.0.0.0/0 0.0.0.0/0 icmp echo-reply 1:F 0.0.0.0/0 0.0.0.0/0 tcp 53 1:F 0.0.0.0/0 0.0.0.0/0 udp 53 1:F 0.0.0.0/0 192.168.0.199/32 tcp 22 2 192.168.0.0/24 0.0.0.0/0 tcp 80,443 2:F eth1 192.168.0.0/24 tcp 80,443 3 192.168.0.0/24 0.0.0.0/0 tcp 25,465,110,143,993,995 3:F eth1 192.168.0.0/24 tcp 25,465,110,143,993,995 4 192.168.0.0/24 0.0.0.0/0 all - 4:F eth1 192.168.0.0/24 all - tcclasses: eth1 1 5*full/10 full 1 tcp-ack,tos-minimize-delay eth0 1 5*full/10 full 1 tcp-ack,tos-minimize-delay eth1 2 3*full/10 9*full/10 2 eth0 2 3*full/10 9*full/10 2 eth1 3 2*full/10 9*full/10 3 eth0 3 2*full/10 9*full/10 3 eth1 4 2*full/10 8*full/10 4 default eth0 4 2*full/10 8*full/10 4 default Generally I had a priority per service, You are absolutly right that build about 200 (and more) queues per user is not good idea. I think per service configuration works much better and faster. What do you think about my configuration, Should I more improve this ? Thank you a lot ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword
Snmpget wrote:>> No. >> >> a) There is nothing wrong with a single user using all available >> bandwidth if that user is the only one using the network. >> >> b) What I prefer is to assign priorities, guarantees and maximums based >> on the TYPE of traffic (web, mail, p2p, etc) rather than by IP address. >> It scales *much* better. >> >> c) In addition to HTB, Shorewall configures each interface to use SFQ >> which guarantees fairness among traffic with the same priority. So one >> user can''t monopolize the traffic if you take my approach. >> >> d) What you are doing is a pain to set up and configure and forces each >> packet through your firewall to pass through 200 rules! In the xtables >> addons, there is an IPMARK target which will do what you are doing in a >> single rule; but you would need to use it out of a Shorewall extension >> script. >> >> e) You have 100 users which you are guaranteeing 128kbit each for >> upload. So your total outgoing guarantee on eth1 is > 12800kbit even >> though the total capacity of the link is only 900kbit. So your >> configuration will work miserably. > > > Thank you for your answer. I read again documentations about shaping and HTB and > I decided to change ma queues according to your propositions. Below is > a simple configurations: > > tcrules: > 1:F 0.0.0.0/0 0.0.0.0/0 icmp echo-request > 1:F 0.0.0.0/0 0.0.0.0/0 icmp echo-reply > 1:F 0.0.0.0/0 0.0.0.0/0 tcp 53 > 1:F 0.0.0.0/0 0.0.0.0/0 udp 53 > 1:F 0.0.0.0/0 192.168.0.199/32 tcp 22 > > 2 192.168.0.0/24 0.0.0.0/0 tcp 80,443 > 2:F eth1 192.168.0.0/24 tcp 80,443 > > 3 192.168.0.0/24 0.0.0.0/0 tcp 25,465,110,143,993,995 > 3:F eth1 192.168.0.0/24 tcp 25,465,110,143,993,995 > > 4 192.168.0.0/24 0.0.0.0/0 all - > 4:F eth1 192.168.0.0/24 all - > > tcclasses: > eth1 1 5*full/10 full 1 > tcp-ack,tos-minimize-delay > eth0 1 5*full/10 full 1 > tcp-ack,tos-minimize-delay > > eth1 2 3*full/10 9*full/10 2 > eth0 2 3*full/10 9*full/10 2 > > eth1 3 2*full/10 9*full/10 3 > eth0 3 2*full/10 9*full/10 3 > > eth1 4 2*full/10 8*full/10 4 default > eth0 4 2*full/10 8*full/10 4 default > > > Generally I had a priority per service, You are absolutly right that > build about 200 (and more) queues per user > is not good idea. I think per service configuration works much better > and faster. What do you think about my configuration, > Should I more improve this ?It is not possible to look at a set of rules and tell if they are ''good'' or not. That is because we don''t know what kind of services you provide. If you are running servers, your rules are not good at all since they categorize traffic only by DEST PORT. Responses from servers need to be categorized by SOURCE PORT. ------------------------------------------------------------------------------ This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword