* [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.