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@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
