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
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..
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+vlan2=34m, 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
???