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