Hello Rubens,
Well--I was going to write a short answer, which would have said something
like "look at the parent of the filters". But...that wouldn't have helped
much. So here's a long-winded message about your config file and
situation.
: After migrating a tc-based script to tcc (from the tcng package), we
: are having a filter issue. The script generated by tcc with tc commands
: is not configuring the tc filters; "tc filter show" results in none
: after the script is run, although no error message is generated from
: the "tc filter add". Classes and qdiscs seem to be ok.
I tried to rebuild your configuration (or something darned close), but I
don't know what idiomatic constructs you might have used. The output from
the config file below is the same as the output you posted, although the
source may be different.*
I'm going to guess that your configuration for device eth1 looks something
like this:
dev eth1 { /* begin device eth1 */
htb { /* begin HTB qdisc */
class ( rate 128 kbps, burst 6144 B ) { /* begin HTB root class */
class ( rate 32 kbps, ceil 96 kbps, burst 6144 B, prio 1 )
if not_tcp_incoming
if tcp_dport == PORT_SSH
if ip_tos == 0x10
{ /* begin class for SSH */
sfq ( perturb 10 s );
} /* end class for SSH */
class ( rate 32 kbps, ceil 32 kbps, burst 6144 B, prio 1 )
if tcp_dport == PORT_SMTP
{ /* begin class for SMTP */
sfq ( perturb 10 s );
} /* end class for SMTP */
class ( rate 32 kbps, ceil 32 kbps, burst 6144 B, prio 1 )
if tcp_dport == PORT_HTTP
{ /* begin inner HTB class */
sfq ( perturb 10 s );
} /* end inner HTB class */
class ( rate 32 kbps, ceil 64 kbps, burst 6144 B, prio 2 )
if ip_proto == IPPROTO_TCP
{ /* begin inner HTB class */
sfq ( perturb 10 s );
} /* end inner HTB class */
} /* end root HTB class */
} /* end HTB qdisc */
} /* end device eth1 */
This is not a bad tcng config file, but I have some questions about it.
- Is this similar to your config file? (I only had your processed
tc output to examine, so I may have gotten it wrong.)
- Do you really want to put ( ssh ) and ( ip_tos_delay ) in the same
class? Or did you meant to put ( ssh and ip_tos_delay ) in this
class? Just curious....
- Why do you use "not_tcp_incoming"? Are you trying to prioritize the
ACKs? If so, just use "if tcp_ACK". (Which leads to the next
question...)
- It looks to me as though eth1 must be on the internal interface of a
router with a few servers inside. Is this accurate? If you are
trying to shape your outbound connectivity, you may wish to review
the rules for shaping [0].
[ important (key, in fact), but repetitive prefix
"tc filter add dev eth1 parent 1:1 protocol all prio 1"
snipped ]
: handle 3:0:0 u32 divisor 1
: u32 match u8 0x6 0xff at 9 offset at 0 mask 0f00 shift 6 eat link 3:0:0
: handle 3:0:1 u32 ht 3:0:0 match u16 0x16 0xffff at 2 classid 1:2
: u32 match u8 0x6 0xff at 9 match u8 0x10 0xff at 1 classid 1:2
A bit of ssh, eh? And low delay?
: handle 4:0:0 u32 divisor 1
: u32 match u8 0x6 0xff at 9 offset at 0 mask 0f00 shift 6 eat link 4:0:0
: handle 4:0:1 u32 ht 4:0:0 match u16 0x19 0xffff at 2 classid 1:3
And some SMTP.
: handle 5:0:0 u32 divisor 1
: u32 match u8 0x6 0xff at 9 offset at 0 mask 0f00 shift 6 eat link 5:0:0
: handle 5:0:1 u32 ht 5:0:0 match u16 0x50 0xffff at 2 classid 1:4
And a bit of HTTP.
: Any hints ?
But, of course! Back up from tcng for a moment and look at the
command-line (tc-style) output again, and notice where all of the filters
are rooted.
tc filter add dev eth1 parent 1:1 protocol all prio 1 ...
They are all attached to the object 1:1, which means that they won't get
called directly by a packet needing to be dequeued! Your filters are
there, though, and you'll be able to see that they are indeed installed if
you examine the filters on object 1:1, as follows:
tc filter show dev eth1 parent 1:1
Frankly, I didn't know how to deal with this "problem" when I first
started playing with tcng, so I made peace with dsmark, and now I use the
class selection path construct in my tcng configurations, which makes for
much less wrangling with tc (the command-line critter). It's not too hard
to get a kernel and iproute2 with dsmark [1].
After you have your dsmark-capable kernel you need only have a "tc" which
groks dsmark. Many distributions provide modular dsmark support; you can
simply type "modprobe sch_dsmark && modprobe cls_tcindex".
In the iproute2 Config, which is two lines long, simply change the
TC_CONFIG_DIFFSERV var to "y", and recompile. Then you can just grab the
compiled "tc" and put it someplace other than /sbin/tc, or you can replace
your existing tc.
TC_CONFIG_DIFFSERV=y
TC_CONFIG_ATM=n
Now, try something like the class selection path example [2], and jump for
joy! Now you can use language constructs that are far more understandable
to humans, and let tcng (tcc) do the heavy lifting.
Suddenly traffic control isn't hard at all!
-Martin
[0] http://tldp.org/HOWTO/Traffic-Control-HOWTO/rules.html
[1] http://tldp.org/HOWTO/Traffic-Control-tcng-HTB-HOWTO/requirements.html
[2] http://linux-ip.net/traffic-control/download-cap.tcc
* To others reading this list! If you post a question about a tcng
config, please post your tcng config file. The tc-style output can
easily be generated with a working tcc. Thank you!
--
Martin A. Brown --- SecurePipe, Inc. --- mabrown@xxxxxxxxxxxxxx
_______________________________________________
LARTC mailing list / LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
