Ok, shaping on Linux is new to me.. so bear with me if i am just stupid. curtain:/etc/shorewall# grep TC shorewall.conf | grep -v ^# TCP_FLAGS_LOG_LEVEL=info TC_ENABLED=Yes CLEAR_TC=Yes TCP_FLAGS_DISPOSITION=DROP curtain:/etc/shorewall# So it should be enabled, right? ---- tcrules ---- 1 eth0 0.0.0.0/0 all 2 eth1 0.0.0.0/0 all 2 eth2 0.0.0.0/0 all 3 fw 0.0.0.0/0 all 20 192.168.0.161/32 0.0.0.0/0 tcp 7000:7010 21 0.0.0.0/0 192.168.0.161/32 tcp 7010:7010 Now, shouldnt this mark all packets to / from .161 to our little daemon on ports 7000:7010 with handle 20 and 21? and here is my tcstart run_tc qdisc add dev eth0 root handle 1: htb default 30 run_tc class add dev eth0 parent 1:1 classid 1:10 htb rate 14kbit ceil 38kbit burst 15k prio 1 run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 20 fw classid 1:10 run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 21 fw classid 1:10 curtain:/etc/shorewall# Now, i pretty much thpught this would limit all traffic to/from those ports to a crawl? But it is still shooting along quite rapidly. Am i missing something stupid, or simply not thinking straight? Internet connection is on eth0, and the local segment on eth2
j2 wrote:> Ok, shaping on Linux is new to me.. so bear with me if i am just stupid. > > curtain:/etc/shorewall# grep TC shorewall.conf | grep -v ^# > TCP_FLAGS_LOG_LEVEL=info > TC_ENABLED=Yes > CLEAR_TC=Yes > TCP_FLAGS_DISPOSITION=DROP > curtain:/etc/shorewall# > > So it should be enabled, right? > > ---- tcrules ---- > > 1 eth0 0.0.0.0/0 all > 2 eth1 0.0.0.0/0 all > 2 eth2 0.0.0.0/0 all > 3 fw 0.0.0.0/0 all > > 20 192.168.0.161/32 0.0.0.0/0 tcp 7000:7010 > 21 0.0.0.0/0 192.168.0.161/32 tcp 7010:7010 > > Now, shouldnt this mark all packets to / from .161 to our little daemon on ports 7000:7010 with handle 20 and 21? > > and here is my tcstart > > run_tc qdisc add dev eth0 root handle 1: htb default 30 > run_tc class add dev eth0 parent 1:1 classid 1:10 htb rate 14kbit ceil 38kbit burst 15k prio 1 > run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 20 fw classid 1:10 > run_tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 21 fw classid 1:10 > curtain:/etc/shorewall# > > Now, i pretty much thpught this would limit all traffic to/from those ports to a crawl? But it is still shooting along quite rapidly. Am i missing something stupid, or simply not thinking straight? >Your ruleset is incomplete since you haven''t defined the default (1:30). I suspect that 1:10 is free to borrow as much bandwidth as it need but then I''m no expert either. What does "shorewall show tc" reveal? -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
> Your ruleset is incomplete since you haven''t defined the default (1:30). > I suspect that 1:10 is free to borrow as much bandwidth as it need but > then I''m no expert either. > > What does "shorewall show tc" reveal?As below. Sooo, can someone hint me in to what i _should_ do to be able to do this? Shorewall-2.0.3a Traffic Control at curtain - Sat Aug 7 12:29:51 CEST 2004 Device eth0: qdisc htb 1: r2q 10 default 30 direct_packets_stat 5181083 ver 3.7 Sent 5372144107 bytes 5280026 pkts (dropped 343, overlimits 1387946) class htb 1:10 root prio 1 quantum 1000 rate 14Kbit ceil 38Kbit burst 15Kb/8 mpu 0b cburst 1647b/8 mpu 0b level 0 Sent 34473703 bytes 98943 pkts (dropped 343, overlimits 0) rate 306bps lended: 98943 borrowed: 0 giants: 0 tokens: 6999771 ctokens: 269474 curtain:/etc/shorewall#
j2 wrote:>>Your ruleset is incomplete since you haven''t defined the default (1:30). >>I suspect that 1:10 is free to borrow as much bandwidth as it need but >>then I''m no expert either. >> >>What does "shorewall show tc" reveal? > > > As below. Sooo, can someone hint me in to what i _should_ do to be able to > do this? >This really isn''t the right list for that question -- As stated in the documentation, Shorewall doesn''t do traffic shaping; it just provides some hooks to interface with traffic shaping solutions. Have you looked at the new "Traffic Control HOWTO" linked from the Shorewall traffic shaping page? -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
> Have you looked at the new "Traffic Control HOWTO" linked from the > Shorewall traffic shaping page?Yeap. But according to my limited knowledge, this should have worked. But, have i grasped the syntax of TCrules properly? As in; does it look like i am atleast _tagging_ stuff like i think i am?
j2 wrote:>>Have you looked at the new "Traffic Control HOWTO" linked from the >>Shorewall traffic shaping page? > > > Yeap. But according to my limited knowledge, this should have worked. > > But, have i grasped the syntax of TCrules properly? As in; does it look like > i am atleast _tagging_ stuff like i think i am? >This looks a bit suspect: > 20 192.168.0.161/32 0.0.0.0/0 tcp 7000:7010 > 21 0.0.0.0/0 192.168.0.161/32 tcp 7010:7010 Do all clients of this service bind to local port 7010 and connect to remote 7010 as well? -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
On Sat, 7 Aug 2004, Tom Eastep wrote:> j2 wrote: > > > Have you looked at the new "Traffic Control HOWTO" linked from the > > > Shorewall traffic shaping page? > > > > > > Yeap. But according to my limited knowledge, this should have worked. > > > > But, have i grasped the syntax of TCrules properly? As in; does it look like > > i am atleast _tagging_ stuff like i think i am? > > > > This looks a bit suspect: > > > 20 192.168.0.161/32 0.0.0.0/0 tcp 7000:7010 > > 21 0.0.0.0/0 192.168.0.161/32 tcp 7010:7010 > > Do all clients of this service bind to local port 7010 and connect to remote > 7010 as well? >Ooops -- the font on my other mailer made that look like "7010 7010". Please disregard my babbling. Back to vacationing... -Tom Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
Tom Eastep wrote:> On Sat, 7 Aug 2004, Tom Eastep wrote: > > >>j2 wrote: >> >>>>Have you looked at the new "Traffic Control HOWTO" linked from the >>>>Shorewall traffic shaping page? >>> >>> >>>Yeap. But according to my limited knowledge, this should have worked. >>> >>>But, have i grasped the syntax of TCrules properly? As in; does it look like >>>i am atleast _tagging_ stuff like i think i am? >>> >> >>This looks a bit suspect: >> >> >>>20 192.168.0.161/32 0.0.0.0/0 tcp 7000:7010 >>>21 0.0.0.0/0 192.168.0.161/32 tcp 7010:7010 >> >>Do all clients of this service bind to local port 7010 and connect to remote >>7010 as well? > > Ooops -- the font on my other mailer made that look like "7010 7010". > Please disregard my babbling. >The above still looks wrong -- from client to server, you are using a port range (7000:7010) but from server to client, you are only using a single source port (7010). -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
> The above still looks wrong -- from client to server, you are using a > port range (7000:7010) but from server to client, you are only using a > single source port (7010).Yeap, i goofed the tcrules file there, however, changing to 7000:7010 made no difference. But, i take it that i _am: grasping how tagging works, and that i can/should focus on the "tc" side of things.. *mumble something baout why cant it be _easy_* ;)
j2 wrote:>>The above still looks wrong -- from client to server, you are using a >>port range (7000:7010) but from server to client, you are only using a >>single source port (7010). > > > Yeap, i goofed the tcrules file there, however, changing to 7000:7010 made > no difference.And didn''t you want the ports in the second rule to be in the SOURCE PORT(S) column?> > But, i take it that i _am: grasping how tagging works, and that i can/should > focus on the "tc" side of things.. *mumble something baout why cant it be > _easy_* ;) >Nod -- I fooled with TC for a week and concluded that I didn''t want to become a TC expert badly enough to go through the learning curve. -Tom -- Tom Eastep \ Nothing is foolproof to a sufficiently talented fool Shoreline, \ http://shorewall.net Washington USA \ teastep@shorewall.net
> And didn''t you want the ports in the second rule to be in the SOURCE > PORT(S) column?*ahem* Maybe? :) (yes yes, i SHOULD have seen that one)> Nod -- I fooled with TC for a week and concluded that I didn''t want to > become a TC expert badly enough to go through the learning curve.Ok, now it actually _controls_ traffic.. sort off ;=) And now i can drop a mail to the developer saying "You know, you MIGHT want to rate control that daemon.. just a tad.. please? Or else ill do unmentionable things to... well, something!" Thanks! I''m now on track! Just in time to go to the concert!
On Sat, 2004-08-07 at 08:38, j2 wrote:> > And didn''t you want the ports in the second rule to be in the SOURCE > > PORT(S) column? > > *ahem* Maybe? :) (yes yes, i SHOULD have seen that one) > > > Nod -- I fooled with TC for a week and concluded that I didn''t want to > > become a TC expert badly enough to go through the learning curve. > > Ok, now it actually _controls_ traffic.. sort off ;=) And now i can drop a > mail to the developer saying "You know, you MIGHT want to rate control that > daemon.. just a tad.. please? Or else ill do unmentionable things to... > well, something!"Read this http://my-opensource.org/howto/qostrafficshaping-shorewall-wondershaper-howto.html You wrote: 20 192.168.0.161/32 0.0.0.0/0 tcp 7000:7010 21 0.0.0.0/0 192.168.0.161/32 tcp 7000:7010 Shouldn''t it be 20 192.168.0.161/32 0.0.0.0/0 tcp 7000:7010 - 21 192.168.0.161/32 0.0.0.0/0 tcp - 7000:7010 Since you can''t really control incoming traffic. (that''s how I do it) or maybe you can do it this way too 20 192.168.0.161/32 0.0.0.0/0 tcp 7000:7010 - 21 fw 192.168.0.161/32 tcp - 7000:7010 That way you''re actually controlling outbound traffic from your fw to your host. But frankly it''ll just mean dropped packets/retransmissions etc. -- Ow Mun Heng Fedora GNU/Linux Core 2 on D600 1.4Ghz CPU kernel 2.6.7-2.jul1-interactive Neuromancer 08:56:48 up 12:39, 6 users, load average: 0.75, 1.27, 1.77