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 _______________________________________________ Shorewall-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/shorewall-users
