[LARTC] HTB and Openvpn

[LARTC] HTB and Openvpn

[Peter Huetmannsberger]

Hi!

I have just started with traffic shaping, and after hours of reading 
websites, man pages asf. I am still stumped at one problem I have. 

The interface eth0 is attached to the outside world, and I have an openvpn 
tunnel to another part of the organization using eth0 and port 5001.

The idea was that all traffic going through the tunnel would have top 
priority and the rest share what's left. Sounded simple enough. 

Here's what I did: 

tc qdisc add dev eth0 root handle 1: htb default 30
tc class add dev eth0 parent 1: classid 1:1 htb rate 10mbit burst 15k
tc class add dev eth0 parent 1:1 classid 1:10 htb rate 700kbit ceil 1mbit 
	burst 15k prio 0
tc class add dev eth0 parent 1:1 classid 1:20 htb rate 1kbit ceil 28800 
	burst 15k
tc class add dev eth0 parent 1:1 classid 1:30 htb rate 1kbit ceil 1mbit 
	burst 15k prio 1
tc qdisc add dev eth0 parent 1:10 handle 10: sfq perturb 10
tc qdisc add dev eth0 parent 1:20 handle 20: sfq perturb 10
tc qdisc add dev eth0 parent 1:30 handle 30: sfq perturb 10
U32="tc filter add dev eth0 protocol ip parent 1:0 prio 0 u32"
$U32  match ip dport 5001 0xffff match ip protocol 17 0xff flowid 1:10
$U32  match ip sport 5001 0xffff match ip protocol 17 0xff flowid 1:10
$U32  match ip dport 5001 0xffff match ip protocol 6 0xff flowid 1:10
$U32  match ip sport 5001 0xffff match ip protocol 6 0xff flowid 1:10

As openvpn uses UDP on port 5001 I tried to use the protocol filter with 
the port filter. 

What happens though is that still about two thirds of the traffic goes 
through 1:30 (default), even though a tcpdump -i eth0 only shows UDP 
traffic on port 5001.

Thus I loose 2/3rds of the traffic to the default qdisc and have no 
guaranteed bandwidth. 

1:20 is only for testing purposes and nothing goes over that one.  

Any idea where I could be wrong? I am sure a lot of this is redundant, but 
as I said, I have only just started with this particular subject. 

Many thanks in advance

Peter Huetmannsberger
Admin Center for Contemporary Art, Linz

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

Re: [LARTC] HTB and Openvpn

[Andreas Klauer]

Peter Huetmannsberger wrote:
> The idea was that all traffic going through the tunnel would have top 
> priority and the rest share what's left. Sounded simple enough. 

You could use a prio queue for that. Tunnel on band 0, rest on band 1. 
Downside is that there may be nothing left for the rest to share. :-)

> tc class add dev eth0 parent 1: classid 1:1 htb rate 10mbit burst 15k

Why make a 10mbit class when it's not used? I find it hard to tell what 
will happen when the rates don't add up properly.

> tc class add dev eth0 parent 1:1 classid 1:10 htb rate 700kbit ceil 1mbit 
> 	burst 15k prio 0

Since the parent has 10mbit which is never fully used, this class will 
most likely always borrow as much as it can. So although it says 700kbit 
it's really a 1mbit class.

> tc class add dev eth0 parent 1:1 classid 1:20 htb rate 1kbit ceil 28800 
> 	burst 15k

This class does not seem to be used at all, why does it exist?

> tc class add dev eth0 parent 1:1 classid 1:30 htb rate 1kbit ceil 1mbit 
> 	burst 15k prio 1

Another 1mbit class. The parent has 10mbit, so there's no reason why it 
shouldn't be able to borrow another mbit, no matter what the actual 
priority of that class is. Am I wrong? :)

> Any idea where I could be wrong?

Guesswork:

The logic of your class structure is flawed.

How fast is your connection to the outside world? I guess it's 1mbit, 
because you set the ceil of your VPN/rest class to 1mbit? However, the 
parent class of those two is a 10mbit class, so both borrow one 1mbit 
from that (they don't share the same one single mbit). In that case, no 
proper shaping is done at all.

10mbit then would be your LAN?

Then how about this class setup:

1:1      10mbit (LAN interface)
|
\--- 1:2 09mbit (LAN only traffic)
\--- 1:3 01mbit (Outside world traffic)
      |
      \--- 1:31 700kbit (VPN)
      \--- 1:32 300kbit (Rest)

This is (about) the kind of setup I use at home.
Make sure your rates add up.

If you intend to give your (Rest) class 1kbit only, throw HTB away and 
use PRIO instead. If (Rest) doesn't need any bandwidth at all, you can 
as well let it starve completely by using prio. And that's much less 
complicated than HTB.

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

Re: [LARTC] HTB and Openvpn

[Peter Huetmannsberger]

Hi, many thanks for your help. 

I have changed my setup accordingly now, however there are still packets 
showing up on the default qdisc when I go through the tunnel, about half 
the packets don't seem to match. 

Did you see anything wrong with the filter rules. Openvpn uses port 5001 
on both ends, and tcpdump -i eth0 shows udp packets going back and forth 
on port 5001 and no other traffic, yet the default counter goes up along 
with the 1:10 qdisc.

Thanks again. 

.peter


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

Re: [LARTC] HTB and Openvpn

[Andreas Klauer]

Peter Huetmannsberger wrote:
> I have changed my setup accordingly now, however there are still packets 
> showing up on the default qdisc when I go through the tunnel, about half 
> the packets don't seem to match. 

If there really only is udp traffic on port 5001, I don't see why your 
rules should match that only partially. If they were wrong, they'd 
either match everything or nothing at all, wouldn't they?

> Did you see anything wrong with the filter rules. Openvpn uses port 5001 
> on both ends, and tcpdump -i eth0 shows udp packets going back and forth 
> on port 5001 and no other traffic, yet the default counter goes up along 
> with the 1:10 qdisc.

I don't know tcpdump - when debugging filter rules, I usually adapt 
these rules to iptables and use iptables log with different prefixes to 
distinct which packets matched which rules (and which didn't match at 
all). If nothing shows up this way, then I too am clueless as to what 
might be wrong. Maybe someone else has a suggestion. :)

I don't have any experience with OpenVPN myself, so I don't know what's 
the best way to match OpenVPN traffic. Using port criteria alone, might 
not be waterproof enough, as long as anyone can use these ports for 
anything. Matching both IP and Port would probably be more reliable.

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