Hi I am playing with filters and cbq/htb and I have found this strange thing. Add some filters using the prio/pref (they seem an alias to me) parameter like: tc filter add dev eth0 protocol ip parent 1: pref 5 u32 match ip dst 1.2.3.4 tc filter add dev eth0 protocol ip parent 1: pref 10 u32 match ip dst 2.3.4.5 And try tc filter show dev eth0, you will see that every filter you have is multiplied by the number of different prio/pref values you have used. Thus it looks like you would do this: tc filter add dev eth0 protocol ip parent 1: pref 5 u32 match ip dst 1.2.3.4 tc filter add dev eth0 protocol ip parent 1: pref 5 u32 match ip dst 2.3.4.5 tc filter add dev eth0 protocol ip parent 1: pref 10 u32 match ip dst 1.2.3.4 tc filter add dev eth0 protocol ip parent 1: pref 10 u32 match ip dst 2.3.4.5 Why is that? Is it a tc bug? Or is it normal? What it happens if I use filters of different pref/prio ? In which order are they checked ? Thanks ---------------------------- Mihai RUSU Disclaimer: Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of any company, unless otherwise specifically stated.
It is bug I described a year ago. It is due to a bit ... weird system used in tc filters and u32. There is global table of all u32 hashed and it is looked up for each filter id - thus it will display them over and over .... You can mitigate it by using "show pref N" so see only part you are interested in. devik On Mon, 8 Apr 2002, Mihai RUSU wrote:> Hi > > I am playing with filters and cbq/htb and I have found this strange thing. > Add some filters using the prio/pref (they seem an alias to me) > parameter like: > tc filter add dev eth0 protocol ip parent 1: pref 5 u32 match ip dst 1.2.3.4 > tc filter add dev eth0 protocol ip parent 1: pref 10 u32 match ip dst 2.3.4.5 > > And try tc filter show dev eth0, you will see that every filter you have > is multiplied by the number of different prio/pref values you have used. > > Thus it looks like you would do this: > > tc filter add dev eth0 protocol ip parent 1: pref 5 u32 match ip dst 1.2.3.4 > tc filter add dev eth0 protocol ip parent 1: pref 5 u32 match ip dst 2.3.4.5 > > tc filter add dev eth0 protocol ip parent 1: pref 10 u32 match ip dst 1.2.3.4 > tc filter add dev eth0 protocol ip parent 1: pref 10 u32 match ip dst 2.3.4.5 > > Why is that? Is it a tc bug? Or is it normal? What it happens if I use > filters of different pref/prio ? In which order are they checked ? > > > Thanks > > ---------------------------- > Mihai RUSU > > Disclaimer: Any views or opinions presented within this e-mail are solely > those of the author and do not necessarily represent those of any company, > unless otherwise specifically stated. > > _______________________________________________ > LARTC mailing list / LARTC@mailman.ds9a.nl > http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/ > >
Hi Folks, I have the following setup. Packages going to 192.168.1.51 are going thru 1:30, instead of 1:32. What have I done wrong? #attach htb in eth1 tc qdisc add dev eth1 root handle 1: htb default 30 #sets the ceil in eth1 root tc class add dev eth1 parent 1: classid 1:1 htb rate $ROOT_ETH1 #gives full BW to localnet traffic tc class add dev eth1 parent 1:1 classid 1:10 htb rate $LOCALBW ceil $LOCALBW_CEIL tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip src 200.255.3.0/24 flowid 1:10 #gives $RADIOBW for traffic which source = ! 200.255.3.0/24 (my localnet) tc class add dev eth1 parent 1:1 classid 1:20 htb rate $RADIOBW tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip src 0.0.0.0/0 flowid 1:20 #################CLIENTES # ##########DON BOSCO tc class add dev eth1 parent 1:20 classid 1:30 htb rate $DB_RATE ceil $DB_CEIL tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.1.16/28 flowid 1:30 ##########OLEGARIO tc class add dev eth1 parent 1:20 classid 1:32 htb rate $OLE_RATE ceil $OLE_CEIL tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst 192.168.1.48/28 flowid 1:32 -- Luiz Felipe Ceglia - Staff TereNet lceglia@terenet.com.br - +55-21-9135-3679
On Mon, 8 Apr 2002, Martin Devera wrote:> It is bug I described a year ago. It is due to a bit ... weird > system used in tc filters and u32. There is global table of > all u32 hashed and it is looked up for each filter id - thus > it will display them over and over .... > You can mitigate it by using "show pref N" so see only part > you are interested in. > devik >Thanks for the answer. Now correct me if I got it right, what you said it is a tc bug? Because it looks for the filters like you said ? I mean the kernel doesnt have all those filters, right? ---------------------------- Mihai RUSU Disclaimer: Any views or opinions presented within this e-mail are solely those of the author and do not necessarily represent those of any company, unless otherwise specifically stated.
> Thanks for the answer. > Now correct me if I got it right, what you said it is a tc bug? Because it > looks for the filters like you said ? I mean the kernel doesnt have all > those filters, right?well it is really bug in kernel in show part. But yes it is only cosmetic bug - kernel have only one copy of it. It only displays it more times. devik