Re: [LARTC] Remarking non conformant packets as AF13 from AF11

[Steffen Moser <lists@steffen-moser.de>]

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