Hi Jesse, * On Mon, Aug 18, 2003 at 07:23 AM (-0800), Jesse wrote: > ---------------------------------------- > Link='dev eth1' > > Rate1='rate 800Kbit' > Rate2='rate 2500Kbit' > > Burst='burst 9K' > > Action='continue' > > Match1='match ip src 192.6.0.90 match ip dst 10.37.1.63 match ip sport 6970 0xffff match ip protocol 17 0xff' > Match2='match ip src 192.6.0.90 match ip dst 10.37.1.63 match ip dport 5005 0xffff match ip protocol 17 0xff' > Match3='match ip src 0/0' > > Meter1="police $Rate1 $Burst $Action" > Meter2="police $Rate2 $Burst $Action" > > ./tc qdisc add $Link handle 1:0 root dsmark indices 64 > ./tc class change $Link classid 1:1 dsmark mask 0x3 value 0x28 > ./tc class change $Link classid 1:2 dsmark mask 0x3 value 0x38 > ./tc class change $Link classid 1:3 dsmark mask 0x3 value 0x0 > > ./tc filter add $Link parent 1:0 protocol ip prio 1 handle 1: u32 divisor 1 > ./tc filter add $Link parent 1:0 prio 1 u32 $Match1 $Meter1 flowid 1:1 > ./tc filter add $Link parent 1:0 prio 1 u32 $Match2 $Meter2 flowid 1:1 > ./tc filter add $Link parent 1:0 prio 1 u32 $Match3 flowid 1:3 > > ---------------------------------------- > > There is traffic travelling across the network through two ports (6970 - > Video streaming, and 5005 - Iperf traffic gernerator). When I monitor the > packets using Ethereal, it can be seen that most packets are remarked > 0x28 (AF11). However, non-conforming traffic is just remarked as 0x00 (BE > class) which is not what I would like. I would like all non-conforming > packets to be remarked 0x38 (AF13) which would afford them special > treament further down my network. Your filter rules don't put any traffic to "classid 1:2". Is that just a typo? What do you mean by "non-conforming traffic"? - Traffic which comes from sport 6970 with a higher rate than $Rate1 as well as traffic which comes from sport 5005 with a higher rate than $Rate2? <untested> Perhaps you can try such a filtering setup: ./tc filter add $Link parent 1:0 prio 1 u32 $Match1 $Meter1 flowid 1:1 ./tc filter add $Link parent 1:0 prio 2 u32 $Match1 flowid 1:2 ./tc filter add $Link parent 1:0 prio 3 u32 $Match2 $Meter2 flowid 1:1 ./tc filter add $Link parent 1:0 prio 4 u32 $Match2 flowid 1:2 ./tc filter add $Link parent 1:0 prio 5 u32 $Match3 flowid 1:3 </untested> > I have a suspiscion that it might have something to do with the fact the > I am using "continue" as the action used for each of my meters, but can't > be sure. If someone could clarify this or suggest anything or offer > sample scripts then I'd be most grateful, or if anyone would like more > details then I'd be happy to give it to them. The keyword "continue" just means that another filter (with lower priority, i.e. a higher prio value) is checked. As an alternative you can also drop packets which exceed a given rate - but I don't think that you want to do this. I also haven't used policers within egress qdiscs, yet. You can try to use them within an ingress qdisc as shown in the diffserv examples which come with the "iproute2" package (i.e. you can police and filter the traffic at ingress side (which causes setting the "skb->tc_index") and then you can use the "TCINDEX" classifier to put the packets into the according classes of your DSMARK qdisc at egress side). HTH, Steffen
