Table of Contents

Chapter Overview
Troubleshooting Dial-in Access

Understanding Call Flow in L2TP Dial-in Access to MPLS VPN
Understanding Call Flow in Direct ISDN PE Dial-in Access to MPLS VPN
Procedure for Troubleshooting Dial-in Access

Step 1. Is the PPP or MLP Link Established?
Step 2. If the Caller Is Not Seen in (1), Check the Remote Access Service
Step 3. If the PPP Link Is Established, Check Virtual-Access Settings
Step 4. If Virtual Access Settings Are OK, Check the Customer VRF
Step 5. Ping from the CE to the Remote PE and VHG/PE
Step 6. Check Tagging and BGP on the VHG/PE
Step 7. Recheck Tagging and BGP on the Remote PE
Step 8. Trace the Route from the Remote PE.
Step 9. Check MLP on the VHG/PE
Step 10. Turn Off CEF Switching on the Virtual Access Interface
Step 11. Troubleshoot L2TP Data Transfer
Step 12. Troubleshoot CEF Switching
Step 13. Troubleshoot MLP

Verifying Correct Configuration for L2TP Dial-in Access to MPLS to VPN

show Commands for NAS
show Commands for VHG/PE
show Commands for Overlapping Address Pool

Verifying Correct Configuration for Direct ISDN PE Dial-in Access to MPLS VPN

show Commands for NAS/PE
show Commands for Overlapping Address Pool

Troubleshooting Dial Backup

Understanding Dial Backup Call Flow
Procedure for Troubleshooting Call Flow in Dial Backup

Initiating Backup Connection, Switching Call to Backup Link
Terminating Backup Connection, Switching Call to Primary Link

Troubleshooting Dial-out Access

Troubleshooting L2TP Dial-out Access

Part 1: Before the Call Has Been Brought Up
Part 2. After the Call Is Brought Up
Debugging Commands for L2TP Dial-out

Troubleshooting Direct ISDN PE Dial-out

Part 1: Before the Call Has Been Brought Up
Part 2. After the Call Is Brought Up
Debugging Commands for Direct ISDN PE Dial-out

Troubleshooting Specific Features

Verifying and Troubleshooting Multilink PPP (on the VHG/PE or NAS/PE)
Verifying and Troubleshooting Multichassis Multilink PPP (MMP)
Verifying and Troubleshooting On-demand Address Pools
Troubleshooting the Framed-Route VRF Aware Feature

Troubleshooting Dial Access to MPLS VPN Integration

Chapter Overview

This chapter is organized in the following sections:

• Troubleshooting dial-in methods of access to Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN):
  
  
• Troubleshooting Dial-in Access
  
  
• Troubleshooting Dial Backup
  
  
• Troubleshooting Dial-out Access
  
  
• Troubleshooting L2TP Dial-out Access
  
  
• Troubleshooting Direct ISDN PE Dial-out
  
  
• Troubleshooting features that may be used with dial access:
  
  
• Verifying and Troubleshooting Multilink PPP (on the VHG/PE or NAS/PE)
  
  
• Verifying and Troubleshooting Multichassis Multilink PPP (MMP)
  
  
• Verifying and Troubleshooting On-demand Address Pools
  
  
• Troubleshooting the Framed-Route VRF Aware Feature
  
  

---

Note   In the context of L2TP (tunneled) dial methods, the NAS functions as a LAC (L2TP Access Concentrator) and the VHG/PE (virtual home gateway/provider edge router) functions as an LNS (L2TP Network Server). In the call flow diagrams and descriptions, however, we show this simply as "NAS" and "VHG/PE" for consistency with the other methods. "LAC" and "LNS" may appear in debugging output.

---

Troubleshooting Dial-in Access

This section describes the call flow for each of the two methods of dial-in access, L2TP and direct ISDN PE, and then presents troubleshooting steps that are applicable, with some variations, to both methods. Procedures for verifying correct configuration are given for each method separately.

Dial-in access may include these features:

• Multilink PPP (MLP)—PPP that is split across multiple data links.
  
  
• Multichassis MLP (MMP)—MLP with redundant "stacked" NAS/PEs, using a stack group bidding process (SGBP) to manage the allocation of PPP sessions among the members of the stack.
  
  
• Address management through overlapping local pools configured on the NAS/PE or overlapping address pools on the SP AAA server, through a DHCP (dynamic host configuration protocol) server, or through on-demand address pools (ODAP).
  
  

Understanding Call Flow in L2TP Dial-in Access to MPLS VPN

Figure 2-1 shows an example of the topology for L2TP dial-in access. In this example, MLP is enabled, so that the remote user establishes PPP sessions over two links. Figure 2-2 shows the steps in the corresponding call flow.

Table 2-1 describes the major dial-in steps shown in Figure 2-2.

Note   The call flow assumes that the VPN's VRF (routing table and other information associated with a specific VPN) has already been instantiated on the VHG/PE.

Understanding Call Flow in Direct ISDN PE Dial-in Access to MPLS VPN

Direct ISDN PE dial-in access to MPLS VPN is characterized by a NAS functioning as both NAS and PE. In contrast to L2TP dial-in access, the PPP session is placed directly into the appropriate VRF for the MPLS VPN, rather than being forwarded into a network concentrator by a tunneling protocol. Direct dial-in is implemented only with pure ISDN calls, not analog POTS calls.

Figure 2-3 shows an example of the topology for direct dial-in access to MPLS VPN. In this example, MLP is enabled, so that the remote user establishes PPP sessions over two links. Figure 2-4 shows the steps in the corresponding call flow.

Call Flow for Direct Dial-in Access to MPLS VPN

---

Note   The call flow assumes that the VPN's VRF (routing table and other information associated with a specific VPN) has already been instantiated on the NAS/PE.

---

Table 2-2: Troubleshooting Direct Dial-in Call Flow Events

Step in Call Flow
1. The remote user initiates a PPP connection to the NAS/PE using ISDN. If MLP is enabled, the session is identified as potentially being part of an MLP bundle.
2. The NAS/PE accepts the connection and a PPP or MLP link is established.
3. The NAS/PE partially authenticates the user with CHAP or PAP. The domain name or DNIS is used to determine whether the user is a VPN client.
4. The SP AAA server associates the remote user with a specific VPN and returns the corresponding VRF name to the NAS/PE, along with an IP address pool name.
5 through 8. The NAS/PE completes the authentication, associates the remote user with a specific customer MPLS VPN, and obtains an IP address.
The remote user is now part of the customer VPN. Packets can flow from/to the remote user.
If MLP is enabled, the remote user initiates a second PPP link of the MLP bundle. The above steps are repeated, except that an IP address is not obtained; the existing IP address is used. The remote user can use both PPP sessions, with packets fragmented across the links and defragmented on the NAS/PE.

Procedure for Troubleshooting Dial-in Access

This section provides a procedure for methodically troubleshooting dial-in remote access problems using a flowchart if/then approach. The steps are summarized in the three related flowcharts below, proceeding from the initial steps in Figure 2-5 to Phase 2 (Figure 2-6) or Phase 3 (Figure 2-7). Details of each numbered step in the flowchart are presented following the figures.

Note   If you are troubleshooting direct ISDN PE dial-in, omit steps involving VPDN and L2TP. Steps described for the VHG/PE should be done on the NAS/PE.

Note   The following troubleshooting process can be used to resolve common dial-in scenarios in this solution. Exhaustive troubleshooting of all possible combinations of features is beyond the scope of this document.

Step 1. Is the PPP or MLP Link Established?

On the VHG/PE, use the show caller command (Example 2-1) to check the highlighted information. For more detail, use the show user command for the user you are interested in (Example 2-2). Use the debug ppp negotiation command to check PPP negotiation on either the NAS or the VHG/PE (Example 2-3), depending on where you believe the problem to exist.

For direct ISDN PE dial-in access, use the following ISDN-related commands:

• If the CE appears to be dialing out but is receiving no answer, the NAS/PE may not be connected properly to ISDN. Use the following show commands:
  
  
• show run—Use to check that the dialer configuration is correct. If so, check the ISDN connection with show isdn status below.
  
  
• show isdn status—Use to verify that ISDN is working and there is a connection.
  
  
• If ISDN is working correctly, use debug dialer to see if packets are triggering the dialer interface.
  
  
• If ISDN is not working correctly, use debug isdn q931 to isolates ISDN information (Layer 2 debugging). Use this only when you have determined that there is an ISDN switch problem. Determine whether it is the CE or user (dial-in) or NAS/PE (dial-out) that is not succeeding in dialing, and run the debug on the device that is having the problem.
  
  
• If the CE cannot dial out or does not have a correct connection to ISDN, check the CE device.
  
  

Analyzing the Results

IPCP must be negotiated, and the remote end should have an IP address. Both ends must agree on a negotiated IP address. debug ppp negotiation should show ACK's received and sent for both IP addresses.

Step 2. If the Caller Is Not Seen in (1), Check the Remote Access Service

Use the following debug commands to check common remote access problems, such as VPDN issues, PPP issues, AAA authentication and authorization, RADIUS issues and virtual profile issues:

• debug vpdn events—Displays errors and events associated with establishing or terminating L2TP tunnels for VPDNs. Example 2-4 shows sample output.
  
  
• debug vpdn l2x-events—Displays errors associated with L2X protocol events.
  
  
• debug ppp negotiation—Enables debugging of the PPP protocol negotiation process.
  
  
• debug ppp authentication—Enables debugging of errors encountered during remote authentication.
  
  
• debug aaa authentication—Displays the methods of authentication that are being used and what results these methods produce.
  
  
• debug aaa authorization—Displays the methods of authorization that are being used and what results these methods produce.
  
  

Example 2-5 provides a sample of the debug command output that results if the NAS queries a AAA server for tunnel details.

• debug aaa per-user—Displays information about the per-user configuration downloaded from the AAA server.
  
  
• debug vtemplate—Displays cloning information for a virtual access interface from the time it is cloned from a virtual template to the time it comes down.
  
  
• debug ip peer—Displays address activity and contains additional output when pool groups are defined.
  
  
• debug radius—Displays information associated with the Remote Authentication Dial-in User Server, or RADIUS.
  
  

Example 2-6 provides a sample of the debug command output that results when you implement these commands.

For details on troubleshooting L2TP (VPDN) issues, refer to "VPDN Configuration and Troubleshooting", http://www-tac.cisco.com/Support_Library/Internetworking/VPDN/vpdn_config.0.html .

For details on troubleshooting PPP negotiation, refer to "Dialup Technology: Troubleshooting Techniques", http://www.cisco.com/warp/public/112/chapter17.htm .

For details on troubleshooting RADIUS AAA, refer to "Diagnosing and Troubleshooting AAA Operations", http://www.cisco.com/univercd/cc/td/doc/cisintwk/intsolns/secsols/aaasols/c262c6.htm .

Step 3. If the PPP Link Is Established, Check Virtual-Access Settings

Before checking the virtual-access settings, verify that the session is established. On the VHG/PE, use the show vpdn session and show caller ip commands. An IP address should appear in the show caller ip results.

If the PPP link is established, check the virtual access interface settings to make sure that the configuration is correct and CEF switching is set up properly. On the virtual access interface:

• Check the configuration. On the VHG/PE, use the show interfaces virtual-access # configuration command to check the configuration on the virtual access interface, as shown in Example 2-7.
  
  
• Use the show cef interface command to check CEF switching capabilities for the virtual access interface, as shown in Example 2-1.
  
  
• If CEF switching is not enabled, check that CEF adjacencies are enabled for the virtual-access interface, as in Example 2-1.
  
  

---

Note   For MLP, check the virtual-access interface point to the MLP bundle.

---

Step 4. If Virtual Access Settings Are OK, Check the Customer VRF

From the show interfaces virtual-access 2 configuration command used in Step 3, you can identify the VRF into which the dial-in session was placed. The commands below give additional information on the route distinguisher for the VRF.

If the customer is placed into the correct VRF, go on to Step 5.

If the customer is not placed into the correct VRF, there is probably a VRF problem. If the VRF name for this customer is mistyped in the AAA lcp:interface-config command, one of two things may happen:

If the error matches an existing VRF configuration on the VHG/PE, the user is placed in the wrong routing table.

If not, a parsing error appears in the virtual template and the session is terminated.

For more information on troubleshooting VRF, refer to "How To Troubleshoot the MPLS VPN", http://www.cisco.com/warp/public/105/mpls_vpn_tsh.html .

c72d2-3# show ip vrf V1.7.com

c72d2-3# show ip vrf interfaces V1.7.com

Step 5. Ping from the CE to the Remote PE and VHG/PE

If the customer is placed in the correct VRF, check the following:

• Ping from the CE to the remote PE. If the ping succeeds, go on to Step 6. If the ping is unsuccessful, go on to the next bullet point.
  
  
• Ping from the CE to the VHG/PE. If the ping succeeds, go on to the next bullet point. If the ping is unsuccessful, go on to
  
  
• Ping from the VHG/PE to the remote PE. If the ping is successful, there may be an L2TP data problem. Refer to "VPDN Configuration and Troubleshooting", http://www-tac.cisco.com/Support_Library/Internetworking/VPDN/vpdn_config.0.html . If the ping is unsuccessful, go on to Step 6.
  
  
• If the ping is not successful, the problem may require assistance from TAC. Before contacting TAC, attempt to gather information to define the problem, such as:
  
  
• Small ping packets
  
  
• Large packets
  
  
• A problem with UDP or TCP packets
  
  
• Ping from the CE to the remote PE. If the ping to the remote PE is not successful, go on to Step 6 (Figure 3).
  
  

Step 6. Check Tagging and BGP on the VHG/PE

When IPCP is negotiated, a host route is placed in the VRF for the dial-in user. This host route creates an FIB entry in the VRF and the VHG/PE assigns it a tag to use when a remote PE forwards traffic to it.

Troubleshoot to determine:

• Is the host route present in the routing table? What is the tag for the host route? Is the route redistributed into BGP and forwarded via the MP-BGP capabilities on the VHG/PE? (Example 2-12).
  
  
• (6a) What is the tag value for the VRF route? You can check this with the show ip cef command (Example 2-13).
  
  
• If CEF is not enabled on the virtual-access interface, collect the tag value for the VRF route tag command (Example 2-14)?
  
  
• (6b) Is the host route present in the BGP VRF table and to what BGP peers (remote PEs) is it sent? (Example 2-15)?
  
  
• (6c) Is the BGP peer to remote PE up and are multiprotocol BGP capabilities for this peer enabled (Example 2-16 and Example 2-17)?
  
  

If tagging and BGP are not OK on the VHG/PE, go on to Step 7. If they are OK, go on to Step 8.

Step 7. Recheck Tagging and BGP on the Remote PE

If the ping is not received on the remote PE, there is probably a problem in the MPLS core. Refer to "How To Troubleshoot the MPLS VPN", http://www.cisco.com/warp/public/105/mpls_vpn_tsh.html .

If the ping is received on the remote PE, proceed with the following troubleshooting.

• (7a) Use the show ip route and show ip bgp commands on the remote PE to determine if the host route was learned via BGP and is present in the routing table on the remote PE (Example 1and 2). If not, there is probably a problem with BGP or routing. Refer to "Troubleshooting BGP", http://www.cisco.com/warp/public/459/bgp_trouble_main.html .
  
  
• (7b) Use the show ip cef command to check that tagging is OK on the remote PE (Example 3). If not, there is probably an MPLS tag-switching problem. Refer to "How To Troubleshoot the MPLS VPN", http://www.cisco.com/warp/public/105/mpls_vpn_tsh.html or "IP Routing Top Issues", http://www.cisco.com/warp/public/105/top_issues/iprouting/top_issues_rp.shtml .
  
  

If MPLS tag-switching and BGP are OK on the remote PE, go on to Step 8.

Note   You do not need to recheck BGP peering commands.

Analyzing the Results

In Example 2-20, note that the second tag is 27, the tag value advertised by the VHG/PE to its BGP peers. If the remote PEs have traffic for VRF V1.7.com IP 10.1.7.20, they should use a tag header with the first tag to reach the VHG/PE and the second to indicate to the VHG/PE which VRF this packet belongs to and to what outgoing interface it should be sent.

Step 8. Trace the Route from the Remote PE.

If MPLS tag-switching and BGP are OK on the remote PE, use the traceroute command to check the route to the VHG/PE or the CE.

Analyzing the Results

The traceroute output should show label 27 with either two tags or one tag.

• If there are two tags, then the P router has been traversed but the penultimate hop of the P router immediately before the VHG/PE is not being reached. There may be a problem in the MPLS core. Refer to "How To Troubleshoot the MPLS VPN", http://www.cisco.com/warp/public/105/mpls_vpn_tsh.html .
  
  
• If there is one tag, then the penultimate hop is being reached.
  
  
• If there are the correct number of tags, there may be a problem in the transition of packets from the MPLS core to the VPDN tunnel. Go to Step 9 (Figure 3).
  
  

---

Note   The traceroute command can also be used from the VHG/PE to check if the MPLS tag switching path from VHG/PE to remote PE is OK.

---

c26d12-1# traceroute vrf V1.7.com 10.1.7.20

Type escape sequence to abort.

Tracing the route to 10.1.7.20

1 10.10.103.113 [MPLS: Labels 57/27 Exp 0] 60 msec 52 msec 52 msec

2 10.10.103.134 [MPLS: Labels 107/27 Exp 0] 48 msec 52 msec 52 msec

3 10.10.103.130 [MPLS: Labels 18/27 Exp 0] 52 msec 49 msec 76 msec

4 10.1.7.242 [MPLS: Label 27 Exp 0] 4 msec 0 msec 4 msec

5 10.1.7.20 24 msec * 208 msec

Step 9. Check MLP on the VHG/PE

If there are no problems in the MPLS core and MPLS tag-switching path is OK, but the VHG/PE is not passing the tag-switched traffic to the NAS/PE via L2TP, do the following:

• Identify if this is an MLP user, then do one of the following:
  
  
• If this is not an MLP user, there may be a problem with L2TP data transfer or CEF switching. Go on to Step 10 to rule out CEF switching issues.
  
  
• If this is an MLP user, check to see if the the expected number of links (bundles) are being created. If so, check to see if send/receive packets are increasing correctly. If not, go on to Step 10 to rule out CEF switching problems.
  
  
• If send/receive packets are increasing, go on to Step 10 to rule out CEF switching problems. If packets are not increasing, also go on to Step 10.
  
  

---

Note   The following procedure can also be used to troubleshoot unsuccessful pings from the remote PE to the VHG/PE.

---

c72d2-3# show ppp multilink

Virtual-Access13, bundle name is U0002N2P4V1.7@V1.7.com

Bundle up for 00:26:04

Using relaxed lost fragment detection algorithm.

15 lost fragments, 21 reordered, 0 unassigned

9 discarded, 2 lost received, 1/255 load

0x17E88 received sequence, 0x17E58 sent sequence

Member links: 1 (max not set, min not set)

lac-lb-V1.7:Virtual-Access2 (10.10.145.5), since 00:26:04, last rcvd seq 017E86, unsequenced

Step 10. Turn Off CEF Switching on the Virtual Access Interface

This step is purely a temporary troubleshooting strategy, not a solution. If you suspect a CEF switching problem, turn off CEF switching to see if the call gets through without it. If so, the problem is in CEF switching. Go on to Step 12.

If this does not solve the problem, the next step depends on what you were investigating before turning off CEF switching. Do one of the following:

• If this is not an MLP user, there is probably a problem with L2TP data transfer. Go on to Step 11.
  
  
• If this is an MLP user but there was not a problem in adding a second link to the bundle, there is probably a problem with L2TP data transfer. Go on to Step 11.
  
  

---

Note   CEF switching can harmlessly be turned off for troubleshooting purposes. It is not required for placing a route in the VRF or creating an MPLS tag value for the host route. When CEF switching is turned off, traffic destined for the dial-in VPN client simply takes a different switching path (fast switching or process switching) on the VHG/PE.

---

To turn off CEF switching on the virtual-access interface, enter this configuration command on the virtual-template:

no ip route-cache cef

Step 11. Troubleshoot L2TP Data Transfer

(Not applicable to direct ISDN PE dial-in access) If you have narrowed the problem down to an L2TP data transfer issue, use the following command to collect relevant debugging information:

debug vpdn

To check L2TP data transfer on the NAS, use the command debug vpdn l2x-data.

Refer to "VPDN Configuration and Troubleshooting", http://www-tac.cisco.com/Support_Library/Internetworking/VPDN/vpdn_config.0.html , or contact TAC.

Step 12. Troubleshoot CEF Switching

If you have narrowed the problem down to a CEF switching issue, use the following command to collect relevant debugging information:

debug ip cef drops

Refer to "How to Verify CEF Switching", http://www.cisco.com/warp/public/105/cef_whichpath.html .

Step 13. Troubleshoot MLP

If you have narrowed the problem down to an MLP issue, use the following command to collect relevant debugging information:

debug ppp multilink

See the "Verifying and Troubleshooting Multilink PPP (on the VHG/PE or NAS/PE)" section. Also refer to "Configuring and Troubleshooting Multilink PPP", http://www.cisco.com/warp/public/471/top_issues/access/793_multilink.html or contact TAC.

Verifying Correct Configuration for L2TP Dial-in Access to MPLS to VPN

This section provides the following examples of how you can show information for the events outlined in Figure 2-1:

• show Commands for NAS
  
  
• show Commands for VHG/PE
  
  
• show Commands for Overlapping Address Pool
  
  

For information on verifying MLP configuration, see "Verifying and Troubleshooting Multilink PPP (on the VHG/PE or NAS/PE)".

The L2TP information provided here applies only to dial access to MPLS VPN integration. For more information about the configuration and troubleshooting tasks associated with L2TP, please refer to Configuring Virtual Private Networks (for IOS 12.2) at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fdial_c/fnsprt8/dafvpn.htm

show Commands for NAS

To verify the details of L2TP tunnel setup and session on the NAS, use the following show commands in user EXEC mode:

• show vpdn—Displays information about active Level 2 Forwarding (L2F) protocol tunnel and message identifiers in a Virtual Private Dialup Network.
  
  
• show vpdn tunnel—Displays VPN tunnel information including tunnel protocol, ID, local and remote tunnel names, packets sent and received, tunnel, and transport status (summary-style format).
  
  
• show vpdn tunnel all—Displays VPN tunnel information including tunnel protocol, ID, local and remote tunnel names, packets sent and received, tunnel, and transport status.
  
  
• show vpdn session—Displays VPN session information including interface, tunnel, username, packets, status, and window statistics.
  
  
• show user—Displays information about the active lines on the router per a specific user.
  
  
• show caller—Displays individual users and consumed resources on the NAS, and active call statistics for large pools of connections, and the absolute and idle times for each user.
  
  
• show caller user caller name—Displays the show caller command information for a particular user.
  
  
• show vpdn history failure—Displays the content of the failure history table for the user.
  
  
• show resource-pool call—(RPMS-specific) Displays all active call information for all customer profiles and resource groups.
  
  
• show resource-pool resource—(RPMS-specific) Displays resource groups configured in the network access server.
  
  

Example 2-23 shows the detailed output that results when you implement these show commands.

show Commands for VHG/PE

To verify the details of the L2TP tunnel setup, PPP sessions, virtual access interface configurations, and local address pool assignment on the VHG/PE, use the following show commands in user EXEC mode:

• show vpdn—Displays information about active Level 2 Forwarding (L2F) protocol tunnel and message identifiers in a Virtual Private Dialup Network.
  
  
• show vpdn tunnel—Displays VPN tunnel information including tunnel protocol, ID, local and remote tunnel names, packets sent and received, tunnel, and transport status (summary-style format).
  
  
• show vpdn tunnel all—Displays VPN tunnel information including tunnel protocol, ID, local and remote tunnel names, packets sent and received, tunnel, and transport status.
  
  
• show vpdn session—Displays VPN session information including interface, tunnel, username, packets, status, and window statistics.
  
  
• show user—Displays information about the active lines on the router per a specific user.
  
  
• show caller—Displays individual users and consumed resources on the NAS, active call statistics for large pools of connections, and the absolute and idle times for each user.
  
  
• show caller user caller name—Displays the "show caller" information for a particular user.
  
  
• show interface virtual-access—Displays detailed information about the virtual access interface.
  
  
• show virtual access configuration—Displays detailed information about the virtual access interface configuration.
  
  
• show ip route—Displays the current state of the routing table, including the IP address, the network mask, protocol, and static routes.
  
  
• show ip local pool—Displays the address pools that have been downloaded to a Cisco network access server.
  
  

Example 2-24 shows the detailed output that results from these show commands:

show Commands for Overlapping Address Pool

The overlapping address pool feature allows the administrator to configure overlapping IP address pool groups in order to concurrently use the IP addresses in multiple address spaces.

• Assign pools in different groups to a single address space.
  
  
• Use with applications that cannot handle duplicate address assignments in their routing table.
  
  
• Use on all DSL and Dial platforms that support the current IP local address pools.
  
  
• On the Dial platforms, PPP over ISDN sessions will try to use overlapping IP address pools with MPLS VPN configuration.
  
  

To verify that an IP address is active, use the show local pool command in user EXEC mode. The output shown in Example 2-25 tells you which IP address has been received, and that the call is active and in use.

Verifying Correct Configuration for Direct ISDN PE Dial-in Access to MPLS VPN

This section provides the following examples of how you can show information for the events outlined in Figure 2-1:

• show Commands for NAS/PE
  
  
• show Commands for Overlapping Address Pool
  
  

The information provided here applies only to dial-in access to MPLS VPN integration. For more information about the configuration and troubleshooting tasks associated with direct dial-in, please refer to Configuring Virtual Private Networks at the following URL: http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/dialns_c/dnsprt3/
dcdvpn.htm

show Commands for NAS/PE

• show user—Displays information about the active lines on the router per a specific user.
  
  
• show caller—Displays individual users and consumed resources on the NAS, and active call statistics for large pools of connections, and the absolute and idle times for each user.
  
  
• show caller user caller name—Displays the show caller command information for a particular user.
  
  
• show resource-pool call—(RPMS-specific) Displays all active call information for all customer profiles and resource groups.
  
  
• show resource-pool resource—(RPMS-specific) Displays resource groups configured in the network access server.
  
  
• show interface virtual-access—Displays detailed information about the virtual access interface.
  
  
• show virtual access configuration—Displays detailed information about the virtual access interface configuration.
  
  
• show ip route—Displays the current state of the routing table, including the IP address, the network mask, protocol, and static routes.
  
  
• show ip local pool—Displays the address pools that have been downloaded to a Cisco network access server.
  
  

Example 2-26 shows the detailed output that results when you implement these show commands.

show Commands for Overlapping Address Pool

The overlapping address pool feature allows the administrator to configure overlapping IP address pool groups in order to concurrently use the IP addresses in multiple address spaces.

• Assign pools in different groups to a single address space.
  
  
• Use with applications that cannot handle duplicate address assignments in their routing table.
  
  
• Use on all DSL and Dial platforms that support the current IP local address pools.
  
  
• On the Dial platforms, PPP over ISDN sessions will try to use overlapping IP address pools with MPLS VPN configuration.
  
  

To verify that an IP address is active, use the show local pool command in user EXEC mode. The output shown in Example 2-27 tells you which IP address has been received, and that the call is active and in use.

Troubleshooting Dial Backup

Dial backup is used as a backup for direct remote connections such as cable or DSL. Using L2TP dial-in, it provides backup connectivity from the customer's remote office to the customer's VPN when their primary link becomes unavailable.

The primary link and the backup link are typically configured on the same CE router at the remote site.

Understanding Dial Backup Call Flow

Call flow in dial backup is identical to that in L2TP dial-in access, except that the call is initiated by a backup interface, when connectivity to the primary interface is lost, instead of by a remote user. The backup interface is a dialer interface configured to dial into the service provider's NAS on a dial backup phone number. (The phone number indicates that dial backup is being initiated instead of a typical L2TP dial-in.)

Using L2TP, the NAS tunnels the PPP session to the VHG/PE, which then maps the incoming session into the appropriate VRF.

When the primary link is restored, the primary route will also be restored, the backup connection terminated by the remote user, and the backup route deleted by the VHG/PE.

This is depicted in Figure 2-8.

Table 2-3 describes the major dial backup events.

Procedure for Troubleshooting Call Flow in Dial Backup

Dial backup problems can occur either in the first step in the call flow, when the primary link goes down and the dial backup link is to be dialed, or in the last step, when the primary link comes back up and the backup link is to be deactivated. This section describes procedures for troubleshooting these steps, followed by an example of the output of the commands used.

Initiating Backup Connection, Switching Call to Backup Link

Is the backup link dialed when the primary link goes down?

• Check that when the primary link goes down, the interface on which the backup interface command is configured goes down as well. For example, if the primary interface is interface Serial 0, then the line protocol for that interface must go down for the backup interface to be brought out of standby. Since the backup interface method relies on the interface it is configured on to be in a down state before the backup interface actually comes up, verify that a primary link failure is actually reflected in the state of the interface. You can determine the state of the interface using the command show interface interface slot/port. To determine the dial backup interface, use the command show backup.
  
  
• Check to see if the router generated a console message indicating that the backup interface changed out of standby mode. This message will only appear after the enable-timer, specified by the backup delay enable-timer disable-timer command, has expired. If you do not see this console message, adjust the backup delay enable timer to a lower value. An example of a 10 second delay timer is shown here:
  
  

• Verify the routing table contains a valid route to the backup interface to be dialed. Use the show ip route command to verify that the route exists in the routing table after the primary link goes down. The floating static route will only be installed in the routing table after all other identical routes, with lower administrative distance are removed. Check to make sure that there are no other sources for the primary route (possibly due to a routing loop).
  
  
• Check that the interesting traffic definition is correctly defined (using the dialer-list command) and is applied to the interface (using the dialer-group command) providing the backup. Generate interesting traffic, then use the command debug dialer packet to verify the traffic is designated interesting and can bring up the link.
  
  

---

Note   The routing protocol should not be defined as interesting. This prevents the periodic updates or hellos from keeping the backup link up indefinitely. The following is an example of a good interesting traffic definition for this backup method:

---

Terminating Backup Connection, Switching Call to Primary Link

Is the backup link deactivated when the primary link recovers?

• Check that when the primary link recovers, the interface (on which the backup interface command is configured) comes up as well. This is necessary since the router will not recognize that the primary link is up until the line protocol of that interface is up. For example, if the primary interface is interface Serial 0, then the line protocol for that interface must come up for the backup interface to change into standby. You can determine the state of the interface using the command show interface interface slot/port. To determine the dial backup interface, use the command show backup.
  
  
• Verify that the disable timer is set appropriately. The disable timer is specified with the command backup delay enable-timer disable-timer. For example, the command backup delay 10 60 indicates that the backup link will be enabled 10 seconds after the primary link goes down, and that the backup link will be brought down 60 seconds after the primary link recovers. If your backup link stays up longer than desired, adjust the disable time downwards.
  
  
• Use show ip route to verify that the routing protocol reinstalls the primary route. This should cause the floating static route to be removed from the routing table. All traffic should now use the primary link. If the primary route is not reinstalled, troubleshoot the routing protocol.
  
  
• Use debug dialer to verify that there is no interesting traffic that passes on the backup link. Since interesting traffic resets the idle timeout, the link will not be brought down if there is unwanted interesting traffic. Watch for certain broadcast and multicast packets that can reset the idle time-out. If necessary, modify the interesting traffic definition to be more restrictive and designate such rogue packets as not interesting.
  
  
• Lower the dialer idle-timeout (default is 120 seconds). Because the backup link is only brought down when the idle time-out expires, a lower idle timeout can bring down the backup link.
  
  

Troubleshooting Dial-out Access

In dial-out remote access, instead of a remote user or CE initiating a call into the MPLS VPN, the connection is established by traffic coming from the MPLS VPN and triggering a call from the dial-out router to the remote CE. Dial-out access can use either L2TP or direct ISDN architecture.

Dial-out is often used for automated functions. For example, a central database system might dial out nightly to remote vending machines to collect daily sales data and check inventories.

In this release of Cisco Remote Access to MPLS VPN integration, the dialer interface used is a dialer profile. With a dialer profile, each physical interface becomes a member of a dialer pool. The VHG/PE (in L2TP dial-out) or the NAS/PE (in direct dial-out) triggers a call when it receives interesting traffic from a remote peer in the customer VPN. ("Interesting traffic" is traffic identified as destined for this particular dial-out network.)

Based on the dialer interface configuration, the VHG/PE or NAS/PE borrows a physical interface from the dialer pool for the duration of the call. Once the call is complete, the router returns the physical interface to the dialer pool. Because of this dynamic binding, different dialer interfaces can be configured for different customer VPNs, each with its own VRF, IP address, and dialer string.

Unlike dial-in remote access, dial-out access does not require the querying of an AAA server or the use of two-way authentication, because user information is directly implemented on the dialer profile interface configured on the dial-out router.

Dial-out access may include these features:

• Multilink PPP (MLP)—PPP that is split across multiple data links.
  
  
• Multichassis MLP (MMP)—MLP with redundant "stacked" NAS/PEs, using a stack group bidding process (SGBP) to manage the allocation of PPP sessions among the members of the stack.
  
  
• Address management through overlapping local pools configured on the NAS/PE or overlapping address pools on the SP AAA server, through a DHCP (dynamic host configuration protocol) server, or through on-demand address pools (ODAP).
  
  

Figure 2-9 shows an example of the topology for L2TP dial-out access, and Figure 2-10 shows an example of the topology for direct ISDN PE dial-out access.

Troubleshooting L2TP Dial-out Access

The following troubleshooting process can be used to resolve common dial-out scenarios in this solution. Exhaustive troubleshooting of all possible combinations of features is beyond the scope of this document.

Part 1: Before the Call Has Been Brought Up

Follow these steps to troubleshoot call flow before the call has been brought up.

Step 1. Is the VHG/PE Receiving Traffic?

Step 2. Is VRF FIB Information Forwarded in the MPLS Core?

Step 3. Is CEF Switching Configured to Trigger the Call?

In Step 2 above, the outgoing interface in the show mpls command on the VHG/PE was not yet filled in. When a packet comes in from the remote PE with a tag header 82 - the tag for selecting the outgoing interface - the VHG/PE does not yet know what interface to use.

On the VHG/PE, the incoming packet will be processed by the CEF switching path. In this step, check that CEF switching entries have been defined to trigger the call. In the example, the CEF switching path for 10.1.17.10 (the CE) shows that the IP CEF switching path has a valid CEF entry to reach that address and Dialer50.

This entry makes it possible to trigger the call because the tag 82 in the VRF FIB table shows it is linked to a route for 10.1.17.10, which is in the VRF FIB as an aggregate.

With an aggregate route, CEF lookup is not done via the CEF fast switching path and information in the adjacency table, but is handled by the IP CEF process switching routine. Packets are handed off to the dialer routing code.

---

Note   Because the call is not yet established, the CEF entry is still incomplete. The tag rewrite is empty and there is no reference to the adjacency for the outgoing interface. When the call is established, this information will be completed.

---

Example 2-34: Checking CEF Switching router# sh ip cef vrf V1.17.com 10.1.17.10 10.1.17.10/32, version 9, epoch 0, attached 0 packets, 0 bytes tag information set local tag: 82 via Dialer50, 0 dependencies valid punt adjacency tag rewrite with , , tags imposed: {} (***see note below) c72d2-2# sh ip cef vrf V1.17.com dialer 50 Prefix Next Hop Interface 10.1.17.10/32 attached Dialer50

Part 2. After the Call Is Brought Up

Step 1. Is the Call Triggered and a PPP Connection Established?

With CEF switching properly configured on the VHG/PE, if a packet comes in on the ingress MPLS interface with a tag header containing, in this example, tag value 82, the VHG/PE looks at the IP CEF switching path in the VRF and determined that it must go on dialer 50.

At this point the IP packet is punted [is there a better word?] to the dialer code. The dialer routine triggers the call and brings up the PPP connection to the remote CE. As soon the connection is up, the MPLS and CEF switching procedures will adjust to the new changes.

On the VHG/PE, is the route connected?

In this example, the route is connected (the route metric is changed from static to connected):

Example 2-35: Checking Route Connection router# sh ip route vrf V1.17.com connected 10.0.0.0/32 is subnetted, 6 subnets 10.1.17.10 is directly connected, Dialer50

On the VHG/PE, is the show mpls information updated?

In this example, the show mpls information is updated for tag 82. Note that the tag relationship has changed from aggregate to untagged, and the outgoing interface uses vi2:

Example 2-36: Checking MPLS Update router# sh mpls forwarding-table vrf V1.17.com 10.1.17.10 Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 82 Untagged 10.1.17.10/32[V] 722072 Vi2 point2point

Is the CEF switching path updated?

With the change from aggregate to untagged in the show mpls information above, CEF lookup is no longer done via the IP CEF process switching path.

With an outgoing interface (vi2) stipulated, the CEF lookup process will now look for adjacencies for this outgoing interface. CEF fast switching is in place, as shown in the following example:

Example 2-37: Checking CEF Switching Path Update router# sh adj virtual-acc 2 Protocol Interface Address TAG Virtual-Access2 point2point(4) (incomplete) IP Virtual-Access2 point2point(33) router# sh adj virtual-acc 2 detail Protocol Interface Address TAG Virtual-Access2 point2point(4) (incomplete) 0 packets, 0 bytes mpls adj never Epoch: 0 IP Virtual-Access2 point2point(33) 8098 packets, 842192 bytes FF030021 Epoch: 0

The CEF lookup path is changed in order to process the packets faster. Packets are now processed by checking the adjacency entries.

---

Note   Although the TAG path shows incomplete, this is normal since the tag header of the incoming MPLS packet should not be forwarded over the PPP link. Since the TAG path is incomplete, it will now look at the IP adjacency when forwarding the IP header and data received from the MPLS cloud and append the header "FF030021" in front of it.

---

Debugging Commands for L2TP Dial-out

For general dial-out troubleshooting, the following debug commands may be used. Debug commands are issued in enable mode. Debug output examples are shown in Table 2-4.

Command	Use To
debug dialer	Show information on the dialer profile.
deb ip cef dialer	Show the change in the CEF switching path, as discussed in Part 2 above.
deb mpls pac	Show information on the mpls packet. Caution   In a production environment, this command can produce much more output than the packet you are interested in.

Debugging after changes in the CEF switching path: The following output is seen only if the call comes up. If the call does not come up, troubleshooting is the same as for a non-MPLS call.

Troubleshooting Direct ISDN PE Dial-out

The following troubleshooting process can be used to troubleshoot common dial-out scenarios in this solution, which uses direct ISDN PE dial-out with dialer profiles. Exhaustive troubleshooting of all possible combinations of features is beyond the scope of this document.

Part 1: Before the Call Has Been Brought Up

Step 1. Is the NAS/PE Receiving Traffic?

Is the NAS/PE receiving traffic for the remote CE?

Check to see if a static route is configured on the NAS/PE.

In the following example, the static route has been created for Dialer50:

Is the route being forwarded to remote PEs?

If the static route has been created, you can check for more route-specific detail, including whether the route is being forwarded via MP-BGP to other remote PEs:

On the remote PE, is the route reflected in the routing table?

If you determine that the route was forwarded, check the remote PE to make sure the static route is reflected in the routing table for this VRF. In the example below, the remote PE is aware that traffic for 10.1.17.10 (the remote CE IP address) should be forwarded to the VHG/PE 10.10.104.12:

On the remote PE, enter the show ip route vrf vpn command, as in this example:

Step 2. Is VRF FIB Information Forwarded in the MPLS Core?

To properly forward traffic to the NAS/PE, the remote PE must know not only the remote CE's IP address but also which outgoing interface the NAS/PE should use for this CE.

If the route is properly reflected in the remote PE's routing table, check the NAS/PE configuration for the correct MPLS path. Specifically, make sure that the MPLS forwarding table includes the tag that the remote CE must use when forwarding traffic to the remote CE via this NAS/PE:

On the NAS/PE, is the MPLS path configured correctly?

Note that at this point, the outgoing interface information is missing. The CEF switching path is not fully complete until the call is brought up.

On the remote PE, are the necessary tags appearing?

Check that the CEF entry for the remote CE (10.1.17.10) includes the two required tags, one to reach the NAS/PE (its IP address, 10.10.104.12) and another for the remote CE IP address (10.1.17.10) entry in the V1.17.com VRF table:

In this example, 78 is the tag to reach 10.10.104.12, the NAS/PE. 82 is the tag for selecting the correct outgoing interface on the VHG/PE.

If the tags do not appear on the remote PE, there is a problem in the MPLS VPN core. Troubleshooting MPLS VPN is beyond the scope of this document. For more information, see the MPLS VPN Troubleshooting Guide.

Step 3. Is CEF Switching Configured to Trigger the Call?

In Step 2 above, the outgoing interface in the show mpls command on the NAS/PE was not yet filled in. When a packet comes in from the remote PE with a tag header 82 - the tag for selecting the outgoing interface - the NAS/PE does not yet know what interface to use.

On the NAS/PE, the incoming packet will be processed by the CEF switching path. In this step, check that CEF switching entries have been defined to trigger the call. In the example, the CEF switching path for 10.1.17.10 (the CE) shows that the IP CEF switching path has a valid CEF entry to reach that address and Dialer50.

This entry makes it possible to trigger the call because the tag 82 in the VRF FIB table shows it is linked to a route for 10.1.17.10, which is in the VRF FIB as an aggregate.

With an aggregate route, CEF lookup is not done via the CEF fast switching path and information in the adjacency table, but is handled by the IP CEF process switching routine. Packets are handed off to the dialer routine code.

Note   Because the call is not yet established, the CEF entry is still incomplete - tag rewrite is empty and there is no reference to the adjacency for the outgoing interface. When the call is established, this information will be completed.

Part 2. After the Call Is Brought Up

Is the Call Triggered and a PPP Connection Established?

With CEF switching properly configured on the NAS/PE, if a packet comes in on the ingress MPLS interface with a tag header containing tag value 82, the NAS/PE looks at the IP CEF switching path in the VRF and determined that it must go via dialer 50.

At this point the IP packet gets punted to the dialer code, and the dialer routine triggers the call and brings up the PPP connection to the remote CE. As soon the connection is up, the MPLS and CEF switching procedures will adjust to the new changes.

On the NAS/PE, is the route connected?

In this example, the route is connected (the route metric is changed from static to connected):

On the NAS/PE, is the show mpls information updated?

In this example, the show mpls information is updated for tag 82. Note that the tag relationship has changed from aggregate to untagged, and the outgoing interface uses vi2:

Is the CEF switching path updated?

With the change from aggregate to untagged in the show mpls information above, CEF lookup is no longer done via the IP CEF process switching path.

With an outgoing interface (vi2) stipulated, the CEF lookup process will now look for adjacencies for this outgoing interface. CEF fast switching is in place, as shown in the following example:

The CEF lookup path is changed in order to process the packets faster. Packets are now processed by checking the adjacency entries.

Note   Although the TAG path shows incomplete, this is normal since the tag header of the incoming MPLS packet should not be forwarded over the PPP link. Since the TAG path is incomplete, it will now look at the IP adjacency when forwarding the IP header and data received from the MPLS cloud and append the header "FF030021" in front of it.

Debugging Commands for Direct ISDN PE Dial-out

For general dial-out troubleshooting, the following debug commands may be used. Debug commands are issued in enable mode. Debug output examples are shown in Table 2-5.

Command	Use to
debug dialer	Show information on the dialer profile.
deb ip cef dialer	Show the change in the CEF switching path, as discussed in Part 2 above.
deb mpls pac	Show information on the mpls packet. Caution   In a production environment, this command can produce much more output than the packet you are interested in.

Troubleshooting Specific Features

The features described here may be used with various dial access methods. This section describes how to troubleshoot the feature itself. For information on troubleshooting the main call flow for the specific access method, see the access method sections.

This section includes:

Verifying and Troubleshooting Multilink PPP (on the VHG/PE or NAS/PE)

Verifying and Troubleshooting Multichassis Multilink PPP (MMP)

Verifying and Troubleshooting On-demand Address Pools

Troubleshooting the Framed-Route VRF Aware Feature

Verifying and Troubleshooting Multilink PPP (on the VHG/PE or NAS/PE)

Multilink PPP (MLP) is designed to exploit additional bandwidth that may be available between two network devices by bundling together two PPP links, with the same IP address assigned to both. From the user's point of view, this appears to be a single link, but because packets can be transferred on both links, it can operate more efficiently. The multilink bundle is always associated with a virtual access interface.

On the VHG/PE (in L2TP dial-in access) or the NAS/PE (in direct dial-in access), use the show ppp multilink command in user EXEC mode to verify the following:

• There are no lost or discarded fragments.
  
  
• Multilink bundle settings contain the correct settings received from the virtual template and from the service provider AAA server.
  
  
• The bundle displays the correct number of member links (2,4 or 6 member links). In Example 2-52, the bundle displays two links.
  
  
• The multilink bundle should be placed in the correct VRF via the VRF settings received from the AAA server
  
  

For more on troubleshooting MLP, refer to "Configuring and Troubleshooting Multilink PPP", http://www.cisco.com/warp/public/471/top_issues/access/793_multilink.html.

Verifying and Troubleshooting Multichassis Multilink PPP (MMP)

Multichassis Multilink PPP (MMP) provides the capability for MLP links to terminate at multiple "stacked" network access servers. The network access servers are configured as members of a "stack group" and, to the caller, appear as a single PE server.

With MMP, an organization can provide a single dialup telephone number for a large dialup pool. MMP enhances a network's scalability; an organization can add new routers to their dialup pool to expand capacity.

MMP is accomplished through the use of SGBP (Stack Group Bidding Protocol), which assigns ownership of a call to a master NAS in the stack group through a process of bidding. A call flow follows this general sequence, shown in Figure 2-11:

1. MLP Call 1 is made by user X. NAS A answers the call.

2. NAS A informs its stack group peer network access servers that it has accepted a call from user X on CE router X.

3. All members of the stack group bid for the ownership of the call ("bundle mastership").

4. In this example, SGBP bidding was configured to have the network access server that receives the first call "win". NAS A, therefore, becomes the bundle master for the MLP session and receives the call. As bundle master, NAS A owns all connections with user X.

5. When user X needs more bandwidth, a second MLP call (Call 2) is made to the stack group. In this example, NAS C accepts the call, and informs its stack group peers of the call.

6. As in Step 3, the stack group members bid for ownership of this call.

7. NAS A wins the bidding, because it already has an MLP session from user X. NAS C forwards the raw PPP data to NAS A (tunneling via L2F), which reassembles and resequences the packets.

8. Final authentication is done on the bundle master, NAS A.

9. The reassembled data is passed on to the MPLS VPN as if it had all come through one physical link

L2F performs standard PPP operations up to authentication,

If a problem occurs in multichassis multilink PPP, use the show and debug commands shown in Table 2-6.

For more on troubleshooting MMP, refer to "Multichassis MP, Part 2", http://www.cisco.com/warp/public/131/6.html .

Example 2-53 shows the command output on stack group member router D where user X has its bundle interface as Virtual-Access4. Two member interfaces are joined to this bundle interface:

• The first is a local PRI channel
  
  
• The second is a projected interface from stack group member NAS B.
  
  

In Example 2-54, the stack group member NASA cannot detect the remote stack group member router D.

In Example 2-55, authentication fails because the new group member (NASA) does not have a password.

The debug sgbp queries command displays SGBP bundle mastership queries. In Example 2-56, router D becomes the master for a bundle from user X.

In Example 2-57, debug sgbp error is used to detect whether the configured access server address is different from the hello address.

In the first debug sgbp error, issued from RouterD, the first line shows that the SGBP hello received from NASB does not match the IP address configured (with sgbp member) on the local system. To correct the problem, check the configuration of NASB or the configuration of the stack group on the local NAS.

The second line shows that NASK is not a local stack group member.

In the second debug sgbp error, issued from NASC, the group member name and the host name are mismatched because of a difference in case: the CHAP challenge is sent with the host name "routerd", the server is actually configured as "RouterD".

Verifying and Troubleshooting On-demand Address Pools

In on-demand address pools (ODAP), a central SP RADIUS server manages a block of addresses for each customer. Each pool is divided into subnets of various sizes, and the server assigns subnets to the VHG/PE or NAS/PE on request.

The VHG/PE or NAS/PE acts as a DHCP server. On the VHG/PE or NAS/PE, one on-demand pool is configured for each customer VPN supported by that router. Upon configuration, the VHG/PE or NAS/PE's pool manager requests an initial subnet from the server.

Address management is on demand because address pool subnets are allocated or released based on a threshold. If use exceeds a defined ceiling threshold, the pool manager requests an additional subnet from the server and adds it to the on-demand pool. If use falls below a floor threshold, the pool manager attempts to free one, or more then one, of the on-demand pool's subnets to return it to the server. The VRF routing table on the VHG/PE or NAS/PE is updated with the subnet route whenever a range of addresses is requested from the AR.

If a problem occurs in ODAP, use the commands shown in Table 2-7 on the VHG/PE or NAS/PE. Example 2-58 shows the results of show up dhcp pool and Example 2-59 shows the results of debug ip dhcp server events.

Troubleshooting the Framed-Route VRF Aware Feature

On the VHG/PE, verify that the subnet sent to the CPE is in the appropriate VRF routing table:

show ip route vrf <vrf name>

If the subnet is not in the correct VRF routing table, troubleshoot the RADIUS exchange between the VHG/PE and the RADIUS AR server, checking to make sure the AV pair containing the subnet is being exchanged. Use the following commands:

debug aaa authorization

debug aaa authentication

debug aaa per-user

debug radius

debug ip routing vrf vrf name to which PPP session belongs

When you disconnect, you will see the static route being removed:

Posted: Sun Sep 29 17:42:05 PDT 2002
All contents are Copyright © 1992--2002 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.