[LARTC] vlan traffic shaping.

[LARTC] vlan traffic shaping.

[Robert Denier]

I couldn't find anyone who had actually made it work via google so I
guess I'll ask here.

My setup is a VPN point to point link.  The VPN is a modified version of
Openvpn where I'm using zlib compression to improve the compression a
bit.

The goal is to shape traffic coming from a routing server through the
vpn to the endpoint of the vpn and in such a way maximize the usefulness
of a limited bandwidth connection.

You can shape the vpn tunnel just fine, but that has a problem since you
shape the traffic _before_ any of it is compressed and thus cannot
really deal with compression in an ideal manner.

The ideal thing to do is to shape traffic after the VPN software
processes it and sends it to the real interface.  Of course, now that
I'm taking the time to explain the problem, an answer becomes somewhat
obvious and that is to add shaping just on the source/dest path used by
vpn packets on the real interface.

What I was trying to do was to create a vlan interface like eth0.5 and
then use that interface to run the VPN link, and thus have a nice
intermediate point where I can do all the shaping.  Unfortunately when
one actually tries to do this, the shaping seems to set itself up
normally, but in fact does absolutely nothing with the vlan interface.

I suppose some more analysis of my idea is in order.  I may be a little
wrong on some things so feel free to correct me.

1) You can shape all traffic correctly on the VPN link, except
compressible traffic which changes in size after leaving the VPN
software.

2) You could shape raw VPN packets based on source/dest type marking.
Now what does this mean for the shaping in 1)?  If this particular path
is at its max rate and the queue is full then a packet will be sent to
that interface but ultimately dropped.  VPN packets are UDP, so the
recovery would have to be in the VPN software.

It would seem if I'm understanding this correctly that even if I got
vlan to do what I thought I wanted it to do, it might not help anything.
Of course you might get around this by using TCP for vpn packets.

I'm a little uncertain of some things in the last couple paragraphs so
I'll probably just try it.  At any rate, one way for compression to
still be useful is to allow web pages to burst above the maximum
bandwidth by around 100KB.  This covers most of the cases where
compression is useful.  Anything low priority like ftp transfers must of
course be hard capped below the links capacity and set to a low
priority..


-- 
Robert Denier (denier@umr.edu)
PhD Electrical Engineering (May 2005)
University of Missouri-Rolla
http://www.finiteinfinity.com

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] vlan traffic shaping.

[Andy Furniss]

Robert Denier wrote:
> I couldn't find anyone who had actually made it work via google so I
> guess I'll ask here.
> 
> My setup is a VPN point to point link.  The VPN is a modified version of
> Openvpn where I'm using zlib compression to improve the compression a
> bit.
> 
> The goal is to shape traffic coming from a routing server through the
> vpn to the endpoint of the vpn and in such a way maximize the usefulness
> of a limited bandwidth connection.
> 
> You can shape the vpn tunnel just fine, but that has a problem since you
> shape the traffic _before_ any of it is compressed and thus cannot
> really deal with compression in an ideal manner.
> 
> The ideal thing to do is to shape traffic after the VPN software
> processes it and sends it to the real interface.  Of course, now that
> I'm taking the time to explain the problem, an answer becomes somewhat
> obvious and that is to add shaping just on the source/dest path used by
> vpn packets on the real interface.
> 
> What I was trying to do was to create a vlan interface like eth0.5 and
> then use that interface to run the VPN link, and thus have a nice
> intermediate point where I can do all the shaping.  Unfortunately when
> one actually tries to do this, the shaping seems to set itself up
> normally, but in fact does absolutely nothing with the vlan interface.
> 
> I suppose some more analysis of my idea is in order.  I may be a little
> wrong on some things so feel free to correct me.
> 
> 1) You can shape all traffic correctly on the VPN link, except
> compressible traffic which changes in size after leaving the VPN
> software.

It would be nice if a netfilter mark would carry over from before to 
after VPN - maybe the software could be hacked to do this. Then you 
could classify/mark traffic before encapsulation and shape it on eth0 - 
I have never tried, but don't think shaping on virtual eth0.x will work.
> 
> 2) You could shape raw VPN packets based on source/dest type marking.
> Now what does this mean for the shaping in 1)?  If this particular path
> is at its max rate and the queue is full then a packet will be sent to
> that interface but ultimately dropped.  VPN packets are UDP, so the
> recovery would have to be in the VPN software.

Double shaping is not going  to be Ideal. If you just shape after 
encapsulation I think the fact udp is used to encapsulate is irrelevant. 
If it is tcp that is being carried then the sender should react normally 
to drops.

Andy.

> 
> It would seem if I'm understanding this correctly that even if I got
> vlan to do what I thought I wanted it to do, it might not help anything.
> Of course you might get around this by using TCP for vpn packets.
> 
> I'm a little uncertain of some things in the last couple paragraphs so
> I'll probably just try it.  At any rate, one way for compression to
> still be useful is to allow web pages to burst above the maximum
> bandwidth by around 100KB.  This covers most of the cases where
> compression is useful.  Anything low priority like ftp transfers must of
> course be hard capped below the links capacity and set to a low
> priority..

_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc

Re: [LARTC] vlan traffic shaping.

[Arkadiusz Binder]

hello. I soon will have similar problem.

Do you know any vlan hardware switches from middle shelf price which can shape traffic on one interface between different vlans on it? With borrowing, not borrowing and priorityzing?

Linux1--34rmbit----hw_switch--34m--linux2
                             \--internet

On linux box side i consider  such scenario of solving my problem.
Vlan1=linux1-linux2
Vlan2=linux1-internet
Vlan3=linux2-internet

Vlan1+vlan24m, vlan2 cir=8 mbit
Vlan3 cir=8 mbit
All in duplex.

So i will create 2 queues in linux1, one for vlan1 and one for vlan2.
Build script that will do:
 tc -s ls dev eth0.1
Tc -s ls dev eth0.2

the script will be executed every second and will look for total bandwidth... When sum exceeds 33 mbits it will then set :
Tc class replace / qdisc replace, to decrease the bandwidth of vlan1, to improve vlan2.

I consider some checking of external link statistics if needed.

What do you think about that, if i cannot mix queues of eth0, eth0.1 and eth0.2 ???



_______________________________________________
LARTC mailing list
LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc