[LARTC] QOS Script difficulty on bridge

[LARTC] QOS Script difficulty on bridge

[Ed Wildgoose]

I'm playing with the rather excellent QOS script from Alexander Clouter  
at http://digriz.org.uk/jdg-qos-script/

So far I am really impressed with it - a very impressive example of the 
power of linux QOS rules (has pretty much everything in it from the 
LARTC Howto!)  However, the instructions hint that "for QoS to affect 
locally generated traffic in a non ethernet bridge setup you must have 
IMQ". 

Now, I *DO* have a bridged config (br -> eth0 & eth1), but I can't see 
how I can set things up so that traffic from the local machine suffers 
the effect of the QOS limitations (on download) without using IMQ.

More broadly, can *anyone* see how it might be possible to limit the 
download rate to a local machine running as a bridge, without using IMQ? 
(err, and not using the policer either, I want an HTB qdisk running on 
the download traffic - I just want to know if I am missing something 
obvious about the way the bridge works)

Just for reference only the bridge has an ip address, both physical 
interfaces are anonymous.

Thanks for any pointers. 

Ed W

P.S. Anyone using this script on 2.6 with a bridge needs to be aware 
that the syntax for "tc" has changed.  You can't use "tc -i eth0" 
anymore, you need "tc -i br0 -m physdev --physdev-in eth0".  And the 
same for "-o".  Hope that helps anyone who tries the script out

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

RE: [LARTC] QOS Script difficulty on bridge

[S Mohan]

If eth0 is your interface connected to the Internet, shape outgoing traffic
on eth1. This will simulate the effect of limiting download coming thro'
eth0 and also shape traffic from the local machine going out to the LAN on
eth1. In case you want to limit download from the local machines to nodes on
eth0 and eth1, apply QoS on both interfaces. Bridging does not affect or
help this in any way. Ethernet interfaces do not need to have IP addresses
for QoS to be applied in Linux. I've used htb-init with bridge-nf which has
been documented in the LEAF Bering user manual. In case you have any
questions, I'll be glad to answer them as the maintainer of that part of the
documentation.

HTH.

Warm regards
Mohan  

> -----Original Message-----
> From: lartc-admin@mailman.ds9a.nl 
> [mailto:lartc-admin@mailman.ds9a.nl] On Behalf Of Ed Wildgoose
> Sent: Wednesday, June 16, 2004 9:23 PM
> To: lartc@mailman.ds9a.nl
> Subject: [LARTC] QOS Script difficulty on bridge
> 
> I'm playing with the rather excellent QOS script from 
> Alexander Clouter at http://digriz.org.uk/jdg-qos-script/
> 
> So far I am really impressed with it - a very impressive 
> example of the power of linux QOS rules (has pretty much 
> everything in it from the LARTC Howto!)  However, the 
> instructions hint that "for QoS to affect locally generated 
> traffic in a non ethernet bridge setup you must have IMQ". 
> 
> Now, I *DO* have a bridged config (br -> eth0 & eth1), but I 
> can't see how I can set things up so that traffic from the 
> local machine suffers the effect of the QOS limitations (on 
> download) without using IMQ.
> 
> More broadly, can *anyone* see how it might be possible to 
> limit the download rate to a local machine running as a 
> bridge, without using IMQ? 
> (err, and not using the policer either, I want an HTB qdisk 
> running on the download traffic - I just want to know if I am 
> missing something obvious about the way the bridge works)
> 
> Just for reference only the bridge has an ip address, both 
> physical interfaces are anonymous.
> 
> Thanks for any pointers. 
> 
> Ed W
> 
> P.S. Anyone using this script on 2.6 with a bridge needs to 
> be aware that the syntax for "tc" has changed.  You can't use 
> "tc -i eth0" 
> anymore, you need "tc -i br0 -m physdev --physdev-in eth0".  
> And the same for "-o".  Hope that helps anyone who tries the 
> script out
> 
> _______________________________________________
> 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/

Re: [LARTC] QOS Script difficulty on bridge

[Jason Boxman]

On Wednesday 16 June 2004 11:53, Ed Wildgoose wrote:
<snip>
> Ed W
>
> P.S. Anyone using this script on 2.6 with a bridge needs to be aware
> that the syntax for "tc" has changed.  You can't use "tc -i eth0"
> anymore, you need "tc -i br0 -m physdev --physdev-in eth0".  And the
> same for "-o".  Hope that helps anyone who tries the script out

There is no `tc -i` afaik?

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

Re: [LARTC] QOS Script difficulty on bridge

[Ed Wildgoose]

Jason Boxman wrote:

>On Wednesday 16 June 2004 11:53, Ed Wildgoose wrote:
><snip>
>  
>
>>Ed W
>>
>>P.S. Anyone using this script on 2.6 with a bridge needs to be aware
>>that the syntax for "tc" has changed.  You can't use "tc -i eth0"
>>anymore, you need "tc -i br0 -m physdev --physdev-in eth0".  And the
>>same for "-o".  Hope that helps anyone who tries the script out
>>    
>>
>
>There is no `tc -i` afaik?
>  
>

Durr.. I meant "iptables -i".  Sorry, was thinking about something 
else.  Please sub tc for iptables in the above.

Any ideas on how to do this though?

Ed W

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

Re: [LARTC] QOS Script difficulty on bridge

[Ed Wildgoose]

S Mohan wrote:

>If eth0 is your interface connected to the Internet, shape outgoing traffic
>on eth1. This will simulate the effect of limiting download coming thro'
>eth0 and also shape traffic from the local machine going out to the LAN on
>eth1. In case you want to limit download from the local machines to nodes on
>eth0 and eth1, apply QoS on both interfaces. Bridging does not affect or
>help this in any way. Ethernet interfaces do not need to have IP addresses
>for QoS to be applied in Linux. I've used htb-init with bridge-nf which has
>been documented in the LEAF Bering user manual. In case you have any
>questions, I'll be glad to answer them as the maintainer of that part of the
>documentation.
>  
>

Hmm, leaf looks like a very interesting project.  THanks for the link

I think I wasn't clear though:  I understand what I need to do to limit 
traffic into the whole network, it's limiting it to the bridge machine 
that is causing me problems

Consider:

Internet -> Router -> Eth1 -> br0 -> Eth0 -> local net

Now by applying QOS to eth1 I control outgoing traffic from everywhere.  
By applying QOS to eth0 I control incoming to the localnet (great), but 
NOT to the local bridge machine

Now I could fix this by using the IMQ device on eth1 and grabbing 
incoming traffic, but the top of the file at 
http://digriz.org.uk/jdg-qos-script/ implies that it is possible to do 
this without IMQ... 

The question is how?  I don't see how to do it....  What am I missing?

Thanks

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

Re: [LARTC] QOS Script difficulty on bridge

[Jason Boxman]

On Thursday 17 June 2004 03:29, Ed Wildgoose wrote:
<sni>
> Consider:
>
> Internet -> Router -> Eth1 -> br0 -> Eth0 -> local net
>
> Now by applying QOS to eth1 I control outgoing traffic from everywhere.
> By applying QOS to eth0 I control incoming to the localnet (great), but
> NOT to the local bridge machine
>
> Now I could fix this by using the IMQ device on eth1 and grabbing
> incoming traffic, but the top of the file at
> http://digriz.org.uk/jdg-qos-script/ implies that it is possible to do
> this without IMQ...
>
> The question is how?  I don't see how to do it....  What am I missing?

It's my understanding that you cannot attach much of anything except the 
police filter on the ingress hook.  As such, you need IMQ to attach egress 
qdiscs to for application to incoming traffic, as you would to the root hook 
for egress traffic.

http://www.docum.org/docum.org/kptd/

> Thanks
>
> Ed W


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

Re: [LARTC] QOS Script difficulty on bridge

[Ed Wildgoose]

Jason Boxman wrote:

>On Thursday 17 June 2004 03:29, Ed Wildgoose wrote:
><sni>
>  
>
>>Consider:
>>
>>Internet -> Router -> Eth1 -> br0 -> Eth0 -> local net
>>
>>Now by applying QOS to eth1 I control outgoing traffic from everywhere.
>>By applying QOS to eth0 I control incoming to the localnet (great), but
>>NOT to the local bridge machine
>>
>>Now I could fix this by using the IMQ device on eth1 and grabbing
>>incoming traffic, but the top of the file at
>>http://digriz.org.uk/jdg-qos-script/ implies that it is possible to do
>>this without IMQ...
>>
>>The question is how?  I don't see how to do it....  What am I missing?
>>    
>>
>
>It's my understanding that you cannot attach much of anything except the 
>police filter on the ingress hook.  As such, you need IMQ to attach egress 
>qdiscs to for application to incoming traffic, as you would to the root hook 
>for egress traffic.
>
>http://www.docum.org/docum.org/kptd/
>  
>

Sure, that's my understanding as well, but see the comments at the top 
of the script, and also the way the script carefully checks for a bridge 
connection and avoids using the IMQ device...

Perhaps it's just a mistaken comment, but it implies that he thinks it's 
possible to avoid using the IMQ device...  I can't see how though (I did 
drop him an email, but no answer so far)

THanks for any ideas on this conundrum

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