thr3ads.net - Shorewall users - prioritizing/shaping in a VPN tunnel [Nov 2011]

If this information is useful, please help other people find it:
Share via:

Brian J. Murrell

2011-Nov-13 16:14 UTC

prioritizing/shaping in a VPN tunnel

OK.  So, even though I have to do it in a way that doesn''t seem
entirely clear,
I have managed to shape/prioritize upstream traffic.  Witness:

# (sleep 7; dd if=/dev/zero bs=1M count=8 | ssh linux cat \>/dev/null &)
# ping 99.227.140.1
PING 99.227.140.1 (99.227.140.1) 56(84) bytes of data.
64 bytes from 99.227.140.1: icmp_seq=1 ttl=255 time=8.62 ms
64 bytes from 99.227.140.1: icmp_seq=2 ttl=255 time=6.91 ms
64 bytes from 99.227.140.1: icmp_seq=3 ttl=255 time=6.70 ms
64 bytes from 99.227.140.1: icmp_seq=4 ttl=255 time=12.7 ms
64 bytes from 99.227.140.1: icmp_seq=5 ttl=255 time=6.65 ms
64 bytes from 99.227.140.1: icmp_seq=6 ttl=255 time=5.83 ms
64 bytes from 99.227.140.1: icmp_seq=7 ttl=255 time=9.73 ms
64 bytes from 99.227.140.1: icmp_seq=8 ttl=255 time=110 ms
64 bytes from 99.227.140.1: icmp_seq=9 ttl=255 time=52.5 ms
64 bytes from 99.227.140.1: icmp_seq=10 ttl=255 time=33.3 ms
64 bytes from 99.227.140.1: icmp_seq=11 ttl=255 time=34.4 ms
64 bytes from 99.227.140.1: icmp_seq=12 ttl=255 time=13.6 ms
64 bytes from 99.227.140.1: icmp_seq=13 ttl=255 time=61.0 ms
64 bytes from 99.227.140.1: icmp_seq=14 ttl=255 time=41.0 ms
64 bytes from 99.227.140.1: icmp_seq=15 ttl=255 time=17.3 ms
64 bytes from 99.227.140.1: icmp_seq=16 ttl=255 time=20.3 ms
64 bytes from 99.227.140.1: icmp_seq=17 ttl=255 time=25.4 ms

So as you can see when pining the next-hop router (99.227.140.1), at the 7-8s 
mark there is a tiny blip upward, and even while that is still reasonable, ping 
times come back even better.  The shaping is working wonderfully.

For reference, the host "linux" to which I''m pushing traffic
in the benchmark,
is actually at the other end of an openvpn tunnel from the machine I am running 
the above on, so the upstream bandwidth is actually saturated with openvpn udp 
packets, not raw ssh packets and so the shaping on the external interface (eth0)
is dealing with the openvpn packets and the icmp packets and doing a wonderful 
job.

What doesn''t seem to be working is shaping inside the tunnel.  Witness:

# (sleep 7; dd if=/dev/zero bs=1M count=8 | ssh linux cat \>/dev/null &)
# ping linux
PING 10.75.22.3 (10.75.22.3) 56(84) bytes of data.
64 bytes from 10.75.22.3: icmp_seq=1 ttl=63 time=34.0 ms
64 bytes from 10.75.22.3: icmp_seq=2 ttl=63 time=31.8 ms
64 bytes from 10.75.22.3: icmp_seq=3 ttl=63 time=32.4 ms
64 bytes from 10.75.22.3: icmp_seq=4 ttl=63 time=35.4 ms
64 bytes from 10.75.22.3: icmp_seq=5 ttl=63 time=30.9 ms
64 bytes from 10.75.22.3: icmp_seq=6 ttl=63 time=32.3 ms
64 bytes from 10.75.22.3: icmp_seq=7 ttl=63 time=572 ms
64 bytes from 10.75.22.3: icmp_seq=8 ttl=63 time=763 ms
64 bytes from 10.75.22.3: icmp_seq=9 ttl=63 time=150 ms
64 bytes from 10.75.22.3: icmp_seq=10 ttl=63 time=181 ms
64 bytes from 10.75.22.3: icmp_seq=11 ttl=63 time=367 ms
64 bytes from 10.75.22.3: icmp_seq=12 ttl=63 time=586 ms
64 bytes from 10.75.22.3: icmp_seq=13 ttl=63 time=706 ms
64 bytes from 10.75.22.3: icmp_seq=14 ttl=63 time=767 ms
64 bytes from 10.75.22.3: icmp_seq=15 ttl=63 time=775 ms
64 bytes from 10.75.22.3: icmp_seq=16 ttl=63 time=776 ms
64 bytes from 10.75.22.3: icmp_seq=17 ttl=63 time=877 ms
64 bytes from 10.75.22.3: icmp_seq=18 ttl=63 time=1435 ms
64 bytes from 10.75.22.3: icmp_seq=19 ttl=63 time=718 ms
64 bytes from 10.75.22.3: icmp_seq=20 ttl=63 time=891 ms

So same data generation, inside the tunnel and a ping also inside the tunnel.  
Now the traffic shaping on eth0 is dealing with only the openvpn udp packets and
I need traffic shaping/prioritization of the traffic in the tunnel, on tun0.

http://www.shorewall.net/simple_traffic_shaping.html suggests being able to name
a VPN interface in the tcinterfaces to effect shaping on that interface as such:

#INTERFACE             TYPE          IN-BANDWIDTH
tun0                   Internal

Which I have done:

# cat tcinterfaces 
#INTERFACE      TYPE            IN-BANDWIDTH
eth0            External        6mbit           500kbit
tun0            Internal

But that doesn''t seem to give me those nice results as
shaping/prioritization on
eth0.  What am I missing?

For the record, the openvpn traffic is the only traffic on the external 
interface (eth0) so this is not a case of the openvpn traffic contending with 
other traffic.

Any ideas?

Cheers,
b.



------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1

Brian J. Murrell

2011-Nov-13 16:48 UTC

head link

Re: prioritizing/shaping in a VPN tunnel

Brian J. Murrell <brian <at> interlinx.bc.ca>
writes:> 
> What doesn''t seem to be working is shaping inside the tunnel.
And once again, setting a value on the fourth column (out-bandwidth) of the 
tcinterfaces actually made this work as such:

#INTERFACE      TYPE            IN-BANDWIDTH
eth0            External        6mbit           500kbit
tun0            Internal        6mbit           460kbit

But you see, now I am artificially limiting my already limited upstream, which
is why I prefer pure prioritization over artificially prioritizing by limiting 
bandwidth.

And FWIW, I did try setting the out-bandwidth of the tun0 before my previous 
posting but I had it set to 500kbit, which obviously
won''t/doesn''t work.  FWIW,
460kbit seems to be about the highest I can go and still get consistent ping 
results, which is almost 10% of my upstream bandwidth.

Cheers,
b.



------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1

Shorewall users - Nov 2011 - prioritizing/shaping in a VPN tunnel

prioritizing/shaping in a VPN tunnel

Re: prioritizing/shaping in a VPN tunnel