End-to-End, Bottom-Up (or Top-Down) Troubleshooting
Troubleshooting can take many forms, but VPN technologies are particularly suited to end-to-end, bottom-up (or top-down) troubleshooting.
For example, if you are troubleshooting a compulsory mode Layer Two Tunneling Protocol (L2TP) version 2 VPN (with dial-in), the first thing to do is to confirm that remote clients' calls are being received on the L2TP Access Concentrator (LAC). Next you should confirm that Link Control Protocol (LCP) and partial authentication are being successfully completed on the LAC. Then you should confirm that L2TP tunnel and session setup is successful between the LAC and the L2TP Network Server (LNS). Finally, you can verify that PPP negotiation is successfully completed between the remote client and the LNS. Figure 1-2 illustrates L2TPv2 VPN setup.
In this example, setup is asymmetric—the calling party is the remote client, and the called party is (ultimately) the LNS.
Some other VPN technologies require a symmetric approach to troubleshooting. A good example of this is MPLS Layer 3 (RFC 2547bis) VPNs. In this case, you need to verify route exchange between customer edge (CE) routers bidirectionally over the MPLS VPN backbone. Additionally, you will need to verify the label switched path (LSP) in both directions between provider edge (PE) routers across the MPLS backbone. Figure 1-3 illustrates route exchange and LSPs across the MPLS VPN backbone.
Figure 1-3. Bidirectional Route Exchange and LSPs Across the MPLS VPN Backbone
When you are troubleshooting a VPN, you should never lose sight of the underlying physical, data-link, and network layer protocols.
It is always good practice to ask yourself what must happen first, then next, then after that for the VPN to function correctly. Also ask yourself what underlies each particular process or mechanism.