This document presents a configuration example in which Virtual Private Dialup Network (VPDN) Layer 2 Tunneling Protocol (L2TP) is configured for ISDN and analog dialin calls. There is no Authentication, Authorization, and Accounting (AAA) server involved in this setup.
L2TP is an Internet Engineering Task Force (IETF) standard that combines the best features of two existing tunneling protocols:
Cisco Layer 2 Forwarding (L2F)
Microsoft Point-to-Point Tunneling Protocol (PPTP)
In this setup, we are using L2TP by adding the command protocol L2TP. L2F is the default.
Cisco recommends that you use the command vpdn-group, introduced in Cisco IOS® Software Release 12.0(1)T, to define the VPDN parameters in both L2TP Access Concentrator (LAC) and L2TP Network Server (LNS). However, if you want to use the commands vpdn incoming and vpdn outgoing, please refer to Configuring Virtual Private Dialup Networks.
The main characteristics of this setup are as follows:
The LAC:
identifies a VPDN client based on the domain name received in the authentication (Challenge Handshake Authentication Protocol [CHAP] in this setup) response.
uses its local VPDN parameters to bring up the tunnel and the session with the LNS.
The LNS:
uses its local VPDN parameters to accept the VPDN tunnel and session from the LAC.
authenticates the remote user locally.
assigns an IP address from its local pool to the client.
This configuration was developed and tested using the software and hardware versions below.
Cisco IOS Software Release 12.2 Main line. The IP+ feature is required for VPDN.
A Cisco AS5300 (the LAC) with an E1 card and a Mica card. It can accept ISDN and analog calls.
The information presented in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If you are working in a live network, ensure that you understand the potential impact of any command before using it.
Refer to Cisco Technical Tips Conventions for more information on document conventions.
In this section, you are presented with the information to configure the features described in this document.
Note: Use the Command Lookup Tool (registered customers only) to find more information on the commands used in this document.
This document uses this network setup:
LAC |
---|
version 12.2 service timestamps debug datetime msec service timestamps log datetime msec ! hostname LAC ! spe 2/0 2/9 firmware location system:/ucode/mica_port_firmware ! ! modem country mica belgium ! vpdn enable ! -- Enables VPDN. ! vpdn search-order domain ! -- VPDN tunnel authorization is based on the domain name ! -- (the default is DNIS). ! vpdn-group GroupCisco request-dialin protocol l2tp ! -- L2TP is used instead of the default (L2F). domain cisco.com ! -- The domain name cisco.com is used to identify a VPDN user when ! -- receiving the CHAP response from the user. initiate-to ip 10.48.74.35 ! -- The tunnel and session are initialized to the ethernet ip address of the ! -- LNS 10.48.74.35. l2tp tunnel password cisco ! -- for tunnel authentication ! isdn switch-type primary-net5 ! controller E1 0 clock source line primary pri-group timeslots 1-31 ! interface Ethernet0 ip address 10.48.75.7 255.255.254.0 ! interface Serial0:15 no ip address encapsulation ppp dialer rotary-group 1 isdn switch-type primary-net5 isdn incoming-voice modem ! interface Group-Async1 no ip address encapsulation ppp async mode dedicated ppp authentication chap pap group-range 1 120 ! interface Dialer1 no ip address encapsulation ppp ppp authentication chap pap ! ip classless ip route 0.0.0.0 0.0.0.0 10.48.74.1 ! line con 0 exec-timeout 0 0 line 1 120 modem InOut transport input all line aux 0 line vty 0 4 exec-timeout 0 0 password cisco login ! |
LNS |
---|
version 12.2 service timestamps debug datetime msec service timestamps log datetime msec ! hostname LNS ! username UserISDN@cisco.com password 0 cisco username UserAnalog@cisco.com password 0 cisco ! -- The LNS authenticates the remote users locally. ! vpdn enable ! -- Enables VPDN. ! vpdn-group VPDN accept-dialin ! -- Enables the LNS to accept VPDN request. protocol l2tp !-- L2TP is used instead of the L2F (default). virtual-template 1 ! -- For each user, the virtual-template 1 is used to terminate the PPP session. terminate-from hostname LAC ! -- The LNS accepts VPDN request from router LAC. l2tp tunnel password cisco ! -- for tunnel authentication ! ! ! ! interface Loopback1 ip address 12.12.12.1 255.255.255.255 no ip route-cache no ip mroute-cache ! interface Ethernet0 ip address 10.48.74.35 255.255.254.0 no ip route-cache no ip mroute-cache no cdp enable ! interface Virtual-Template1 ! -- The PPP session is terminated in the virtual-access cloned from this ! -- virtual-template ip unnumbered Loopback1 peer default ip address pool GroupCisco ppp authentication chap pap ! ip local pool GroupCisco 12.12.12.2 12.12.12.50 ! -- The LNS assigns an ip address to the remote user ip classless ip route 0.0.0.0 0.0.0.0 10.48.74.1 |
Note: In the configurations above, we have configured the dialer 1 and group-async1 interfaces with the minimum Point to Point Protocol (PPP) options.
To allow more functionalities at PPP level (ppp multilink, compression, and so on), you need to add these functionalities on those interfaces and on the virtual-template 1 of the LNS.
Important: The rule is that all PPP options you define in the dialer 1 and group-async1 interfaces have to be configured in the virtual-template 1 of the LNS.
The virtual-template 1 receives a "copy" of LCP options negotiated between the LAC and the client. If an option that has been negotiated between the LAC and the client is not configured in the virtual-template 1, then the LNS clears the VPDN session. However, to allow the LNS to renegotiate the LCP with the client, set the commands lcp renegotiation always or lcp renegotiation on-mismatch in the VPDN group.
Note: By default, the LAC and the LNS use their hostname in the L2TP exchange packets. To modify this behaviour, define the command local name in the vpdn-group. Let's look at an example of an LNS configuration:
vpdn-group VPDN accept-dialin protocol l2tp virtual-template 1 terminate-from hostname LAC local name LNS-cental
This section provides information you can use to confirm your configuration is working properly.
The Output Interpreter Tool (registered customers only) (OIT) supports certain show commands. Use the OIT to view an analysis of show command output.
show vpdn tunnel — Displays information about all active L2F and L2TP tunnels in summary-style format.
show caller ip — Displays a summary of caller information for the IP address you provide.
This section provides information you can use to troubleshoot your configuration.
Note: Refer to Important Information on Debug Commands before you use debug commands.
On the LAC:
debug vpdn event — Displays L2TP errors and events that are a part of normal tunnel establishment or shutdown for VPDNs.
debug vpdn l2x-event — Displays messages about events that are part of normal tunnels establishment or shutdown for 12x.
debug vpdn l2x-error — Displays l2x protocol errors that prevent l2x establishment or prevent its normal operation.
debug ppp negotiation — Causes the debug ppp command to display PPP packets transmitted during PPP startup, where PPP options are negotiated.
debug isdn q931 — Displays information about call setup and teardown of ISDN network connections (Layer 3) between the local router (user side) and the network.
debug modem — Displays modem line activity on an access server.
On the LNS:
debug vpdn event
debug vpdn l2x-event
debug vpdn l2x-error
debug vtemplate — Displays cloning information for a virtual access interface from the time it is cloned from a virtual template to the time the virtual access interface comes down when the call ends.
debug ppp negotiation
Below is an ISDN call from the client UserISDN@cisco.com.
debug Commands on the LAC
The LAC receives an ISDN call from the number 8101.
LAC# *Feb 1 14:45:09.684: ISDN Se0:15: RX <- SETUP pd = 8 callref = 0x3D03 *Feb 1 14:45:09.688: Sending Complete *Feb 1 14:45:09.688: Bearer Capability i = 0x8890 *Feb 1 14:45:09.688: Channel ID i = 0xA18387 *Feb 1 14:45:09.688: Calling Party Number i = 0xA1, '8101', Plan:ISDN, Type:National *Feb 1 14:45:09.688: Called Party Number i = 0x81, '214', Plan:ISDN, Type:Unknown *Feb 1 14:45:09.692: %LINK-3-UPDOWN: Interface Serial0:6, changed state to up *Feb 1 14:45:09.692: Se0:6 PPP: Treating connection as a callin *Feb 1 14:45:09.692: Se0:6 PPP: Phase is ESTABLISHING, Passive Open [0 sess, 0 load] *Feb 1 14:45:09.692: Se0:6 LCP: State is Listen *Feb 1 14:45:09.696: ISDN Se0:15: TX -> CALL_PROC pd = 8 callref = 0xBD03 *Feb 1 14:45:09.696: Channel ID i = 0xA98387 *Feb 1 14:45:09.696: ISDN Se0:15: TX -> CONNECT pd = 8 callref = 0xBD03 *Feb 1 14:45:09.696: Channel ID i = 0xA98387 ! -- The ISDN phase is finished and the B channel is up ! -- as soon as the LAC receives RX <- CONNECT_ACK. *Feb 1 14:45:09.752: ISDN Se0:15: RX <- CONNECT_ACK pd = 8 callref = 0x3D03 *Feb 1 14:45:09.752: ISDN Se0:15: CALL_PROGRESS: CALL_CONNECTED call id 0x90, bchan 6, dsl 0 ! -- PPP starts with LCP phase : authentication protocol and other LCP ! -- options (compression, multilink, and so on) are negotiated. ! -- In the debug below, only chap is negotiated. *Feb 1 14:45:09.844: Se0:6 LCP: I CONFREQ [Listen] id 179 len 10 *Feb 1 14:45:09.844: Se0:6 LCP: MagicNumber 0x5B90B785 (0x05065B90B785) *Feb 1 14:45:09.844: Se0:6 LCP: O CONFREQ [Listen] id 1 len 15 *Feb 1 14:45:09.844: Se0:6 LCP: AuthProto CHAP (0x0305C22305) *Feb 1 14:45:09.844: Se0:6 LCP: MagicNumber 0x1A9DC8A5 (0x05061A9DC8A5) *Feb 1 14:45:09.844: Se0:6 LCP: O CONFACK [Listen] id 179 len 10 *Feb 1 14:45:09.844: Se0:6 LCP: MagicNumber 0x5B90B785 (0x05065B90B785) *Feb 1 14:45:09.876: Se0:6 LCP: I CONFACK [ACKsent] id 1 len 15 *Feb 1 14:45:09.876: Se0:6 LCP: AuthProto CHAP (0x0305C22305) *Feb 1 14:45:09.876: Se0:6 LCP: MagicNumber 0x1A9DC8A5 (0x05061A9DC8A5) *Feb 1 14:45:09.876: Se0:6 LCP: State is Open *Feb 1 14:45:09.876: Se0:6 PPP: Phase is AUTHENTICATING, by this end [0 sess, 0 load] ! -- The LAC sends the client a CHAP challenge. *Feb 1 14:45:09.876: Se0:6 CHAP: O CHALLENGE id 1 len 24 from "LAC". ! -- The LAC receives the CHAP response from the client with username ! -- UserISDN@cisco.com. *Feb 1 14:45:09.924: Se0:6 CHAP: I RESPONSE id 1 len 39 from "UserISDN@cisco.com" ! -- The LAC checks out if UserISDN@cisco.com is a VPDN client or not. ! -- Because the domain cisco.com is configured in the vpdn-group ! -- GroupCisco, UserISDN@cisco.com is a VPDN client. The LAC takes ! -- the VPDN parameters in the vpdn-group where the domain name ! -- cisco.com is located. *Feb 1 14:45:09.924: Se0:6 PPP: Phase is FORWARDING [0 sess, 0 load] *Feb 1 14:45:09.924: Se0:6 VPDN: Got DNIS string 214 *Feb 1 14:45:09.924: Se0:6 VPDN: Looking for tunnel -- cisco.com -- *Feb 1 14:45:09.928: Se0:6 VPDN/RPMS/GroupCisco: Got tunnel info for cisco.com *Feb 1 14:45:09.928: Se0:6 VPDN/RPMS/GroupCisco: LAC *Feb 1 14:45:09.928: Se0:6 VPDN/RPMS/GroupCisco: l2tp-busy-disconnect yes *Feb 1 14:45:09.928: Se0:6 VPDN/RPMS/GroupCisco: IP 10.48.74.35 *Feb 1 14:45:09.928: Se0:6 VPDN/GroupCisco: curlvl 1 Address 0: 10.48.74.35, priority 1 *Feb 1 14:45:09.928: Se0:6 VPDN/GroupCisco: Select non-active address 10.48.74.35, priority 1 *Feb 1 14:45:09.928: Se0:6 VPDN: Find LNS process created *Feb 1 14:45:09.928: Tnl 2027 L2TP: SM State idle ! -- In order to bring up the tunnel, the LAC sends SCCRQ (Start Control ! -- Connection Request) to the LNS. ! -- A CHAP challenge is included in the packet. *Feb 1 14:45:09.928: Tnl 2027 L2TP: O SCCRQ *Feb 1 14:45:09.928: Tnl 2027 L2TP: Tunnel state change from idle to wait-ctl-reply *Feb 1 14:45:09.928: Tnl 2027 L2TP: SM State wait-ctl-reply *Feb 1 14:45:09.928: Se0:6 VPDN: Forward to address 10.48.74.35 *Feb 1 14:45:09.928: Se0:6 VPDN: Pending *Feb 1 14:45:09.932: Se0:6 VPDN: Process created ! -- The LAC receives from the LNS SCCRP (Start Control Connection Reply). ! -- The response to its own chalenge and another chap chalenge from the LNS ! -- are included in the packet. *Feb 1 14:45:09.956: Tnl 2027 L2TP: I SCCRP from LNS *Feb 1 14:45:09.956: Tnl 2027 L2TP: Got a challenge from remote peer, LNS *Feb 1 14:45:09.956: Tnl 2027 L2TP: Got a response from remote peer, LNS *Feb 1 14:45:09.956: Tnl 2027 L2TP: Tunnel Authentication success *Feb 1 14:45:09.956: Tnl 2027 L2TP: Tunnel state change from wait-ctl-reply to established ! -- The LAC sends to the LNS SCCCN (Start Control Connection Connected). ! -- The response to LNS's challenge is included in the packet. *Feb 1 14:45:09.956: Tnl 2027 L2TP: O SCCCN to LNS tnlid 11514 *Feb 1 14:45:09.956: Tnl 2027 L2TP: SM State established *Feb 1 14:45:09.956: Se0:6 VPDN: Forwarding... *Feb 1 14:45:09.956: Se0:6 VPDN: Bind interface direction=1 *Feb 1 14:45:09.956: Tnl/Cl 2027/18 L2TP: Session FS enabled *Feb 1 14:45:09.956: Tnl/Cl 2027/18 L2TP: Session state change from idle to wait-for-tunnel *Feb 1 14:45:09.960: Se0:6 Tnl/Cl 2027/18 L2TP: Create session *Feb 1 14:45:09.960: Tnl 2027 L2TP: SM State established ! -- The Tunnel is up. The LAC brings up the session for the user ! -- UserISDN@cisco.com. For that, it sends ICRQ (Incoming Call ReQuest). *Feb 1 14:45:09.960: Se0:6 Tnl/Cl 2027/18 L2TP: O ICRQ to LNS 11514/0 *Feb 1 14:45:09.960: Se0:6 Tnl/Cl 2027/18 L2TP: Session state change from wait-for-tunnel to wait-reply *Feb 1 14:45:09.960: Se0:6 VPDN: UserISDN@cisco.com is forwarded ! -- After receiving ICRP (Incoming Call Reply, we don't see it in the debug) ! -- the LAC sends ICCN Incoming Call Connected. The VPDN session is up . ! -- Then the LAC forwards to the LNS what it has negotiated with the client ! -- (LCP options) along with the username and chap password of the client. *Feb 1 14:45:10.008: Se0:6 Tnl/Cl 2027/18 L2TP: O ICCN to LNS 11514/6 *Feb 1 14:45:10.008: Se0:6 Tnl/Cl 2027/18 L2TP: Session state change from wait-reply to established *Feb 1 14:45:10.960: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0:6, changed state to up *Feb 1 14:45:15.692: %ISDN-6-CONNECT: Interface Serial0:6 is now connected to 8101 UserISDN@cisco.com LAC#
debug Commands on the LNS
The LNS receives SCCRQ from LAC.
LNS# *Mar 1 02:13:06.499: L2TP: I SCCRQ from LAC tnl 2027 *Mar 1 02:13:06.507: Tnl 11514 L2TP: Got a challenge in SCCRQ, LAC *Mar 1 02:13:06.511: Tnl 11514 L2TP: New tunnel created for remote LAC, address 10.48.75.7 ! -- The LNS replies with SCCRP which includes the CHAP response to LAC's ! -- challenge and a CHAP challenge. *Mar 1 02:13:06.515: Tnl 11514 L2TP: O SCCRP to LAC tnlid 2027 *Mar 1 02:13:06.523: Tnl 11514 L2TP: Tunnel state change from idle to wait-ctl-reply ! -- The LNS receives SCCCN. *Mar 1 02:13:06.535: Tnl 11514 L2TP: I SCCCN from LAC tnl 2027 *Mar 1 02:13:06.539: Tnl 11514 L2TP: Got a Challenge Response in SCCCN from LAC *Mar 1 02:13:06.543: Tnl 11514 L2TP: Tunnel Authentication success *Mar 1 02:13:06.543: Tnl 11514 L2TP: Tunnel state change from wait-ctl-reply to established *Mar 1 02:13:06.547: Tnl 11514 L2TP: SM State established ! -- The tunnel is up. The LNS receives ICRQ to bring up the session. *Mar 1 02:13:06.555: Tnl 11514 L2TP: I ICRQ from LAC tnl 2027 *Mar 1 02:13:06.559: Tnl/Cl 11514/6 L2TP: Session FS enabled *Mar 1 02:13:06.563: Tnl/Cl 11514/6 L2TP: Session state change from idle to wait-connect *Mar 1 02:13:06.567: Tnl/Cl 11514/6 L2TP: New session created ! -- The LNS replies with ICRP (Incoming Call Reply). *Mar 1 02:13:06.567: Tnl/Cl 11514/6 L2TP: O ICRP to LAC 2027/18 ! -- The LNS receives ICCN (Incoming Call coNnected). The VPDN sesion is up, ! -- then the LNS receives the LCP layer along with the username ! -- and chap password of the client. ! -- A virtual-access is cloned from the virtual-template 1. *Mar 1 02:13:06.583: Tnl/Cl 11514/6 L2TP: I ICCN from LAC tnl 2027, cl 18 *Mar 1 02:13:06.591: Tnl/Cl 11514/6 L2TP: Session state change from wait-connect to established *Mar 1 02:13:06.591: Vt1 VTEMPLATE: Unable to create and clone vaccess *Mar 1 02:13:06.595: Vi1 VTEMPLATE: Reuse Vi1, recycle queue size 1 *Mar 1 02:13:06.595: Vi1 VTEMPLATE: Hardware address 0000.0c4a.4314 *Mar 1 02:13:06.599: Vi1 VPDN: Virtual interface created for UserISDN@cisco.com *Mar 1 02:13:06.603: Vi1 PPP: Phase is DOWN, Setup [0 sess, 0 load] *Mar 1 02:13:06.603: Vi1 VPDN: Clone from Vtemplate 1 filterPPP=0 blocking *Mar 1 02:13:06.607: Vi1 VTEMPLATE: Has a new cloneblk vtemplate, now it has vtemplate *Mar 1 02:13:06.611: Vi1 VTEMPLATE: ************* CLONE VACCESS1 ***************** *Mar 1 02:13:06.615: Vi1 VTEMPLATE: Clone from Virtual-Template1 interface Virtual-Access1 default ip address no ip address encap ppp ip unnumbered Loopback1 end *Mar 1 02:13:07.095: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to up *Mar 1 02:13:07.099: Vi1 PPP: Using set call direction *Mar 1 02:13:07.103: Vi1 PPP: Treating connection as a callin *Mar 1 02:13:07.103: Vi1 PPP: Phase is ESTABLISHING, Passive Open [0 sess, 0 load] *Mar 1 02:13:07.107: Vi1 LCP: State is Listen *Mar 1 02:13:07.111: Vi1 VPDN: Bind interface direction=2 *Mar 1 02:13:07.111: Vi1 LCP: I FORCED CONFREQ len 11 *Mar 1 02:13:07.115: Vi1 LCP: AuthProto CHAP (0x0305C22305) *Mar 1 02:13:07.119: Vi1 LCP: MagicNumber 0x1A9DC8A5 (0x05061A9DC8A5) *Mar 1 02:13:07.119: Vi1 VPDN: PPP LCP accepted rcv CONFACK *Mar 1 02:13:07.123: Vi1 LCP: I FORCED CONFACK len 6 *Mar 1 02:13:07.127: Vi1 LCP: MagicNumber 0x5B90B785 (0x05065B90B785) *Mar 1 02:13:07.131: Vi1 VPDN: PPP LCP accepted sent CONFACK ! -- The LNS authenticates the user. It doesn't send a new CHAP challenge ! -- (the debug may be confusing) since it has received the CHAP challenge ! -- and response from the LAC. *Mar 1 02:13:07.131: Vi1 PPP: Phase is AUTHENTICATING, by this end [0 sess, 0 load] *Mar 1 02:13:07.135: Vi1 CHAP: O CHALLENGE id 2 len 24 from "LNS" *Mar 1 02:13:07.143: Vi1 CHAP: I RESPONSE id 1 len 39 from "UserISDN@cisco.com" *Mar 1 02:13:07.151: Vi1 CHAP: O SUCCESS id 1 len 4 *Mar 1 02:13:07.155: Vi1 PPP: Phase is UP [0 sess, 0 load] ! -- The IPCP phase starts. ! -- The IP address 12.12.12.2 is assigned to the client. *Mar 1 02:13:07.159: Vi1 IPCP: O CONFREQ [Closed] id 1 len 10 *Mar 1 02:13:07.163: Vi1 IPCP: Address 12.12.12.1 (0x03060C0C0C01) *Mar 1 02:13:07.215: Vi1 IPCP: I CONFREQ [REQsent] id 34 len 10 *Mar 1 02:13:07.219: Vi1 IPCP: Address 0.0.0.0 (0x030600000000) *Mar 1 02:13:07.223: Vi1 IPCP: Pool returned 12.12.12.2 *Mar 1 02:13:07.227: Vi1 IPCP: O CONFNAK [REQsent] id 34 len 10 *Mar 1 02:13:07.231: Vi1 IPCP: Address 12.12.12.2 (0x03060C0C0C02) *Mar 1 02:13:07.235: Vi1 IPCP: I CONFACK [REQsent] id 1 len 10 *Mar 1 02:13:07.239: Vi1 IPCP: Address 12.12.12.1 (0x03060C0C0C01) *Mar 1 02:13:07.271: Vi1 IPCP: I CONFREQ [ACKrcvd] id 35 len 10 *Mar 1 02:13:07.275: Vi1 IPCP: Address 12.12.12.2 (0x03060C0C0C02) *Mar 1 02:13:07.279: Vi1 IPCP: O CONFACK [ACKrcvd] id 35 len 10 *Mar 1 02:13:07.283: Vi1 IPCP: Address 12.12.12.2 (0x03060C0C0C02) *Mar 1 02:13:07.287: Vi1 IPCP: State is Open *Mar 1 02:13:07.295: Vi1 IPCP: Install route to 12.12.12.2 ! -- The virtual-access is up. *Mar 1 02:13:08.159: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access1, changed state to up LNS#
show Commands
LAC#show vpdn tunnel L2TP Tunnel Information Total tunnels 1 sessions 1 LocID RemID Remote Name State Remote Address Port Sessions 36556 45655 LNS est 10.48.74.35 1701 1 %No active L2F tunnels %No active PPTP tunnels %No active PPPoE tunnels LAC#
LNS#show vpdn tunnel L2TP Tunnel Information Total tunnels 1 sessions 1 LocID RemID Remote Name State Remote Address Port Sessions 45655 36556 LAC est 10.48.75.7 1701 1 %No active L2F tunnels %No active PPTP tunnels %No active
LNS#show caller ip Line User IP Address Local Number Remote Number <-> Vi1 UserISDN@cisco.com \ 12.12.12.2 214 8101 in LNS#
Revision | Publish Date | Comments |
---|---|---|
1.0 |
09-Sep-2005 |
Initial Release |