thr3ads.net - Shorewall users - tc filter add dev eth0.1 protocol all prio 1 parent 11: handle 11 flow hash keys nfct-src divisor 1024: No such file or directory [Sep 2010]

If this information is useful, please help other people find it:
Share via:

Brian J. Murrell

2010-Sep-11 18:51 UTC

tc filter add dev eth0.1 protocol all prio 1 parent 11: handle 11 flow hash keys nfct-src divisor 1024: No such file or directory

I''m trying out the "Simple" TC model (with 4.4.6) and I seem
to be
getting an error with one of the tc commands:

# tc filter add dev eth0.1 protocol all prio 1 parent 11: handle 11 flow hash
keys nfct-src divisor 1024
RTNETLINK answers: No such file or directory
We have an error talking to the kernel

My guess is a missing kernel module, but I''m not sure which one.  Any
ideas?

Cheers,
b.



------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev

Tom Eastep

2010-Sep-11 19:17 UTC

head link

Re: tc filter add dev eth0.1 protocol all prio 1 parent 11: handle 11 flow hash keys nfct-src divisor 1024: No such file or directory

On 9/11/10 11:51 AM, Brian J. Murrell wrote:> I''m trying out the "Simple" TC model (with 4.4.6) and I
seem to be
> getting an error with one of the tc commands:
> 
> # tc filter add dev eth0.1 protocol all prio 1 parent 11: handle 11 flow
hash keys nfct-src divisor 1024
> RTNETLINK answers: No such file or directory
> We have an error talking to the kernel
> 
> My guess is a missing kernel module, but I''m not sure which one. 
Any
> ideas?
I''m guessing it is ''cls_flow''. Shorewall 4.4.6 did
not accurately detect
the availability of that capability.

-Tom
-- 
Tom Eastep        \ When I die, I want to go like my Grandfather who
Shoreline,         \ died peacefully in his sleep. Not screaming like
Washington, USA     \ all of the passengers in his car
http://shorewall.net \________________________________________________



------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev

Brian J. Murrell

2010-Sep-11 20:31 UTC

head link

Re: tc filter add dev eth0.1 protocol all prio 1 parent 11: handle 11 flow hash keys nfct-src divisor 1024: No such file or directory

On Sat, 2010-09-11 at 12:17 -0700, Tom Eastep wrote: > 
> I''m guessing it is ''cls_flow''.
Bingo!
> Shorewall 4.4.6 did not accurately detect
> the availability of that capability.
Explains it then.  :-)

But strangeness ensues.  My connection is capable of 15Mbps down/1Mbps
up.  When I set the IN-BANDWIDTH absurdly high, like 24mbit, of course,
I see the full 15Mbps down.  However when I go down to 12mbit, I only
see between 7-8Mbps down.  Setting IN-BANDWIDTH to 15mbit yields between
11-12Mbps and setting IN-BANDWIDTH to 18mbit yields 14-15Mbps.

Any thoughts as to why the discrepancies?

On another note, maybe I am just misunderstanding, but it seems this
Simple TC mode is only dealing with downstream bandwidth and not
upstream bandwidth (even though, typically, on consumer and even some
small business connections, there is lots of downstream bandwidth
compared to upstream bandwidth).  Is my understanding correct here?

Priority dequeuing seems like a reasonable approach for the downstream
side where we cannot really shape bandwidth anyway (that is more
properly done upstream), but what about preventing saturation of the
upstream bandwidth interrupting latency sensitive applications like VIOP
and whatnot?

b.

------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev

Tom Eastep

2010-Sep-12 13:58 UTC

head link

Re: tc filter add dev eth0.1 protocol all prio 1 parent 11: handle 11 flow hash keys nfct-src divisor 1024: No such file or directory

On 9/11/10 1:31 PM, Brian J. Murrell wrote:> 
> But strangeness ensues.  My connection is capable of 15Mbps down/1Mbps
> up.  When I set the IN-BANDWIDTH absurdly high, like 24mbit, of course,
> I see the full 15Mbps down.  However when I go down to 12mbit, I only
> see between 7-8Mbps down.  Setting IN-BANDWIDTH to 15mbit yields between
> 11-12Mbps and setting IN-BANDWIDTH to 18mbit yields 14-15Mbps.
> 
> Any thoughts as to why the discrepancies?
What is the MTU of this link?
> 
> On another note, maybe I am just misunderstanding, but it seems this
> Simple TC mode is only dealing with downstream bandwidth and not
> upstream bandwidth (even though, typically, on consumer and even some
> small business connections, there is lots of downstream bandwidth
> compared to upstream bandwidth).  Is my understanding correct here?
Yes.
> 
> Priority dequeuing seems like a reasonable approach for the downstream
> side where we cannot really shape bandwidth anyway (that is more
> properly done upstream)
And it is not possible without using an IFB. The IN-BANDWIDTH setting in
both Complex and Simple TC is enforced using bandwidth policing which
simple drops packets at random to maintain the target bandwidth.

, but what about preventing saturation of the> upstream bandwidth interrupting latency sensitive applications like VIOP
> and whatnot?
If you want that, use the complex TC. I have not found a satisfactory
means for enforcing a single upstream rate without negating the effects
of priority queuing.

-Tom
-- 
Tom Eastep        \ When I die, I want to go like my Grandfather who
Shoreline,         \ died peacefully in his sleep. Not screaming like
Washington, USA     \ all of the passengers in his car
http://shorewall.net \________________________________________________



------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev

Brian J. Murrell

2010-Sep-12 15:03 UTC

head link

Re: tc filter add dev eth0.1 protocol all prio 1 parent 11: handle 11 flow hash keys nfct-src divisor 1024: No such file or directory

On Sun, 2010-09-12 at 06:58 -0700, Tom Eastep wrote: > What is the MTU of this link?
1500
> And it is not possible without using an IFB. The IN-BANDWIDTH setting in
> both Complex and Simple TC is enforced using bandwidth policing which
> simple drops packets at random to maintain the target bandwidth.
Yeah, I guess I mis-characterized what (I think) Simple TC is doing.
It''s not so much shaping bandwidth as much as simply prioritizing it.
Do you think that is an accurate statement?  Essentially not delivering
low priority traffic while there is high priority traffic to be
delivered, yes?
> If you want that, use the complex TC.
Yeah, I wondered if that was the case.  In fact I was using Complex TC
before yesterday but running into the same inaccuracies of the bandwidth
settings and what was actually being achieved and figured since I was
tickling all this stuff, I might as well give the Simple TC a try, since
in actuality, I prefer prioritization over actual shaping.
> I have not found a satisfactory
> means for enforcing a single upstream rate without negating the effects
> of priority queuing.
Yeah, I guess I am not looking to enforce an upstream bandwidth but
simply perform priority dequeueing upstream also.  That is, get the VIOP
packets out there before any "bulk" type traffic, even at the complete
expense of bulk traffic, should VOIP actually want all of the upstream
bandwidth.

But now that I say that, and put it in the context of the Simple TC and
downstream prioritization, am I really, simply looking for a
tcinterfaces entry of:

br-lan Internal 1mbit

where "br-lan" is the LAN side of Shorewall gateway?  Hrm, no.  That
would prioritize traffic going out to the lan, not coming in from it.

Cheers,
b.



------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev

Tom Eastep

2010-Sep-12 15:27 UTC

head link

Re: tc filter add dev eth0.1 protocol all prio 1 parent 11: handle 11 flow hash keys nfct-src divisor 1024: No such file or directory

On 9/12/10 8:03 AM, Brian J. Murrell wrote:> On Sun, 2010-09-12 at 06:58 -0700, Tom Eastep wrote: 
>> What is the MTU of this link?
> 
> 1500
Then I have no idea why you are seeing these inaccuracies.
> Yeah, I guess I mis-characterized what (I think) Simple TC is doing.
> It''s not so much shaping bandwidth as much as simply prioritizing
it.
> Do you think that is an accurate statement?  Essentially not delivering
> low priority traffic while there is high priority traffic to be
> delivered, yes?
> 
Yes.
> 
>> I have not found a satisfactory
>> means for enforcing a single upstream rate without negating the effects
>> of priority queuing.
> 
> Yeah, I guess I am not looking to enforce an upstream bandwidth but
> simply perform priority dequeueing upstream also.  That is, get the VIOP
> packets out there before any "bulk" type traffic, even at the
complete
> expense of bulk traffic, should VOIP actually want all of the upstream
> bandwidth.
Which is what simple TC does. And it optionally polices ingress, if an
IN-BANDWIDTH is given.
> 
> But now that I say that, and put it in the context of the Simple TC and
> downstream prioritization, am I really, simply looking for a
> tcinterfaces entry of:
> 
> br-lan Internal 1mbit
> 
> where "br-lan" is the LAN side of Shorewall gateway?  Hrm, no. 
That
> would prioritize traffic going out to the lan, not coming in from it.
Once again -- the *only* thing you can do with incoming traffic is to
police it. It is handled in the order in which it arrives and you can''t
change that. If it is destined for a local application, it gets queued
on the socket bound to the destination address. If it gets forwarded,
then it is prioritized as it is sent, assuming that simple TC is
configured on the output interface.

An IFB is a hack which sends all input traffic through a dummy egress
device so that traffic shaping can be applied. It makes no sense to
apply priority bands in an IFB, as far as I can see.

-Tom
-- 
Tom Eastep        \ When I die, I want to go like my Grandfather who
Shoreline,         \ died peacefully in his sleep. Not screaming like
Washington, USA     \ all of the passengers in his car
http://shorewall.net \________________________________________________



------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev

Laurent Caron (Phone)

2010-Sep-12 15:57 UTC

head link

Re: tc filter add dev eth0.1 protocol all prio 1 parent 11: handle 11 flow hash keys nfct-src divisor 1024: No such file or directory

Le 12 sept. 2010 à 15:58, Tom Eastep <teastep@shorewall.net> a écrit :
> On 9/11/10 1:31 PM, Brian J. Murrell wrote:
>> 
>> But strangeness ensues.  My connection is capable of 15Mbps down/1Mbps
>> up.  When I set the IN-BANDWIDTH absurdly high, like 24mbit, of course,
>> I see the full 15Mbps down.  However when I go down to 12mbit, I only
>> see between 7-8Mbps down.  Setting IN-BANDWIDTH to 15mbit yields
between
>> 11-12Mbps and setting IN-BANDWIDTH to 18mbit yields 14-15Mbps.
>> 
>> Any thoughts as to why the discrepancies?
> 
Hi

I did expérience it before on a NIC/Switch combination that produced this
behavior. Setting both the card and the switch to 100mbps/full fixed it.
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Brian J. Murrell

2010-Sep-12 16:57 UTC

head link

Re: tc filter add dev eth0.1 protocol all prio 1 parent 11: handle 11 flow hash keys nfct-src divisor 1024: No such file or directory

On Sun, 2010-09-12 at 08:27 -0700, Tom Eastep wrote: > 
> Then I have no idea why you are seeing these inaccuracies.
OK.  Maybe it''s a bug somewhere in the kernel.
> Which is what simple TC does. And it optionally polices ingress, if an
> IN-BANDWIDTH is given.
Ahhh.  Yes, of course.  I was mixing/combining the two -- not realizing
that the prioritization is happening on the upstream packets and the
IN-BANDWIDTH was optionally for policing the downstream bandwidth.

So in doing a test, it doesn''t seem to be having the desired
effect.  :-(

I explicitly put ICMP into band 1 in tcpri:

#BAND		PROTO	PORT(S)		ADDRESS		INTERFACE	HELPER
1		-	-		-		-		sip
1		icmp	-		-		-

And then reloaded the firewall (to reset some counters and such) and
then, while pinging the upstream router, scp''d a (3940KB) file from the
lan to a machine out on the Internet.

The classes and counters after the copy showed:

class prio 1:1 parent 1: leaf 11: 
 Sent 4814 bytes 53 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 
class prio 1:2 parent 1: leaf 12: 
 Sent 26849 bytes 79 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 
class prio 1:3 parent 1: leaf 13: 
 Sent 4262752 bytes 2884 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0 

As you can see, the 4MB of file was sent in band 3, some unknown traffic
in band 2 and the pings in band 1.  However the ping statistics at the
end were:

35 packets transmitted, 35 received, 0% packet loss, time 34003ms
rtt min/avg/max/mdev = 5.974/408.201/666.489/194.407 ms

where the transfer was done during ping packets 4-34, which account for
the high average and max RTT.

For posterity, the rest of the TC configuration:

# tc -s qdisc ls dev eth0.1
qdisc prio 1: root bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
Sent 4367741 bytes 3325 pkt (dropped 0, overlimits 0 requeues 0) 
rate 0bit 0pps backlog 0b 0p requeues 0 
qdisc sfq 11: parent 1:1 limit 127p quantum 1875b perturb 10sec 
Sent 8578 bytes 101 pkt (dropped 0, overlimits 0 requeues 0) 
rate 0bit 0pps backlog 0b 0p requeues 0 
qdisc sfq 12: parent 1:2 limit 127p quantum 1875b perturb 10sec 
Sent 95699 bytes 338 pkt (dropped 0, overlimits 0 requeues 0) 
rate 0bit 0pps backlog 0b 0p requeues 0 
qdisc sfq 13: parent 1:3 limit 127p quantum 1875b perturb 10sec 
Sent 4262894 bytes 2885 pkt (dropped 0, overlimits 0 requeues 0) 
rate 0bit 0pps backlog 0b 0p requeues 0 

# tc -s filter ls dev eth0.1
filter parent 1: protocol all pref 49150 fw 
filter parent 1: protocol all pref 49150 fw handle 0x3 classid 1:3 
filter parent 1: protocol all pref 49151 fw 
filter parent 1: protocol all pref 49151 fw handle 0x2 classid 1:2 
filter parent 1: protocol all pref 49152 fw 
filter parent 1: protocol all pref 49152 fw handle 0x1 classid 1:1 

And my mangle table:

Chain PREROUTING (policy ACCEPT 5627 packets, 4556K bytes)
 pkts bytes target     prot opt in     out     source               destination
 5133 4436K CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0   
connmark match !0x0/0xff00 CONNMARK restore mask 0xff00
   84 23805 routemark  all  --  eth0.1 *       0.0.0.0/0            0.0.0.0/0   
mark match 0x0/0xff00
   83  5256 routemark  all  --  ppp0   *       0.0.0.0/0            0.0.0.0/0   
mark match 0x0/0xff00
 2008  192K tcpre      all  --  eth0.1 *       0.0.0.0/0            0.0.0.0/0
  157 11680 tcpre      all  --  ppp0   *       0.0.0.0/0            0.0.0.0/0
  327 90334 tcpre      all  --  *      *       0.0.0.0/0            0.0.0.0/0   
mark match 0x0/0xff00

Chain INPUT (policy ACCEPT 350 packets, 37188 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 5249 packets, 4508K bytes)
 pkts bytes target     prot opt in     out     source               destination
 5249 4508K MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0   
MARK and 0x0
 5249 4508K tcfor      all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT 249 packets, 18487 bytes)
 pkts bytes target     prot opt in     out     source               destination
  136 10015 CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0   
connmark match !0x0/0xff00 CONNMARK restore mask 0xff00
  113  8472 tcout      all  --  *      *       0.0.0.0/0            0.0.0.0/0   
mark match 0x0/0xff00

Chain POSTROUTING (policy ACCEPT 5498 packets, 4526K bytes)
 pkts bytes target     prot opt in     out     source               destination
 5498 4526K tcpost     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain routemark (2 references)
 pkts bytes target     prot opt in     out     source               destination
   84 23805 MARK       all  --  eth0.1 *       0.0.0.0/0            0.0.0.0/0   
MARK xset 0x100/0xffffffff
   83  5256 MARK       all  --  ppp0   *       0.0.0.0/0            0.0.0.0/0   
MARK xset 0x200/0xffffffff
  167 29061 CONNMARK   all  --  *      *       0.0.0.0/0            0.0.0.0/0   
mark match !0x0/0xff00 CONNMARK save mask 0xff00

Chain tcfor (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain tcout (1 references)
 pkts bytes target     prot opt in     out     source               destination

Chain tcpost (1 references)
 pkts bytes target     prot opt in     out     source               destination
    0     0 MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0   
helper match "sip" MARK xset 0x1/0xffffffff
  230 16120 MARK       icmp --  *      *       0.0.0.0/0            0.0.0.0/0   
MARK xset 0x1/0xffffffff

Chain tcpre (3 references)
 pkts bytes target     prot opt in     out     source               destination

Are my expectations (that the pings should be low latency) not in line
with what Simple TC does?

FWIW, there was practically no download bandwidth usage (nowhere near
the 15Mbps is capable of) to account for the high latency either.

b.



------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev

Brian J. Murrell

2010-Sep-12 17:17 UTC

head link

Re: tc filter add dev eth0.1 protocol all prio 1 parent 11: handle 11 flow hash keys nfct-src divisor 1024: No such file or directory

On Sun, 2010-09-12 at 17:57 +0200, Laurent Caron (Phone) wrote:
> 
> Hi
Hi Laurent,
> I did expérience it before on a NIC/Switch combination that produced this
behavior.
In my case, this is NIC/cable modem.
> Setting both the card and the switch to 100mbps/full fixed it.
AFAIK these two are auto-negotiating and should be achieving
100mbps/full.

Grateful for your input though.

b.



------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev

Laurent Caron (Phone)

2010-Sep-12 17:30 UTC

head link

Re: tc filter add dev eth0.1 protocol all prio 1 parent 11: handle 11 flow hash keys nfct-src divisor 1024: No such file or directory

Le 12 sept. 2010 à 19:17, "Brian J. Murrell"
<brian@interlinx.bc.ca> a écrit :>> I did expérience it before on a NIC/Switch combination that produced
this behavior.
> 
> In my case, this is NIC/cable modem.
> 
>> Setting both the card and the switch to 100mbps/full fixed it.
> 
> AFAIK these two are auto-negotiating and should be achieving
> 100mbps/full.
> 
Maybe better Check it with ethtool. Although autoneg works 99%...better not be
the remaining 1%.
------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev
_______________________________________________
Shorewall-users mailing list
Shorewall-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/shorewall-users

Tom Eastep

2010-Sep-12 20:42 UTC

head link

Re: tc filter add dev eth0.1 protocol all prio 1 parent 11: handle 11 flow hash keys nfct-src divisor 1024: No such file or directory

On 9/12/10 9:57 AM, Brian J. Murrell wrote:
> 
> So in doing a test, it doesn''t seem to be having the desired
> effect.  :-(
> 
> 35 packets transmitted, 35 received, 0% packet loss, time 34003ms
> rtt min/avg/max/mdev = 5.974/408.201/666.489/194.407 ms
> 
> where the transfer was done during ping packets 4-34, which account for
> the high average and max RTT.
Yep, I saw the same thing. At which point I concluded that 100% line
utilization is bad for latency, even if packets are prioritized on the
sending end.

As I''ve said, I don''t see a way to enforce a single bandwidth
limit
while doing effective priority queuing.

-Tom
-- 
Tom Eastep        \ When I die, I want to go like my Grandfather who
Shoreline,         \ died peacefully in his sleep. Not screaming like
Washington, USA     \ all of the passengers in his car
http://shorewall.net \________________________________________________



------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev

Brian J. Murrell

2010-Sep-13 11:54 UTC

head link

Re: tc filter add dev eth0.1 protocol all prio 1 parent 11: handle 11 flow hash keys nfct-src divisor 1024: No such file or directory

On Sun, 2010-09-12 at 06:58 -0700, Tom Eastep wrote: > 
> If you want that, use the complex TC.
I suppose the policy routing features of complex TC are not available
with simple TC anyway, so complex TC looks like what I need to use
anyway.

b.



------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev

Tom Eastep

2010-Sep-13 13:34 UTC

head link

Re: tc filter add dev eth0.1 protocol all prio 1 parent 11: handle 11 flow hash keys nfct-src divisor 1024: No such file or directory

On 9/13/10 4:54 AM, Brian J. Murrell wrote:> On Sun, 2010-09-12 at 06:58 -0700, Tom Eastep wrote: 
>>
>> If you want that, use the complex TC.
> 
> I suppose the policy routing features of complex TC are not available
> with simple TC anyway, so complex TC looks like what I need to use
> anyway.
Policy routing works fine with Simple TC.

-Tom
-- 
Tom Eastep        \ When I die, I want to go like my Grandfather who
Shoreline,         \ died peacefully in his sleep. Not screaming like
Washington, USA     \ all of the passengers in his car
http://shorewall.net \________________________________________________



------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev

Tom Eastep

2010-Sep-13 14:53 UTC

head link

Re: tc filter add dev eth0.1 protocol all prio 1 parent 11: handle 11 flow hash keys nfct-src divisor 1024: No such file or directory

On 9/13/10 4:54 AM, Brian J. Murrell wrote:> On Sun, 2010-09-12 at 06:58 -0700, Tom Eastep wrote: 
>>
>> If you want that, use the complex TC.
> 
> I suppose the policy routing features of complex TC are not available
> with simple TC anyway, so complex TC looks like what I need to use
> anyway.
I resurrected some old code that I had implemented earlier and performed
some more testing. Attached is a patch against
/usr/share/shorewall/Shorewall/Tc.pm. It applies (with offsets) to
4.4.11 and later versions.

It adds an OUT-BANDWIDTH column to /etc/shorewall/tcinterfaces. This
column contains:

	<rate>:<latency>[:[<peak>][:[<minburst>]]]

where the terms are explained in tc-tbf(8).

I have a 5mbit uplink and I placed 4500kbit:100kb:200ms in the new
column. I then pinged while running several speed tests at speedtest.net.

My /etc/shorewall/tcpri:

#BAND	PROTO		PORT(S)		ADDRESS		INTERFACE
3	-	 	-		70.90.191.124/31
3	ipp2p:all	bit
2	udp	   	53
1	icmp	        8

The results:

--- xx.xx.xx.xx ping statistics ---
263 packets transmitted, 263 received, 0% packet loss, time 273041ms
rtt min/ave/max/mdev = 6.130/8.876/72.844/5.497 ms

#gateway:/etc/shorewall# shorewall show tc
Shorewall 4.4.13-Beta4 Traffic Control at gateway - Mon Sep 13 07:44:50
PDT 2010

Device eth1:
qdisc ingress ffff: parent ffff:fff1 ----------------
 Sent 46057721 bytes 48914 pkt (dropped 399, overlimits 0 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc tbf 1: root rate 4500Kbit burst 100Kb/8 mpu 0b lat 200.0ms
 Sent 31738156 bytes 45487 pkt (dropped 137, overlimits 31095 requeues 0)
 rate 0bit 0pps backlog 0b 0p requeues 0
qdisc prio 101: parent 1: bands 3 priomap  1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
 Sent 31738156 bytes 45487 pkt (dropped 137, overlimits 0 requeues 31095)
 rate 0bit 0pps backlog 0b 0p requeues 31095
qdisc sfq 1011: parent 101:1 limit 127p quantum 1875b flows 127/1024
perturb 10sec
 Sent 25774 bytes 263 pkt (dropped 0, overlimits 0 requeues 3)
 rate 0bit 0pps backlog 0b 0p requeues 3
qdisc sfq 1012: parent 101:2 limit 127p quantum 1875b flows 127/1024
perturb 10sec
 Sent 30716576 bytes 44243 pkt (dropped 137, overlimits 0 requeues 30309)
 rate 0bit 0pps backlog 0b 0p requeues 30309
qdisc sfq 1013: parent 101:3 limit 127p quantum 1875b flows 127/1024
perturb 10sec
 Sent 995806 bytes 981 pkt (dropped 0, overlimits 0 requeues 783)
 rate 0bit 0pps backlog 0b 0p requeues 783

class tbf 1:1 parent 1: leaf 101:

class prio 101:1 parent 101: leaf 1011:
 Sent 25774 bytes 263 pkt (dropped 0, overlimits 0 requeues 3)
 backlog 0b 0p requeues 3
class prio 101:2 parent 101: leaf 1012:
 Sent 30716874 bytes 44245 pkt (dropped 137, overlimits 0 requeues 30309)
 backlog 0b 0p requeues 30309
class prio 101:3 parent 101: leaf 1013:
 Sent 995806 bytes 981 pkt (dropped 0, overlimits 0 requeues 783)
 backlog 0b 0p requeues 783

Because the TBF qdisc is applied before the prio qdisc, I suspect that
the prio qdisc is pretty ineffective (although it still dropped 137
speedtest packets). But the overall goal of reducing latency seems to
have been met. Previous tests resulted in max TTL for ping of > 200ms

YYMV

-Tom
-- 
Tom Eastep        \ When I die, I want to go like my Grandfather who
Shoreline,         \ died peacefully in his sleep. Not screaming like
Washington, USA     \ all of the passengers in his car
http://shorewall.net \________________________________________________



------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev

Tom Eastep

2010-Sep-13 15:05 UTC

head link

Re: tc filter add dev eth0.1 protocol all prio 1 parent 11: handle 11 flow hash keys nfct-src divisor 1024: No such file or directory

On 9/13/10 7:53 AM, Tom Eastep wrote:
> 
> It adds an OUT-BANDWIDTH column to /etc/shorewall/tcinterfaces. This
> column contains:
> 
> 	<rate>:<latency>[:[<peak>][:[<minburst>]]]
> 
> where the terms are explained in tc-tbf(8).
Sorry; that should have been:

 
<rate>:<burst>:<latency>[:[<peak>][:[<minburst>]]]

-Tom
-- 
Tom Eastep        \ When I die, I want to go like my Grandfather who
Shoreline,         \ died peacefully in his sleep. Not screaming like
Washington, USA     \ all of the passengers in his car
http://shorewall.net \________________________________________________



------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev

Tom Eastep

2010-Sep-13 15:58 UTC

head link

Re: tc filter add dev eth0.1 protocol all prio 1 parent 11: handle 11 flow hash keys nfct-src divisor 1024: No such file or directory

On 09/13/2010 07:53 AM, Tom Eastep wrote:
> 
> Because the TBF qdisc is applied before the prio qdisc, I suspect that
> the prio qdisc is pretty ineffective (although it still dropped 137
> speedtest packets). But the overall goal of reducing latency seems to
> have been met. Previous tests resulted in max TTL for ping of > 200ms
I''ve found the same gross inaccuracy with the IN-BANDWIDTH as Brian
did. I
changed my /etc/shorewall/tcinterfaces file to:

#INTERFACE	TYPE		IN-BANDWIDTH	OUT-BANDWIDTH
COM_IF		External	100mbit		8mbit:100kb:200ms

With those settings, I get:

Download Speed:  50 -  60 mbit
Upload Speed:   7.8 - 8.0 mbit

Maximum ping times were in the 50-85 ms range, down from over 200ms.

Which is all pretty satisfactory. Setting the IN-BANDWIDTH down to 80mbit
reduced the Download Speed to ~ 40 mbit. Setting it to 40mbit reduced the
Download Speed to 10-12 mbit.

-Tom
-- 
Tom Eastep        \ When I die, I want to go like my Grandfather who
Shoreline,         \ died peacefully in his sleep. Not screaming like
Washington, USA     \ all of the passengers in his car
http://shorewall.net \________________________________________________



------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev

Brian J. Murrell

2010-Sep-15 11:25 UTC

head link

Re: tc filter add dev eth0.1 protocol all prio 1 parent 11: handle 11 flow hash keys nfct-src divisor 1024: No such file or directory

On Mon, 2010-09-13 at 07:53 -0700, Tom Eastep wrote: > 
> I resurrected some old code that I had implemented earlier and performed
> some more testing. Attached is a patch against
> /usr/share/shorewall/Shorewall/Tc.pm. It applies (with offsets) to
> 4.4.11 and later versions.
> 
> It adds an OUT-BANDWIDTH column to /etc/shorewall/tcinterfaces. This
> column contains:
> 
> 	<rate>:<latency>[:[<peak>][:[<minburst>]]]
> 
> where the terms are explained in tc-tbf(8).
> 
> I have a 5mbit uplink and I placed 4500kbit:100kb:200ms in the new
> column. I then pinged while running several speed tests at speedtest.net.
> 
> My /etc/shorewall/tcpri:
> 
> #BAND	PROTO		PORT(S)		ADDRESS		INTERFACE
> 3	-	 	-		70.90.191.124/31
> 3	ipp2p:all	bit
> 2	udp	   	53
> 1	icmp	        8
> 
> The results:
> 
> --- xx.xx.xx.xx ping statistics ---
> 263 packets transmitted, 263 received, 0% packet loss, time 273041ms
> rtt min/ave/max/mdev = 6.130/8.876/72.844/5.497 ms
Sweet.  I will have to find a moment to give this a try.

b.



------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev

Brian J. Murrell

2010-Sep-15 11:26 UTC

head link

Re: tc filter add dev eth0.1 protocol all prio 1 parent 11: handle 11 flow hash keys nfct-src divisor 1024: No such file or directory

On Mon, 2010-09-13 at 08:58 -0700, Tom Eastep wrote: > 
> I''ve found the same gross inaccuracy with the IN-BANDWIDTH as
Brian did.
I wonder how widespread (as in across kernel versions) and well-known
this issue is.  I''ve had it in the back of mind to go rattle the cage
of
the TC folks to get an impression, but time is just not with me these
days.  Too many pokers in the fire I think.

Cheers,
b.



------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev

Tom Eastep

2010-Sep-15 15:16 UTC

head link

Re: tc filter add dev eth0.1 protocol all prio 1 parent 11: handle 11 flow hash keys nfct-src divisor 1024: No such file or directory

On 9/15/10 4:25 AM, Brian J. Murrell wrote:> On Mon, 2010-09-13 at 07:53 -0700, Tom Eastep wrote: 
>>
>> I resurrected some old code that I had implemented earlier and
performed
>> some more testing. Attached is a patch against
>> /usr/share/shorewall/Shorewall/Tc.pm. It applies (with offsets) to
>> 4.4.11 and later versions.
>>
>> It adds an OUT-BANDWIDTH column to /etc/shorewall/tcinterfaces. This
>> column contains:
>>
>> 	<rate>:<latency>[:[<peak>][:[<minburst>]]]
>>
>> where the terms are explained in tc-tbf(8).
>>
>> I have a 5mbit uplink and I placed 4500kbit:100kb:200ms in the new
>> column. I then pinged while running several speed tests at
speedtest.net.
>>
>> My /etc/shorewall/tcpri:
>>
>> #BAND	PROTO		PORT(S)		ADDRESS		INTERFACE
>> 3	-	 	-		70.90.191.124/31
>> 3	ipp2p:all	bit
>> 2	udp	   	53
>> 1	icmp	        8
>>
>> The results:
>>
>> --- xx.xx.xx.xx ping statistics ---
>> 263 packets transmitted, 263 received, 0% packet loss, time 273041ms
>> rtt min/ave/max/mdev = 6.130/8.876/72.844/5.497 ms
> 
> Sweet.  I will have to find a moment to give this a try.
You might want to just install 4.4.13 Beta 5 -- be sure to apply the fix
for ''clear'' I sent out yesterday.

I''m really pleased with the way that it is working here. While the
theory behind the implementation is questionable (tc-prio under tc-tbf),
the results are very pleasing.

-Tom
-- 
Tom Eastep        \ When I die, I want to go like my Grandfather who
Shoreline,         \ died peacefully in his sleep. Not screaming like
Washington, USA     \ all of the passengers in his car
http://shorewall.net \________________________________________________



------------------------------------------------------------------------------
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev

Shorewall users - Sep 2010 - tc filter add dev eth0.1 protocol all prio 1 parent 11: handle 11 flow hash keys nfct-src divisor 1024: No such file or directory

tc filter add dev eth0.1 protocol all prio 1 parent 11: handle 11 flow hash keys nfct-src divisor 1024: No such file or directory

Re: tc filter add dev eth0.1 protocol all prio 1 parent 11: handle 11 flow hash keys nfct-src divisor 1024: No such file or directory

Re: tc filter add dev eth0.1 protocol all prio 1 parent 11: handle 11 flow hash keys nfct-src divisor 1024: No such file or directory

Re: tc filter add dev eth0.1 protocol all prio 1 parent 11: handle 11 flow hash keys nfct-src divisor 1024: No such file or directory

Re: tc filter add dev eth0.1 protocol all prio 1 parent 11: handle 11 flow hash keys nfct-src divisor 1024: No such file or directory

Re: tc filter add dev eth0.1 protocol all prio 1 parent 11: handle 11 flow hash keys nfct-src divisor 1024: No such file or directory

Re: tc filter add dev eth0.1 protocol all prio 1 parent 11: handle 11 flow hash keys nfct-src divisor 1024: No such file or directory

Re: tc filter add dev eth0.1 protocol all prio 1 parent 11: handle 11 flow hash keys nfct-src divisor 1024: No such file or directory

Re: tc filter add dev eth0.1 protocol all prio 1 parent 11: handle 11 flow hash keys nfct-src divisor 1024: No such file or directory

Re: tc filter add dev eth0.1 protocol all prio 1 parent 11: handle 11 flow hash keys nfct-src divisor 1024: No such file or directory

Re: tc filter add dev eth0.1 protocol all prio 1 parent 11: handle 11 flow hash keys nfct-src divisor 1024: No such file or directory

Re: tc filter add dev eth0.1 protocol all prio 1 parent 11: handle 11 flow hash keys nfct-src divisor 1024: No such file or directory

Re: tc filter add dev eth0.1 protocol all prio 1 parent 11: handle 11 flow hash keys nfct-src divisor 1024: No such file or directory

Re: tc filter add dev eth0.1 protocol all prio 1 parent 11: handle 11 flow hash keys nfct-src divisor 1024: No such file or directory

Re: tc filter add dev eth0.1 protocol all prio 1 parent 11: handle 11 flow hash keys nfct-src divisor 1024: No such file or directory

Re: tc filter add dev eth0.1 protocol all prio 1 parent 11: handle 11 flow hash keys nfct-src divisor 1024: No such file or directory

Re: tc filter add dev eth0.1 protocol all prio 1 parent 11: handle 11 flow hash keys nfct-src divisor 1024: No such file or directory

Re: tc filter add dev eth0.1 protocol all prio 1 parent 11: handle 11 flow hash keys nfct-src divisor 1024: No such file or directory

Re: tc filter add dev eth0.1 protocol all prio 1 parent 11: handle 11 flow hash keys nfct-src divisor 1024: No such file or directory