All of lore.kernel.org
 help / color / mirror / Atom feed
* [LARTC] problem with filters - packets 'slipping' through them when
@ 2005-05-03 11:58 Marcin Kałuża
  2005-05-03 13:38 ` [LARTC] problem with filters - packets 'slipping' through them Andy Furniss
  2005-05-04  9:40 ` Marcin Kałuża
  0 siblings, 2 replies; 3+ messages in thread
From: Marcin Kałuża @ 2005-05-03 11:58 UTC (permalink / raw)
  To: lartc

Hi!
I'm trying to shape my internet connection traffic using hsfc and I've 
encountered the following problem (may not be connected with hfsc).
on my lan interface I shape incoming traffic like this:

tc qdisc add root dev eth1  handle 1: hfsc default 1003
tc class add dev eth1 parent 1:0 classid 1:1003 hfsc ls rate 10kbit ul rate 
10kbit
tc class add dev eth1 parent 1: classid 1:1001 hfsc ls rate 70Mbit ul rate 
70Mbit

tc filter add dev eth1 parent 1: protocol ip prio 1 u32 \
               match ip src 192.168.0.1 \
               flowid 1:1001

tc class add dev eth1 parent 1: classid 1:1002 hfsc ls rate 1Mbit ul rate 
1Mbit
tc filter add dev eth1 parent 1: protocol ip prio 2 u32 \
               match ip dst 192.168.0.0/24 \
               flowid 1:1002

class 1001 recievs the traffic generated by the server
class 1002 gets incoming traffic from the internet 
class 1003 is the default

And that's where my problem is - 1003 shouldn't get any traffic since (as I 
think) the above filters should in total match everything and direct it to 
1001/2. But there are some packets that go to 1003 and if I delete it, most 
of the traffic dies (even ping 192.168.0.2 doesn't work - whats even more 
wierd, not immediately, but after a minute or so from installing new queue)

Can anybody help me? Am I missing something in the filters? I've tried doing 
the same with iptables and mark in the postrouting chain and with fw filters. 
The situation was strange as well - every packet got marked either for the 
first or the second class, and in spite of this 1003 got traffic anyway...

thanks for any hints
Martin
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [LARTC] problem with filters - packets 'slipping' through them
  2005-05-03 11:58 [LARTC] problem with filters - packets 'slipping' through them when Marcin Kałuża
@ 2005-05-03 13:38 ` Andy Furniss
  2005-05-04  9:40 ` Marcin Kałuża
  1 sibling, 0 replies; 3+ messages in thread
From: Andy Furniss @ 2005-05-03 13:38 UTC (permalink / raw)
  To: lartc

Marcin Ka³u¿a wrote:
> Hi!
> I'm trying to shape my internet connection traffic using hsfc and I've 
> encountered the following problem (may not be connected with hfsc).
> on my lan interface I shape incoming traffic like this:
> 
> tc qdisc add root dev eth1  handle 1: hfsc default 1003
> tc class add dev eth1 parent 1:0 classid 1:1003 hfsc ls rate 10kbit ul rate 
> 10kbit
> tc class add dev eth1 parent 1: classid 1:1001 hfsc ls rate 70Mbit ul rate 
> 70Mbit
> 
> tc filter add dev eth1 parent 1: protocol ip prio 1 u32 \
>                match ip src 192.168.0.1 \
>                flowid 1:1001
> 
> tc class add dev eth1 parent 1: classid 1:1002 hfsc ls rate 1Mbit ul rate 
> 1Mbit
> tc filter add dev eth1 parent 1: protocol ip prio 2 u32 \
>                match ip dst 192.168.0.0/24 \
>                flowid 1:1002
> 
> class 1001 recievs the traffic generated by the server
> class 1002 gets incoming traffic from the internet 
> class 1003 is the default
> 
> And that's where my problem is - 1003 shouldn't get any traffic since (as I 
> think) the above filters should in total match everything and direct it to 
> 1001/2. But there are some packets that go to 1003 and if I delete it, most 
> of the traffic dies (even ping 192.168.0.2 doesn't work - whats even more 
> wierd, not immediately, but after a minute or so from installing new queue)

It's arp traffic - your filters are catching IP it stops working when 
the cache expires. Unlike htb hfsc drops traffic it doesn't know what to 
do with if you don't specify a default class.

> 
> Can anybody help me? Am I missing something in the filters? I've tried doing 
> the same with iptables and mark in the postrouting chain and with fw filters. 
> The situation was strange as well - every packet got marked either for the 
> first or the second class, and in spite of this 1003 got traffic anyway...

If you don't want use default you could classify with a TC filter

.... protocol arp u32 match u32 0 0 ....

Andy.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [LARTC] problem with filters - packets 'slipping' through them
  2005-05-03 11:58 [LARTC] problem with filters - packets 'slipping' through them when Marcin Kałuża
  2005-05-03 13:38 ` [LARTC] problem with filters - packets 'slipping' through them Andy Furniss
@ 2005-05-04  9:40 ` Marcin Kałuża
  1 sibling, 0 replies; 3+ messages in thread
From: Marcin Kałuża @ 2005-05-04  9:40 UTC (permalink / raw)
  To: lartc

Thanks :)
I didn't think of that :)
Martin

On Tuesday 03 May 2005 15:38, you wrote:
>
> If you don't want use default you could classify with a TC filter
>
> .... protocol arp u32 match u32 0 0 ....
>
> Andy.
_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2005-05-04  9:40 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-05-03 11:58 [LARTC] problem with filters - packets 'slipping' through them when Marcin Kałuża
2005-05-03 13:38 ` [LARTC] problem with filters - packets 'slipping' through them Andy Furniss
2005-05-04  9:40 ` Marcin Kałuża

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.