Re: [LARTC] $100 USD to the first person that can provide the rules/scripts

[Darryl Miles <lartc-list@the-morg.org>]

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@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/