Greg,
You do not say in your original article how your 640kbit/640kbit link is attached, eth0, eth1 or pppX? If the interface is dedicated only for WAN usage, or if the WAN be via a gateway? If your VPN endpoint hosts are on the same or a different box to that with the 640kbit link.
You did not say if pinging between the two tunnel endpoint addresses (i.e. their non-10.x.x.x addresses) also had any latency reduction during the times of increased latency through the tunnel. I'm trying to establish if the 640kbit link is the point where the queuing occurs, or if its never saturated and the problem with your TC rule set.
Since I expect the 640kbit link is your bottle neck, and that there is a quantity of non-VPN traffic also passing through this point (web browsing, email, internet downloading), rules MUST also be applied here. It is this point causing your latency issue, the device interface queue is whats holding all the packets and thus adding propagation delay. While the traffic going into the IPSEC it being controlled, there is nothing I can see in your configuration which arbitrates bandwidth usage between webbrowsing and VPN data over the 640kbit link.
I am not the most knowledgable person about VPN and TC operation, but I would look for a solution using ipchains to MARK the DS/TOS field of the outside IP header of VPN packets only for VoIP/HiPriority packets, this has to be done on the box which is a VPN endpoint at the point each packet enters the tunnel. Maybe the inside TOS field is already copied into the outside TOS field during encapsulation (this is what I believe IPIP and GRE encaps would do). Use tcpdump on both the inside and outside interfaces, if possible to see. I would expect the UDP packets to already be marked with a "low latency" TOS (due to the nature of the applications), if this is the case then you have enough information to distinguish your important traffic from the rest over the 640kbit link. Other than this suggestion I'm not sure how you can mark the outside IP packet header based on the inside IP, UDP/TCP content during encapsulation (I'd like to know myself). I do not think any TC rules need to be applied to the ipsec0 interface, I believe you only need to ensure the packets have been marked at this point.
The next thing to do is, at the box with the 640kbit link, use your TC rule set to provide bandwidth reservation based on the protocol byte (VPN traffic, ESP/AH, etc..) and the IP DS/TOS header marking to select them to be placed in a higher priority queue.
Don't forget to account with the packet length increase due to the extra layer of headers of VPN traffic, both in overall bandwidth calculation and average packet length.
If your 640kbit link were say DSL and your DSL providers equipment was between the two 640kbit link interfaces, then there are also other issues with managing the inbound packet queue length at your ISP. Check out the "WonderShaper" (on google) for information on the problem and how the TC rules in it help the situation, but basically your Internet downloads need to be controlled to prevent queueing by your ISP when it sends inbound data to you.
Hope I read your original article correctly and am I'm pitching at the real problem,
Darryl
_______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
