Last one for today, I promise... Just tested with u32 classifier match by fwmark and works as well. My tc rules (for test) shows like this: tc qdisc add dev eth1 handle ffff: ingress # for cls_fw tc filter add dev eth1 parent ffff: \ protocol ip prio 50 handle 100 fw \ police rate 100kbit burst 100kbit mtu 1500 drop \ flowid :1 # and the equivalent for cls_u32 (it can be more extendend) tc filter add dev eth1 parent ffff: \ protocol ip prio 50 \ u32 match mark 100 0xffff \ police rate 100kbit burst 100kbit mtu 1500 drop \ flowid :1 # packets are market with iptables in mangle/PREROUTING, i.e. iptables -t mangle -I PREROUTING \ -p tcp -d 192.168.1.218 --dport 22 \ -j MARK --set-mark 100 Cheers, Adrian On Mon 04 Apr 2005 17:24, Adrian Turcu wrote: > Yippee! It worked :) > I have tried on both kernels 2.6.10 and 2.6.11.6 and it's really sweet to > see it works... BTW, in 2.6.11.6 when sch_ingress is loaded this message > "Ingress scheduler: Classifier actions preferred over netfilter" appears in > the log, which in 2.6.10 it's just silent, the feature is the same. I have > tried with different marks for different kind of inbound traffic and the > tests looked good. Man, I'm happy now :) > > For the future search on this subject, bellow is my kernel config for "QoS > and/or fair queueing" section (maybe there are lots to be removed): > > # > # QoS and/or fair queueing > # > CONFIG_NET_SCHED=y > # CONFIG_NET_SCH_CLK_JIFFIES is not set > # CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set > CONFIG_NET_SCH_CLK_CPU=y > CONFIG_NET_SCH_CBQ=m > CONFIG_NET_SCH_HTB=m > CONFIG_NET_SCH_HFSC=m > CONFIG_NET_SCH_PRIO=m > CONFIG_NET_SCH_RED=m > CONFIG_NET_SCH_SFQ=m > CONFIG_NET_SCH_TEQL=m > CONFIG_NET_SCH_TBF=m > CONFIG_NET_SCH_GRED=m > CONFIG_NET_SCH_DSMARK=m > CONFIG_NET_SCH_NETEM=m > CONFIG_NET_SCH_INGRESS=m > CONFIG_NET_QOS=y > CONFIG_NET_ESTIMATOR=y > CONFIG_NET_CLS=y > CONFIG_NET_CLS_TCINDEX=m > CONFIG_NET_CLS_ROUTE4=m > CONFIG_NET_CLS_ROUTE=y > CONFIG_NET_CLS_FW=m > CONFIG_NET_CLS_U32=m > CONFIG_CLS_U32_PERF=y > # CONFIG_NET_CLS_IND is not set > CONFIG_CLS_U32_MARK=y > CONFIG_NET_CLS_RSVP=m > CONFIG_NET_CLS_RSVP6=m > # CONFIG_NET_CLS_ACT is not set > CONFIG_NET_CLS_POLICE=y > > and just to recap the versions used: > iproute2-ss050318 > iptables v1.3.1 > gcc-3.4.3 > kernel custom built as per above versions > > > Thanks guys, > Adrian > > > > There is alot of work going on with tc at the moment - There are/will > > > be lots more matches and the ability to run iptables commands from > > > filters. > > > > ... Like matching the tc flows with iptables chains? that will be nice. > > I've seen some similar options in the kernel, but not sure how they work > > (i.e. CONFIG_NET_ACT_IPT); I couldn't find any doc (howto)... > > > > > I think with 2.6.10 you can still get the behaviour you want if you > > > don't select packet action in Qos and/or fair queuing of config - you > > > get to select a different policer then. > > > > > > CONFIG_NET_CLS_POLICE is the one you want if the other doesn't > > > disappear de select it aswell. > > > > I don't have CONFIG_NET_CLS_POLICE, but CONFIG_NET_CLS_ACT enabled and > > CONFIG_NET_ACT_POLICE as a module. If I disable CONFIG_NET_CLS_ACT there > > are few more that disappear. I'll try this right now (have to rebuild the > > kernel). > > > > > Andy. > > _______________________________________________ > LARTC mailing list > LARTC@xxxxxxxxxxxxxxx > http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc _______________________________________________ LARTC mailing list LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
