Betterment of diagnostics for VPN connection issues in LH

  • [アーティクル]

To have a better diagnostics around VPN connection issues in LH, RRAS has introduced a functionality of tagging the VPN connection related events with what is called as "Correlation-ID" (CoID).

The relevant event messages are prefixed with "CoID={128 bit identifier}". Note: Not all the event messages are tagged with the CoID, as mentioned above it tags only the VPN connection related events. The CoID are tagged in the RRAS client event messages and the same CoID is transferred to the RRAS Server for the same connection and all the event messages associated on the RRAS server are tagged with the same CoID. This way user administration would be able to correlate the events on the RRAS client and RRAS server with the same CoID which could be used for better debugging of the issue end to end.

The same CoID is also tagged to the Windows Software Trace Preprocessor (WPP) logs trace events on the client and the server as well. This way even if the VPN connection request is still not established connection with the server, based on the CoID one could analyze the logged events with the WPP logged tracing events to narrow down the problem at the client end itself.

Similar to how using the CoID one is able to correlate events between RRAS Client and RRAS Server, the CoID will be sent by RRAS Server to NPS Server as well. So that the associated events in the NPS are also tagged with the CoID.

Similarly with respect to Network Access protection (NAP) scenarios, the NAP Agent running on the RRAS client would tag a NAP CoID on the NAP related event messages on the client. The RRAS Client would tag all the connection related events with CoID. Note the NAP CoID and RRAS CoID are distinct and hence since they too need to be correlated to have an end to end diagnosis. RASQEC logs one event that has both RRAS CoID and NAP CoID.

Mahesh Narayanan
Program Manager
RRAS, Windows Enterprise Networking
[This posting is provided "AS IS" with no warranties, and confers no rights.]

Comments

  • Anonymous
    January 01, 2003
    Any luck of improved diagnostics on the client side for DUNS VPN connections (ie. ISAKMP progress rather than timeout for L2TP/IPSec, or indication of whether or not PPP negotiations as started or not for PPTP)?