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@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@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.
_______________________________________________
LARTC mailing list
LARTC@xxxxxxxxxxxxxxx
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
