cc/td/doc/product/vpn/solution/rampls2
hometocprevnextglossaryfeedbacksearchhelp
PDF

Table of Contents

Troubleshooting Dial Access to MPLS VPN Integration

Troubleshooting Dial Access to MPLS VPN Integration

Chapter Overview

This chapter is organized in the following sections:

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:

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.


Figure 2-1: Topology of L2TP Dial-in Access to MPLS VPN



Figure 2-2:
Call Flow of L2TP Dial-in Access to MPLS VPN




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.


Table 2-1: Troubleshooting Call Flow Events

Step in Call Flow

1. The remote user initiates a PPP connection to the NAS1 using either analog POTS2 or ISDN.

If MLP is enabled, the session is identified as potentially being part of an MLP bundle.

2. The NAS accepts the connection and a PPP or MLP link is established.

3. The NAS partially authenticates the user with CHAP3 or PAP4 and obtains tunnel information. The domain name or DNIS is used to determine whether the user is a VPN client.

4. The NAS initiates a tunnel to the VHG/PE5 (if an L2TP tunnel does not exist as a result of existing traffic).

5-10(a). The PPP session is created and the connection is extended to terminate on the VHG/PE. The NAS propagates available PPP information.

5-10(b). The VHG/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 to and from the remote user.

If MLP is enabled, the remote user initiates a second PPP (PPP 2 in Figure 2-1) link of the MLP bundle. 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. Packets are fragmented across links and defragmented on the VHG/PE, with both MLP bundles put into the same VRF6.

1Network access server
2Plain old telephone service
3Challenge Handshake Authentication Protocol
4Password Authentication Protocol
5Virtual home gateway provider edge router
6VPN routing/forwarding instance, the routing information for a specific customer VPN site.

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.


Figure 2-3: Topology of Direct Dial-in Access to MPLS VPN



Figure 2-4:
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.


Figure 2-5: Troubleshooting Dial-in Access, Phase 1



Figure 2-6:
Troubleshooting Dial-in Access, Phase 2



Figure 2-7:
Troubleshooting Dial-in, Phase 3


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:

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.


Example 2-1: show caller Output

c72d2-3# show caller

Active Idle

Line User Service Time Time

Vi2 U0001N2P4V1.7@V1.7.com PPP L2TP 00:00:02 00:00:03


Example 2-2:
show user Output

c72d2-3# show user U0001N2P4V1.7@V1.7.com

User: U0001N2P4V1.7@V1.7.com, line Vi2, service PPP L2TP

PPP: LCP Open, multilink Closed, CHAP (<- none), IPCP

IP: Local 10.1.7.242, remote 10.1.7.20

VPDN: NAS lac-lb-V1.7, MID 20, MID Unknown

HGW c72d2-3, NAS CLID 0, HGW CLID 0, tunnel open

Counts: 14 packets input, 594 bytes, 0 no buffer

0 input errors, 0 CRC, 0 frame, 0 overrun

22 packets output, 806 bytes, 0 underruns

0 output errors, 0 collisions, 0 interface resets


Example 2-3:
Sample debug Command Output for Accepting Connection (PPP Connection) [LAC Only] 5300mid# show debug PPP: PPP authentication debugging is on PPP protocol negotiation debugging is on 5300mid# *Apr 2 12:13:05.413 UTC: As31 LCP: I CONFREQ [Closed] id 10 len 20 *Apr 2 12:13:05.417 UTC: As31 LCP: ACCM 0x000A0000 (0x0206000A0000) *Apr 2 12:13:05.417 UTC: As31 LCP: MagicNumber 0x23C67BCA (0x050623C67BCA) *Apr 2 12:13:05.417 UTC: As31 LCP: PFC (0x0702) *Apr 2 12:13:05.417 UTC: As31 LCP: ACFC (0x0802) *Apr 2 12:13:05.417 UTC: As31 LCP: Lower layer not up, Fast Starting *Apr 2 12:13:05.417 UTC: As31 PPP: Treating connection as a dedicated line *Apr 2 12:13:05.417 UTC: As31 PPP: Phase is ESTABLISHING, Active Open [0sess, 0 load] *Apr 2 12:13:05.417 UTC: As31 LCP: O CONFREQ [Closed] id 1 len 25 *Apr 2 12:13:05.417 UTC: As31 LCP: ACCM 0x000A0000 (0x0206000A0000) *Apr 2 12:13:05.417 UTC: As31 LCP: AuthProto CHAP (0x0305C22305) *Apr 2 12:13:05.417 UTC: As31 LCP: MagicNumber 0xF3697B63 (0x0506F3697B63) *Apr 2 12:13:05.417 UTC: As31 LCP: PFC (0x0702) *Apr 2 12:13:05.417 UTC: As31 LCP: ACFC (0x0802) *Apr 2 12:13:05.417 UTC: As31 LCP: O CONFACK [REQsent] id 10 len 20 *Apr 2 12:13:05.417 UTC: As31 LCP: ACCM 0x000A0000 (0x0206000A0000) *Apr 2 12:13:05.417 UTC: As31 LCP: MagicNumber 0x23C67BCA (0x050623C67BCA) *Apr 2 12:13:05.417 UTC: As31 LCP: PFC (0x0702) *Apr 2 12:13:05.417 UTC: As31 LCP: ACFC (0x0802) *Apr 2 12:13:05.421 UTC: %LINK-3-UPDOWN: Interface Async31, changed state to up *Apr 2 12:13:05.557 UTC: As31 LCP: I CONFACK [ACKsent] id 1 len 25 *Apr 2 12:13:05.561 UTC: As31 LCP: ACCM 0x000A0000 (0x0206000A0000) *Apr 2 12:13:05.561 UTC: As31 LCP: AuthProto CHAP (0x0305C22305) *Apr 2 12:13:05.561 UTC: As31 LCP: MagicNumber 0xF3697B63 (0x0506F3697B63) *Apr 2 12:13:05.561 UTC: As31 LCP: PFC (0x0702) *Apr 2 12:13:05.561 UTC: As31 LCP: ACFC (0x0802) *Apr 2 12:13:05.561 UTC: As31 LCP: State is Open *Apr 2 12:13:05.561 UTC: As31 PPP: Phase is AUTHENTICATING, by this end [0sess, 0 load] *Apr 2 12:13:05.561 UTC: As31 CHAP: O CHALLENGE id 1 len 28 from "5300mid" *Apr 2 12:13:05.701 UTC: As31 CHAP: I RESPONSE id 1 len 39 from "anchan@gcoe.com" *Apr 2 12:13:05.705 UTC: As31 PPP: Phase is FORWARDING [0 sess, 0 load]

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:

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

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 .


Example 2-4: Sample debug Command Output for Establishing L2TP Tunnel

[LAC Only]

5300mid# debug vpdn events

VPDN events debugging is on

5300mid# debug vpdn 12x-event ^

*Apr 2 13:58:52.137 UTC: %LINK-3-UPDOWN: Interface Async41, changed state to up

*Apr 2 13:58:52.469 UTC: As41 VPDN: Got DNIS string 5551111

*Apr 2 13:58:52.473 UTC: As41 VPDN: Looking for tunnel -- gcoe.com --

*Apr 2 13:58:52.481 UTC: As41 VPDN/RPMS/: Got tunnel info for gcoe.com

*Apr 2 13:58:52.481 UTC: As41 VPDN/RPMS/: LAC gcoe

*Apr 2 13:58:52.481 UTC: As41 VPDN/RPMS/: l2tp-busy-disconnect yes

*Apr 2 13:58:52.485 UTC: As41 VPDN/RPMS/: l2tp-tunnel-password xxxxxx

*Apr 2 13:58:52.485 UTC: As41 VPDN/RPMS/: IP 10.1.3.1

*Apr 2 13:58:52.485 UTC: As41 VPDN/: curlvl 1 Address 0: 10.1.3.1, priority 1

*Apr 2 13:58:52.485 UTC: As41 VPDN/: Select non-active address 10.1.3.1, priority 1

*Apr 2 13:58:52.485 UTC: Tnl 35054 L2TP: SM State idle

*Apr 2 13:58:52.485 UTC: Tnl 35054 L2TP: O SCCRQ

*Apr 2 13:58:52.485 UTC: Tnl 35054 L2TP: Tunnel state change from idle to wait-ctl-reply

*Apr 2 13:58:52.485 UTC: Tnl 35054 L2TP: SM State wait-ctl-reply

*Apr 2 13:58:52.485 UTC: As41 VPDN: Find LNS process created

*Apr 2 13:58:52.485 UTC: As41 VPDN: Forward to address 10.1.3.1

*Apr 2 13:58:52.485 UTC: As41 VPDN: Pending

*Apr 2 13:58:52.485 UTC: As41 VPDN: Process created

*Apr 2 13:58:52.489 UTC: Tnl 35054 L2TP: I SCCRP from gcoe.com

*Apr 2 13:58:52.489 UTC: Tnl 35054 L2TP: Got a challenge from remote peer, gcoe.com

*Apr 2 13:58:52.489 UTC: Tnl 35054 L2TP: Got a response from remote peer, gcoe.com

*Apr 2 13:58:52.489 UTC: Tnl 35054 L2TP: Tunnel Authentication success

*Apr 2 13:58:52.489 UTC: Tnl 35054 L2TP: Tunnel state change from wait-ctl-reply to established

*Apr 2 13:58:52.489 UTC: Tnl 35054 L2TP: O SCCCN to gcoe.com tnlid 46672

*Apr 2 13:58:52.489 UTC: Tnl 35054 L2TP: SM State established

*Apr 2 13:58:52.489 UTC: As41 VPDN: Forwarding...

*Apr 2 13:58:52.489 UTC: As41 VPDN: Bind interface direction=1

*Apr 2 13:58:52.489 UTC: Tnl/Cl 35054/32 L2TP: Session FS enabled

*Apr 2 13:58:52.489 UTC: Tnl/Cl 35054/32 L2TP: Session state change from idle to wait-for-tunnel

*Apr 2 13:58:52.489 UTC: As41 Tnl/Cl 35054/32 L2TP: Create session

*Apr 2 13:58:52.489 UTC: Tnl 35054 L2TP: SM State established

*Apr 2 13:58:52.489 UTC: As41 Tnl/Cl 35054/32 L2TP: O ICRQ to gcoe.com 46672/0

*Apr 2 13:58:52.493 UTC: As41 Tnl/Cl 35054/32 L2TP: Session state change from wait-for-tunnel to wait-reply

*Apr 2 13:58:52.493 UTC: As41 VPDN: anchan@gcoe.com is forwarded

*Apr 2 13:58:52.493 UTC: As41 Tnl/Cl 35054/32 L2TP: O ICCN to gcoe.com 46672/45

*Apr 2 13:58:52.493 UTC: As41 Tnl/Cl 35054/32 L2TP: Session state change from wait-reply to established

*Apr 2 13:58:53.493 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async41, changed state to up

[LNS Only]

72vhg2# show debug

VPN:

L2X protocol events debugging is on

VPDN events debugging is on

72vhg2#

3d22h: L2TP: I SCCRQ from gcoe tnl 35054

3d22h: Tnl 46672 L2TP: Got a challenge in SCCRQ, gcoe

3d22h: Tnl 46672 L2TP: New tunnel created for remote gcoe, address 10.1.2.183d22h: Tnl 6672 L2TP: O SCCRP to gcoe tnlid 35054

3d22h: Tnl 46672 L2TP: Tunnel state change from idle to wait-ctl-reply

3d22h: Tnl 46672 L2TP: I SCCCN from gcoe tnl 35054

3d22h: Tnl 46672 L2TP: Got a Challenge Response in SCCCN from gcoe

3d22h: Tnl 46672 L2TP: Tunnel Authentication success

3d22h: Tnl 46672 L2TP: Tunnel state change from wait-ctl-reply to established

3d22h: Tnl 46672 L2TP: SM State established

3d22h: Tnl 46672 L2TP: I ICRQ from gcoe tnl 35054

3d22h: Tnl/Cl 46672/45 L2TP: Session FS enabled

3d22h: Tnl/Cl 46672/45 L2TP: Session state change from idle to wait-connect

3d22h: Tnl/Cl 46672/45 L2TP: New session created

3d22h: Tnl/Cl 46672/45 L2TP: O ICRP to gcoe 35054/32

3d22h: Tnl/Cl 46672/45 L2TP: I ICCN from gcoe tnl 35054, cl 32

3d22h: Tnl/Cl 46672/45 L2TP: Session state change from wait-connect to established

3d22h: Vi3 VPDN: Virtual interface created for anchan@gcoe.com

3d22h: Vi3 VPDN: Set to Async interface

3d22h: Vi3 VPDN: Clone from Vtemplate 25 filterPPP=0 blocking

3d22h: %LINK-3-UPDOWN: Interface Virtual-Access3, changed state to up

3d22h: Vi3 VPDN: Bind interface direction=2

3d22h: Vi3 VPDN: PPP LCP accepted rcv CONFACK

3d22h: Vi3 VPDN: PPP LCP accepted sent CONFACK

3d22h: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access3, changed state to up

72vhg2#


Example 2-5:
Sample debug Command Output for Authenticating and Obtaining Tunnel Information [LAC Only] 5300mid# show debug General OS: AAA Authentication debugging is on AAA Authorization debugging is on Radius protocol debugging is on 5300mid# *Apr 2 13:25:20.705 UTC: As33 AAA/AUTHOR/FSM: (0): LCP succeeds trivially *Apr 2 13:25:20.705 UTC: AAA/ACCT/DS0: channel=0, ds1=0, t3=0, slot=0, ds0=0 *Apr 2 13:25:20.709 UTC: %LINK-3-UPDOWN: Interface Async33, changed state to up *Apr 2 13:25:20.881 UTC: AAA/ACCT/DS0: channel=0, ds1=0, t3=0, slot=0, ds0=0 *Apr 2 13:25:21.041 UTC: AAA: parse name=Async33 idb type=10 tty=33 *Apr 2 13:25:21.041 UTC: AAA: name=Async33 flags=0x11 type=4 shelf=0 slot=0 adapter=0 port=33 channel=0 *Apr 2 13:25:21.041 UTC: AAA: parse name=Serial0:0 idb type=12 tty=-1 *Apr 2 13:25:21.041 UTC: AAA: name=Serial0:0 flags=0x51 type=1 shelf=0 slot=0 adapter=0 port=0 channel=0 *Apr 2 13:25:21.041 UTC: AAA/ACCT/DS0: channel=0, ds1=0, t3=0, slot=0, ds0=0 *Apr 2 13:25:21.041 UTC: AAA/MEMORY: create_user (0x620DF6C8) user='gcoe.com' ruser='' port='Async33' rem_addr='async/5551111' authen_type=NONE service=LOGIN priv=0 *Apr 2 13:25:21.041 UTC: Async33 AAA/AUTHOR/VPDN (1549343951): Port='Async33' list='default' service=NET *Apr 2 13:25:21.041 UTC: AAA/AUTHOR/VPDN: Async33 (1549343951) user='gcoe.com' *Apr 2 13:25:21.041 UTC: Async33 AAA/AUTHOR/VPDN (1549343951): send AV service=ppp *Apr 2 13:25:21.041 UTC: Async33 AAA/AUTHOR/VPDN (1549343951): send AV protocol=vpdn *Apr 2 13:25:21.041 UTC: Async33 AAA/AUTHOR/VPDN (1549343951): found list "default" *Apr 2 13:25:21.041 UTC: Async33 AAA/AUTHOR/VPDN (1549343951): Method=radius (radius) *Apr 2 13:25:21.045 UTC: RADIUS: authenticating to get author data *Apr 2 13:25:21.045 UTC: RADIUS: ustruct sharecount=2 *Apr 2 13:25:21.045 UTC: RADIUS: Initial Transmit Async33 id 24172.29.51.235:1645, Access-Request, len 84 *Apr 2 13:25:21.045 UTC: Attribute 4 6 81010105 *Apr 2 13:25:21.045 UTC: Attribute 5 6 00000021 *Apr 2 13:25:21.045 UTC: Attribute 61 6 00000000 *Apr 2 13:25:21.045 UTC: Attribute 1 13 6A756E69 *Apr 2 13:25:21.045 UTC: Attribute 30 9 35353531 *Apr 2 13:25:21.045 UTC: Attribute 2 18 2F3B1919 *Apr 2 13:25:21.045 UTC: Attribute 6 6 00000005 *Apr 2 13:25:21.053 UTC: RADIUS: Received from id 24 172.29.51.235:1645, Access-Accept, len 160 *Apr 2 13:25:21.053 UTC: Attribute 6 6 00000005 *Apr 2 13:25:21.053 UTC: Attribute 26 30 0000000901187670 *Apr 2 13:25:21.053 UTC: Attribute 26 29 0000000901177670 *Apr 2 13:25:21.053 UTC: Attribute 26 35 00000009011D7670 *Apr 2 13:25:21.053 UTC: Attribute 26 40 0000000901227670 *Apr 2 13:25:21.053 UTC: RADIUS: saved authorization data for user 620DF6C8 at 62136E50 *Apr 2 13:25:21.053 UTC: RADIUS: cisco AVPair "vpdn:tunnel-id=gcoe" *Apr 2 13:25:21.057 UTC: RADIUS: cisco AVPair "vpdn:tunnel-type=l2tp" *Apr 2 13:25:21.057 UTC: RADIUS: cisco AVPair "vpdn:ip-addresses=10.1.3.1" *Apr 2 13:25:21.057 UTC: RADIUS: cisco AVPair "vpdn:l2tp-tunnel-password=bodega" *Apr 2 13:25:21.057 UTC: AAA/AUTHOR (1549343951): Post authorization status = PASS_ADD*Apr 2 13:25:21.057 UTC: AAA/AUTHOR/VPDN: Processing AV service=ppp *Apr 2 13:25:21.057 UTC: AAA/AUTHOR/VPDN: Processing AV protocol=vpdn *Apr 2 13:25:21.057 UTC: AAA/AUTHOR/VPDN: Processing AV tunnel-id=gcoe *Apr 2 13:25:21.057 UTC: AAA/AUTHOR/VPDN: Processing AV tunnel-type=l2tp *Apr 2 13:25:21.057 UTC: AAA/AUTHOR/VPDN: Processing AV ip-addresses=10.1.3.1 *Apr 2 13:25:21.057 UTC: AAA/AUTHOR/VPDN: Processing AV l2tp-tunnel-password=bodega *Apr 2 13:25:21.057 UTC: AAA/MEMORY: free_user (0x620DF6C8) user='gcoe.com' ruser='' port='Async33' rem_addr='async/5551111' authen_type=NONE service=LOGIN priv=0 *Apr 2 13:25:21.061 UTC: AAA: parse name=Async33 idb type=10 tty=33 *Apr 2 13:25:21.061 UTC: AAA: name=Async33 flags=0x11 type=4 shelf=0 slot=0 adapter=0 port=33 channel=0 *Apr 2 13:25:21.061 UTC: AAA: parse name=Serial0:0 idb type=12 tty=-1 *Apr 2 13:25:21.061 UTC: AAA: name=Serial0:0 flags=0x51 type=1 shelf=0 slot=0 adapter=0 port=0 channel=0 *Apr 2 13:25:21.061 UTC: AAA/ACCT/DS0: channel=0, ds1=0, t3=0, slot=0, ds0=0 *Apr 2 13:25:21.061 UTC: AAA/MEMORY: create_user (0x620DF6C8) user='anchan@gcoe.com' ruser='' port='Async33' rem_addr='async/5551111' authen_type=CHAP service=PPP priv=1 *Apr 2 13:25:22.061 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async33, changed state to up


Example 2-6:
Sample debug Command Output for Completing PPP Authentication 00:02:18: Vt25 VTEMPLATE: Unable to create and clone vaccess 00:02:18: VTEMPLATE: No unused vaccess, create new vaccess 00:02:18: Vi1 VTEMPLATE: Set default settings with no ip address, encap ppp 00:02:18: Vi1 VTEMPLATE: Hardware address 0003.e412.f800 00:02:18: Vi1 VTEMPLATE: Has a new cloneblk vtemplate, now it has vtemplate 00:02:18: Vi1 VTEMPLATE: ************* CLONE VACCESS1 ***************** 00:02:18: Vi1 VTEMPLATE: Clone from Virtual-Template25 interface Virtual-Access1 default ip address no ip address encap ppp no ip address ip mroute-cache ppp authentication chap end 00:02:18: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up 00:02:18: RADIUS: ustruct sharecount=1 00:02:18: RADIUS: Initial Transmit Virtual-Access1 id 0 172.29.51.235:1645, Access-Request, len 98 00:02:18: Attribute 4 6 8101010E 00:02:18: Attribute 5 6 00000001 00:02:18: Attribute 61 6 00000005 00:02:18: Attribute 1 20 616E6368 00:02:18: Attribute 30 9 35353531 00:02:18: Attribute 3 19 01001183 00:02:18: Attribute 6 6 00000002 00:02:18: Attribute 7 6 00000001 00:02:18: RADIUS: Received from id 0 172.29.51.235:1645, Access-Accept, len 221 00:02:18: Attribute 6 6 00000002 00:02:18: Attribute 7 6 00000001 00:02:18: Attribute 26 58 0000000901346C63 00:02:18: Attribute 26 58 0000000901346C63 00:02:18: Attribute 26 73 0000000901436C63 00:02:18: RADIUS: cisco AVPair "lcp:interface-config#1 = ip vrf forwarding gcoe" 00:02:18: RADIUS: cisco AVPair "lcp:interface-config#2 = ip unnumbered Loopback200" 00:02:18: RADIUS: cisco AVPair "lcp:interface-config#3 = peer default ip address pool gcoe.com" 00:02:18: Vi1 VTEMPLATE: Has a new cloneblk AAA, now it has vtemplate/AAA 00:02:18: Vi1 VTEMPLATE: ************* CLONE VACCESS1 ***************** 00:02:18: Vi1 VTEMPLATE: Clone from AAA interface Virtual-Access1 ip vrf forwarding gcoe ip unnumbered Loopback200 peer default ip address pool gcoe.com end 00:02:18: RADIUS: cisco AVPair "lcp:interface-config#1 = ip vrf forwarding gcoe" not applied for ip 00:02:18: RADIUS: cisco AVPair "lcp:interface-config#2 = ip unnumbered Loopback200" not applied for ip 00:02:18: RADIUS: cisco AVPair "lcp:interface-config#3 = peer default ip address pool gcoe.com" not applied for ip 00:02:19: Vi1: Pools to search : gcoe.com 00:02:19: Vi1: Pool gcoe.com returned address = 10.40.1.1 00:02:19: RADIUS: cisco AVPair "lcp:interface-config#1 = ip vrf forwarding gcoe" not applied for ip 00:02:19: RADIUS: cisco AVPair "lcp:interface-config#2 = ip unnumbered Loopback200" not applied for ip 00:02:19: RADIUS: cisco AVPair "lcp:interface-config#3 = peer default ip address pool gcoe.com" not applied for ip 00:02:19: Vi1 AAA/AUTHOR/PER-USER: Event IP_UP 00:02:19: Vi1 AAA/AUTHOR: IP_UP 00:02:19: Vi1 AAA/PER-USER: processing author params. 00:02:19: Vi1 IPCP: Install route to 10.40.1.1 00:02:19: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up

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:


Example 2-7: show interfaces virtual-access configuration Output c72d2-3# show interfaces virtual-access 2 configuration Virtual-Access2 is an L2TP link interface interface Virtual-Access2 configuration... ip vrf forwarding V1.7.com ip unnumbered Loopback7
Example 2-8: show cef interface Output

c72d2-3# show cef interface virtual-access 2

Virtual-Access2 is up (if_number 50) Corresponding hwidb fast_if_number 50 Corresponding hwidb firstsw->if_number 50 Internet address is 0.0.0.0/0 Unnumbered interface. Using address of Loopback7 (10.1.7.242) Interface is marked as point to point interface Hardware idb is Virtual-Access2 Fast switching type 7, interface type 21 IP CEF switching enabled IP Feature Fast switching turbo vector IP VPN Feature CEF switching turbo vector VPN Forwarding table "V1.7.com"

IP MTU 1464


Example 2-9: show adjacency Output

c72d2-3# show adjacency virtual-access 2

Protocol Interface Address

TAG Virtual-Access2 point2point(3) (incomplete) IP Virtual-Access2 point2point(6) c72d2-3# show adjacency virtual-access 2 detail Protocol Interface Address TAG Virtual-Access2 point2point(3) (incomplete) 0 packets, 0 bytes Epoch: 0 IP Virtual-Access2 point2point(6)

2025 packets, 283500 bytes

4500001C56C80000FF1157CC0A0A6823

0A0A910506A506A5000800000202099E

00280000FF030021

CEF expires: never

refresh: 00:00:44

Epoch: 0

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 .


Example 2-10: show ip vrf Output

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

Name Default RD Interfaces V1.7.com 1:7 Serial4/0 Virtual-Access2 Loopback7 Loopback107
Example 2-11: show ip vrf interfaces Output

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

Interface IP-Address VRF Protocol Virtual-Access1 10.1.7.242 V1.7.com up

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:

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:

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.


Example 2-12: show ip route Output

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

Routing entry for 10.1.7.20/32 Known via "connected", distance 0, metric 0 (connected, via interface) Redistributing via bgp 100 Advertised by bgp 100 metric 1 Routing Descriptor Blocks: * directly connected, via Virtual-Access2 Route metric is 0, traffic share count is 1


Example 2-13:
show ip cef Output

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

10.1.7.20/32, version 14, epoch 0, attached, connected, cached adjacency to Virtual-Access2 tag information set local tag: 27 via Virtual-Access2, 0 dependencies valid cached adjacency tag rewrite with Vi2, point2point, tags imposed: {}
Example 2-14:
show tag forwarding Output

c72d2-3# show tag forwarding vrf V1.7.com

Local Outgoing Prefix Bytes tag Outgoing Next Hop

tag tag or VC or Tunnel Id switched interface 27 Untagged 10.1.7.20/32[V] 812700 Vi2 point2point
Example 2-15:
show ip bgp Output

c72d2-3# show ip bgp vpnv4 vrf V1.7.com 10.1.7.20

BGP routing table entry for 1:7:10.1.7.20/32, version 291 Paths: (1 available, best #1) Advertised to non peer-group peers: 10.10.104.12 10.10.104.31 Local 0.0.0.0 from 0.0.0.0 (10.10.104.35) Origin incomplete, metric 1, localpref 100, weight 32768, valid, sourced, best Extended Community: RT:1:7
Example 2-16:
show ip bgp summary Output c72d2-3# show ip bgp summary BGP router identifier 10.10.104.35, local AS number 100 Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd 10.10.104.12 4 100 2971 2963 2 0 0 2d00h 0 10.10.104.31 4 100 3131 2963 2 0 0 2d00h 1
Example 2-17:
show ip bgp neighbor Output c72d2-3# show ip bgp neighbor 10.10.104.31 BGP neighbor is 10.10.104.31, remote AS 100, internal link BGP version 4, remote router ID 10.10.104.31 BGP state = Established, up for 2d00h Last read 00:00:55, hold time is 180, keepalive interval is 60 seconds Neighbor capabilities: Route refresh: advertised and received(old & new) Address family IPv4 Unicast: advertised and received Address family VPNv4 Unicast: advertised and received

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.

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.


Example 2-18: show adjacency Output, Remote PE c26d12-1# show ip route vrf V1.7.com 10.1.7.20 Routing entry for 10.1.7.20/32 Known via "bgp 100", distance 200, metric 1, type internal Last update from 10.10.104.35 00:00:30 ago Routing Descriptor Blocks: * 10.10.104.35 (Default-IP-Routing-Table), from 10.10.104.35, 00:00:30 ago


Example 2-19: show ip bgp Output, Remote PE c26d12-1# show ip bgp vpnv4 vrf V1.7.com 10.1.7.20 BGP routing table entry for 1:7:10.1.7.20/32, version 5103 Paths: (1 available, best #1) Flag: 0x410 Not advertised to any peer Local 10.10.104.35 (metric 14) from 10.10.104.35 (10.10.104.35) Origin incomplete, metric 1, localpref 100, valid, internal, best Extended Community: RT:1:7
Example 2-20: show ip cef Output, Remote PE c26d12-1# show ip cef vrf V1.7.com 10.1.7.20 10.1.7.20/32, version 204, cached adjacency 10.10.103.113 0 packets, 0 bytes tag information set local tag: VPN-route-head fast tag rewrite with Et0/1, 10.10.103.113, tags imposed: {57 27} via 10.10.104.35, 0 dependencies, recursive next hop 10.10.103.113, Ethernet0/1 via 10.10.104.35/32 valid cached adjacency tag rewrite with Et0/1, 10.10.103.113, tags imposed: {57 27}

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.


Example 2-21: show traceroute Output

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:


Example 2-22: show ppp multilink Output

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:

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:

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:

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


Example 2-23: Sample show Command Output for NAS c53c2-1# sh vpdn L2TP Tunnel and Session Information Total tunnels 1 sessions 1 LocID RemID Remote Name State Remote Address Port Sessions 29916 29227 c72c3-1 est 10.10.110.1 1701 1 LocID RemID TunID Intf Username State Last Chg Fastswitch 23 30 29916 Se0:30 U0001N3P1V1.2@V1.2.com est 00:00:10 enabled c53c2-1# sh vpdn tunnel L2TP Tunnel Information Total tunnels 1 sessions 1 LocID RemID Remote Name State Remote Address Port Sessions 29916 29227 c72c3-1 est 10.10.110.1 1701 1 c53c2-1# sh vpdn tunnel all L2TP Tunnel Information Total tunnels 1 sessions 1 Tunnel id 29916 is up, remote id is 29227, 1 active sessions Tunnel state is established, time since change 00:00:22 Remote tunnel name is c72c3-1 Internet Address 10.10.110.1, port 1701 Local tunnel name is c53c2-1-V1.2 Internet Address 10.10.110.3, port 1701 123 packets sent, 124 received 92982 bytes sent, 92662 received Control Ns 4, Nr 2 Local RWS 800 (default), Remote RWS 800 (max) Retransmission time 1, max 1 seconds Unsent queuesize 0, max 0 Resend queuesize 0, max 2 Total resends 0, ZLB ACKs sent 0 Current nosession queue check 0 of 5 Retransmit time distribution: 0 0 0 0 0 0 0 0 0 Sessions disconnected due to lack of resources 0 c53c2-1# sh vpdn session L2TP Session Information Total tunnels 1 sessions 1 LocID RemID TunID Intf Username State Last Chg Fastswitch 23 30 29916 Se0:30 U0001N3P1V1.2@V1.2.com est 00:00:32 enabled c53c2-1# sh caller Active Idle Line User Service Time Time con 0 - TTY 19:04:31 18:58:14 vty 0 - VTY 00:21:59 00:00:00 Se0:30 U0001N3P1V1.2@V1.2.com \ PPP 00:00:38 00:00:00 5300mid# sh user Line User Host(s) Idle Location * 0 con 0 idle 00:00:00 16 tty 16 anchan@jun Async interface - Interface User Mode Idle Peer Address c53c2-1# sh caller user U0001N3P1V1.2@V1.2.com User: U0001N3P1V1.2@V1.2.com, line Se0:30, service PPP Active time 00:00:48, Idle time 00:00:00 Timeouts: Absolute Idle Limits: - - Disconnect in: - - PPP: LCP Open, CHAP (<- none) Dialer: Connected, inbound Type is ISDN, group Se0:15 VPDN: NAS c53c2-1-V1.2, MID 23, MID Unknown HGW , NAS CLID 0, HGW CLID 0, tunnel open Counts: 888 packets input, 252631 bytes, 0 no buffer 0 input errors, 0 CRC, 0 frame, 0 overrun 810 packets output, 203706 bytes, 0 underruns 0 output errors, 0 collisions, 79 interface resets c53c2-1# sh vpdn hist failure Table size: 20 Number of entries in table: 1 User: U0001N3P1V1.9@V1.9.com, MID = 15 NAS: Information is not applicable Gateway: Information is not applicable Log time: 00:45:47, Error repeat count: 13 Failure type: The remote server closed this session Failure reason: Result 2, Error 6, Disconnect from PPP c53c2-1# sh resource-pool call Shelf 0, slot 0, port 0, channel 30, state RM_RPM_RES_ALLOCATED Customer profile vpdnrpms, resource group C53c2-1-dig DNIS number 1020 c53c2-1# sh resource-pool resource List of Resources: C53c2-1-dig

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:

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


Example 2-24: Sample show Command Output for VHG/PE 72vhg2# sh vpdn L2TP Tunnel and Session Information Total tunnels 1 sessions 1 LocID RemID Remote Name State Remote Address Port Sessions 46668 13637 gcoe est 10.1.2.18 1701 1 LocID RemID TunID Intf Username State Last Chg Fastswitch 9 57 46668 Vi2 anchan@gcoe.c est 4d03h enabled 72vhg2# sh vpdn tunnel L2TP Tunnel Information Total tunnels 1 sessions 1 LocID RemID Remote Name State Remote Address Port Sessions 46668 13637 gcoe est 10.1.2.18 1701 1 72vhg2# sh vpdn tunnel all L2TP Tunnel Information Total tunnels 1 sessions 1 Tunnel id 46668 is up, remote id is 13637, 1 active sessions Tunnel state is established, time since change 4d03h Remote tunnel name is gcoe Internet Address 10.1.2.18, port 1701 Local tunnel name is gcoe.com Internet Address 10.1.3.1, port 1701 71791 packets sent, 71783 received, 1723220 bytes sent, 1723598 received Control Ns 3, Nr 7 Local RWS 3000 (default), Remote RWS 800 Retransmission time 1, max 1 seconds Unsent queuesize 0, max 0 Resend queuesize 0, max 1 Total resends 0, ZLB ACKs sent 4 Current nosession queue check 0 of 5 Retransmit time distribution: 0 0 0 0 0 0 0 0 0 Sessions disconnected due to lack of resources 0 72vhg2# sh vpdn session L2TP Session Information Total tunnels 1 sessions 1 LocID RemID TunID Intf Username State Last Chg Fastswitch 9 57 46668 Vi2 anchan@gcoe.c est 4d03h enabled c72c3-1# sh user Line User Host(s) Idle Location * 0 con 0 idle 00:00:00 Interface User Mode Idle Peer Address Vi1 U0001N3P1V Virtual PPP (L2TP ) 00:00:00 c72c3-1# sh caller Active Idle Line User Service Time Time con 0 - TTY 00:22:03 00:00:00 Vi1 U0001N3P1V1.8@V1.8.com \ PPP L2TP 00:00:48 00:00:00 c72c3-1# sh caller user U0001N3P1V1.8@V1.8.com User: U0001N3P1V1.8@V1.8.com, line Vi1, service PPP L2TP Active time 00:01:02, Idle time 00:00:00 Timeouts: Absolute Idle Limits: - - Disconnect in: - - PPP: LCP Open, multilink Closed, CHAP (<- AAA), IPCP IP: Local 12.1.8.250, remote 12.1.8.1 VPDN: NAS c53c2-1, MID 4, MID Unknown HGW , NAS CLID 0, HGW CLID 0, tunnel open Counts: 137 packets input, 85970 bytes, 0 no buffer 0 input errors, 0 CRC, 0 frame, 0 overrun 21 packets output, 356 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets c72c3-1# sh int virtual-ac 1 Virtual-Access1 is up, line protocol is up Hardware is Virtual Access interface Interface is unnumbered. Using address of Loopback8 (12.1.8.250) MTU 1500 bytes, BW 64 Kbit, DLY 100000 usec, reliability 255/255, txload 1/255, rxload 23/255 Encapsulation PPP, loopback not set Keepalive set (10 sec) DTR is pulsed for 5 seconds on reset LCP Open, multilink Closed Open: IPCP Last input 00:00:00, output never, output hang never Last clearing of "show interface" counters 00:05:05 Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 5 minute input rate 6000 bits/sec, 5 packets/sec 5 minute output rate 0 bits/sec, 0 packets/sec 195 packets input, 128226 bytes, 0 no buffer Received 0 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 23 packets output, 388 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out 0 carrier transitions c72c3-1# sh int virtual-ac 1 configur Virtual-Access1 is an L2TP link interface Building configuration... interface Virtual-Access1 configuration... ip vrf forwarding V1.8.com ip unnumbered Loopback8 ip mtu 1460 ip mroute-cache no snmp trap link-status c72c3-1# sh ip route vrf V1.8.com 12.1.8.250 Routing entry for 12.1.8.250/32 Known via "connected", distance 0, metric 0 (connected, via interface) Redistributing via bgp 100 Advertised by bgp 100 metric 1 Routing Descriptor Blocks: * directly connected, via Loopback8 Route metric is 0, traffic share count is 1 c72c3-1# sh ip local pool V1.8-pool Pool Begin End Free In use V1.8-pool 12.1.8.1 12.1.8.10 9 1 Available addresses: 12.1.8.2 12.1.8.3 12.1.8.4 12.1.8.5 12.1.8.6 12.1.8.7 12.1.8.8 12.1.8.9 12.1.8.10 Inuse addresses: 12.1.8.1 Vi1 U0001N3P1V1.8@V1.8.com

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.

The design of this feature ensures that a pool name is an explicit selection of a group, or address space. There are, however, a few characteristics about this feature that the administrator must know.

With Overlapping Address Pool, you can:

With Overlapping Address Pool, you cannot:

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.


Example 2-25: Sample show Command Output for Overlapping Address Pool c72c3-1# sh ip local pool V1.28-pool Pool Begin End Free In use ** pool <V1.28-pool> is in group <V1.28-group> V1.28-pool 10.1.28.1 10.1.28.10 9 1 Available addresses: 10.1.28.5 10.1.28.6 10.1.28.7 10.1.28.8 10.1.28.9 10.1.28.10 10.1.28.1 10.1.28.2 10.1.28.3 Inuse addresses: 10.1.28.4 Vi9 U0001N3P1@V1.28.com

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:

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

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


Example 2-26: Sample show Command Output for NAS/PE

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.

The design of this feature ensures that a pool name is an explicit selection of a group, or address space. There are, however, a few characteristics about this feature that the administrator must know.

With Overlapping Address Pool, you can:

With Overlapping Address Pool, you cannot:

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.


Example 2-27: Sample show Command Output for Overlapping Address Pool c72c3-1# sh ip local pool V1.28-pool Pool Begin End Free In use ** pool <V1.28-pool> is in group <V1.28-group> V1.28-pool 10.1.28.1 10.1.28.10 9 1 Available addresses: 10.1.28.5 10.1.28.6 10.1.28.7 10.1.28.8 10.1.28.9 10.1.28.10 10.1.28.1 10.1.28.2 10.1.28.3 Inuse addresses: 10.1.28.4 Vi9 U0001N3P1@V1.28.com

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.


Figure 2-8: Topology of Dial Backup


Table 2-3 describes the major dial backup events.


Table 2-3: Troubleshooting Dial Backup Call Flow Events
Step in Call Flow Troubleshooting Topic

1. Connectivity is lost (for a specified time) on the primary connection. On the remote CE, the backup interface is activated and dials a backup phone number on the NAS. The customer's subnets are moved from the primary link to the backup link.

Initiating Backup Connection, Switching Call to Backup Link

2. The session proceeds as in L2TP dial-in access to MPLS VPN. The NAS tunnels the PPP (or MLP) session to the VHG/PE, which then maps the incoming session into the appropriate VRF.

Connectivity is maintained and the remote user is again part of the customer VPN. Packets can flow from/to the remote user.

Once you verify that the backup link is dialed, troubleshoot as in troubleshooting normal L2TP dial-in access.

3. When the primary link is restored, the backup connection is terminated by the remote user, the VHG/PE deletes the backup route, and the CE switches back to the primary link.

Terminating Backup Connection, Switching Call to Primary Link

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?

*Mar 1 03:37:31.788: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, changed state to down !-- The primary interface goes down *Mar 1 03:37:42.719: %LINK-3-UPDOWN: Interface Dialer1, changed state to up !-- The backup interface is brought out of standby mode approximately !-- ten seconds later

Terminating Backup Connection, Switching Call to Primary Link

Is the backup link deactivated when the primary link recovers?


Example 2-28: Sample Results of Commands on Remote CE CE router# show debug Backup: Backup events debugging is on PPP: PPP authentication debugging is on PPP protocol errors debugging is on PPP protocol negotiation debugging is on IP routing: IP routing debugging is on CE router# show backup Primary Interface Secondary Interface Status ----------------- ------------------- ------ Serial7:0 Dialer81 normal operation CE router# show interface se7:0 Serial7:0 is up, line protocol is up Hardware is DSX1 Internet address is 10.1.8.5/30 Backup interface Dialer81, failure delay 0 sec, secondary disable delay 0 sec, /*'backup delay {enable-delay|never} {disable-delay|never}' enable-delay Number of seconds that elapse after the primary line goes down but before IOS activates the secondary line. disable-delay Number of seconds that elapse after the primary line comes up but before IOS deactivates the secondary line. never Prevents secondary line from being activated or deactivated.*/ kickin load not set, kickout load not set /*'backup load {enable-threshold|never} {disable-threshold|never}' enable-threshold Percentage of the primary line's available bandwidth that the traffic load must exceed before to enable dial backup. disable-threshold Percentage of the primary line's available bandwidth that the load must be less than to disable dial backup. never Set the secondary line never to be activated due to traffic load.*/ MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation HDLC, loopback not set Keepalive set (10 sec) Last input 00:00:01, output never, output hang never Last clearing of "show interface" counters never Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 30 second input rate 0 bits/sec, 0 packets/sec 30 second output rate 0 bits/sec, 0 packets/sec 75 packets input, 10526 bytes, 0 no buffer Received 52 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 5500 packets output, 137397 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out 1 carrier transitions Timeslot(s) Used:1, Transmitter delay is 0 flags CE router# show dialer interface dialer 81 Di81 - Dialing not enabled on this interface. CE router# show ip route 10.1.8.241 Routing entry for 10.1.8.241/32 Known via "rip", distance 120, metric 1 Redistributing via rip Last update from 10.1.8.6 on Serial7:0, 00:00:26 ago Routing Descriptor Blocks: * 10.1.8.6, from 10.1.8.6, 00:00:26 ago, via Serial7:0 Route metric is 1, traffic share count is 1

...The primary link goes down...

Jul 4 08:20:00.042: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial7:0, changed state to down Jul 4 08:20:00.042: BACKUP(Serial7:0): event = primary went down Jul 4 08:20:00.042: BACKUP(Serial7:0): changed state to "waiting to backup" Jul 4 08:20:00.042: RT: del 10.2.8.241/32 via 10.1.8.6, rip metric [120/9] Jul 4 08:20:00.042: RT: delete subnet route to 10.2.8.241/32 Jul 4 08:20:00.042: RT: del 10.2.8.242/32 via 10.1.8.6, rip metric [120/9] Jul 4 08:20:00.042: RT: delete subnet route to 10.2.8.242/32 Jul 4 08:20:00.042: RT: del 10.2.8.243/32 via 10.1.8.6, rip metric [120/9] Jul 4 08:20:00.042: RT: delete subnet route to 10.2.8.243/32 Jul 4 08:20:00.042: RT: del 10.2.8.244/32 via 10.1.8.6, rip metric [120/9] Jul 4 08:20:00.042: RT: delete subnet route to 10.2.8.244/32 Jul 4 08:20:00.042: RT: del 10.2.8.245/32 via 10.1.8.6, rip metric [120/9] Jul 4 08:20:00.042: RT: delete subnet route to 10.2.8.245/32 Jul 4 08:20:00.046: RT: del 10.2.8.246/32 via 10.1.8.6, rip metric [120/9] Jul 4 08:20:00.046: RT: delete subnet route to 10.2.8.246/32 Jul 4 08:20:00.046: RT: del 10.2.8.247/32 via 10.1.8.6, rip metric [120/9] Jul 4 08:20:00.046: RT: delete subnet route to 10.2.8.247/32 Jul 4 08:20:00.046: RT: del 10.2.8.248/32 via 10.1.8.6, rip metric [120/9] Jul 4 08:20:00.046: RT: delete subnet route to 10.2.8.248/32 Jul 4 08:20:00.046: RT: del 10.2.8.249/32 via 10.1.8.6, rip metric [120/9] Jul 4 08:20:00.046: RT: delete subnet route to 10.2.8.249/32 Jul 4 08:20:00.046: RT: del 10.1.8.241/32 via 10.1.8.6, rip metric [120/1] Jul 4 08:20:00.046: RT: delete subnet route to 10.1.8.241/32 Jul 4 08:20:00.046: RT: del 10.1.8.242/32 via 10.1.8.6, rip metric [120/9] Jul 4 08:20:00.046: RT: delete subnet route to 10.1.8.242/32 Jul 4 08:20:00.046: RT: del 10.1.8.245/32 via 10.1.8.6, rip metric [120/1] Jul 4 08:20:00.046: RT: delete subnet route to 10.1.8.245/32 Jul 4 08:20:00.050: RT: del 10.1.8.246/32 via 10.1.8.6, rip metric [120/9] Jul 4 08:20:00.050: RT: delete subnet route to 10.1.8.246/32 Jul 4 08:20:00.050: BACKUP(Serial7:0): event = timer expired Jul 4 08:20:00.050: BACKUP(Serial7:0): secondary interface (Dialer81) made active Jul 4 08:20:00.050: BACKUP(Serial7:0): changed state to "backup mode" Jul 4 08:20:00.150: RT: interface Serial7:0 removed from routing table Jul 4 08:20:00.150: RT: del 10.1.8.4/30 via 0.0.0.0, connected metric [0/0] Jul 4 08:20:00.150: RT: delete subnet route to 10.1.8.4/30 Jul 4 08:20:00.154: RT: add 10.1.8.0/30 via 0.0.0.0, connected metric [0/0] Jul 4 08:20:00.154: RT: interface Dialer81 added to routing table Jul 4 08:20:01.154: RT: add 10.2.8.250/32 via 0.0.0.0, static metric [220/0] Jul 4 08:20:01.154: RT: add 10.1.8.0/24 via 0.0.0.0, static metric [230/0] Jul 4 08:20:02.050: %LINK-3-UPDOWN: Interface Dialer81, changed state to up Jul 4 08:20:02.050: Di81 LCP: Not allowed on a Dialer Profile Jul 4 08:20:02.050: BACKUP(Dialer81): event = primary came up CE router# show ip route 10.1.8.241 Routing entry for 10.1.8.0/24 Known via "static", distance 230, metric 0 (connected) Redistributing via rip Advertised by rip Routing Descriptor Blocks: * directly connected, via Dialer81 Route metric is 0, traffic share count is 1 CE router# show inter se7:0 Serial7:0 is up, line protocol is down Hardware is DSX1 Internet address is 10.1.8.5/30 Backup interface Dialer81, failure delay 0 sec, secondary disable delay 0 sec, kickin load not set, kickout load not set MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec, reliability 255/255, txload 1/255, rxload 1/255 Encapsulation HDLC, loopback not set Keepalive set (10 sec) Last input 00:00:56, output never, output hang never Last clearing of "show interface" counters never Queueing strategy: fifo Output queue 0/40, 0 drops; input queue 0/75, 0 drops 30 second input rate 0 bits/sec, 0 packets/sec 30 second output rate 0 bits/sec, 0 packets/sec 86 packets input, 11737 bytes, 0 no buffer Received 57 broadcasts, 0 runts, 0 giants, 0 throttles 0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort 5519 packets output, 138641 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets 0 output buffer failures, 0 output buffers swapped out 1 carrier transitions Timeslot(s) Used:1, Transmitter delay is 0 flags CE router# show dialer interface dialer 81 Di81 - dialer type = DIALER PROFILE Idle timer (120 secs), Fast idle timer (300 secs) Wait for carrier (30 secs), Re-enable (15 secs) Dialer state is data link layer up Number of active calls = 1 Dial String Successes Failures Last DNIS Last status 8110 3 0 00:01:26 successful Default Serial0:15 - dialer type = ISDN Dial String Successes Failures Last DNIS Last status 0 incoming call(s) have been screened. 0 incoming call(s) rejected for callback. Serial0:0 - dialer type = ISDN Idle timer (120 secs), Fast idle timer (300 secs) Wait for carrier (30 secs), Re-enable (15 secs) Dialer state is data link layer up Dial reason: ip (s=10.1.8.1, d=10.1.8.241) Interface bound to profile Di81 Time until disconnect 35 secs Current call connected 00:01:28 Connected to 8110 (8110) CE router# show backup Primary Interface Secondary Interface Status ----------------- ------------------- ------ Serial7:0 Dialer81 backup mode CE router# show ip route 10.1.8.241 Routing entry for 10.1.8.241/32 Known via "rip", distance 120, metric 1 Redistributing via rip Last update from 10.1.8.2 on Dialer81, 00:00:20 ago Routing Descriptor Blocks: * 10.1.8.2, from 10.1.8.2, 00:00:20 ago, via Dialer81 Route metric is 1, traffic share count is 1 To summarize, ping through the MPLS network, from end to end. CE router# ping 10.1.8.241 Jul 4 08:20:15.422: %LINK-3-UPDOWN: Interface Serial0:0, changed state to up Jul 4 08:20:15.422: Se0:0 PPP: Phase is DOWN, Setup [0 sess, 0 load] Jul 4 08:20:15.422: Se0:0 PPP: Treating connection as a callout Jul 4 08:20:15.422: Se0:0 PPP: Phase is ESTABLISHING, Active Open [0 sess, 0 load] Jul 4 08:20:15.426: Se0:0 PPP: No remote authentication for call-out Jul 4 08:20:15.426: Se0:0 LCP: O CONFREQ [Closed] id 1 len 10 Jul 4 08:20:15.426: Se0:0 LCP: MagicNumber 0x53B5CC6E (0x050653B5CC6E) Jul 4 08:20:15.426: %DIALER-6-BIND: Interface Se0:0 bound to profile Di81 Jul 4 08:20:15.426: Se0:0 PPP: Treating connection as a callout Jul 4 08:20:15.434: Se0:0 LCP: I CONFREQ [REQsent] id 30 len 15 Jul 4 08:20:15.434: Se0:0 LCP: AuthProto CHAP (0x0305C22305) Jul 4 08:20:15.434: Se0:0 LCP: MagicNumber 0xEF83FEAF (0x0506EF83FEAF) Jul 4 08:20:15.434: Se0:0 LCP: O CONFACK [REQsent] id 30 len 15 Jul 4 08:20:15.434: Se0:0 LCP: AuthProto CHAP (0x0305C22305) Jul 4 08:20:15.434: Se0:0 LCP: MagicNumber 0xEF83FEAF (0x0506EF83FEAF) Jul 4 08:20:15.438: Se0:0 LCP: I CONFACK [ACKsent] id 1 len 10 Jul 4 08:20:15.438: Se0:0 LCP: MagicNumber 0x53B5CC6E (0x050653B5CC6E) Jul 4 08:20:15.438: Se0:0 LCP: State is Open Jul 4 08:20:15.438: Se0:0 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 0 load] Jul 4 08:20:15.446: Se0:0 CHAP: I CHALLENGE id 30 len 28 from "c53d9-1" Jul 4 08:20:15.446: Se0:0 CHAP: Using alternate hostname U0001N1P3V1.8@V1.8.com Jul 4 08:20:15.446: Se0:0 CHAP: Username c53d9-1 not found Jul 4 08:20:15.446: Se0:0 CHAP: Using default password Jul 4 08:20:15.446: Se0:0 CHAP: O RESPONSE id 30 len 43 from "U0001N1P3V1.8@V1.8.com" Jul 4 08:20:15.490: Se0:0 CHAP: I SUCCESS id 30 len 4 Jul 4 08:20:15.490: Se0:0 PPP: Phase is UP [0 sess, 0 load] Jul 4 08:20:15.490: Se0:0 IPCP: O CONFREQ [Closed] id 1 len 10 Jul 4 08:20:15.490: Se0:0 IPCP: Address 10.1.8.1 (0x030620010801) Jul 4 08:20:15.522: Se0:0 IPCP: I CONFREQ [REQsent] id 1 len 10 Jul 4 08:20:15.522: Se0:0 IPCP: Address 10.1.8.2 (0x030620010802) Jul 4 08:20:15.522: Se0:0 IPCP: O CONFACK [REQsent] id 1 len 10 Jul 4 08:20:15.522: Se0:0 IPCP: Address 10.1.8.2 (0x030620010802) Jul 4 08:20:15.526: Se0:0 IPCP: I CONFACK [ACKsent] id 1 len 10 Jul 4 08:20:15.526: Se0:0 IPCP: Address 10.1.8.1 (0x030620010801) Jul 4 08:20:15.526: Se0:0 IPCP: State is Open Jul 4 08:20:15.526: RT: add 10.1.8.2/32 via 0.0.0.0, connected metric [0/0] Jul 4 08:20:15.526: Di81 IPCP: Install route to 10.1.8.2 Jul 4 08:20:16.490: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0:0, changed state to up Jul 4 08:20:17.866: RT: add 10.2.8.241/32 via 10.1.8.2, rip metric [120/9] Jul 4 08:20:17.866: RT: add 10.2.8.242/32 via 10.1.8.2, rip metric [120/9] Jul 4 08:20:17.866: RT: add 10.2.8.243/32 via 10.1.8.2, rip metric [120/9] Jul 4 08:20:17.866: RT: add 10.2.8.244/32 via 10.1.8.2, rip metric [120/9] Jul 4 08:20:17.866: RT: add 10.2.8.245/32 via 10.1.8.2, rip metric [120/9] Jul 4 08:20:17.870: RT: add 10.2.8.246/32 via 10.1.8.2, rip metric [120/9] Jul 4 08:20:17.870: RT: add 10.2.8.247/32 via 10.1.8.2, rip metric [120/9] Jul 4 08:20:17.874: RT: add 10.2.8.248/32 via 10.1.8.2, rip metric [120/9] Jul 4 08:20:17.874: RT: add 10.2.8.249/32 via 10.1.8.2, rip metric [120/9] Jul 4 08:20:17.874: RT: add 10.1.8.241/32 via 10.1.8.2, rip metric [120/1] Jul 4 08:20:17.878: RT: add 10.1.8.242/32 via 10.1.8.2, rip metric [120/9] Jul 4 08:20:17.878: RT: add 10.1.8.245/32 via 10.1.8.2, rip metric [120/1] Jul 4 08:20:17.878: RT: add 10.1.8.246/32 via 10.1.8.2, rip metric [120/9] Jul 4 08:20:21.426: %ISDN-6-CONNECT: Interface Serial0:0 is now connected to 8110 unknown

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:

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.


Figure 2-9: Topology of L2TP Dial-out Remote Access



Figure 2-10:
Topology of Direct ISDN PE Dial-out Remote Access


These are the main events in the dial-out call flow:

    1. Traffic from a specific customer VPN, destined for a specific dial-out network (identified through static routes in the customer VRF) is directed to the appropriate VHG/PE or NAS/PE.

    2. Upon receiving the traffic, either the VHG/PE or the NAS/PE responds:

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?

Is the VHG/PE receiving traffic for the remote CE? Check to see if a static route is configured on the VHG/PE. In the following example, the static route has been created for Dialer50.


Example 2-29: Checking for a Static Route router# sh ip route vrf V1.17.com static 10.0.0.0/32 is subnetted, 6 subnets S 10.1.17.40 is directly connected, Dialer53 S 10.1.17.30 is directly connected, Dialer52 S 10.1.17.20 is directly connected, Dialer51 S 10.1.17.10 is directly connected, Dialer50

Is the route being forwarded to the 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:


Example 2-30: Checking Route-Specific Detail router# sh ip route vrf V1.17.com 10.1.17.10 Routing entry for 10.1.17.10/32 Known via "static", distance 1, metric 0 (connected) Redistributing via bgp 100 <<< Advertised by bgp 100 <<< Routing Descriptor Blocks: * directly connected, via Dialer50, permanent Route metric is 0, traffic share count is 1

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:


Example 2-31: Checking the Remote PE

On the remote PE:

router# sh ip route vrf V1.17.com 10.1.17.10 Routing entry for 10.1.17.10/32 Known via "bgp 100", distance 200, metric 1, type internal Last update from 10.10.104.12 00:23:07 ago Routing Descriptor Blocks: * 10.10.104.12 (Default-IP-Routing-Table), from 10.10.104.12, 00:23:07 ago Route metric is 1, traffic share count is 1 AS Hops 0
Step 2. Is VRF FIB Information Forwarded in the MPLS Core?

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

If the route is properly reflected in the remote PE's routing table, check the VHG/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 VHG/PE:

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


Example 2-32: Checking MPLS Path router# show 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 Aggregate 10.1.17.10/32[V] 0

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 VHG/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:


Example 2-33: Checking CEF router# sh ip cef vrf V1.17.com 10.1.17.10 10.1.17.10/32, version 163, cached adjacency 10.10.103.113 0 packets, 0 bytes tag information set local tag: VPN-route-head fast tag rewrite with Et0/1, 10.10.103.113, tags imposed: {78 82} via 10.10.104.12, 0 dependencies, recursive next hop 10.10.103.113, Ethernet0/1 via 10.10.104.12/32 valid cached adjacency tag rewrite with Et0/1, 10.10.103.113, tags imposed: {78 82}

In this example, 78 is the tag to reach 10.10.104.12, the VHG/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 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 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.


Table 2-4: debugging Commands for Dial-out
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 Examples

This is the incoming MPLS packet with a tag header containing tag value 82, destined for remote CE and triggering the call. The following debugging shows this.

router# Mar 7 09:58:37.878: TAG: PO5/0: recvd: CoS=0, TTL=252, Tag(s)=82 Mar 7 09:58:37.882: Vi31 DDR: Dialing cause ip (s=10.2.17.241, d=10.1.17.10) Mar 7 09:58:37.882: Vi31 DDR: Attempting to dial 11710 Mar 7 09:58:37.914: %LINK-3-UPDOWN: Interface Virtual-Access31, changed state to up Mar 7 09:58:37.914: Vi31 DDR: Dialer statechange to up Mar 7 09:58:37.914: %DIALER-6-BIND: Interface Vi31 bound to profile Di50 Mar 7 09:58:37.914: Vi31 DDR: Dialer call has been placed Mar 7 09:58:37.966: %DIALER-6-BIND: Interface Vi30 bound to profile Di50 Mar 7 09:58:37.970: %LINK-3-UPDOWN: Interface Virtual-Access30, changed state to up Mar 7 09:58:37.970: Vi30 DDR: Dialer statechange to up Mar 7 09:58:37.970: Vi30 DDR: Dialer call has been placed

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.


Example 2-38: debug Output When the Call Is Up Mar 7 09:58:37.978: CEF-Dialer (legacy): add link to 10.1.17.10 via Dialer50 through Virtual-Access30 Mar 7 09:58:37.978: CEF-Dialer: adjacency added: 0x62F77AC0 Mar 7 09:58:37.978: CEF-Dialer: adjacency found: 0x62F77AC0; fib->count: 1 Mar 7 09:58:37.978: CEF-Dialer: setup loadinfo with 1 paths Mar 7 09:58:37.978: Vi30 DDR: dialer protocol up Mar 7 09:58:38.958: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access31, changed state to up Mar 7 09:58:38.970: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access30, changed state to up
Example 2-39: debug Output When the Call Goes Down deb ip cef dialer Mar 7 12:41:47.853: CEF-Dialer (legacy): remove link to 10.1.17.10 via Dialer50 through Virtual-Access30

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:


Example 2-40: show ip route router# sh ip route vrf V1.17.com static 10.0.0.0/32 is subnetted, 6 subnets S 10.1.17.40 is directly connected, Dialer53 S 10.1.17.30 is directly connected, Dialer52 S 10.1.17.20 is directly connected, Dialer51 S 10.1.17.10 is directly connected, 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:


Example 2-41: show ip route detail router# sh ip route vrf V1.17.com 10.1.17.10 Routing entry for 10.1.17.10/32 Known via "static", distance 1, metric 0 (connected) Redistributing via bgp 100 <<< Advertised by bgp 100 <<< Routing Descriptor Blocks: * directly connected, via Dialer50, permanent Route metric is 0, traffic share count is 1

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:


Example 2-42: show ip route vrf router# sh ip rout vrf V1.17.com 10.1.17.10 Routing entry for 10.1.17.10/32 Known via "bgp 100", distance 200, metric 1, type internal Last update from 10.10.104.12 00:23:07 ago Routing Descriptor Blocks: * 10.10.104.12 (Default-IP-Routing-Table), from 10.10.104.12, 00:23:07 ago Route metric is 1, traffic share count is 1 AS Hops 0
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?


Example 2-43: show mpls forwarding-table router# show 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 Aggregate 10.1.17.10/32[V] 0

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:


Example 2-44: show ip cef router# show ip cef vrf V1.17.com 10.1.17.10 10.1.17.10/32, version 163, cached adjacency 10.10.103.113 0 packets, 0 bytes tag information set local tag: VPN-route-head fast tag rewrite with Et0/1, 10.10.103.113, tags imposed: {78 82} via 10.10.104.12, 0 dependencies, recursive next hop 10.10.103.113, Ethernet0/1 via 10.10.104.12/32 valid cached adjacency tag rewrite with Et0/1, 10.10.103.113, tags imposed: {78 82} ^^^^

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.


Example 2-45: show ip cef router# show 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

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):


Example 2-46: show ip route router# show 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 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:


Example 2-47: show mpls forwarding table 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-48: show adjacency router# show adjacency virtual-acc 2 Protocol Interface Address TAG Virtual-Access2 point2point(4) (incomplete) IP Virtual-Access2 point2point(33)
Example 2-49: show adjacency detail router# show adjacency 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 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.


Table 2-5: Debug Commands for Direct ISDN PE Dial-out
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 Examples

Example 2-50: Debugging Direct ISDN PE Dial-out c72d2-2# Mar 7 09:58:37.878: TAG: PO5/0: recvd: CoS=0, TTL=252, Tag(s)=82 This is the incoming MPLS packet with a tag header containing tag value 82, destined for remote CE and triggering the call. The following debugging shows this. Mar 7 09:58:37.882: Vi31 DDR: Dialing cause ip (s=10.2.17.241, d=10.1.17.10) Mar 7 09:58:37.882: Vi31 DDR: Attempting to dial 11710 Mar 7 09:58:37.914: %LINK-3-UPDOWN: Interface Virtual-Access31, changed state to up Mar 7 09:58:37.914: Vi31 DDR: Dialer statechange to up Mar 7 09:58:37.914: %DIALER-6-BIND: Interface Vi31 bound to profile Di50 Mar 7 09:58:37.914: Vi31 DDR: Dialer call has been placed Mar 7 09:58:37.966: %DIALER-6-BIND: Interface Vi30 bound to profile Di50 Mar 7 09:58:37.970: %LINK-3-UPDOWN: Interface Virtual-Access30, changed state to up Mar 7 09:58:37.970: Vi30 DDR: Dialer statechange to up Mar 7 09:58:37.970: Vi30 DDR: Dialer call has been placed
Example 2-51: Debugging After Changes in the CEF Switching Path

This 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.

Mar 7 09:58:37.978: CEF-Dialer (legacy): add link to 10.1.17.10 via Dialer50 through Virtual-Access30 Mar 7 09:58:37.978: CEF-Dialer: adjacency added: 0x62F77AC0 Mar 7 09:58:37.978: CEF-Dialer: adjacency found: 0x62F77AC0; fib->count: 1 Mar 7 09:58:37.978: CEF-Dialer: setup loadinfo with 1 paths Mar 7 09:58:37.978: Vi30 DDR: dialer protocol up Mar 7 09:58:38.958: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access31, changed state to up Mar 7 09:58:38.970: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access30, changed state to up When the call goes down deb ip cef dialer Mar 7 12:41:47.853: CEF-Dialer (legacy): remove link to 10.1.17.10 via Dialer50 through Virtual-Access30

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:


Example 2-52: Sample Show Output for Multilink PPP Virtual-Access9, bundle name is U0006N1P3V1.2@V1.2.com/U0006N1P3V1.2@V1.2.com Bundle up for 00:00:37 0 lost fragments, 0 reordered, 0 unassigned 0 discarded, 0 lost received, 11/255 load 0x7E received sequence, 0x0 sent sequence Member links: 2 (max not set, min not set) Serial1/0:0, since 00:00:37, last rcvd seq 00007C Serial1/0:1, since 00:00:05, last rcvd seq 00007D

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,


Figure 2-11: Topology of Multichassis Multilink PPP


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 .


Table 2-6: show and debug Commands for MMP
Command Use To...

show ppp multilink

Display multilink PPP bundle information.

show sgbp

Verify the state of the stack group members. Make sure all member states are ACTIVE (the group member is functioning as a group member).

If state is IDLE, the stack group cannot detect the remote stack group member. Unless there is a known reason for the down state (such as maintenance), look for routing problems. Use debug sgbp errors to confirm that authentication was successful.

Note   CONNECTING or WAITINFO are transitional states that should occur only when the stack group member is making the transition to the ACTIVE state.

debug sgbp hellos

Use this command if an authentication problem between two stack group members is detected using show sgbp.

Stack group names and member names are case-sensitive and must match exactly the host names configured for the stack group. If authentication of one NAS by another fails, determine if a new group member has a password.

debug sgbp error

Check for wiring or routing problems which may cause the stack member's source IP address (received in the hello message) to differ from its locally-defined IP address.

debug vpdn event

Display errors and events associated with establishing or terminating L2TP tunnels for VPDNs.

debug vpdn error

Display errors associated with L2TP events.

debug vpdn l2f-error

Display errors associated with L2X protocol events.

debug vtemplate

Display cloning information for a virtual access interface from the time it is cloned from a virtual template to the time it comes down.

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:


Example 2-53: Sample Results of show ppp multilink for Troubleshooting MMP RouterD# show ppp multilink Bundle UserX 2 members, Master link is Virtual-Access4 0 lost fragments, 0 reordered, 0 unassigned, 100/255 load 0 discarded, 0 lost received, sequence 40/66 rcvd/sent members: 2 NASC: Virtual-Access1 (1.1.1.3) NASB: Virtual-Access6 (1.1.1.2)

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


Example 2-54: Sample Results of show sgbp for Troubleshooting MMP NASA# show sgbp Group Name: stack1 State: 0 Ref: 0xC07B060 Member Name: NASB State: ACTIVE Id: 1 Ref: 0xC14256F Address: 1.1.1.2 Tcb: 0x60B34538 Member Name: NASC State: ACTIVE Id: 2 Ref: 0xA24256D Address: 1.1.1.3 Tcb: 0x60B34439 Member Name: RouterD State: IDLE Id: 3 Ref: 0x0 Address: 1.1.1.4 Tcb: 0x0

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


Example 2-55: Sample Results of debug sgbp hellos for Troubleshooting MMP NASA# debug sgbp hellos %SGBP-7-CHALLENGE: Send Hello Challenge to NASB group stack1 %SGBP-7-CHALLENGED: Hello Challenge message from member NASB using (1.1.1.2) %SGBP-7-RESPONSE: Send Hello Response to NASB group stack1 %SGBP-7-RESPONDED: Hello Response message from member NASB using (1.1.1.2) %SGBP-7-AUTHOK: Send Hello Authentication OK to member NASBusing (1.1.1.2) %SGBP-7-INFO: Addr = 1.1.1.2 Reference = 0xC347DF7 %SGBP-5-ARRIVING = New peer event for member NASB %SGBP-7-AUTHFAILED - Member NASB failed authentication %SGBP-7-NORESP - Fail to respond to NASB group stack1, may not have 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.


Example 2-56: Sample Results of debug sgbp queries for Troubleshooting MMP RouterD# debug sgbp queries will show the query state transition %SGBPQ-7-MQ: Bundle: UserX State: Query_to_peers OurBid: 050 %SGBPQ-7-PB: 1.1.1.1 State: Open_to_peer Bid: 000 Retry: 0 %SGBPQ-7-PB: 1.1.1.2 State: Open_to_peer Bid: 000 Retry: 0 %SGBPQ-7-PB: 1.1.1.3 State: Open_to_peer Bid: 000 Retry: 0 %SGBPQ-7-MQ: Bundle: UserX State: Query_to_peers OurBid: 050 %SGBPQ-7-PB: 1.1.1.1 State: Rcvd Bid: 000 Retry: 0 %SGBPQ-7-PB: 1.1.1.2 State: Rcvd Bid: 000 Retry: 0 %SGBPQ-7-PB: 1.1.1.3 State: Rcvd Bid: 000 Retry: 0 %SGBPQ-7-DONE: Query #5 for bundle UserX, count 1, master is local %SGBPQ-7-MQ: Bundle: UserX State: Done OurBid: 10000 %SGBPQ-7-PB: 1.1.1.1 State: Rcvd Bid: 000 Retry: 0 %SGBPQ-7-PB: 1.1.1.2 State: Rcvd Bid: 000 Retry: 0 %SGBPQ-7-PB: 1.1.1.3 State: Rcvd Bid: 000 Retry: 0

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".


Example 2-57: Sample Results of debug sgbp error for Troubleshooting MMP RouterD# debug sgbp error %SGBP-7-DIFFERENT - NASB addr 1.1.1.2 is different from hellos addr (3.3.4.5) %SGBP-7-MISCONF, Possible misconfigured member NASK (1.1.1.6) NASC# debug sgbp error %SGBP-7-CHALLENGE: Send Hello Challenge to routerd group stack1 %SGBP-1-MISSCONF: Possible misconfigured member RouterD using 1.1.1.4

In this example, debug sgbp error is issued on NASC (the network access server side of the CHAP exchange), and shows that the password on RouterD is incorrect.

NASC# debug sgbp error %SGBP-7-CHALLENGED: Rcv Hello Challenge message from member RouterD using 1.1.1.4 %SGBP-7-RESPONSE: Send Hello Response to RouterD group stack1 %SGBP-7-CHALLENGE: Send Hello Challenge to RouterD group stack1 %SGBP-7-RESPONSED: Rcv Hello Response message from member RouterD using 1.1.1.4 %SGBP-1-AUTHFAILED: Member RouterD failed authentication

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.


Table 2-7: show and debug Commands for ODAP
Command Use To...

show ip dhcp pool <address pool name>

Check that DHCP pool hands out IP addresses for incoming PPP session and puts it in the correct VRF.

debug ip dhcp server events

Report server events such as address assignments.


Example 2-58:
Sample Results of show ip dhcp pool for Troubleshooting ODAP Router# show ip dhcp pool odap-test Pool odap-test : Utilization mark (high/low) : 80 / 20 Subnet size (first/next) : 27 / 27 (autogrow) VRF name : V1.1.com Total addresses : 30 Leased addresses : 0 Pending requests : 0 1 subnet is currently in the pool :Current index IP address range Leased addresses 42.1.1.1 42.1.1.1 - 42.1.1.30
Example 2-59:
Sample Results of debug ip dhcp server events for Troubleshooting ODAP Router# debug ip dhcp server events

DHCPD: allocate request for client U1000N1P3V1.1@V1.1.com on Virtual-Access7. DHCPD: locate VRF V1.1.com pool odap-test for client U1000N1P3V1.1@V1.1.com. DHCPD: assigned IP address 42.1.1.1 to client 5531.3030.304e.3150.3356.312e.3140.5631.2e31.2e63.6f6d.

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


Example 2-60: Example of VHG/PE show ip route Command Output c72d9-1# *Sep 4 09:42:33.627: AAA/AUTHOR (0x55): Pick method list 'default' *Sep 4 09:42:33.631: AAA/AUTHEN/PPP (00000055): Pick method list 'default' *Sep 4 09:42:33.631: RADIUS: Pick NAS IP for uid=85 tableid=0 cfg_addr=10.10.104.9 best_addr=0.0.0.0 *Sep 4 09:42:33.631: RADIUS/ENCODE(00000055): acct_session_id: 146 *Sep 4 09:42:33.631: RADIUS(00000055): sending *Sep 4 09:42:33.631: RADIUS(00000055): Send to unknown id 21647/157 10.10.100.3:1645, Access-Request, len 103 *Sep 4 09:42:33.635: RADIUS: authenticator 96 9E 2F 52 E4 9E 98 10 - E5 B1 B4 77 F5 F4 40 63 *Sep 4 09:42:33.635: RADIUS: Framed-Protocol [7] 6 PPP [1] *Sep 4 09:42:33.635: RADIUS: User-Name [1] 24 "U0001N1P3V1.9@V1.9.com" *Sep 4 09:42:33.635: RADIUS: CHAP-Password [3] 19 * *Sep 4 09:42:33.635: RADIUS: NAS-Port-Type [61] 6 ISDN [2] *Sep 4 09:42:33.635: RADIUS: Called-Station-Id [30] 6 "9111" *Sep 4 09:42:33.635: RADIUS: Service-Type [6] 6 Framed [2] *Sep 4 09:42:33.635: RADIUS: NAS-IP-Address [4] 6 10.10.104.9 *Sep 4 09:42:33.635: RADIUS: Acct-Session-Id [44] 10 "00000092" *Sep 4 09:42:33.639: RADIUS: Received from id 21647/157 10.10.100.3:1645, Access-Accept, len 478 *Sep 4 09:42:33.639: RADIUS: authenticator AA 76 9F 6E 15 06 14 5D - 4B DA F0 6C E6 25 D3 C4 *Sep 4 09:42:33.639: RADIUS: Service-Type [6] 6 Framed [2] *Sep 4 09:42:33.639: RADIUS: Framed-Protocol [7] 6 PPP [1] *Sep 4 09:42:33.639: RADIUS: Vendor, Cisco [26] 83 *Sep 4 09:42:33.639: RADIUS: Cisco AVpair [1] 77 "lcp:interface-config=ip vrf forwarding V1.9.com \n ip unnumbered loopback 9" *Sep 4 09:42:33.639: RADIUS: Vendor, Cisco [26] 75 *Sep 4 09:42:33.639: RADIUS: Cisco AVpair [1] 69 "ip:route=vrf V1.9.com 192.168.200.0 255.255.255.0 32.1.9.10 tag 250" *Sep 4 09:42:33.639: RADIUS(00000055): Received from id 21647/157 *Sep 4 09:42:33.643: ppp118 PPP/AAA: Check Attr: service-type *Sep 4 09:42:33.643: ppp118 PPP/AAA: Check Attr: Framed-Protocol *Sep 4 09:42:33.643: ppp118 PPP/AAA: Check Attr: interface-config:Peruser I/F *Sep 4 09:42:33.643: ppp118 PPP/AAA: Check Attr: route:Peruser *Sep 4 09:42:33.663: %LINK-3-UPDOWN: Interface Virtual-Access10, changed state to up *Sep 4 09:42:33.663: AAA/AUTHEN/PPP (00000055): Pick method list 'default' *Sep 4 09:42:33.663: Vi10 AAA/AUTHOR/LCP: Process Author *Sep 4 09:42:33.663: Vi10 AAA/AUTHOR/LCP: Process Attr: interface-config *Sep 4 09:42:33.663: AAA/AUTHOR: Processing PerUser AV interface-config *Sep 4 09:42:33.663: Vi10 AAA/AUTHOR/LCP: Process Attr: interface-config *Sep 4 09:42:33.663: Vi10 AAA/AUTHOR/LCP: IF_config: ip vrf forwarding V1.9.com \n ip unnumbered loopback 9 *Sep 4 09:42:33.719: Vi10 AAA/AUTHOR/IPCP: FSM authorization not needed *Sep 4 09:42:33.719: Vi10 AAA/AUTHOR/FSM: We can start IPCP *Sep 4 09:42:33.719: Vi10 AAA/AUTHOR/IPCP: Start. Her address 32.1.9.10, we want 0.0.0.0 *Sep 4 09:42:33.719: Vi10 AAA/AUTHOR/IPCP: Reject 32.1.9.10, using 0.0.0.0 *Sep 4 09:42:33.719: Vi10 AAA/AUTHOR/IPCP: Processing AV route *Sep 4 09:42:33.719: Vi10 AAA/AUTHOR/IPCP: Authorization succeeded *Sep 4 09:42:33.719: Vi10 AAA/AUTHOR/IPCP: Done. Her address 32.1.9.10, we want 0.0.0.0 *Sep 4 09:42:33.727: AAA/AUTHOR: Processing PerUser AV route *Sep 4 09:42:33.727: Vi10 AAA/PERUSER/ROUTE: route string: IP route vrf V1.9.com 192.168.200.0 255.255.255.0 32.1.9.10 tag 250 *Sep 4 09:42:33.735: RT(V1.9.com): closer admin distance for 32.1.9.10, flushing 1 routes *Sep 4 09:42:33.735: RT(V1.9.com): NET-RED 32.1.9.10/32 *Sep 4 09:42:33.735: RT(V1.9.com): NET-RED queued, Queue size 1 *Sep 4 09:42:33.735: RT(V1.9.com): add 32.1.9.10/32 via 0.0.0.0, connected metric [0/0] *Sep 4 09:42:33.735: RT(V1.9.com): NET-RED 32.1.9.10/32 *Sep 4 09:42:33.735: RT(V1.9.com): NET-RED push *Sep 4 09:42:33.735: RT(V1.9.com): NET-RED queued, Queue size 2 *Sep 4 09:42:33.747: AAA/PER-USER: command = [IP route vrf V1.9.com 192.168.200.0 255.255.255.0 32.1.9.10 tag 250 ] *Sep 4 09:42:33.747: AAA/PER-USER: line = [IP route vrf V1.9.com 192.168.200.0 255.255.255.0 32.1.9.10 tag 250] *Sep 4 09:42:33.751: RT(V1.9.com): add 192.168.200.0/24 via 32.1.9.10, static metric [1/0] *Sep 4 09:42:33.751: RT(V1.9.com): NET-RED 192.168.200.0/24 *Sep 4 09:42:33.751: RT(V1.9.com): NET-RED queued, Queue size 1 *Sep 4 09:42:33.763: is_up: 1 state: 4 sub state: 1 line: 0 has_route: True *Sep 4 09:42:34.663: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access10, changed state to up

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

*Sep 4 09:56:43.713: %LINK-3-UPDOWN: Interface Virtual-Access10, changed state to down *Sep 4 09:56:43.713: is_up: 0 state: 0 sub state: 1 line: 0 has_route: True *Sep 4 09:56:43.713: RT(V1.9.com): interface Virtual-Access10 removed from routing table *Sep 4 09:56:43.713: RT(V1.9.com): Pruning routes for Virtual-Access10 (1) *Sep 4 09:56:43.713: RT(V1.9.com): delete route to 32.1.9.10 via 0.0.0.0, Virtual-Access10 *Sep 4 09:56:43.713: RT(V1.9.com): no routes to 32.1.9.10, flushing *Sep 4 09:56:43.713: RT(V1.9.com): NET-RED 32.1.9.10/32 *Sep 4 09:56:43.713: RT(V1.9.com): NET-RED queued, Queue size 1 *Sep 4 09:56:43.713: RT(V1.9.com): add 32.1.9.10/32 via 0.0.0.0, static metric [1/0] *Sep 4 09:56:43.713: RT(V1.9.com): NET-RED 32.1.9.10/32 *Sep 4 09:56:43.713: RT(V1.9.com): NET-RED queued, Queue size 2 *Sep 4 09:56:44.713: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access10, changed state to down c72d9-1# c72d9-1# *Sep 4 09:57:03.712: AAA/PER-USER: command = [no IP route vrf V1.9.com 192.168.200.0 255.255.255.0 32.1.9.10 tag 250] *Sep 4 09:57:03.712: AAA/PER-USER: line = [no IP route vrf V1.9.com 192.168.200.0 255.255.255.0 32.1.9.10 tag 250] *Sep 4 09:57:03.724: AAA/AUTHOR: decrement ref cnt for ip route 192.168.200.0 255.255.255.0 32.1.9.10 to 0 *Sep 4 09:57:03.724: RT(V1.9.com): del 192.168.200.0 via 32.1.9.10, static metric [1/0] *Sep 4 09:57:03.724: RT(V1.9.com): delete network route to 192.168.200.0 *Sep 4 09:57:03.724: RT(V1.9.com): NET-RED 192.168.200.0/24 *Sep 4 09:57:03.724: RT(V1.9.com): NET-RED queued, Queue size 1 Show ip route output: c72d9-1#sh ip rout vrf V1.9.com conn 32.0.0.0/32 is subnetted, 2 subnets C 32.1.9.10 is directly connected, Virtual-Access10 C 32.1.9.241 is directly connected, Loopback9 c72d9-1#sh ip route vrf V1.9.com stat U 192.168.200.0/24 [1/0] via 32.1.9.10 V1.9.com is the VRf to which the PPP session belongs U means per-user static route ( a route downloaded via AAA)
Example 2-61: Example of RADIUS debug Command Output Jun 14 12:27:28.969: AAA/BIND: Bind template "V1.33.com" to uid:139 Jun 14 12:27:28.969: AAA/MLIST Ref count of of mlist 0x639668BC raised to 2 Jun 14 12:27:28.969: AAA/AUTHEN/PPP (0000008B): Pick method list 'method_list_V1_33_com' Jun 14 12:27:28.969: RADIUS: Pick NAS IP 32.1.33.241 (uid:139) from source config Jun 14 12:27:28.969: RADIUS/ENCODE(0000008B): acct_session_id: 184 Jun 14 12:27:28.969: RADIUS(0000008B): sending Jun 14 12:27:28.969: AAA/SG/REF_COUNT refcount of server CF000005 increased to 4 Jun 14 12:27:28.969: RADIUS(0000008B): Send to unknown id 21645/182 10.10.132.4:1645, Access-Request, len 107 Jun 14 12:27:28.969: RADIUS: authenticator 55 55 7C 43 89 40 E8 D9 - E5 B1 B4 77 5B E1 63 BB Jun 14 12:27:28.969: RADIUS: Framed-Protocol [7] 6 PPP [1] Jun 14 12:27:28.969: RADIUS: User-Name [1] 26 "U0001N1P3V1.33@V1.33.com" Jun 14 12:27:28.969: RADIUS: CHAP-Password [3] 19 * Jun 14 12:27:28.969: RADIUS: NAS-Port-Type [61] 6 Virtual [5] Jun 14 12:27:28.969: RADIUS: Called-Station-Id [30] 8 "311033" Jun 14 12:27:28.969: RADIUS: Service-Type [6] 6 Framed [2] Jun 14 12:27:28.969: RADIUS: NAS-IP-Address [4] 6 32.1.33.241 Jun 14 12:27:28.969: RADIUS: Acct-Session-Id [44] 10 "000000B8" Jun 14 12:27:28.985: RADIUS: Received from id 21645/182 10.10.132.4:1645, Access-Accept, len 130 Jun 14 12:27:28.985: RADIUS: authenticator E0 53 5C BB C0 8E E1 C5 - 0A A9 E8 45 23 96 D6 53 Jun 14 12:27:28.985: RADIUS: Service-Type [6] 6 Framed [2] Jun 14 12:27:28.985: RADIUS: Framed-Protocol [7] 6 PPP [1] Jun 14 12:27:28.985: RADIUS: Framed-Route [22] 12 "1.1.1.1/32" Jun 14 12:27:28.985: RADIUS: Vendor, Cisco [26] 86 Jun 14 12:27:28.985: RADIUS: Cisco AVpair [1] 80 "lcp:interface-config=ip vrf forwarding V1.33.com \n ip unnumbered loopback 33" Jun 14 12:27:28.985: RADIUS(0000008B): Received from id 21645/182 Jun 14 12:27:28.985: AAA/SG/REF_COUNT decreased ref count of server CF000005 to 3 Jun 14 12:27:28.989: ppp136 PPP/AAA: Check Attr: service-type Jun 14 12:27:28.989: ppp136 PPP/AAA: Check Attr: Framed-Protocol Jun 14 12:27:28.989: ppp136 PPP/AAA: Check Attr: route:Peruser Jun 14 12:27:28.989: ppp136 PPP/AAA: Check Attr: interface-config:Peruser I/F Jun 14 12:27:28.989: AAA/MLIST Ref count of of mlist 0x600000B lowered to 1 Jun 14 12:27:28.989: VT:Sending vaccess request, id 0x7200010B Jun 14 12:27:28.989: VT:Processing vaccess requests, 1 outstanding Jun 14 12:27:28.989: VT:Create and clone interface, Vt10 Jun 14 12:27:28.989: VT[Vi4]:Reuse interface, recycle queue size 2 Jun 14 12:27:28.989: VT[Vi4]:Cloning a recycled vaccess Jun 14 12:27:28.989: VT[Vi4]:Processing vaccess response, id 0x7200010B, result success (1) Jun 14 12:27:28.989: Vi4: Binding template V1.33.com Jun 14 12:27:28.989: AAA/BIND: Bind Virtual-Access4 to uid:139 (ccb:0x63EF9738) Jun 14 12:27:28.993: %LINK-3-UPDOWN: Interface Virtual-Access4, changed state to up Jun 14 12:27:28.993: Vi4 AAA/AUTHOR/LCP: Process Author Jun 14 12:27:28.993: Vi4 AAA/AUTHOR/LCP: Process Attr: interface-config Jun 14 12:27:28.993: AAA/AUTHOR: Processing PerUser AV interface-config Jun 14 12:27:28.993: Vi4 AAA/AUTHOR/LCP: Process Attr: interface-config Jun 14 12:27:28.993: Vi4 AAA/AUTHOR/LCP: IF_config: ip vrf forwarding V1.33.com \n ip unnumbered loopback 33 Jun 14 12:27:28.993: VT[Vi3]:Reuse interface, recycle queue size 1 Jun 14 12:27:28.993: VT[Vi3]:Vaccess created Jun 14 12:27:28.993: VT[Vi3]:Created unnumbered vaccess Jun 14 12:27:28.997: VT[Vi3]:Bringing up interface Jun 14 12:27:28.997: Vi3 AAA/AUTHOR/LCP: Authorization succeeds trivially Jun 14 12:27:29.001: %LINK-3-UPDOWN: Interface Virtual-Access3, changed state to up Jun 14 12:27:29.001: AAA/MLIST Ref count of of mlist 0x62D905E4 raised to 2 Jun 14 12:27:29.001: AAA/MLIST Ref count of of mlist 0x62D905E4 raised to 3 Jun 14 12:27:29.001: Vi3 AAA/AUTHOR/IPCP: FSM authorization not needed Jun 14 12:27:29.001: Vi3 AAA/AUTHOR/FSM: We can start IPCP Jun 14 12:27:29.001: RADIUS/ENCODE(0000008B): Unsupported AAA attribute start_time Jun 14 12:27:29.001: RADIUS/ENCODE(0000008B): Unsupported AAA attribute timezone Jun 14 12:27:29.001: RADIUS/ENCODE(0000008B): Unsupported AAA attribute start_time Jun 14 12:27:29.001: RADIUS: Pick NAS IP 32.1.33.241 (uid:139) from source config Jun 14 12:27:29.001: RADIUS(0000008B): sending Jun 14 12:27:29.001: Vi3 AAA/AUTHOR/IPCP: Start. Her address 0.0.0.0, we want 32.1.33.10 Jun 14 12:27:29.001: Vi3 AAA/AUTHOR/IPCP: Processing AV route Jun 14 12:27:29.001: Vi3 AAA/AUTHOR/IPCP: Authorization succeeded Jun 14 12:27:29.001: Vi3 AAA/AUTHOR/IPCP: Done. Her address 0.0.0.0, we want 32.1.33.10 Jun 14 12:27:29.001: AAA/SG/REF_COUNT refcount of server CF000005 increased to 4 Jun 14 12:27:29.001: RADIUS(0000008B): Send to unknown id 21645/183 10.10.132.4:1646, Accounting-Request, len 203 Jun 14 12:27:29.001: RADIUS: authenticator C3 19 4C 21 08 76 11 AC - FF F8 DB AE 76 A4 81 BB Jun 14 12:27:29.001: RADIUS: Acct-Session-Id [44] 10 "000000B8" Jun 14 12:27:29.001: RADIUS: Tunnel-Server-Endpoi[67] 14 00:"10.10.104.9" Jun 14 12:27:29.001: RADIUS: Tunnel-Client-Endpoi[66] 15 00:"10.10.104.22" Jun 14 12:27:29.001: RADIUS: Tunnel-Assignment-Id[82] 8 00:"V1.33" Jun 14 12:27:29.001: RADIUS: Acct-Tunnel-Connecti[68] 12 "3990802017" Jun 14 12:27:29.001: RADIUS: Tunnel-Client-Auth-I[90] 16 00:"c53d9-1-V1.33" Jun 14 12:27:29.001: RADIUS: Tunnel-Server-Auth-I[91] 10 00:"c72d9-1" Jun 14 12:27:29.001: RADIUS: Framed-Protocol [7] 6 PPP [1] Jun 14 12:27:29.001: RADIUS: Authentic [45] 6 RADIUS [1] Jun 14 12:27:29.001: RADIUS: Acct-Status-Type [40] 6 Start [1] Jun 14 12:27:29.001: RADIUS: User-Name [1] 26 "U0001N1P3V1.33@V1.33.com" Jun 14 12:27:29.001: RADIUS: Multilink-Session-ID[50] 10 "0000008C" Jun 14 12:27:29.001: RADIUS: Acct-Link-Count [51] 6 1 Jun 14 12:27:29.001: RADIUS: NAS-Port-Type [61] 6 Virtual [5] Jun 14 12:27:29.001: RADIUS: Called-Station-Id [30] 8 "311033" Jun 14 12:27:29.001: RADIUS: Service-Type [6] 6 Framed [2] Jun 14 12:27:29.005: RADIUS: NAS-IP-Address [4] 6 32.1.33.241 Jun 14 12:27:29.005: RADIUS: Event-Timestamp [55] 6 1024057649 Jun 14 12:27:29.005: RADIUS: Acct-Delay-Time [41] 6 0 Jun 14 12:27:29.013: AAA/AUTHOR: Processing PerUser AV route Jun 14 12:27:29.013: AAA/PER-USER: command = [ip route vrf V1.33.com 1.1.1.1 255.255.255.255 32.1.33.10 ] Jun 14 12:27:29.013: AAA/PER-USER: line = [ip route vrf V1.33.com 1.1.1.1 255.255.255.255 32.1.33.10] Jun 14 12:27:29.017: AAA/AUTHOR: increment ref cnt for ip route 1.1.1.1 255.255.255.255 32.1.33.10 to 8 Jun 14 12:27:29.041: RADIUS: Received from id 21645/183 10.10.132.4:1646, Accounting-response, len 20 Jun 14 12:27:29.041: RADIUS: authenticator 5A 21 1C F0 FF EE FA FC - 90 A7 5C D5 1F 27 E2 6F Jun 14 12:27:29.041: AAA/SG/REF_COUNT decreased ref count of server CF000005 to 3 Jun 14 12:27:29.041: AAA/MLIST Ref count of of mlist 0x6A000010 lowered to 2 Jun 14 12:27:29.993: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access4, changed state to up Jun 14 12:27:30.001: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access3, changed state to up


hometocprevnextglossaryfeedbacksearchhelp
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.