Diagnosing VPN connectivity issues

"Frank Bulk" <[email protected]> Sat, 24 Apr 2010 12:29:57 -0500
Newsgroups gmane.org.operators.internet-access
Message-ID <!&!AAAAAAAAAAAuAAAAAAAAAKTyXRN5/+lGvU59a+P7CFMBAN6gY+ZG84BMpVQcAbDh1IQAAAATbSgAABAAAADaEGDNoqZpTYgxKNJp6rx7AQAAAAA=@iname.com>
We have several small enterprise customers who, on occasion, complain about
VPN tunnel stability issues to their remote branches.  After eliminating the
obvious physical plant issues (whether that be cable broadband, ADSL, SHDSL,
or fiber), we have them run PingPlotter in both directions.  While
PingPlotter is better than nothing, I would say it helps identify the issue
only 10 to 20% of the time.  Not to speak of the time helping the customer
properly interpret the PingPlotter results (they get caught up on ICMP
packet loss at one hop that has no packet loss any further, and my attempted
explanations regarding control plane rate-limiting usually loses them and
they point at the red lines).  And you know how it goes -- they point the
finger at us, and we honestly want to help them, but if our L1, L2, and L3
checks come up clean, what then?  I hate to point to fingers.  If I ask for
basic information such as VPN debug logs from their VPN gear the customers
aren't able to help.  It's usually frustrating -- they want to the issue
resolved, but often aren't willing to spend the time to work with us to
identify the issue.

What are others doing to help their customers with their VPN issues?  

Frank

-- 
Eat sushi frequently. - Avi
[email protected] is the human contact address.
[email protected] is the list posting address.
See below URL for subscribe/unsubscribe and list options:
http://inet-access.net/mailman/listinfo/list