[LARTC] Classes do not receive any traffic ?

[Andy Furniss]

bartekR wrote:

> 1.Main problem.
> It seems that classes on imq0 that should shape incoming traffic from 
> internet do not recognizes marks. Fw match don't work. U32 match works 
> except matching marks. The only classes that receive traffic on imq0 are 
> server class and user classes. Similar problem occurred on eth0(upload) 
> but I managed to solve this problem by using -j CLASSIFY instead -j 
> MARK. When I tried to fix this problem I have learned that this may be 
> caused by the way tc and iptables are works together.I am sure that 
> marks are set and IMQ target works (non zero iptables/ifconfig counters) 
> . I think that it is possible for u32 matches to classify traffic before 
> any mark is set. Unfortunately kptd is out of date so it is not certain 
> to me. Would somebody explain me why fwmark do not work on imq0 ?

Mark should work on IMQ if set in PREROUTING mangle - so should 
classify, so perhaps you could work around with that.

You say it didn't work on eth0 either so maybe your/your distro's kernel 
config is to blame here's what I get greping for mark/fw

andy at noki:~$ grep -i mark /boot/config-2.6.21.1
# CONFIG_NETWORK_SECMARK is not set
CONFIG_NF_CONNTRACK_MARK=y
CONFIG_NETFILTER_XT_TARGET_CONNMARK=m
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_MATCH_CONNMARK=m
CONFIG_NETFILTER_XT_MATCH_MARK=m
CONFIG_BRIDGE_EBT_MARK=m
CONFIG_BRIDGE_EBT_MARK_T=m
CONFIG_NET_SCH_DSMARK=m
CONFIG_CLS_U32_MARK=y
andy at noki:~$ grep -i fw /boot/config-2.6.21.1
CONFIG_NET_CLS_FW=m
CONFIG_FW_LOADER=m

If your config looks OK your rules are so complex I would try something 
very simple like marking icmp and making a filter for that on eth/imq 
and seeing if it works or not.

iptables counters don't tell you if you later accidently cleared the 
mark and -j IMQ won't jump to IMQ from that place in the script.

> 
> 2.
> I have found that when i try to ping from host in lan to host in 
> internet every fifth icmp packet has significantly higher delay. F.e. 
> four packets goes trough with delay approx 15ms but next packet have 
> delay up to 100ms ! I suppose that it may be caused by to big txqueuelen 
> so i decreased it from 1000 to 30 on all interfaces without any problems 
> with lesser bandwidth or packet looses. Could somebody advice proper 
> value for txqueuelen if it was a good idea to change it.
> I have 1Mbit/256kbit DSL modem.

DSl rates are hard to get right without patching tc/kernel as it uses 
ATM and the overheads on a packet are high and vary with size in 53byte 
chunks. Without patching you need to back off from the rates.

To make things worse ingress shaping needs you to back off even more as 
you are at the wrong end of the bottleneck, so don't have total control 
like on egress. The slower the link the harder it is, you should use 
short child qdiscs on the htb bulk classes (limit parameter) and try to 
arrange the htb rules so that interactive classes (and don't have too 
many) get a rate much higher than they ever need with a higher prio than 
bulk.

For htb prio 0 is top - for tc filters it's 1

> 
> 3.
> Is it a good idea to set proper ToS value for a outbound traffic that 
> was classified as prio ?? Would it give any decrease in delays ??

I don't think it will make any difference.

Andy.