All of lore.kernel.org
 help / color / mirror / Atom feed
* [LARTC] Bridge + TC
@ 2004-03-15 11:15 Jon Anderson
  2004-03-15 15:28 ` Jon Anderson
                   ` (5 more replies)
  0 siblings, 6 replies; 7+ messages in thread
From: Jon Anderson @ 2004-03-15 11:15 UTC (permalink / raw)
  To: lartc

I'm hoping someone can provide a little input that might help me out a 
little...

I've recently tried to setup a 3-interface transparent bridge, where 2 
internal interfaces (eth1,eth2) funnel into 1 outgoing interface (eth0). 
The idea was to be that eth1 gets priority over eth2 in all cases.

The bridge works flawlessly - it passes all layer2 traffic through 
properly. The traffic control however, does not work at all. (The LARTC 
Howto says bridging + tc should "work as advertised", but no examples or 
instructions are given...)

The conclusion I came to was that bridging is done in layer2, and so 
traffic control code (typically layer3) never gets to touch it. Am I wrong?

Setup was: mark packets with ebtables, then filter into 2 qdiscs based 
on those marks.

Ebtables bit:
ebtables -A FORWARD -i eth1 -j mark --set-mark 0x1
ebtables -A FORWARD -i eth2 -j mark --set-mark 0x2
- This works, as ebtables' counters do count matching packets correctly 
(connecting a machine to and interface, and starting . (I assume that 
they set sk_buff->nfmark properly.)

.

Classes:
tc qdisc add dev eth0 root handle 1: htb default 10
tc class add dev eth0 parent 1: classid 1:1 htb rate 500kbit ceil 500kbit
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 450kbit ceil 500kbit prio 0
tc class add dev eth0 parent 1:1 classid 1:20 htb rate 50kbit ceil 500kbit prio 1

tc filter add dev eth0 parent 1:0 protocol ip prio 1 handle 1 fw classid 1:10

tc filter add dev eth0 parent 1:0 protocol ip prio 2 handle 2 fw classid 1:20

As I understand it, the second last line should put packets with nfmark 1 into class 1:10 (450-500 kbit), and the last line should put packets with nfmark 2 into class 1:20 (50-500kbit).

With an active host plugged into eth2, all I get is traffic going through the default class (1:10) according to 'tc -s show class dev eth0'

If anyone could offer any suggestions, I'd be glad to hear 'em.

Cheers,

jon anderson


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

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

* Re: [LARTC] Bridge + TC
  2004-03-15 11:15 [LARTC] Bridge + TC Jon Anderson
@ 2004-03-15 15:28 ` Jon Anderson
  2004-03-15 17:14 ` Jeroen Vriesman
                   ` (4 subsequent siblings)
  5 siblings, 0 replies; 7+ messages in thread
From: Jon Anderson @ 2004-03-15 15:28 UTC (permalink / raw)
  To: lartc

Jeroen Vriesman wrote:

>So I would suggest testing:
>
>1) no filter rule for 1:10 which is default
>  
>
This shouldn't affect things in the end though, correct? (I.e. it's 
overkill, but it won't hurt anything, right?)

(I've also had it pass by default through the 1:1, in which case nothing 
passed through 1:10, nor 1:20 - everything went through 1:1.)

>2) no filters with handle 1, (I start at 101 for the filters)
>  
>
>> tc filter add dev eth0 parent 1:0 protocol ip prio 1 handle 1 fw classid 1:10

"handle 1" - is that not how it picks up on nfmark? If nfmark is set to 
1, is this not the part that picks up that nfmark?

>3) marking with iptables in mangle PREROUTING
>  
>

I have also tried that. I'm using 2.6.3-mm3 -> packets don't seem to 
pass through iptables anymore unless they're specifically routed rather 
than bridged (can anyone confirm this?). I have another (2-if, no QoS) 
bridge running 2.4, and iptables commands filter fine. With this new 
bridge running 2.6, dropping everything with iptables doesn't work 
'iptables -A FORWARD -j DROP' doesn't affect the bridge in the least - 
hosts continue to talk through the bridge. (Same in ebtables works as 
expected though.)

>should work, it's working fine here on 2.4.24+ebtables 
>
>  
>
Perhaps the key here is 2.4. I might have to revert...

Thanks for the input. Now I have something else to try!

Cheers,

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

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

* Re: [LARTC] Bridge + TC
  2004-03-15 11:15 [LARTC] Bridge + TC Jon Anderson
  2004-03-15 15:28 ` Jon Anderson
@ 2004-03-15 17:14 ` Jeroen Vriesman
  2004-03-15 21:03 ` miller69
                   ` (3 subsequent siblings)
  5 siblings, 0 replies; 7+ messages in thread
From: Jeroen Vriesman @ 2004-03-15 17:14 UTC (permalink / raw)
  To: lartc

Hi,

I've got an almost simular setup, which is working fine.

something I noticed:

You say everything is going into class 1:10, which is both your default AND you got a filter for it <-??
I also see that your "default filter" has handle 1, in my setup the handles of the filters are unique.
For the rest, the only real difference is that I mark in the iptables mangle PREROUTING table, maybe an idea to test that.


So I would suggest testing:

1) no filter rule for 1:10 which is default
2) no filters with handle 1, (I start at 101 for the filters)
3) marking with iptables in mangle PREROUTING

should work, it's working fine here on 2.4.24+ebtables 

Cheers,
Jeroen.

On Mon, 15 Mar 2004 11:15:48 +0000
Jon Anderson <jon-anderson@rogers.com> wrote:

> I'm hoping someone can provide a little input that might help me out a 
> little...
> 
> I've recently tried to setup a 3-interface transparent bridge, where 2 
> internal interfaces (eth1,eth2) funnel into 1 outgoing interface (eth0). 
> The idea was to be that eth1 gets priority over eth2 in all cases.
> 
> The bridge works flawlessly - it passes all layer2 traffic through 
> properly. The traffic control however, does not work at all. (The LARTC 
> Howto says bridging + tc should "work as advertised", but no examples or 
> instructions are given...)
> 
> The conclusion I came to was that bridging is done in layer2, and so 
> traffic control code (typically layer3) never gets to touch it. Am I wrong?
> 
> Setup was: mark packets with ebtables, then filter into 2 qdiscs based 
> on those marks.
> 
> Ebtables bit:
> ebtables -A FORWARD -i eth1 -j mark --set-mark 0x1
> ebtables -A FORWARD -i eth2 -j mark --set-mark 0x2
> - This works, as ebtables' counters do count matching packets correctly 
> (connecting a machine to and interface, and starting . (I assume that 
> they set sk_buff->nfmark properly.)
> 
> .
> 
> Classes:
> tc qdisc add dev eth0 root handle 1: htb default 10
> tc class add dev eth0 parent 1: classid 1:1 htb rate 500kbit ceil 500kbit
> tc class add dev eth0 parent 1:1 classid 1:10 htb rate 450kbit ceil 500kbit prio 0
> tc class add dev eth0 parent 1:1 classid 1:20 htb rate 50kbit ceil 500kbit prio 1
> 
> tc filter add dev eth0 parent 1:0 protocol ip prio 1 handle 1 fw classid 1:10
> 
> tc filter add dev eth0 parent 1:0 protocol ip prio 2 handle 2 fw classid 1:20
> 
> As I understand it, the second last line should put packets with nfmark 1 into class 1:10 (450-500 kbit), and the last line should put packets with nfmark 2 into class 1:20 (50-500kbit).
> 
> With an active host plugged into eth2, all I get is traffic going through the default class (1:10) according to 'tc -s show class dev eth0'
> 
> If anyone could offer any suggestions, I'd be glad to hear 'em.
> 
> Cheers,
> 
> jon anderson
> 
> 
> _______________________________________________
> LARTC mailing list / LARTC@mailman.ds9a.nl
> http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
> 
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

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

* Re: [LARTC] Bridge + TC
  2004-03-15 11:15 [LARTC] Bridge + TC Jon Anderson
  2004-03-15 15:28 ` Jon Anderson
  2004-03-15 17:14 ` Jeroen Vriesman
@ 2004-03-15 21:03 ` miller69
  2004-03-15 22:11 ` Roy Walker
                   ` (2 subsequent siblings)
  5 siblings, 0 replies; 7+ messages in thread
From: miller69 @ 2004-03-15 21:03 UTC (permalink / raw)
  To: lartc

Hi,

> I have also tried that. I'm using 2.6.3-mm3 -> packets don't seem to 
> Perhaps the key here is 2.4. I might have to revert...
There was a change with kernel 2.6.0 for incoming and outgoing interfaces of
a bridge device (at least for iptables - that's why I'm guessing it also
affects ebtables):

> ebtables -A FORWARD -i eth1 -j mark --set-mark 0x1
> ebtables -A FORWARD -i eth2 -j mark --set-mark 0x2
Well for iptables a similar rule would look like:
iptables -A FORWARD -i eth1 -j MARK --set-mark 0x1

If eth1 is a port of a bridge you have to use with 2.6.x this:
iptables -A FORWARD -m physdev --physdev-in eth1 -j MARK --set-mark 0x1

Having a closer look at this may help solving your problem?

Regards,
 

-- 
+++ NEU bei GMX und erstmalig in Deutschland: TÜV-geprüfter Virenschutz +++
100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz

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

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

* RE: [LARTC] Bridge + TC
  2004-03-15 11:15 [LARTC] Bridge + TC Jon Anderson
                   ` (2 preceding siblings ...)
  2004-03-15 21:03 ` miller69
@ 2004-03-15 22:11 ` Roy Walker
  2004-03-16  1:00 ` Jon Anderson
  2004-03-16  9:45 ` miller69
  5 siblings, 0 replies; 7+ messages in thread
From: Roy Walker @ 2004-03-15 22:11 UTC (permalink / raw)
  To: lartc

I posted out on this problem some time ago and could never get 2.4.25 or any 2.6 kernel to work with TC + Bridging.  If anyone has this working and has actually tested it (I am actually just doing IP based iptables filtering from my bridge interface) please let us know what version of iproute you used and what patches you applied and with which version of the kernel.

The older 2.4.2x kernel's seem to work fine for this (I am currently running 2.4.22).

Roy

-----Original Message-----
From: miller69@gmx.net [mailto:miller69@gmx.net] 
Sent: Monday, March 15, 2004 3:03 PM
To: lartc@mailman.ds9a.nl
Subject: Re: [LARTC] Bridge + TC

Hi,

> I have also tried that. I'm using 2.6.3-mm3 -> packets don't seem to 
> Perhaps the key here is 2.4. I might have to revert...
There was a change with kernel 2.6.0 for incoming and outgoing interfaces of
a bridge device (at least for iptables - that's why I'm guessing it also
affects ebtables):

> ebtables -A FORWARD -i eth1 -j mark --set-mark 0x1
> ebtables -A FORWARD -i eth2 -j mark --set-mark 0x2
Well for iptables a similar rule would look like:
iptables -A FORWARD -i eth1 -j MARK --set-mark 0x1

If eth1 is a port of a bridge you have to use with 2.6.x this:
iptables -A FORWARD -m physdev --physdev-in eth1 -j MARK --set-mark 0x1

Having a closer look at this may help solving your problem?

Regards,
 

-- 
+++ NEU bei GMX und erstmalig in Deutschland: TÜV-geprüfter Virenschutz +++
100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz

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

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

* Re: [LARTC] Bridge + TC
  2004-03-15 11:15 [LARTC] Bridge + TC Jon Anderson
                   ` (3 preceding siblings ...)
  2004-03-15 22:11 ` Roy Walker
@ 2004-03-16  1:00 ` Jon Anderson
  2004-03-16  9:45 ` miller69
  5 siblings, 0 replies; 7+ messages in thread
From: Jon Anderson @ 2004-03-16  1:00 UTC (permalink / raw)
  To: lartc

Roy Walker wrote:

>I posted out on this problem some time ago and could never get 2.4.25 or any 2.6 kernel to work with TC + Bridging.  If anyone has this working and has actually tested it (I am actually just doing IP based iptables filtering from my bridge interface) please let us know what version of iproute you used and what patches you applied and with which version of the kernel.
>
>The older 2.4.2x kernel's seem to work fine for this (I am currently running 2.4.22).
>  
>
I just got this working under 2.4.25 on a different test rig (with only 
2 interfaces) - installed Debian Testing, patched and compiled a kernel 
with relevant stuff, start the bridge, apply tc rules, and *poof* 
packets get filtered/classified properly. All within 1.5 hrs.

`tc -s class show dev eth0` shows the right stuff going through the 
right filters at the right rate.

Versions/patches:
    iproute-20010824-13, from Debian testing
    iptables-1.2.9, from Debian testing (Used: iptables -t mangle -A 
PREROUTING -i eth1 -j MARK --set-mark 0x4 --> no ebtables needed)
    ebtables-brnf-5-vs-2.4.25 patch from ebtables.sourceforge.net
    kernel-2.4.25, with above ebtables patch

Hopefully it'll still work with 3 interfaces when I get 2.4.25 on the 
original test rig!

Cheers,

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

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

* RE: [LARTC] Bridge + TC
  2004-03-15 11:15 [LARTC] Bridge + TC Jon Anderson
                   ` (4 preceding siblings ...)
  2004-03-16  1:00 ` Jon Anderson
@ 2004-03-16  9:45 ` miller69
  5 siblings, 0 replies; 7+ messages in thread
From: miller69 @ 2004-03-16  9:45 UTC (permalink / raw)
  To: lartc

> I posted out on this problem some time ago and could never get 2.4.25 or 
> any 2.6 kernel to work with TC + Bridging.  If anyone has this working 
> and has actually tested it (I am actually just doing IP based iptables 
> filtering from my bridge interface) please let us know what version of 
> iproute you used and what patches you applied and with which version of 
> the kernel.
-Vanilla kernel 2.6.3 form kernel.org - no patches applied just ethernet
bridging and Bridged IP/ARP packets filtering enabled in kernel config.
-iptables snapshot v1.2.9-20040302
-as far as I remember tc is from the htb homepage
http://luxik.cdi.cz/~devik/qos/htb/

Regards,

-- 
+++ NEU bei GMX und erstmalig in Deutschland: TÜV-geprüfter Virenschutz +++
100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz

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

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

end of thread, other threads:[~2004-03-16  9:45 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-03-15 11:15 [LARTC] Bridge + TC Jon Anderson
2004-03-15 15:28 ` Jon Anderson
2004-03-15 17:14 ` Jeroen Vriesman
2004-03-15 21:03 ` miller69
2004-03-15 22:11 ` Roy Walker
2004-03-16  1:00 ` Jon Anderson
2004-03-16  9:45 ` miller69

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.