[LARTC] does any body ever met this strange problem?

[LARTC] does any body ever met this strange problem?

[Folke Aeon]

hi, does any body ever met this strange problem?

--linux1---------linux2--------linux3--
               eth0   eth1

my purpose is :

  make the packets from linux1 to linux3
to be marked with a proper dscp value when
they gose through linux2.

i do the following at eth0 on linux2:

tc qdisc add dev eth0 handle ffff: ingress
tc filter add dev eth0 parent ffff: protocol ip prio 4 u32 \
          match ip dst 10.0.2.18 flowid :1

and at eth1 on linux2 :

tc qdisc add dev eth1 handle 1:0 root dsmark indices 64
tc class change dev eth1 classid 1:1 dsmark mask 0x3 value 0x88
tc filter add dev eth1 parent 1:0 protocol all prio 4 \
                       handle 1 tcindex classid 1:1

now i ping linux3(10.0.2.18) from linux1 , and i can
see the dscp value 0x22 catched at linux3. everything
looks perfect now :)

But , when i add the following line at eth1 on linux2
the problem arised :

tc qdisc add dev eth1 parent 1:0 handle 2:0 dsmark  \
         indices 64 set_tc_index
tc filter add dev eth1 parent 2:0 protocol all prio \
         1 tcindex mask 0xfc shift 2 pass_on
tc filter add dev eth1 parent 2:0 prio 1 handle 0x22\
         tcindex classid 2:111
tc qdisc add dev eth1 parent 2:0 handle 3:0 cbq bandwidth \
                      10Mbit cell 8 avpkt 1000 mpu 64
tc filter add dev eth1 parent 3:0 protocol all prio 1 \
                       tcindex mask 0xf0 shift 4 pass_on
tc class add dev eth1 parent 3:0 classid 3:99 cbq bandwidth \
                      10Mbit rate 9Mbit avpkt 1000 prio 2   \
                      allot 1514 weight 9 maxburst 21 defmap 0
tc filter add dev eth1 parent 3:0 prio 1 handle 1 tcindex \
                       classid 3:99

when i use 'tc -s class ls dev eth1'
i can see the packet from linux1 to linux3 is directed into
class 3:99 , BUT the packet catched at linux3 have a dscp
value of ZERO.

  where has the dscp 0x22 gone?


_________________________________________________________________
Choose an Internet access plan right for you -- try MSN! 
http://resourcecenter.msn.com/access/plans/default.asp

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] does any body ever met this strange problem?

[Werner Almesberger]

Folke Aeon wrote:
> hi, does any body ever met this strange problem?

No, I haven't, because I usually don't nest dsmark ;-)

dsmark changes the DS field according to the value in skb->tc_index
when the packet _leaves_ the qdisc, and your inner dsmark changes
skb->tc_index.

I suggest you have a look at figures 6 and 8 (the latter is on page
6) of ftp://icaftp.epfl.ch/pub/linux/diffserv/misc/dsid-01.ps.gz

- Werner

-- 
  _________________________________________________________________________
 / Werner Almesberger, Buenos Aires, Argentina         wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] does any body ever met this strange problem?

[Folke Aeon]

Thank Werner,
  that's helps alot :)
i managed to figure out that the following does the trick for me :

tc qdisc add dev eth1 handle 1:0 root dsmark indices 64
tc class change dev eth1 classid 1:11 dsmark mask 0x3 value 0x28
tc class change dev eth1 classid 1:21 dsmark mask 0x3 value 0x48
tc filter add dev eth1 parent 1:0 protocol all prio 1 handle 2 \
              tcindex classid 1:11
tc filter add dev eth1 parent 1:0 protocol all prio 1 handle 1 \
              tcindex classid 1:21

#tc qdisc add dev eth1 parent 1:0 handle 2:0 dsmark indices 64 set_tc_index
#tc filter add dev eth1 parent 2:0 protocol all prio 1 tcindex mask 0xfc 
shift 2 pass_on
#tc filter add dev eth1 parent 2:0 prio 1 handle 0x22 tcindex classid 2:111
#tc filter add dev eth1 parent 2:0 prio 1 handle 0x12 tcindex classid 2:191

tc qdisc add dev eth1 parent 1:0 handle 2:0 cbq bandwidth \
                      10Mbit cell 8 avpkt 1000 mpu 64
tc filter add dev eth1 parent 2:0 protocol all prio 1 \
                       tcindex mask 0xf0 shift 4 pass_on
tc class add dev eth1 parent 2:0 classid 2:99 cbq bandwidth \
                      10Mbit rate 9Mbit avpkt 1000 prio 2   \
                      allot 1514 weight 9 maxburst 21 defmap 0
tc class add dev eth1 parent 2:0 classid 2:44 cbq bandwidth \
                      10Mbit rate 1Mbit avpkt 1000 prio 2   \
                      allot 1514 weight 9 maxburst 21 defmap 0

tc filter add dev eth1 parent 2:0 prio 1 handle 1 tcindex \
                       classid 2:99
tc filter add dev eth1 parent 2:0 prio 1 handle 2 tcindex \
                       classid 2:44

tc qdisc add dev eth1 parent 2:99 handle 4:0 pfifo limit 10
tc qdisc add dev eth1 parent 2:44 handle 5:0 pfifo limit 10

  note that after i delete the lines begin with notation mark "#",
all things seems to be back to normal. :)
  will someone give some comment on this ?

>From: Werner Almesberger <wa@almesberger.net>
>To: Folke Aeon <aeon_folke@hotmail.com>
>CC: Subject: Re: [LARTC] does any body ever met this strange problem?
>Date: Thu, 24 Oct 2002 03:19:51 -0300
>
>Folke Aeon wrote:
> > hi, does any body ever met this strange problem?
>
>No, I haven't, because I usually don't nest dsmark ;-)
>
>dsmark changes the DS field according to the value in skb->tc_index
>when the packet _leaves_ the qdisc, and your inner dsmark changes
>skb->tc_index.
>
>I suggest you have a look at figures 6 and 8 (the latter is on page
>6) of ftp://icaftp.epfl.ch/pub/linux/diffserv/misc/dsid-01.ps.gz
>
>- Werner
>
>--
>   
>_________________________________________________________________________
>  / Werner Almesberger, Buenos Aires, Argentina         wa@almesberger.net 
>/
>/_http://www.almesberger.net/____________________________________________/


_________________________________________________________________
Unlimited Internet access -- and 2 months free!  Try MSN. 
http://resourcecenter.msn.com/access/plans/2monthsfree.asp

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/