Troubleshooting Tools

The primary tools for troubleshooting VPNs are the show, ping, traceroute, and debug commands. For these commands to be used correctly (and safely), a number of guidelines need to be followed.

The show command can be used to view a wide variety of information and statistics related to VPNs.

The ping and traceroute commands can be used to verify basic IP connectivity and route across the network. The traceroute command can also be used in an MPLS backbone to display the label stack. Maximum Transmission Unit (MTU) issues that may result in a VPN can also be identified using extended ping to sweep a range of packet sizes. If pings using smaller packet sizes succeed but larger packet sizes fail, this can indicate an issue with the MTU in the VPN.

Finally, the debug command can be used to display a variety of status and error information associated with VPNs. Although debug is a useful and, at times, essential tool, there are some dangers with using it. If you use the wrong debug command, or do not filter its output, the output can tie up all the systems resources and potentially cause the system to hang.

You can employ a number of ways to avoid loading the system too much. The first is not to debug via the console, but instead to debug via a Telnet session. Use the no logging console command to turn off logging to console. Use the terminal monitor command to view debugging output via a Telnet session. The terminal no monitor command disables viewing debug output via a Telnet session.

It might even be a good idea to open a second Telnet session to the device in question so that debugging can still be turned off even if the first session is overwhelmed with output from a debug command. You can also redirect debug output to a syslog server using the logging syslog_server_ip_address command.

Note that the quickest (most abbreviated) way to cancel all debug commands is by entering the un all command. This is an abbreviation of the undebug all command.

One very useful command, particularly when debugging L2F, PPTP, L2TP, Any Transport over MPLS (AToM), and IPSec is debug condition or debug crypto condition (for IPSec). The debug condition command can be used to limit the output of a debug command so that only the output related to a particular called or calling number, interface, username, IP address, or AToM virtual circuit (VC) ID is displayed. The debug condition command can be used to limit the output of the following commands:

• debug aaa {accounting | authorization | authentication}

• debug dialer {events | packets}

• debug isdn {q921 | q931}

• debug modem {oob | trace}

• debug ppp {all | authentication | chap | error | negotiation | multilink events | packet}

• debug mpls l2transport vc {event | fsm}

• debug crypto {isakmp | ipsec | engine}

In Example 1-1, debug condition is used to limit the output of the debug ppp negotiation command to that related to interface virtual-template 1. Note that only a portion of the output is shown.

Example 1-1. debug ppp authentication with debug condition (interface virtual-template 1)

					Skydance_LNS#debug condition interface virtual-template 1
Condition 1 set
Skydance_LNS#
Skydance_LNS#debug ppp negotiation
PPP protocol negotiation debugging is on
Skydance_LNS#
*Mar  1 00:27:33.478 UTC: Vi1 Debug: Condition 1, interface Vt1 triggered, count 1
*Mar  1 00:27:33.482 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to
  up
*Mar  1 00:27:33.482 UTC: Vi1 PPP: Using vpn set call direction
*Mar  1 00:27:33.482 UTC: Vi1 PPP: Treating connection as a callin
*Mar  1 00:27:33.482 UTC: Vi1 PPP: Phase is ESTABLISHING, Passive Open 
  [0 sess, 0 load]
*Mar  1 00:27:33.486 UTC: Vi1 LCP: State is Listen
*Mar  1 00:27:33.486 UTC: Vi1 LCP: I FORCED CONFREQ len 11
*Mar  1 00:27:33.486 UTC: Vi1 LCP:    AuthProto CHAP (0x0305C22305)
*Mar  1 00:27:33.486 UTC: Vi1 LCP:    MagicNumber 0x066CA0F0 (0x0506066CA0F0)
*Mar  1 00:27:33.486 UTC: Vi1 LCP: I FORCED CONFACK len 6
*Mar  1 00:27:33.490 UTC: Vi1 LCP:    MagicNumber 0x508E6BD0 (0x0506508E6BD0)
*Mar  1 00:27:33.490 UTC: Vi1 PPP: Phase is AUTHENTICATING, by this end 
  [0 sess, 0 load]

In the first highlighted line, debugging messages for interface virtual template 1 are enabled using the debug condition interface virtual-template 1 command. This also disables output for any other interfaces. In the second highlighted line, the debug ppp negotiation command is used to enable debugging of PPP negotiation events. Finally, in the third highlighted line, PPP debugging messages are triggered on interface virtual template 1 (from which interface virtual access 1 is cloned, in this example). PPP debugging messages are then displayed.

More than one debug (crypto) condition command can be enabled at one time, but do not enable too many conditions as this can impact router performance. In this case, debug output must fulfill just one of the conditions to be displayed. Use the show debug condition or show crypto debug-condition commands as appropriate to verify current debugging conditions, as shown in Example 1-2.

Example 1-2. Output of the show debug condition Command

London_PE#show debug condition
					Condition 1: vcid 123 (2 flags triggered)
    Flags: 123 123
London_PE#

As you can see, the condition AToM VC ID 123 has been configured. This condition has been met twice. To remove a condition, simply use the no debug (crypto) condition command. With IPSec, you can disable all conditional settings using the debug crypto condition reset command, but make sure you turn off all IPSec debug commands first.

The output of a number of debug commands can also be filtered using an access list. A good example of this is the debug ip bgp update [access-list] command. This can be used to limit the output of the command to updates containing prefixes specified by the access list.