Inhoud

Inleiding

Voorwaarden

Gebruikte componenten

Conventies

Configureren

Netwerkdiagram

Configuraties

Verifiëren

Problemen oplossen

Opdrachten voor troubleshooting

Gerelateerde informatie

Inleiding

Dit document geeft een configuratievoorbeeld in waarin Virtual Private Dialup Network (VPDN) Layer 2 Tunneling Protocol (L2TP) is geconfigureerd voor ISDN en analoge dialoogvenster. Er is geen AAA-server (verificatie, autorisatie en accounting) betrokken bij deze installatie.

L2TP is een IETF-standaard (Internet Engineering Task Force) die de beste functies van twee bestaande tunnelprotocollen combineert:

- Cisco Layer 2 Forwarding (L2F)

- Microsoft Point-to-Point Tunneling Protocol (PPTP)

In deze instelling gebruiken we L2TP door het opdrachtprotocol L2TP toe te voegen. L2F is de standaard.

Cisco raadt u aan om de opdracht vPDN-groep te gebruiken, die in Cisco IOS-softwarerelease 12.0(1)T is geïntroduceerd, om de VPDN-parameters te definiëren in zowel L2TP access Concentrator (LAC) als L2TP Network Server (LNS). Als u echter de opdrachten vpdn inkomend en uitgaande vpdn wilt gebruiken, raadpleegt u Virtual Private Dialup-netwerken configureren.

De belangrijkste kenmerken van deze instelling zijn:

- DE LAC:

- identificeert een VPDN-client op basis van de domeinnaam die in de verificatie is ontvangen (Challenge Handshake Authentication Protocol [CHAP] in deze instelling).

- gebruikt zijn lokale VPDN-parameters om de tunnel en de sessie met de LNS te vergroten.

- De LNS:

- gebruikt zijn lokale VPDN-parameters om de VPDN-tunnel en -sessie van de LAC te accepteren.

- verklaart de afstandsgebruiker plaatselijk voor authentiek.

- wijst een IP adres van zijn lokale pool aan de client toe.

Voorwaarden

Gebruikte componenten

Deze configuratie is ontwikkeld en getest met behulp van de onderstaande software- en hardwareversies.

- Cisco IOS-softwarerelease 12.2 hoofdlijn De functie IP+ is vereist voor VPDN.

- Een Cisco AS5300 (de LAC) met een E1 kaart en een MICA-kaart. Het kan ISDN en analoge oproepen accepteren.

De informatie in dit document is gebaseerd op apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als u in een levend netwerk werkt, zorg er dan voor dat u de potentiële impact van om het even welke opdracht begrijpt alvorens het te gebruiken.

Conventies

Raadpleeg Cisco Technical Tips Conventions (Conventies voor technische tips van Cisco) voor meer informatie over documentconventies.

Configureren

Deze sectie bevat informatie over het configureren van de functies die in dit document worden beschreven.

N.B.: Gebruik het Opdrachtupgereedschap (alleen geregistreerde klanten) om meer informatie te vinden over de opdrachten die in dit document worden gebruikt.

Netwerkdiagram

Het netwerk in dit document is als volgt opgebouwd:

Configuraties

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

Opmerking: In de bovenstaande configuraties hebben we de opties dialer 1 en groepsasync1 met de opties Point to Point Protocol (PPP) ingesteld.

Om meer functies op PPP niveau (PPP multilink, compressie, enz.) toe te staan, moet u deze functies op die interfaces en op virtueel-sjabloon 1 van de LNS toevoegen.

Belangrijk: De regel is dat alle opties PPP die u in dialer 1 en de groep-async1 interfaces definieert in virtueel-sjabloon 1 van de LNS moeten worden geconfigureerd.

The Virtual-sjabloon 1 ontvangt een "kopie" van LCP-opties die zijn overeengekomen tussen de LAC en de client. Als een optie die tussen de LAC en de client is onderhandeld, niet is ingesteld in virtueel-sjabloon 1, dan verwijdert de LNS de VPDN-sessie. Echter, om de LNS toe te staan om opnieuw te onderhandelen over de LCP met de client, stelt u de opdrachten in, lcp heronderhandeling altijd of lcp heronderhandeling op een mismatch in de VPDN-groep.

Opmerking: Standaard gebruiken LAC en LNS hun hostname in de L2TP-pakketten. Om dit gedrag aan te passen, definieer de opdracht lokale naam in de vpdn-groep. Laten we een voorbeeld nemen van een LNS-configuratie:

vpdn-group VPDN

accept-dialin

protocol l2tp

virtual-template 1

terminate-from hostname LAC

local name LNS-cental

Verifiëren

Deze sectie verschaft informatie die u kunt gebruiken om te bevestigen dat uw configuratie correct werkt.

Het Uitvoer Tolk (uitsluitend geregistreerde klanten) (OIT) ondersteunt bepaalde show opdrachten. Gebruik de OIT om een analyse van tonen opdrachtoutput te bekijken.

- vpdn-tunnel — Informatie over alle actieve L2F- en L2TP-tunnels in snelstijl weergeven.

- IP van de bezoeker tonen — Toont een samenvatting van de telefooninformatie voor het IP adres dat u verschaft.

Problemen oplossen

Deze sectie bevat informatie waarmee u problemen met de configuratie kunt oplossen.

Opdrachten voor troubleshooting

Opmerking: Raadpleeg Important Information on Debug Commands (Belangrijke informatie over opdrachten met debug) voordat u opdrachten met debug opgeeft.

Op de LAC:

- debug VPDN-gebeurtenis — Hiermee worden L2TP-fouten en -gebeurtenissen weergegeven die deel uitmaken van een normale tunnelinstelling of afsluiten voor VPDN’s.

- debug vpdn l2x-event — Beeldingen van gebeurtenissen die deel uitmaken van een normale tunnelvestiging of shutdown voor 12x.

- debug vpdn l2x-fout — Hiermee worden l2x-protocolfouten weergegeven die een l2x-instelling voorkomen of de normale werking ervan verhinderen.

- debug PPP onderhandeling — veroorzaakt het debug ppp bevel om PPP pakketten te tonen die tijdens PPP opstarten worden verzonden, waar PPP opties worden besproken.

- debug ISDN Q931 — Informatie over installatie bij oproepen en verwijdering van ISDN-netwerkverbindingen (Layer 3) tussen de lokale router (gebruikerszijde) en het netwerk.

- debug-modemactiviteit — Hiermee wordt modemactiviteit op een toegangsserver weergegeven.

Op de LNS:

- debug van VPN-gebeurtenis

- debug vpdn l2x-gebeurtenis

- bug van VPN l2x

- debug Vsjabloon — Hier wordt informatie over klonen weergegeven voor een virtuele toegangsinterface vanaf het moment dat de sjabloon wordt gekloond vanaf een virtuele sjabloon tot het moment dat de virtuele toegangsinterface afloopt wanneer de oproep stopt.

- debug van PPP-onderhandeling

Hieronder staat een ISDN-oproep van de client UserISDN@cisco.com.

zuiveren Opdrachten op de LAC

De LAC ontvangt een ISDN-oproep van het nummer 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#

zuiveren Opdrachten op de LNS

LNS ontvangt SCCRQ van 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#

tonen Opdrachten

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#

Gerelateerde informatie

- Ondersteuning van inbel- en toegangstechnologie

- Technische ondersteuning en documentatie – Cisco Systems