Hi!
I'm trying to shape my internet connection traffic using hsfc and I've encountered the following problem (may not be connected with hfsc).
on my lan interface I shape incoming traffic like this:
tc qdisc add root dev eth1 handle 1: hfsc default 1003
tc class add dev eth1 parent 1:0 classid 1:1003 hfsc ls rate 10kbit ul rate 10kbit
tc class add dev eth1 parent 1: classid 1:1001 hfsc ls rate 70Mbit ul rate 70Mbit
tc filter add dev eth1 parent 1: protocol ip prio 1 u32 \ match ip src 192.168.0.1 \ flowid 1:1001
tc class add dev eth1 parent 1: classid 1:1002 hfsc ls rate 1Mbit ul rate 1Mbit
tc filter add dev eth1 parent 1: protocol ip prio 2 u32 \
match ip dst 192.168.0.0/24 \
flowid 1:1002
class 1001 recievs the traffic generated by the server
class 1002 gets incoming traffic from the internet class 1003 is the default
And that's where my problem is - 1003 shouldn't get any traffic since (as I think) the above filters should in total match everything and direct it to 1001/2. But there are some packets that go to 1003 and if I delete it, most of the traffic dies (even ping 192.168.0.2 doesn't work - whats even more wierd, not immediately, but after a minute or so from installing new queue)
It's arp traffic - your filters are catching IP it stops working when the cache expires. Unlike htb hfsc drops traffic it doesn't know what to do with if you don't specify a default class.
Can anybody help me? Am I missing something in the filters? I've tried doing the same with iptables and mark in the postrouting chain and with fw filters. The situation was strange as well - every packet got marked either for the first or the second class, and in spite of this 1003 got traffic anyway...
If you don't want use default you could classify with a TC filter
.... protocol arp u32 match u32 0 0 ....
Andy. _______________________________________________ LARTC mailing list LARTC@mailman.ds9a.nl http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
