* [LARTC] question about tc and ip aliasing
@ 2003-04-25 21:18 Enric Ramos Mas
2003-04-28 8:45 ` Szymon Miotk
2003-04-28 19:26 ` Stef Coene
0 siblings, 2 replies; 3+ messages in thread
From: Enric Ramos Mas @ 2003-04-25 21:18 UTC (permalink / raw)
To: lartc
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi.
I don't know if this subject has been treated before.
Anyway, this is my question:
I have implemented a traffic control / advanced router server using
iproute2 and tc (using htb). For all my outgoing tc policies, all
it's ok (all the traffic goes out using eth0, and therefore I'm able
to catch it using the corresponfing tc filter).
However, the incoming traffic has to be treated in eth1, which has
several virtual ifaces (eth1:0, eth1:1, eth1:2 and so on).
Even I have introduced all the tc rules correctly, the kernel is not
matching any filter rule and there is no way to match any destination
into any queue discipline.
Anyone knows some way to implement that ?
Here are my tc rules:
tc qdisc add dev eth0 root handle 1: htb default 99
# Root class
tc class add dev eth0 parent 1: classid 1:1 htb rate 3256kbit
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 128kbit ceil
256kbit ##
tc class add dev eth0 parent 1:1 classid 1:11 htb rate 128kbit ceil
128kbit ##
tc class add dev eth0 parent 1:1 classid 1:12 htb rate 90kbit ceil
128kbit ##
... an so on
tc class add dev eth0 parent 1:1 classid 1:99 htb rate 1024kbit
ceil 3256kbit
#
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip src
213.???.???.??? flowid 1:10
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip src
213.???.???.??? flowid 1:10
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip src
62..???.???.??? flowid 1:11
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip src
213..???.???.??? flowid 1:12
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip src
213.229.188.143 flowid 1:13
... and so on
- --> this is tha part that works correctly :-)
# Root class
tc class add dev eth1 parent 1: classid 1:1 htb rate 3256kbit
tc class add dev eth1 parent 1:1 classid 1:10 htb rate 128kbit ceil
256kbit ##
tc class add dev eth1 parent 1:1 classid 1:11 htb rate 128kbit ceil
128kbit ##
tc class add dev eth1 parent 1:1 classid 1:12 htb rate 90kbit ceil
128kbit ##
... an so on
tc class add dev eth1 parent 1:1 classid 1:99 htb rate 1024kbit
ceil 3256kbit
#
tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst
213.???.???.??? flowid 1:10
tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst
213.???.???.??? flowid 1:10
tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst
62..???.???.??? flowid 1:11
tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst
213..???.???.??? flowid 1:12
tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 match ip dst
213.229.188.143 flowid 1:13
... and so on
- --> This part doesn't match any filter rule !!!!!
I think the possible problems could be:
tc doesn't match virtual interfaces, as the tc definition says eth1,
not eth1:?. I have tried to define tc filter rules using eth1:?, but
tc doen't likes that.
Anyone has been implemented an scenario similar than this ?
Any help will be appreciated !!
Regards
Enric Ramos
enric@helpdeskit.net
-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com>
iQA/AwUBPqmmLyu+yQzF8Lq8EQKZhwCg7xTocqm/RjEcaUScp2m4WX+k5HwAnjok
NPzvrkoSIl4B4izx2p5T3yhp
=P1Vy
-----END PGP SIGNATURE-----
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [LARTC] question about tc and ip aliasing
2003-04-25 21:18 [LARTC] question about tc and ip aliasing Enric Ramos Mas
@ 2003-04-28 8:45 ` Szymon Miotk
2003-04-28 19:26 ` Stef Coene
1 sibling, 0 replies; 3+ messages in thread
From: Szymon Miotk @ 2003-04-28 8:45 UTC (permalink / raw)
To: lartc
Enric Ramos Mas wrote:
> I have implemented a traffic control / advanced router server using
> iproute2 and tc (using htb). For all my outgoing tc policies, all
> it's ok (all the traffic goes out using eth0, and therefore I'm able
> to catch it using the corresponfing tc filter).
>
> However, the incoming traffic has to be treated in eth1, which has
> several virtual ifaces (eth1:0, eth1:1, eth1:2 and so on).
> Even I have introduced all the tc rules correctly, the kernel is not
> matching any filter rule and there is no way to match any destination
> into any queue discipline.
>
> Anyone knows some way to implement that ?
I'm also very interested about this question as I have similiar link
configuration.
One question about classes on eth0: do leaf rates (1:10 - 1:??) sum up
to 3256kbit (parent rate)?
I have to split 1040 kbit for 700 users and HTB manual advices
a) that children rates should sum up to parent rate
b) that the rate should not be less than 4kbit
I expect that I should go by the b) rule, as used rates will never sum
up over 1040kbit (there will never be 700 users using this link at the
same time).
Am I right?
Szymon Miotk
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [LARTC] question about tc and ip aliasing
2003-04-25 21:18 [LARTC] question about tc and ip aliasing Enric Ramos Mas
2003-04-28 8:45 ` Szymon Miotk
@ 2003-04-28 19:26 ` Stef Coene
1 sibling, 0 replies; 3+ messages in thread
From: Stef Coene @ 2003-04-28 19:26 UTC (permalink / raw)
To: lartc
On Monday 28 April 2003 10:45, Szymon Miotk wrote:
> Enric Ramos Mas wrote:
> > I have implemented a traffic control / advanced router server using
> > iproute2 and tc (using htb). For all my outgoing tc policies, all
> > it's ok (all the traffic goes out using eth0, and therefore I'm able
> > to catch it using the corresponfing tc filter).
> >
> > However, the incoming traffic has to be treated in eth1, which has
> > several virtual ifaces (eth1:0, eth1:1, eth1:2 and so on).
> > Even I have introduced all the tc rules correctly, the kernel is not
> > matching any filter rule and there is no way to match any destination
> > into any queue discipline.
> >
> > Anyone knows some way to implement that ?
>
> I'm also very interested about this question as I have similiar link
> configuration.
> One question about classes on eth0: do leaf rates (1:10 - 1:??) sum up
> to 3256kbit (parent rate)?
> I have to split 1040 kbit for 700 users and HTB manual advices
> a) that children rates should sum up to parent rate
> b) that the rate should not be less than 4kbit
This is the first time I hear about this rule. You can have a problem with
quantum if you have a low rate. But you can overrule quantum when you add a
htb class (rule : quantum > MTU).
> I expect that I should go by the b) rule, as used rates will never sum
> up over 1040kbit (there will never be 700 users using this link at the
> same time).
> Am I right?
Yes. The problem is that the parent rate is not respected. So if each class
is sending, it will exceed the parent rate. This can be "bad" because you
send more data then your router/modem can handle so it's possible that you
your shaping will not be that perfect.
Stef
--
stef.coene@docum.org
"Using Linux as bandwidth manager"
http://www.docum.org/
#lartc @ irc.oftc.net
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2003-04-28 19:26 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-04-25 21:18 [LARTC] question about tc and ip aliasing Enric Ramos Mas
2003-04-28 8:45 ` Szymon Miotk
2003-04-28 19:26 ` Stef Coene
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.