You are on page 1of 0

Cisco Press

800 E 96th Street


Indianapolis, IN 46240 USA

Cisco Press

Troubleshooting Virtual Private
Networks

Mark Lewis, CCIE No. 6280

FrontMatter.fm Page i Friday, April 30, 2004 2:57 PM

ii

Troubleshooting Virtual Private Networks

Mark Lewis
Copyright 2004 Cisco Systems, Inc.
Published by:
Cisco Press
800 East 96th Street
Indianapolis, IN 46240 USA
All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or
mechanical, including photocopying, recording, or by any information storage and retrieval system, without written
permission from the publisher, except for the inclusion of brief quotations in a review.
Printed in the United States of America 1 2 3 4 5 6 7 8 9 0
First Printing June 2004
Library of Congress Cataloging-in-Publication Number: 2002104703
ISBN: 1-58705-104-4

Warning and Disclaimer

This book is designed to provide information about troubleshooting virtual private networks. Every effort has been made
to make this book as complete and as accurate as possible, but no warranty or tness is implied.
The information is provided on an as is basis. The authors, Cisco Press, and Cisco Systems, Inc. shall have neither
liability nor responsibility to any person or entity with respect to any loss or damages arising from the information
contained in this book or from the use of the discs or programs that may accompany it.
The opinions expressed in this book belong to the author and are not necessarily those of Cisco Systems, Inc.

Trademark Acknowledgments

All terms mentioned in this book that are known to be trademarks or service marks have been appropriately capitalized.
Cisco Press or Cisco Systems, Inc. cannot attest to the accuracy of this information. Use of a term in this book should
not be regarded as affecting the validity of any trademark or service mark.

Feedback Information

At Cisco Press, our goal is to create in-depth technical books of the highest quality and value. Each book is crafted with
care and precision, undergoing rigorous development that involves the unique expertise of members from the profes-
sional technical community.
Readers feedback is a natural continuation of this process. If you have any comments regarding how we could
improve the quality of this book, or otherwise alter it to better suit your needs, you can contact us through e-mail at
feedback@ciscopress.com. Please make sure to include the book title and ISBN in your message.
We greatly appreciate your assistance.

Corporate and Government Sales

Cisco Press offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales.
For more information please contact:

U.S. Corporate and Government Sales

1-800-382-3419
corpsales@pearsontechgroup.com
For sales outside the U.S. please contact:

International Sales

international@pearsoned.com

FrontMatter.fm Page ii Friday, April 30, 2004 2:57 PM

iii

Publisher John Wait
Editor-in-Chief John Kane
Executive Editor Brett Bartow
Cisco Representative Anthony Wolfenden
Cisco Press Program Manager Sonia Torres Chavez
Acquisitions Editor Michelle Grandin
Production Manager Patrick Kanouse
Development Editor Christopher Cleveland
Project Editor Marc Fowler
Copy Editor Ginny Kaczmarek
Technical Editors Henry Benjamin, Robert Brown, Nathan Lohr, Andrew Makin,
Ivan Pepelnjak, Tim Sammut, Wen Zhang
Team Coordinator Tammi Barnett
Book Designer Louisa Adair
Cover Designer Louisa Adair
Composition Argosy
Indexer Larry Sweazy

FrontMatter.fm Page iii Friday, April 30, 2004 2:57 PM

iv

About the Author

Mark Lewis

, CCIE No. 6280, is technical director of MJL Network Solutions (www.mjlnet.com), a leading
provider of internetworking solutions that focuses on helping service and enterprise provider customers to implement
cutting edge technologies, deploy security solutions, and optimize their networks, as well as providing them with
advanced training. Mark specializes in VPN technologies and has many years of experience designing,
implementing, and troubleshooting IP networks. He is also an MCSE+I and a certied Cisco Systems instructor.
Mark can be contacted at mark@mjlnet.com.

About the Technical Reviewers

Henry Benjamin

, CCIE No. 4695, holds three CCIE certications (Routing and Switching, ISP Dial, and Communica-
tions and Services). He has more than 10 years experience with Cisco networks and recently worked for Cisco in the
internal IT department helping to design and implement networks throughout Australia and Asia. Henry was a key mem-
ber of the CCIE global team, where he was responsible for writing new laboratory examinations and questions for the
CCIE exams. Henry is an independent consultant with a large security rm in Australia.

Robert Brown

, CCIE No. 7309, is developer and technical leader of Cisco Output Interpreter, a powerful online trou-
bleshooting tool that diagnoses and provides troubleshooting recommendations for Catalyst, IOS and PIX devices. He
spent 10 years in the United States Air Force as a Cryptographic Electronic Technician and Telephone Systems Special-
ist. He worked for TRW, Litton PRC and International Network Services before joining Cisco Systems.
He enjoys spending time with family in Round Rock, TX, and fullls his shing needs by competing in professional
bass tournaments.

Nathan Lohr

(CISSP, CCSP, and CCNA) is president of TRL Secure Solutions, a small business based in Northern Vir-
ginia providing national and international security consulting and training services. During the past fteen years he has
designed, tested and certied VPN, rewall, intrusion detection, and incident response solutions as well as ensuring cus-
tomer compliance with HIPAA and DCID requirements.

Andrew Makin

is a network consultant for Energis, a Cisco Gold Partner in the United Kingdom, and he currently
holds the CCNP, CCDP, and CSS-1 qualications. He designs WAN solutions for customers involving both IP and
secure VPN technology across the public Internet and the Energis provider network. He lives in Harrogate with his wife,
Lisa, and two daughters, Katy and Jessica.

Ivan Pepelnjak

, CCIE No. 1354, has more than 10 years of experience in designing, installing, troubleshooting, and
operating large service provider and enterprise WAN and LAN networks and is currently chief technologies advisor at
NIL Data Communications. He is the architect of NILs Service Provider Academy program, one of the architects of the
Cisco Systems Service Provider curriculum, and the lead developer of several service provider-focused courses cover-
ing MPLS, Border Gateway Protocol (BGP), and IP quality of service. Ivan is one of the Cisco Routing authorities in
Europe.

Tim Sammut

, CCIE No. 6642, is a senior network consultant for Northrop Grumman Information Technology. Tim has
served in key project roles involving technologies from LAN switching to security to SNA integration and has helped
many organizations, ranging from 100 to 130,000 users, make the most of their network investment. Tim also holds the
CISSP, CCIE Security, and CCIE Communication and Services certications.

Wen Zhang

has been a member of the Cisco Technical Assistance Center (TAC) in security and VPN technologies since
June 1997 and a member of the TAC escalation team since August 2000. Wen is a regular contributor on Cisco Open
Forum. He earned his B.S. and M.S. from Clemson University.

FrontMatter.fm Page iv Friday, April 30, 2004 2:57 PM

v

Acknowledgments

Id like to thank a number of people who have helped to make this project a reality. First and foremost are Michelle and
Chris at Cisco Press, without whose help this book would still be on the drawing board. And I dont want to forgot all the
other Cisco Press people involved with the production of this book, including: Marc, Patrick, Ginny, Tammi, Gina,
Louisa, Brett, and Larrythanks!
Id also like to thank the technical reviewers, Henry Benjamin, Tim Sammut, Wen Zhang, Nathan Lohr, Ivan Pepelnjak,
Robert Brown, and Andrew Makin, who contributed interesting and useful comments as I went along.
Finally, Id like to thank W. Mark Townsley for reviewing Chapter 5, as well as Glen Zorn and Luca Martini for conrm-
ing important points with regard to PPTP voluntary tunnel mode architecture and draft-martini Layer 2 MPLS transport
respectively.
Also, thanks to Vicky at Astricom for the loan of one of Astricoms ISDN simulators.

FrontMatter.fm Page v Friday, April 30, 2004 2:57 PM

vi

Contents at a Glance

Introduction xvii

Chapter 1

Basic Troubleshooting Methodology 3

Chapter 2

Troubleshooting Layer Two Forwarding Protocol VPNs 11

Chapter 3

Troubleshooting Point-to-Point Tunneling Protocol VPNs 135

Chapter 4

Troubleshooting Layer 2 Tunneling Protocol Version 2 VPNs 213

Chapter 5

Troubleshooting L2TPv3 Based VPNs 357

Chapter 6

Troubleshooting Multiprotocol Label Switching Layer 3 VPNs 419

Chapter 7

Troubleshooting Any Transport over MPLS Based VPNs 577

Chapter 8

Troubleshooting IPSec VPNs 655

Appendix A

Answers to Review Questions 757

Appendix B

Lab Instructions and Solutions 767

Index

777

FrontMatter.fm Page vi Friday, April 30, 2004 2:57 PM

vii

Table of Contents

Introduction xvii

Chapter 1

Basic Troubleshooting Methodology 3

Preparatory Steps: Baselining Your Network 3
What to Do When Problems Occur 4
Open Systems Interconnection Model 4
End-to-End, Bottom-Up (or Top-Down) Troubleshooting 5
Troubleshooting Tools 6
Summary 9

Chapter 2

Troubleshooting Layer Two Forwarding Protocol VPNs 11

Technical Overview of L2F 12
L2F Management Messages 17
L2F Tunnel Establishment 18
L2F Session Establishment 25
L2F Tunnel Maintenance 32
L2F Tunnel Teardown 34
Configuring L2F 35
Configuring the L2F NAS 36
Configuring the L2F Home Gateway 43
Troubleshooting L2F 48
Call Reception on the NAS 52
Troubleshooting PPP on the NAS 58
Troubleshooting L2F Tunnel Establishment 69
Troubleshooting L2F Session Establishment 80
Home Gateway/Remote Access Client PPP Negotiation Failure 84
Case Studies 98
Case Study 1: Remote AAA 98
Case Study 2: Cannot Complete an L2F Tunnel from an Offload Server to the Home
Gateway 114

FrontMatter.fm Page vii Friday, April 30, 2004 2:57 PM

viii

Additional Commands for Troubleshooting 122
show vpdn history failure 122
debug vpdn error 123
debug vpdn event 123
debug vpdn l2x-data 124
debug vpdn l2x-packets 124
debug vpdn packet 126
Error Messages 126
show and debug Command Summary 129
Review Questions 130
Troubleshooting Practice Labs 131
Troubleshooting Lab 1 131
Troubleshooting Lab 2 132
Troubleshooting Lab 3 133

Chapter 3

Troubleshooting Point-to-Point Tunneling Protocol VPNs 135

Technical Overview of PPTP 137
PPTP Control Channel Setup 138
PPTP Session Establishment 142
PPP Negotiation and Frame Forwarding 146
PPTP Tunnel Maintenance 148
PPTP Session and Control Channel Termination 150
Other PPTP Messages 154
Configuring PPTP 155
Troubleshooting PPTP 159
Control Connection and Call Session Establishment Failure 163
Virtual Access Interface Is Not Cloned 168
LCP Negotiation Failure 169
PPP Authentication Failure 176
NCP Negotiation Failure 180
Case Studies 197
Case Study 1: MPPE Attributes Are Not Returned from the RADIUS Server 197
Case Study 2: Split Tunnel 203
Additional Troubleshooting Commands 204
show vpdn 204
show vpdn tunnel 205
show vpdn session 205
show ppp mppe virtual-access

number

206

FrontMatter.fm Page viii Friday, April 30, 2004 2:57 PM

ix

debug ppp mppe packet 207
debug ppp mppe event 207
debug ppp mppe detailed 208
debug vpdn error 209
debug vpdn event 209
clear vpdn tunnel pptp

remote access client/PNS_name PAC_name

210
show and debug Command Summary 210
Review Questions 211

Chapter 4

Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs 213

L2TPv2 Technical Overview 215
L2TP Control Messages 220
L2TP Tunnel (Control Connection) Establishment 227
L2TP Session Establishment 230
L2TP Tunnel Maintenance 232
L2TP Session Teardown 233
L2TP Tunnel Teardown 234
Other L2TP Messages 234
Outgoing Calls 235
L2TP Security 236
Configuring L2TPv2 237
Configuring L2TP Compulsory Tunnel Mode 237
Configuring L2TP Voluntary Tunnel Mode 252
Configuring IPSec Protection for L2TP in Compulsory Tunnel Mode with Preshared
Keys 252
Configuring IPSec Protection for L2TP in Voluntary Tunnel Mode with Preshared
Keys 255
Troubleshooting L2TPv2 255
Call Reception on the LAC 260
Troubleshooting PPP on the LAC 266
L2TPv2 Tunnel Establishment Failure 278
L2TPv2 Session Establishment Failure 290
LNS/Remote Access Client PPP Negotiation Failure 297
Case Studies 311
Case Study 1: Misconfigured L2TP Tunnel Definition on an AAA RADIUS
Server 312
Case Study 2: Remote AAA (RADIUS) Authentication Failure on the LNS 322
Case Study 3: Remote AAA (RADIUS) Authorization Failure on the LNS 326
Case Study 4: AAA (RADIUS) Server Unreachable from the LNS 331
Case Study 5: Voluntary Tunnel Mode Connectivity from a Windows 2000 Workstation
Fails 335

FrontMatter.fm Page ix Friday, April 30, 2004 2:57 PM

x

Additional L2TP Troubleshooting Commands 342
show vpdn history failure 342
show vpdn session all 343
debug vpdn error 344
debug vpdn l2x-data 345
debug vpdn l2x packets 346
debug vpdn packet 347
clear vpdn tunnel 348
Error Messages 348
show and debug Command Summary 351
Review Questions 352
L2TP Troubleshooting Practice Labs 352
L2TP Troubleshooting Lab 1 353
L2TP Troubleshooting Lab 2 354
L2TP Troubleshooting Lab 3 354

Chapter 5

Troubleshooting L2TPv3 Based VPNs 357

Technical Overview of L2TPv3 358
L2TPv3 Message Types 359
Control Connection Establishment 371
Session Establishment 372
Control Connection Maintenance 373
Session Teardown 374
Control Connection Teardown 374
Set-Link-Info (SLI) Message 375
Configuring L2TPv3 375
Configuring L2TPv3 for Dynamic Session Setup 376
Configuring L2TPv3 for Static Sessions 380
Complete Sample L2TPv3 Configurations 382
MTU Issues with L2TPv3 387
Troubleshooting L2TPv3 389
Troubleshooting L2TPv3 Control Connection Setup 390
Troubleshooting L2TPv3 Dynamic Session Establishment 400
Troubleshooting L2TPv3 with Static Session Configuration 408
Other Commands 410
show l2tun tunnel all 410
show l2tun session all 411
debug acircuit [error | event] 413
debug xconnect [error | event] 414

FrontMatter.fm Page x Friday, April 30, 2004 2:57 PM

xi

debug vpdn l2tp-sequencing 414
debug vpdn packet 415
debug vpdn l2x-packets 416
Command Summary 417
Review Questions 417

Chapter 6

Troubleshooting Multiprotocol Label Switching Layer 3 VPNs 419

Technical Overview 420
MPLS Architecture 421
MPLS Layer-3 VPNs 430
Configuring MPLS VPNs 445
Configuring the CE Router 446
Configuring the PE Router 446
Configuring the P Router 462
Configuring MVPNs 464
Configuring the CE Router 464
Configuring the Backbone (P Routers) 465
Configuring the PE Router 465
Configuring TE Tunnels to Carry MPLS VPN Traffic 468
Configuring TE Tunnels Between PE Routers 468
TE Tunnels Between P Routers 472
Troubleshooting MPLS VPNs 473
Locating the Problem in an MPLS VPN 476
Troubleshooting the Backbone IGP 479
Troubleshooting the LSP 481
Troubleshooting Route Advertisement Between VPN Sites 511
Case Studies 536
MPLS MTU Is Too Small in the MPLS VPN Backbone 536
Summarization of PE Router Loopback Addresses Causes VPN Packets to Be
Dropped 540
MPLS VPN Traffic Is Dropped on TE Tunnels Between P Routers 547
MVPN Fails When TE Tunnels Are Configured in the MPLS VPN Backbone 553
Additional Troubleshooting Commands 560
show ip cef vrf

vrf_name

detail 560
show adjacency detail 561
show mpls ldp parameters 563
show mpls atm-ldp capability 564
show atm vc 565
show ip bgp vpnv4 vrf

vrf_name

labels 565

FrontMatter.fm Page xi Friday, April 30, 2004 2:57 PM

xii

debug mpls ldp transport events 566
debug mpls ldp messages 567
debug mpls ldp advertisements 567
debug mpls ldp bindings 568
show and debug Command Summary 569
Review Questions 571
MPLS VPN Troubleshooting Practice Labs 571
Troubleshooting Lab 1 572
Troubleshooting Lab 2 573
Troubleshooting Lab 3 574

Chapter 7

Troubleshooting Any Transport over MPLS Based VPNs 577

Technical Overview of AToM 577
Layer 2 PDU Transport 578
VC Label Exchange 582
Configuring AToM 588
Step 1: Configure the Loopback Interface to Be Used as the LDP Router ID 588
Step 2: Enable CEF 588
Step 3: Specify LDP as the Label Protocol 589
Step 4: Configure the LDP Router ID 589
Step 5: Configure MPLS on Core Interfaces 589
Step 6: Configure the MPLS Backbone IGP 590
Step 7: Configure the AToM Pseudowires 591
Complete Sample Configurations for AToM PE Routers 597
Maximum Transmission Unit Issues 602
Troubleshooting AToM 605
Verifying and Troubleshooting the Tunnel LSP 607
Verifying and Troubleshooting VC Label Exchange 636
Other AToM Troubleshooting Commands 645
show mpls l2transport vc

vcid

detail 646
show mpls l2transport hw-capability interface

interface_name

647
show mpls l2transport summary 647
show mpls l2transport binding 648
debug mpls l2transport signaling [event | fsm | message] 649
debug mpls l2transport packet {data | error} 650
debug frame-relay events 650
debug acircuit [error | event] 651
Troubleshooting AToM: Command Summary 652
Review Questions 652

FrontMatter.fm Page xii Friday, April 30, 2004 2:57 PM

xiii

Chapter 8

Troubleshooting IPSec VPNs 655

Technical Overview of IPSec 656
Security Protocols 656
Security Associations 660
SA and Key Management with the IKE Protocol 660
Configuring IPSec VPNs 668
Configuring a Site-to-Site IPSec VPN 669
Configuring Remote Access VPNs with Cisco VPN Client 3.x / 4.0 682
Maximum Transmission Unit (MTU) Issues with IPSec 689
Troubleshooting IPSec VPNs 690
IKE Phase 1 (Main Mode) Negotiation Fails 692
IKE Phase 2 (Quick Mode) Negotiation Fails 719
User Traffic Does Not Successfully Cross the IPSec Tunnel 733
Case Studies 736
CA Authentication or Enrollment Fails 736
IKE Negotiation Fails with a Remote VPN Client 740
Additional Troubleshooting Commands 747
show crypto engine connections active 747
show crypto key mypubkey rsa 747
show crypto key pubkey-chain rsa 748
show crypto ipsec dynamic-map 748
show crypto ipsec security-association lifetime 749
debug crypto ipsec 749
show and debug Command Summary 750
Review Questions 751
Practice Labs 752
Troubleshooting Lab 1 752
Troubleshooting Lab 2 753
Troubleshooting Lab 3 754

Appendix A

Review Questions and Answers 757

Chapter 2 Review Questions & Answers 757
Chapter 3 Review Questions & Answers 758
Chapter 4 Review Questions & Answers 759
Chapter 5 Review Questions & Answers 760
Chapter 6 Review Questions & Answers 761

FrontMatter.fm Page xiii Friday, April 30, 2004 2:57 PM

xiv

Chapter 7 Review Questions & Answers 762
Chapter 8 Review Questions & Answers 763

Appendix B

Lab Instructions and Solutions 767

Setting Up Your Routers and Loading the Configuration Files 767
Router Platforms and Cabling 767
Loading Configuration Files onto Your Lab Routers 768
Chapter 2: L2F Troubleshooting Lab Solutions 771
Troubleshooting Lab 1 Solution 771
Troubleshooting Lab 2 Solution 772
Troubleshooting Lab 3 Solution 772
Chapter 4: L2TPv2 Troubleshooting Lab Solutions 772
Troubleshooting Lab 1 Solution 772
Troubleshooting Lab 2 Solution 773
Troubleshooting Lab 3 Solution 773
Chapter 6: MPLS Layer 3 VPN Troubleshooting Lab Solutions 773
Troubleshooting Lab 1 Solution 773
Troubleshooting Lab 2 Solution 773
Troubleshooting Lab 3 Solution 774
Chapter 8: IPSec Troubleshooting Lab Solutions 774
Troubleshooting Lab 1 Solution 774
Troubleshooting Lab 2 Solution 774
Troubleshooting Lab 3 Solution 775

Index 777

FrontMatter.fm Page xiv Friday, April 30, 2004 2:57 PM

xv

Icons Used in This Book

Throughout the book, you will see the following icons used for networking devices:
PC PC with
Software
Sun
Workstation
Macintosh
Terminal File
Server
Web
Server
Cisco Works
Workstation
Printer Laptop IBM
Mainframe
Front End
Processor
Cluster
Controller
Modem
DSU/CSU
Router Bridge Hub DSU/CSU
Catalyst
Switch
Multilayer
Switch
ATM
Switch
ISDN/Frame Relay
Switch
Communication
Server
Gateway
Access
Server
Network Cloud
Token
Ring
Token Ring
Line: Ethernet
FDDI
FDDI
Line: Serial Line: Switched Serial

FrontMatter.fm Page xv Friday, April 30, 2004 2:57 PM

xvi

Command Syntax Conventions

The conventions used to present command syntax in this book are the same conventions used in the Cisco IOS Software
Command Summary:


Boldface

indicates commands and keywords that are entered literally as shown. In actual congu-
ration examples and output (not general command syntax), boldface indicates commands that are
manually input by the user (such as a

show

command).


Italics

indicate arguments for which you supply actual values.
Vertical bars (|) separate alternative, mutually exclusive elements.
Square brackets [ ] indicate optional elements.
Braces { } indicate a required choice.
Braces within brackets [{ }] indicate a required choice within an optional element.

FrontMatter.fm Page xvi Friday, April 30, 2004 2:57 PM

xvii

Introduction

Virtual private networks (VPNs) in their many and varied guises are becoming more and more prevalent throughout the
world. For the service provider and enterprise, they provide a means of enabling new services and applications over a
wide-area network (WAN), while providing considerable concomitant cost savings.
VPNs are complex, so when things go wrong, they can be difcult to troubleshoot. What are your options? One option is
to contact Cisco TAC. Alternatively, you can buy this book, roll up your sleeves, and get to work. Armed with as much
information as I could cram into 800-odd pages, youll be well on your way to solving your problem. And if your orga-
nization is considering deploying or optimizing a VPN and wants to avoid all the issues described in this book and more,
please see my company website (www.mjlnet.com) or contact me directly (mark@mjlnet.com), and my very knowl-
edgeable colleagues or I will soon be on site helping to ensure that the process goes smoothly (our services are charge-
able, of course!). Furthermore, if your organization would like to improve staff productivity and expertise through
advanced training, again please see the website.
A number of RFCs and Internet Drafts are referenced in this book. You should be able to locate many of these at the
IETF Web site (www.ietf.org). Internet Drafts do, however, expire, so an alternative way of locating them is to use an
archive such as www.watersprings.org.

Motivation for the Book

In my work designing, implementing, and troubleshooting VPNs, I noticed a lack of a single source that not only
described the commands and techniques to troubleshoot VPNs, but also included the detailed protocol information nec-
essary to correctly interpret troubleshooting command output. This book will provide you with that single source, and it
will (hopefully) save you a lot of time and stress when troubleshooting your VPNs.

Audience

This book covers a wide range of VPN technologies, including IPSec, MPLS, L2TP version 3, L2TP version 2, PPTP,
and L2F. It is suited to network support engineers and architects, whose job is to provide day-to-day support for VPNs or
deploy VPNs successfully in the rst place.
Because of the range of coverage, and the fact that each chapter covers not only troubleshooting, but also a technical
overview and conguration guidelines, this book may be of considerable assistance to CCIE candidates preparing for
the Service Provider and Security exams.

Organization

This book can be read in three different ways. First, it can be read end to end. This is the approach to take if you are curi-
ous about VPN technologies in general and want to improve your internetworking skills.
A second way of reading this book is to read a particular chapter or chapters that deals with VPN technologies deployed
in your network in advance of problems occurring. This is a good ideaforewarned is forearmed, after all.
Lastly, you can dip into the chapters as and when problems do crop up. Each chapter has been arranged in a manner to
facilitate this as much as possible.
As a bonus, a number of troubleshooting labs are included to help you develop and hone your VPN troubleshooting
skills. Included on the Cisco Press Web site for this book (www.ciscopress.com/1587051044) are labs for L2F, L2TP
version 2, MPLS Layer 3 VPN, and IPSec. Labs for PPTP are not included because Cisco IOS routers support only
voluntary tunnel mode, and the list of possible client operating systems is extensive. Labs for L2TP version 3 and Any
Transport over MPLS (AToM) are not included because the base platform required for these technologies at the time of
writing is the Cisco 7200I dont imagine that many people are lucky enough to have 7200s in their lab!

FrontMatter.fm Page xvii Friday, April 30, 2004 2:57 PM

xviii

If and when support for L2TP version 3 and AToM is added to lower-end platforms, I may develop a few labs for these
technologies. Check the Cisco Press web site in that case. You may also nd one or two extra labs for the other technol-
ogies discussed in this book.
The chapters are arranged in the following order:


Chapter 1, Basic Troubleshooting Methodology

This chapter introduces a basic end-to-end trouble-
shooting methodology that is particularly suited to VPNs. Also discussed are the tools and techniques used for
troubleshooting these technologies.


Chapter 2, Troubleshooting Layer Two Forwarding Protocol VPNs

L2F was one of the rst virtual
private dialup network technologies to be deployed. This chapter discusses the technology, its conguration,
and in-depth troubleshooting techniques.


Chapter 3, Troubleshooting Point-to-Point Tunneling Protocol VPNs

The PPTP protocol, congura-
tion, and in-depth troubleshooting are examined in this chapter.


Chapter 4, Troubleshooting Layer 2 Tunneling Protocol Version 2 VPNs

L2TP is based on L2F and
PPTP. This chapter introduces L2TP, discusses conguration, and goes on to examine in-depth L2TPv2 trou-
bleshooting techniques.


Chapter 5, Troubleshooting L2TP v3 Based VPNs

L2TPv3 is a technology that allows the tunneling
of not only PPP, but also other Layer 2 protocols, such as Ethernet, HDLC, and Frame Relay. This chapter
examines the technology itself, its conguration, and in-depth troubleshooting.


Chapter 6, Troubleshooting Multiprotocol Label Switching Layer 3 VPNs

MPLS Layer 3 VPNs are
proving to be a very popular technology for service providers and enterprises alike. The technology, its cong-
uration, and in-depth troubleshooting are discussed in this chapter.


Chapter 7, Troubleshooting Any Transport over MPLS Based VPNs

AToM can be used to provide
transport of Layer 2 protocols such as HDLC, PPP, Frame Relay, and Ethernet over an MPLS backbone. The
technology, conguration, and in-depth troubleshooting are examined.


Chapter 8, Troubleshooting IPSec VPNs

IPSec VPNs are typically deployed to provide secure VPNs
in a site-to-site or remote access conguration. The IPSec technology, conguration, and in-depth trouble-
shooting are discussed in this chapter.


Appendix A, Answers to Review Questions

This appendix includes answers to the review questions
provided at the end of each chapter.


Appendix B, Lab Instructions and Solutions

The L2F, L2TPv2, MPLS Layer 3 VPN, and IPSec chap-
ters include troubleshooting labs to help readers understand and consolidate concepts and techniques dis-
cussed. This appendix explains how lab conguration can be loaded onto lab routers from the Cisco Press
Web site (www.ciscopress.com/1587051044) and provides solutions to the labs themselves.

FrontMatter.fm Page xviii Friday, April 30, 2004 2:57 PM

FrontMatter.fm Page xix Friday, April 30, 2004 2:57 PM

CH01i.book Page 2 Friday, April 30, 2004 8:58 AM

C

H



A



P



T



E



R

1

Basic Troubleshooting
Methodology

There are two basic approaches to troubleshooting: the stab-in-the-dark approach and the
systematic approach. The stab-in-the-dark approach usually involves little knowledge of
the technology involved and is completely random in nature. A systematic approach, on the
other hand, involves a step-by-step approach and requires in-depth knowledge of the
technology.
Very occasionally, the stab-in-the-dark approach can work, but the more complex the
technology (and virtual private networks [VPNs] are denitely complex), the less likely
that the stab-in-the-dark approach is going to be effective.
This chapter, therefore, introduces a step-by-step, systematic approach to troubleshooting
that is detailed in the remainder of the book. If you are going to troubleshoot VPNs in a fast
and efcient manner, this approach is denitely the one to adopt.

Preparatory Steps: Baselining Your Network

Preparatory steps? How can you prepare to troubleshoot? Surely troubleshooting is purely
activity, you might be thinking. It can be, but you can do a number of things so that, when
problems do arise, you are prepared.
A rst step is to prepare a detailed network topology diagram or diagrams. This diagram
should include information such as device types, names, addresses, routing protocols,
routing protocol autonomous systems, and link types.
You should also gather information including device congurations, software versions
(IOS / CatOS), and performance statistics, such as utilization and error rates. Finally, make
sure that you have a solid understanding of the technologies and protocols deployed in your
network.
Once you have all this information and have a good understanding of your network, youll
be able to spot and troubleshoot network problems much more easily.

CH01i.book Page 3 Friday, April 30, 2004 8:58 AM

4

Chapter 1: Basic Troubleshooting Methodology

What to Do When Problems Occur

When problems do occur, all of the information mentioned in the previous section will stand
you in good stead. But even if you are in possession of this information, you are going to need
to work fast to gather facts relating to the issue.
The rst thing that you should do is ascertain

exactly

what has gone wrongestablish what the
facts are. Find out whether any changes have been made to the network and, if so, what. If
possible, try to talk to people directly involved with any changes; secondhand information
might not always be as reliable as you would like.
Also, if it becomes apparent during the troubleshooting process that there are multiple issues
involved, be sure that you tackle one problem at a time. Any attempt to tackle multiple issues
at one time usually just leads to confusion and may even make the situation worse.
Open Systems Interconnection Model
Two reference models are often used to understand internetworking technologies: the Open Systems
Interconnection (OSI) and Department of Defense (DoD) models. Both can be useful, but in this
book, the model that is used is the OSI model. Figure 1-1 illustrates the OSI reference model.
Figure 1-1 OSI Reference Model
Only four of the seven layers are central to troubleshooting the technologies discussed in this book:
Physical layer (Layer 1)
Data link layer (Layer 2)
Network layer (Layer 3)
Transport layer (Layer 4)
The physical layer is associated with the transmission of bits over the physical medium itself.
Characteristics such as voltage levels, maximum transmission distances, and connector types
are specied at this layer.
The data link layer handles physical addressing, ow control, access to the physical medium,
and error detection. Data link layer protocols include HDLC, PPP, Frame Relay, and Ethernet.
7. Application
6. Presentation
5. Session
4. Transport
3. Network
2. Data Link
1. Physical
CH01i.book Page 4 Friday, April 30, 2004 8:58 AM
End-to-End, Bottom-Up (or Top-Down) Troubleshooting 5
The network layer facilitates the transmission of packets between end systems on different
logical networks by providing path determination and selection. Network layer protocols
include IP and IPX.
Finally, the transport layer provides end-to-end communication and multiplexing of multiple
applications over a transport connection. The transport layer can also provide a reliable channel
of communication between end systems, with ow control and congestion avoidance. Transport
layer protocols include TCP and UDP.
One thing to remember, however, is that the OSI model is, after all, just a reference model. Not all
protocols t easily; a good example of this is Multiprotocol Label Switching (MPLS). It resides
at neither the data link nor the network layer. It sits somewhat uncomfortably between the two.
End-to-End, Bottom-Up (or Top-Down) Troubleshooting
Troubleshooting can take many forms, but VPN technologies are particularly suited to end-to-
end, bottom-up (or top-down) troubleshooting.
For example, if you are troubleshooting a compulsory mode Layer Two Tunneling Protocol
(L2TP) version 2 VPN (with dial-in), the rst thing to do is to conrm that remote clients calls
are being received on the L2TP Access Concentrator (LAC). Next you should conrm that Link
Control Protocol (LCP) and partial authentication are being successfully completed on the LAC.
Then you should conrm that L2TP tunnel and session setup is successful between the LAC and
the L2TP Network Server (LNS). Finally, you can verify that PPP negotiation is successfully
completed between the remote client and the LNS. Figure 1-2 illustrates L2TPv2 VPN setup.
Figure 1-2 L2TPv2 VPN Setup
Remote client
LAC
LNS
Service Provider
Backbone/Internet
1. Call Reception
3. L2TP Tunnel Establishment
4. L2TP Session Establishment
5. PPP Negotiation Completed
6. PPP Frame Forwarding
2. LCP / Partial
Authentication
PSTN/
ISDN
CH01i.book Page 5 Friday, April 30, 2004 8:58 AM
6 Chapter 1: Basic Troubleshooting Methodology
In this example, setup is asymmetricthe calling party is the remote client, and the called party
is (ultimately) the LNS.
Some other VPN technologies require a symmetric approach to troubleshooting. A good
example of this is MPLS Layer 3 (RFC 2547bis) VPNs. In this case, you need to verify route
exchange between customer edge (CE) routers bidirectionally over the MPLS VPN backbone.
Additionally, you will need to verify the label switched path (LSP) in both directions between
provider edge (PE) routers across the MPLS backbone. Figure 1-3 illustrates route exchange
and LSPs across the MPLS VPN backbone.
Figure 1-3 Bidirectional Route Exchange and LSPs Across the MPLS VPN Backbone
When you are troubleshooting a VPN, you should never lose sight of the underlying physical,
data-link, and network layer protocols.
It is always good practice to ask yourself what must happen rst, then next, then after that for
the VPN to function correctly. Also ask yourself what underlies each particular process or
mechanism.
Troubleshooting Tools
The primary tools for troubleshooting VPNs are the show, ping, traceroute, and debug
commands. For these commands to be used correctly (and safely), a number of guidelines need
to be followed.
The show command can be used to view a wide variety of information and statistics related to
VPNs.
Chengdu_PE Chengdu_P HongKong_P HongKong_PE
LSP
LSP
Route
Advertisement
Route
Advertisement
MPLS VPN
Backbone
CE1 CE2
Site 2 Site 1
CH01i.book Page 6 Friday, April 30, 2004 8:58 AM
Troubleshooting Tools 7
The ping and traceroute commands can be used to verify basic IP connectivity and route
across the network. The traceroute command can also be used in an MPLS backbone to display
the label stack. Maximum Transmission Unit (MTU) issues that may result in a VPN can also
be identied using extended ping to sweep a range of packet sizes. If pings using smaller packet
sizes succeed but larger packet sizes fail, this can indicate an issue with the MTU in the VPN.
Finally, the debug command can be used to display a variety of status and error information
associated with VPNs. Although debug is a useful and, at times, essential tool, there are some
dangers with using it. If you use the wrong debug command, or do not lter its output, the
output can tie up all the systems resources and potentially cause the system to hang.
You can employ a number of ways to avoid loading the system too much. The rst is not to
debug via the console, but instead to debug via a Telnet session. Use the no logging console
command to turn off logging to console. Use the terminal monitor command to view
debugging output via a Telnet session. The terminal no monitor command disables viewing
debug output via a Telnet session.
It might even be a good idea to open a second Telnet session to the device in question so that
debugging can still be turned off even if the rst session is overwhelmed with output from a
debug command. You can also redirect debug output to a syslog server using the logging
syslog_server_ip_address command.
Note that the quickest (most abbreviated) way to cancel all debug commands is by entering the
un all command. This is an abbreviation of the undebug all command.
One very useful command, particularly when debugging L2F, PPTP, L2TP, Any Transport over
MPLS (AToM), and IPSec is debug condition or debug crypto condition (for IPSec). The
debug condition command can be used to limit the output of a debug command so that only
the output related to a particular called or calling number, interface, username, IP address, or
AToM virtual circuit (VC) ID is displayed. The debug condition command can be used to limit
the output of the following commands:
debug aaa {accounting | authorization | authentication}
debug dialer {events | packets}
debug isdn {q921 | q931}
debug modem {oob | trace}
debug ppp {all | authentication | chap | error | negotiation | multilink events | packet}
debug mpls l2transport vc {event | fsm}
debug crypto {isakmp | ipsec | engine}
In Example 1-1, debug condition is used to limit the output of the debug ppp negotiation
command to that related to interface virtual-template 1. Note that only a portion of the output
is shown.
CH01i.book Page 7 Friday, April 30, 2004 8:58 AM
8 Chapter 1: Basic Troubleshooting Methodology
In the rst highlighted line, debugging messages for interface virtual template 1 are enabled
using the debug condition interface virtual-template 1 command. This also disables output
for any other interfaces. In the second highlighted line, the debug ppp negotiation command
is used to enable debugging of PPP negotiation events. Finally, in the third highlighted line, PPP
debugging messages are triggered on interface virtual template 1 (from which interface virtual
access 1 is cloned, in this example). PPP debugging messages are then displayed.
More than one debug (crypto) condition command can be enabled at one time, but do not
enable too many conditions as this can impact router performance. In this case, debug output
must fulll just one of the conditions to be displayed. Use the show debug condition or show
crypto debug-condition commands as appropriate to verify current debugging conditions, as
shown in Example 1-2.
As you can see, the condition AToM VC ID 123 has been congured. This condition has been
met twice. To remove a condition, simply use the no debug (crypto) condition command. With
IPSec, you can disable all conditional settings using the debug crypto condition reset
command, but make sure you turn off all IPSec debug commands rst.
The output of a number of debug commands can also be ltered using an access list. A good
example of this is the debug ip bgp update [access-list] command. This can be used to limit
the output of the command to updates containing prexes specied by the access list.
Example 1-1 debug ppp authentication with debug condition (interface virtual-template 1)
Skydance_LNS#debug condition interface virtual-template 1
Condition 1 set
Skydance_LNS#
Skydance_LNS#debug ppp negotiation
PPP protocol negotiation debugging is on
Skydance_LNS#
*Mar 1 00:27:33.478 UTC: Vi1 Debug: Condition 1, interface Vt1 triggered, count 1
*Mar 1 00:27:33.482 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to
up
*Mar 1 00:27:33.482 UTC: Vi1 PPP: Using vpn set call direction
*Mar 1 00:27:33.482 UTC: Vi1 PPP: Treating connection as a callin
*Mar 1 00:27:33.482 UTC: Vi1 PPP: Phase is ESTABLISHING, Passive Open
[0 sess, 0 load]
*Mar 1 00:27:33.486 UTC: Vi1 LCP: State is Listen
*Mar 1 00:27:33.486 UTC: Vi1 LCP: I FORCED CONFREQ len 11
*Mar 1 00:27:33.486 UTC: Vi1 LCP: AuthProto CHAP (0x0305C22305)
*Mar 1 00:27:33.486 UTC: Vi1 LCP: MagicNumber 0x066CA0F0 (0x0506066CA0F0)
*Mar 1 00:27:33.486 UTC: Vi1 LCP: I FORCED CONFACK len 6
*Mar 1 00:27:33.490 UTC: Vi1 LCP: MagicNumber 0x508E6BD0 (0x0506508E6BD0)
*Mar 1 00:27:33.490 UTC: Vi1 PPP: Phase is AUTHENTICATING, by this end
[0 sess, 0 load]
Example 1-2 Output of the show debug condition Command
London_PE#show debug condition
Condition 1: vcid 123 (2 flags triggered)
Flags: 123 123
London_PE#
CH01i.book Page 8 Friday, April 30, 2004 8:58 AM
Summary 9
Summary
This chapter introduced a basic systematic troubleshooting methodology. VPNs are particularly
suited to end-to-end, bottom-up, or top-down troubleshooting.
For some VPN technologies, such as L2F, L2TP version 2, and PPTP, end-to-end
troubleshooting is asymmetric, whereas for others, such as MPLS layer-3 VPNs and L2TP
version 3, end-to-end troubleshooting is symmetric.
Preparatory steps, such as drawing network diagrams, recording software versions, and backing
up device congurations, are recommended.
Finally, VPN troubleshooting tools, such as the show, ping, traceroute, and debug commands,
were introduced. Usage guidelines for the debug command were also discussed.
CH01i.book Page 9 Friday, April 30, 2004 8:58 AM
CH01i.book Page 10 Friday, April 30, 2004 8:58 AM
C H A P T E R
2
Troubleshooting Layer Two
Forwarding Protocol VPNs
The Layer Two Forwarding (L2F) Protocol is a Cisco proprietary protocol that facilitates
the transparent forwarding of Point-to-Point Protocol (PPP) and Serial Line Internet
Protocol (SLIP) across an IP backbone.
L2F, which is dened in RFC 2341, allows the separation of the functionality of the
traditional Network Access Server (NAS), with call reception on a NAS, but termination of
the PPP or SLIP connection on a device called a Home Gateway. The Home Gateway is
geographically separated from the NAS. This means that an enterprise can outsource call
reception to an Internet service provider (ISP) but still terminate PPP/SLIP connections
within the corporate network. This allows the enterprise to save or minimize on call charges
because remote access clients are no longer required to dial directly to the enterprise. They
are instead able to dial in to the ISPs nearest Point-of-Presence (POP). Figure 2-1
illustrates this concept.
Figure 2-1 L2F Topology
This logical separation of call reception and PPP connection termination presupposes a
mechanism for tunneling the PPP frames across the backbone to the Home Gateway. This
mechanism is provided by L2F.
Only compulsory tunneling is supported with L2F. This means that tunneling directly from
the remote access client to the Home Gateway is not supported.
Note that L2F is also used to support the tunneling of multilink PPP (MP) links between
NASs in a multichassis multilink PPP (MMP) environment.
Remote Access
Client
NAS
PSTN/
ISDN
Home Gateway
Corporate
Network
Service Provider
Backbone
L2F Tunnel PPP PPP
CH01i.book Page 11 Friday, April 30, 2004 8:58 AM
12 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
Technical Overview of L2F
This chapter focuses on in-depth troubleshooting of L2F. Fast and efcient troubleshooting
requires a good knowledge of both L2F and its conguration, and to that end, a brief description
of both follows.
As previously described, L2F is a protocol that allows the tunneling of PPP and SLIP frames
across a IP backbone between a NAS and a Home Gateway. This chapter focuses on the
tunneling of PPP frames because, to a great extent, PPP has superceded SLIP as the remote
access protocol of choice.
The protocol itself uses the User Datagram Protocol (UDP), on top of which sits the L2F packet
(header, payload, and optional CRC) itself.
Figure 2-2 illustrates the relationship between IP, UDP, and L2F.
Figure 2-2 Overall L2F Packet Format
Note that L2F packets utilize UDP port 1701. This will be relevant when troubleshooting L2F.
Now take a closer look at the L2F Protocol packet header itself in Figure 2-3.
IP Header
UDP Header
L2F Header
L2F Payload
L2F CRC (Optional)
CH01i.book Page 12 Friday, April 30, 2004 8:58 AM
Technical Overview of L2F 13
Figure 2-3 L2F Packet Header
The following list provides an analysis of the L2F header, starting with the header ags:
The F, K, S, and C bits, if set to 1, indicate that the optional elds (shown as opt in Figure
2-3) should be present:
F, if set, indicates that the Offset eld should be present.
K, if set, indicates that the Key eld should be present.
S, if set, indicates that the Sequence number should be set.
Finally, C, if set, indicates that the Checksum should be present.
The P bit, if set, indicates that this L2F packet is a priority packet. RFC 2341 does not
specically dene what type of packet should constitute a priority packet but instead
leaves this up to the implementer.
The Version (Ver) eld is a 3-bit eld and should be set to 001 binary = 1 decimal. No
other value is valid, at least as far as L2F is concerned.
The 8-bit Protocol eld has only three legal values, 0x01, 0x02, and 0x03. The value 0x1
indicates that this is an L2F management packet (type L2F_PROTO), the value 0x2
indicates that this packet contains PPP tunneled within L2F (type L2F_PPP), and the
value 0x3 indicates that the packet contains SLIP tunneled within L2F (type L2F_SLIP).
Table 2-1 summarizes Protocol eld values.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
F K P S O O O O O O O O C Ver Protocol Sequence (opt)
Client ID
Offset (opt)
Key (opt)
Length
Multiplex ID
(payload)
(payload)
L2F Checksum (optional)
L2F
Header
. . . . .
. . . . .
. . . . .
0 1 2 3
CH01i.book Page 13 Friday, April 30, 2004 8:58 AM
14 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
If the value in the Protocol eld species a management packet, then various
options and suboptions are carried within the L2F payload. Options specify an
overall message type, with suboptions carrying data associated with the message
type.
Options and suboptions are discussed in the section L2F Management
Messages.
The 8-bit Sequence eld is present only if the S-bit is set. The S-bit must be set, and
therefore, sequence numbering must be used, for L2F management packets.
RFC 2341 allows a degree of exibility with regard to the Sequence number
eld. Packets other than management packets can use sequence numbers, but it
is not mandatory. Some protocols might be sensitive to packets arriving out of
sequence, and sequence numbering can be useful in this case. If sequence
numbering is used, it must be present in every packet for a particular session (for
every packet with the same multiplex ID [MID]).
The MID is a 16-bit eld, and it is used to distinguish between different sessions
(connections) within the overall L2F tunnel from a NAS to a Home Gateway.
Figure 2-4 illustrates an L2F tunnel between a NAS and Home Gateway with multiple sessions
within it, each from a different remote access client.
In Figure 2-4, two remote access users are connected to the NAS. Their PPP connections are
tunneled via L2F from the NAS to the Home Gateway.
The Home Gateway has to be able to distinguish between the two sessions, and this is done
using unique MIDs. Remote access user As PPP connection uses MID 17, and user Bs PPP
connection uses MID 18. Note that MID 17 and 18 have no special signicance and are used
purely for illustrative purposes.
The MID 0 is reserved for L2F management (L2F_PROTO) packets, leaving a theoretical
2^16-1 (65535) MIDs for client sessions.
Table 2-1 L2F Protocol Field Values
Value Type Description
0x00 L2F_ILLEGAL Illegal protocol type
0x01 L2F_PROTO Management packets
0x02 L2F_PPP Payload carries tunneled PPP
0x03 L2F_SLIP Payload carries tunneled SLIP
CH01i.book Page 14 Friday, April 30, 2004 8:58 AM
Technical Overview of L2F 15
Figure 2-4 Multiple Sessions Within the L2F Tunnel
The Client ID (CLID) is a 16-bit eld, and it is used to uniquely identify a particular tunnel from
a NAS to a Home Gateway and vice-versa. At any one time, a Home Gateway might be
terminating L2F tunnels from a number of NASs. Similarly at any one time, a NAS might have
tunnels to several Home Gateways. To allow the Home Gateway (or NAS) to distinguish
between the packets coming through tunnels from different NASs (or Home Gateways), a CLID
is used.
The CLID assigned to a particular tunnel is communicated during the tunnel setup. It is
communicated via the Assigned CLID eld in a L2F_CONF packet (see the section L2F
Tunnel Establishment). The receiving device then uses the CLID to distinguish inbound
packets belonging to different tunnels.
For example, a NAS with hostname LODI_NAS1 receives a call from an employee of the Perris
Corporation. Having no existing L2F tunnel to the Home Gateway for the Perris Corporation
(PERRIS_HGW1), LODI_NAS1 needs to set one up. Tunnel setup begins from LODI_NAS1
to PERRIS_HGW1. PERRIS_HGW1 is already terminating an L2F tunnel from LODI_NAS2,
and this tunnel is identied by the CLID 1. PERRIS_HGW1 needs to distinguish inbound
packets on the tunnel from LODI_NAS1 from those inbound from LODI_NAS2. During tunnel
setup to LODI_NAS1, therefore, PERRIS_HGW1 assigns the unique CLID 2 and
communicates this to LODI_NAS1 via the Assigned CLID eld in a L2F_CONF message.
Thereafter, whenever LODI_NAS1 needs to send L2F tunnel packets to PERRIS_HGW1, it
puts the number 2 in the Client ID eld.
MID=18 (Client B)
Remote Access
Client B
Remote Access
Client A
NAS
MID=17 (Client A)
L2F Tunnel
Home Gateway
PPP
PPP
CH01i.book Page 15 Friday, April 30, 2004 8:58 AM
16 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
In simple terms, during tunnel setup, PERRIS_HGW1 says to LODI_NAS1, Whenever you
want to send tunnel packets to me, please uniquely identify them with the CLID 2 so that I will
know that they are packets from you. Remember that this process is bidirectional, so
LODI_NAS1 also communicates a locally unique CLID to PERRIS_HGW1.
Figure 2-5 illustrates this concept.
Figure 2-5 Identification of Tunnel Packets Using CLIDs
In Figure 2-5, PERRIS_HGW1 is receiving L2F tunnel packets from both LODI_NAS1 and
LODI_NAS2. It is able to distinguish these packets by examining the CLID eld.
The next eld in the packet header is Length. The Length eld is 16 bits long, and it reects the
length of the header and payload but does not include the checksum if one is present. The Offset
eld, if present, is used to specify how many bytes after the L2F header the payload starts.
For some transport architectures, it might be more efcient if the payload is aligned with a
32-bit boundary, and the Offset eld can be used to ensure this (with an offset of 0). The Offset
is present only if the F bit is set.
The Key is a 32-bit eld, is only present if the K bit is set, and is used to authenticate a tunnel
peer. This prevents tunnel packets from being spoofed by another source.
LODI_NAS1
LODI_NAS2
PERRIS_HGW1
CLID=2
CLID=1
CH01i.book Page 16 Friday, April 30, 2004 8:58 AM
Technical Overview of L2F 17
The Key is calculated as follows:
1 During tunnel establishment, each end of the tunnel sends a challenge to its peer in an
L2F_CONF message.
2 This challenge contains a random number. The recipient of this challenge calculates a
128-bit hash value based on the random number and a shared password (tunnel secret).
3 The recipient then breaks the 128-bit hash into four parts, exclusive-ORs (XORs) them
together, and sends the resultant hash value in the Key eld back to its tunnel peer (NAS
or Home Gateway). Note that the original 128-bit hash value is also sent to the tunnel peer
during tunnel authentication.
4 The originator of the challenge calculates its own hash value based on the same random
number and the shared password and compares it to the hash value received. If the two
hash values match, authentication is successful.
The 32-bit Key, once calculated, is carried in all tunnel packets for the duration of its lifetime.
Next in the packet comes the L2F payload. This is used to carry either L2F management
messages or PPP frames depending on the packet type.
Finally, if the C bit is set, a 16-bit checksum is appended to the packet. The checksum is
calculated over the entire L2F packet, starting with the header and including the payload.
L2F Management Messages
As previously mentioned, if the L2F header has a value of 0x01 (L2F_PROTO) in the Protocol
eld, the packet is a tunnel management packet. Within the payload of a tunnel management
packet, various options and suboptions can be carried. The option specied dictates what kind
of management message the packet is, whereas the suboptions carry any data associated with
that particular message type.
Table 2-2 summarizes the available options and their corresponding suboptions.
Table 2-2 Tunnel Management Packet Payload Options
Option Suboption Suboption Value Description
L2F_CONF (0x01) L2F_CONF_NAME 0x02 Name of peer sending L2F_CONF
L2F_CONF_CHAL 0x03 Random number challenge
L2F_CONF_CLID 0x04 Assigned CLID for peer use
L2F_OPEN (0x02) L2F_OPEN_NAME 0x01 Username received from remote access
client
L2F_OPEN_CHAL 0x02 Challenge Handshake Authentication
Protocol (CHAP) challenge sent by
NAS to remote access client
continues
CH01i.book Page 17 Friday, April 30, 2004 8:58 AM
18 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
As you can see, if a L2F_CONF message is sent, three suboptions can be carried along with it:
L2F_CONF_NAME, L2F_CONF_CHAL, and L2F_CLID. Similarly, if the message is an
L2F_OPEN, the suboptions that can be carried range from L2F_OPEN_NAME to
L2F_REQ_LCP0. When an L2F_CLOSE message is sent, the two suboptions can be carried
are L2F_CLOSE_WHY and L2F_CLOSE_STR. Finally, if the message is either an
L2F_ECHO or an L2F_ECHO_RESP, no suboptions can be carried.
The sections that follow describe the function of the options and suboptions in greater detail.
L2F Tunnel Establishment
Tunnel establishment begins with the reception of a PPP connection by the NAS. At this stage,
the NAS goes through the Link Control Protocol (LCP) negotiation phase with the remote
client, with options such as compression, callback, and authentication protocol being
negotiated.
As soon as the LCP negotiation phase has been completed, the NAS and the remote client move
onto authentication. A Challenge Handshake Authentication Protocol (CHAP) challenge is now
sent by the NAS to the client. Note that although either CHAP or Password Authentication
Protocol (PAP) could be used for authentication, this chapter assumes that CHAP is used.
L2F_OPEN_RESP 0x03 1. Tunnel authentication response
2. Response from remote access client
to NAS challenge (hash value, if
CHAP)
L2F_ACK_LCP1 0x04 Last LCP CONFACK received from
remote access client by NAS
L2F_ACK_LCP2 0x05 Last LCP CONFACK sent by NAS to
remote access client
L2F_OPEN_TYPE 0x06 Type of authentication used
L2F_OPEN_ID 0x07 ID associated with CHAP challenge
L2F_REQ_LCP0 0x08 First LCP CONFREQ received from
remote access client
L2F_CLOSE (0x03) L2F_CLOSE_WHY 0x01 Reason code for close
L2F_CLOSE_STR 0x02 ASCII string description of close reason
L2F_ECHO (0x04) (no suboptions) Keepalive
L2F_ECHO_RESP (0x05) (no suboptions) Response to L2F_ECHO
Table 2-2 Tunnel Management Packet Payload Options (Continued)
Option Suboption Suboption Value Description
CH01i.book Page 18 Friday, April 30, 2004 8:58 AM
Technical Overview of L2F 19
Upon receipt of the CHAP challenge, the remote client takes the random number in the
challenge (call it Random3), the Challenge ID, and the CHAP password and calculates a
Message Digest 5 (MD5) hash value (call it Hash3). This hash value is transmitted back to the
NAS via a CHAP response message.
At this point, the NAS performs a partial authentication on the CHAP response. The NAS does
not examine the hash value contained within the CHAP response packet as it normally would
but looks at the senders name (which is also contained within the response). If this PPP
connection is one that should be tunneled to a Home Gateway, the senders name should be in
the format username@domain_name. The domain name indicates to the NAS to which Home
Gateway this PPP connection should be tunneled.
It is worth noting that this delimiter character (@) can be modied on the NAS using the
command vpdn domain-delimiter.
This association of user to tunnel can also be based on the Dialed Number Information Service
(DNIS) string. The DNIS is the dialed number, and it is present in ISDN Q.931 messages passed
from the ISDN switch to the NAS during call setup. This means that, for example, if a remote
access client dials the number 555-1234 to access the NAS, the NAS will use this number to
associate the user to a L2F tunnel.
The user-to-tunnel association can also be established on a per-username basis. In this case, the
NAS sends the complete username to an authentication, authorization, and accounting (AAA)
server, and the AAA server responds with tunnel information based on this username.
Conguration of per-user VPDN is beyond the scope of this chapter, but more details can be
found at the following URL:
http://www.cisco.com/en/US/tech/tk801/tk703/
technologies_conguration_example09186a0080094860.shtml
Once the user-to-tunnel association has been made, the NAS either initiates tunnel setup to the
appropriate Home Gateway, or if a tunnel already exists, initiates a new L2F session for the PPP
connection within that tunnel.
In this example, assume that the tunnel is not yet in existence. The NAS initiates tunnel setup
by sending a L2F_CONF message. Figure 2-6 illustrates the L2F_CONF sent by the NAS to
the Home Gateway.
Within the L2F packet header, the protocol type eld is set to 0x01 (L2F_PROTO), which
indicates that this is a management message. The Sequence Number, MID, CLID, and Key are
all set to a value of 0. Contained within the payload is the L2F_CONF (option 0x01) itself.
The L2F_CONF message contains within it the following suboptions:
L2F_CONF_NAME (name of the tunnel initiating NAS)
L2F_CONF_CHAL (random number challenge)
L2F_CONF_CLID (assigned Client ID)
CH01i.book Page 19 Friday, April 30, 2004 8:58 AM
20 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
Figure 2-6 L2F_CONF Sent by the NAS
In this example, assume that the NAS has chosen an assigned CLID of 34 (which is locally
unique to the NAS).
Figure 2-7 represents this packet.
Figure 2-7 L2F_CONF Message Sent by the NAS
Notice that a checksum is omitted in this example.
The receiving Home Gateway rst conrms that the incoming L2F_CONF message is from a
recognized NAS. If it is, the Home Gateway takes the random number specied in
Remote Access
Client
NAS
PSTN/
ISDN
Home Gateway
Service Provider
Backbone
1. LCP
Negotiation
2. Partial PPP
Authentication
3. L2F_CONF
L2F Header:
Protocol Type = L2F_PROTO (0x01)
Sequence Number (Seq) = 0
Multiplex ID (MID) = 0
Client ID (CLID) = 0
Key = 0
L2F Payload:
Option (Message Type) = L2F_CONF (0x01)
Suboptions:
L2F_CONF_NAME = (NAS Name)
L2F_CONF_CHAL = (Random Number: Random1)
L2F_CONF_CLID = (Assigned CLID, e.g. 34)
CH01i.book Page 20 Friday, April 30, 2004 8:58 AM
Technical Overview of L2F 21
L2F_CONF_CHAL (call it Random1) and the tunnel secret (password) corresponding to the
NASs name (specied in L2F_CONF_NAME suboption) and performs a hash.
The password corresponding to the NASs name is stored either locally on the Home Gateway
(username nas_name password password) or on an authentication server (for example, a
Remote Authentication Dial-In User Service [RADIUS] server).
If the L2F_CONF is not from a recognized NAS, the Home Gateway terminates tunnel setup.
Once the L2F_CONF has been accepted, the Home Gateway is ready to reply to the NAS. At
this point, the Home Gateway responds to the NAS with its own L2F_CONF message. This
serves as recognition of the NASs tunnel setup request.
Figure 2-8 illustrates the L2F_CONF sent by the Home Gateway.
Figure 2-8 L2F_CONF Sent by the Home Gateway
Within the L2F header, the protocol eld is set to 0x01 (L2F_CONF); the Sequence Number,
MID, and Key are all set to a value of 0; and the Client ID is set to 34 (the Assigned CLID from
the NAS).
The L2F_CONF message itself is contained within the payload of the L2F packet. Again, a
number of suboptions are included:
The L2F_CONF_NAME is set to be the name of the Home Gateway.
L2F_CONF_CHAL contains a random number (call it Random2).
L2F_CONF_CLID contains a CLID assigned by and locally unique on the Home
Gateway (in this example, the value 38).
Figure 2-9 illustrates this packet.
Remote Access
Client
NAS
PSTN/
ISDN
Home Gateway
Service Provider
Backbone
1. LCP
Negotiation
2. Partial PPP
Authentication
3. L2F_CONF
4. L2F_CONF
CH01i.book Page 21 Friday, April 30, 2004 8:58 AM
22 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
Figure 2-9 L2F_CONF Message Sent by the Home Gateway
The Home Gateway has now received a L2F_CONF from the NAS, and the NAS has received
a L2F_CONF from the Home Gateway.
The NAS now prepares to reply to, and to be authenticated by, the Home Gateway. To do this,
the NAS calculates a hash (a CHAP-like hash) based on the random number, Random2,
received from the Home Gateway in its L2F_CONF (see Figure 2-9), together with the tunnel
secret (password). Call this hash Hash2, because it corresponds to Random2.
The NAS uses an L2F_OPEN message to communicate the resultant hash value, Hash2, to the
Home Gateway.
Figure 2-10 shows the L2F_OPEN sent by the NAS.
The packet header for this message is constructed as follows:
The Protocol eld contains the value 0x01.
The Sequence eld (number) is set to 1 (the next exchange in the sequence, following the
exchange of L2F_CONF messages).
The MID eld is set to 0.
The CLID is set to 38 (the CLID assigned by the Home Gateway).
The Key is set to the value Hash2 (32-bit).
The payload of the packet contains the L2F_OPEN message itself and suboption
L2F_OPEN_RESP. The L2F_OPEN_RESP contains the entire 128-bit authentication hash
value.
L2F Header:
Protocol Type = L2F_PROTO
Sequence Number (Seq) = 0
Multiplex ID (MID) = 0
Client ID (CLID) = 34
Key = 0
L2F Payload:
Option (Message Type) = L2F_CONF
Suboptions:
L2F_CONF_NAME = (Home Gateways Name)
L2F_CONF_CHAL = (Random Number: Random2)
L2F_CONF_CLID = (Assigned CLID, e.g. 38)
CH01i.book Page 22 Friday, April 30, 2004 8:58 AM
Technical Overview of L2F 23
Figure 2-10 L2F_OPEN sent by the NAS
Figure 2-11 shows the L2F_OPEN message sent by the NAS.
Figure 2-11 The L2F_OPEN Message Sent by the NAS
Remote Access
Client
NAS
PSTN/
ISDN
Home Gateway
Service Provider
Backbone
LCP
Negotiation
Partial PPP
Authentication
L2F_CONF
L2F_CONF
L2F_OPEN
L2F Header:
Protocol Type = L2F_PROTO
Sequence Number (Seq) = 1
Multiplex ID (MID) = 0
Client ID (CLID) = 38
Key = 32-bit hash2
L2F Payload:
Option (Message Type) = L2F_OPEN
Suboptions:
L2F_OPEN_RESP = 128-bit Hash2
CH01i.book Page 23 Friday, April 30, 2004 8:58 AM
24 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
Upon receipt of the L2F_OPEN message, the Home Gateway authenticates the NAS. This is
done by comparing the received hash value (Hash2) to a hash value calculated locally based on
the same input values (Random2 and the tunnel password). If the hash values match, the Home
Gateway authenticates the NAS. If the values do not match, then tunnel setup is terminated.
Once it has authenticated the NAS, the Home Gateway sends an L2F_OPEN message to the
NAS with Hash1 (hash computed on Random1, plus the tunnel secret) being carried in the
packet.
Figure 2-12 illustrates the L2F_OPEN sent by the Home Gateway.
Figure 2-12 L2F_OPEN Sent by the Home Gateway
The packet format is shown in Figure 2-13, and is exactly the same as the L2F_OPEN sent by
the NAS to the Home Gateway, with the protocol eld set to 0x01 (L2F_PROTO), the Sequence
Number set to 1, the MID is set to 0, and the CLID is set to 34 (the CLID assigned by the NAS).
The Key is set to be hash1 (32-bit). Finally, the payload of the packet carries the message type
itself (L2F_OPEN), with suboption L2F_OPEN_RESP.
The NAS compares the received hash value (hash1) to its own hash value calculated based on
the same inputs (Random1 and the tunnel password). If the two hash values match, the NAS
authenticates the Home Gateway. If not, the NAS terminates tunnel setup.
Remote Access
Client
NAS
PSTN/
ISDN
Home Gateway
Service Provider
Backbone
LCP
Negotiation
Partial PPP
Authentication
L2F_CONF
L2F_CONF
L2F_OPEN
L2F_OPEN
CH01i.book Page 24 Friday, April 30, 2004 8:58 AM
Technical Overview of L2F 25
Figure 2-13 Packet Format of the L2F_OPEN Sent by the Home Gateway to the NAS
Assuming that the NAS successfully authenticates the Home Gateway, both ends of the tunnel
have now authenticated each other and are now ready to move on to the establishment of L2F
sessions within the tunnel.
L2F Session Establishment
Now that the L2F tunnel has been established between the NAS and the Home Gateway, the
NAS can proceed to pass the LCP and authentication data negotiated with the remote access
client to the Home Gateway.
Youll remember that when the client rst dialed into the NAS, the NAS issued a CHAP
challenge to the client. Within the challenge was an ID value, together with a random number
(Random3). The client responded to the challenge with a hash value (call it hash3) calculated
from the random number (Random3), the ID, and the secret password.
Although the NAS issued the CHAP challenge, it cannot fully authenticate the client because
it does not have the password. In fact, the logical endpoint of the PPP connection is responsible
for authenticating the client, and that is the Home Gateway.
The NAS needs to pass the hash value, hash3, together with the clients user name and the
CHAP challenge ID value on to the Home Gateway. To do this, it sends another L2F_OPEN
message.
Figure 2-14 shows the session setup L2F_OPEN sent by the NAS.
L2F Header:
Protocol Type = L2F_PROTO
Sequence Number (Seq) = 1
Multiplex ID (MID) = 0
Client ID (CLID) = 34
Key = 32-bit hash1
L2F Payload:
Option (Message Type) = L2F_OPEN
Sub-Options:
L2F_OPEN_RESP = 128-bit Hash1
CH01i.book Page 25 Friday, April 30, 2004 8:58 AM
26 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
Figure 2-14 Session Setup L2F_OPEN Sent by the NAS
The L2F_OPEN message header takes the following form:
The Protocol eld contains the value 0x01 (because this is still a tunnel management
message).
The Sequence number eld is set to the value 2 (this is the next in the sequence).
The MID eld is set to 1.
The CLID is set to 38.
The Key is set to the value Hash2.
The payload contains the message type (option) L2F_OPEN. A number of suboptions are
included:
L2F_OPEN_TYPE (indicating authentication type)
L2F_OPEN_NAME (the remote access clients username)
L2F_OPEN_CHAL (the random number used to challenge the client [Random3])
L2F_OPEN_RESP (the hash value received in the response, Hash3)
L2F_OPEN_ID (the ID used in the challenge from the NAS to the client).
Remote Access
Client
NAS
PSTN/
ISDN
Home Gateway
Service Provider
Backbone
1. LCP
Negotiation
2. Partial PPP
Authentication
3. L2F_CONF
4. L2F_CONF
5. L2F_OPEN
6. L2F_OPEN
7. L2F_OPEN
CH01i.book Page 26 Friday, April 30, 2004 8:58 AM
Technical Overview of L2F 27
In addition to client authentication information, the NAS passes some client LCP negotiation
messages to the Home Gateway:
The last LCP Congure-Ack (CONFACK) sent from the remote access client to the NAS
(L2F_ACK_LCP1)
The last CONFACK sent from the NAS to the client (L2F_ACK_LCP2)
The rst Congure-Request (CONFREQ) sent from the client to the NAS
(L2F_REQ_LCP0).
LCP negotiation messages passed by the NAS to the Home Gateway can allow the Home
Gateway to much more rapidly congure LCP for communication with the client. If it accepts
the options in the CONFACKs, there is no need to renegotiate with the client. However, the
Home Gateway can renegotiate LCP with the client if it so wishes.
LCP renegotiation can be based on the options specied in the rst CONFREQ sent by the
client but not agreed to by the NAS.
It is worth noting that the MID value has now changed from 0 to a nonzero value. This is
because this message corresponds to the L2F session, rather than being a purely tunnel
management message (which would have a MID value of 0). Note that MID values are assigned
based on being the next available.
Figure 2-15 illustrates this L2F_OPEN message.
Figure 2-15 Session L2F_OPEN Sent by the Home Gateway
L2F Header:
Protocol Type = L2F_PROTO
Sequence Number (Seq) = 2
Multiplex ID (MID) = 1
Client ID (CLID) = 38
Key = 32-bit hash2
L2F Payload:
Option (Message Type) = L2F_OPEN
Suboptions:
L2F_OPEN_TYPE = CHAP
L2F_OPEN_NAME = (remote access clients name)
L2F_OPEN_CHAL = Random3
L2F_OPEN_RESP = Hash3
L2F_OPEN_ID = (ID used by CHAP challenge)
L2F_ACK_LCP1 = (CONFACK from client)
L2F_ACK_LCP2 = (CONFACK from NAS)
L2F_REQ_LCP0 = (CONFREQ from client)
CH01i.book Page 27 Friday, April 30, 2004 8:58 AM
28 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
Upon receiving this L2F_OPEN message, the Home Gateway responds to the NAS with a
L2F_OPEN. This L2F_OPEN serves to conrm acceptance of the client L2F session.
Figure 2-16 shows the L2F_OPEN sent from the Home Gateway to the NAS.
Figure 2-16 L2F_OPEN from the Home Gateway to the NAS
The L2F_OPEN message header takes the following format:
The Protocol eld is set to 0x01 (L2F_PROTO).
The Sequence number eld is set to 2.
The MID is set to 1.
The CLID is set to 34.
The Key is set to Hash1.
The payload of the packet contains the L2F_OPEN message itself. Figure 2-17 illustrates this
packet.
Remote Access
Client
NAS
PSTN/
ISDN
Home Gateway
Service Provider
Backbone
1. LCP
Negotiation
2. Partial PPP
Authentication
3. L2F_CONF
4. L2F_CONF
5. L2F_OPEN
6. L2F_OPEN
7. L2F_OPEN
8. L2F_OPEN
CH01i.book Page 28 Friday, April 30, 2004 8:58 AM
Technical Overview of L2F 29
Figure 2-17 Session L2F_OPEN Message
The NAS, having received this acceptance message from the Home Gateway, begins to
transparently forward PPP frames between the client and the Home Gateway.
Figure 2-18 shows the forwarding of PPP frames between the Home Gateway and the remote
access client.
It is worth qualifying the statement word transparently. PPP frames are unescaped, and any bit-
stufng is removed before forwarding. Additionally, PPP ags (excluding the address and
control ags, unless negotiated away) and the CRC are omitted.
PPP frames (from the remote access client) forwarded by the NAS to the Home Gateway are
tunneled within L2F_PPP packets. This means that the packet headers now take the following
form:
The Protocol eld is set to 0x02 (L2F_PPP, indicating PPP in payload).
The sequence number is set to 0 (assuming that sequence numbering is not used).
The MID is set to 1; the CLID is set to 38.
The Key is set to Hash2.
The payload contains the PPP frame.
L2F Header:
Protocol Type = L2F_PROTO
Sequence Number (Seq) = 2
Multiplex ID (MID) = 1
Client ID (CLID) = 34
Key = 32-bit Hash1
L2F Payload:
Option (Message Type) = L2F_OPEN
CH01i.book Page 29 Friday, April 30, 2004 8:58 AM
30 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
Figure 2-18 NAS Forwards PPP Frames
Similarly, PPP frames forwarded by the Home Gateway to the NAS are carried in L2F_PPP
packets, with the packet header constructed as follows:
The Protocol eld is set to 0x02.
The Sequence Number is set to 0; the MID is set to 1.
The CLID is set to 34.
The Key is set to Hash1.
The payload again contains the PPP frame.
Note how the Sequence number is now 0 for PPP frames sent between the NAS and the Home
Gateway. This is because it is mandatory only for tunnel management packets to contain
sequence numbering.
Remote Access
Client
NAS
PSTN/
ISDN
Home Gateway
Service Provider
Backbone
1. LCP
Negotiation
2. Partial PPP
Authentication
3. L2F_CONF
4. L2F_CONF
5. L2F_OPEN
6. L2F_OPEN
7. L2F_OPEN
8. L2F_OPEN
9. PPP
Frames
CH01i.book Page 30 Friday, April 30, 2004 8:58 AM
Technical Overview of L2F 31
Figure 2-19 illustrates the form of PPP frames tunneled within L2F packets sent from the NAS
to the Home Gateway.
Figure 2-19 L2F_PPP Packets Sent by the NAS
Figure 2-20 shows the form taken by PPP frames tunneled from the Home Gateway to the NAS.
Figure 2-20 L2F_PPP Packets Sent by the Home Gateway
L2F Header:
Protocol Type = L2F_PPP
Sequence Number (Seq) = 0
Multiplex ID (MID) = 1
Client ID (CLID) = 38
Key = 32-bit Hash2
L2F Payload:
PPP Frame
L2F Header:
Protocol Type = L2F_PPP
Sequence Number (Seq) = 0
Multiplex ID (MID) = 1
Client ID (CLID) = 34
Key = 32-bit Hash1
L2F Payload:
PPP Frame
CH01i.book Page 31 Friday, April 30, 2004 8:58 AM
32 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
L2F Tunnel Maintenance
RFC 2341 species a keepalive mechanism for L2F tunnels. This consists of sending
L2F_ECHO and L2F_ECHO_RESP messages. The L2F_ECHO is not a mandatory
requirement for an implementation of L2F, but should an L2F peer receive an L2F_ECHO
message, it is mandatory that the peer replies with a L2F_ECHO_RESP.
Figure 2-21 illustrates the L2F keepalive mechanism.
Figure 2-21 L2F Keepalive Mechanism
A recommended practice is that if a tunnel peer (NAS or Home Gateway) transmits at least ve
consecutive L2F_ECHOs without receiving a L2F_ECHO_RESP in reply, it (the NAS or Home
Gateway) should assume that its peer has terminated the tunnel connection.
The L2F_ECHO is encoded as option 0x04, with the MID set to 0 (tunnel management packet).
It is possible for L2F to include extra data in the payload, and if extra data is present, it must be
preserved in the L2F_ECHO_RESP (option 0x05). A possible usage of this extra data is to
associate an L2F_ECHO_RESP with a particular L2F_ECHO.
Figure 2-22 represents the L2F_ECHO.
Figure 2-23 illustrates the L2F_ECHO_RESP.
You will notice that the nonzero sequence numbering in the L2F_ECHO and
L2F_ECHO_RESP. This is because, as L2F management messages, these two messages must
carry sequence numbering.
The Key values carried in the L2F_ECHO and L2F_ECHO_RESP messages are the same as
those calculated in the tunnel establishment phase (Hash1 or Hash2). Similarly, the CLID
corresponds to the CLIDs assigned during tunnel establishment.
Remote Client
NAS
PSTN/
ISDN
Home Gateway
Service Provider
Backbone
1. L2F_ECHO
2. L2F_ECHO_RESP
CH01i.book Page 32 Friday, April 30, 2004 8:58 AM
Technical Overview of L2F 33
Figure 2-22 L2F_ECHO Message
Figure 2-23 L2F_ECHO_RESP Message
L2F Header:
Protocol Type = L2F_PROTO
Sequence Number (Seq) = (Non-zero)
Multiplex ID (MID) = 0
Client ID (CLID) = (Non-zero)
Key = 32-bit Hash
L2F Payload:
L2F_ECHO (0x04)
(Possible Other Data)
L2F Header:
Protocol Type = L2F_PROTO
Sequence Number (Seq) = (Non-zero)
Multiplex ID (MID) = 0
Client ID (CLID) = (Non-zero)
Key = 32-bit Hash
L2F Payload:
L2F_ECHO_RESP (0x05)
(Preserved Other Data, if Present in L2F_ECHO)
CH01i.book Page 33 Friday, April 30, 2004 8:58 AM
34 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
L2F Tunnel Teardown
The nal action in the life of tunnel is, of course, termination. Tunnel termination can be caused
by several factors, for example reception of an invalid message type, reception of a PPP
TERMREQ (Termination Request) on the last PPP connection in a tunnel, or simply execution
of the command clear vpdn tunnel.
It is worth pointing out that the reception of packets with an invalid key will not cause the tunnel
to be terminated. The fact that L2F tunnels are not terminated when packets with an invalid key
are received prevents denial-of-service attacks against L2F tunnels.
Once an event that mandates tunnel teardown has occurred, the endpoint wishing to tear down the
tunnel (either the NAS or the Home Gateway) transmits an L2F_CLOSE message to its peer.
Figure 2-24 illustrates the L2F_CLOSE message.
Figure 2-24 NAS Sends an L2F_CLOSE Message
Figure 2-25 illustrates the format of the L2F_CLOSE message.
Figure 2-25 L2F_CLOSE Message Format
Remote Client
NAS
PSTN/
ISDN
Home Gateway
Service Provider
Backbone
L2F_CLOSE
L2F Header:
Protocol Type = L2F_PROTO
Sequence Number (Seq) = (Nonzero)
Multiplex ID (MID) = 0
Client ID (CLID) = (Nonzero)
Key = 32-bit hash
L2F Payload:
L2F_CLOSE (0x03)
Suboptions:
L2F_CLOSE_WHY(0x01) = (Reason, Optional)
L2F_CLOSE_STR(0x02) = (ASCII String, Optional)
CH01i.book Page 34 Friday, April 30, 2004 8:58 AM
Conguring L2F 35
The L2F_CLOSE_WHY suboption, which can optionally be included in the L2F_CLOSE
message, is 4 octets long. It is used to inform the NAS of the reason for a tunnel setup failure
or tunnel termination. An implementer might choose not to indicate the reason for declining
certain tunnels. This helps to prevent attackers from gaining valuable information that would
help them to progress their attacks.
The reason for tunnel or session setup failure is encoded in suboption L2F_CLOSE_WHY
(0x01), as per Table 2-3.
Additionally, L2F_CLOSE_WHY failure codes that can be masked by the value 0xFF000000
(0x01000000 to 0xFF000000) are reserved for vendor-specied codes.
The L2F_CLOSE_STR suboption can also be included in the L2F_CLOSE message. This is an
ASCII string that describes the reason for the tunnel termination.
Conguring L2F
Misconguration is the most common cause of L2F tunnel failure. Although L2F conguration
is not a primary goal of this chapter, this section discusses basic L2F conguration.
Table 2-3 Tunnel/Session Setup Failure Reason Codes
L2F_CLOSE_WHY Failure Reason Failure Code
Authentication failure 0x00000001
Out of resources 0x00000002
Administrative intervention 0x00000004
User quota exceeded 0x00000008
Protocol error 0x00000010
Unknown user 0x00000020
Incorrect password 0x00000040
PPP conguration incompatible 0x00000080
Wrong multilink PPP destination 0x00000100
Carrier loss 0x00000200
User disconnect 0x00000400
PPP disconnect 0x00000800
Tunnel shutdown 0x00001000
Session limit / Softshut 0x00002000
No sessions 0x00004000
CH01i.book Page 35 Friday, April 30, 2004 8:58 AM
36 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
The next two sections step through the congurations for the NAS and the Home Gateway.
Conguring the L2F NAS
The conguration for the NAS discussed here assumes a typical hardware conguration
including either E1 or T1 ISDN Primary Rate Interfaces (PRIs), together with asynchronous
digital (MICA) modems.
Conguration of the NAS involves nine basic steps, as summarized in the list that follows:
Step 1 Congure the E1/T1 controllers.
Step 2 Congure global ISDN parameters.
Step 3 Congure the D channels.
Step 4 Congure parameters for asynchronous lines.
Step 5 Congure group asynchronous interfaces.
Step 6 Congure remote AAA (optional).
Step 7 Congure the tunnel secrets.
Step 8 Globally enable VPDNs.
Step 9 Congure the VPDN groups.
It is worth pointing out that many possible permutations exist; however, this section
concentrates on only the most common conguration .
The sections that follow discuss each step of the conguration in detail.
Step 1: Congure the E1/T1 Controllers
The rst step is to congure either the E1 or T1 controllers. Conguration of the E1 or T1
controllers involves specifying the framing, line code, clock source, and timeslots.
Example 2-1 shows a sample conguration of an E1 controller.
Note that in this example, the framing is CRC4 (framing crc4), the linecode is HDB3 (linecode
hdb3), and the clock source is line (clock source line). These are the defaults and so do not
appear in the conguration.
Ensure that the E1/T1 framing, linecode, and clock source are congured per your service
providers recommendations.
Example 2-1 Specifying the Framing, Line Code, Clock Source, and Timeslots for an E1 Controller
controller E1 0/0
pri-group timeslots 1-31
CH01i.book Page 36 Friday, April 30, 2004 8:58 AM
Conguring L2F 37
Step 2: Congure Global ISDN Parameters
The next step is to congure global ISDN parameters. In Example 2-2, only the global ISDN
switch-type is specied.
Example 2-2 species the Primary-net5 ISDN switch-type. This is an ISDN switch-type used
in Europe, Australia, New Zealand, and Asia. Make sure that the ISDN switch type is specied
per your providers specications.
Step 3: Congure the D Channels
Next, you should congure the ISDN D channels to receive asynchronous modem calls. To do
this, the conguration in Example 2-3 is required.
In Example 2-3, no IP address is applied to the physical address. This is because, in this
example, no ISDN calls are being terminated on the NAS.
The ISDN primary-net5 switch type is congured next. Note that this is not strictly necessary,
as it has already been congured globally.
The incoming voice-modem command is essential, and it routes any incoming voice
(asynchronous modem) calls to the internal digital MICA modems.
Step 4: Congure Parameters for Asynchronous Lines
Once the conguration of the E1/T1 controllers and the D channel conguration is completed,
it is time to congure the modems and their corresponding asynchronous lines.
Example 2-4 shows the conguration of the asynchronous lines.
Example 2-2 Configuring the Global ISDN Switch-type
isdn switch-type primary-net5
Example 2-3 Configuring ISDN Channels to Receive Asynchronous Modem Calls
interface Serial0/0:15
no ip address
isdn switch-type primary-net5
isdn incoming-voice modem
no cdp enable
Example 2-4 Configuring the Modem and Corresponding Asynchronous Lines
line 33 38
modem InOut
modem autoconfigure type mica
autoselect ppp
CH01i.book Page 37 Friday, April 30, 2004 8:58 AM
38 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
The command line 33 38 allows you to congure a group of asynchronous lines together in the
same way. In Example 2-4, there are six internal digital modems on asynchronous lines 33 to
38. Use the show line command to conrm line numbering.
The rst command in the line conguration is the modem InOut command. This allows the
modems to both receive and initiate calls. The modem autocongure type mica command
allows the NAS to automatically congure the modems on lines 33 to 38. Finally, the autoselect
ppp command allows PPP to be autodetected on the lines and PPP framing to be applied.
This line conguration is applied to all six lines without having to congure the lines
individually.
Step 5: Congure Group Asynchronous Interfaces
The corresponding logical conguration is now applied to the asynchronous interfaces. It is
again possible to apply this conguration individually or to a group of interfaces together. A
group conguration is usually used because it saves time and ensures that all interfaces are
consistently congured.
Example 2-5 shows the conguration for the asynchronous interfaces.
The rst command in the conguration is no ip address. The command no IP address is
congured on the group-async interface because no PPP connections from remote access
clients are being terminated locally on the NAS in this example.
The command encapsulation ppp congures the interface to use a PPP frame type.
The next command, async mode interactive, allows remote users to start interactive mode on
the lines. To prevent users from starting an interactive shell, use the async mode dedicated
command.
The no peer default default ip address command congures the NAS not to supply the remote
access client with an IP address (it is instead supplied by the PPP connection endpointthe
Home Gateway).
Next, ppp authentication chap congures CHAP authentication. Finally, the group-range
33-38 command causes the group-async 1 interface conguration to be applied to lines 33 to 38.
Example 2-5 Configuring Asynchronous Interfaces
interface Group-Async1
no ip address
encapsulation ppp
async mode interactive
no peer default ip address
no cdp enable
ppp authentication chap
group-range 33 38
CH01i.book Page 38 Friday, April 30, 2004 8:58 AM
Conguring L2F 39
Note that the ppp authentication chap command allows the NAS to partially authenticate
remote access clients. It allows the NAS to challenge the client and to use its response to match
to the appropriate L2F tunnel. The CHAP response from the client is forwarded to the Home
Gateway via an L2F_OPEN message (see the earlier section entitled L2F Tunnel
Establishment for more details).
Step 6: Congure Remote AAA (Optional)
Remote AAA can be enabled next. RADIUS and Terminal Access Controller Access Control
System + (TACACS+) are the two options. Because remote access client PPP connections are
terminated on the Home Gateway, remote AAA is necessary on the NAS only if you are
conguring per-user VPDN, if you have tunnel denitions (tunnel conguration) stored on a
AAA server, or if you are also terminating some remote access client connections locally rather
than tunneling them to the Home Gateway via L2F.
Although a detailed discussion of tunnel denitions stored on a AAA server is beyond the scope
of this chapter, more information can be found in the case study entitled Miscongured L2F
Tunnel Denition on the AAA Server toward the end of the chapter.
In this particular environment, RADIUS is the more popular AAA server type.
Example 2-6 shows a simple remote AAA conguration.
The aaa new-model command globally enables AAA.
Authentication at login is then set with the default method list (aaa authentication login
default group radius local). The default method list species that the rst method used for
authentication should be radius, with the local database being used in the event that the
RADIUS server cannot be contacted. Note that the aaa authentication login command is not
necessary for L2F, but it is shown here as part of a complete AAA conguration.
Authentication for PPP is then enabled with the default method list (aaa authentication ppp
default local group radius). This method list species that PPP should authenticate rst
against a local database, and then against a RADIUS server.
AAA authorization for network connections is then enabled (aaa authorization network
default group radius). Again, authorization is controlled by the RADIUS server.
Example 2-6 Sample Remote AAA Configuration
aaa new-model
aaa authentication login default group radius local
aaa authentication ppp default local group radius
aaa authorization network default group radius
aaa accounting network default start-stop group radius
!
radius-server host 172.16.1.5 auth-port 1645 acct-port 1646 key cisco
CH01i.book Page 39 Friday, April 30, 2004 8:58 AM
40 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
The command radius-server ip_address auth-port 1645 acct-port 1646 key key is used to
congure the RADIUS server IP address and the shared key that is used to encrypt user
passwords when sent between the NAS and the RADIUS server. The authentication/
authorization and accounting ports are left at their defaults of UDP 1645 and 1646, respectively.
Note that these defaults work with the Cisco Access Control Server (Cisco ACS) and other early
implementations of RADIUS. The ofcial ports for authentication/authorization and
accounting are, however, 1812 and 1813, respectively.
Finally, the command aaa accounting network default start-stop group radius enables start-
stop accounting for network connections, with accounting messages being saved to the
RADIUS server. Again, conguration of accounting is not mandatory on the L2F NAS, but it
is shown for completeness.
Step 7: Congure the Tunnel Secrets
The passwords used by the NAS and the Home Gateway to authenticate each other are now
congured. These can again be congured locally or on the AAA server.
To congure the tunnel secrets locally, use the following commands:
username nas_name password password
username home_gateway_name password password
Step 8: Globally Enable VPDNs
The next stage of the conguration is to globally enable Virtual Private Dialup Networks
(VPDNs), of which L2F is one type. This is achieved via the following command:
vpdn enable
Step 9: Congure the VPDN Groups
Finally, the VPDN groups need to be congured (that is, if their congurations are not stored
on the AAA server as tunnel denitions). To enable the VPDN groups, use the sample
conguration in Example 2-7.
Example 2-7 Enabling VPDN Groups on the NAS
vpdn search-order domain
vpdn-group 1
request-dialin
protocol l2f
domain mjlnet.com
initiate-to ip 172.16.2.2
CH01i.book Page 40 Friday, April 30, 2004 8:58 AM
Conguring L2F 41
The conguration of the VPDN groups is relatively easy. One VPDN group should be
congured for each tunnel.
In Example 2-7, vpdn-group 1 is congured. The group name, in this case 1, must be unique
among all VPDN groups congured on this NAS.
The second command, request dialin, congures the NAS to initiate tunnels to the Home
Gateway. This will trigger the L2F_CONF or L2F_OPEN message in the event that a tunnel or
session initiation event takes place (that is, when a client associated with this tunnel connects
to the NAS).
The protocol L2F is specied next, followed by the domain name associated with the tunnel. In
this case, the domain is mjlnet.com. This means that if a user connects with the username
user@mjlnet.com, mjlnet.com is associated with the VPDN group and causes a new tunnel
(and session) to be established to the Home Gateway if it is the rst PPP connection. Otherwise,
it causes a new session within the existing tunnel to be initiated.
Note that if you want to associate users to tunnels based on the DNIS, use the dnis dnis
command in place of the domain domain_name command.
The initiate-to ip command is self-explanatory; it indicates the IP address of the Home
Gateway to which this tunnel should be initiated.
There is one other command in Example 2-7. The vpdn search-order domain command is
optional, and it congures the NAS to match the remote access clients call to a L2F tunnel
based upon the domain name. The default search order is DNIS, and if that fails, it is the domain
name.
A sample conguration for the NAS is shown in Example 2-8.
Example 2-8 Sample Configuration for the L2F NAS
LODI_NAS1#show running-config
Building configuration...
Current configuration : 1755 bytes
version 12.1
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
service password-encryption
!
hostname LODI_NAS1
!
logging buffered 16384 debugging
no logging console
enable secret 5 $1$yD1w$LfNsZG33BvIIDWkg5ZhBq/
!
username mark password 7 030752180500
! Configure the L2F tunnel secrets
username PERRIS_HGW1 password 7 14141B180F0B
username LODI_NAS1 password 7 121A0C041104
CH01i.book Page 41 Friday, April 30, 2004 8:58 AM
42 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
!
clock timezone GMT 0
no ip source-route
ip subnet-zero
no ip domain-lookup
!
no ip bootp server
! Enable VPDNs (including L2F)
vpdn enable
! Match the users domain for user to tunnel assignment
vpdn search-order domain
!
! Configure the VPDN group for domain mjlnet.com to 172.16.2.2 (the Home Gateway)
vpdn-group 1
request-dialin
protocol l2f
domain mjlnet.com
initiate-to ip 172.16.2.2
!
! Configure the PRI switch type
isdn switch-type primary-net5
!
! Configure the E1 controller
controller E1 0/0
pri-group timeslots 1-31
!
interface FastEthernet0/0
ip address 172.16.1.1 255.255.255.0
no ip redirects
no ip proxy-arp
duplex auto
speed auto
no cdp enable
!
! Configure the D channel
interface Serial0/0:15
no ip address
isdn switch-type primary-net5
isdn incoming-voice modem
no cdp enable
!
! Configure the group asynchronous interface
interface Group-Async1
no ip address
encapsulation ppp
async mode interactive
no peer default ip address
no cdp enable
ppp authentication chap
group-range 33 38
!
Example 2-8 Sample Configuration for the L2F NAS (Continued)
CH01i.book Page 42 Friday, April 30, 2004 8:58 AM
Conguring L2F 43
Note that a static route is used in Example 2-8 for IP reachability to the Home Gateway.
Conguring the L2F Home Gateway
Compared to that for the NAS, the conguration of the Home Gateway is pretty simple. Basic
conguration of the L2F Home Gateway consists of the following six steps:
Step 1 Congure either local authentication or remote AAA conguration.
Step 2 Congure the tunnel secret.
Step 3 Globally enable VPDNs.
Step 4 Congure VPDN groups.
Step 5 Congure virtual templates.
Step 6 Create IP pools and congure DNS/WINS server addresses.
The sections that follow cover each step of the conguration in detail.
! Static route for IP reachability to the Home Gateway (PERRIS_HGW1, 172.16.2.2)
ip route 172.16.2.0 255.255.255.0 172.16.1.2
!
ip classless
ip http server
!
logging trap debugging
no cdp run
!
line con 0
password 7 070C285F4D06
login
! Configure parameters for asynchronous lines
line 33 38
modem InOut
modem autoconfigure type mica
autoselect ppp
line aux 0
line vty 0 4
password 7 030752180500
login
!
end
Example 2-8 Sample Configuration for the L2F NAS (Continued)
CH01i.book Page 43 Friday, April 30, 2004 8:58 AM
44 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
Step 1: Congure Either Local Authentication or Remote AAA Conguration
The rst step is the conguration of either local authentication or remote AAA on the Home
Gateway.
To congure a simple username and password database for remote access clients, use the
following command:
username username password password
A more scalable solution is to use remote AAA.
Example 2-9 shows the conguration of remote AAA on the Home Gateway.
The remote AAA conguration is largely the same as that for the NAS. Please refer to the
previous section for a complete explanation.
Step 2: Congure the Tunnel Secret
To congure the tunnel secret locally, use the following commands:
username nas_name password password
username home_gateway_name password password
These passwords should be the same as those on the NAS.
Step 3: Globally Enable VPDNs
The next part of the conguration again follows that for the NAS.
To enable VPDNs globally, use the following command:
vpdn enable
Step 4: Congure VPDN Groups
Conguration of the VPDN groups is slightly different than that on the NAS.
Conguration of the VPDN groups on the Home Gateway can be accomplished as follows:
vpdn-group 1
accept-dialin
protocol l2f
Example 2-9 Remote AAA on the Home Gateway
aaa new-model
!
aaa authentication login default group radius local
aaa authentication ppp default local group radius
aaa authorization network default group radius
aaa accounting network default start-stop group radius
radius-server host 10.10.10.5 auth-port 1645 acct-port 1646 key 7 1511021F0725
CH01i.book Page 44 Friday, April 30, 2004 8:58 AM
Conguring L2F 45
virtual-template 1
terminate-from hostname LODI_NAS1
The VPDN group is enabled using the vpdn-group 1 command. Again, the name of the group
must be locally unique.
The accept dialin command is used to specify that the Home Gateway accepts L2F tunnels.
Next, the virtual-template 1 command is used to specify that client PPP connections are
terminated on virtual access interfaces with conguration cloned (copied) from virtual template 1.
These virtual access interfaces are dynamically created (one per client) as the remote access
clients connect to the Home Gateway. Finally, the terminate-from command species the
hostname of the NAS from which tunnels are accepted.
Step 5: Congure Virtual Templates
The virtual template specied in the VPDN group must be congured next.
Example 2-10 shows a sample conguration of the virtual template on the Home Gateway.
Most of the conguration in Example 2-10 is fairly self-explanatory.
The virtual template is not congured with a specic IP address but instead borrows the IP
address on interface fast Ethernet 1/0 (ip unnumbered FastEthernet1/0). Note that in this
example the Home Gateway has only two physical interfaces (see Example 2-11). If the Home
Gateway has more physical interfaces, it is a good idea to borrow the IP address from a
loopback interface (a loopback interface is always in an UP state).
The command peer default ip address pool PERRIS_POOL species that the remote access
client should be assigned an IP address from address pool PERRIS_POOL.
CHAP authentication is then specied, together with multilink PPP using the ppp authentication
chap and ppp multilink commands. Note that the ppp multilink command is optional.
It is also possible to store user-specic interface conguration on a AAA server (this conguration
is downloaded to the Home Gateway as remote access clients connect). Conguration of user-
specic interface conguration on a AAA server is beyond the scope of this book, but for more
information refer to the document entitled Conguring Virtual Proles on www.cisco.com.
Note that two other commands that you may want to congure are mtu (on the virtual template
interface) and lcp renegotiation (under the VPDN group). This allows the Home Gateway to
negotiate the PPP Maximum Receive Unit (MRU) with the remote access client. This can be
important to prevent fragmentation of large packets when they are sent over the L2F tunnel.
Reassembly of the resulting fragments can cause a high processor overhead on the Home Gateway.
Example 2-10 Configuring the Virtual Template
interface Virtual-Template1
ip unnumbered FastEthernet1/0
peer default ip address pool PERRIS_POOL
ppp authentication chap
ppp multilink
CH01i.book Page 45 Friday, April 30, 2004 8:58 AM
46 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
NOTE For more information on the conguration of MTU tuning, see the article entitled MTU
Tuning for L2TP on the Cisco Web site (www.cisco.com). Although this article focuses on
L2TP, all of the principles discussed are equally applicable to L2F.
An alternative (or complementary) solution to fragmentation issues in an L2F environment is
to reduce the MTU size on the remote access client. See the following articles for more
information on this subject:
Microsoft Knowledge Base articles 159211 and 314825, available at the Microsoft Web
site (www.microsoft.com)
Adjusting IP MTU, TCP MSS, and PMTUD on Windows and Sun Systems, available
at the Cisco Web site (www.cisco.com)
Cloning of virtual access interfaces on the Home Gateway can also cause high CPU overhead.
The virtual-template template_number pre-clone number command can be used to preclone
virtual access interfaces and substantially reduce processor overhead during remote access
client connection setup.
Step 6: Create IP Pools and Congure DNS/WINS Server Addresses
The nal step is to congure the IP address pool on the Home Gateway. At the same time, any
DNS and WINS (NetBios Name) server addresses can be congured.
The IP address pool called PERRIS_POOL, together with DNS and WINS server addresses,
are congured as follows:
ip local pool PERRIS_POOL 10.10.10.50 10.10.10.59
async-bootp dns-server 10.10.10.99
async-bootp nbns-server 10.10.10.100
The pool has ten addresses in it, with the rst address being 10.10.10.50 and the last address
being 10.10.10.59.
When a remote client connects to the Home Gateway, an IP address is assigned to the client from
PERRIS_POOL. At the same time, the DNS and WINS server addresses are provided to the client.
Example 2-11 shows a sample conguration for the Home Gateway.
Example 2-11 Sample Configuration for the L2F Home Gateway
Building configuration...
Current configuration : 1714 bytes
!
version 12.1
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
service password-encryption
!
hostname PERRIS_HGW1
CH01i.book Page 46 Friday, April 30, 2004 8:58 AM
Conguring L2F 47
!
logging buffered 16384 debugging
no logging console
enable secret 5 $1$jZXl$awSeGWo.H88fjh46OjAoj1
!
username mark password 7 121A0C041104
! Configure the L2F tunnel secrets, as well as the remote access client usernames and
passwords
username joebloggs@mjlnet.com password 7 110A1016141D
username LODI_NAS1 password 7 030752180500
username PERRIS_HGW1 password 7 121A0C041104
username TATEBAYASHI@mjlnet.com password 7 13061E010803
!
ip subnet-zero
no ip source-route
!
no ip finger
no ip domain-lookup
!
no ip bootp server
! Enable VPDNs (including L2F)
vpdn enable
!
! Configure the VPDN group for LODI_NAS1
vpdn-group 1
accept-dialin
protocol l2f
virtual-template 1
terminate-from hostname LODI_NAS1
!
! Configure the DNS and WINS server addresses
async-bootp dns-server 10.10.10.99
async-bootp nbns-server 10.10.10.100
!
interface FastEthernet0/0
ip address 10.10.10.1 255.255.255.0
no ip redirects
no ip directed-broadcast
no ip proxy-arp
no cdp enable
!
interface FastEthernet1/0
ip address 172.16.2.2 255.255.255.0
no ip redirects
no ip directed-broadcast
no ip proxy-arp
no cdp enable
!
Example 2-11 Sample Configuration for the L2F Home Gateway (Continued)
CH01i.book Page 47 Friday, April 30, 2004 8:58 AM
48 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
You will notice in Example 2-11 that a static route is again congured for IP connectivity to the NAS.
To avoid simple misconguration errors, you should always incrementally congure and test
your NAS and Home Gateway. This means that the dial conguration of the NAS should be
completed rst, then tested. Then the VPDN groups should be congured with local
authentication and tested. And nally, the NAS/Home Gateway should be congured to use a
remote AAA server, if required.
Troubleshooting L2F
Fast and efcient troubleshooting of L2F is dependent upon a good understanding of L2F
protocol operation, L2F conguration, and PPP. Additionally, if remote access clients dial into
the NAS, a good knowledge of ISDN and asynchronous modems is also important. In this
section, you will see how to apply the end-to-end troubleshooting methodology to L2F.
The owchart in Figure 2-26 describes the troubleshooting process used with L2F. You can use
this owchart to quickly access the section of the chapter relevant to problems you are
experiencing on your network.
! Configure the virtual template
interface Virtual-Template1
ip unnumbered FastEthernet1/0
no ip directed-broadcast
peer default ip address pool PERRIS_POOL
ppp authentication chap
ppp multilink
!
! Static route for IP reachability to the NAS (LODI_NAS1)
ip route 172.16.1.0 255.255.255.0 172.16.2.1
!
ip local pool PERRIS_POOL 10.10.10.50 10.10.10.59
ip classless
ip http server
!
logging trap debugging
no cdp run
!
!
line con 0
password 7 060506324F41
login
transport input none
line aux 0
line vty 0 4
password 7 01100F175804
login
!
end
Example 2-11 Sample Configuration for the L2F Home Gateway (Continued)
CH01i.book Page 48 Friday, April 30, 2004 8:58 AM
Troubleshooting L2F 49
Figure 2-26 L2F Troubleshooting Flowchart
CH01i.book Page 49 Friday, April 30, 2004 8:58 AM
50 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
Before beginning the troubleshooting process, it is worth briey re-examining the tunnel
establishment model for L2F and some of the possible issues that could be seen.
Figure 2-27 illustrates tunnel establishment.
Figure 2-27 L2F Tunnel and Session Establishment
Figure 2-27 illustrates the following steps:
1 If the remote access client is using asynchronous dial, the rst step in L2F tunnel setup is
call reception on the NAS.
ISDN call setup messages arrive on the PRI via the ISDN Q.931 protocol.
The remote access clients call is then switched internally on the NAS to the digital
(MICA) modems.
Remote Access
Client
NAS
PSTN/
ISDN
Home Gateway
Service Provider
Backbone
1. Call
Reception
2. LCP
Negotiation
Authentication
(CHAP)
3. Partial
8. LCP Negotiation / PPP Authentication
Completed
9 NCP
Negotiation
5. Tunnel Establishment 5. Home Gateway
Confirms Valid
Source / Protocol /
Resources
7. Virtual Template
Config Cloned to Virtual
Access Interface
(Authentication)
6. Client (Session)
Establishment
Forwarding
10. PPP Frame
4. Associate
Domain/DNIS/
Username to Tunnel
CH01i.book Page 50 Friday, April 30, 2004 8:58 AM
Troubleshooting L2F 51
2 PPP is autodetected, and LCP negotiation takes place between the NAS and the remote
access client. This involves negotiation of such parameters as authentication protocol,
callback, and Asynchronous Control Character Map (ACCM).
3 When LCP negotiation is complete, partial authentication begins. Assuming CHAP
authentication, a Challenge is sent from the NAS to the remote access client.
The client replies with a CHAP Response message.
4 The NAS parses the name eld in the Response message and checks to see whether it
contains a domain name that corresponds to a L2F tunnel (domain domain_name).
Alternatively, DNIS or the complete username (with per-user VPDN) can be used to
associate the client to the L2F tunnel.
5 Assuming there is no existing tunnel, the NAS and Home Gateway now initiate and
establish the L2F tunnel.
During tunnel initiation, the Home Gateway conrms that a VPDN group is congured to
terminate a L2F tunnel from the NAS and that there are sufcient resources available.
NAS and the Home Gateway also authenticate each other during this stage.
6 Following tunnel setup, client session establishment begins. During this stage, the NAS
forwards the CHAP Response and other LCP parameters from the client to the Home Gateway.
7 Conguration is now cloned (copied) from the virtual template to a virtual access interface.
8 LCP negotiation and PPP authentication are then completed on the Home Gateway.
9 Once LCP negotiation and PPP authentication have been completed, NCPs, such as IPCP,
are negotiated between the Home Gateway and the remote access client.
10 If NCP negotiation is successful, forwarding then begins for the negotiated protocols, such as IP.
Thats what should happen. As you have probably guessed, there are quite a number of things
that can go wrong. Some of these things are shown in Figure 2-28. Note that not all potential
problems are shown.
Together, Figure 2-28 and Table 2-4 illustrate some potential problems.
Figure 2-28 Potential Problems with L2F Tunnel Setup
Remote Access
Client
PSTN/
ISDN
Service Provider
Backbone
NAS
Home Gateway
CH01i.book Page 51 Friday, April 30, 2004 8:58 AM
52 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
The rst part of the tunnel establishment model for L2F is, of course, the PPP connection
initiated by the remote access client. Some of the issues that might occur are highlighted in
Table 2-4.
Assuming a Microsoft client, issues might include incorrect modem drivers, a cabling issue
between the client and the modem, misconguration of Dial-up Networking (DUN), and so on.
It is not the intention of this book, however, to detail how to troubleshoot client operating
systems and hardware but, instead, to focus on troubleshooting issues that can occur on the
NAS and the Home Gateway.
The next section begins the L2F tunnel troubleshooting process, beginning with call reception
on the NAS.
Call Reception on the NAS
The rst thing that needs to be conrmed on the NAS is that calls are indeed being received as
intended. This section assumes that the client is using an asynchronous modem and that these
calls are being received by the NAS on its ISDN PRI.
Table 2-4 Potential Problems at Each Point Between the Remote Access Client and the Home Gateway
Potential Problems
at the Remote
Access Client
Potential Problems
at the NAS
Potential Problems
in the Service
Provider Backbone
Potential Problems
at the Home
Gateway
OS Issues Cabling issue Physical layer issue Cabling issue
Incorrect modem
driver
ISDN conguration Data link issue Data link issue
DUN miscongured Modem conguration IP connectivity broken Tunnel protocol
mismatch
TCP/IP not installed Authentication IP/UDP/L2F blocked
(ACL/Firewall)
Tunnel authentication
TCP/IP not bound to
dialup networking
adapter
VPDN protocol
mismatch
Unrecognized domain/
dnis
Modem Issues
Wrong IP address for
Home Gateway
Resource issue
Not switched on Tunnel authentication Virtual template
misconguration
Cabling issue AAA server issues PPP authentication
mismatch
Authentication failure
CH01i.book Page 52 Friday, April 30, 2004 8:58 AM
Troubleshooting L2F 53
Figure 2-29 illustrates call reception on the NAS.
Figure 2-29 Call Reception on the NAS
The rst thing to do is to conrm that the ISDN interface is active and that calls are being
received. The show isdn status command is a very good command to give you a quick snapshot
of the state of the ISDN interface.
Example 2-12 shows good output from this command.
Highlighted line 1 shows the globally congured ISDN switch type (primary-net5).
Highlighted line 2 shows the ISDN switch type applied to interface serial 0/0:15 (also
primary-net5).
The status of Layers 1, 2, and 3 are shown in next three highlighted lines. Layer 1 status is
ACTIVE. This indicates that physical connectivity has been established.
Moving on to Layer 2, you can see that the status is MULTIPLE_FRAME_ESTABLISHED.
This shows that the PRI has established communications with the service providers ISDN
Example 2-12 Good Output from the show isdn status Command
LODI_NAS1#show isdn status
Global ISDN Switchtype = primary-net5
ISDN Serial0/0:15 interface
dsl 0, interface ISDN Switchtype = primary-net5
Layer 1 Status:
ACTIVE
Layer 2 Status:
TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
Layer 3 Status:
1 Active Layer 3 Call(s)
CCB:callid=5, sapi=0, ces=0, B-chan=1, calltype=VOICE
CCB:callid=4, sapi=0, ces=0, B-chan=1, calltype=VOICE
Active dsl 0 CCBs = 2
The Free Channel Mask: 0xFFFF7FFE
Number of L2 Discards = 0, L2 Session ID = 2
Total Allocated ISDN CCBs = 2
LODI_NAS1#
Remote Access
Client
NAS
(172.16.1.1)
PSTN/
ISDN
Home Gateway
(172.16.2.2)
Service Provider
Backbone
1. Call
Reception
CH01i.book Page 53 Friday, April 30, 2004 8:58 AM
54 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
switch. Below that, the status of Layer 3 is shown. In this case, you can see that there is one
active call on the interface.
Now that you have seen an example of good output, Example 2-13 provides some output that
is not so good.
In this case, you can see that Layer 1 is in a DEACTIVATED state. This obviously indicates a
problem. An examination of the E1 controller shows the results in Example 2-14.
You can see in the rst highlighted line of the output that E1 0/0 is down.
In the second highlighted line, the transmitter is sending a remote alarm, and in the next line,
the receiver is reporting a loss of signal. A loss of signal usually indicates a problem with the
cable. It could be that the cable is not connected correctly or that there is a break in the cable.
The cable is replaced in this case, and the controller is checked again in Example 2-15.
Example 2-13 Not-So-Good Output from the show isdn status Command
LODI_NAS1#show isdn status
Global ISDN Switchtype = primary-net5
ISDN Serial0/0:15 interface
dsl 0, interface ISDN Switchtype = primary-net5
Layer 1 Status:
DEACTIVATED
Layer 2 Status:
TEI = 0, Ces = 1, SAPI = 0, State = TEI_ASSIGNED
Layer 3 Status:
0 Active Layer 3 Call(s)
Active dsl 0 CCBs = 0
The Free Channel Mask: 0x0
Number of L2 Discards = 0, L2 Session ID = 0
Total Allocated ISDN CCBs = 0
LODI_NAS1#
Example 2-14 E1 Controller Reports a Remote Alarm and Loss of Signal
LODI_NAS1#show controller e1 0/0
E1 0/0 is down.
Applique type is Channelized E1 - balanced
Transmitter is sending remote alarm.
Receiver has loss of signal.
alarm-trigger is not set
Framing is CRC4, Line Code is HDB3, Clock Source is Line.
Data in current interval (81 seconds elapsed):
0 Line Code Violations, 0 Path Code Violations
1 Slip Secs, 81 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 81 Unavail Secs
LODI_NAS1#
CH01i.book Page 54 Friday, April 30, 2004 8:58 AM
Troubleshooting L2F 55
In the rst highlighted line in Example 2-15, you can see that E1 0/0 is now up and, in the
second highlighted line, that there are no alarms detected.
Now check the ISDN status using the show isdn status command, as demonstrated in Example 2-16.
As you can see in the highlighted output, Layer 1 is now ACTIVE, and Layer 2 is
MULTIPLE_FRAME_ESTABLISHED. The issue is resolved.
Note that most problems with E1 or T1 controllers are caused by incorrectly congured
framing, linecode, or clock source. Make sure that these are congured as per your service
providers recommendations. Also ensure that ISDN switch type and encapsulation type are
correctly set.
You now know that the router is communicating correctly with the ISDN switch. The next step
is to check that call setup operates correctly. ISDN uses the Q.931 protocol to signal call setup,
so use debug isdn q931 command to verify call setup, as shown in Example 2-17.
In the rst highlighted line of Example 2-17, a call setup message is received (RX) on the D
channel (serial0/0:15).
Example 2-15 E1 Controller Now Reports No Alarms
LODI_NAS1#show controller e1 0/0
E1 0/0 is up.
Applique type is Channelized E1 - balanced
No alarms detected.
alarm-trigger is not set
Framing is CRC4, Line Code is HDB3, Clock Source is Line.
Data in current interval (290 seconds elapsed):
0 Line Code Violations, 0 Path Code Violations
1 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
1 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
LODI_NAS1#
Example 2-16 ISDN Layer 1 Status Is Now Active
LODI_NAS1#show isdn status
Global ISDN Switchtype = primary-net5
ISDN Serial0/0:15 interface
dsl 0, interface ISDN Switchtype = primary-net5
Layer 1 Status:
ACTIVE
Layer 2 Status:
TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
Layer 3 Status:
0 Active Layer 3 Call(s)
Active dsl 0 CCBs = 0
The Free Channel Mask: 0x80007FFF
Number of L2 Discards = 0, L2 Session ID = 0
Total Allocated ISDN CCBs = 0
LODI_NAS1#
CH01i.book Page 55 Friday, April 30, 2004 8:58 AM
56 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
If you look further down the output, you can see the calling party number (the remote access
client) 1111, and the called party number, 7777 (the NAS).
In highlighted line 4, a CONNECT message is transmitted (TX) by the NAS. This indicates that
the call has been accepted on the PRI.
Toward the bottom of the output, you can see the message Interface Serial0/0:0 is now
connected to 1111. Call setup has been successful. If call setup is not successful, check the
ISDN switch-type and the number that the remote access client is calling to access the NAS.
Once the call has been successfully received on interface serial 0/0:0 (one of the B channels),
it is routed to the internal MICA modems. Success or failure of one of the modems to receive
the call successfully can be examined using the debug modem command. This is demonstrated
in Example 2-18.
Example 2-17 Verifying Call Setup Operation
LODI_NAS1#debug isdn q931
ISDN Q931 packets debugging is on
LODI_NAS1#
Jan 6 18:35:43.131 GMT:GMT: ISDN Se0/0:15: RX <- SETUP pd = 8 callref = 0x0006
Jan 6 18:35:43.131 GMT: Sending Complete
Jan 6 18:35:43.131 GMT: Bearer Capability i = 0x8090A3
Jan 6 18:35:43.131 GMT: Channel ID i = 0xA98381
Jan 6 18:35:43.135 GMT: Calling Party Number i = 0xA1, '1111',
Plan:ISDN, Type:National
Jan 6 18:35:43.135 GMT: Called Party Number i = 0xA1, '7777',
Plan:ISDN, Type:National
Jan 6 18:35:43.135 GMT: Low Layer Compat i = 0x8090A3
Jan 6 18:35:43.143 GMT: ISDN Se0/0:15: llc valid, speed 64, call type is VOICE
speed:0 async:N
Jan 6 18:35:43.147 GMT: ISDN Se0/0:15: TX -> CALL_PROC pd = 8 callref = 0x8006
Jan 6 18:35:43.147 GMT: Channel ID i = 0xA98381
Jan 6 18:35:43.183 GMT: ISDN Se0/0:15: TX -> ALERTING pd = 8 callref = 0x8006
Jan 6 18:35:43.187 GMT: ISDN Se0/0:15: TX -> CONNECT pd = 8 callref = 0x8006
Jan 6 18:35:43.211 GMT: ISDN Se0/0:15: RX <- CONNECT_ACK pd = 8
callref = 0x0006
Jan 6 18:35:43.215 GMT: ISDN Se0/0:15: CALL_PROGRESS: CALL_CONNECTED
call id 0xA, bchan 0, dsl 0
Jan 6 18:35:43.215 GMT: %ISDN-6-CONNECT: Interface Serial0/0:0 is
now connected to 1111
Jan 6 18:36:08.847 GMT: %LINK-3-UPDOWN: Interface Async33, changed state to up
LODI_NAS1#
Jan 6 18:36:15.123 GMT: %LINEPROTO-5-UPDOWN: Line protocol on
Interface Async33, changed state to up
LODI_NAS1#
CH01i.book Page 56 Friday, April 30, 2004 8:58 AM
Troubleshooting L2F 57
In highlighted line 1, modem MICA 1/1 (slot 1, modem 1), goes off the hook (Modem 1/1
Mica: in modem state CALL_SETUP), and in highlighted line 2, the modem is connected at
transmit and receive (Tx/Rx) speeds of 49333 and 28800 bps, respectively.
Between highlighted lines 3 and 4, the autoselect process takes place, with several samples
made of the data received on the line. Based on these samples, the NAS is able to detect that
PPP is being used and autocongures the line for this encapsulation type. PPP negotiation is
then triggered on the line. Finally, in highlighted line 5, interface async 34 changes state to up.
If you do not see any output from the debug modem command, make sure that the isdn
incoming voice-modem command is congured on the ISDN D channel. Also make sure that
the modem InOut command is congured on the modem lines.
Example 2-18 Verifying Success/Failure of Call Receipt by the Modem
LODI_NAS1#debug modem
Modem control/process activation debugging is on
LODI_NAS1#
Jan 6 18:37:52.215 GMT: Modem 1/1 Mica: configured for Answer mode, with Null
signaling, 0x0 tone detection.
Jan 6 18:37:52.215 GMT: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected
to 1111
Jan 6 18:37:52.379 GMT: Modem 1/1 Mica: in modem state CALL_SETUP
Jan 6 18:37:53.447 GMT: Modem 1/1 Mica: in modem state CONNECT
Jan 6 18:37:57.939 GMT: Modem 1/1 Mica: in modem state LINK
Jan 6 18:38:09.163 GMT: Modem 1/1 Mica: in modem state TRAINUP
Jan 6 18:38:13.219 GMT: Modem 1/1 Mica: in modem state EC_NEGOTIATING
Jan 6 18:38:13.755 GMT: Modem 1/1 Mica: in modem state STEADY
Jan 6 18:38:13.767 GMT: Modem 1/1 Mica: CONNECT at 49333/28800 (Tx/Rx), V90,
LAPM, V42bisJan 6 18:38:14.655 GMT: TTY34: DSR came up
Jan 6 18:38:14.655 GMT: tty34: Modem: IDLE->(unknown)
Jan 6 18:38:14.659 GMT: TTY34: Autoselect started
Jan 6 18:38:14.659 GMT: TTY34: create timer type 0, 120 seconds
Jan 6 18:38:15.827 GMT: TTY34: Autoselect sample 7E
Jan 6 18:38:15.827 GMT: TTY34: Autoselect sample 7EFF
Jan 6 18:38:15.827 GMT: TTY34: Autoselect sample 7EFF7D
Jan 6 18:38:15.827 GMT: TTY34: Autoselect sample 7EFF7D23
Jan 6 18:38:15.831 GMT: TTY34 Autoselect cmd: ppp negotiate
Jan 6 18:38:15.831 GMT: TTY34: destroy timer type 0 (OK)
Jan 6 18:38:15.831 GMT: TTY34: EXEC creation
Jan 6 18:38:15.835 GMT: TTY34: create timer type 1, 600 seconds
Jan 6 18:38:15.839 GMT: TTY34: destroy timer type 1 (OK)
Jan 6 18:38:15.839 GMT: TTY34: destroy timer type 0
Jan 6 18:38:17.839 GMT: %LINK-3-UPDOWN: Interface Async34, changed state to up
Jan 6 18:38:22.923 GMT: Modem 1/1 Mica: PPP escape_map: Tx map = 0, Rx map = 0
Jan 6 18:38:24.111 GMT: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Async34, changed state to up
Jan 6 18:38:34.843 GMT: Modem 1/1 Mica: in modem state SS_SHIFTINGSPEED
Jan 6 18:38:36.087 GMT: Modem 1/1 Mica: in modem state STEADY
Jan 6 18:38:36.099 GMT: Modem 1/1 Mica: SpeedShifted to 49333/31200 (Tx/Rx)
LODI_NAS1#
CH01i.book Page 57 Friday, April 30, 2004 8:58 AM
58 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
Another useful command to use when debugging modems is debug modem csm. This
command provides detailed debugging for the Call Switching Module (for internal digital
modems). You have now conrmed that the call setup is completing successfully.
Troubleshooting PPP on the NAS
If you have conrmed that calls from the remote access client are being successfully received,
it is now time to check PPP negotiation on the NAS. PPP negotiation is a two-stage process on
the NAS, consisting of LCP negotiation and partial authentication.
Remember that Network Control Protocols (NCPs) are not negotiated by the NAS, but instead
between the client and the Home Gateway.
LCP Negotiation Fails Between the Remote Client and the NAS
If LCP negotiation is not successful between the NAS and the remote client, use the debug ppp
negotiation command to see what went wrong.
Figure 2-30 shows LCP negotiation between the NAS and the remote access client.
Figure 2-30 LCP Negotiation Between the NAS and Client
The output in Examples 2-19 to 2-31 show successful LCP negotiation between the NAS and
the remote client.
Example 2-19 PPP Negotiation Begins
LODI_NAS1#debug ppp negotiation
PPP protocol negotiation debugging is on
LODI_NAS1#
Jan 6 18:45:37.063 GMT: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected
to 1111
Jan 6 18:46:05.723 GMT: %LINK-3-UPDOWN: Interface Async36, changed state to up
Jan 6 18:46:05.723 GMT: As36 PPP: Treating connection as a dedicated line
Jan 6 18:46:05.723 GMT: As36 PPP: Phase is ESTABLISHING, Active Open
Remote Access
Client
NAS
(172.16.1.1)
PSTN/
ISDN
Home Gateway
(172.16.2.2)
Service Provider
Backbone
1. Call
Reception
2. LCP
Negotiation
CH01i.book Page 58 Friday, April 30, 2004 8:58 AM
Troubleshooting L2F 59
Highlighted line 1 shows that interface serial0/0:0 (one of the B channels) is connected.
In highlighted line 2, interface async 36 changes state to up.
PPP then moves to the ESTABLISHING phase (highlighted line 3). This means that PPP
negotiation is about to begin.
PPP negotiation begins when the NAS sends a Congure-Request (CONFREQ) to the remote
access client, as shown in Example 2-20.
The highlighted line in Example 2-20 shows the outbound (O) Congure-Request (CONFREQ)
from the NAS. This is used to inform the remote access client of the LCP options that the NAS
wants to use.
The LCP options included in this CONFREQ are Asynchronous Control Character Map
(ACCM), Authentication Protocol, Magic Number, Protocol Field Compression (PFC), and
Address & Control Field Compression (ACFC).
ACCM is used to control how data is escaped over the link. Escaping data ensures that data sent
over the link is not misinterpreted by the modem as commands.
Raw data is given in parentheses. In ACCM 0x000A0000 (0x0206000A0000), 0x02 is the LCP
option number (ACCM itself), 0x06 is the option length, and 0x000A0000 is the four-octet map
that denes how character escaping will be performed.
It is worth noting that the elements option number, option length, and value comprise a common
format with PPP options.
The next LCP option is authentication protocol (0x03). In this case, the authentication protocol
specied is standard MD5 CHAP (0xC22305).
The third option is Magic Number (0x05). The Magic Number specied by the NAS is
0x115342A4. The Magic Number is used for loop detection.
PFC (0x07) is the next option specied. The NAS uses this option to inform the client that it
can receive PPP protocol elds that are compressed.
The nal option is ACFC (0x08). This option is used to indicate that the NAS can receive PPP
frames without HDLC Address and Control elds.
The client then acknowledges the NASs CONFREQ with a Congure-Ack (CONFACK), as
shown in Example 2-21. Notice that the CONFACK has the same ID (6) as the previous
CONFREQ (see Example 2-20).
Example 2-20 Outbound CONFREQ from the NAS
Jan 6 18:46:05.727 GMT: As36 LCP: O CONFREQ [Closed] id 6 len 25
Jan 6 18:46:05.727 GMT: As36 LCP: ACCM 0x000A0000 (0x0206000A0000)
Jan 6 18:46:05.727 GMT: As36 LCP: AuthProto CHAP (0x0305C22305)
Jan 6 18:46:05.727 GMT: As36 LCP: MagicNumber 0x115342A4 (0x0506115342A4)
Jan 6 18:46:05.727 GMT: As36 LCP: PFC (0x0702)
Jan 6 18:46:05.727 GMT: As36 LCP: ACFC (0x0802)
CH01i.book Page 59 Friday, April 30, 2004 8:58 AM
60 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
All the options contained in the CONFACK are the same as those in the CONFREQ in
Example 2-20.
The rst inbound (I) CONFREQ is now received from the client (see Example 2-22).
Most of the options are the same as those specied in the NASs CONFREQ, but there is one
addition: The client has specied the Callback (0x0D) option. The client uses this option to
request that the NAS drop the link after authentication and call it back.
Note that this rst CONFREQ from the client will later be forwarded to the Home Gateway
during client (session) setup as L2F_OPEN suboption L2F_REQ_LCP0.
The NAS then sends a Congure-Reject (CONFREJ) to the remote access client, as shown in
Example 2-23.
The NAS uses the Congure-Reject (CONREJ) in Example 2-23 to reject conguration of
Callback. Note that LCP times out here.
The NAS now sends a second outbound CONFREQ to the client, shown in Example 2-24. The
NAS species the same options as the rst CONFREQ (see Example 2-20).
Example 2-21 Inbound LCP CONFACK from the Remote Access Client
Jan 6 18:46:05.831 GMT: As36 LCP: I CONFACK [REQsent] id 6 len 25
Jan 6 18:46:05.831 GMT: As36 LCP: ACCM 0x000A0000 (0x0206000A0000)
Jan 6 18:46:05.835 GMT: As36 LCP: AuthProto CHAP (0x0305C22305)
Jan 6 18:46:05.835 GMT: As36 LCP: MagicNumber 0x115342A4 (0x0506115342A4)
Jan 6 18:46:05.835 GMT: As36 LCP: PFC (0x0702)
Jan 6 18:46:05.835 GMT: As36 LCP: ACFC (0x0802)
Example 2-22 Inbound LCP CONFREQ from the Remote Access Client
Jan 6 18:46:06.711 GMT: As36 LCP: I CONFREQ [ACKrcvd] id 0 len 23
Jan 6 18:46:06.711 GMT: As36 LCP: ACCM 0x00000000 (0x020600000000)
Jan 6 18:46:06.711 GMT: As36 LCP: MagicNumber 0x000064CB (0x0506000064CB)
Jan 6 18:46:06.711 GMT: As36 LCP: PFC (0x0702)
Jan 6 18:46:06.711 GMT: As36 LCP: ACFC (0x0802)
Jan 6 18:46:06.711 GMT: As36 LCP: Callback 6 (0x0D0306)
Example 2-23 Outbound CONFREJ from NAS
Jan 6 18:46:06.715 GMT: As36 LCP: O CONFREJ [ACKrcvd] id 0 len 7
Jan 6 18:46:06.715 GMT: As36 LCP: Callback 6 (0x0D0306)
Jan 6 18:46:07.727 GMT: As36 LCP: TIMEout: State ACKrcvd
Example 2-24 Second Outbound CONFREQ from the NAS
Jan 6 18:46:07.727 GMT: As36 LCP: O CONFREQ [ACKrcvd] id 7 len 25
Jan 6 18:46:07.727 GMT: As36 LCP: ACCM 0x000A0000 (0x0206000A0000)
Jan 6 18:46:07.727 GMT: As36 LCP: AuthProto CHAP (0x0305C22305)
Jan 6 18:46:07.727 GMT: As36 LCP: MagicNumber 0x115342A4 (0x0506115342A4)
Jan 6 18:46:07.727 GMT: As36 LCP: PFC (0x0702)
Jan 6 18:46:07.727 GMT: As36 LCP: ACFC (0x0802)
CH01i.book Page 60 Friday, April 30, 2004 8:58 AM
Troubleshooting L2F 61
A second CONFACK is received from the client in Example 2-25.
The CONFACK in Example 2-25 is used to acknowledge the previous CONFREQ from the
NAS. Note another LCP timeout here.
A third CONFREQ is now sent to the client, as shown in Example 2-26.
The CONFREQ in Example 2-26 contains the same options as the two previous CONFREQs.
The third CONFREQ is acknowledged by a nal inbound CONFACK from the client in
Example 2-27.
The CONFACK in Example 2-27 will later be passed to the Home Gateway as L2F_OPEN
suboption L2F_ACK_LCP1 during L2F session establishment.
A second inbound CONFREQ is received from the client, as shown in Example 2-28.
Example 2-25 Second Inbound CONFREQ from Client
Jan 6 18:46:07.819 GMT: As36 LCP: I CONFACK [REQsent] id 7 len 25
Jan 6 18:46:07.819 GMT: As36 LCP: ACCM 0x000A0000 (0x0206000A0000)
Jan 6 18:46:07.819 GMT: As36 LCP: AuthProto CHAP (0x0305C22305)
Jan 6 18:46:07.819 GMT: As36 LCP: MagicNumber 0x115342A4 (0x0506115342A4)
Jan 6 18:46:07.819 GMT: As36 LCP: PFC (0x0702)
Jan 6 18:46:07.819 GMT: As36 LCP: ACFC (0x0802)
Jan 6 18:46:09.727 GMT: As36 LCP: TIMEout: State ACKrcvd
Example 2-26 Third LCP Outbound CONFREQ from the NAS
Jan 6 18:46:09.727 GMT: As36 LCP: O CONFREQ [ACKrcvd] id 8 len 25
Jan 6 18:46:09.727 GMT: As36 LCP: ACCM 0x000A0000 (0x0206000A0000)
Jan 6 18:46:09.727 GMT: As36 LCP: AuthProto CHAP (0x0305C22305)
Jan 6 18:46:09.727 GMT: As36 LCP: MagicNumber 0x115342A4 (0x0506115342A4)
Jan 6 18:46:09.727 GMT: As36 LCP: PFC (0x0702)
Jan 6 18:46:09.727 GMT: As36 LCP: ACFC (0x0802)
Example 2-27 Final CONFACK Received from the Client
Jan 6 18:46:09.819 GMT: As36 LCP: I CONFACK [REQsent] id 8 len 25
Jan 6 18:46:09.819 GMT: As36 LCP: ACCM 0x000A0000 (0x0206000A0000)
Jan 6 18:46:09.819 GMT: As36 LCP: AuthProto CHAP (0x0305C22305)
Jan 6 18:46:09.819 GMT: As36 LCP: MagicNumber 0x115342A4 (0x0506115342A4)
Jan 6 18:46:09.819 GMT: As36 LCP: PFC (0x0702)
Jan 6 18:46:09.823 GMT: As36 LCP: ACFC (0x0802)
Example 2-28 Second CONFREQ Received from the Client
Jan 6 18:46:10.715 GMT: As36 LCP: I CONFREQ [ACKrcvd] id 0 len 23
Jan 6 18:46:10.715 GMT: As36 LCP: ACCM 0x00000000 (0x020600000000)
Jan 6 18:46:10.715 GMT: As36 LCP: MagicNumber 0x000064CB (0x0506000064CB)
Jan 6 18:46:10.715 GMT: As36 LCP: PFC (0x0702)
Jan 6 18:46:10.715 GMT: As36 LCP: ACFC (0x0802)
Jan 6 18:46:10.715 GMT: As36 LCP: Callback 6 (0x0D0306)
CH01i.book Page 61 Friday, April 30, 2004 8:58 AM
62 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
The options contained in the CONFREQ in Example 2-28 are the same as those specied in the
clients rst CONFREQ (see Example 2-22).
Callback is then rejected by the NAS using a CONFREJ in Example 2-29.
The client now sends its third CONFREQ (in Example 2-30), and this time you will notice there
is no Callback option included.
Finally, in Example 2-31, the NAS sends a CONFACK to the client acknowledging its
CONFREQ (highlighted line 1). This CONFACK is also later forwarded to the NAS as
LCP_OPEN suboption L2F_ACK_LCP2 during L2F session establishment.
In highlighted line 2, the LCP state changes to OPEN, indicating that LCP negotiation has
completed successfully.
Example 2-32 shows the output of the debug ppp negotiation command when LCP negotiation
is unsuccessful. Note that only the relevant portion of the output is shown.
Example 2-29 Second CONFREJ Sent by NAS
Jan 6 18:46:10.715 GMT: As36 LCP: O CONFREJ [ACKrcvd] id 0 len 7
Jan 6 18:46:10.719 GMT: As36 LCP: Callback 6 (0x0D0306)
Example 2-30 Third CONFREQ from Client
Jan 6 18:46:10.803 GMT: As36 LCP: I CONFREQ [ACKrcvd] id 1 len 20
Jan 6 18:46:10.803 GMT: As36 LCP: ACCM 0x00000000 (0x020600000000)
Jan 6 18:46:10.803 GMT: As36 LCP: MagicNumber 0x000064CB (0x0506000064CB)
Jan 6 18:46:10.803 GMT: As36 LCP: PFC (0x0702)
Jan 6 18:46:10.803 GMT: As36 LCP: ACFC (0x0802)
Example 2-31 NAS Sends CONFACK to the Client
Jan 6 18:46:10.807 GMT: As36 LCP: O CONFACK [ACKrcvd] id 1 len 20
Jan 6 18:46:10.807 GMT: As36 LCP: ACCM 0x00000000 (0x020600000000)
Jan 6 18:46:10.807 GMT: As36 LCP: MagicNumber 0x000064CB (0x0506000064CB)
Jan 6 18:46:10.807 GMT: As36 LCP: PFC (0x0702)
Jan 6 18:46:10.807 GMT: As36 LCP: ACFC (0x0802)
Jan 6 18:46:10.807 GMT: As36 LCP: State is Open
Example 2-32 debug ppp negotiation Command Output
LODI_NAS1#debug ppp negotiation
PPP protocol negotiation debugging is on
LODI_NAS1#
*Mar 1 01:26:21.131 GMT: As36 LCP: O CONFREQ [ACKsent] id 18 len 25
*Mar 1 01:26:21.131 GMT: As36 LCP: ACCM 0x000A0000 (0x0206000A0000)
*Mar 1 01:26:21.131 GMT: As36 LCP: AuthProto CHAP (0x0305C22305)
*Mar 1 01:26:21.131 GMT: As36 LCP: MagicNumber 0x10CA833B (0x050610CA833B)
*Mar 1 01:26:21.131 GMT: As36 LCP: PFC (0x0702)
*Mar 1 01:26:21.131 GMT: As36 LCP: ACFC (0x0802)
*Mar 1 01:26:21.239 GMT: As36 LCP: I CONFNAK [ACKsent] id 18 len 9
CH01i.book Page 62 Friday, April 30, 2004 8:58 AM
Troubleshooting L2F 63
In highlighted line 1, the NAS sends an LCP CONFREQ to the client. Note that the
authentication protocol (AuthProto) specied is CHAP (standard MD5 CHAP). In highlighted
line 2, the client then responds with a CONFNACK specifying MS-CHAP (Microsoft CHAP).
Highlighted line 3 shows that the NAS has failed to negotiate with the peer (the client), and in
highlighted line 4, the NAS sends a TERMREQ to terminate the connection.
Then in highlighted lines 5 and 6, interface serial 0/0:0 is disconnected from 1111, and interface
async 36 changes state to down. The NAS and the client were unable to agree on an
authentication protocol, and the client was disconnected.
To resolve this issue, the NAS can be congured to accept MS-CHAP, or the client can be
congured to accept standard MD5 CHAP. In this case, the client is recongured to accept
standard MD5 CHAP. The client now reconnects, and LCP negotiates successfully. This is
veried using the show user and show caller user commands.
Example 2-33 shows the output of the show user command.
As you can see, user joebloggs@(mjlnet.com) is connected on interface async 37. More
information about the client connection can be found using the show caller user command.
*Mar 1 01:26:21.243 GMT: As36 LCP: AuthProto MS-CHAP (0x0305C22380)
*Mar 1 01:26:21.243 GMT: As36 LCP: Failed to negotiate with peer
*Mar 1 01:26:21.243 GMT: As36 LCP: O TERMREQ [ACKsent] id 19 len 4
*Mar 1 01:26:21.403 GMT: %ISDN-6-DISCONNECT: Interface Serial0/0:0 disconnected from
1111 , call lasted 32 seconds
*Mar 1 01:26:23.243 GMT: As36 LCP: TIMEout: State TERMsent
*Mar 1 01:26:23.243 GMT: As36 LCP: O TERMREQ [TERMsent] id 20 len 4
*Mar 1 01:26:25.023 GMT: %LINK-5-CHANGED: Interface Async36, changed state to reset
*Mar 1 01:26:25.023 GMT: As36 LCP: State is Closed
*Mar 1 01:26:25.027 GMT: As36 PPP: Phase is DOWN
*Mar 1 01:26:30.023 GMT: %LINK-3-UPDOWN: Interface Async36, changed state to down
*Mar 1 01:26:30.023 GMT: As36 LCP: State is Closed
LODI_NAS1#
Example 2-33 show user Command Output
LODI_NAS1#show user
Line User Host(s) Idle Location
* 0 con 0 idle 00:00:00
37 tty 37 joebloggs@ Async interface -
Interface User Mode Idle Peer Address
LODI_NAS1#
Example 2-32 debug ppp negotiation Command Output (Continued)
CH01i.book Page 63 Friday, April 30, 2004 8:58 AM
64 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
Example 2-34 shows the output of the show caller user command.
In highlighted line 1, you can see that user joebloggs@mjlnet.com is connected on line 37.
Highlighted line 2 shows that PPP is running on the line. Then highlighted line 3 shows that
LCP has been successfully negotiated (state is OPEN), and that the authentication protocol is
standard MD5 CHAP.
Partial PPP Authentication Fails on the NAS
LCP has now been successfully negotiated and is in the OPEN state. At this point, PPP
authentication begins.
Figure 2-31 shows partial authentication between the NAS and remote access client.
Example 2-34 show caller user Command Output
LODI_NAS1#show caller user joebloggs@mjlnet.com
User: joebloggs@mjlnet.com, line tty 37, service Async
Active time 00:00:54, Idle time 00:00:07
Timeouts: Absolute Idle Idle
Session Exec
Limits: - - 00:10:00
Disconnect in: - - -
TTY: Line 37, running PPP on As37
Line: Baud rate (TX/RX) is 115200/115200, no parity, 2 stopbits, 8 databits
Status: Ready, Active, No Exit Banner, Async Interface Active
HW PPP Support Active, Modem Detected
Capabilities: Modem Callout, Modem RI is CD,
Line is permanent async interface, Modem Autoconfigure
Integrated ModemLinenumber Not Suppressed
Modem State: Ready, Modem Configured
User: joebloggs@mjlnet.com, line As37, service PPP
Active time 00:00:51, Idle time 00:00:00
Timeouts: Absolute Idle
Limits: - -
Disconnect in: - -
PPP: LCP Open, CHAP (<- none)
IP: Local 172.16.1.1
VPDN: NAS LODI_NAS1, MID 19, MID open
HGW PERRIS_HGW1, NAS CLID 4, HGW CLID 18, tunnel open
Counts: 206 packets input, 11542 bytes, 0 no buffer
0 input errors, 0 CRC, 0 frame, 0 overrun
318 packets output, 14026 bytes, 0 underruns
0 output errors, 0 collisions, 3 interface resets
LODI_NAS1#
CH01i.book Page 64 Friday, April 30, 2004 8:58 AM
Troubleshooting L2F 65
Figure 2-31 Partial Authentication Between the NAS and the Client
Example 2-35 shows the output of the debug ppp negotiation command when authentication
is successful. Note that only the relevant portion of the output is shown.
Note that the debug ppp authentication command can also be used to troubleshoot PPP
authentication.
In highlighted line 1, the LCP state changes to OPEN. LCP negotiation has completed
successfully. The PPP phase now changes to AUTHENTICATING (highlighted line 2).
Authentication is about to begin.
Example 2-35 Successful PPP Authentication on the NAS
LODI_NAS1#debug ppp negotiation
PPP protocol negotiation debugging is on
LODI_NAS1#
Jan 6 18:46:10.807 GMT: As36 LCP: State is Open
Jan 6 18:46:10.811 GMT: As36 PPP: Phase is AUTHENTICATING, by this end
Jan 6 18:46:10.811 GMT: As36 CHAP: O CHALLENGE id 3 len 30 from "LODI_NAS1"
Jan 6 18:46:10.895 GMT: As36 LCP: I IDENTIFY [Open] id 2 len 18 magic
0x000064CB MSRASV4.00
Jan 6 18:46:10.903 GMT: As36 LCP: I IDENTIFY [Open] id 3 len 21 magic
0x000064CB MSRAS-1-ORCH1
Jan 6 18:46:10.927 GMT: As36 CHAP: I RESPONSE id 3 len 40 from
"joebloggs@mjlnet.com"
Jan 6 18:46:10.927 GMT: As36 PPP: Phase is FORWARDING
Jan 6 18:46:11.471 GMT: As36 PPP: Phase is FORWARDED
Jan 6 18:46:11.995 GMT: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Async36, changed state to up
Remote Access
Client
NAS
(172.16.1.1)
PSTN/
ISDN
Home Gateway
(172.16.2.2)
Service Provider
Backbone
1. Call
Reception
2. LCP
Negotiation
Authentication
(CHAP)
3. Partial
CH01i.book Page 65 Friday, April 30, 2004 8:58 AM
66 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
First the NAS sends an outbound (O) CHAP Challenge to the remote access client (highlighted
line 3). Note that you should not see inbound (I) CHAP challenges from the remote access
client. In highlighted line 4, the client replies with a Response message.
The NAS does not now send a CHAP Success or Failure message to the client. At rst, this may
seem a little strange, because this is what would be expected in a normal PPP negotiation
sequence.
In this case, the negotiation sequence is different. The NAS does not examine the Value eld
(which contains the response data) in the CHAP Response message at all. Instead, it parses the
username or DNIS and looks for an L2F tunnel corresponding to the domain name or DNIS.
Having found a corresponding L2F tunnel and establishing an L2F tunnel to the Home Gateway
if necessary, it sends the clients CHAP Response, together with other information, to the Home
Gateway.
In this case, the username supplied in the clients Response is joebloggs@mjlnet.com. The
domain name mjlnet.com is matched by the NAS to an L2F tunnel.
Also note in Example 2-35 the two LCP Identify options received from the client between
highlighted lines 3 and 4. These are both vendor specic options (0x00), and they serve to
inform the NAS that the client is using Microsoft RAS version 4 and that the computer name is
ORCH1. Note that this is not the client username.
You have seen debug output where the authentication on the NAS is successful. Example 2-36
shows the output of debug ppp negotiation when the authentication is not successful.
Example 2-36 Unsuccessful Partial PPP Authentication on the NAS
LODI_NAS1#debug ppp negotiation
PPP protocol negotiation debugging is on
LODI_NAS1#
Jan 6 19:03:27.562 GMT: As38 LCP: State is Open
Jan 6 19:03:27.566 GMT: As38 PPP: Phase is AUTHENTICATING, by this end
Jan 6 19:03:27.566 GMT: As38 CHAP: O CHALLENGE id 4 len 30 from "LODI_NAS1"
Jan 6 19:03:27.650 GMT: As38 LCP: I IDENTIFY [Open] id 2 len 18 magic
0x00000DF5 MSRASV4.00
Jan 6 19:03:27.662 GMT: As38 LCP: I IDENTIFY [Open] id 3 len 21 magic
0x00000DF5 MSRAS-1-ORCH1
Jan 6 19:03:27.682 GMT: As38 CHAP: I RESPONSE id 4 len 40 from
"joebloggs@mjlnet.com"
Jan 6 19:03:27.682 GMT: As38 PPP: Phase is FORWARDING
Jan 6 19:03:27.686 GMT: As38 PPP: Phase is AUTHENTICATING
Jan 6 19:03:27.686 GMT: As38 CHAP: Unable to validate Response. Username
joebloggs@mjlnet.com not found
Jan 6 19:03:27.690 GMT: As38 CHAP: O FAILURE id 4 len 26 msg is
"Authentication failure"
Jan 6 19:03:27.690 GMT: As38 PPP: Phase is TERMINATING
Jan 6 19:03:27.690 GMT: As38 LCP: O TERMREQ [Open] id 13 len 4
Jan 6 19:03:27.778 GMT: As38 LCP: I TERMREQ [TERMsent] id 4 len 8 (0x00000005)
Jan 6 19:03:27.778 GMT: As38 LCP: O TERMACK [TERMsent] id 4 len 4
Jan 6 19:03:27.782 GMT: As38 LCP: I TERMACK [TERMsent] id 13 len 4
CH01i.book Page 66 Friday, April 30, 2004 8:58 AM
Troubleshooting L2F 67
In highlighted line 1, the LCP state changes to OPEN, indicating that LCP negotiation has been
successful. The PPP phase then changes to AUTHENTICATING (highlighted line 2), and
authentication begins. In highlighted line 3, the NAS sends an outbound (O) Challenge to the
client. In highlighted line 4 of the output, the client replies to the Challenge from the NAS with
a Response message.
Again, the NAS parses the username (joebloggs@mjlnet.com) and searches for a L2F tunnel
corresponding to the domain name mjlnet.com. Having failed to nd a corresponding tunnel,
the NAS tries to authenticate the client itself, but when this does not succeed (highlighted line
5), it sends a CHAP Failure message to the client (highlighted line 6). The PPP phase then
changes to TERMINATING (highlighted line 7).
Terminate-Requests (TERMREQs) and Terminate-Acks (TERMACKs) are then exchanged
between the client and the NAS (highlighted lines 8 to 11). The TERMREQ message is, as its
name suggests, used to request teardown of the connection. The TERMACK is an
acknowledgement of the request.
In highlighted line 12, interface serial0/0:0 disconnects, and then in highlighted line 13,
interface async 38 changes state to down.
PPP authentication has failed and the client connection has been torn down. The NAS was
unable to nd a L2F tunnel corresponding to domain name mjlnet.com. The VPDN
conguration is then examined and the problem is revealed.
Example 2-37 shows the output of the show running-cong command on the NAS. Note that
only the relevant portion of the output is shown.
Jan 6 19:03:27.782 GMT: As38 LCP: State is Closed
Jan 6 19:03:27.782 GMT: As38 PPP: Phase is DOWN
Jan 6 19:03:27.782 GMT: As38 PPP: Phase is ESTABLISHING, Passive Open
Jan 6 19:03:27.786 GMT: As38 LCP: State is Listen
Jan 6 19:03:27.866 GMT: %ISDN-6-DISCONNECT: Interface Serial0/0:0 disconnected
from 1111 , call lasted 30 seconds
Jan 6 19:03:29.782 GMT: %LINK-5-CHANGED: Interface Async38, changed state to
reset
Jan 6 19:03:29.782 GMT: As38 LCP: State is Closed
Jan 6 19:03:29.786 GMT: As38 PPP: Phase is DOWN
Jan 6 19:03:34.782 GMT: %LINK-3-UPDOWN: Interface Async38, changed state to
down
Jan 6 19:03:34.782 GMT: As38 LCP: State is Closed
Example 2-36 Unsuccessful Partial PPP Authentication on the NAS (Continued)
CH01i.book Page 67 Friday, April 30, 2004 8:58 AM
68 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
As you can see, the domain for the VPDN group has been incorrectly congured as disco.com.
To correct this, use the conguration in Example 2-38.
Having corrected the domain name, the client reconnects. When the client reconnects, partial
PPP authentication succeeds, and the L2F tunnel is established to the Home Gateway.
Successful L2F tunnel establishment is veried using the show vpdn tunnel all command.
Example 2-39 shows the output of the show vpdn tunnel all command.
Example 2-37 VPDN Group Domain Name Is Misconfigured
LODI_NAS1#show running-config
Building configuration...
Current configuration : 1755 bytes
!
vpdn-group 1
request-dialin
protocol l2f
domain disco.com
initiate-to ip 172.16.2.2
!
Example 2-38 Reconfiguration of the VPDN Domain Name
LODI_NAS1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
LODI_NAS1(config)#vpdn-group 1
LODI_NAS1(config-vpdn)#request-dialin
LODI_NAS1(config-vpdn-req-in)#no domain disco.com
LODI_NAS1(config-vpdn-req-in)#domain mjlnet.com
LODI_NAS1(config-vpdn-req-in)#exit
LODI_NAS1#
Example 2-39 L2F Tunnel Establishment Is Successful
LODI_NAS1#show vpdn tunnel all
% No active L2TP tunnels
L2F Tunnel Information Total tunnels 1 sessions 1
NAS name: LODI_NAS1
NAS CLID: 1
NAS IP address 172.16.1.1
Gateway name: PERRIS_HGW1
Gateway CLID: 15
Gateway IP address 172.16.2.2
State: open
Packets out: 280
Bytes out: 11899
Packets in: 390
Bytes in: 18182
LODI_NAS1#
CH01i.book Page 68 Friday, April 30, 2004 8:58 AM
Troubleshooting L2F 69
Highlighted line 1 shows that one tunnel and one session have been established. In highlighted
lines 2 to 4, the name (PERRIS_HGW), CLID (15), and IP address (172.16.2.2) of the Home
Gateway are shown.
Troubleshooting L2F Tunnel Establishment
Once LCP negotiation and partial authentication have been completed and the domain name or
DNIS has been matched to a VPDN group, the NAS begins tunnel establishment to the Home
Gateway.
Figure 2-32 shows tunnel initialization and establishment between the NAS and the Home
Gateway.
Figure 2-32 L2F Tunnel Initialization Between the NAS and Home Gateway
Before examining what happens when L2F tunnel establishment fails, it is worth having a look
at successful tunnel establishment using the debug vpdn l2x-events command.
Examples 2-40 to 2-42 show the output of the debug vpdn l2x-events command.
In highlighted line 1 (Example 2-40), interface serial 0/0:0 (one of the B channels) is connected
to the remote access client (1111).
Remote Access
Client
NAS
(172.16.1.1)
PSTN/
ISDN
Home Gateway
(172.16.2.2)
Service Provider
Backbone
1. Call
Reception
2. LCP
Negotiation
Authentication
(CHAP)
3. Partial
5. Tunnel Initialization 6. Home Gateway
Confirms Valid
Source / Protocol /
Resources
(L2F_CONF)
4. Associate
Domain/DNIS/
Username to Tunnel
CH01i.book Page 69 Friday, April 30, 2004 8:58 AM
70 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
Then in highlighted line 2, interface async 34 changes state to up. The remote access client is
now connected to the NAS.
In highlighted line 3, the NAS opens a UDP port and sends an L2F_CONF to the Home
Gateway. Note that the L2F_CONF is not explicitly shown in the debug output.
The Home Gateway responds with an L2F_CONF, shown in Example 2-41.
The NAS now replies to the Home Gateway with an L2F_OPEN, as shown in Example 2-42,
highlighted line 1.
The Home Gateway authenticates the NAS, and because this is successful, responds with its
own L2F_OPEN. This is seen in highlighted line 2.
The NAS successfully authenticates the Home Gateway, and the L2F tunnel is now established.
The show vpdn tunnel all command can be used to conrm L2F tunnel establishment, as
shown in Example 2-43.
Example 2-40 Successful L2F Tunnel Establishment
LODI_NAS1#debug vpdn l2x-events
L2X protocol events debugging is on
LODI_NAS1#
Jan 6 19:28:44.006 GMT: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected
to 1111
Jan 6 19:29:09.842 GMT: %LINK-3-UPDOWN: Interface Async34, changed state to up
Jan 6 19:29:15.046 GMT: Tnl 24 L2F: UDP socket opened to 172.16.2.2 using
source 172.16.1.1
Jan 6 19:29:15.046 GMT: Tnl 24 L2F: Tunnel state change from closed state
opening
Example 2-41 L2F Tunnel Initialization
Jan 6 19:29:15.074 GMT: Tnl 24 L2F: L2F_CONF received
Jan 6 19:29:15.078 GMT: Tnl 24 L2F: Received L2F-CONF from PERRIS_HGW1
Jan 6 19:29:15.078 GMT: Tnl 24 L2F: Tunnel PERRIS_HGW1 state change from
opening state open
Example 2-42 L2F Tunnel Establishment and Authentication
Jan 6 19:29:15.078 GMT: Tnl 24 L2F: Replying with L2F-OPEN, Tunnel in Open-Wait
Jan 6 19:29:15.102 GMT: Tnl 24 L2F: L2F_OPEN received
Jan 6 19:29:15.106 GMT: Tnl 24 L2F: OPEN from PERRIS_HGW1 received for tunnel
in state open
Jan 6 19:29:15.106 GMT: Tnl 24 L2F: Tunnel PERRIS_HGW1 state change from open
state open
Jan 6 19:29:15.110 GMT: As34 Tnl/Cl 24/23 L2F: Session state change from closed
to opening
CH01i.book Page 70 Friday, April 30, 2004 8:58 AM
Troubleshooting L2F 71
Highlighted line 1 shows that there is one L2F tunnel and one L2F session established.
Highlighted lines 2 to 4 show the NASs name (LODI_NAS1), CLID (32), and IP address
(172.16.1.1). The Home Gateways name (PERRIS_HGW1), CLID (21), and IP address
(172.16.2.2) are shown in highlighted lines 5 to 7. Highlighted line 8 shows the tunnel state
(OPEN). Finally, highlighted lines 9 to 12 show the number of packets and bytes input and
output for the tunnel.
Tunnel establishment can fail for a number of reasons, including:
Lack of IP (and L2F) connectivity to the Home Gateway. To verify IP connectivity, the
ping command can be used. You should also verify that no access lists are blocking L2F.
L2F uses UDP port 1701.
The NAS is congured with an incorrect IP address for the Home Gateway. To verify that
the NAS is congured with the correct IP address for the Home Gateway, simply check
the initiate-to ip Home_Gateway_address command under the VPDN group on the NAS
or verify the IP address specied in the tunnel denition on the RADIUS server.
Home Gateway does not recognize the NAS. Check that the Home Gateway is correctly
congured to terminate tunnels from the NAS. Ensure that the NASs name is specied
with the terminate-from hostname NAS_name under the VPDN group.
There is a VPDN protocol mismatch between the NAS and the Home Gateway.
Tunnel authentication fails.
Troubleshooting a VPDN protocol mismatch and tunnel authentication failure are examined in
depth in this section.
If your tunnel denition is stored on a AAA server, be sure to see the case study entitled
Miscongured L2F Tunnel Denition on the AAA Server toward the end of this chapter.
Example 2-43 Output of the show vpdn tunnel all Command
LODI_NAS1#show vpdn tunnel all
% No active L2TP tunnels
L2F Tunnel Information Total tunnels 1 sessions 1
NAS name: LODI_NAS1
NAS CLID: 32
NAS IP address 172.16.1.1
Gateway name: PERRIS_HGW1
Gateway CLID: 21
Gateway IP address 172.16.2.2
State: open
Packets out: 17
Bytes out: 1400
Packets in: 12
Bytes in: 501
LODI_NAS1#
CH01i.book Page 71 Friday, April 30, 2004 8:58 AM
72 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
VPDN Protocol Mismatch
If there is a VPDN protocol mismatch between the NAS and the Home Gateway, tunnel setup
will fail.
Use the debug vpdn l2x-events command to troubleshoot a VPDN protocol mismatch, as
shown in Examples 2-44 to 2-46.
Highlighted lines 1 and 2 in Example 2-44 show that interface serial 0/0:0 is connected to 1111
and that interface async 34 has changed state to up. The remote access client is now connected
to the NAS.
In highlighted line 3, the NAS opens a UDP (L2F) connection to the Home Gateway. The NAS
sends an L2F_CONF here, although it is not explicitly shown in Example 2-44.
There is no response to the NASs L2F_CONF, and in Example 2-45 (highlighted line 1), the
NAS resends it.
Example 2-44 Output of the debug vpdn events Command When L2F Initialization Is Unsuccessful
LODI_NAS1#debug vpdn l2x-events
L2X protocol events debugging is on
LODI_NAS1#
Jan 6 19:39:26.878 GMT: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected
to 1111
Jan 6 19:39:52.462 GMT: %LINK-3-UPDOWN: Interface Async38, changed state to up
Jan 6 19:39:57.666 GMT: Tnl 28 L2F: UDP socket opened to 172.16.2.2 using
source 172.16.1.1
Jan 6 19:39:57.666 GMT: Tnl 28 L2F: Tunnel state change from closed state
opening
Example 2-45 The NAS Resends the L2F_CONF
Jan 6 19:40:02.898 GMT: Tnl 28 L2F: Resending L2F_CONF, time #1 max 6
Jan 6 19:40:07.898 GMT: Tnl 28 L2F: Tunnel in state opening with Sessions being
aborted
Jan 6 19:40:07.898 GMT: Tnl 28 L2F: Tunnel state change from opening state
closing
Jan 6 19:40:07.898 GMT: Tnl 28 L2F: Tunnel state change from closing state
closed
Jan 6 19:40:07.898 GMT: L2F: Closed tunnel structure
Jan 6 19:40:07.898 GMT: Tnl 28 L2F: Tunnel state change from closed state
opening
Jan 6 19:40:07.902 GMT: Tnl 28 L2F: Tunnel in state opening with Sessions being
aborted with remote close requested
CH01i.book Page 72 Friday, April 30, 2004 8:58 AM
Troubleshooting L2F 73
The NAS now sends an L2F_CLOSE to request tunnel shutdown as shown in Example 2-46.
In highlighted line 1 in Example 2-46, the NAS sends the L2F_CLOSE to notify the Home
Gateway of its intention to terminate tunnel establishment.
Then in highlighted lines 2 and 3, interface async 38 changes the state to down, and the interface
serial 0/0:0 is disconnected from 1111 (the remote access client). Tunnel intialization has failed.
Note that the debug vpdn l2x-errors command also shows this failure.
An examination of the VPDN group conguration on the Home Gateway shows the results in
Example 2-47. Note that only the relevant portion of the output is shown.
As you can see, the Home Gateway is correctly congured to terminate a tunnel from the NAS
but, unfortunately, is congured to terminate L2TP tunnels and not L2F tunnels.
Example 2-46 NAS Sends an L2F_CLOSE
Jan 6 19:40:07.902 GMT: Tnl 28 L2F: Requesting Tunnel shutdown via L2F-Close
Jan 6 19:40:07.902 GMT: Tnl 28 L2F: Tunnel state change from opening state
close-wait
Jan 6 19:40:07.902 GMT: Tnl 28 L2F: Tunnel state change from close-wait state
closed
Jan 6 19:40:07.902 GMT: L2F: Closed tunnel structure
Jan 6 19:40:09.902 GMT: %LINK-3-UPDOWN: Interface Async38, changed state to
down
Jan 6 19:40:10.554 GMT: %ISDN-6-DISCONNECT: Interface Serial0/0:0 disconnected
from 1111 , call lasted 43 seconds
Jan 6 19:40:11.906 GMT: %LINK-5-CHANGED: Interface Async38, changed state to
reset
Jan 6 19:40:16.906 GMT: %LINK-3-UPDOWN: Interface Async38, changed state to
down
LODI_NAS1#
Example 2-47 VPDN Group Configuration on the Home Gateway
PERRIS_HGW1#show running-config
Building configuration...
!
vpdn-group 1
accept-dialin
protocol l2tp
virtual-template 1
terminate-from hostname LODI_NAS1
!
CH01i.book Page 73 Friday, April 30, 2004 8:58 AM
74 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
The conguration is modied as in Example 2-48.
When the client reconnects, tunnel establishment is successful. The output of the show vpdn
tunnel command conrms this, as demonstrated in Example 2-49.
Highlighted line 1 shows that one tunnel and one session have been established. In highlighted
lines 2 to 5, the Home Gateways name (PERRIS_HGW1), CLID (30), and IP address
(172.16.2.2) are shown.
Tunnel Authentication Failure
In the section entitled Technical Overview of L2F earlier in this chapter, you saw that the
NAS and the Home Gateway must authenticate each other before the L2F tunnel can be
established. If tunnel authentication fails, tunnel establishment will not succeed.
Figure 2-33 illustrates tunnel authentication between the NAS and the Home Gateway.
Before examining what happens when tunnel authentication fails, it is worthwhile to have
another look at the tunnel establishment sequence when tunnel authentication succeeds. Use the
debug vpdn l2x-events command to examine the L2F tunnel establishment sequence.
Example 2-48 Reconfiguration of Home Gateway to Terminate L2F Tunnels
PERRIS_HGW1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
PERRIS_HGW1(config)#vpdn-group 1
PERRIS_HGW1(config-vpdn)#accept-dialin
PERRIS_HG(config-vpdn-acc-in)#protocol l2f
PERRIS_HG(config-vpdn-acc-in)#exit
PERRIS_HGW1(config-vpdn)#terminate-from hostname LODI_NAS1
PERRIS_HGW1(config-vpdn)#end
PERRIS_HGW1#
Example 2-49 Successful L2F Tunnel Establishment
LODI_NAS1#show vpdn tunnel all
% No active L2TP tunnels
L2F Tunnel Information Total tunnels 1 sessions 1
NAS name: LODI_NAS1
NAS CLID: 36
NAS IP address 172.16.1.1
Gateway name: PERRIS_HGW1
Gateway CLID: 30
Gateway IP address 172.16.2.2
State: open
Packets out: 25
Bytes out: 2173
Packets in: 15
Bytes in: 685
CH01i.book Page 74 Friday, April 30, 2004 8:58 AM
Troubleshooting L2F 75
Figure 2-33 L2F Tunnel Establishment
Examples 2-50 and 2-51 show the L2F tunnel establishment process.
In highlighted line 1 in Example 2-50, you can see that the NAS has opened a UDP port (1701)
to 172.16.2.2 (the Home Gateway). Although it does not explicitly say so, a L2F_CONF
message is sent to the Home Gateway at this point.
It is worth reiterating once again that this L2F_CONF message contains, among other things, a
32-bit random number challenge.
Example 2-50 L2F Tunnel Authentication Succeeds
LODI_NAS1#debug vpdn l2x-events
L2X protocol events debugging is on
LODI_NAS1#
Jan 6 19:58:58.982 GMT: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected
to 1111
Jan 6 19:59:24.730 GMT: %LINK-3-UPDOWN: Interface Async38, changed state to up
Jan 6 19:59:29.942 GMT: Tnl 34 L2F: UDP socket opened to 172.16.2.2 using
source 172.16.1.1
Jan 6 19:59:29.942 GMT: Tnl 34 L2F: Tunnel state change from closed state
opening
Jan 6 19:59:29.974 GMT: Tnl 34 L2F: L2F_CONF received
Jan 6 19:59:29.974 GMT: Tnl 34 L2F: Received L2F-CONF from PERRIS_HGW1
Jan 6 19:59:29.978 GMT: Tnl 34 L2F: Tunnel PERRIS_HGW1 state change from
opening state open
Remote Access
Client
NAS
(172.16.1.1)
PSTN/
ISDN
Home Gateway
(172.16.2.2)
Service Provider
Backbone
1. Call
Reception
2. LCP
Negotiation
Authentication
(CHAP)
3. Partial
5. Tunnel Establishment 5. Home Gateway
Confirms Valid
Source / Protocol /
Resources
(Authentication)
4. Associate
Domain/DNIS/
Username to Tunnel
CH01i.book Page 75 Friday, April 30, 2004 8:58 AM
76 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
In highlighted line 2 of the output, you can see that the NAS receives a L2F_CONF message.
This also contains a 32-bit random number challenge.
Both the NAS and the Home Gateway at this point take the different random numbers that they
have received and, together with the congured tunnel password, calculate a MD5 hash value.
The NAS and the Home Gateway now begin tunnel establishment (Example 2-51).
In highlighted line 1 in Example 2-51, the NAS sends an L2F_OPEN message to the Home
Gateway. This message contains a hash value calculated on the random number received from
the Home Gateway in the L2F_CONF in highlighted line 2 of Example 2-50 and the tunnel
password congured on the NAS.
In highlighted line 2, a L2F_OPEN message is received from the Home Gateway. This message
is crucial, and it has two functions. First, it shows that the Home Gateway has successfully
authenticated the NAS based on the hash value sent. Second, it contains in turn the hash value
that the Home Gateway has calculated based on the random number sent by the NAS (in the
L2F_CONF in highlighted line 1 of Example 2-50), together with the tunnel password
congured on the Home Gateway. At this stage, the Home Gateway has successfully
authenticated the NAS, but the NAS has not yet authenticated the Home Gateway.
In highlighted line 3, the NAS reports that the session state has moved from closed to opening.
This means that the NAS has now successfully authenticated the Home Gateway, and the tunnel
has been established.
If you are a little lost, it is probably a good idea to reread the section entitled L2F Tunnel
Establishment at the beginning of the chapter.
You have now seen what happens when L2F tunnel authentication succeeds, but what happens
if the authentication fails? Once again, use the debug vpdn l2x-events command to examine
the tunnel establishment sequence.
Examples 2-52 to 2-54 show the output from the debug vpdn l2x-events command when
tunnel authentication fails.
Example 2-51 L2F Tunnel Authentication
Jan 6 19:59:29.978 GMT: Tnl 34 L2F: Replying with L2F-OPEN, Tunnel in Open-Wait
Jan 6 19:59:30.002 GMT: Tnl 34 L2F: L2F_OPEN received
Jan 6 19:59:30.002 GMT: Tnl 34 L2F: OPEN from PERRIS_HGW1 received for tunnel
in state open
Jan 6 19:59:30.002 GMT: Tnl 34 L2F: Tunnel PERRIS_HGW1 state change from open
state open
Jan 6 19:59:30.006 GMT: As38 Tnl/Cl 34/28 L2F: Session state change from closed
to opening
CH01i.book Page 76 Friday, April 30, 2004 8:58 AM
Troubleshooting L2F 77
In highlighted lines 1 and 2 in Example 2-52, interface serial 0/0:0 is connected to 1111, and
interface async 36 changes state to up. The remote access client is connected to the NAS.
Highlighted line 3 again shows that a UDP socket has been opened, and L2F_CONF sent, to
the Home Gateway.
The Home Gateway (Perris_HGW1) then responds with a L2F_CONF (highlighted lines 4 and
5). Remember that these two L2F_CONF packets contain the random number authentication
challenges.
L2F tunnel establishment then proceeds, as shown in Example 2-53.
The NAS then sends an L2F_OPEN to the Home Gateway (Example 2-53, highlighted line 1).
This contains the response (MD5 hash) to the Home Gateways challenge that it sent in its
L2F_CONF (Example 2-52, highlighted line 4).
Example 2-52 L2F Tunnel Authentication Fails
LODI_NAS1#debug vpdn l2x-events
L2X protocol events debugging is on
LODI_NAS1#
Jan 6 20:10:37.246 GMT: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected
to 1111
Jan 6 20:11:02.990 GMT: %LINK-3-UPDOWN: Interface Async36, changed state to up
Jan 6 20:11:08.190 GMT: Tnl 38 L2F: UDP socket opened to 172.16.2.2 using
source 172.16.1.1
Jan 6 20:11:08.190 GMT: Tnl 38 L2F: Tunnel state change from closed state
opening
Jan 6 20:11:08.222 GMT: Tnl 38 L2F: L2F_CONF received
Jan 6 20:11:08.222 GMT: Tnl 38 L2F: Received L2F-CONF from PERRIS_HGW1
Jan 6 20:11:08.226 GMT: Tnl 38 L2F: Tunnel PERRIS_HGW1 state change from
opening state open
Example 2-53 L2F Tunnel Establishment Proceeds
Jan 6 20:11:08.226 GMT: Tnl 38 L2F: Replying with L2F-OPEN, Tunnel in Open-Wait
Jan 6 20:11:13.610 GMT: Tnl 38 L2F: Resending L2F_OPEN, time #1 max 6
Jan 6 20:11:18.610 GMT: Tnl 38 L2F: Tunnel in state open with Sessions being
aborted
Jan 6 20:11:18.610 GMT: Tnl 38 L2F: Tunnel PERRIS_HGW1 state change from open
state closing
Jan 6 20:11:18.610 GMT: Tnl 38 L2F: Tunnel PERRIS_HGW1 state change from
closing state closed
Jan 6 20:11:18.610 GMT: L2F: Closed tunnel structure
Jan 6 20:11:18.610 GMT: Tnl 38 L2F: Tunnel PERRIS_HGW1 state change from closed
state opening
Jan 6 20:11:18.614 GMT: Tnl 38 L2F: Tunnel in state opening with Sessions being
aborted with remote close requested
CH01i.book Page 77 Friday, April 30, 2004 8:58 AM
78 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
In highlighted line 2, you can see that the NAS has re-sent the L2F_OPEN to the Home
Gateway. The Home Gateway should respond with an L2F_OPEN, but nothing is received.
The NAS now aborts tunnel establishment (Example 2-54).
The NAS sends a L2F_CLOSE message to the Home Gateway (Example 2-54, highlighted line
1). This serves as notication that tunnel establishment is being aborted.
Finally, in highlighted lines 2 and 3, interface serial 0/0:0 disconnects from 1111, and interface
async 36 changes state to down. Tunnel establishment has failed.
The next step is to have a look at what happens on the Home Gateway when the NAS reattempts
tunnel establishment.
Use the debug vpdn l2x-errors command to examine tunnel establishment errors.
Example 2-55 shows the output of the debug vpdn l2x-errors command when the NAS
reattempts tunnel establishment.
Example 2-54 NAS Aborts Tunnel Establishment
Jan 6 20:11:18.614 GMT: Tnl 38 L2F: Requesting Tunnel shutdown via L2F-Close
Jan 6 20:11:18.614 GMT: Tnl 38 L2F: Tunnel PERRIS_HGW1 state change from
opening state close-wait
Jan 6 20:11:18.614 GMT: Tnl 38 L2F: Tunnel PERRIS_HGW1 state change from
close-wait state closed
Jan 6 20:11:18.614 GMT: L2F: Closed tunnel structure
Jan 6 20:11:20.090 GMT: %ISDN-6-DISCONNECT: Interface Serial0/0:0 disconnected
from 1111 , call lasted 42 seconds
Jan 6 20:11:20.614 GMT: %LINK-3-UPDOWN: Interface Async36, changed state to
down
Jan 6 20:11:22.618 GMT: %LINK-5-CHANGED: Interface Async36, changed state to
reset
Jan 6 20:11:27.618 GMT: %LINK-3-UPDOWN: Interface Async36, changed state to
down
LODI_NAS1#
Example 2-55 L2F Tunnel Authentication Failure
PERRIS_HGW1#debug vpdn l2x-errors
L2X protocol errors debugging is on
PERRIS_HGW1#
.Jan 6 20:17:18.876 GMT: Tnl 16 L2F: Packet has bogus2 key DB3046F8 A9634082
.Jan 6 20:17:21.408 GMT: Tnl 16 L2F: Resending L2F_CONF, time #1 max 6
.Jan 6 20:17:22.068 GMT: Tnl 16 L2F: Packet has bogus2 key DB3046F8 A9634082
.Jan 6 20:17:26.412 GMT: Tnl 16 L2F: Resending L2F_CONF, time #2 max 6
.Jan 6 20:17:27.068 GMT: Tnl 16 L2F: Packet has bogus2 key DB3046F8 A9634082
PERRIS_HGW1#
CH01i.book Page 78 Friday, April 30, 2004 8:58 AM
Troubleshooting L2F 79
In highlighted line 1, the Home Gateway reports that it has received an L2F packet with a bogus
authentication key. The packet in question is the L2F_OPEN from the NAS.
In highlighted line 2, the Home Gateway resends its L2F_CONF message to the NAS.
Therefore, the authentication response from the NAS to the Home Gateways challenge is
incorrect. This can mean only one thing. Tunnel passwords must be congured inconsistently
on the NAS and the Home Gateway.
The service password-encryption command is congured on both the NAS and the Home
Gateway, so it is impossible to be sure where the tunnel password is miscongured. The
passwords are, therefore, recongured on both the NAS and the Home Gateway using the
conguration in Example 2-56.
When the client reconnects, L2F tunnel establishment succeeds. This is congured using the
show vpdn tunnel all command.
Example 2-57 shows the output of the show vpdn tunnel all command.
Example 2-56 Reconfiguration of the Tunnel Passwords
LODI_NAS1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
LODI_NAS1(config)#username LODI_NAS1 password cisco
LODI_NAS1(config)#username PERRIS_HGW1 password cisco
LODI_NAS1(config)#exit
LODI_NAS1#
PERRIS_HGW1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
PERRIS_HGW1(config)#username PERRIS_HGW1 password cisco
PERRIS_HGW1(config)#username LODI_NAS1 password cisco
PERRIS_HGW1(config)#exit
PERRIS_HGW1#
Example 2-57 show vpdn tunnel all Confirms Successful Tunnel Establishment
LODI_NAS1#show vpdn tunnel all
% No active L2TP tunnels
L2F Tunnel Information Total tunnels 1 sessions 1
NAS name: LODI_NAS1
NAS CLID: 37
NAS IP address 172.16.1.1
Gateway name: PERRIS_HGW1
Gateway CLID: 31
Gateway IP address 172.16.2.2
State: open
Packets out: 13
Bytes out: 959
Packets in: 11
Bytes in: 410
LODI_NAS1#
CH01i.book Page 79 Friday, April 30, 2004 8:58 AM
80 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
Highlighted line 1 reveals that one tunnel and one session have been established. Highlighted
lines 2 to 4 show the Home Gateways name (PERRIS_HGW1), CLID (31), and IP address
(172.16.2.2).
Troubleshooting L2F Session Establishment
Once tunnel setup has completed, session setup begins. Figure 2-34 shows L2F session setup.
Figure 2-34 L2F Session Setup
Before examining what happens when there is an L2F session setup failure, it is a good idea to
rst have a look at a successful session establishment using the debug vpdn l2x-events
command.
Example 2-58 shows the output of the debug vpdn l2x-events command when L2F session
establishment is successful. Note that only the relevant portion of the output is shown.
Remote Access
Client
NAS
(172.16.1.1)
PSTN/
ISDN
Home Gateway
(172.16.2.2)
Service Provider
Backbone
1. Call
Reception
2. LCP
Negotiation
Authentication
(CHAP)
3. Partial
5. Tunnel Establishment 5. Home Gateway
Confirms Valid
Source / Protocol /
Resources
(Authentication)
6. Client (Session)
Establishment
4. Associate
Domain/DNIS/
Username to Tunnel
CH01i.book Page 80 Friday, April 30, 2004 8:58 AM
Troubleshooting L2F 81
The NAS begins session establishment in highlighted line 1 in Example 2-58 by sending an
L2F_OPEN message. The Home Gateway responds with an L2F_OPEN (highlighted line 2),
and the session state changes from opening to open (highlighted line 3). The client session is
now established.
The message L2F: MID synced NAS/HG Clid=35/24 Mid=23 (highlighted line 4) conrms
that the CLIDs 35 and 24 are assigned to the tunnel by the NAS and the Home Gateway,
respectively, and that the MID to be used for this session is 23. The NAS is now free to forward
PPP frames between the Home Gateway and the client over the tunnel.
The show vpdn session command can also be used to conrm successful L2F session setup, as
shown in Example 2-59.
Highlighted line 1 shows the CLID, the MID, the username associated with the session, the
interface on which the client is connected, and the session state.
The most common cause of a session setup failure is the conguration of a session limit or the
VPDN softshut feature. This issue is examined in this section. The starting point for
troubleshooting this issue is the debug vpdn l2x-errors command.
Example 2-58 Successful L2F Session Establishment
LODI_NAS1#debug vpdn l2x-events
L2X protocol events debugging is on
LODI_NAS1#
Jan 6 19:29:15.110 GMT: As34 Tnl/Cl 24/23 L2F: Sending L2F-OPEN for New Session
Jan 6 19:29:15.578 GMT: As34 Tnl/Cl 24/23 L2F: L2F_OPEN received
Jan 6 19:29:15.578 GMT: As34 Tnl/Cl 24/23 L2F: OPEN received for existing
session in state opening
Jan 6 19:29:15.578 GMT: As34 Tnl/Cl 24/23 L2F: Session state change from
opening to open
Jan 6 19:29:15.578 GMT: As34 Tnl/Cl 24/23 L2F: MID synced NAS/HG Clid=35/24
Mid=23
Jan 6 19:29:16.110 GMT: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Async34, changed state to up
LODI_NAS1#
Example 2-59 Output of the show vpdn session Command
LODI_NAS1#show vpdn session
% No active L2TP tunnels
L2F Session Information Total tunnels 1 sessions 1
CLID MID Username Intf State
21 20 joebloggs@mjlnet.com As37 open
LODI_NAS1#
CH01i.book Page 81 Friday, April 30, 2004 8:58 AM
82 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
Examples 2-60 to 2-62 show the output from the debug vpdn l2x-errors command.
In highlighted line 1 in Example 2-60, interface serial 0/0:1 is connected to 1111, and in
highlighted line 2, interface async 38 changes state to up. The remote access client is now
connected to the NAS. An L2F_OPEN for the client session is sent to the Home Gateway at this
point (not shown).
L2F session setup fails, as shown in Example 2-61.
In highlighted line 1 in Example 2-61, the NAS receives an L2F_CLOSE for the client session.
The NAS then replies with an L2F_CLOSE.
In Example 2-62, the client interface changes state to down.
Interface async 38 now changes state to down (Example 2-62, highlighted line 1), and interface
serial 0/0:1 is disconnected from 1111. The L2F session setup has failed, and the client has been
disconnected.
Example 2-60 L2F Session Setup Fails
LODI_NAS1#debug vpdn l2x-errors
L2X protocol errors debugging is on
LODI_NAS1#
Jan 8 21:29:15.339 GMT: %ISDN-6-CONNECT: Interface Serial0/0:1 is now connected
to 1111
Jan 8 21:29:21.339 GMT: %ISDN-6-CONNECT: Interface Serial0/0:1 is now connected
to 1111
Jan 8 21:29:40.955 GMT: %LINK-3-UPDOWN: Interface Async38, changed state to up
Jan 8 21:29:46.215 GMT: As38 Tnl/Cl 2/8 L2F: Session_create: Tunnel in open
state
Example 2-61 L2F Session Setup Fails
Jan 8 21:29:46.271 GMT: As38 Tnl/Cl 2/8 L2F: Received Session CLOSE in state
opening Tunnel: open, WHY: 0x2000, STR:
Jan 8 21:29:46.271 GMT: As38 Tnl/Cl 2/8 L2F: Replying with Session CLOSE
Example 2-62 Client Interface Changes State to Down
Jan 8 21:29:48.275 GMT: %LINK-3-UPDOWN: Interface Async38, changed state to
down
Jan 8 21:29:48.367 GMT: %ISDN-6-DISCONNECT: Interface Serial0/0:1 disconnected
from 1111 , call lasted 33 seconds
Jan 8 21:29:50.275 GMT: %LINK-5-CHANGED: Interface Async38, changed state to
reset
Jan 8 21:29:55.275 GMT: %LINK-3-UPDOWN: Interface Async38, changed state to
down
LODI_NAS1#
CH01i.book Page 82 Friday, April 30, 2004 8:58 AM
Troubleshooting L2F 83
The reason for the session setup failure is contained in Example 2-61 highlighted line 1. Notice
the output WHY: 0x2000, STR:. This output indicates that the L2F_CLOSE shown in
highlighted line 1 contains the L2F_CLOSE_WHY and L2F_CLOSE_STR suboptions (see
Table 2-2).
The L2F_CLOSE_WHY contains the reason code for the close, and in this case it is 0x2000. If
you refer back to Table 2-3, you will see that this code indicates that a session limit has been
reached or that VPDN softshut has been congured.
The L2F_CLOSE_STR is an ASCII description of the tunnel or session close reason. In this
case, there is no ASCII description.
Having discovered the reason for the close, a look at the conguration of the Home Gateway in
Example 2-63 reveals the source of the problem.
In the highlighted line of output, you can see the statement vpdn session-limit 1. This, as the
syntax suggests, limits the L2F tunnel to one session. In this example, this limit has already
been reached.
This issue can be resolved by either removing the congured limit or revising it upward. In
Example 2-64, the limit is removed.
When the client reconnects, L2F session setup succeeds. This is veried using the show vpdn
tunnel all command, as shown in Example 2-65.
Example 2-63 Home Gateway Is Configured with a VPDN Session Limit of 1
PERRIS_HGW1#show running-config
Building configuration...
!
vpdn enable
vpdn session-limit 1
!
vpdn-group 1
accept-dialin
protocol l2f
virtual-template 1
terminate-from hostname LODI_NAS1
!
Example 2-64 Removal of the VPDN Session Limit
PERRIS_HGW1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
PERRIS_HGW1(config)#no vpdn session-limit 1
PERRIS_HGW1(config)#exit
PERRIS_HGW1#
CH01i.book Page 83 Friday, April 30, 2004 8:58 AM
84 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
In highlighted line 1, you can see that there is one tunnel and, importantly, now two sessions
established. Highlighted lines 2 to 4 show the Home Gateways name, CLID, and IP address.
The issue is now resolved.
As previously mentioned, the vpdn softshut command also causes session setup to fail. The
vpdn softshut command can be used by a network administrator to disallow any new sessions
to the Home Gateway, while at the same time allowing any existing sessions to continue until
they are closed in the normal way (for example, the client drops the connection). This allows
graceful tunnel shutdown. Removal of the vpdn softshut command (no vpdn softshut) allows
new sessions to be established.
Home Gateway/Remote Access Client PPP Negotiation Failure
Once the L2F tunnel and session have been set up, the next stage is for PPP negotiation to be
completed on the Home Gateway. Specically, LCP negotiation, PPP authentication, and NCP
negotiation must take place.
Before PPP negotiation can be completed on the Home Gateway, a virtual access interface must
be cloned from the virtual template. This virtual access interface is used to terminate the client
PPP connection from the remote client.
Before troubleshooting PPP negotiation issues on the Home Gateway, therefore, the rst thing
to do is to verify that conguration is being correctly cloned from the virtual template to the
virtual access interface.
Figure 2-35 shows the cloning of conguration from the virtual template to the virtual access
interface.
Example 2-65 L2F Session Setup Has Succeeded
LODI_NAS1#show vpdn tunnel all
% No active L2TP tunnels
L2F Tunnel Information Total tunnels 1 sessions 2
NAS name: LODI_NAS1
NAS CLID: 1
NAS IP address 172.16.1.1
Gateway name: PERRIS_HGW1
Gateway CLID: 1
Gateway IP address 172.16.2.2
State: open
Packets out: 119
Bytes out: 7204
Packets in: 149
Bytes in: 7475
LODI_NAS1#
CH01i.book Page 84 Friday, April 30, 2004 8:58 AM
Troubleshooting L2F 85
Figure 2-35 Cloning Configuration from the Virtual Template to the Virtual Access Interface
Cloning of conguration from the virtual template to the virtual access interface can be veried
with the debug vtemplate command, as demonstrated in Example 2-66.
Example 2-66 Configuration Is Cloned from the Virtual Template to the Virtual Access Interface
PERRIS_HGW1#debug vtemplate
Virtual Template debugging is on
PERRIS_HGW1#
Jan 6 20:20:25.304 UTC: Vi1 VTEMPLATE: Reuse Vi1, recycle queue size 3
Jan 6 20:20:25.304 UTC: Vi1 VTEMPLATE: Hardware address 0006.535a.efc0
Jan 6 20:20:25.304 UTC: Vi1 VTEMPLATE: Has a new cloneblk vtemplate, now it has
vtemplate
Jan 6 20:20:25.304 UTC: Vi1 VTEMPLATE: ************* CLONE VACCESS1 ***********
******
Jan 6 20:20:25.308 UTC: Vi1 VTEMPLATE: Clone from Virtual-Template1interface
Virtual-Access1
default ip address
no ip address
encap ppp
ip unnum e0/0
encap ppp
peer default ip address pool PERRIS_POOL
Remote Access
Client
NAS
(172.16.1.1)
PSTN/
ISDN
Home Gateway
(172.16.2.2)
Service Provider
Backbone
1. Call
Reception
2. LCP
Negotiation
Authentication
(CHAP)
3. Partial
5. Tunnel Establishment 5. Home Gateway
Confirms Valid
Source / Protocol /
Resources
7. Virtual Template
Config Cloned to Virtual
Access Interface
(Authentication)
6. Client (Session)
Establishment
4. Associate
Domain/DNIS/
Username to Tunnel
CH01i.book Page 85 Friday, April 30, 2004 8:58 AM
86 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
Highlighted line 1 shows that conguration is about to be cloned from the virtual template to
virtual access interface 1. Highlighted lines 2 to 7 show the precise conguration cloned to the
virtual access interface. The virtual access interface then changes state to up (highlighted line
8). Finally, in highlighted line 9, the line protocol on the virtual access interface changes state
to up. The conguration has been successfully cloned to the virtual access interface.
If no conguration is cloned to the virtual access interface, use the show running-cong
command to verify that the virtual template is correctly referenced in the VPDN group
conguration, as demonstrated in Example 2-67.
In this case, the virtual template is correctly referenced in the conguration of the VPDN group.
If you have user-specic conguration stored on a AAA server, as you troubleshooting PPP
negotiation be sure to verify that this conguration is correct, and that it is being downloaded
to the Home Gateway. One useful command when troubleshooting the download of user-
specic conguration is debug aaa per-user.
LCP Negotiation or PPP Authentication Failures
Once the virtual template conguration has been cloned to the virtual access interface, the
Home Gateway attempts to complete LCP negotiation and authenticate the remote client.
Figure 2-36 shows the LCP negotiation and authentication phase between the client and the
Home Gateway.
ppp multi
ppp authen chap
end
Jan 6 20:20:25.713 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed
state to up
Jan 6 20:20:26.726 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Virtual-Access1, changed state to up
PERRIS_HGW1#
Example 2-67 VPDN Group Configuration Contains Reference to the Virtual Template
PERRIS_HGW1#show running-config
Building configuration...
!
vpdn-group 1
accept-dialin
protocol l2f
virtual-template 1
terminate-from hostname LODI_NAS1
!
Example 2-66 Configuration Is Cloned from the Virtual Template to the Virtual Access Interface (Continued)
CH01i.book Page 86 Friday, April 30, 2004 8:58 AM
Troubleshooting L2F 87
The Home Gateway has two choices at this point. It can simply complete LCP negotiation and
authentication with the client based on the information sent to it by the NAS (LCP CONFREQ
and CONFACKs, plus clients username and authentication response), or it can restart LCP
negotiation or authentication.
Figure 2-36 Home Gateway Negotiates LCP and Authenticates the Remote Access Client
Use the debug ppp negotiation command to examine the PPP negotiation sequence (including
LCP negotiation and PPP authentication) on the Home Gateway.
Before examining what happens when LCP negotiation or PPP authentication fail, it is worth
taking a look at what happens when LCP negotiation and PPP authentication succeed (see
Examples 2-68 to 2-71).
Example 2-68 Successful LCP Negotiation and Authentication Between the Home Gateway and the Client
PERRIS_HGW1#debug ppp negotiation
PPP protocol negotiation debugging is on
PERRIS_HGW1#
Jan 6 20:25:12.379 UTC: Vi4 PPP: Phase is DOWN, Setup
Jan 6 20:25:12.796 UTC: %LINK-3-UPDOWN: Interface Virtual-Access4, changed
state to up
Jan 6 20:25:12.800 UTC: Vi4 PPP: Using set call direction
Remote Access
Client
NAS
(172.16.1.1)
PSTN/
ISDN
Home Gateway
(172.16.2.2)
Service Provider
Backbone
1. Call
Reception
2. LCP
Negotiation
Authentication
(CHAP)
3. Partial
8. LCP Negotiation / PPP Authentication
Completed
5. Tunnel Establishment 5. Home Gateway
Confirms Valid
Source / Protocol /
Resources
7. Virtual Template
Config Cloned to Virtual
Access Interface
(Authentication)
6. Client (Session)
Establishment
4. Associate
Domain/DNIS/
Username to Tunnel
CH01i.book Page 87 Friday, April 30, 2004 8:58 AM
88 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
In highlighted line 1 (Example 2-68), virtual access interface 4 changes state to up. The client
is now connected to the Home Gateway. Highlighted line 2 shows that the PPP phase is
ESTABLISHING.
LCP negotiation now begins with the processing of an inbound FORCED CONFREQ by the
Home Gateway, as shown in Example 2-69.
Highlighted line 1 (Example 2-69) shows that the inbound (I) FORCED CONFREQ has been
received by the Home Gateway.
This FORCED CONFREQ is not, in fact, a CONFREQ received directly from the client but is,
instead, the CONFREQ forwarded by the NAS (L2F_REQ_LCP0) during L2F session setup.
This is the initial CONFREQ received by the NAS during LCP negotiation with the client.
The Home Gateway now processes an inbound FORCED CONFACK, as shown in Example 2-70.
The Home Gateway processes the inbound FORCED CONFACK (Example 2-70, highlighted
line 1). Again, this is not received directly from the client but is, instead, a CONFACK
forwarded by the NAS during L2F session setup (L2F_ACK_LCP2). This is the LCP
CONFACK sent by the NAS during the LCP negotiation with the remote access client.
LCP negotiation is now complete, and authentication begins, as shown in Example 2-71.
Jan 6 20:25:12.800 UTC: Vi4 PPP: Treating connection as a callin
Jan 6 20:25:12.800 UTC: Vi4 PPP: Phase is ESTABLISHING, Passive Open
Jan 6 20:25:12.800 UTC: Vi4 LCP: State is Listen
Example 2-69 Forced LCP CONFREQ
Jan 6 20:25:12.800 UTC: Vi4 LCP: I FORCED CONFREQ len 21
Jan 6 20:25:12.804 UTC: Vi4 LCP: ACCM 0x000A0000 (0x0206000A0000)
Jan 6 20:25:12.804 UTC: Vi4 LCP: AuthProto CHAP (0x0305C22305)
Jan 6 20:25:12.804 UTC: Vi4 LCP: MagicNumber 0x11ADEB98 (0x050611ADEB98)
Jan 6 20:25:12.804 UTC: Vi4 LCP: PFC (0x0702)
Jan 6 20:25:12.804 UTC: Vi4 LCP: ACFC (0x0802)
Example 2-70 Forced LCP CONFACK
Jan 6 20:25:12.804 UTC: Vi4 LCP: I FORCED CONFACK len 16
Jan 6 20:25:12.804 UTC: Vi4 LCP: ACCM 0x00000000 (0x020600000000)
Jan 6 20:25:12.808 UTC: Vi4 LCP: MagicNumber 0x0000725F (0x05060000725F)
Jan 6 20:25:12.808 UTC: Vi4 LCP: PFC (0x0702)
Jan 6 20:25:12.808 UTC: Vi4 LCP: ACFC (0x0802)
Example 2-71 PPP Authentication Begins
Jan 6 20:25:12.812 UTC: Vi4 PPP: Phase is AUTHENTICATING, by this end
Jan 6 20:25:12.812 UTC: Vi4 CHAP: O CHALLENGE id 8 len 32 from "PERRIS_HGW1"
Jan 6 20:25:12.816 UTC: Vi4 CHAP: I RESPONSE id 9 len 40 from
"joebloggs@mjlnet.com"
Jan 6 20:25:12.820 UTC: Vi4 CHAP: O SUCCESS id 9 len 4
Jan 6 20:25:12.820 UTC: Vi4 PPP: Phase is UP
Example 2-68 Successful LCP Negotiation and Authentication Between the Home Gateway and the Client
CH01i.book Page 88 Friday, April 30, 2004 8:58 AM
Troubleshooting L2F 89
In highlighted line 1 in Example 2-71, the PPP phase changes to AUTHENTICATING,
indicating that authentication is about to begin. In highlighted line 2, the NAS sends a CHAP
Challenge to the client. The client replies with a Response message (highlighted line 3). The
NAS then sends a Success message to the client in highlighted line 4. LCP negotiation and
authentication has succeeded on the Home Gateway.
In the following scenario, PPP authentication fails between the remote access client and the
Home Gateway. Again, use the debug ppp negotiation command to verify PPP negotiation
between the Home Gateway and the remote access client.
Example 2-72 shows the output of the debug ppp negotiation command when authentication
fails between the Home Gateway and the client. Note that only the relevant portion of the output
is shown.
Highlighted line 1 shows that the PPP phase is AUTHENTICATING. Authentication is about
to begin. In highlighted line 2, the Home Gateway sends a CHAP Challenge to the client. The
client replies with a Response message in highlighted line 3. Then in highlighted line 4, the
Home Gateway sends a Failure message to the client. Authentication has failed.
The PPP connection now terminates, as shown in Example 2-73.
Example 2-72 PPP Authentication Fails Between the Home Gateway and the Remote Access Client
PERRIS_HGW1#debug ppp negotiation
PPP protocol negotiation debugging is on
Jan 6 20:28:34.280 UTC: Vi3 PPP: Phase is AUTHENTICATING, by this end
Jan 6 20:28:34.280 UTC: Vi3 CHAP: O CHALLENGE id 9 len 32 from "PERRIS_HGW1"
Jan 6 20:28:34.284 UTC: Vi3 CHAP: I RESPONSE id 9 len 40 from
"joebloggs@mjlnet.com"
Jan 6 20:28:34.288 UTC: Vi3 CHAP: O FAILURE id 9 len 25 msg is "MD/DES compare
failed"
Example 2-73 PPP Connection Teardown Begins
Jan 6 20:28:34.288 UTC: Vi3 PPP: Phase is TERMINATING
Jan 6 20:28:34.288 UTC: Vi3 LCP: O TERMREQ [Open] id 1 len 4
Jan 6 20:28:34.404 UTC: Vi3 LCP: I TERMREQ [TERMsent] id 4 len 8 (0x00000005)
Jan 6 20:28:34.404 UTC: Vi3 LCP: O TERMACK [TERMsent] id 4 len 4
Jan 6 20:28:34.412 UTC: Vi3 LCP: I TERMACK [TERMsent] id 1 len 4
Jan 6 20:28:34.412 UTC: Vi3 LCP: State is Closed
Jan 6 20:28:34.412 UTC: Vi3 PPP: Phase is DOWN
Jan 6 20:28:34.416 UTC: Vi3 PPP: Phase is ESTABLISHING, Passive Open
Jan 6 20:28:34.416 UTC: Vi3 LCP: State is Listen
Jan 6 20:28:34.500 UTC: Vi3 PPP: No remote authentication for call-in
Jan 6 20:28:34.817 UTC: %LINK-3-UPDOWN: Interface Virtual-Access3, changed
state to down
Jan 6 20:28:34.817 UTC: Vi3 LCP: State is Closed
Jan 6 20:28:34.817 UTC: Vi3 PPP: Phase is DOWN
PERRIS_HGW1#
CH01i.book Page 89 Friday, April 30, 2004 8:58 AM
90 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
In highlighted line 1, the PPP phase changes to TERMINATING. The PPP connection is about
to be torn down. In highlighted lines 2 to 5, the Home Gateway and the client exchange
TERMREQ and TERMACK messages, then in highlighted line 6, the PPP phase changes
state to DOWN. Finally, in highlighted line 7, the virtual access interface changes state to down.
PPP authentication has failed, and the client connection has been torn down. This indicates that
the clients username or password is miscongured on the client or Home Gateway. In this case,
the client conrms that he is using the correct username and password, and so one or the other
must be miscongured on the Home Gateway.
The clients username and password are then recongured on the Home Gateway, as shown in
Example 2-74.
When the client reconnects, PPP authentication succeeds. This is veried using the show caller
user on the Home Gateway, as shown in Example 2-75.
Highlighted line 1 shows that user joebloggs@mjlnet.com is now connected to interface
virtual access 1 and that the interface virtual access 1 is running the PPP service over L2F.
In highlighted line 2, you can see that LCP, CHAP, and IPCP have been negotiated with the
remote access client. Note that multilink PPP (MP) has not been negotiated with the client and
so is in a Closed state. The issue is now resolved.
Example 2-74 Reconfiguration of the Clients Username and Password on the Home Gateway
PERRIS_HGW1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
PERRIS_HGW1(config)#username joebloggs@mjlnet.com password cisco
PERRIS_HGW1(config)#end
PERRIS_HGW1#
Example 2-75 Output of the show caller user Command on the Home Gateway
PERRIS_HGW1#show caller user joebloggs@mjlnet.com
User: joebloggs@mjlnet.com, line Vi1, service PPP L2F
Active time 00:33:06, Idle time 00:00:07
Timeouts: Absolute Idle
Limits: - -
Disconnect in: - -
PPP: LCP Open, multilink Closed, CHAP (<- local), IPCP
IP: Local 172.16.2.2, remote 10.10.10.50
VPDN: NAS LODI_NAS1, MID 2, MID open
HGW PERRIS_HGW1, NAS CLID 1, HGW CLID 1, tunnel open
Counts: 279 packets input, 10883 bytes, 0 no buffer
0 input errors, 0 CRC, 0 frame, 0 overrun
668 packets output, 0 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
PERRIS_HGW1#
CH01i.book Page 90 Friday, April 30, 2004 8:58 AM
Troubleshooting L2F 91
Note that the debug ppp authentication command can also be used to verify PPP
authentication.
One other thing to check when verifying PPP authentication on the Home Gateway is that the
client is not trying to authenticate the Home Gateway. If you are using CHAP authentication,
check for any inbound (I) CHAP Challenge messages received from the client. If CHAP
Challenges are being received, recongure the client not to authenticate the Home Gateway
(unless intended).
Also, if you are using a AAA server, see the case studies entitled Remote AAA (RADIUS)
Authentication Fails for the Remote Access Client and Remote AAA (RADIUS)
Authorization Fails for the Remote Access Client toward the end of this chapter.
Finally, it is worth noting that if the Home Gateway does not accept the options in the LCP
messages passed to it by the NAS (L2F_REQ_LCP0 and L2F_ACK_LCP2; see Examples
2-69 and 2-70), then you will see a message such as PPP LCP not accepting rcv CONFACK
indicating that LCP negotiation has failed. In this case, one option is to congure the Home
Gateway to renegotiate LCP with the remote access client using the lcp renegotiation {always
| on-mismatch} command (under the VPDN group).
NCP Negotiation Failure
Once the Home Gateway has completed LCP negotiation and PPP authentication with the
remote access client, NCP negotiation begins. If the network layer conguration is incorrect on
the virtual template interface, NCP negotiation might fail.
Figure 2-37 illustrates the NCP negotiation between the client and the Home Gateway.
Before having a look at what happens when NCP negotiation fails, it is a good idea to examine
a successful NCP negotiation sequence between the Home Gateway and the client. Use the
debug ppp negotiation command to examine the NCP negotiation sequence between the
Home Gateway and the client.
CH01i.book Page 91 Friday, April 30, 2004 8:58 AM
92 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
Figure 2-37 NCP Negotiation Between the Home Gateway and the Remote Access Client
Examples 2-76 to 2-88 show the output of the debug ppp negotiation command when NCP
negotiation is successful. Only the relevant portion of the output is shown.
Once LCP negotiation and authentication have taken place, the PPP state changes to UP
(highlighted line 1). NCP negotiation now begins (see Example 2-77).
Example 2-76 NCP Negotiation Succeeds Between the Home Gateway and the Remote Access Client
PERRIS_HGW1#debug ppp negotiation
PPP protocol negotiation debugging is on
PERRIS_HGW1#
Jan 6 20:36:29.604 UTC: Vi4 PPP: Phase is UP
Example 2-77 NCP Negotiation Begins
Jan 6 20:36:29.604 UTC: Vi4 IPCP: O CONFREQ [Closed] id 1 len 10
Jan 6 20:36:29.604 UTC: Vi4 IPCP: Address 10.10.10.1 (0x03060A0A0A01)
Remote Access
Client
NAS
(172.16.1.1)
PSTN/
ISDN
Home Gateway
(172.16.2.2)
Service Provider
Backbone
1. Call
Reception
2. LCP
Negotiation
Authentication
(CHAP)
3. Partial
8. PPP Authentication
Completed
9. NCP
Negotiation
5. Tunnel Establishment 5. Home Gateway
Confirms Valid
Source / Protocol /
Resources
7. Virtual Template
Config Cloned to Virtual
Access Interface
(Authentication)
6. Client (Session)
Establishment
4. Associate
Domain/DNIS/
Username to Tunnel
CH01i.book Page 92 Friday, April 30, 2004 8:58 AM
Troubleshooting L2F 93
The Home Gateway initiates IPCP negotiation by sending an IPCP (IP Control Protocol)
CONFREQ to the client (see Example 2-77). In it, the Home Gateway species its own IP
address (IPCP option 0x03, IP-Address).
The remote access client then requests conguration of Microsoft Point-to-Point Compression
(MS-PPC), as shown in Example 2-78.
The Home Gateway receives an inbound (I) Compression Control Protocol (CCP) CONFREQ
from the client (in Example 2-78).
Within it, the client requests conguration of MS-PPC (option 0x12).
The Home Gateway rejects conguration of MS-PPC in Example 2-79 by sending a PROTREJ
message.
Following the rejection of MS-PPC, the client sends an IPCP CONFREQ to the Home Gateway
in Example 2-80.
The IPCP CONFREQ from the client shown in Example 2-80 requests Van Jacobson
compression (option 0x02), an IP address (option 0x03), and both primary and secondary DNS
and WINS server addresses (options 0x81, 0x82, 0x83, and 0x84, respectively).
The Home Gateway now obtains an IP address for the client in response to its request, as shown
in Example 2-81.
Example 2-78 Client Requests MS-PPC
Jan 6 20:36:29.712 UTC: Vi4 CCP: I CONFREQ [Not negotiated] id 4 len 10
Jan 6 20:36:29.712 UTC: Vi4 CCP: MS-PPC supported bits 0x00000001
(0x120600000001)
Example 2-79 Home Gateway Rejects MS-PPC
Jan 6 20:36:29.716 UTC: Vi4 LCP: O PROTREJ [Open] id 1 len 16 protocol CCP
(0x80FD0104000A120600000001)
Example 2-80 Client Sends an IPCP CONFREQ
Jan 6 20:36:29.728 UTC: Vi4 IPCP: I CONFREQ [REQsent] id 5 len 40
Jan 6 20:36:29.728 UTC: Vi4 IPCP: CompressType VJ 15 slots CompressSlotID
(0x0206002D0F01)
Jan 6 20:36:29.728 UTC: Vi4 IPCP: Address 0.0.0.0 (0x030600000000)
Jan 6 20:36:29.728 UTC: Vi4 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000)
Jan 6 20:36:29.728 UTC: Vi4 IPCP: PrimaryWINS 0.0.0.0 (0x820600000000)
Jan 6 20:36:29.732 UTC: Vi4 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000)
Jan 6 20:36:29.732 UTC: Vi4 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000)
Example 2-81 Home Gateway Obtains an IP Address from Its Pool
Jan 6 20:36:29.732 UTC: Vi4 IPCP: Pool returned 10.10.10.50
CH01i.book Page 93 Friday, April 30, 2004 8:58 AM
94 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
The Home Gateway then sends a CONFREJ to the client rejecting its request for Van
Jacobson compression, primary/secondary WINS, and secondary DNS server addresses (see
Example 2-82).
The client acknowledges the Home Gateways IP address with a CONFACK (Example 2-83).
This is in response to the CONFREQ sent by the Home Gateway in Example 2-77.
In Example 2-84, the client sends a second CONFREQ requesting an IP address and a primary
DNS server address.
Note that these are the only IPCP options not rejected in the Home Gateways CONFREJ (see
Example 2-82).
The Home Gateway responds with a Congure-Nak (CONFNACK) in Example 2-85. This is
used to supply the client with an IP address and primary DNS server address. The IP address is
the one obtained from the pool in Example 2-81.
The client then responds with another CONFREQ in Example 2-86. This serves to conrm the
IP and DNS server address just supplied by the Home Gateway.
Example 2-82 Home Gateway Rejects the Request for Van Jacobson Compression, Primary/Secondary WINS, and
Secondary DNS Server Addresses
Jan 6 20:36:29.732 UTC: Vi4 IPCP: O CONFREJ [REQsent] id 5 len 28
Jan 6 20:36:29.736 UTC: Vi4 IPCP: CompressType VJ 15 slots CompressSlotID
(0x0206002D0F01)
Jan 6 20:36:29.736 UTC: Vi4 IPCP: PrimaryWINS 0.0.0.0 (0x820600000000)
Jan 6 20:36:29.736 UTC: Vi4 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000)
Jan 6 20:36:29.736 UTC: Vi4 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000)
Example 2-83 Client Acknowledges the Home Gateways IP Address
Jan 6 20:36:29.736 UTC: Vi4 IPCP: I CONFACK [REQsent] id 1 len 10
Jan 6 20:36:29.740 UTC: Vi4 IPCP: Address 10.10.10.1 (0x03060A0A0A01)
Example 2-84 Client Requests IP and Primary DNS Server Addresses
Jan 6 20:36:29.857 UTC: Vi4 IPCP: I CONFREQ [ACKrcvd] id 6 len 16
Jan 6 20:36:29.857 UTC: Vi4 IPCP: Address 0.0.0.0 (0x030600000000)
Jan 6 20:36:29.857 UTC: Vi4 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000)
Example 2-85 Home Gateway Supplies an IP Address and Primary DNS Server Address to the Client
Jan 6 20:36:29.861 UTC: Vi4 IPCP: O CONFNAK [ACKrcvd] id 6 len 16
Jan 6 20:36:29.861 UTC: Vi4 IPCP: Address 10.10.10.50 (0x03060A0A0A32)
Jan 6 20:36:29.861 UTC: Vi4 IPCP: PrimaryDNS 10.10.10.99 (0x81060A0A0A63)
Example 2-86 Client Confirms Its IP Address and Primary DNS Server Addresses
Jan 6 20:36:29.977 UTC: Vi4 IPCP: I CONFREQ [ACKrcvd] id 7 len 16
Jan 6 20:36:29.981 UTC: Vi4 IPCP: Address 10.10.10.50 (0x03060A0A0A32)
Jan 6 20:36:29.981 UTC: Vi4 IPCP: PrimaryDNS 10.10.10.99 (0x81060A0A0A63)
CH01i.book Page 94 Friday, April 30, 2004 8:58 AM
Troubleshooting L2F 95
The Home Gateway now acknowledges the clients IP address and primary DNS server
addresses with a CONFACK (see Example 2-87).
Finally, in Example 2-88, the IPCP state changes to OPEN (highlighted line 1), a route to the
client is installed in the routing table (highlighted line 2), and the virtual access interface
changes state to up (highlighted line 3).
NCP negotiation has been completed successfully.
Note that in this example, IP is the only network layer protocol congured on the Home
Gateway and the client. If other protocols such as IPX are congured, then their respective
NCPs are also negotiated.
Now that you have seen successful NCP negotiation between the Home Gateway and the client,
it is time to examine what happens when NCP negotiation is not successful.
The debug ppp negotiation command is again used to examine the NCP negotiation sequence.
Examples 2-89 to 2-94 show the output of the debug ppp negotiation command. Note that only
the relevant portion of the output is shown.
The sequence begins in Example 2-89 with the PPP phase changing to UP. This indicates that
NCP negotiation is about to start.
Immediately after NCP negotiation begins, a Compression Control Protocol (CCP) CONFREQ
is received from the client (see Example 2-90). In it, the client requests conguration of MS-PPC.
Example 2-87 Home Gateway Acknowledges the Clients IP Address and Primary DNS Server Address
Jan 6 20:36:29.981 UTC: Vi4 IPCP: O CONFACK [ACKrcvd] id 7 len 16
Jan 6 20:36:29.981 UTC: Vi4 IPCP: Address 10.10.10.50 (0x03060A0A0A32)
Jan 6 20:36:29.981 UTC: Vi4 IPCP: PrimaryDNS 10.10.10.99 (0x81060A0A0A63)
Example 2-88 IPCP State Changes to OPEN, and the Virtual Access Interface Line Protocol State Changes to Up
Jan 6 20:36:29.985 UTC: Vi4 IPCP: State is Open
Jan 6 20:36:29.985 UTC: Vi4 IPCP: Install route to 10.10.10.50
Jan 6 20:36:30.606 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Virtual-Access4, changed state to up
Jan 6 20:36:31.588 UTC: Vi4 LCP: TIMEout: State Open
PERRIS_HGW1#
Example 2-89 NCP Negotiation Is Unsuccessful
PERRIS_HGW1#debug ppp negotiation
PPP protocol negotiation debugging is on
PERRIS_HGW1#
Jan 6 20:44:27.221 UTC: Vi1 PPP: Phase is UP
Example 2-90 CCP CONFREQ Received from the Client
Jan 6 20:44:27.385 UTC: Vi1 CCP: I CONFREQ [Not negotiated] id 4 len 10
Jan 6 20:44:27.385 UTC: Vi1 CCP: MS-PPC supported bits 0x00000001
(0x120600000001)
CH01i.book Page 95 Friday, April 30, 2004 8:58 AM
96 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
The Home Gateway, however, rejects CCP (including MS-PPC), as shown in Example 2-91.
In Example 2-92, the client sends an IPCP CONFREQ to the Home Gateway, requesting an IP
address and the addresses of primary and secondary DNS and WINS servers.
At this point, the Home Gateway sends a PROTREJ to the client rejecting conguration of IPCP
(see Example 2-93).
Once the Home Gateway has rejected the conguration of IPCP, things go downhill very quickly.
In Example 2-94, the remote access client connection is torn down.
In highlighted line 1 in Example 2-94, interface virtual access 1 changes state to down. Then in
highlighted line 2, the PPP phase changes to TERMINATING. This indicates the Home
Gateways intention to tear down the client connection. Finally, in highlighted line 3, the PPP
phase changes to DOWN. The client connection has been torn down. What went wrong?
Example 2-91 Home Gateway Rejects CCP
Jan 6 20:44:27.385 UTC: Vi1 LCP: O PROTREJ [Open] id 1 len 16 protocol CCP
(0x80FD0104000A120600000001)
Example 2-92 Client Sends an IPCP CONFREQ
Jan 6 20:44:27.397 UTC: Vi1 IPCP: I CONFREQ [Not negotiated] id 5 len 40
Jan 6 20:44:27.397 UTC: Vi1 IPCP: CompressType VJ 15 slots CompressSlotID
(0x0206002D0F01)
Jan 6 20:44:27.397 UTC: Vi1 IPCP: Address 0.0.0.0 (0x030600000000)
Jan 6 20:44:27.401 UTC: Vi1 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000)
Jan 6 20:44:27.401 UTC: Vi1 IPCP: PrimaryWINS 0.0.0.0 (0x820600000000)
Jan 6 20:44:27.401 UTC: Vi1 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000)
Jan 6 20:44:27.401 UTC: Vi1 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000)
Example 2-93 Home Gateway Rejects Configuration of IPCP
Jan 6 20:44:27.401 UTC: Vi1 LCP: O PROTREJ [Open] id 2 len 46 protocol IPCP
Jan 6 20:44:27.401 UTC: Vi1 LCP: (0x8021010500280206002D0F0103060000)
Jan 6 20:44:27.405 UTC: Vi1 LCP: (0x00008106000000008206000000008306)
Jan 6 20:44:27.405 UTC: Vi1 LCP: (0x00000000840600000000)
Example 2-94 Client Connection Is Torn Down
Jan 6 20:44:28.222 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Virtual-Access1, changed state to up
Jan 6 20:44:29.208 UTC: Vi1 LCP: TIMEout: State Open
Jan 6 20:44:31.207 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed
state to down
Jan 6 20:44:31.211 UTC: Vi1 PPP: Phase is TERMINATING
Jan 6 20:44:31.211 UTC: Vi1 LCP: State is Closed
Jan 6 20:44:31.211 UTC: Vi1 PPP: Phase is DOWN
Jan 6 20:44:32.209 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Virtual-Access1, changed state to down
PERRIS_HGW1#
CH01i.book Page 96 Friday, April 30, 2004 8:58 AM
Troubleshooting L2F 97
The answer is in Example 2-93. At this point in the NCP negotiation sequence, the Home Gateway
rejected conguration of IPCP. There is only one reason that the Home Gateway would reject
conguration of IPCP: if there is no IP address congured on the virtual template.
The virtual template conguration is then examined using the show running-cong command,
as shown in Example 2-95. Note that only the relevant portion of the output is shown.
As expected, there is no IP address on the virtual template interface.
This is remedied by conguring ip unnumbered on the virtual template, as shown in Example 2-96.
Once ip unnumbered has been congured on the virtual template, the client reconnects, and
NCP negotiation is successful.
Use the show caller user command to verify NCP negotiation on the Home Gateway. Example
2-97 shows the output of the show caller user command when IPCP negotiation has been
successful.
Example 2-95 Configuration of the Virtual Template
PERRIS_HGW1#show running-config
Building configuration...
!
interface Virtual-Template1
no ip address
peer default ip address pool PERRIS_POOL
ppp authentication chap
ppp multilink
!
Example 2-96 Configuration of ip unnumbered on the Virtual Template
PERRIS_HGW1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
PERRIS_HGW1(config)#interface virtual-template1
PERRIS_HGW1(config-if)#ip unnumbered ethernet0/0
PERRIS_HGW1(config-if)#exit
PERRIS_HGW1#
Example 2-97 Output of the show caller user Command
PERRIS_HGW1#show caller user joebloggs@mjlnet.com
User: joebloggs@mjlnet.com, line Vi1, service PPP L2F
Active time 00:01:15, Idle time 00:00:09
Timeouts: Absolute Idle
Limits: - -
Disconnect in: - -
PPP: LCP Open, multilink Closed, CHAP (<- local), IPCP
IP: Local 172.16.2.2, remote 10.10.10.50
VPDN: NAS LODI_NAS1, MID 18, MID open
HGW PERRIS_HGW1, NAS CLID 3, HGW CLID 17, tunnel open
Counts: 46 packets input, 4286 bytes, 0 no buffer
CH01i.book Page 97 Friday, April 30, 2004 8:58 AM
98 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
Highlighted line 1 shows that user joebloggs@mjlnet.com is connected to interface virtual
access 1. Interface virtual access 1 is running the PPP service (over L2F).
Highlighted line 2 shows that LCP, CHAP, and IPCP have been successfully negotiated with
the client. Also note that multilink PPP (MP) has not been negotiated, and so is in a Closed
state. The issue is resolved.
One other thing to note is that clients, including Cisco routers, will not necessarily terminate
the connection just because IPCP has not been negotiated. Check the status of the connection
using the show caller user or show interfaces virtual-access command.
Case Studies
This section contains issues and solutions that may be considered slightly more uncommon than
those contained within the preceding section of the chapter.
Case Study 1: Remote AAA
This case study examines some of the issues that can arise in a conguration that involves remote AAA.
All remote AAA issues are examined with reference to the topology in Figure 2-38. There is
one NAS, LODI_NAS1, and one Home Gateway, PERRIS_HGW1. The remote access client is
dialing in to the LODI_NAS1.
Figure 2-38 Remote AAA Scenario Topology
0 input errors, 0 CRC, 0 frame, 0 overrun
32 packets output, 0 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
PERRIS_HGW1#
Example 2-97 Output of the show caller user Command (Continued)
Remote Access
Client
(TATEBAYASHI@
mjlnet.com)
LODI_NAS1
(172.16.1.1)
PSTN/
ISDN
PERRIS_HGW1
(172.16.2.2)
Service Provider
Backbone/Internet
RADIUS Server
(Tunnel Definitions
Stored Here)
RADIUS Server
(Remote Access Client
Username and Passwords
Stored Here)
CH01i.book Page 98 Friday, April 30, 2004 8:58 AM
Case Studies 99
Issue 1: Miscongured L2F Tunnel Denition on the AAA Server
Storing tunnel denitions and conguration on a AAA server can be a convenient way of
managing your L2F VPDNs. If the tunnel denition is miscongured, however, tunnel setup
will fail.
Tunnel denitions can be congured using either Cisco AV-pairs or standard IETF attributes. In
this scenario, Cisco AV-pairs are used.
When troubleshooting this issue, the rst thing to do is to conrm that the tunnel denition is
being correctly downloaded from the AAA server. To do this, the command debug aaa
authorization can be useful, as demonstrated in Example 2-98.
In highlighted lines 1 and 2, interface serial 0/0:0 is connected to 1111, and interface async 38
changes state to up. The remote access client has connected.
Then in highlighted line 3, user mjlnet.com is created. This is the domain name supplied in the
remote access clients authentication response.
Note that the tunnel denition is stored on the AAA server under the username that corresponds
to the clients domain name.
Authorization for user mjlnet.com now begins (see Example 2-99).
Example 2-98 Incomplete Tunnel Definition Downloaded
LODI_NAS1#debug aaa authorization
AAA Authorization debugging is on
LODI_NAS1#
Jan 28 18:02:57.815 GMT: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected to
1111
Jan 28 18:03:26.263 GMT: As38 AAA/AUTHOR/FSM: (0): LCP succeeds trivially
Jan 28 18:03:26.267 GMT: %LINK-3-UPDOWN: Interface Async38, changed state to up
Jan 28 18:03:26.547 GMT: AAA: parse name=Async38 idb type=10 tty=38
Jan 28 18:03:26.547 GMT: AAA: name=Async38 flags=0x11 type=4 shelf=0 slot=0 adapter=0
port=38 channel=0
Jan 28 18:03:26.551 GMT: AAA: parse name=Serial0/0:0 idb type=13 tty=-1
Jan 28 18:03:26.551 GMT: AAA: name=Serial0/0:0 flags=0x55 type=1 shelf=0 slot=0
adapter=0 port=0 channel=0
Jan 28 18:03:26.551 GMT: AAA/MEMORY: create_user (0x623B38A0) user='mjlnet.com'
ruser='' port='Async38' rem_addr='1111/7777' authen_type=NONE service=LOGIN priv=0
Example 2-99 Authorization for User mjlnet.com Begins
Jan 28 18:03:26.551 GMT: Async38 AAA/AUTHOR/VPDN (4199196954): Port='Async38'
list='default' service=NET
Jan 28 18:03:26.551 GMT: AAA/AUTHOR/VPDN: Async38 (4199196954) user='mjlnet.com'
Jan 28 18:03:26.551 GMT: Async38 AAA/AUTHOR/VPDN (4199196954): send AV service=ppp
Jan 28 18:03:26.551 GMT: Async38 AAA/AUTHOR/VPDN (4199196954): send AV protocol=vpdn
Jan 28 18:03:26.551 GMT: Async38 AAA/AUTHOR/VPDN (4199196954): found list "default"
Jan 28 18:03:26.551 GMT: Async38 AAA/AUTHOR/VPDN (4199196954): Method=radius (radius)
CH01i.book Page 99 Friday, April 30, 2004 8:58 AM
100 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
Highlighted line 1 shows that authorization for the network service (NET) is sought by
LODI_NAS1. Note that the network service includes PPP. Specically, authorization is sought
for the PPP service (highlighted line 2), and the VPDN protocol (highlighted line 3).
Highlighted line 4 shows that the default method list will be used, and highlighted line 5
indicates that authorization will be sought from a RADIUS server.
In Example 2-100, authorization succeeds.
Highlighted line 1 in Example 2-100 shows that authorization has succeeded (PASS_REPL).
A number of attribute-value (AV) pairs are downloaded from the RADIUS server, and these are
shown in highlighted lines 2 to 4.
Everything is looking good, and then in highlighted line 5, interface serial 0/0:0 is disconnected
from 1111. Furthermore, in highlighted line 6, interface async 38 changes state to down. The
remote access client has been disconnected.
More clarity can be obtained using the debug radius command, as demonstrated in Example
2-101.
Example 2-100 Authorization Succeeds
Jan 28 18:03:26.687 GMT: AAA/AUTHOR (4199196954): Post authorization
status = PASS_REPL
Jan 28 18:03:26.691 GMT: AAA/AUTHOR/VPDN: Processing AV gw-password=cisco
Jan 28 18:03:26.691 GMT: AAA/AUTHOR/VPDN: Processing AV nas-password=cisco
Jan 28 18:03:26.691 GMT: AAA/AUTHOR/VPDN: Processing AV tunnel-id=LODI_NAS1
Jan 28 18:03:26.691 GMT: AAA/MEMORY: free_user (0x623B38A0) user='mjlnet.com' ruser=''
port='Async38' rem_addr='1111/7777' authen_type=NONE service=LOGIN priv=0
Jan 28 18:03:26.931 GMT: %ISDN-6-DISCONNECT: Interface Serial0/0:0 disconnected from
1111 , call lasted 29 seconds
Jan 28 18:03:28.763 GMT: %LINK-5-CHANGED: Interface Async38, changed state to reset
Jan 28 18:03:35.183 GMT: %LINK-3-UPDOWN: Interface Async38, changed state to down
LODI_NAS1#
Example 2-101 Output of debug radius
LODI_NAS1#debug radius
Radius protocol debugging is on
LODI_NAS1#
Jan 28 18:04:14.627 GMT: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected to
1111
Jan 28 18:04:45.055 GMT: %LINK-3-UPDOWN: Interface Async33, changed state to up
Jan 28 18:04:45.343 GMT: RADIUS: authenticating to get author data
Jan 28 18:04:45.343 GMT: RADIUS: ustruct sharecount=2
Jan 28 18:04:45.343 GMT: RADIUS: Initial Transmit Async33 id 22 172.16.5.1:1645,
Access-Request, len 85
Jan 28 18:04:45.343 GMT: Attribute 4 6 AC100101
Jan 28 18:04:45.347 GMT: Attribute 5 6 00000021
Jan 28 18:04:45.347 GMT: Attribute 61 6 00000000
Jan 28 18:04:45.347 GMT: Attribute 1 11 63697363
Jan 28 18:04:45.347 GMT: Attribute 30 6 37373737
CH01i.book Page 100 Friday, April 30, 2004 8:58 AM
Case Studies 101
In highlighted line 1, interface serial 0/0:0 is connected to 1111, and in highlighted line 2,
interface async 33 changes state to up. The remote access client is connected to the NAS.
Then in highlighted line 3, an Access-Request message is sent to the RADIUS server. A number
of attributes are included in this Access-Request, which are listed directly below highlighted
line 3.
In highlighted line 4, the RADIUS server responds with an Access-Accept message, indicating
that authentication has been successful. Again, a number of attributes are included in the
Access-Accept message, which are shown in highlighted lines 5 to 7.
The downloaded attributes make up the tunnel denition.
Shortly thereafter, in highlighted lines 8 and 9, interface serial 0/0:0 is disconnected from 1111,
and interface async 33 changes state to down. The client has been disconnected.
The NAS downloads a tunnel denition from the RADIUS server and then almost immediately
disconnects the client. This might indicate a problem with the tunnel denition itself. The
tunnel denition is then examined on the RADIUS server. In this case a Cisco Secure Access
Control Server (Cisco Secure ACS).
Figure 2-39 shows the tunnel denition on the RADIUS server.
If you look closely at the tunnel denition, you can see that one crucial attribute is missing
the IP address of the Home Gateway.
Jan 28 18:04:45.347 GMT: Attribute 31 6 31313131
Jan 28 18:04:45.347 GMT: Attribute 2 18 C73FDAE1
Jan 28 18:04:45.347 GMT: Attribute 6 6 00000005
Jan 28 18:04:45.363 GMT: RADIUS: Received from id 22 172.16.5.1:1645, Access-Accept,
len 119
Jan 28 18:04:45.363 GMT: Attribute 26 30 0000000901187670
Jan 28 18:04:45.363 GMT: Attribute 26 31 0000000901197670
Jan 28 18:04:45.363 GMT: Attribute 26 32 00000009011A7670
Jan 28 18:04:45.363 GMT: Attribute 6 6 00000005
Jan 28 18:04:45.363 GMT: RADIUS: saved authorization data for user 623B3924
at 623B3B5C
Jan 28 18:04:45.367 GMT: RADIUS: cisco AVPair "vpdn:gw-password=cisco"
Jan 28 18:04:45.367 GMT: RADIUS: cisco AVPair "vpdn:nas-password=cisco"
Jan 28 18:04:45.367 GMT: RADIUS: cisco AVPair "vpdn:tunnel-id=LODI_NAS1"
Jan 28 18:04:45.367 GMT: RADIUS: authenticating to get author data
Jan 28 18:04:45.371 GMT: RADIUS: ustruct sharecount=2
Jan 28 18:04:45.599 GMT: %ISDN-6-DISCONNECT: Interface Serial0/0:0 disconnected from
1111 , call lasted 30 seconds
Jan 28 18:04:47.439 GMT: %LINK-5-CHANGED: Interface Async33, changed state to reset
Jan 28 18:04:54.191 GMT: %LINK-3-UPDOWN: Interface Async33, changed state to down
LODI_NAS1#
Example 2-101 Output of debug radius (Continued)
CH01i.book Page 101 Friday, April 30, 2004 8:58 AM
102 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
Figure 2-39 Tunnel Definition on the RADIUS Server
The IP address of the Home Gateway is dened using the Cisco AV pair (009/001) vpdn:ip-
addresses=ip_address. This attribute is then added to the tunnel denition on the RADIUS server.
Note that the tunnel denition in Figure 2-39 does not include the Cisco AV pair vpdn:tunnel-
type=tunnel_protocol. This is OK because the default tunnel protocol on Cisco routers is L2F.
Figure 2-40 shows the reconguration of the tunnel denition.
Once the tunnel denition has been recongured, the client reconnects, and tunnel
establishment succeeds.
Successful tunnel establishment is veried using the show vpdn tunnel all command, as
demonstrated in Example 2-102.
CH01i.book Page 102 Friday, April 30, 2004 8:58 AM
Case Studies 103
Figure 2-40 Reconfiguration of Tunnel Definition
Example 2-102 Tunnel Establishment Now Succeeds
LODI_NAS1#show vpdn tunnel all
% No active L2TP tunnels
L2F Tunnel Information Total tunnels 1 sessions 1
NAS name: LODI_NAS1
NAS CLID: 8
NAS IP address 172.16.1.1
Gateway name: PERRIS_HGW1
Gateway CLID: 5
Gateway IP address 172.16.2.2
State: open
Packets out: 286
Bytes out: 7850
Packets in: 283
Bytes in: 7196
LODI_NAS1#
CH01i.book Page 103 Friday, April 30, 2004 8:58 AM
104 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
Highlighted line 1 shows that one tunnel and one session have been established. Highlighted
lines 2 through 4 show the Home Gateways name (PERRIS_HGW1), CLID (5), and IP address
(172.16.2.2).
The client session is then examined using the show vpdn session command. Example 2-103
shows the output of the show vpdn session command.
In highlighted line 1, you can see that a session has been established for client
joebloggs@mjlnet.com. The issue is resolved.
When troubleshooting the tunnel denition, there are a number of other issues for which to look
out. Ensure that the user (domain) associated with the tunnel denition on the RADIUS server
is congured with the password cisco. This password is hard-coded for tunnel denitions on
Cisco routers. Also, make sure that the Service-Type (attribute 6) is congured as outbound or
dialout framed. These attributes can be found under Group setup on the Cisco Secure ACS.
Lastly, make sure that No IP Assignment (attribute 8) is congured within the User or Group
setup if you are conguring a Cisco Secure ACS.
Note that if you see the message No response from server in the output of the debug radius
command, this indicates that the server is unreachable. You should, therefore, troubleshoot
connectivity issues.
NOTE For more information on IETF tunnel attributes, see RFC 2868. Additionally, see the following URL:
http://www.cisco.com/en/US/products/sw/iosswrel/ps1830/
products_feature_guide09186a00800879eb.html
For more information on RADIUS attributes in general, see the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/secur_c/scprt6/
scdradat.htm
Note that you can get a quick explanation of the output of the debug radius command by
pasting the output into the Output Interpreter on the Cisco Web site (https://www.cisco.com/
cgi-bin/Support/OutputInterpreter/home.pl). Login is required for the Output Interpreter.
From Cisco IOS Software Release 12.2(4)T, attributes are decoded in the output of the debug
radius command.
Example 2-103 Client Session Information
LODI_NAS1#show vpdn session
% No active L2TP tunnels
L2F Session Information Total tunnels 1 sessions 1
CLID MID Username Intf State
6 5 joebloggs@mjlnet.com As36 open
LODI_NAS1#
CH01i.book Page 104 Friday, April 30, 2004 8:58 AM
Case Studies 105
Before nishing this case study, it worth also taking a look at an L2F tunnel denition (using
Cisco AV pairs) in Merit format.
A correctly congured L2F tunnel denition for a Merit RADIUS server is shown in Example 2-104.
The tunnel denition is pretty self-explanatory. In line 1, the domain name is specied
(mjlnet.com); this is the domain name supplied by remote access clients connecting to the
NAS. You can also see the hard-coded password for Cisco routers specied here (cisco). In line
2, the service type (Outbound-User) is shown.
The remainder of the tunnel denition consists of the tunnel ID (LODI_NAS1), the IP address
of the Home Gateway (172.16.2.2), and the tunnel secrets (both cisco, in this example).
Issue 2: Remote AAA (RADIUS) Authentication Fails for the Remote Access Client
A more scalable solution for supporting a large number of remote access clients is to store their
usernames and passwords on a AAA server.
If you need to troubleshoot client authentication in this scenario, the rst command to use is
debug aaa authentication.
Example 2-105 shows the output of the debug aaa authentication command.
Example 2-104 Merit RADIUS L2F Tunnel Definition
mjlnet.com Password = "cisco"
Service-Type = Outbound-User,
cisco-avpair = "vpdn:tunnel-id=LODI_NAS1",
cisco-avpair = "vpdn:ip-addresses=172.16.2.2",
cisco-avpair = "vpdn:nas-password=cisco",
cisco-avpair = "vpdn:gw-password=cisco"
Example 2-105 Output of debug aaa authentication
PERRIS_HGW1#debug aaa authentication
AAA Authentication debugging is on
PERRIS_HGW1#
*Mar 1 01:16:45.995 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to
up
*Mar 1 01:16:45.999 UTC: AAA: parse name=Virtual-Access1 idb type=21 tty=-1
*Mar 1 01:16:45.999 UTC: AAA: name=Virtual-Access1 flags=0x11 type=5 shelf=0 slot=0
adapter=0 port=1 channel=0
*Mar 1 01:16:45.999 UTC: AAA/MEMORY: create_user (0x6249B848)
user='joebloggs@mjlnet.com' ruser='' port='Virtual-Access1' rem_addr='172.16.1.1'
authen_type=CHAP service=PPP priv=1
*Mar 1 01:16:45.999 UTC: AAA: parse name=Virtual-Access1 idb type=21 tty=-1
*Mar 1 01:16:45.999 UTC: AAA: name=Virtual-Access1 flags=0x11 type=5 shelf=0 slot=0
adapter=0 port=1 channel=0
*Mar 1 01:16:45.999 UTC: AAA/MEMORY: create_user (0x6249B958)
user='joebloggs@mjlnet.com' ruser='' port='Virtual-Access1' rem_addr='1111/7777'
authen_type=CHAP service=PPP priv=1
CH01i.book Page 105 Friday, April 30, 2004 8:58 AM
106 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
In highlighted line 1, interface virtual-access 1 changes state to up. The client has connected to
the Home Gateway over the L2F tunnel. Then in highlighted line 2, user
joebloggs@mjlnet.com is created.
Authentication is about to begin (see Example 2-106).
In highlighted line 1, login authentication for service PPP begins. Highlighted lines 2 and 3
show that the rst method of authentication in the default method list is local authentication.
In highlighted line 4, local authentication results in an error. Authentication using RADIUS (the
second method in the default method list) begins in highlighted line 5. Highlighted line 6 shows
that authentication using RADIUS has failed.
Interface virtual-access 1 now changes state to down (highlighted line 7), and the client is
disconnected.
A bit more insight can be gained using the debug radius command. Example 2-107 shows the
output of the debug radius command.
Example 2-106 Authentication Begins
*Mar 1 01:16:45.999 UTC: AAA/AUTHEN/START (3951084872): port='Virtual-Access1'
list='' action=LOGIN service=PPP
*Mar 1 01:16:45.999 UTC: AAA/AUTHEN/START (3951084872): using "default" list
*Mar 1 01:16:45.999 UTC: AAA/AUTHEN/START (3951084872): Method=LOCAL
*Mar 1 01:16:45.999 UTC: AAA/AUTHEN (3951084872): status = ERROR
*Mar 1 01:16:45.999 UTC: AAA/AUTHEN/START (3951084872): Method=radius (radius)
*Mar 1 01:16:46.007 UTC: AAA/AUTHEN (3951084872): status = FAIL
*Mar 1 01:16:46.007 UTC: AAA/MEMORY: free_user (0x6249B958)
user='joebloggs@mjlnet.com' ruser='' port='Virtual-Access1' rem_addr='1111/7777'
authen_type=CHAP service=PPP priv=1
*Mar 1 01:16:49.659 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to
down
*Mar 1 01:16:49.659 UTC: AAA/MEMORY: free_user (0x6249B848)
user='joebloggs@mjlnet.com' ruser='' port='Virtual-Access1' rem_addr='172.16.1.1'
authen_type=CHAP service=PPP priv=1
PERRIS_HGW1#
Example 2-107 Output of debug radius
PERRIS_HGW1#debug radius
Radius protocol debugging is on
PERRIS_HGW1#
*Mar 1 01:18:43.455 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to
up
*Mar 1 01:18:43.459 UTC: RADIUS: ustruct sharecount=1
*Mar 1 01:18:43.459 UTC: RADIUS: Initial Transmit Virtual-Access1 id 10
172.16.5.1:1645, Access-Request, len 102
*Mar 1 01:18:43.459 UTC: Attribute 4 6 AC100202
*Mar 1 01:18:43.459 UTC: Attribute 5 6 00000001
CH01i.book Page 106 Friday, April 30, 2004 8:58 AM
Case Studies 107
In highlighted line 1, interface virtual-access 1 changes state to up, and the client is connected
to the Home Gateway. In highlighted line 2, the Home Gateway sends an Access-Request
message to the RADIUS server to authenticate the client.
Then in highlighted line 3, the RADIUS server sends the Home Gateway an Access-Reject
message. Authentication has failed, and in highlighted line 4, interface virtual-access 1 changes
state to down. The client is disconnected.
The fact that authentication has failed indicates that the clients username or password may be
miscongured on either the client workstation or the RADIUS server. The client conrms that
his username and password are correctly congured. This leaves only the RADIUS server. The
username on the RADIUS server is correctly congured. This means that the password must be
incorrectly congured. The password is then recongured.
Figure 2-41 shows the reconguration of the client password in the user setup (or at least the
User Setup conguration boxtake my word that the password has been recongured).
*Mar 1 01:18:43.459 UTC: Attribute 61 6 00000005
*Mar 1 01:18:43.459 UTC: Attribute 1 21 6A6F6562
*Mar 1 01:18:43.459 UTC: Attribute 30 6 37373737
*Mar 1 01:18:43.459 UTC: Attribute 31 6 31313131
*Mar 1 01:18:43.459 UTC: Attribute 3 19 02EB11EF
*Mar 1 01:18:43.459 UTC: Attribute 6 6 00000002
*Mar 1 01:18:43.459 UTC: Attribute 7 6 00000001
*Mar 1 01:18:43.463 UTC: RADIUS: Received from id 10 172.16.5.1:1645, Access-Reject,
len 32
*Mar 1 01:18:43.467 UTC: Attribute 18 12 52656A65
*Mar 1 01:18:47.691 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to
down
PERRIS_HGW1#
Example 2-107 Output of debug radius (Continued)
CH01i.book Page 107 Friday, April 30, 2004 8:58 AM
108 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
Figure 2-41 Reconfiguration of the User Password
As soon as the password has been recongured, the client reconnects, and this time,
authentication is successful. This is veried using the show user caller command, as
demonstrated in Example 2-108.
Example 2-108 Output of the show caller user Command
PERRIS_HGW1#show caller user joebloggs@mjlnet.com
User: joebloggs@mjlnet.com, line Vi1, service PPP L2F
Active time 00:00:59, Idle time 00:00:04
Timeouts: Absolute Idle
Limits: - -
Disconnect in: - -
PPP: LCP Open, multilink Closed, CHAP (<- AAA), IPCP
IP: Local 172.16.2.2, remote 10.10.10.50
VPDN: NAS LODI_NAS1, MID 9, MID open
CH01i.book Page 108 Friday, April 30, 2004 8:58 AM
Case Studies 109
Highlighted line 1 shows that the user is connected to interface virtual-access 1.
In highlighted lines 2 through 4, you can see that LCP, CHAP, and IPCP have been successfully
negotiated with the remote access client. Multilink PPP was not negotiated with the client and
remains in a Closed state. The issue is resolved.
Note that if you see the message No response from server in the output of the debug radius
command, this indicates that the server is unreachable. In this case, you should troubleshoot
connectivity issues.
NOTE For more information on RADIUS attributes, see the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/secur_c/scprt6/
scdradat.htm
Note that you can get a quick explanation of the output of the debug radius command by
pasting the output into the Output Interpreter on the Cisco Web site (https://www.cisco.com/
cgi-bin/Support/OutputInterpreter/home.pl).
Note that login is required for the Output Interpreter.
Also, from Cisco IOS Software Release 12.2(4)T, attributes are decoded in the output of the
debug radius command.
Issue 3: Remote AAA (RADIUS) Authorization Fails for the Remote Access Client
When using remote AAA on the Home Gateway, it is important to remember that the RADIUS
server must not only authenticate the client but also authorize services used by the client. If
authorization is not correctly congured, the client connection may fail.
Use the debug aaa authorization command to debug this issue. Note that Example 2-109
shows only the relevant portion of debug output.
HGW PERRIS_HGW1, NAS CLID 8, HGW CLID 8, tunnel open
Counts: 57 packets input, 5626 bytes, 0 no buffer
0 input errors, 0 CRC, 0 frame, 0 overrun
27 packets output, 0 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
PERRIS_HGW1#
Example 2-108 Output of the show caller user Command (Continued)
CH01i.book Page 109 Friday, April 30, 2004 8:58 AM
110 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
In highlighted line 1, interface virtual-access 1 changes state to up. The remote access client has
connected to the Home Gateway.
Then in highlighted line 2, user joebloggs@mjlnet.com is created.
Authorization now begins (see Example 2-110).
Highlighted line 1 shows that the Home Gateway is seeking authorization for the Network
(NET) service. Note that the Network service includes PPP. Specically, the Home Gateway is
seeking authorization for service PPP and protocol VPDN (see highlighted lines 2 and 3).
Highlighted lines 4 and 5 show that the Home Gateway has selected RADIUS for authorization
from the default method list. Then in highlighted line 6, authorization fails. Finally, in
highlighted line 7, interface virtual-access 1 changes state to down. The debug radius
command is then used to gain further insight.
Example 2-109 Authorization Fails for the Remote Access Client
PERRIS_HGW1#debug aaa authorization
AAA Authorization debugging is on
PERRIS_HGW1#
*Mar 1 01:32:52.719 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to
up
*Mar 1 01:32:52.723 UTC: Vi1 AAA/AUTHOR/FSM: (0): LCP succeeds trivially
*Mar 1 01:32:52.723 UTC: AAA: parse name=Virtual-Access1 idb type=21 tty=-1
*Mar 1 01:32:52.723 UTC: AAA: name=Virtual-Access1 flags=0x11 type=5 shelf=0 slot=0
adapter=0 port=1 channel=0
*Mar 1 01:32:52.723 UTC: AAA/MEMORY: create_user (0x624C2688)
user='joebloggs@mjlnet.com' ruser='' port='Virtual-Access1' rem_addr='1111/7777'
authen_type=CHAP service=PPP priv=1
*Mar 1 01:32:52.743 UTC: Vi1 AAA/AUTHOR/LCP: Authorize LCP
Example 2-110 Authorization Begins
*Mar 1 01:32:52.743 UTC: Vi1 AAA/AUTHOR/LCP (2875175667): Port='Virtual-Access1'
list='' service=NET
*Mar 1 01:32:52.743 UTC: AAA/AUTHOR/LCP: Vi1 (2875175667) user='joebloggs@mjlnet.com'
*Mar 1 01:32:52.743 UTC: Vi1 AAA/AUTHOR/LCP (2875175667): send AV service=ppp
*Mar 1 01:32:52.743 UTC: Vi1 AAA/AUTHOR/LCP (2875175667): send AV protocol=lcp
*Mar 1 01:32:52.743 UTC: Vi1 AAA/AUTHOR/LCP (2875175667): found list "default"
*Mar 1 01:32:52.743 UTC: Vi1 AAA/AUTHOR/LCP (2875175667): Method=radius (radius)
*Mar 1 01:32:52.743 UTC: Vi1 AAA/AUTHOR (2875175667): Post authorization
status = FAIL
*Mar 1 01:32:52.743 UTC: Vi1 AAA/AUTHOR/LCP: Denied
*Mar 1 01:32:52.743 UTC: AAA/MEMORY: free_user (0x624C2688)
user='joebloggs@mjlnet.com' ruser='' port='Virtual-Access1' rem_addr='1111/7777'
authen_type=CHAP service=PPP priv=1
*Mar 1 01:32:57.027 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to
down
PERRIS_HGW1#
CH01i.book Page 110 Friday, April 30, 2004 8:58 AM
Case Studies 111
Example 2-111 shows the output of the debug radius command.
Interface virtual-access 1 changes state to up in highlighted line 1. The client is now connected
to the Home Gateway. Highlighted line 2 shows that the Home Gateway has sent an Access-
Request to the RADIUS server. Then in highlighted line 3, the Home Gateway receives an
Accept-Accept from the RADIUS server. Highlighted line 4 indicates that the Home Gateway
has not received appropriate authorization for the client. Finally, interface virtual-access 1
changes state to down, and the client is disconnected. Authorization occurs but not the right
type.
The next step is to examine the clients user amd group setup on the RADIUS server.
Figure 2-42 shows the clients group setup on the RADIUS server.
Example 2-111 Authorization Sequence with the debug radius Command
PERRIS_HGW1#debug radius
Radius protocol debugging is on
PERRIS_HGW1#
*Mar 1 01:34:26.355 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to
up
*Mar 1 01:34:26.359 UTC: RADIUS: ustruct sharecount=1
*Mar 1 01:34:26.359 UTC: RADIUS: Initial Transmit Virtual-Access1 id 16
172.16.5.1:1645, Access-Request, len 102
*Mar 1 01:34:26.359 UTC: Attribute 4 6 AC100202
*Mar 1 01:34:26.359 UTC: Attribute 5 6 00000001
*Mar 1 01:34:26.359 UTC: Attribute 61 6 00000005
*Mar 1 01:34:26.359 UTC: Attribute 1 21 6A6F6562
*Mar 1 01:34:26.359 UTC: Attribute 30 6 37373737
*Mar 1 01:34:26.359 UTC: Attribute 31 6 31313131
*Mar 1 01:34:26.359 UTC: Attribute 3 19 038C5703
*Mar 1 01:34:26.359 UTC: Attribute 6 6 00000002
*Mar 1 01:34:26.359 UTC: Attribute 7 6 00000001
*Mar 1 01:34:26.379 UTC: RADIUS: Received from id 16 172.16.5.1:1645, Access-Accept,
len 38
*Mar 1 01:34:26.379 UTC: Attribute 6 6 00000001
*Mar 1 01:34:26.379 UTC: Attribute 7 6 00000001
*Mar 1 01:34:26.379 UTC: Attribute 8 6 FFFFFFFF
*Mar 1 01:34:26.379 UTC: RADIUS: no appropriate authorization type for user.
*Mar 1 01:34:30.067 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to
down
PERRIS_HGW1#
CH01i.book Page 111 Friday, April 30, 2004 8:58 AM
112 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
Figure 2-42 Clients User Setup
As you can see, in the IETF RADIUS Attributes conguration, the Service-Type (attribute 6) is
congured as Login, and the Framed-Protocol (attribute 7) is congured as PPP.
The Framed-Protocol is correctly congured, but the Service-Type is miscongured. Instead of
Login, the Service-Type should be congured as Framed.
The Service-Type is then recongured as Framed, as shown in Figure 2-43.
Once the Service-Type has been recongured, the client reconnects, and authorization
succeeds. This is veried using the show caller user command.
Example 2-112 shows the output of the show caller user command.
CH01i.book Page 112 Friday, April 30, 2004 8:58 AM
Case Studies 113
Figure 2-43 Reconfiguration of the Service-Type
Example 2-112 Output of the show caller user Command
PERRIS_HGW1#show caller user joebloggs@mjlnet.com
User: joebloggs@mjlnet.com, line Vi1, service PPP L2F
Active time 00:01:14, Idle time 00:00:08
Timeouts: Absolute Idle
Limits: - -
Disconnect in: - -
PPP: LCP Open, multilink Closed, CHAP (<- AAA), IPCP
IP: Local 172.16.2.2, remote 10.10.10.50
VPDN: NAS LODI_NAS1, MID 15, MID open
HGW PERRIS_HGW1, NAS CLID 14, HGW CLID 14, tunnel open
Counts: 46 packets input, 4286 bytes, 0 no buffer
0 input errors, 0 CRC, 0 frame, 0 overrun
CH01i.book Page 113 Friday, April 30, 2004 8:58 AM
114 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
Highlighted line 1 shows that user joebloggs@mjlnet.com is connected to the Home Gateway
over an L2F tunnel.
In highlighted line 2, you can see that LCP, authentication, and IPCP have been successfully
negotiated with the client. Multilink PPP (MP) has not been negotiated with the client and so
remains in a Closed state. The issue is now resolved.
Note that if you see the message No response from server in the output of the debug radius
command, the server is unreachable. If this is the case, you should troubleshoot connectivity
issues between the Home Gateway and the RADIUS server.
NOTE For more information on RADIUS attributes, see the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/secur_c/scprt6/
scdradat.htm
You can also get an explanation of the output of the debug radius command by pasting the
output into the Output Interpreter on the Cisco Web site (https://www.cisco.com/cgi-bin/
Support/OutputInterpreter/home.pl).
A CCO account is required for the Output Interpreter.
From Cisco IOS Software Release 12.2(4)T, attributes are decoded in the output of the debug
radius command.
Case Study 2: Cannot Complete an L2F Tunnel from an Ofoad Server
to the Home Gateway
When conguring an L2F tunnel from an ofoad server in a Multichassis Multilink PPP (MMP)
environment, the tunnel from the ofoad server (NAS) to the Home Gateway will fail unless
multihop VPDN is used.
It is important to remember that when using a Stack Group Bidding Protocol (SGBP) group in
a MMP environment, Multilink PPP (MP) and possibly regular PPP connections (if you are
using the command sgbp ppp-forward), are tunneled to the bid winner or ofoad server using
L2F tunnels (or L2TP in more recent versions of Cisco IOS software).
Note that the tunnel protocol used can be changed using the sgbp protocol {any | l2f | l2tp}
command. If you want to tunnel the PPP trafc arriving in these MMP L2F tunnels from the
ofoad server to a Home Gateway, you are in effect connecting inbound tunnels from SGBP
31 packets output, 0 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
PERRIS_HGW1#
Example 2-112 Output of the show caller user Command (Continued)
CH01i.book Page 114 Friday, April 30, 2004 8:58 AM
Case Studies 115
members to the outbound tunnel to the Home Gateway. This interconnection of tunnels requires
careful conguration.
In the following scenario, two front-end NASsLODI_NAS1 and LODI_NAS2are
congured to forward PPP trafc to an ofoad server, LODI_OFFLOAD. LODI_OFFLOAD is
then congured to tunnel the PPP connections onward to the Home Gateway, PERRIS_HGW1,
as illustrated in Figure 2-44.
Figure 2-44 LODI_OFFLOAD Tunnels MP Links to PERRIS_HGW1
It is apparent, however, that although PPP trafc is being tunneled successfully from
LODI_NAS1 and LODI_NAS2 to the ofoad server, LODI_OFFLOAD, the L2F tunnel from
there to the PERRIS_HGW1 is not functioning correctly.
The show user command on LODI_OFFLOAD shows that two MP sessions have been
successfully tunneled from the front-end NASs, LODI_NAS1 and LODI_NAS2 (see
Example 2-113).
Example 2-113 MP Links Are Being Tunneled to the Offload Server
LODI_OFFLOAD#show user
Line User Host(s) Idle Location
* 0 con 0 idle 00:00:00
Interface User Mode Idle Peer Address
Vi1 joebloggs@ Virtual PPP (L2F ) -
Vi3 joebloggs@ Virtual PPP (L2F ) -
Vi4 joebloggs@ Virtual PPP (Bundle) 00:00:54 172.16.2.7
LODI_OFFLOAD#
LODI_NAS1
(172.16.1.1)
LODI_NAS2
(172.16.1.3)
Remote Access
Client
(joebloggs@mjlnet.com)
Multilink PPP
(MP) Bundle
ISDN / PSTN
Service Provider
Backbone
L2F
L2F
LODI_OFFLOAD
(172.16.1.4)
L2F
PERRIS_HGW1
(172.16.5.1)
SGBP Group:
LODI_STACK
CH01i.book Page 115 Friday, April 30, 2004 8:58 AM
116 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
As you can see, one MP session for user joebloggs@mjlnet.com is being terminated on
interface virtual-access1, another on interface virtual-access3, and the two are bundled together
on interface virtual-access4. You can also see that both MP connections are tunneled to
LODI_OFFLOAD via L2F tunnels (see highlighted lines 1 and 2). A look at the output of the
show ppp multilink command even shows you from where each MP session is tunneled.
Example 2-114 shows the output of the show ppp multilink on LODI_OFFLOAD.
Highlighted lines 2 and 3 show that the MP connection terminated on interface virtual-access
1 is coming from LODI_NAS1 (172.16.1.1), and the MP session terminating on interface
virtual-access 3 is coming from LODI_NAS2.
In highlighted line 1, there is conrmation that these two MP sessions are bundled together on
interface virtual-access 4.
At this stage all looks good, but the output of the command show vpdn tunnel in Example
2-115 reveals that not all of the expected L2F tunnels are, in fact, in place.
In highlighted line 1 in Example 2-115, you can see that there are a total of two L2F tunnels,
with a total of two active sessions. If you look at highlighted line 2, you can see that one tunnel
Example 2-114 show ppp multilink Reveals the Origin of Each MP Session
LODI_OFFLOAD#show ppp multilink
Virtual-Access4, bundle name is joebloggs@mjlnet.com
Bundle up for 00:01:05
Using relaxed lost fragment detection algorithm.
0 lost fragments, 0 reordered, 0 unassigned
0 discarded, 0 lost received, 1/255 load
0x0 received sequence, 0x0 sent sequence
Member links: 2 (max not set, min not set)
LODI_NAS1:Virtual-Access1 (172.16.1.1), since 00:01:05, no frags rcvd,
unsequenced
LODI_NAS2:Virtual-Access3 (172.16.1.3), since 00:00:14, no frags rcvd,
unsequenced
LODI_OFFLOAD#
Example 2-115 Not All the L2F Tunnels Have Been Established
LODI_OFFLOAD#show vpdn tunnel
%No active L2TP tunnels
L2F Tunnel Information Total tunnels 2 sessions 2
NAS CLID HGW CLID NAS Name HGW Name State
38 5 LODI_STACK LODI_STACK open
172.16.1.3 172.16.1.4
37 21 LODI_STACK LODI_STACK open
172.16.1.1 172.16.1.4
%No active PPTP tunnels
%No active PPPoE tunnels
LODI_OFFLOAD#
CH01i.book Page 116 Friday, April 30, 2004 8:58 AM
Case Studies 117
is from 172.16.1.3 (LODI_NAS2) to 172.16.1.4 (LODI_OFFLOAD), and in highlighted line 3,
one tunnel is from 172.16.1.1 (LODI_NAS1) to 172.16.1.4 (LODI_OFFLOAD).
Notice that the Home Gateway and NAS names for both tunnels is LODI_STACK. This is
because LODI_NAS1, LODI_NAS2, and LODI_OFFLOAD are all congured in SGBP group
LODI_STACK and are authenticated with each other as such.
One problem is evident in the output in Example 2-113, however. The expected tunnel from
LODI_OFFLOAD to the Home Gateway, PERRIS_HGW1, is not present.
To begin with, regular L2F troubleshooting is the way to go. In this case, call reception consists
of the successful tunneling of PPP frames from LODI_NAS1 and LODI_NAS2 to
LODI_OFFLOAD. You know that this is successful from the output of the previous show
commands.
The next step is to troubleshoot the building of the tunnel from LODI_OFFLOAD to
PERRIS_HGW1. For this particular tunnel, LODI_OFFLOAD is functioning as the L2F NAS
device, and PERRIS_HGW1 is the L2F Home Gateway.
Because call reception has been veried already, the next thing to do is check that there is basic
IP connectivity between the NAS (LODI_OFFLOAD) and the Home Gateway
(PERRIS_HGW1) using the ping command, as shown in Example 2-116.
You can see from the output in Example 2-116 that the IP connectivity seems to be OK. Do not
forget, however, that ping only tests whether ICMP Echo Request and Reply messages can be
sent between the two devices.
Having established IP connectivity between the two devices, it is time to verify L2F tunnel
establishment. To do this, you can use debug vpdn l2x-events, as demonstrated in Example
2-117.
Example 2-116 Testing IP Connectivity to the Home Gateway
LODI_OFFLOAD#ping 172.16.5.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.5.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms
LODI_OFFLOAD#
Example 2-117 debug vpdn l2x-events Shows L2F Tunnel Setup
LODI_OFFLOAD#debug vpdn l2x-events
Jan 27 02:05:32.489 UTC: L2X: L2F_CONF received
Jan 27 02:05:32.489 UTC: Tnl 41 L2F: Received L2F-CONF from LODI_STACK
Jan 27 02:05:32.493 UTC: Tnl 41 L2F: Opened UDP socket to 172.16.1.1 using
source 172.16.1.4
Jan 27 02:05:32.493 UTC: Tnl 41 L2F: Tunnel LODI_STACK state change from closed
state opening
Jan 27 02:05:32.493 UTC: Tnl 41 L2F: Sending L2F-CONF to peer
Jan 27 02:05:32.509 UTC: Tnl 41 L2F: L2F_OPEN received
CH01i.book Page 117 Friday, April 30, 2004 8:58 AM
118 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
In highlighted line 1, an L2F_CONF is received from LODI_STACK. At this stage, it is not
clear which member of SGBP group LODI_STACK has sent this L2F_CONF.
Then in highlighted line 2, LODI_OFFLOAD opens a UDP socket to 172.16.1.1
(LODI_NAS1), and in highlighted line 3 sends a L2F_CONF to LODI_NAS1. Therefore, the
L2F_CONF in highlighted line 1 was from LODI_NAS1.
An L2F_OPEN is now received from LODI_NAS1 in highlighted line 4. LODI_OFFLOAD
responds with an L2F_OPEN, and L2F tunnel establishment is complete.
L2F client session establishment now begins, as shown in Example 2-118.
In highlighted line 1, a L2F_OPEN is received from LODI_NAS1. This initiates L2F session
establishment. L2F_OFFLOAD replies with an L2F_OPEN in highlighted line 2. Then in
highlighted lines 3 and 4, the line protocol on virtual access interfaces 3 and 2 changes state
to up.
LODI_OFFLOAD is terminating the MP link from LODI_NAS1 on interface virtual-access 3.
Interface virtual-access 4 is used to bundle the MP links (including the one from LODI_NAS1).
Jan 27 02:05:32.513 UTC: Tnl 41 L2F: OPEN from LODI_STACK received for tunnel in
state opening
Jan 27 02:05:32.513 UTC: Tnl 41 L2F: Tunnel LODI_STACK state change from opening
state open
Jan 27 02:05:32.513 UTC: Tnl 41 L2F: Replying to LODI_STACK with L2F-OPEN
Example 2-118 L2F Session Establishment Begins
Jan 27 02:05:32.525 UTC: Tnl 41 L2F: L2F_OPEN received
Jan 27 02:05:32.529 UTC: Tnl 41 L2F: New OPEN received for Session 27
Jan 27 02:05:32.529 UTC: joebloggs@mjlnet.com Tnl/Cl 41/27 L2F: Session state
change from closed to opening
Jan 27 02:05:32.565 UTC: %LINK-3-UPDOWN: Interface Virtual-Access3, changed
state to up
Jan 27 02:05:32.569 UTC: Vi3 Tnl/Cl 41/27 L2F: Transfer NAS-Rate L2F/0/0 to LCP
Jan 27 02:05:32.573 UTC: Vi3 Tnl/Cl 41/27 L2F: Created VA for Mid, Replying with
OPEN
Jan 27 02:05:32.573 UTC: Vi3 Tnl/Cl 41/27 L2F: Session state change from opening
to open
Jan 27 02:05:32.757 UTC: %LINK-3-UPDOWN: Interface Virtual-Access2, changed
state to up
Jan 27 02:05:33.575 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Virtual-Access3, changed state to up
Jan 27 02:05:33.763 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Virtual-Access2, changed state to up
Example 2-117 debug vpdn l2x-events Shows L2F Tunnel Setup (Continued)
CH01i.book Page 118 Friday, April 30, 2004 8:58 AM
Case Studies 119
Next, L2F tunnel setup from LODI_NAS2 begins (see Example 2-119).
L2F tunnel establishment from LODI_NAS2 (172.16.1.3, highlighted line 2) begins with the
receipt of an L2F_CONF in highlighted line 1. LODI_OFFLOAD responds with an
L2F_CONF in highlighted line 3. LODI_NAS2 and LODI_OFFLOAD then exchange
L2F_OPEN messages in highlighted lines 4 and 5, and the L2F tunnel is set up.
L2F client session setup from LODI_NAS2 now begins (see Example 2-120).
In highlighted lines 1 and 2, LODI_NAS2 and LODI_OFFLOAD exchange L2F_OPEN
messages, and the L2F session is established. Finally, the line protocol on interface virtual-
access 1 changes state to up. This interface terminates the MP link from LODI_NAS2.
L2F tunnel and session setup is operating correctly between both LODI_NAS1 and
LODI_NAS2 and LODI_OFFLOAD. Unfortunately, there is no evidence of L2F tunnel setup
Example 2-119 L2F Tunnel Setup from LODI_NAS2 Begins
Jan 27 02:05:46.060 UTC: L2X: L2F_CONF received
Jan 27 02:05:46.064 UTC: Tnl 42 L2F: Received L2F-CONF from LODI_STACK
Jan 27 02:05:46.068 UTC: Tnl 42 L2F: Opened UDP socket to 172.16.1.3 using
source 172.16.1.4
Jan 27 02:05:46.068 UTC: Tnl 42 L2F: Tunnel LODI_STACK state change from closed
state opening
Jan 27 02:05:46.068 UTC: Tnl 42 L2F: Sending L2F-CONF to peer
Jan 27 02:05:46.084 UTC: Tnl 42 L2F: L2F_OPEN received
Jan 27 02:05:46.084 UTC: Tnl 42 L2F: OPEN from LODI_STACK received for tunnel in
state opening
Jan 27 02:05:46.088 UTC: Tnl 42 L2F: Tunnel LODI_STACK state change from opening
state open
Jan 27 02:05:46.088 UTC: Tnl 42 L2F: Replying to LODI_STACK with L2F-OPEN
Example 2-120 L2F Session Setup from LODI_NAS2 Begins
Jan 27 02:05:46.100 UTC: Tnl 42 L2F: L2F_OPEN received
Jan 27 02:05:46.100 UTC: Tnl 42 L2F: New OPEN received for Session 8
Jan 27 02:05:46.104 UTC: joebloggs@mjlnet.com Tnl/Cl 42/8 L2F: Session state
change from closed to opening
Jan 27 02:05:46.136 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed
state to up
Jan 27 02:05:46.140 UTC: Vi1 Tnl/Cl 42/8 L2F: Transfer NAS-Rate L2F/0/0 to LCP
Jan 27 02:05:46.144 UTC: Vi1 Tnl/Cl 42/8 L2F: Created VA for Mid, Replying with
OPEN
Jan 27 02:05:46.144 UTC: Vi1 Tnl/Cl 42/8 L2F: Session state change from opening
to open
Jan 27 02:05:47.149 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Virtual-Access1, changed state to up
LODI_OFFLOAD#
CH01i.book Page 119 Friday, April 30, 2004 8:58 AM
120 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
from LODI_OFFLOAD to the Home Gateway (PERRIS_HGW1). This points to a possible
conguration error on LODI_OFFLOAD. Example 2-121 shows the relevant portion of
LODI_OFFLOADs conguration.
Example 2-121 shows the VPDN conguration on LODI_OFFLOAD.
At rst glance, this conguration looks good. One crucial command is missing, however. This
command would allow LODI_OFFLOAD to pass packets from the two incoming tunnels from
LODI_NAS1 and LODI_NAS2 to the tunnel that it should establish to PERRIS_HGW1. The
command is vpdn multihop.
The conguration is corrected in Example 2-122.
One further action is required: Both existing tunnels must now be cleared and reinitiated from
LODI_NAS1 and LODI_NAS2 to ensure forwarding over the new tunnel to PERRIS_HGW1.
Use the clear vpdn tunnel command to clear and reinitiate L2F tunnels from LODI_NAS1 and
LODI_NAS2 (see Example 2-123).
L2F tunnel establishment is then veried again using the show vpdn tunnel command.
Example 2-124 shows the output of the show vpdn tunnel command after the L2F tunnel from
LODI_NAS1 and LODI_NAS2 have been re-established.
Example 2-121 LODI_OFFLOADs VPDN Configuration
PERRIS_HGW1#show running-config
Building configuration...
vpdn enable
!
vpdn-group 1
request-dialin
protocol l2f
domain mjlnet.com
initiate-to ip 172.16.5.1
!
Example 2-122 vpdn multihop Is Added to the VPDN Configuration
LODI_OFFLOAD#conf t
Enter configuration commands, one per line. End with CNTL/Z.
LODI_OFFLOAD(config)#vpdn multihop
LODI_OFFLOAD(config)#exit
LODI_OFFLOAD#
Example 2-123 L2F Tunnels from LODI_NAS1 and LODI_NAS2 Are Cleared
LODI_OFFLOAD#clear vpdn tunnel l2f LODI_STACK LODI_STACK
Clearing all MIDs and dropping the tunnel
CH01i.book Page 120 Friday, April 30, 2004 8:58 AM
Case Studies 121
Both of the original tunnels are back, but now there is an additional tunnel from
LODI_OFFLOAD to PERRIS_HGW1 (172.16.5.1).
The nal step is to verify that the MP sessions are being correctly terminated on
PERRIS_HGW1. This is done using the show ppp multilink command, as demonstrated in
Example 2-125.
You can see that there are two MP sessions tunneled from LODI_OFFLOAD (172.16.2.1) and
terminating on interfaces virtual-access 1 and 2 (highlighted lines 2 and 3).
These two sessions are then bundled together on interface virtual-access 3 (highlighted line 1).
The issue is resolved.
Example 2-124 L2F Tunnel from LODI_OFFLOAD Is Now Established to PERRIS_HGW1
LODI_OFFLOAD#show vpdn tunnel
%No active L2TP tunnels
L2F Tunnel Information Total tunnels 3 sessions 4
NAS CLID HGW CLID NAS Name HGW Name State
44 8 LODI_STACK LODI_STACK open
172.16.1.3 172.16.1.4
43 24 LODI_STACK LODI_STACK open
172.16.1.1 172.16.1.4
9 45 LODI_OFFLOAD PERRIS_HGW1 open
172.16.1.4 172.16.5.1
%No active PPTP tunnels
%No active PPPoE tunnels
LODI_OFFLOAD#
Example 2-125 Output of the show ppp multilink Command
PERRIS_HGW1#show ppp multilink
Virtual-Access3, bundle name is joebloggs@mjlnet.com
Bundle up for 00:03:13
Using relaxed lost fragment detection algorithm.
0 lost fragments, 0 reordered, 0 unassigned
0 discarded, 0 lost received, 1/255 load
0x0 received sequence, 0x0 sent sequence
Member links: 2 (max not set, min not set)
LODI_OFFLOAD:Virtual-Access1 (172.16.2.1), since 00:03:13, no frags rcvd,
unsequenced
LODI_OFFLOAD:Virtual-Access2 (172.16.2.1), since 00:03:13, no frags rcvd,
unsequenced
PERRIS_HGW1#
CH01i.book Page 121 Friday, April 30, 2004 8:58 AM
122 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
NOTE For more information about conguring MMP, see the article entitled Multichassis Multilink
PPP (MMP) on the Cisco Web site (www.cisco.com).
For more information on the VPDN multihop feature, see the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/113t/113t_3/
multih2.htm
Additional Commands for Troubleshooting
This section contains some additional commands that may be useful when troubleshooting L2F.
show vpdn history failure
The show vpdn history failure command displays the VPDN history failure table.
Example 2-126 shows the output of the show vpdn history failure command.
Highlighted line 1 shows the default VPDN history failure table size (20 entries). The default
VPDN history failure table size can be modied using the vpdn history failure table-size
command.
In highlighted line 2, the current number of entries in the table is shown (1). The user
corresponding to this table entry is shown in highlighted line 3 (joebloggs@mjlnet.com).
Highlighted lines 4 and 5 show the NASs and Home Gateways names, IP addresses, and
CLIDs. Then in highlighted line 6, the time that the failure occurred is shown, together with the
number of times that the failure has been logged. Finally, in highlighted lines 7 and 8, the failure
type and reason are shown.
Note that the VPDN history failure table can be cleared using the clear vpdn history failure
command.
Example 2-126 Output of the show vpdn history failure Command
LODI_NAS1#show vpdn history failure
Table size: 20
Number of entries in table: 1
User: joebloggs@mjlnet.com, MID = 11
NAS: LODI_NAS1, IP address = 172.16.1.1, CLID = 2
Gateway: PERRIS_HGW1, IP address = 172.16.2.2, CLID = 2
Log time: Jan 8 21:44:36.891, Error repeat count: 1
Failure type: The remote server closed this session
Failure reason: Soft shutdown/session limit
LODI_NAS1#
CH01i.book Page 122 Friday, April 30, 2004 8:58 AM
Additional Commands for Troubleshooting 123
debug vpdn error
The debug vpdn error command displays VPDN error information.
Example 2-127 shows the output of the debug vpdn error command.
The output in Example 2-127 indicates that there has been an authorization error for DNIS
2222. This indicates that the NAS has searched for and found no locally congured VPDN
group congured for DNIS 2222, or that the AAA server is unreachable.
Even if this error is displayed, L2F tunnel setup may still succeed if the NAS is congured to
search for and set up the tunnel based on the domain name. Note that the default VPDN search
order is DNIS, then domain name. If you want to modify the search order so that the NAS
searches for a domain name rst, use the vpdn search-order domain [dnis] command.
debug vpdn event
The debug vpdn event command displays VPDN event information.
Example 2-128 shows the output of the debug vpdn event command.
Example 2-127 Output of the debug vpdn error Command
LODI_NAS1#debug vpdn error
10:16:24: VPDN/dnis:2222: Authorization failed, could not talk to AAA server or
local tunnel problem
LODI_NAS1#
Example 2-128 debug vpdn event Output
LODI_NAS1#debug vpdn event
10:19:33: BR0:1 VPDN: Got DNIS string 7777
10:19:33: BR0:1 VPDN: Looking for tunnel -- dnis:7777 --
10:19:33: VPDN/dnis:7777: Authorization failed, could not talk to AAA server or
local tunnel problem
10:19:33: BR0:1 VPDN: Looking for tunnel -- mjlnet.com --
10:19:33: BR0:1 VPDN/RPMS/1: Got tunnel info for mjlnet.com
10:19:33: BR0:1 VPDN/RPMS/1: NAS LODI_NAS1
10:19:33: BR0:1 VPDN/RPMS/1: l2tp-busy-disconnect yes
10:19:33: BR0:1 VPDN/RPMS/1: IP 172.16.2.2
10:19:33: BR0:1 VPDN/1: curlvl 1 Address 0: 172.16.2.2, priority 1
10:19:33: BR0:1 VPDN/1: Select non-active address 172.16.2.2, priority 1
10:19:33: BR0:1 VPDN: Find HGW process created
10:19:33: BR0:1 VPDN: Forward to address 172.16.2.2
10:19:33: BR0:1 VPDN: Pending
10:19:33: BR0:1 VPDN: Process created
10:19:33: VPDN: Chap authentication succeeded for HGW
10:19:33: BR0:1 VPDN: Forwarding...
10:19:33: BR0:1 VPDN: Bind interface direction=1
10:19:33: BR0:1 VPDN: joebloggs@mjlnet.com is forwarded
LODI_NAS1#
CH01i.book Page 123 Friday, April 30, 2004 8:58 AM
124 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
Example 2-128, highlighted line 1 shows that LODI_NAS1 has found DNIS string 7777. Then
in highlighted line 2, LODI_NAS1 looks for the a tunnel (VPDN group) corresponding to DNIS
string 7777.
In highlighted line 3, the NAS fails to nd a tunnel corresponding to the DNIS string. The
LODI_NAS1 now looks for and nds a tunnel based on the domain name mjlnet.com
(highlighted lines 4 and 5). The IP address of the Home Gateway is shown in highlighted line
6 (172.16.2.2).
LODI_NAS1 authenticates the Home Gateway in highlighted line 7, and in highlighted line 8,
LODI_NAS begins forwarding PPP frames between the client (joebloggs@mjlnet.com) and
the Home Gateway.
debug vpdn l2x-data
The debug vpdn l2x-data command displays L2F data packets. Particular care should be taken
when using this command, as it can produce copious output.
Example 2-129 demonstrates sample output from this command.
The highlighted line shows that L2F tunnel (UDP port 1701) packets are being fast switched to
IP address 172.16.2.2 (the Home Gateway).
debug vpdn l2x-packets
The debug vpdn l2x-packets command displays L2F management packets (L2F_PROTO).
Example 2-130 shows the output of the debug vpdn l2x-packets command.
Example 2-129 Output from the debug vpdn l2x-data Command
LODI_NAS1#debug vpdn l2x-data
L2X data packets debugging is on
LODI_NAS1#
10:28:24: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
10:28:25: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state
to up
10:28:34: BR0:1 Tnl/Cl 30/31 L2F: UDP sent (fastswitch) src 172.16.1.1(1701),
dst 172.16.2.2(1701), length 88
10:28:34: BR0:1 Tnl/Cl 30/31 L2F: UDP sent (fastswitch) src 172.16.1.1(1701),
dst 172.16.2.2(1701), length 52
10:28:34: BR0:1 Tnl/Cl 30/31 L2F: UDP sent (fastswitch) src 172.16.1.1(1701),
dst 172.16.2.2(1701), length 64
10:28:34: BR0:1 Tnl/Cl 30/31 L2F: UDP sent (fastswitch) src 172.16.1.1(1701),
dst 172.16.2.2(1701), length 52
CH01i.book Page 124 Friday, April 30, 2004 8:58 AM
Additional Commands for Troubleshooting 125
The rst two highlighted lines show the header of an L2F control packet.
Highlighted line 1 shows that the ags and Version elds have a value of 0x9001. This indicates
that the Offset and Sequence ags are set and that the Version is 1. The protocol eld has a value
of 1, which indicates that this is a L2F_PROTO (L2F management) packet. Finally, the
Sequence number of the packet is 0.
Highlighted line 2 shows that the MID, CLID, length, and Offset eld value (0, 34, 41, and 0,
respectively). Also shown in highlighted line 2 is the L2F message (option) type, which in this
case is L2F_CONF.
Highlighted lines 3 to 5 show the suboptions contained within the L2F_CONF message. These
are L2F_CONF_NAME, L2F_CONF_CHAL, and L2F_CONF_CLID. See Table 2-2 for more
details on these suboptions.
Example 2-130 Output of the debug vpdn l2x-packets Command
LODI_NAS1#debug vpdn l2x-packets
LODI_NAS1#
10:38:07: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
10:38:07:
L2F: SENDING src 172.16.1.1 dst 172.16.2.2 size 41
90 01 01 00 00 00 00 00 00 29 00 00 01 02 03 4E
41 53 03 10 57 92 CE FB A5 87 29 37 11 28 84 EB
E8 FE 77 EA 04 00 00 00 22
10:38:07: L2F: I flags & version 0x9001 protocol 1 sequence 0
10:38:07: L2F: mid 0 cid 34 length 41 offset 0 L2F_CONF
90 01 01 00 00 00 00 22 00 29 00 00 01 02 03 48
47 57 03 10 03 DE 88 AF AC E4 FB 15 87 60 C5 88
EE C2 2C 1A 04 00 00 00 22
10:38:07: L2X: L2F: L2F_CONF_NAME HGW
10:38:07: L2X: L2F: L2F_CONF_CHAL (16 bytes)
10:38:07: L2X: L2F: L2F_CONF_CLID clid = 34
10:38:07:
L2F: SENDING src 172.16.1.1 dst 172.16.2.2 size 35
D0 01 01 01 00 00 00 22 00 23 00 00 0B 45 72 A9
02 03 10 B1 06 42 EB 5A 73 1B C8 AE FA E1 C3 4E
CA CA 49
10:38:07: L2F: I flags & version 0xD001 protocol 1 sequence 1
10:38:07: L2F: mid 0 cid 34 length 35 offset 0 key 0xB536CC1A L2F_OPEN
D0 01 01 01 00 00 00 22 00 23 00 00 B5 36 CC 1A
02 03 10 A0 65 85 4E F1 12 6F 9A 84 96 63 57 60
D7 45 99
10:38:07: L2X: L2F: L2F_OPEN_RESP length 16
10:38:07:
L2F: SENDING src 172.16.1.1 dst 172.16.2.2 size 199
D0 01 01 00 00 23 00 22 00 C7 00 00 0B 45 72 A9
02 06 02 01 13 64 69 61 6C 69 6E 62 6F 78 40 63
69 73 63 6F 2E 63 6F 6D 02 10 F7
CH01i.book Page 125 Friday, April 30, 2004 8:58 AM
126 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
Highlighted lines 6, 7, and 8 show the packet header and payload for another L2F message,
which in this case is L2F_OPEN.
debug vpdn packet
The debug vpdn packet command displays VPDN packet information.
Example 2-131 shows the output of the debug vpdn packet command.
The highlighted lines in Example 2-131 show L2F packets being fast switched out of and into
the L2F tunnel.
Error Messages
This section introduces some of the more commonly seen error messages and explains their
meanings and their resolutions. These messages can be seen if VPDN logging is enabled.
Example 2-132 shows how to enable VPDN logging.
Note that VPDN logging is enabled by default.
Example 2-131 Output of the debug vpdn packet Command
LODI_NAS1#debug vpdn packet
VPDN packet debugging is on
LODI_NAS1#
10:41:26: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
10:41:27: %LINEPROTO-5-UPDOWN: Line protocol on Interface BRI0:1, changed state
to up
10:41:36: BR0:1 L2F: OUT UDP FS out
10:41:36: BR0:1 VPDN: I FS
10:41:36: BR0:1 L2F: OUT UDP FS out
10:41:36: BR0:1 VPDN: I FS
10:41:36: BR0:1 L2F: OUT UDP FS out
10:41:36: BR0:1 VPDN: I FS
10:41:36: BR0:1 L2F: OUT UDP FS out
10:41:36: BR0:1 VPDN: I FS
10:41:36: BR0:1 L2F: OUT UDP FS out
10:41:36: BR0:1 VPDN: I FS
10:41:36: BR0:1 L2F: OUT UDP FS out
Example 2-132 Enabling VPDN logging
LODI_NAS1#conf t
Enter configuration commands, one per line. End with CNTL/Z.
LODI_NAS1(config)#vpdn logging
LODI_NAS1(config)#exit
LODI_NAS1#
CH01i.book Page 126 Friday, April 30, 2004 8:58 AM
Error Messages 127
%VPDN-6-AUTHENERR Error Message
This error indicates that the NAS or Home Gateway was not able to connect to an AAA server
to authenticate a user or tunnel. This may indicate misconguration of AAA parameters on the
NAS/Home Gateway, a problem with connectivity between the NAS/Home Gateway and the
AAA server, or even that the AAA server is ofine.
To resolve this issue, check the AAA conguration on the NAS/Home Gateway, ensure
connectivity with the AAA server using ping and traceroute, and ensure that the AAA server
is online.
%VPDN-6-AUTHENFAIL Error Message
This error indicates that authentication has failed for a user or tunnel on the NAS or Home
Gateway.
In this case, you should ensure that the remote access clients domain name or DNIS
corresponds to a tunnel conguration/denition on the NAS or AAA server. Additionally, verify
tunnel authentication using the debug vpdn events command.
If tunnel authentication fails, check that tunnel passwords are correctly congured.
%VPDN-6-AUTHORERR Error Message
This error means that authorization has produced an error condition for the user or tunnel in
question. This indicates that the AAA server is not able to be contacted by the NAS/Home
Gateway.
Once again, examine the AAA conguration on the NAS/Home Gateway to ensure that it is
correct. Also ensure that there is connectivity between the AAA server and the NAS/Home
Gateway using ping and traceroute.
%VPDN-6-AUTHORFAIL Error Message
This indicates that authorization for the user or tunnel has failed on the NAS or Home Gateway.
Check the AAA conguration on the NAS/Home Gateway, as well as the conguration of the
AAA server.
%VPDN-6-CLOSED Error Message
This message is generic in nature and indicates simply that an L2F_CLOSE message has been
received on either the NAS or Home Gateway. The L2F_WHY suboption might be listed,
together with the L2F_CLOSE_STR. These two suboptions might indicate the reason for the
close. See Table 2-2 for L2F_CLOSE reason codes.
CH01i.book Page 127 Friday, April 30, 2004 8:58 AM
128 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
It might be useful to examine the output of the debug vpdn l2x-events, debug vpdn l2x-error,
and debug ppp negotiation on the NAS or Home Gateway. Also examine the output of the
show vpdn history failure command.
Possible reasons for tunnel closure include tunnel authentication failure, insufcient resources
on the NAS/Home Gateway, or termination of the connection by the client.
%VPDN-6-MAX_SESS_EXCD Error Message
This message shows that the maximum number of sessions permissible in a tunnel has been
exceeded. This session maximum is congurable using the vpdn session-limit command.
To remedy this error, examine the conguration, and either remove the session limit or adjust it
upward.
%VPDN-4-MIDERROR Error Message
This error is generic, and it indicates that there is a conguration or resource issue on the Home
Gateway. You should check the conguration of the Home Gateway to ensure that it is correct.
%VPDN-5-NOIDB Error Message
The NOIDB error can be seen on the Home Gateway when it has no more Interface Data Blocks
(IDBs) with which to terminate tunnel sessions.
IDBs contain data such as addressing and statistics associated with an interface. One is
allocated to every physical interface, subinterface, and, importantly in this case, virtual
interface associated with an L2F session.
The number of IDBs available depends on the hardware platform. As of Cisco IOS 12.2, for
2500 series access servers, there are 300 IDBs available; for 3620s and 3640s, 800 IDBs; for
AS5300s, 800 IDBs; and for AS5800s, there are 2048 IDBs.
To resolve this issue, you should contact Cisco Technical Assistance Center (TAC).
%VPDN-3-NORESOURCE Error Message
This error indicates that the NAS or the Home Gateway is out of resources needed either to
forward or to terminate a user session or tunnel. Contact Cisco TAC to resolve this issue.
%VPDN-4-REFUSED Error Message
If you see this error, it means that the Home Gateway has refused to terminate a L2F session.
You should examine the Home Gateways conguration to ensure that it is correct.
CH01i.book Page 128 Friday, April 30, 2004 8:58 AM
show and debug Command Summary 129
%VPDN-6-RESIZE Error Message
This indicates that the MID table size has been altered on the NAS or Home Gateway. Examine
your congurations to ensure that they are correct.
%VPDN-6-SOFTSHUT Error Message
This message tells you that the vpdn softshut command has been congured on the NAS or
Home Gateway. This command allows L2F sessions to be gracefully terminated, while not
allowing any new session to be established.
To resolve this, you should examine the conguration of the NAS or Home Gateway and
remove this command (no vpdn softshut).
%VPDN-6-TIMEOUT Error Message
You will see this error message if the user session within the tunnel has timed out. This can be
because of either PPP negotiation failing or the absolute timeout for the session expiring. This
timeout is used to close user sessions if there is no user activity.
%VPDN-5-UNREACH Error Message
This error is seen on the NAS if it fails to establish connectivity to the Home Gateway. This is
seen when either IP or L2F connectivity cannot be established.
Examine the NASs conguration to ensure that the IP address of the Home Gateway is
congured correctly (initiate-to ip).
%VPDN-6-DOWN Error Message
This message is displayed when a tunnel connection has been terminated by the Home
Gateway.
Use the debug vpdn l2x-events and debug vpdn l2x-error commands to examine the
L2F_CLOSE_WHY and L2F_CLOSE_STR elds of the L2F_CLOSE message. The cause
codes contained within the L2F_CLOSE_WHY suboption can be found in Table 2-3. Also
examine the output of the show vpdn history failure command. Resolution of this issue will
depend on the cause of the close.
show and debug Command Summary
Table 2-5 summarizes the show and debug commands used for troubleshooting L2F VPDNs in
this chapter.
CH01i.book Page 129 Friday, April 30, 2004 8:58 AM
130 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
Review Questions
1 Which L2F message type is the rst sent when a NAS is establishing a L2F tunnel to the
Home Gateway?
2 By default, what is the message sequence for PPP authentication between the remote
access client and the NAS? Assume that CHAP authentication is used and that the client
is not congured to authenticate the NAS.
3 What is the sequence for PPP authentication between the client and the Home Gateway?
Assume that the Home Gateway accepts all parameters sent by the NAS during session
setup.
4 By default, how is LCP negotiated between the remote access client and the Home
Gateway?
5 Which parts of the PPP frame are NOT carried when the frame is forwarded by the NAS
to the Home Gateway?
6 How is a tunnel termination reason indicated within the L2F_CLOSE message?
7 What does the error message %VPDN-6-SOFTSHUT: mean? How can this issue be
resolved?
8 What are the MID and the CLID?
9 What is the signicance of MID 0?
10 How is the L2F tunnel maintained in the absence of client trafc?
Table 2-5 show and debug Command Summary for Troubleshooting L2F VPDNs
Command Parameters Description
show vpdn
history failure Displays user failure history table
multilink Displays L2F multilink information
session Displays session information
session all Displays all session information
tunnel Displays tunnel information
tunnel all Displays all tunnel information
debug vpdn
error Displays L2F error conditions
event Displays L2F events
L2x-data Displays L2F data packet information
L2x-errors Displays detailed L2F error conditions
L2x-events Displays detailed L2F events
packets Displays L2F control packet information
CH01i.book Page 130 Friday, April 30, 2004 8:58 AM
Troubleshooting Practice Labs 131
Troubleshooting Practice Labs
The following labs are provided to help you to consolidate and to practice the knowledge and
skills that you have gained in this chapter.
Three labs are provided, and all are based on the network topology shown in Figure 2-45.
Figure 2-45 L2F Troubleshooting Lab Topology
In each lab, you must restore end-to-end IP connectivity from TATEBAYASHI@mjlnet.com to
PERRIS_HGW1. This should be tested by pinging PERRIS_HGW1s loopback interface
(10.20.10.1) from TATEBAYASHI@mjlnet.com.
Base congurations for the labs can be found on the Cisco Press Web site
(www.ciscopress.com/1587051044). Detailed instructions for loading these base
congurations onto your lab routers, as well as solutions can be found in Appendix B.
Troubleshooting Lab 1
In this scenario, user TATEBAYASHI@mjlnet.com reports that he can connect to LODI_NAS1
but that the connection is dropped almost immediately.
Troubleshoot this issue end-to-end, and record the symptoms, actions, and resolution in the
space provided below:
Symptoms:
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
LODI_NAS1
ISDN
PERRIS_HGW1
DELAND_RTR
Lo0:
192.168.1.1/24
TATEBAYASHI@
mjlnet.com
BRI 0/0 BRI 0/0
(Number: 2222)
S 0/0 S 0/0 S 0/1 S 0/0 E 0/0
.1
.2
.1
.1 .2
Serial
Ethernet
Loopback
S -
E -
Lo -
10.10.10.0/24
172.16.2.0/24 172.16.1.0/24
Lo0:
10.10.10.0/24
CH01i.book Page 131 Friday, April 30, 2004 8:58 AM
132 Chapter 2: Troubleshooting Layer Two Forwarding Protocol VPNs
Actions:
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
Resolution:
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
Troubleshooting Lab 2
In this scenario, the L2F tunnel is initiated but fails for an unknown reason.
Troubleshoot this issue end-to-end, and record the symptoms, actions, and resolution in the
space provided below:
Symptoms:
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
Actions:
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
Resolution:
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
CH01i.book Page 132 Friday, April 30, 2004 8:58 AM
Troubleshooting Practice Labs 133
Troubleshooting Lab 3
In this scenario, L2F tunnel establishment succeeds, but it is torn down almost immediately.
Troubleshoot this issue end-to-end, and record the symptoms, actions, and resolution in the
space provided below:
Symptoms:
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
Actions:
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
Resolution:
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
CH01i.book Page 133 Friday, April 30, 2004 8:58 AM
CH01i.book Page 134 Friday, April 30, 2004 8:58 AM
C H A P T E R
3
Troubleshooting Point-to-Point
Tunneling Protocol VPNs
The Point-to-Point Tunneling Protocol (PPTP) is described in RFC 2637 and allows the
tunneling of Point-to-Point Protocol (PPP) frames across an IP backbone from a PPTP
Access Concentrator (PAC) to a PPTP Network Server (PNS). PPTP was the result of work
carried out by a consortium of vendors, the most prominent of which was Microsoft.
RFC 2637 describes how PPTP separates the functionality of the traditional Network
Access Server (NAS). The PAC is responsible for remote access client call termination,
Link Control Protocol (LCP) termination, and possibly PPP authentication. The PNS is
responsible for PPP authentication, Multilink PPP (MP) channel aggregation, and Network
Control Protocol (NCP) negotiation. In this scenario, the remote access client does not
participate in and is not aware of PPTP. Remote access client PPP frames are simply
forwarded (tunneled) from the PAC to the PNS transparently. This division of functionality
is known as compulsory tunnel mode.
Note that the PAC in compulsory tunnel mode is typically located at the service provider
point-of-presence (POP), and the PNS is located at the enterprise network edge.
Figure 3-1 illustrates this mode of operation.
Figure 3-1 PPTP Compulsory Tunnel Mode
Another mode of operation offered by PPTP is known as voluntary tunnel mode. In this
mode, instead of the PPTP tunnel being established between a dial access platform (the
PAC) and a PNS, it is established directly from the remote access client itself to the PAC.
PPP frames are then forwarded over this tunnel between the remote access client and
the PAC.
Remote Access
Client
PAC
PSTN/
ISDN
PNS
Corporate
Network
Service Provider
Backbone
PPTP Tunnel PPP PPP
CH01i.book Page 135 Friday, April 30, 2004 8:58 AM
136 Chapter 3: Troubleshooting Point-to-Point Tunneling Protocol VPNs
In this scenario, the client workstation functions as a PNS. Figure 3-2 illustrates voluntary
tunnel mode operation.
Figure 3-2 PPTP Voluntary Tunnel Mode
Because PPTP functionality is built into most Microsoft client operating systems, voluntary
tunnel mode has become by far the most common mode of operation. Cisco routers support the
voluntary mode of PPTP operation and function as the PAC within this model.
After reading this introduction, if you have the feeling that this all seems rather familiar, you
would be right. PPTP in compulsory mode is designed to perform the same job as the Layer 2
Forwarding Protocol (L2F), although there are one or two differences. It also performs the same
job as the Layer 2 Tunneling Protocol (L2TP), which is discussed in Chapter 4,
Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs.
Some of the main differences between PPTP and L2F are as follows:
PPTP tunnels PPP, whereas L2F can tunnel both PPP and Serial Line Internet Protocol
(SLIP).
In PPTP, the control connection uses Transmission Control Protocol (TCP), and PPP
frames are transported over Enhanced Generic Routing Encapsulation (GRE). In L2F,
both control messages and PPP/SLIP frames are transported (in an IP network) over UDP.
The PPTP includes support for outgoing calls, whereas L2F does not.
L2F operates only in compulsory tunnel mode, whereas PPTP can operate in both
compulsory and voluntary tunnel modes.
In compulsory tunnel mode, the L2F NAS has the capability to negotiate the LCP and to
authenticate the remote access client. This LCP and authentication information is then
passed to the Home Gateway. The PAC (the functional equivalent of the L2F NAS) has no
capability to pass LCP and authentication information to the PNS (the functional
equivalent of the L2F Home Gateway).
PPTP provides ow and congestion control, whereas L2F does not.
The L2F NAS and Home Gateway authenticate each other during tunnel setup, whereas
the PAC and PNS do not. In PPTP, security is provided via the authentication of PPP peers,
which in voluntary tunnel mode are also the PAC and the PNS.
Remote Access
Client/PNS
PAC
Corporate
Network
Internet
PPTP Tunnel PPP PPP
CH01i.book Page 136 Friday, April 30, 2004 8:58 AM
Technical Overview of PPTP 137
When troubleshooting PPTP, it is important to have a rm grasp both of its underlying operation
and basic conguration. The next two sections examine the operation and conguration
of PPTP.
Technical Overview of PPTP
Because Cisco routers do not support compulsory tunnel mode with PPTP, only voluntary
tunnel mode is examined in this chapter.
Voluntary tunnel mode, unlike compulsory tunnel mode, is initiated by the remote access client
itself. In this mode of operation, the remote access client acts as the PNS, with the tunnel being
established directly to the PAC.
PPTP provides for two distinct channels of communication between the remote access client/
PNS and the PAC:
The control connection/channelThe control connection is used to exchange control
messages between the remote access client/PNS and the PAC. These control messages
allow the establishment and termination of client sessions and perform such functions as
keepalive, error reporting, and link parameter conguration.
The (user) data tunnelThe data tunnel allows the forwarding of PPP frames between
the remote access client/PNS and the PAC. In compulsory tunnel mode, it is possible to
multiplex multiple user PPP sessions over the tunnel. In voluntary tunnel mode, however,
only one user session is maintained.
Note that control channel and data tunnel connections between the remote access client/PNS
and PAC are separate and distinct. Control channel transport is provided for via a TCP
connection, whereas data tunnel transport is provided for via Enhanced GRE.
Figure 3-3 illustrates control channel and data tunnel connectivity between the remote access
client/PNS and the PAC.
Figure 3-3 PPTP Control Channel and Data Tunnel Connectivity
The following few sections describe PPTP operation and examine control channel setup,
session establishment, PPP negotiation, tunnel maintenance, and session and control channel
termination.
Remote Access
Client/PNS
PAC
Data Tunnel (E. GRE)
Control Connection (TCP 1723)
PPP PPP
CH01i.book Page 137 Friday, April 30, 2004 8:58 AM
138 Chapter 3: Troubleshooting Point-to-Point Tunneling Protocol VPNs
PPTP Control Channel Setup
The control channel must be established before any user PPP sessions are established over a
tunnel between the PNS and the PAC. The control channel setup is initiated by the remote
access client/PNS over a TCP connection that utilizes destination port 1723. According to RFC
2637, the source port should simply be an unused port.
RFC 2637 discusses two types of message that may be sent over a Control Connection between
the PNS and the PAC:
Control Messages (message type 1)
Management Messages (message type 2)
Management Messages are presently not dened.
Figure 3-4 shows the overall control channel packet format.
Figure 3-4 Control Channel Packet Format
Control Messages are used to establish and maintain the control connection itself, to manage
calls, to report errors, and to control the PPP session.
Table 3-1 summarizes PPTP Control Message types.
Table 3-1 PPTP Control Messages
Message Code Control Message
1 Start-Control-Connection-Request (SCCRQ)
2 Start-Control-Connection-Reply (SCCRP)
3 Stop-Control-Connection-Request (StopCCRQ)
4 Stop-Control-Connection-Reply (StopCCRP)
5 Echo-Request
6 Echo-Reply
7 Outgoing-Call-Request (OCRQ)
IP Header
TCP Header
(port 1723)
Payload
(Control Channel Message)
CH01i.book Page 138 Friday, April 30, 2004 8:58 AM
Technical Overview of PPTP 139
Establishment of the Control Channel itself begins with the transmission of a Start-Control-
Connection-Request (SCCRQ) message from the remote access client/PNS to the PAC.
As the name suggests, the function of the SCCRQ message is to initiate establishment of the
control connection between the PNS and PAC.
Figure 3-5 shows the format of the SCCRQ.
As Figure 3-5 depicts, the SCCRQ message format consists of the following elds:
As the name suggests, the Length eld indicates the length of the PPTP message,
including the PPTP header itself.
The PPTP Message Type eld is set to a value of 1 to indicate that this is a Control
Message.
The Magic Cookie eld holds a constant value irrespective of the control message type.
The value of the Magic Cookie is 0x1A2B3C4D.
The function of the Magic Cookie is to ensure that the receiver of the message
(PNS or PAC) is synchronized with the control connection TCP data stream.
The Control Message Type eld value for the SCCRQ is 1.
The Reserved0 eld is set to a value of 0. This eld is designed to allow future
expansibility of PPTP.
Protocol Version denes the version and revision number of PPTP being requested by the
sender (the remote access client/PNS in this case). This eld is four octets wide, with the
rst two octets describing the version number, and the last two octets the revision number.
The Reserved1 eld is also reserved for future use and should be set to a value of 0.
8 Outgoing-Call-Reply (OCRP)
9 Incoming-Call-Request (ICRQ)
*
10 Incoming-Call-Reply (ICRP)*
11 Incoming-Call-Connected (ICCN)*
12 Call-Clear-Request (CCRQ / ClearRQ)
13 Call-Disconnect-Notify (CDN)
14 WAN-Error-Notify (WEN)
15 Set-Link-Info (SLI)
* The Incoming-Call-Request (ICRQ), Incoming-Call-Reply (ICRP), and Incoming-Call-Connected (ICCN) message
types shown in Table 3-1 are used only in compulsory tunnel mode and are, therefore, (with one brief exception) not
discussed further in this chapter.
Table 3-1 PPTP Control Messages (Continued)
Message Code Control Message
CH01i.book Page 139 Friday, April 30, 2004 8:58 AM
140 Chapter 3: Troubleshooting Point-to-Point Tunneling Protocol VPNs
Figure 3-5 SCCRQ Message Format
NOTE Note that the Length, PPTP Message Type, Magic Cookie, and Reserved0 elds are present in
all PPTP control messages.
Framing Capabilities indicates the type of framing that the sender of the SCCRQ can
support. Although this eld is 32 bits wide, only two bit settings are currently dened. If
bit 1 is set, asynchronous framing is supported, and if bit 2 is set, synchronous framing is
supported.
Bearer Capabilities, the next eld, is similar. Although 32 bits wide, only two bit settings
are dened. Bit setting 1 indicates that analog access is supported, and bit setting 2
indicates that digital access is supported.
The Maximum Channels eld is used by the PAC in compulsory tunnel mode to specify
the number of user (PPP) sessions that can be supported within the tunnel. In voluntary
tunnel mode, the remote access client/PNS sets this eld to a value of 0.
The Firmware Revision eld species the rmware revision number or software
driver version of the remote access client/PNS.
The Host Name eld contains the DNS name of the sender of the SCCRQ.
The Vendor Name eld contains vendor-specic information, such as the type of software
being used by the remote access client/PNS.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
PPTP Message Type (1)
Reserved0 (0)
Reserved1 (0)
Magic Cookie (0x1A2B3C4D)
Framing Capability
Bearer Capability
Host Name (64 octets)
Vendor String (64 octets)
Length
Protocol Version
Control Message Type (1)
Firmware Revision Maximum Channels
0 1 2 3
CH01i.book Page 140 Friday, April 30, 2004 8:58 AM
Technical Overview of PPTP 141
The PAC responds to the SCCRQ message with a Start-Control-Connection-Reply (SCCRP)
message. This message indicates whether the control channel has been successfully established
or whether an error condition has resulted.
Figure 3-6 illustrates the exact format of the SCCRP message.
Figure 3-6 SCCRP Message Format
The SCCRP message format consists of many of the same elds as the SCCRQ message
format. After the Protocol Version eld, the message format begins to look a little different than
that of the SCCRQ (see Figure 3-5). The signicant elds for the SCCRP message format that
differ from the SCCRQ message format are described as follows:
The Control Message Type eld contains a value of 2, which indicates that this message
is a SCCRP.
The Result Code eld is an 8-bit eld that is used to indicate one of ve conditions or
results.
Table 3-2 summarizes the possible result codes, together with their associated
meaning.
Table 3-2 Result Codes
Result Code Meaning
1 Successful channel establishment
2 General error (Error Code species)
3 Command channel already exists
4 Requester is not authorized to establish command channel
5 Protocol version of the requester is not supported
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
PPTP Message Type (1)
Reserved0 (0)
Result Code Error Code
Magic Cookie (0x1A2B3C4D)
Framing Capability
Bearer Capability
Host Name (64 Octets)
Vendor String (64 Octets)
Length
Protocol Version
Control Message Type (2)
Firmware Revision Maximum Channels
0 1 2 3
CH01i.book Page 141 Friday, April 30, 2004 8:58 AM
142 Chapter 3: Troubleshooting Point-to-Point Tunneling Protocol VPNs
Should a General Error be indicated by the Result Code (code 2), the next eld, Error
Code, indicates the specic error that has caused the control connection to fail.
Table 3-3 summarizes the Error Codes, together with their meanings.
Note that if a General Error should not be indicated in the Result Code eld (in
other words, any value other than 2 is contained within the eld), the Error Code
eld should be set to 0.
Figure 3-7 shows the exchange of messages to enable the establishment of the control channel
from the PNS to the PAC.
Figure 3-7 PPTP Control Channel Establishment
PPTP Session Establishment
Once the control channel has been established between the remote access client/PNS and the
PAC, the remote access client/PNS signals that it wishes to establish a client session. This is
done by sending an Outgoing-Call-Request (OCRQ) message over the control channel.
Table 3-3 Error Codes
General Error Code Meaning
0 No general error
1 No control connection exists yet for this remote access client/PNS-PAC pair
2 Length is wrong or Magic Cookie value is incorrect
3 One of the eld values was out of range/reserved eld was non-zero
4 Insufcient resources to handle this command now
5 The Call ID is invalid in this context
6 Vendor specic error (for errors on PAC)
SCCRQ
SCCRQ
Remote Access
Client/PNS
PAC
Internet
CH01i.book Page 142 Friday, April 30, 2004 8:58 AM
Technical Overview of PPTP 143
The OCRQ was originally designed to be sent by the PNS to the PAC in compulsory tunnel
mode. Its purpose was, as the name suggests, to signal the PAC to make an outgoing call to an
end user or client.
In voluntary tunnel mode, the remote access client/PNS sends an OCRQ to the PAC to signal
that the remote access client/PNS wishes to establish a PPP session within the PPTP tunnel.
Figure 3-8 shows the packet format for the OCRQ message.
Figure 3-8 OCRQ Packet Format
As Figure 3-8 depicts, the OCRQ message format consists of the following elds.
(Explanations of elds already described have been omitted unless they differ based on packet
relevance.)
The Control Message Type eld is set to a value of 7 to indicate that this message is
an OCRQ.
Skipping the Reserved0 eld, the next eld is Call ID. This eld is a unique identier for
a particular PPP session within the overall PPTP tunnel. The Call ID is essential in a
compulsory tunnel mode environment to disambiguate the different sessions within the
tunnel. In a voluntary tunnel mode environment, there is only one session but the Call ID
remains.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
PPTP Message Type (1)
Reserved0 (0)
Call Serial Number
Magic Cookie (0x1A2B3C4D)
Minimum BPS
Maximum BPS
Bearer Type
Framing Type
Phone Number (64 octets)
Subaddress (64 octets)
Length
Call ID
Control Message Type (7)
Packet Processing Delay
Reserved1 Phone Number Length
Packet Recv. Window Size
0 1 2 3
CH01i.book Page 143 Friday, April 30, 2004 8:58 AM
144 Chapter 3: Troubleshooting Point-to-Point Tunneling Protocol VPNs
Note that the Call ID is locally unique, meaning that the remote access client/
PNS and the PAC may use different Call IDs to identify the same session.
The Call Serial Number eld has a similar function to that of the Call ID. The purpose of
the Call Serial number is again to identify uniquely the session within the tunnel but only
for session logging purposes. It is worth noting that the Call Serial Number, unlike the
Call ID, is globally unique (that is, the remote access client/PNS and the PAC use the same
number to identify the same session).
The Minimum BPS eld species the minimum line speed (in bits per second) that would
be acceptable to the remote access client/PNS.
The Maximum BPS eld species the maximum line speed (in bits per second) that would
be acceptable to the remote access client/PNS.
The Bearer Type eld is used in compulsory tunnel mode to specify the bearer type that
the outgoing call should be made with. The possible bearer types are: 1 = analog,
2 = digital, and 3 = any.
The Framing Type eld is similar in nature to the Bearer Type eld and indicates the type
of PPP framing that should be used. There are three possible values: 1 = asynchronous,
2 = synchronous, and 3 = any.
The Packet Recv. Window Size eld is used for ow control and species the number of
packets that are buffered for a particular session.
The Packet Processing Delay (PPD) eld is again used for ow control purposes and
species the time required to process the maximum amount of data in the buffer. The time
is specied in tenths of a second.
The nal three elds (excluding Reserved1, which has been previously described) are
Phone Number Length, Phone Number, and Subaddress.
Again, these three elds are relevant only to compulsory tunnel mode. They are
used to specify the telephone number (and subaddress) to call.
In voluntary tunnel mode, all three elds are set to a value of 0 (by the remote
access client/PNS).
The PAC replies to the OCRQ from the remote access client/PNS with an Outgoing-Call-Reply
(OCRP) message. In compulsory tunnel mode, this message is used to signal the result of the
outgoing call. In voluntary tunnel mode, however, it is simply used to signal the success or
otherwise of the session establishment attempt from the remote access client/PNS.
Figure 3-9 illustrates the packet format of the OCRP.
CH01i.book Page 144 Friday, April 30, 2004 8:58 AM
Technical Overview of PPTP 145
Figure 3-9 OCRP Packet Format
As Figure 3-9 depicts, the OCRP message format consists of the following elds (explanations
of elds already described have been omitted unless they differ based on packet relevance):
The Control Message Type eld is set to a value of 8, which indicates that this message is
an OCRP.
The Call ID eld is used to identify uniquely the session within the PPTP tunnel. This
value is locally unique to the PAC.
You may be wondering how the remote access client/PNS is going to associate the OCRP
from the PAC with the OCRQ that it sent if the Call ID in the OCRP is local to the PAC.
The answer is the next eld, the Peers Call ID. This is set to the value of the Call ID in
the OCRQ sent from the remote access client/PNS. With this information, the remote
access client/PNS can associate this OCRP message with the OCRQ that it sent.
The Result Code eld is signicant. It is used to indicate the success or failure of the
session establishment attempt (the OCRQ).
Although RFC 2637 species seven different possible result codes, most of these
are relevant only for compulsory tunnel mode. Only three codes have possible
relevance for voluntary tunnel mode: 1 = Call (session) established with no
errors, 2 = Outgoing call (session) not established for the reason specied in the
Error Code eld (this is known as a General Error), and 7 = Outgoing call
(session) administratively prohibited.
The Error Code eld is a nonzero value if the Result Code eld is set to a value of 2
(General Error). Table 3-3 summarizes the possible error codes.
The Cause Code eld is designed to provide additional error information. In compulsory
tunnel mode, in the event of ISDN call failure, the Q.931 cause code could be
communicated in this eld, for example.
CH01i.book Page 145 Friday, April 30, 2004 8:58 AM
146 Chapter 3: Troubleshooting Point-to-Point Tunneling Protocol VPNs
The Physical Channel ID eld is used in compulsory tunnel mode and species the
physical channel used to dial out from the PAC.
Figure 3-10 shows the call session establishment sequence between the remote access client/
PNS and the PAC.
Figure 3-10 PPTP Call Session Setup
PPP Negotiation and Frame Forwarding
After the exchange of OCRQ and OCRP messages, PPP negotiation takes place between the
remote access client/PNS and the PAC.
The PPP negotiation sequence between the remote access client/PNS and the PAC consists of:
1 LCP negotiation
2 PPP authentication
3 NCP negotiation
These negotiations proceed as they would between directly connected PPP peers. Once PPP
negotiation is complete, regular PPP frame forwarding can take place over the tunnel between
the remote access client/PNS and the PAC.
Figure 3-11 illustrates the PPP negotiation phase, together with PPP frame forwarding (post
negotiation).
PPP frames sent between the remote access client/PNS and the PAC are forwarded over the data
tunnel and are encapsulated in Enhanced GRE packets.
Enhanced GRE differs from regular GRE in that it provides congestion and ow control
(something not provided by regular GRE).
SCCRQ
SCCRQ
OCRQ
OCRQ
Remote Access
Client/PNS
PAC
Internet
CH01i.book Page 146 Friday, April 30, 2004 8:58 AM
Technical Overview of PPTP 147
Figure 3-11 PPP Negotiation and Frame Forwarding
Figure 3-12 shows the Enhanced GRE header.
Figure 3-12 Enhanced GRE Header
The bits and elds in this header are described as follows:
The C, R, K, S, and s bits indicate the presence of a checksum, routing, a key, a sequence
number, and strict source routing, respectively.
The Recur (Recursion Control) bits are all set to 0.
The A bit indicates the presence of an acknowledgment number. Note that the A bit is not
present in the regular GRE header.
SCCRQ
SCCRQ
OCRQ
OCRQ
LCP Negotiation
PPP Authentication
NCP Negotiation
PPP Frames
Remote Access
Client/PNS
PAC
Internet
Recur
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Protocol Type Ver Flags
Sequence Number (Optional)
Acknowledgment Number (Optional)
C R K S s A
Key (LW) Call ID Key (HW) Payload Length
0 1 2 3
CH01i.book Page 147 Friday, April 30, 2004 8:58 AM
148 Chapter 3: Troubleshooting Point-to-Point Tunneling Protocol VPNs
The Flags bits are all set to 0.
Importantly, the Ver (Version) eld is set to a value of 1. This indicates Enhanced GRE.
The Protocol Type eld must be set to a value of 0x880B (the Ethertype for PPP).
The low two octets of the Key eld are set to equal the Call ID for this session. PPTP uses
the high two octets of the key eld to indicate the size of the packet payload (not including
the GRE header).
The two nal elds are the Sequence Number and Acknowledgement Number elds. The
presence of these two elds is dependent on the setting of the S and A bits, respectively.
The Sequence Number eld contains the sequence number of the payload, and
the Acknowledgement Number eld contains the sequence number of the highest
numbered Enhanced GRE packet received. Note that the Acknowledgement eld
is not present in the regular GRE header.
Enhanced GRE packets are themselves encapsulated within IP (protocol 47).
Figure 3-13 shows the data tunnel packet encapsulation.
Figure 3-13 Enhanced GRE (Data Tunnel) Packet Format
PPTP Tunnel Maintenance
PPTP also provides a keepalive mechanism that operates over the control channel. This
keepalive mechanism allows the control connection to be closed down in a timely fashion
should there be a connectivity failure of some kind between the remote access client/PNS and
the PAC.
The keepalive mechanism consists of Echo-Request and Echo-Reply messages and operates as
follows: If there is no activity on the control channel for 60 seconds, an Echo-Request message
is sent. An Echo-Reply message should then be received back from the peer within 60 seconds.
If it is not, then the control channel is terminated.
Figure 3-14 shows the packet format for the Echo-Request message.
IP Header
E.GRE Header
Payload
(PPP Frame)
CH01i.book Page 148 Friday, April 30, 2004 8:58 AM
Technical Overview of PPTP 149
Figure 3-14 Echo-Request Packet Format
As you can see, the message format is very simple:
The Control Message Type eld is set to a value of 5 to identify this message as an
Echo-Request.
The Identier eld is a unique value set by the sender of the message (either remote access
client/PNS or PAC).
Figure 3-15 illustrates the format of the Echo-Reply packet.
Figure 3-15 Echo-Reply Packet Format
Again, the message format is very simple:
The Control Message Type eld is set to a value of 6 to indicate that this message is an
Echo-Reply.
The Identier eld is set to the same value as the Identier eld in the received Echo-
Request. This allows the sender to match the Echo-Reply to the original Echo-Request
message.
The Result and Error codes are used to indicate the validity of the Echo-Request and any
error conditions generated.
The Result Code eld can have one of two values: 1, which indicates that the
Echo-Request is valid, and 2, which indicates that the Echo-Request was not
accepted. If the Echo-Request was not accepted, then the error condition is
indicated in the Error Code eld.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
PPTP Message Type (1)
Reserved0 (0)
Magic Cookie (0x1A2B3C4D)
Identifier
Length
Control Message Type (5)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
PPTP Message Type (1)
Reserved0 (0)
Reserved1
Magic Cookie (0x1A2B3C4D)
Identifier
Result Code Error Code
Length
Control Message Type (6)
0 1 2 3
CH01i.book Page 149 Friday, April 30, 2004 8:58 AM
150 Chapter 3: Troubleshooting Point-to-Point Tunneling Protocol VPNs
The Error Code eld is set to 0 if the Result Code was 1. If the Result Code is 2,
the General Error condition is indicated in this eld. Table 3-3 earlier in this
chapter summarized the General Error conditions.
Figure 3-16 shows the PPTP keepalive mechanism.
Figure 3-16 PPTP Keepalive Mechanism
In Figure 3-16, the Echo-Request is sent from the remote access client/PNS to the PAC. It
should be noted that this message can be sent by either the remote access client/PNS or the PAC.
PPTP Session and Control Channel Termination
In voluntary tunnel mode, if either the remote access client/PNS or the PAC wishes to terminate
the PPTP tunnel, the call (session) is rst torn down, followed by the control connection. The
exact sequence of messages used to terminate the PPTP tunnel depends on whether the
termination is initiated by the remote access client/PNS or by the PAC.
Note that all session and control channel termination messages are sent over the control
channel.
If the remote access client/PNS wishes to terminate the session, it sends a Call-Clear-Request
(CCRQ, or ClearRQ). The PAC then replies to this with a Call-Disconnect-Notify (CDN).
Figure 3-17 shows the format of the CCRQ message.
Figure 3-17 CCRQ Packet Format
ECHO_REPLY
ECHO_REQUEST
Remote Access
Client/PNS
PAC
Internet
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
PPTP Message Type (1)
Reserved0 (0)
Magic Cookie (0x1A2B3C4D)
Length
Call ID
Control Message Type (13)
Reserved1 (0)
0 1 2 3
CH01i.book Page 150 Friday, April 30, 2004 8:58 AM
Technical Overview of PPTP 151
The CCRQ packet elds of signicance are as follows:
The Control Message Type eld is set to a value of 12 to indicate that this is a CCRQ
message.
The Call ID eld is set to indicate the ID of the call (session) to be terminated.
Figure 3-18 illustrates the CDN packet format.
Figure 3-18 CDN Packet Format
The CDN packet elds of signicance are as follows:
The Control Message Type eld is set to 13 to indicate that this is CDN message.
The Call ID eld is set to identify the particular call (session) that is being cleared down.
The Result Code eld can contain one of four possible values: 1 = call disconnected due
to lost carrier (relevant for compulsory tunnel mode only), 2 = call disconnect for reason
indicated by the Error Code eld (known as General Error), 3 = call disconnected for
administrative reasons, and nally, 4 = call disconnected in response to CCRQ.
The Error Code eld is set to 0, except in the event that the Result Code is set to a value
of 2. If this is the case, the Error Code is set to one of the values shown earlier in Table 3-3.
The Cause Code and Call Statistics eld are the nal two elds in the packet. Both are
relevant only for compulsory tunnel mode. Cause Code is used to convey additional call
disconnect information, and Call Statistics can be used to give call statistics for logging
purposes.
As soon as the session has been terminated, the control channel is cleared down.
A Cisco PAC initiates control channel clearing as soon as the session has been terminated by
sending a Stop-Control-Connection-Request (StopCCRQ).
Figure 3-19 shows the format of the StopCCRQ packet.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
PPTP Message Type (1)
Reserved0 (0)
Magic Cookie (0x1A2B3C4D)
Call Statistics (128 octets)
Length
Call ID
Control Message Type (13)
Reserved1 (0) Cause Code
Result Code Error Code
0 1 2 3
CH01i.book Page 151 Friday, April 30, 2004 8:58 AM
152 Chapter 3: Troubleshooting Point-to-Point Tunneling Protocol VPNs
Figure 3-19 StopCCRQ Packet Format
The StopCCRQ packet elds of signicance are as follows:
The Control Message Type eld is set to 3 to indicate that this is a StopCCRQ.
The Reason eld conveys the reason for the control connection termination. There are
three legal values: 1 = general request to clear the control connection, 2 = cannot support
the peers PPTP version, and 3 = this machine is being shut down.
The Reserved2 eld is set to 0.
The client/PNS should then reply to the StopCCRQ with a Stop-Control-Connection-Reply
(StopCCRP).
Figure 3-20 illustrates the format of the StopCCRP packet.
Figure 3-20 StopCCRP Packet Format
The StopCCRQ packet elds of signicance are as follows:
The Control Message Type eld has a value of 4 to indicate that this is a StopCCRP.
In the Result Code eld, one of two values can be used to indicate the result of the attempt
to terminate the control connection. The valid values are: 1 = the control connection has
been closed, and 2 = the control connection has not been closed for the reason indicated
by the Error Code eld (this is known as a General Error).
The Error Code eld is set to a value of 0, unless the Result Code eld is set to a value of
2. If this is the case, an error condition is indicated. These error conditions are shown in
Table 3-3.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
PPTP Message Type (1)
Reserved0 (0)
Reserved2 (0) Reserved1 (0) Reason
Magic Cookie (0x1A2B3C4D)
Length
Control Message Type (3)
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
PPTP Message Type (1)
Reserved0 (0)
Reserved1 (0) Error Code Result Code
Magic Cookie (0x1A2B3C4D)
Length
Control Message Type (4)
0 1 2 3
CH01i.book Page 152 Friday, April 30, 2004 8:58 AM
Technical Overview of PPTP 153
Once this exchange has been completed, the PPTP tunnel has been completely terminated.
Figure 3-21 shows the exchange of messages between the remote access client/PNS and the
PAC necessary for call (session) and control channel termination.
Figure 3-21 Remote Access Client/PNS Initiated Tunnel Termination
If session termination is initiated by the PAC, the sequence of messages is slightly different. The
PAC initiates call session termination by sending a CDN to the remote access client/PNS. The
control connection is then cleared using an exchange of StopCCRQ and StopCCRP messages,
as previously described. As soon as this has been completed, the tunnel is down.
Figure 3-22 shows this exchange.
Figure 3-22 PAC-Initiated Tunnel Termination
StopCCRQ
StopCCRP
CCRQ
CDN
Remote Access
Client/PNS
PAC
Internet
StopCCRQ
StopCCRP
CDN
Remote Access
Client/PNS
PAC
Internet
CH01i.book Page 153 Friday, April 30, 2004 8:58 AM
154 Chapter 3: Troubleshooting Point-to-Point Tunneling Protocol VPNs
Other PPTP Messages
In addition to all of the control channel message types described in the previous section, one
other message is used in voluntary tunnel mode. This message is called Set-Link-Info (SLI).
The SLI is sent by the remote access client/PNS to communicate Asynchronous Control
Character Map (ACCM) information to the PAC.
Figure 3-23 shows the format of the SLI message.
Figure 3-23 SLI Packet Format
The SLI packet elds of signicance are as follows:
The Control Message type eld is set to a value of 15. This indicates that this is a SLI
message.
The Peers Call ID indicates the Call ID that has been assigned by the PAC to this call
(session).
Finally, and most importantly, the Send and Receive ACCM elds are used to
communicate Send and Receive Asynchronous Control Character Maps to the PAC.
Figure 3-24 shows the remote access client/PNS sending a SLI message to the PAC.
Figure 3-24 Remote Access Client/PNS Sends a SLI to the PNS
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
PPTP Message Type (1)
Reserved0 (0)
Reserved1 (0)
Magic Cookie (0x1A2B3C4D)
Send ACCM
Receive ACCM
Length
Peers Call ID
Control Message Type (15)
0 1 2 3
SLI
Remote Access
Client/PNS
PAC
Internet
CH01i.book Page 154 Friday, April 30, 2004 8:58 AM
Conguring PPTP 155
Conguring PPTP
Cisco routers support PPTP voluntary tunnel mode and function as the PAC, with the client
functioning as the PNS.
Conguration is not the main theme of this chapter, but because misconguration is always one
of the most common causes of problems, basic conguration of PPTP on Cisco routers is briey
reviewed here.
A number of conguration tasks have to be completed to enable PPTP. These steps are
summarized as follows:
Step 1 Congure local authentication or remote AAA.
Step 2 Globally enable VPDNs.
Step 3 Congure the VPDN group.
Step 4 Congure the virtual-template.
Step 5 Create the IP pools.
Step 6 Verify each step of the conguration.
To enable local authentication, all that is required is the following:
username username password password
In this case, the username of the remote access client/PNS and its password are specied.
Alternatively, remote AAA can be congured. Remote AAA is much more scalable than local
authentication.
Example 3-1 shows the conguration of remote AAA.
The aaa new-model command is used to globally enable authentication, authorization, and
accounting.
The aaa authentication login default group radius local command is not directly related to
PPTP conguration but is included to illustrate a complete remote AAA conguration. It
congures a default method list for login authentication. This default method list species that
Remote Access Dial In User Service (RADIUS) should be used for login authentication, and
that in the event that the RADIUS server is unreachable, local authentication should be used.
Example 3-1 Configuring Remote AAA
aaa new-model
aaa authentication login default group radius local
aaa authentication ppp default group radius
aaa authorization network default group radius
aaa accounting network default start-stop group radius
radius-server host 10.20.10.5 auth-port 1645 acct-port 1646 key cisco
CH01i.book Page 155 Friday, April 30, 2004 8:58 AM
156 Chapter 3: Troubleshooting Point-to-Point Tunneling Protocol VPNs
The third command, aaa authentication ppp default group radius creates a default method
list specifying RADIUS for PPP authentication.
The aaa authorization network default group radius command is used to congure
authorization for network-related services (including PPP). In this case, a default method list is
used to specify that the RADIUS server should again be queried for authorization.
Accounting is then enabled with the command aaa accounting network default start-stop
group radius. This command species that for network services, an accounting notice should
be sent to the RADIUS server when the service starts and when the service stops. Again, this
command is not essential for PPTP but is included to illustrate a complete AAA conguration.
Finally, the RADIUS server IP address, authentication/authorization and accounting ports, and
the key are specied using the radius-server host 10.20.10.5 auth-port 1645 acct-port 1646
key cisco command.
Note that the authentication/authorization and accounting ports specied here (1645 and 1646,
respectively) are the Cisco defaults. Some RADIUS servers may require you to use ports 1812
and 1813, however.
The next stage of the conguration is to enable virtual private dialup networks (VPDNs, of
which PPTP is one type) globally on the router. This is achieved as follows:
vpdn enable
Having enabled VPDNs, the VPDN group must be congured.
Example 3-2 shows the conguration of the VPDN group.
The rst line in the conguration, vpdn-group 1, denes the name of the VPDN group. In this
case it is 1.
The second line of the conguration (accept-dialin) allows the router to accept inbound VPDN
connections.
The third line (protocol pptp) species that the VPDN protocol to be used is PPP.
The last line in the conguration (virtual-template 1) species that any inbound PPP
connections should be terminated on virtual access interfaces whose conguration is cloned
(copied) from virtual template 1.
Virtual access interfaces are dynamically created when remote access clients connect to the PAC.
After the VPDN group has been dened, the next step is the conguration of the virtual template.
Example 3-3 shows the conguration of the virtual template.
Example 3-2 Configuring the VPDN Group
vpdn-group 1
accept-dialin
protocol pptp
virtual-template 1
CH01i.book Page 156 Friday, April 30, 2004 8:58 AM
Conguring PPTP 157
In the rst line of the virtual template conguration, ip unnumbered is applied to the interface.
In this case, when the conguration is cloned to the virtual access interfaces, the IP address of
interface Ethernet 1/1 will be appliedthis saves on IP addresses.
In this particular example, the PAC has only two interfaces (see Example 3-5), but if your PAC
has more interfaces, a better choice of interface to specify with the ip unnumbered command
is a loopback interface (it is always up).
The next command, peer default ip address pool PPTPPool, species a pool of IP addresses.
Addresses from this pool are assigned to remote access clients connecting to the router (PAC).
The pool name in this example is PPTPPool.
Note that another method that you can use for IP address assignment is via Dynamic Host
Conguration Protocol (DHCP). In this case, the peer default ip address dhcp command
should be used. The DHCP server address can then be specied using the ip dhcp-server
{server_name | server_ip_address} global conguration mode command.
The ppp encrypt mppe 40 required command is next. This is an optional command, which
species that Microsoft Point-to-Point Encryption (MPPE) should be used on the tunnel
between the remote access client/PNS and the router (PAC).
Note that MPPE uses the RC4 variable-key-size cipher, and two session key sizes are congurable:
40-bit and 128-bit. In this case, the key is specied as 40 bits, and the keyword required is applied.
The required keyword means that should the router (PAC) not be able to negotiate MPPE
encryption with the remote access client/PNS, the connection is dropped.
MPPE can alternatively be congured with the passive keyword, as follows: ppp encrypt
mppe 40 passive. If this conguration is used, the PAC attempts to negotiate MPPE with the
remote access client/PNS, but does not drop the connection if that negotiation is unsuccessful.
The virtual template interface is also congured for Microsoft CHAP authentication. Note that
this is a Microsoft requirement when using MPPE.
User-specic interface conguration can also be stored on a AAA server and downloaded by
the PAC when users connect. This conguration is beyond the scope of this chapter, so for some
examples of this (in the form cisco-avpair = lcp:interface-cong=) see the document
entitled Conguring Virtual Proles on www.cisco.com.
The nal part of the conguration involves the conguration of the IP address pool
(PPTPPool), together with DNS and WINS (NetBIOS Name Server) server addresses to be
provided to the remote access client/PNS.
Example 3-3 Configuring the Virtual Template
interface Virtual-Template1
ip unnumbered Ethernet1/1
peer default ip address pool PPTPPool
ppp encrypt mppe 40 required
ppp authentication ms-chap
CH01i.book Page 157 Friday, April 30, 2004 8:58 AM
158 Chapter 3: Troubleshooting Point-to-Point Tunneling Protocol VPNs
Example 3-4 shows the conguration of the address pool, together with DNS and WINS server
addresses.
In this example, ten IP addresses are congured in the pool (192.168.2.1 to 192.168.2.10). Only
ten concurrent PPTP remote access client/PNS connections can, therefore, be accommodated.
The DNS and WINS server addresses are specied as 192.168.1.10 and 192.168.1.12,
respectively.
Example 3-5 shows a complete basic PAC conguration using local authentication.
Example 3-4 Configuring the IP Address Pool and DNS and WINS Server Addresses
ip local pool PPTPPool 192.168.2.1 192.168.2.10
async-bootp dns-server 192.168.1.10
async-bootp nbns-server 192.168.1.12
Example 3-5 Basic PAC Configuration with Local Authentication
Arizona_PAC#show running-config
Building configuration...
Current configuration : 2323 bytes
!
version 12.2
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
service password-encryption
!
hostname Arizona_PAC
!
!
! Configure the remote access clients usernames and passwords
username saru password 7 070C285F4D06
username mo password 7 104D000A0618
username ki password 7 13061E010803
username kara password 7 05080F1C2243
username ochiru password 7 00071A150754
ip subnet-zero
ip cef
!
!
no ip domain-lookup
!
! Configure the DNS and WINS server addresses
async-bootp dns-server 192.168.1.10
async-bootp nbns-server 192.168.1.12
!
! Enable VPDNs (including PPTP)
vpdn enable
! Configure the VPDN group for PPTP remote access clients
vpdn-group 1
! Default PPTP VPDN group
accept-dialin
protocol pptp
CH01i.book Page 158 Friday, April 30, 2004 8:58 AM
Troubleshooting PPTP 159
Before nishing this section, it is worth noting that PPTP trafc is either CEF or processed
switched on Cisco routers.
Troubleshooting PPTP
In previous sections in this chapter, the underlying theory of PPTP operation and its
conguration were discussed. As you begin to troubleshoot PPTP, this accumulated knowledge
will prove very useful.
This section goes through troubleshooting PPTP end-to-end from the remote access client/PNS
to the PAC.
virtual-template 1
!
interface Ethernet1/0
ip address 10.10.10.100 255.255.255.0
duplex half
!
interface Ethernet1/1
ip address 192.168.1.1 255.255.255.0
duplex half
!
! Configure the virtual template
interface Virtual-Template1
ip unnumbered Ethernet1/1
peer default ip address pool PPTPPool
ppp encrypt mppe 40 required
ppp authentication ms-chap
!
! Configure the IP address pool
ip local pool PPTPPool 192.168.2.1 192.168.2.10
ip classless
ip route 0.0.0.0 0.0.0.0 10.10.10.101
!
!
line con 0
password 7 13061E010803
login
line aux 0
line vty 0 4
password 7 1511021F0725
login
!
end
Example 3-5 Basic PAC Configuration with Local Authentication (Continued)
CH01i.book Page 159 Friday, April 30, 2004 8:58 AM
160 Chapter 3: Troubleshooting Point-to-Point Tunneling Protocol VPNs
The owchart in Figure 3-25 describes the troubleshooting process used with PPTP. You can
use this owchart to quickly access the section of the chapter relevant to problems you are
experiencing on your network.
Figure 3-25 PPTP Troubleshooting Flowchart
Note that the remote access client/PNS used in this chapter is a Microsoft Windows 2000
workstation. Client implementations are available for a wide variety of operating systems,
including Windows, FreeBSD, Linux, and MacOS X. Windows 2000 is used only for
illustrative purposes.
CH01i.book Page 160 Friday, April 30, 2004 8:58 AM
Troubleshooting PPTP 161
Before getting down to the nuts and bolts of troubleshooting itself, it is worthwhile to restate
the sequence of events necessary to successfully complete a PPTP connection between the
remote access client/PNS and the PAC:
1 The remote access client/PNS sends a SCCRQ message to the PAC.
2 The PAC responds with a SCCRP message.
3 With the Control Connection established, the remote access client/PNS now sends an
OCRQ message to the PAC.
4 The PAC then responds to the OCRQ with an OCRP message.
5 Once the OCRP has been sent, the PAC clones (copies) the conguration from the virtual
interface to a virtual access interface.
6 The session is now set up between the remote access client/PNS and the PAC. The remote
access client/PNS begins to forward PPP frames to the PAC.
7 The remote access client/PNS and the PAC negotiate the LCP.
8 Following LCP negotiation, PPP authentication is performed.
9 Finally, NCPs, including CCP and IPCP, can be negotiated.
10 Forwarding of negotiated protocols, such as IP, begins.
Figure 3-26 summarizes the PPTP tunnel setup sequence.
Figure 3-26 PPTP Tunnel Setup Sequence
LCP Negotiation
PPP Authentication
NCP Negotiation
Control Channel Established (SCCRQ, SCCRP)
Call (Session) Setup (OCRQ, OCRP)
PPP Frames Forwarding
Remote Access
Client/PNS
PAC
Internet
CH01i.book Page 161 Friday, April 30, 2004 8:58 AM
162 Chapter 3: Troubleshooting Point-to-Point Tunneling Protocol VPNs
Now that you have been reminded of the overall model for successful PPTP tunnel negotiation,
you can examine some of the problems that could potentially result in a PPTP tunnel failure.
Together, Figure 3-27 and Table 3-4 illustrate some of these potential issues.
Figure 3-27 Possible PPTP Setup Issues
Note that many of the potential problems do not directly relate to conguration of PPTP on the
PAC but are provided in Figure 3-27 and Table 3-4 for illustrative purposes only.
In the next few sections, potential PPTP issues are examined, together with their solutions,
using an end-to-end troubleshooting methodology.
Table 3-4 Potential Problems at Each Point Along the Tunnel
Potential Problems at the
Remote Access Client/PNS
Potential Problems in
Service Provider Backbone
Potential Problems
at the PAC
OS Issues Cabling/physical layer issue Cabling issue
Incorrect modem driver Data-link issue Data-link issue
DUN miscongured IP connectivity broken Tunnel protocol mismatch
TCP/IP not installed TCP port 1723/GRE blocked
(ACL/Firewall)
Virtual template
misconguration
TCP/IP not bound to dialup
networking adapter
Authentication protocol
mismatch
Incorrect IP address for PAC Authentication failure
Wrong tunnel protocol MPPE issue
Authentication protocol mismatch IP misconguration
Authentication failure
MPPE Issue
Modem Issues
Not switched on
Cabling issue
Remote Access
Client/PNS
PAC
Internet
CH01i.book Page 162 Friday, April 30, 2004 8:58 AM
Troubleshooting PPTP 163
Control Connection and Call Session Establishment Failure
As can be seen from the summary of PPTP tunnel establishment in the previous section (Figure
3-26), the rst thing that the remote access client/PNS must do to establish a PPTP tunnel is to
set up a control connection to the PAC. Once the control connection has been set up, the call
session can be established.
Figure 3-28 illustrates control connection and call session setup.
Figure 3-28 Control Channel and Call Session Setup
A number of issues can cause a control connection failure, among them the following:
A basic IP connectivity failure. To troubleshoot this issue, simply attempt to ping the PAC
from the remote access client/PNS. Also, ensure that an access list or rewall is not
blocking TCP port 1723 (used by control channel packets).
The error reported by Microsoft remote access client/PNSs in the event of a
connectivity failure is as follows: Error 678: There was no answer.
A tunnel (VPDN) protocol mismatch.
PPTP is not the only tunnel protocol that can be used to establish voluntary tunnel mode
connectivity between a remote access client workstation and a Cisco router. An alternative is
the L2TP. Therefore, it is possible for there to be a mismatch of tunnel protocols between the
remote access client and the PAC.
Before troubleshooting this scenario, it is useful to examine an example of successful PPTP
control connection and session establishment. To determine whether PPTP control messages
are being received on the PAC, use the debug vpdn l2x-packets command. Note that if you are
terminating a large number of PPTP tunnels on the PAC, this command may produce a large
amount of output. In this case, the debug vpdn l2x-events and debug vpdn l2x-errors
commands may be better alternatives.
Examples 3-6 to 3-8 show a successful control connection and session establishment between
the remote access client/PNS and the PAC.
Remote Access
Client/PNS
(172.16.1.2)
Arizona_PAC
(10.10.10.100)
Internet
User: mjlnet
Control Channel Established (SCCRQ, SCCRP)
Session Setup (OCRQ, OCRP)
CH01i.book Page 163 Friday, April 30, 2004 8:58 AM
164 Chapter 3: Troubleshooting Point-to-Point Tunneling Protocol VPNs
Highlighted line 1 (Example 3-6) shows an incoming (I) SCCRQ message from the remote
access client/PNS. Note that the line above this shows the raw data in the packet.
The following seven lines of output detail the contents (elds) of this message. Of particular
interest is the Vendor eld, which indicates that the remote access client/PNS is a Windows NT
workstation.
Note also that the Framing and Bearer Capabilities elds are both set to a value of 1, indicating
asynchronous framing and analog access support. These are simply defaults and may not in fact
reect true connectivity.
In highlighted line 2, the PAC responds to the SCCRQ by sending a SCCRP message to the
remote access client/PNS. Notice that this message is outgoing (indicated by the O).
The PPTP control connection has now been set up between the remote access client/PNS and
the PAC.
For more information about the elds contained within the SCCRQ and SCCRP messages, see
the section entitled PPTP Control Channel Setup earlier in chapter.
PPTP session setup now begins, as shown in Example 3-7.
Example 3-6 Successful Control Connection and Session Setup
Arizona_PAC#debug vpdn l2x-packets
L2X control packets debugging is on
Arizona_PAC#
Jan 20 10:29:16.075 UTC: Tnl 13 PPTP: I
009C00011A2B3C4D0001000001000000000000010000...
Jan 20 10:29:16.075 UTC: Tnl 13 PPTP: I SCCRQ
Jan 20 10:29:16.075 UTC: Tnl 13 PPTP: protocol version 100
Jan 20 10:29:16.075 UTC: Tnl 13 PPTP: framing caps 1
Jan 20 10:29:16.075 UTC: Tnl 13 PPTP: bearer caps 1
Jan 20 10:29:16.075 UTC: Tnl 13 PPTP: max channels 0
Jan 20 10:29:16.075 UTC: Tnl 13 PPTP: firmware rev 870
Jan 20 10:29:16.075 UTC: Tnl 13 PPTP: hostname ""
Jan 20 10:29:16.075 UTC: Tnl 13 PPTP: vendor "Microsoft Windows NT"
Jan 20 10:29:16.075 UTC: Tnl 13 PPTP: O SCCRP
Jan 20 10:29:16.079 UTC: Tnl 13 PPTP: I
00A800011A2B3C4D00070000400045450000012C05F5...
Example 3-7 Session Setup Begins
Jan 20 10:29:16.079 UTC: Tnl 13 PPTP: CC I OCRQ
Jan 20 10:29:16.079 UTC: Tnl 13 PPTP: call id 16384
Jan 20 10:29:16.079 UTC: Tnl 13 PPTP: serial num 17733
Jan 20 10:29:16.079 UTC: Tnl 13 PPTP: min bps 300
Jan 20 10:29:16.079 UTC: Tnl 13 PPTP: max bps 100000000
Jan 20 10:29:16.079 UTC: Tnl 13 PPTP: bearer type 3
Jan 20 10:29:16.079 UTC: Tnl 13 PPTP: framing type 3
Jan 20 10:29:16.079 UTC: Tnl 13 PPTP: recv win size 64
Jan 20 10:29:16.079 UTC: Tnl 13 PPTP: ppd 0
Jan 20 10:29:16.079 UTC: Tnl 13 PPTP: phone num len 0
CH01i.book Page 164 Friday, April 30, 2004 8:58 AM
Troubleshooting PPTP 165
In highlighted line 1 (Example 3-7), the PAC receives an OCRQ message. Note that the CC in
the line PPTP: CC I OCRQ indicates that this message is received on the control connection
(via TCP).
Below the highlighted line, elds in the OCRQ message are detailed. Note the Call-IDthis is
used by the remote access client/PNS to identify the particular session within the overall tunnel,
although there will be only one session because this is voluntary tunnel mode.
Other elds to note are the Bearer and Framing elds, both of which show a value of 3. This
indicates that any kind of bearer and framing is acceptable. Note also that the phone num
(phone number) eld is blank; obviously, the remote access client/PNS is not really requesting
the PAC to make an outgoing call in this case.
Highlighted line 2 shows the PAC responding with an OCRP message. The conguration from
the virtual template is then cloned to virtual access interface 1, and the interface changes state
to up. The PPTP session is now established.
For more information on the PPTP session setup, see the section entitled PPTP Session
Establishment at the beginning of this chapter.
Two more control connection messages are then sent by the remote access client/PNS to the
PAC, as shown in Example 3-8.
Jan 20 10:29:16.079 UTC: Tnl 13 PPTP: phone num ""
Jan 20 10:29:16.095 UTC: Vi1 Tnl/Cl 13/13 PPTP: CC O OCRP
Jan 20 10:29:16.099 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state
to up
Jan 20 10:29:16.099 UTC: Tnl 13 PPTP: I
001800011A2B3C4D000F0000000D0000FFFFFFFFFFFFFFFF
Example 3-8 The Remote Access Client/PNS Sends Two SLIs
Jan 20 10:29:16.099 UTC: Vi1 Tnl/Cl 13/13 PPTP: CC I SLI
Jan 20 10:29:16.107 UTC: Vi1 PPTP: I, payload length 19
Jan 20 10:29:18.099 UTC: Vi1 PPTP: I, payload length 19
Jan 20 10:29:18.099 UTC: Vi1 PPTP: I, payload length 48
Jan 20 10:29:18.099 UTC: Vi1 PPTP: I, payload length 41
Jan 20 10:29:18.103 UTC: Vi1 PPTP: I, payload length 22
Jan 20 10:29:18.103 UTC: Vi1 PPTP: I, payload length 29
Jan 20 10:29:18.103 UTC: Vi1 PPTP: I, payload length 66
Jan 20 10:29:18.103 UTC: Tnl 13 PPTP: I
001800011A2B3C4D000F0000000D00000000000000000000
Jan 20 10:29:18.103 UTC: Vi1 Tnl/Cl 13/13 PPTP: CC I SLI
Jan 20 10:29:18.127 UTC: Vi1 PPTP: I, payload length 14
Jan 20 10:29:18.127 UTC: Vi1 PPTP: I, payload length 38
Jan 20 10:29:18.127 UTC: Vi1 PPTP: I, payload length 14
Jan 20 10:29:18.127 UTC: Vi1 PPTP: I, payload length 14
Jan 20 10:29:18.131 UTC: Vi1 PPTP: I, payload length 14
Jan 20 10:29:18.131 UTC: Vi1 PPTP: I, payload length 26
Jan 20 10:29:18.135 UTC: Vi1 PPTP: I, payload length 26
Example 3-7 Session Setup Begins (Continued)
CH01i.book Page 165 Friday, April 30, 2004 8:58 AM
166 Chapter 3: Troubleshooting Point-to-Point Tunneling Protocol VPNs
In highlighted lines 1 and 2 (Example 3-8), the PAC receives SLI messages from the remote
access client/PNS. Finally, in highlighted line 3, the line protocol on interface virtual access 1
changes state to up. The remote access client/PNS has successful connected to the PAC.
Having seen what happens if tunnel setup is successful, you can have a look at some debug
output where tunnel setup is not so successful. Once again, the debug vpdn l2x-packets
command is used to monitor control channel and session setup on the PNS.
Example 3-9 shows the output resulting when there is a tunnel protocol mismatch between the
remote access client/PNS and the PAC.
Jan 20 10:29:18.247 UTC: Vi1 PPTP: I, payload length 104
Jan 20 10:29:18.251 UTC: Vi1 PPTP: I, payload length 40
Jan 20 10:29:18.251 UTC: Vi1 PPTP: I, payload length 60
Jan 20 10:29:18.911 UTC: Vi1 PPTP: I, payload length 104
Jan 20 10:29:19.123 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Virtual-Access1, changed state to up
Arizona_PAC#
Example 3-9 Control Connection Setup Fails
Arizona_PAC#debug vpdn l2x-packets
L2X control packets debugging is on
Arizona_PAC#
Jan 20 10:30:30.083 UTC: L2X: Parse AVP 0, len 8, flag 0x8000 (M)
Jan 20 10:30:30.083 UTC: L2X: Parse SCCRQ
Jan 20 10:30:30.083 UTC: L2X: Parse AVP 2, len 8, flag 0x8000 (M)
Jan 20 10:30:30.083 UTC: L2X: Protocol Ver 256
Jan 20 10:30:30.083 UTC: L2X: Parse AVP 3, len 10, flag 0x8000 (M)
Jan 20 10:30:30.083 UTC: L2X: Framing Cap 0x1
Jan 20 10:30:30.083 UTC: L2X: Parse AVP 4, len 10, flag 0x8000 (M)
Jan 20 10:30:30.083 UTC: L2X: Bearer Cap 0x0
Jan 20 10:30:30.083 UTC: L2X: Parse AVP 6, len 8, flag 0x0
Jan 20 10:30:30.083 UTC: L2X: Firmware Ver 0x500
Jan 20 10:30:30.083 UTC: L2X: Parse AVP 7, len 15, flag 0x8000 (M)
Jan 20 10:30:30.083 UTC: L2X: Hostname mlewis
Jan 20 10:30:30.083 UTC: L2X: Parse AVP 8, len 15, flag 0x0
Jan 20 10:30:30.083 UTC: L2X: Vendor Name Microsoft
Jan 20 10:30:30.087 UTC: L2X: Parse AVP 9, len 8, flag 0x8000 (M)
Jan 20 10:30:30.087 UTC: L2X: Assigned Tunnel ID 2
Jan 20 10:30:30.087 UTC: L2X: Parse AVP 10, len 8, flag 0x8000 (M)
Jan 20 10:30:30.087 UTC: L2X: Rx Window Size 8
Jan 20 10:30:30.087 UTC: L2X: No missing AVPs in SCCRQ
Jan 20 10:30:30.087 UTC: L2X: I SCCRQ, flg TLS, ver 2, len 102, tnl 0, cl 0, ns 0,
nr 0
C8 02 00 66 00 00 00 00 00 00 00 00 80 08 00 00
00 00 00 01 80 08 00 00 00 02 01 00 80 0A 00 00
00 03 00 00 00 01 80 0A 00 00 00 04 00 00 00 ...
Jan 20 10:30:30.087 UTC: L2TP: I SCCRQ from mlewis tnl 2
Jan 20 10:30:31.075 UTC: L2X: Parse AVP 0, len 8, flag 0x8000 (M)
Jan 20 10:30:31.075 UTC: L2X: Parse SCCRQ
Example 3-8 The Remote Access Client/PNS Sends Two SLIs (Continued)
CH01i.book Page 166 Friday, April 30, 2004 8:58 AM
Troubleshooting PPTP 167
In highlighted line 1, the PAC parses a SCCRQ from the remote access client/PNS. This seems
OK, but then in highlighted line 2, if you look closely you can see that the SCCRQ is an L2TP
SCCRQ.
Hold on, you might be thinking, isnt the SCCRQ a PPTP message? It is, but it is also a
message type used in L2TP. This is no surprise, as L2TP incorporates the best features of both
PPTP and L2F. Unfortunately, it is backward-compatible with neither.
At this point, it is interesting to note a fundamental difference in voluntary mode session setup
between PPTP and L2TPv2. In PPTP, the remote access client sends an OCRQ to initiate
session setup, and the router responds with an OCRP. In L2TPv2, on the other hand, the remote
access client sends an L2TP Incoming-Call-Request (ICRQ), the router responds with an
Incoming-Call-Reply (ICRP), and the session setup is completed when the remote access client
sends an Incoming-Call-Connected (ICCN). PPTP also uses ICRQ, ICRP, and ICCN messages
but only in compulsory tunnel mode. Interestingly, the rst Microsoft L2TPv2 voluntary tunnel
mode client also used outgoing call messages (in a very similar way to PPTP). But when
Microsoft engineers arrived at an early vendor inter-operability test (called a bakeoff), they
discovered that most other vendors had implemented voluntary tunnel mode in the opposite
way (using incoming call messages), and so modied their client code to make it work in the
same way as other vendor implementations. So, theres been a certain amount of confusion
regarding PPTP and L2TPv2 voluntary tunnel mode, but its really just terminological
confusion (neither protocol is inhibited in operation).
To resolve this issue, the remote access client tunnel protocol needs to be recongured as PPTP.
Once the remote access client is recongured (not shown), the PPTP tunnel is successfully
established. This is veried using the show vpdn tunnel all command, as shown in
Example 3-10.
Jan 20 10:30:31.075 UTC: L2X: Parse AVP 2, len 8, flag 0x8000 (M)
Jan 20 10:30:31.075 UTC: L2X: Protocol Ver 256
Jan 20 10:30:31.075 UTC: L2X: Parse AVP 3, len 10, flag 0x8000 (M)
Jan 20 10:30:31.075 UTC: L2X: Framing Cap 0x1
Jan 20 10:30:31.075 UTC: L2X: Parse AVP 4, len 10, flag 0x8000 (M)
Jan 20 10:30:31.075 UTC: L2X: Bearer Cap 0x0
Jan 20 10:30:31.075 UTC: L2X: Parse AVP 6, len 8, flag 0x0
Jan 20 10:30:31.075 UTC: L2X: Firmware Ver 0x500
Jan 20 10:30:31.075 UTC: L2X: Parse AVP 7, len 15, flag 0x8000 (M)
Jan 20 10:30:31.075 UTC: L2X: Hostname mlewis
Jan 20 10:30:31.079 UTC: L2X: Parse AVP 8, len 15, flag 0x0
Jan 20 10:30:31.079 UTC: L2X: Vendor Name Microsoft
Jan 20 10:30:31.079 UTC: L2X: Parse AVP 9, len 8, flag 0x8000 (M)
Jan 20 10:30:31.079 UTC: L2X: Assigned Tunnel ID 2
Jan 20 10:30:31.079 UTC: L2X: Parse AVP 10, len 8, flag 0x8000 (M)
Jan 20 10:30:31.079 UTC: L2X: Rx Window Size 8
Jan 20 10:30:31.079 UTC: L2X: No missing AVPs in SCCRQ
Arizona_PAC#
Example 3-9 Control Connection Setup Fails (Continued)
CH01i.book Page 167 Friday, April 30, 2004 8:58 AM
168 Chapter 3: Troubleshooting Point-to-Point Tunneling Protocol VPNs
As you can see from the output, one PPTP tunnel has been established, and within it one session
(highlighted line 1).
Highlighted lines 2 and 3 show the remote access client/PNSs and PACs IP addresses, together
with the TCP ports used for control connection connectivity.
Note that the error reported by Microsoft remote access client/PNSs (Windows 2000) in the
event of a tunnel protocol mismatch is as follows:
Error 678: There was no answer.
Virtual Access Interface Is Not Cloned
Once the PPTP tunnel and session have been established, the virtual access interface is cloned
from the virtual template.
Use the debug vtemplate command to verify that the virtual access interface is correctly cloned
from the virtual template as shown in Example 3-11.
Example 3-10 Verifying the PPTP Tunnel
Arizona_PAC#show vpdn tunnel all
%No active L2TP tunnels
%No active L2F tunnels
PPTP Tunnel Information Total tunnels 1 sessions 1
Tunnel id 14, 1 active sessions
Tunnel state is estabd, time since change 00:00:28
Remote tunnel name is
Internet Address 172.16.1.2, port 2085
Local tunnel name is Arizona_PAC
Internet Address 10.10.10.100, port 1723
16 packets sent, 54 received, 562 bytes sent, 5159 received
%No active PPPoE tunnels
Arizona_PAC#
Example 3-11 Virtual Access Interface Is Correctly Cloned
Arizona_PAC#debug vtemplate
Virtual Template debugging is on
Arizona_PAC#
*Aug 17 21:04:07.983 UTC: Vi1 VTEMPLATE: Reuse Vi1, recycle queue size 0
*Aug 17 21:04:07.983 UTC: Vi1 VTEMPLATE: Hardware address 00d0.6354.7000
*Aug 17 21:04:07.983 UTC: Vi1 VTEMPLATE: Has a new cloneblk vtemplate, now it has
vtemplate
*Aug 17 21:04:07.983 UTC: Vi1 VTEMPLATE: ************* CLONE VACCESS1
*****************
*Aug 17 21:04:07.983 UTC: Vi1 VTEMPLATE: Clone from Virtual-Template1
interface Virtual-Access1
default ip address
no ip address
encap ppp
ip unnumbered Ethernet1/1
end
CH01i.book Page 168 Friday, April 30, 2004 8:58 AM
Troubleshooting PPTP 169
In highlighted lines 1 and 2, conguration is copied from virtual template interface 1 to virtual
access interface 1. The following four lines show the conguration copied to the virtual access
interface. The virtual access interface and line protocol change state to up in highlighted lines
3 and 4. In this case, the virtual access interface has been successful cloned.
If the debug vtemplate command produces no output, verify that the virtual template is
correctly referenced under the VPDN group using the show running-cong command. This is
shown in Example 3-12. Note that only the relevant portion of the output is shown.
In this example, the virtual template is correctly referenced under the VPDN group.
If you have user-specic conguration stored on a AAA server, be sure to verify this
conguration as you troubleshoot PPP.
LCP Negotiation Failure
Once the virtual access interface has been cloned, PPP negotiation begins. PPP negotiation
consists of LCP negotiation, PPP authentication, and NCP negotiation. This section examines
what happens if LCP negotiation fails.
Authentication protocol mismatch is a common cause of LCP negotiation failure. For example,
if the remote access client/PNS is congured to authenticate using only the Microsoft
Challenge Handshake Authentication Protocol (MS-CHAP), and the PAC is congured only for
standard Message Digest 5 Challenge Handshake Authentication Protocol (MD5 CHAP),
authentication protocol negotiation failure will occur.
Figure 3-29 illustrates LCP negotiation.
*Aug 17 21:04:08.003 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state
to up
*Aug 17 21:04:11.027 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Virtual-Access1, changed state to up
Arizona_PAC#
Example 3-12 Verifying the VPDN Group
!
vpdn-group 1
! Default PPTP VPDN group
accept-dialin
protocol pptp
virtual-template 1
!
Example 3-11 Virtual Access Interface Is Correctly Cloned (Continued)
CH01i.book Page 169 Friday, April 30, 2004 8:58 AM
170 Chapter 3: Troubleshooting Point-to-Point Tunneling Protocol VPNs
Figure 3-29 LCP Negotiation
To begin with, it is worthwhile examining successful LCP negotiation (including the
negotiation of authentication protocols). Use the debug ppp negotiation command to examine
LCP negotiation between the remote access client/PNS and the PAC.
Examples 3-13 to 3-21 show a successful LCP negotiation sequence.
In the rst highlighted line, virtual interface 1 changes state to up. This means that the control
channel is established, and that OCRQ and OCRP messages have been exchanged. At this point,
PPP phase changes to ESTABLISHING. LCP negotiation is about to begin.
In Example 3-14, the PAC sends an outgoing (O) Congure-Request (CONFREQ) to the
remote access client/PNS. This is used to inform the remote access client/PNS of the LCP
options that the PAC would like to use.
In Example 3-14, the CONFREQ includes two options: option 0x03, Authentication Protocol,
and option 0x05, Magic Number. The authentication protocol specied is MS-CHAPv1
Example 3-13 Successful LCP Negotiation
Arizona_PAC#debug ppp negotiation
PPP protocol negotiation debugging is on
Arizona_PAC#
Jan 20 10:37:11.443 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state
to up
Jan 20 10:37:11.443 UTC: Vi1 PPP: Treating connection as a dedicated line
Jan 20 10:37:11.443 UTC: Vi1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 1 load]
Example 3-14 PAC Sends a CONFREQ
Jan 20 10:37:11.443 UTC: Vi1 LCP: O CONFREQ [Closed] id 41 len 15
Jan 20 10:37:11.443 UTC: Vi1 LCP: AuthProto MS-CHAP (0x0305C22380)
Jan 20 10:37:11.443 UTC: Vi1 LCP: MagicNumber 0xD091B3B6 (0x0506D091B3B6)
Remote Access
Client/PNS
(172.16.1.2) Arizona_PAC
(10.10.10.100)
Internet
User: mjlnet
LCP Negotiation
Control Channel Established (SCCRQ, SCCRP)
Session Setup (OCRQ, OCRP)
CH01i.book Page 170 Friday, April 30, 2004 8:58 AM
Troubleshooting PPTP 171
(0xC22380), and the Magic Number is 0xD091B3B6. Note that the Magic Number is random
and is used to detect error conditions such as a looped back line.
It might be interesting to note the format of the options specied. The format is option type,
length, and any associated data. The raw options are shown in brackets. The option type, length,
and associated data format is common to PPP options.
An incoming (I) Congure-Ack (CONFACK) message is then received from the remote access
client/PNS as demonstrated in Example 3-15. This is good news; it means that the remote
access client/PNS has accepted the options sent in the initial CONFREQ message (Example
3-14). The accepted options are repeated in the CONFACK, as you can see.
In Example 3-16, the PAC sends another CONFREQ to the remote access client/PNS. This
contains the same options as the rst CONFREQ (see Example 3-14). This is sent because LCP
timed out in Example 3-15 (see the nal line in the output).
The remote access client/PNS acknowledges the CONFREQ in Example 3-16 with a
CONFACK, as shown in Example 3-17.
In Example 3-18, an incoming (I) CONFREQ is received from the remote access client/PNS.
The options specied in the message are shown in the following eight lines.
Example 3-15 Remote Access Client/PNS Responds with a CONFACK
Jan 20 10:37:11.451 UTC: Vi1 LCP: I CONFACK [REQsent] id 41 len 15
Jan 20 10:37:11.451 UTC: Vi1 LCP: AuthProto MS-CHAP (0x0305C22380)
Jan 20 10:37:11.451 UTC: Vi1 LCP: MagicNumber 0xD091B3B6 (0x0506D091B3B6)
Jan 20 10:37:13.443 UTC: Vi1 LCP: TIMEout: State ACKrcvd
Example 3-16 PAC Sends Another CONFREQ
Jan 20 10:37:13.443 UTC: Vi1 LCP: O CONFREQ [ACKrcvd] id 42 len 15
Jan 20 10:37:13.443 UTC: Vi1 LCP: AuthProto MS-CHAP (0x0305C22380)
Jan 20 10:37:13.443 UTC: Vi1 LCP: MagicNumber 0xD091B3B6 (0x0506D091B3B6)
Example 3-17 Remote Access Client/PNS Sends a CONFACK
Jan 20 10:37:13.443 UTC: Vi1 LCP: I CONFACK [REQsent] id 42 len 15
Jan 20 10:37:13.443 UTC: Vi1 LCP: AuthProto MS-CHAP (0x0305C22380)
Jan 20 10:37:13.443 UTC: Vi1 LCP: MagicNumber 0xD091B3B6 (0x0506D091B3B6)
Example 3-18 Remote Access Client/PNS Sends a CONFREQ
Jan 20 10:37:13.451 UTC: Vi1 LCP: I CONFREQ [ACKrcvd] id 1 len 44
Jan 20 10:37:13.451 UTC: Vi1 LCP: MagicNumber 0x75674EB0 (0x050675674EB0)
Jan 20 10:37:13.451 UTC: Vi1 LCP: PFC (0x0702)
Jan 20 10:37:13.451 UTC: Vi1 LCP: ACFC (0x0802)
Jan 20 10:37:13.451 UTC: Vi1 LCP: Callback 6 (0x0D0306)
Jan 20 10:37:13.451 UTC: Vi1 LCP: MRRU 1614 (0x1104064E)
Jan 20 10:37:13.451 UTC: Vi1 LCP: EndpointDisc 1 Local
Jan 20 10:37:13.455 UTC: Vi1 LCP: (0x1317011CCDA40A14674B1C963C4A1AC1)
Jan 20 10:37:13.455 UTC: Vi1 LCP: (0x03DF730000000E)
CH01i.book Page 171 Friday, April 30, 2004 8:58 AM
172 Chapter 3: Troubleshooting Point-to-Point Tunneling Protocol VPNs
The rst option specied in the CONFREQ shown in Example 3-18 is another Magic Number,
followed by Protocol Field Compression (PFC, LCP option 0x07). This indicates that the
remote access client/PNS is capable of receiving compressed PPP protocol elds. The next
option is Address and Control Field Compression (ACFC) (option 0x08). The inclusion of this
option indicates that the remote access client/PNS would like to receive PPP frames without the
leading HDLC Address and Control elds.
The nal three options included are Callback (option 0x0D), Maximum-Reconstructed-
Receive-Unit (MRRU) (option 0x11), and Endpoint-Discriminator (ED, option 0x13).
The Callback option is used by the end system to request that the system terminating the link
call it back. MRRU and ED are both used in a Multilink PPP (MP) environment. Note that
Callback and MP are not supported for PPTP on IOS routers.
The PAC now sends a Congure-Reject (CONFREJ) message, which is used to indicate to the
remote access client/PNS that Callback and MRRU options are unacceptable or not understood.
This CONFREJ message is shown in Example 3-19.
Having received the CONFREJ, the remote access client/PNS now sends another CONFREQ,
as shown in Example 3-20. This CONFREQ species all of the options included in its previous
CONFREQ in Example 3-18 minus those rejected by the PAC in Example 3-19.
In Example 3-21, the PAC responds with a CONFACK.
Example 3-19 PAC Rejects Callback and MRRU
Jan 20 10:37:13.455 UTC: Vi1 LCP: O CONFREJ [ACKrcvd] id 1 len 11
Jan 20 10:37:13.455 UTC: Vi1 LCP: Callback 6 (0x0D0306)
Jan 20 10:37:13.455 UTC: Vi1 LCP: MRRU 1614 (0x1104064E)
Example 3-20 Remote Access Client/PNS Sends a Second CONFREQ
Jan 20 10:37:13.455 UTC: Vi1 LCP: I CONFREQ [ACKrcvd] id 2 len 37
Jan 20 10:37:13.455 UTC: Vi1 LCP: MagicNumber 0x75674EB0 (0x050675674EB0)
Jan 20 10:37:13.455 UTC: Vi1 LCP: PFC (0x0702)
Jan 20 10:37:13.455 UTC: Vi1 LCP: ACFC (0x0802)
Jan 20 10:37:13.455 UTC: Vi1 LCP: EndpointDisc 1 Local
Jan 20 10:37:13.455 UTC: Vi1 LCP: (0x1317011CCDA40A14674B1C963C4A1AC1)
Jan 20 10:37:13.455 UTC: Vi1 LCP: (0x03DF730000000E)
Example 3-21 PAC Responds with a CONFACK
Jan 20 10:37:13.455 UTC: Vi1 LCP: O CONFACK [ACKrcvd] id 2 len 37
Jan 20 10:37:13.455 UTC: Vi1 LCP: MagicNumber 0x75674EB0 (0x050675674EB0)
Jan 20 10:37:13.455 UTC: Vi1 LCP: PFC (0x0702)
Jan 20 10:37:13.455 UTC: Vi1 LCP: ACFC (0x0802)
Jan 20 10:37:13.455 UTC: Vi1 LCP: EndpointDisc 1 Local
Jan 20 10:37:13.455 UTC: Vi1 LCP: (0x1317011CCDA40A14674B1C963C4A1AC1)
Jan 20 10:37:13.455 UTC: Vi1 LCP: (0x03DF730000000E)
Jan 20 10:37:13.455 UTC: Vi1 LCP: State is Open
CH01i.book Page 172 Friday, April 30, 2004 8:58 AM
Troubleshooting PPTP 173
The CONFACK sent by the PAC (Example 3-21, highlighted line 1) serves to acknowledge and
accept the options contained in the remote access client/PNSs last CONFREQ (Example 3-20).
Finally, the LCP state changes to Open (highlighted line 2), and LCP negotiation is complete.
When LCP negotiation is not successful, the output of the debug ppp negotiation command is
somewhat different.
Examples 3-22 to 3-24 show an unsuccessful LCP negotiation sequence.
In highlighted line 1 (Example 3-22), virtual access interface 1 changes state to up. This
indicates that the control channel and the session have both been successfully negotiated
between the remote access client/PNS and the PAC. The PPP phase then changes to
ESTABLISHING (highlighted line 2). LCP negotiation is about to begin.
The PAC sends a CONFREQ to the remote access client/PNS in highlighted line 3. In it, the
PAC species two LCP options, Authentication Protocol (option 0x03), and Magic Number
(option 0x05). The authentication protocol specied by the PAC is standard MD5 CHAP
(CHAP, option 0xC22305).
In the third highlighted line, the remote access client/PNS responds with a Congure-Nak
(CONFNAK), which indicates that while CHAP is unacceptable, MS-CHAPv2 (CHAP/129,
0xC22381) would be acceptable instead.
The debug output in Example 3-22 does not explicitly show MS-CHAPv2 and, instead, shows
CHAP/129 because the particular (old) version of Cisco IOS used in this example does not
support MS-CHAPv2. But it is fairly easy to work out that MS-CHAPv2 is indicated from the
hexadecimal (0xc22381, shown in brackets in the last line of Example 3-23). The 0xc223 (in
0xc22381) indicates CHAP of some kind, and the nal two numerals indicate the specic CHAP
algorithmin this case, MS-CHAPv2 (0x81). 0x81 is 129 in decimal hence the CHAP/129.
Example 3-22 LCP Negotiation Is Unsuccessful
Arizona_PAC#debug ppp negotiation
PPP protocol negotiation debugging is on
Arizona_PAC#
Jan 20 10:39:50.247 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state
to up
Jan 20 10:39:50.247 UTC: Vi1 PPP: Treating connection as a dedicated line
Jan 20 10:39:50.247 UTC: Vi1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 1 load]
Jan 20 10:39:50.247 UTC: Vi1 LCP: O CONFREQ [Closed] id 49 len 15
Jan 20 10:39:50.247 UTC: Vi1 LCP: AuthProto CHAP (0x0305C22305)
Jan 20 10:39:50.247 UTC: Vi1 LCP: MagicNumber 0xD094200D (0x0506D094200D)
Jan 20 10:39:50.251 UTC: Vi1 LCP: I CONFNAK [REQsent] id 49 len 9
Jan 20 10:39:50.251 UTC: Vi1 LCP: AuthProto CHAP/129 (0x0305C22381)
CH01i.book Page 173 Friday, April 30, 2004 8:58 AM
174 Chapter 3: Troubleshooting Point-to-Point Tunneling Protocol VPNs
The PAC then tries again to negotiate standard MD5 CHAP with the remote access client/PNS,
as shown in Example 3-23.
In Example 3-23, the PAC again tries to negotiate standard MD5 CHAP by sending four more
CONFREQs in highlighted lines 1, 3, 5, and 7.
The remote access client/PNS again rejects each attempt to negotiate standard CHAP by
sending CONFNAKs in highlighted lines 2, 4, 6, and 8.
LCP negotiation now fails, and the PPP phase changes to DOWN, as demonstrated in Example 3-24.
In highlighted line 1 (Example 3-24), the output indicates that LCP negotiation with the remote
access client/PNS has failed. In highlighted line 2, the PPP phase changes state to DOWN.
PPP negotiation has now ended. It is pretty clear, however, what the problem is: The PAC wants
to use standard MD5 CHAP and the remote access client/PNS wants to use MS-CHAP. The
PAC virtual template conguration needs to be examined. This is done using the show
running-cong command.
Example 3-23 PAC Tries Again, and Again
Jan 20 10:39:50.251 UTC: Vi1 LCP: O CONFREQ [REQsent] id 50 len 15
Jan 20 10:39:50.251 UTC: Vi1 LCP: AuthProto CHAP (0x0305C22305)
Jan 20 10:39:50.255 UTC: Vi1 LCP: MagicNumber 0xD094200D (0x0506D094200D)
Jan 20 10:39:50.255 UTC: Vi1 LCP: I CONFNAK [REQsent] id 50 len 9
Jan 20 10:39:50.255 UTC: Vi1 LCP: AuthProto MS-CHAP (0x0305C22380)
Jan 20 10:39:50.255 UTC: Vi1 LCP: O CONFREQ [REQsent] id 51 len 15
Jan 20 10:39:50.255 UTC: Vi1 LCP: AuthProto CHAP (0x0305C22305)
Jan 20 10:39:50.255 UTC: Vi1 LCP: MagicNumber 0xD094200D (0x0506D094200D)
Jan 20 10:39:50.255 UTC: Vi1 LCP: I CONFNAK [REQsent] id 51 len 9
Jan 20 10:39:50.255 UTC: Vi1 LCP: AuthProto MS-CHAP (0x0305C22380)
Jan 20 10:39:50.255 UTC: Vi1 LCP: O CONFREQ [REQsent] id 52 len 15
Jan 20 10:39:50.255 UTC: Vi1 LCP: AuthProto CHAP (0x0305C22305)
Jan 20 10:39:50.259 UTC: Vi1 LCP: MagicNumber 0xD094200D (0x0506D094200D)
Jan 20 10:39:50.259 UTC: Vi1 LCP: I CONFNAK [REQsent] id 52 len 9
Jan 20 10:39:50.259 UTC: Vi1 LCP: AuthProto MS-CHAP (0x0305C22380)
Jan 20 10:39:50.259 UTC: Vi1 LCP: O CONFREQ [REQsent] id 53 len 15
Jan 20 10:39:50.259 UTC: Vi1 LCP: AuthProto CHAP (0x0305C22305)
Jan 20 10:39:50.259 UTC: Vi1 LCP: MagicNumber 0xD094200D (0x0506D094200D)
Jan 20 10:39:50.259 UTC: Vi1 LCP: I CONFNAK [REQsent] id 53 len 9
Jan 20 10:39:50.259 UTC: Vi1 LCP: AuthProto MS-CHAP (0x0305C22380)
Example 3-24 PPP Phase Changes to DOWN
Jan 20 10:39:50.259 UTC: Vi1 LCP: Failed to negotiate with peer
Jan 20 10:39:50.259 UTC: Vi1 LCP: State is Closed
Jan 20 10:39:50.263 UTC: Vi1 PPP: Phase is DOWN [0 sess, 1 load]
Jan 20 10:39:50.263 UTC: Vi1 PPP: Phase is ESTABLISHING, Passive Open [0 sess, 1 load]
Jan 20 10:39:50.263 UTC: Vi1 LCP: State is Listen
Jan 20 10:39:52.263 UTC: Vi1 LCP: Missed link down notification
Jan 20 10:39:52.263 UTC: Vi1 LCP: State is Closed
Jan 20 10:39:52.263 UTC: Vi1 PPP: Phase is DOWN [0 sess, 1 load]
Arizona_PAC#
CH01i.book Page 174 Friday, April 30, 2004 8:58 AM
Troubleshooting PPTP 175
Example 3-25 shows the conguration of the virtual template on the PAC. Only the relevant
portion of the output is shown.
It is no surprise that the only authentication protocol congured on the virtual template interface
is CHAP. To resolve this, authentication protocols must be modied on either the remote access
client/PNS or PAC. In this case, the authentication protocol on the PAC is changed to support
MS-CHAPv1 (the remote access client supports MS-CHAP versions 1 and 2).
Example 3-26 shows the reconguration of the PPP authentication protocol on the virtual
template interface.
The remote access client/PNS now successfully connects to the PAC. This is veried using the
show vpdn tunnel all command, as shown in Example 3-27.
The output in Example 3-27 shows that the tunnel has been successfully established from a
remote access client/PNS with IP address 172.16.1.2 (highlighted line 1).
Example 3-25 Verifying the Configuration of the Virtual Template
Arizona_PAC#show running-config
!
interface Virtual-Template1
ip unnumbered Ethernet1/1
peer default ip address pool PPTPPool
ppp encrypt mppe 40 required
ppp authentication chap
!
Example 3-26 MS-CHAP Is Configured on the Virtual Template
Arizona_PAC#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Arizona_PAC(config)#interface virtual-template 1
Arizona_PAC(config-if)#ppp authentication ms-chap
Arizona_PAC(config-if)#exit
Arizona_PAC#
Example 3-27 Verifying PPTP Tunnel Status
Arizona_PAC#show vpdn tunnel all
%No active L2TP tunnels
%No active L2F tunnels
PPTP Tunnel Information Total tunnels 1 sessions 1
Tunnel id 18, 1 active sessions
Tunnel state is estabd, time since change 00:00:15
Remote tunnel name is
Internet Address 172.16.1.2, port 2089
Local tunnel name is Arizona_PAC
Internet Address 10.10.10.100, port 1723
14 packets sent, 42 received, 498 bytes sent, 3506 received
%No active PPPoE tunnels
Arizona_PAC#
CH01i.book Page 175 Friday, April 30, 2004 8:58 AM
176 Chapter 3: Troubleshooting Point-to-Point Tunneling Protocol VPNs
NOTE Note that one of two errors is reported by Microsoft remote access client/PNSs in the event of
an authentication protocol mismatch:
Error 734: The PPP link control protocol was terminated.
or
Error 691: The specified port is not connected.
If you would like to see PPP negotiation in detail on a Microsoft remote access client/PNS, you
can enable PPP logging. For more details on this, see Microsoft Knowledge Base article
234014, which is available at the Microsoft Web site (www.microsoft.com).
It is also worth noting here that another problem that can cause LCP negotiation failure is the
presence of an access list or rewall that blocks GRE (IP protocol 47). Remember that although
control connection and session setup are performed using a TCP connection, PPP packets are
tunneled between the remote access client/PNS and the PAC using GRE. LCP packets are the
rst PPP packets to be transported over this GRE tunnel.
Finally, if there is a NAT/PAT device between the PNS and the PAC ensure that it supports
PPTP. Cisco IOS supports one-to-one NAT translation for PPTP, as well as PPTP through PAT
in IOS 12.1(4)T.
PPP Authentication Failure
Once successful LCP negotiation has taken place, and assuming an authentication protocol was
negotiated, the next stage is PPP authentication.
Authentication failure is the result of a mismatch of the username, the password, or both
between the remote access client/PNS and the PAC (assuming local authentication).
Figure 3-30 shows the PPP authentication phase.
Figure 3-30 PPP Authentication Phase
LCP Negotiation
PPP Authentication
Control Channel Established (SCCRQ, SCCRP)
Session Setup (OCRQ, OCRP)
Remote Access
Client/PNS
(172.16.1.2) Arizona_PAC
(10.10.10.100)
Internet
User: mjlnet
CH01i.book Page 176 Friday, April 30, 2004 8:58 AM
Troubleshooting PPTP 177
In the following scenario, authentication fails on the PAC.
Before looking at an authentication failure, however, it is worthwhile to examine a successful
authentication sequence. The debug ppp negotiation command is used here to examine PPP
authentication. Note that the debug ppp authentication command can also be used for this
purpose.
Example 3-28 shows a successful authentication phase. Only the relevant portion of the output
is shown.
Highlighted line 1 shows that LCP negotiation has been completed (the LCP state is Open).
The PPP phase changes to AUTHENTICATING in highlighted line 2. Authentication is about
to begin.
A MS-CHAP challenge is then sent by the PAC to the remote access client/PNS in highlighted
line 3. Note that the PAC identies itself as Arizona_PAC.
After the MS-CHAP challenge has been sent to the remote access client/PNS, two Identication
options are received from the remote access client/PNS. These identify the RAS version (5.00)
and computer name (MLEWIS).
In highlighted line 4, a response message is received from the remote access client/PNS. The
username specied by the remote access client/PNS is visible in the message as mjlnet.
Finally, the PAC sends a MS-CHAP success message to the remote access client/PNS
(highlighted line 5) indicating that authentication has been successful.
Having seen a successful authentication sequence, it is now time to look at an unsuccessful
authentication sequence.
Example 3-29 shows an authentication failure.
Example 3-28 PPP Authentication Succeeds
Arizona_PAC#debug ppp negotiation
Jan 20 10:45:47.947 UTC: Vi1 LCP: State is Open
Jan 20 10:45:47.947 UTC: Vi1 PPP: Phase is AUTHENTICATING, by this end
[0 sess, 1 load]
Jan 20 10:45:47.947 UTC: Vi1 MS-CHAP: O CHALLENGE id 14 len 24 from "Arizona_PAC"
Jan 20 10:45:47.951 UTC: Vi1 LCP: I IDENTIFY [Open] id 3 len 18 magic 0x182F4EAA
MSRASV5.00
Jan 20 10:45:47.951 UTC: Vi1 LCP: I IDENTIFY [Open] id 4 len 25 magic 0x182F4EAA
MSRAS-1-MLEWIS
Jan 20 10:45:47.951 UTC: Vi1 MS-CHAP: I RESPONSE id 14 len 62 from "mjlnet"
Jan 20 10:45:47.967 UTC: Vi1 MS-CHAP: O SUCCESS id 14 len 4
Example 3-29 PPP Authentication Failure
Arizona_PAC#debug ppp negotiation
PPP protocol negotiation debugging is on
Arizona_PAC#
Jan 20 10:46:59.591 UTC: Vi1 LCP: State is Open
Jan 20 10:46:59.591 UTC: Vi1 PPP: Phase is AUTHENTICATING, by this end
CH01i.book Page 177 Friday, April 30, 2004 8:58 AM
178 Chapter 3: Troubleshooting Point-to-Point Tunneling Protocol VPNs
In highlighted line 1, the PPP phase changes to AUTHENTICATINGauthentication is about
to begin.
A MS-CHAP challenge message is sent to the remote access client/PNS in the second
highlighted line.
As before, two LCP messages are then received from the remote access client/PNS that identify
the RAS version and computer name.
An MS-CHAP response message is received from the remote access client/PNS (mjlnet,
highlighted line 3).
Immediately following this, in highlighted line 4, the PAC sends a MS-CHAP failure message
to the remote access client/PNS.
In highlighted line 5, the PAC initiates termination of the connection using a Terminate-Request
(TERMREQ) message, and in highlighted line 6, the remote access client/PNS acknowledges
this with a Terminate-Ack (TERMACK) message.
Finally, the PPP phase changes state to DOWN in highlighted line 7.
As previously described, authentication failure can be caused by a mismatched username, password,
or both. In this case, the user conrms that the correct username and password are being used on the
remote access client/PNS, and, therefore, the only possibility is that either the username or the
password is incorrectly congured on the PAC. This is corrected as shown in Example 3-30.
[0 sess, 1 load]
Jan 20 10:46:59.591 UTC: Vi1 MS-CHAP: O CHALLENGE id 15 len 24 from "Arizona_PAC"
Jan 20 10:46:59.595 UTC: Vi1 LCP: I IDENTIFY [Open] id 3 len 18 magic 0x2A134EF8
MSRASV5.00
Jan 20 10:46:59.595 UTC: Vi1 LCP: I IDENTIFY [Open] id 4 len 25 magic 0x2A134EF8
MSRAS-1-MLEWIS
Jan 20 10:46:59.595 UTC: Vi1 MS-CHAP: I RESPONSE id 15 len 62 from "mjlnet"
Jan 20 10:46:59.615 UTC: Vi1 MS-CHAP: O FAILURE id 15 len 25 msg is
"MD/DES compare failed"
Jan 20 10:46:59.615 UTC: Vi1 PPP: Phase is TERMINATING [0 sess, 2 load]
Jan 20 10:46:59.615 UTC: Vi1 LCP: O TERMREQ [Open] id 60 len 4
Jan 20 10:46:59.623 UTC: Vi1 LCP: I TERMACK [TERMsent] id 60 len 4
Jan 20 10:46:59.623 UTC: Vi1 LCP: State is Closed
Jan 20 10:46:59.623 UTC: Vi1 PPP: Phase is DOWN [0 sess, 2 load]
Jan 20 10:46:59.623 UTC: Vi1 PPP: Phase is ESTABLISHING, Passive Open [0 sess, 2 load]
Jan 20 10:46:59.623 UTC: Vi1 LCP: State is Listen
Jan 20 10:47:01.623 UTC: Vi1 LCP: Missed link down notification
Jan 20 10:47:01.623 UTC: Vi1 LCP: State is Closed
Jan 20 10:47:01.623 UTC: Vi1 PPP: Phase is DOWN [0 sess, 2 load]
Arizona_PAC#
Example 3-29 PPP Authentication Failure (Continued)
CH01i.book Page 178 Friday, April 30, 2004 8:58 AM
Troubleshooting PPTP 179
Once the username and password is recongured correctly, the remote access client/PNS
reconnects and authentication succeeds. This is veried using the show vpdn session all
command, as shown in Example 3-31.
Note that there is now one PPTP tunnel with one session within it (highlighted line 1).
In highlighted line 2, the address of the remote access client/PNS is shown to be 172.16.1.2,
and nally in highlighted line 3, the username mjlnet can be seen.
NOTE Note that the error reported by Microsoft remote access client/PNSs in the event of an
authentication failure is as follows:
Error 691: Access was denied because the username and/or password was invalid in
the domain.
It is also worth remembering that if the Windows client is using MS-CHAP, it may send the
username to the PAC in the format DOMAIN\username. If the PAC is not congured to
recognize this username format, authentication will fail.
If you are using remote AAA, ensure that the AAA server is reachable and that the key is
correctly specied on both the PAC and the AAA server. Also ensure that the user password is
correctly congured.
Example 3-30 Reconfiguration of the Remote Access Clients Username and Password
Arizona_PAC#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Arizona_PAC(config)#username mjlnet password cisco
Arizona_PAC(config)#exit
Arizona_PAC#
Example 3-31 Verifying PPTP Session Setup
Arizona_PAC#show vpdn session all
%No active L2TP tunnels
%No active L2F tunnels
PPTP Session Information Total tunnels 1 sessions 1
Call id 26 is up on tunnel id 26
Remote tunnel name is
Internet Address is 172.16.1.2
Session username is mjlnet, state is estabd
Time since change 00:00:15, interface Vi1
Remote call id is 32768
14 packets sent, 43 received, 498 bytes sent, 3722 received
Ss 15, Sr 43, Remote Nr 14, peer RWS 64
0 out of order packets
Flow alarm is clear.
%No active PPPoE tunnels
Arizona_PAC#
CH01i.book Page 179 Friday, April 30, 2004 8:58 AM
180 Chapter 3: Troubleshooting Point-to-Point Tunneling Protocol VPNs
Finally, if you are using a RADIUS server, ensure that attribute type 6 (Service-Type) is
congured as Framed, and that attribute type 7 (Framed-Protocol) is congured as PPP in
settings associated with the user account. These can be found under group setup if you are using
Cisco Secure ACS.
NCP Negotiation Failure
Once PPP authentication has succeeded, NCP negotiation can begin. During this phase,
protocols such as the Compression Control Protocol (CCP), the IP Control Protocol (IPCP), and
IPX Control Protocol (IPXCP) are negotiated.
Microsoft Point-to-Point Encryption (MPPE) is often used to encrypt PPTP tunnel trafc.
MPPE is negotiated via the CCP. A number of MPPE conguration options are available, so
careful attention must be paid to avoid problems.
Figure 3-31 illustrates NCP negotiation.
Figure 3-31 NCP Negotiation
MPPE Negotiation Failure
MPPE negotiation can fail in a number of different ways:
When using MPPE, MS-CHAP must also be congured, or negotiation will fail.
Either 40-bit or 128-bit encryption is possible, and the remote access client/PNS and the
PAC must agree on this.
Either the remote access client/PNS or the PAC can be congured to require encryption,
and if the peer system is not congured for MPPE, negotiation failure will result.
LCP Negotiation
PPP Authentication
NCP Negotiation
Control Channel Established (SCCRQ, SCCRP)
Session Setup (OCRQ, OCRP)
Remote Access
Client/PNS
(172.16.1.2) Arizona_PAC
(10.10.10.100)
Internet
User: mjlnet
CH01i.book Page 180 Friday, April 30, 2004 8:58 AM
Troubleshooting PPTP 181
As previously mentioned, one way in which tunnel establishment can fail is if MPPE is
congured, but MS-CHAP is not specied as the authentication protocol.
Before taking a look at MPPE negotiation failure, it is useful to have a look at MPPE
negotiation when it is successful, using the debug ppp negotiation command.
Examples 3-32 to 3-36 show a successful MPPE negotiation sequence. Only the relevant
portion of the output is shown.
As you can see, in highlighted line 1, the LCP state is Open, indicating that LCP negotiation
has completed successfully.
Immediately after this, the PPP phase changes to AUTHENTICATING (highlighted line 2),
and authentication begins.
In highlighted line 3, the PAC sends a MS-CHAP challenge to the remote access client/PNS.
The PACs hostname is identiable as Arizona_PAC.
A MS-CHAP response message is received from the remote access client/PNS (username
mjlnet) in highlighted line 4.
The PAC then sends a MS-CHAP success message to the remote access client/PNS (highlighted
line 4). MS-CHAP authentication has succeeded.
NCP negotiation now begins, as shown in Example 3-33.
In highlighted line 1 (Example 3-33), the PPP phase changes to UP, and NCP negotiation
begins.
Example 3-32 Successful MPPE Negotiation
Arizona_PAC#debug ppp negotiation
Jan 21 20:51:03.823 UTC: Vi1 LCP: State is Open
Jan 21 20:51:03.823 UTC: Vi1 PPP: Phase is AUTHENTICATING, by this end
[0 sess, 1 load]
Jan 21 20:51:03.823 UTC: Vi1 MS-CHAP: O CHALLENGE id 4 len 24 from "Arizona_PAC"
Jan 21 20:51:03.827 UTC: Vi1 LCP: I IDENTIFY [Open] id 3 len 18 magic 0x6BAF1C08
MSRASV5.00
Jan 21 20:51:03.827 UTC: Vi1 LCP: I IDENTIFY [Open] id 4 len 25 magic 0x6BAF1C08
MSRAS-1-MLEWIS
Jan 21 20:51:06.823 UTC: Vi1 PPP: Replace CHAP code 2 id 4 with id 4
Jan 21 20:51:06.823 UTC: Vi1 MS-CHAP: I RESPONSE id 4 len 62 from "mjlnet"
Jan 21 20:51:06.843 UTC: Vi1 MS-CHAP: O SUCCESS id 4 len 4
Example 3-33 NCP (Including CCP) Negotiation Begins
Jan 21 20:51:06.843 UTC: Vi1 PPP: Phase is UP [0 sess, 1 load]
Jan 21 20:51:06.843 UTC: Vi1 IPCP: O CONFREQ [Not negotiated] id 4 len 10
Jan 21 20:51:06.843 UTC: Vi1 IPCP: Address 192.168.1.1 (0x0306C0A80101)
Jan 21 20:51:06.843 UTC: Vi1 CCP: O CONFREQ [Not negotiated] id 4 len 10
Jan 21 20:51:06.843 UTC: Vi1 CCP: MS-PPC supported bits 0x01000020 (0x120601000020)
CH01i.book Page 181 Friday, April 30, 2004 8:58 AM
182 Chapter 3: Troubleshooting Point-to-Point Tunneling Protocol VPNs
The PAC sends a CONFREQ to the remote access client/PNS specifying Microsoft Point-to-
Point Compression (MS-PPC) in highlighted line 2. This is signicant because MPPE is a
suboption of MS-PPC.
Have a close look at the supported bits specied in this CONFREQ: 0x01000020. Here the PAC
is specifying that it supports stateless encryption (indicated by the most signicant octet, 0x01),
and that it also supports 40-bit MPPE session keys (least signicant octet, 0x20). Note that
stateless encryption means that session keys are calculated on a packet-by-packet basis.
Before continuing, it is worth briey examining the MS-PPC supported bits.
Figure 3-32 illustrates the supported bits format.
Figure 3-32 MS-PPC Supported Bits
The supported bits eld is four octets in length. Only the H (rst octet), M, S, L, D, and C (least
signicant octet) bits have any meaning.
The H bit indicates support for stateless encryption. The M bit indicates support for 56-bit
session keys, the S bit support for 128-bit session keys, and the L bit support for 40-bit session
keys. The D bit is obsolete, and the C bit indicates support for MS-PPC.
The supported bit values can be easily calculated using binary to hexadecimal conversion.
Should the PAC be congured to support both 40-bit and 128-bit session keys, the least
signicant octet would have a value of 0x60. If only 128-bit encryption was supported, the
value would be 0x40. These values assume that no support for MS-PPC is specied.
Now back to the debug output in Example 3-34 (continued from Example 3-33).
Example 3-34 CCP Negotiation Continues
Jan 21 20:51:06.851 UTC: Vi1 CCP: I CONFREQ [REQsent] id 5 len 10
Jan 21 20:51:06.851 UTC: Vi1 CCP: MS-PPC supported bits 0x01000001 (0x120601000001)
Jan 21 20:51:06.851 UTC: Vi1 CCP: O CONFNAK [REQsent] id 5 len 10
Jan 21 20:51:06.851 UTC: Vi1 CCP: MS-PPC supported bits 0x01000020 (0x120601000020)
Jan 21 20:51:06.851 UTC: Vi1 IPCP: I CONFREQ [REQsent] id 6 len 34
Jan 21 20:51:06.851 UTC: Vi1 IPCP: Address 0.0.0.0 (0x030600000000)
Jan 21 20:51:06.851 UTC: Vi1 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000)
Jan 21 20:51:06.851 UTC: Vi1 IPCP: PrimaryWINS 0.0.0.0 (0x820600000000)
Jan 21 20:51:06.851 UTC: Vi1 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000)
Jan 21 20:51:06.851 UTC: Vi1 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000)
Jan 21 20:51:06.851 UTC: Vi1 IPCP: Pool returned 192.168.2.1
Jan 21 20:51:06.851 UTC: Vi1 IPCP: O CONFREJ [REQsent] id 6 len 16
Jan 21 20:51:06.851 UTC: Vi1 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000)
Jan 21 20:51:06.851 UTC: Vi1 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000)
Jan 21 20:51:06.851 UTC: Vi1 IPCP: I CONFACK [REQsent] id 4 len 10
Jan 21 20:51:06.851 UTC: Vi1 IPCP: Address 192.168.1.1 (0x0306C0A80101)
1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
H C M S L D
3 2 1
CH01i.book Page 182 Friday, April 30, 2004 8:58 AM
Troubleshooting PPTP 183
In highlighted line 1 (Example 3-34), the remote access client/PNS sends a CONFREQ to the
PAC. Once again, MS-PPC is specied, and the supported bits are 01000001. This indicates
support for stateless encryption and MS-PPC. Note that no session key lengths (40, 56 , 128)
are specied.
The PAC then sends a CONFNACK in highlighted line 2, which again species stateless
encryption and 40-bit session key support.
A CCP CONFACK and CONFREQ are now received from the remote access client/PNS, as
demonstrated in Example 3-35.
In highlighted line 1 (Example 3-35), a CONFACK is received from the remote access client/
PNS acknowledging support for stateless encryption and 40-bit session keys. This is followed,
in highlighted line 2, by a CONFREQ, which requests conguration of the same.
In Example 3-36, CCP negotiation succeeds.
The PAC now sends a CONFACK to the remote access client/PNS acknowledging conguration
of stateless encryption and 40-bit session keys (highlighted line 1, Example 3-36).
In highlighted line 2, the CCP state changes to Open. MPPE encryption has been successfully
negotiated.
Having seen successful MPPE negotiation, it is now time to have a look at what happens when
MPPE negotiation fails.
As previously mentioned, if MS-CHAP authentication is not specied, MPPE negotiation will
fail. The output of the debug ppp negotiation command in Examples 3-37 to 3-41 show what
happens if MS-CHAP authentication is not specied. Once again, for the sake of clarity, only
the relevant section of the output is shown.
Example 3-35 Inbound CCP CONFACK and CONFREQ
Jan 21 20:51:06.851 UTC: Vi1 CCP: I CONFACK [REQsent] id 4 len 10
Jan 21 20:51:06.851 UTC: Vi1 CCP: MS-PPC supported bits 0x01000020 (0x120601000020)
Jan 21 20:51:06.855 UTC: Vi1 CCP: I CONFREQ [ACKrcvd] id 7 len 10
Jan 21 20:51:06.855 UTC: Vi1 CCP: MS-PPC supported bits 0x01000020 (0x120601000020)
Example 3-36 CCP Negotiation Succeeds
Jan 21 20:51:06.855 UTC: Vi1 CCP: O CONFACK [ACKrcvd] id 7 len 10
Jan 21 20:51:06.855 UTC: Vi1 CCP: MS-PPC supported bits 0x01000020 (0x120601000020)
Jan 21 20:51:06.855 UTC: Vi1 CCP: State is Open
Arizona_PAC#
Example 3-37 MPPE Negotiation Fails
Arizona_PAC#debug ppp negotiation
Jan 21 20:52:38.571 UTC: Vi1 LCP: State is Open
Jan 21 20:52:38.571 UTC: Vi1 PPP: Phase is AUTHENTICATING, by this end
[0 sess, 1 load]
Jan 21 20:52:38.571 UTC: Vi1 CHAP: O CHALLENGE id 5 len 32 from "Arizona_PAC"
CH01i.book Page 183 Friday, April 30, 2004 8:58 AM
184 Chapter 3: Troubleshooting Point-to-Point Tunneling Protocol VPNs
In highlighted line 1, the LCP state changes to Open. This indicates successful LCP negotiation.
The PPP phase changes to AUTHENTICATING in highlighted line 2.
A CHAP challenge is then sent to the remote access client/PNS in highlighted line 3. A
response is received (highlighted line 4), and in highlighted line 5, a success message is sent to
the remote access client/PNS. Authentication has succeeded.
NCP negotiation begins in Example 3-38.
The PPP phase changes to UP in highlighted line 1 (Example 3-38). NCP negotiation is about
to begin.
A CCP CONFREQ is sent to the remote access client/PNS in highlighted line 2. This seems
good, but a close examination reveals that no options (MS-PPC) are sent with it (notice that the
length [len] is only four octets). Theres something funny going on here.
CCP negotiation continues in Example 3-39.
Jan 21 20:52:38.575 UTC: Vi1 LCP: I IDENTIFY [Open] id 3 len 18 magic 0x244B5803
MSRASV5.00
Jan 21 20:52:38.575 UTC: Vi1 LCP: I IDENTIFY [Open] id 4 len 25 magic 0x244B5803
MSRAS-1-MLEWIS
Jan 21 20:52:38.575 UTC: Vi1 CHAP: I RESPONSE id 5 len 29 from "mjlnet"
Jan 21 20:52:38.575 UTC: Vi1 CHAP: O SUCCESS id 5 len 4
Example 3-38 NCP (Including CCP) Negotiation Begins
Jan 21 20:52:38.575 UTC: Vi1 PPP: Phase is UP [0 sess, 1 load]
Jan 21 20:52:38.575 UTC: Vi1 IPCP: O CONFREQ [Not negotiated] id 5 len 10
Jan 21 20:52:38.575 UTC: Vi1 IPCP: Address 192.168.1.1 (0x0306C0A80101)
Jan 21 20:52:38.575 UTC: Vi1 CCP: O CONFREQ [Closed] id 5 len 4
Example 3-39 CCP Negotiation Continues
Jan 21 20:52:38.579 UTC: Vi1 CCP: I CONFREQ [REQsent] id 5 len 10
Jan 21 20:52:38.579 UTC: Vi1 CCP: MS-PPC supported bits 0x01000001 (0x120601000001)
Jan 21 20:52:38.583 UTC: Vi1 CCP: O CONFNAK [REQsent] id 5 len 10
Jan 21 20:52:38.583 UTC: Vi1 CCP: MS-PPC supported bits 0x01000020 (0x120601000020)
Jan 21 20:52:38.583 UTC: Vi1 IPCP: I CONFREQ [REQsent] id 6 len 34
Jan 21 20:52:38.583 UTC: Vi1 IPCP: Address 0.0.0.0 (0x030600000000)
Jan 21 20:52:38.583 UTC: Vi1 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000)
Jan 21 20:52:38.583 UTC: Vi1 IPCP: PrimaryWINS 0.0.0.0 (0x820600000000)
Jan 21 20:52:38.583 UTC: Vi1 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000)
Jan 21 20:52:38.583 UTC: Vi1 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000)
Jan 21 20:52:38.583 UTC: Vi1 IPCP: Pool returned 192.168.2.1
Jan 21 20:52:38.583 UTC: Vi1 IPCP: O CONFREJ [REQsent] id 6 len 16
Jan 21 20:52:38.583 UTC: Vi1 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000)
Jan 21 20:52:38.583 UTC: Vi1 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000)
Jan 21 20:52:38.583 UTC: Vi1 IPCP: I CONFACK [REQsent] id 5 len 10
Jan 21 20:52:38.583 UTC: Vi1 IPCP: Address 192.168.1.1 (0x0306C0A80101)
Example 3-37 MPPE Negotiation Fails (Continued)
CH01i.book Page 184 Friday, April 30, 2004 8:58 AM
Troubleshooting PPTP 185
In highlighted line 1 (Example 3-39), a CCP CONFREQ is received from the remote access
client/PNS. In it, MS-PPC is specied, with supported bits 0x01000001. If you refer back to the
previous description of supported bits, you will see that this indicates support for stateless
encryption and MS-PPC itself but does not specify any session key length.
The PAC then sends a CCP CONFNACK to the remote access client/PNS (highlighted line 2).
In it, supported bits 0x010000020 are specied (stateless encryption and 40-bit session keys).
MPPE negotiation now fails, as shown in Example 3-40.
In Example 3-40, the PAC receives a CCP CONFACK from the remote access client/PNS
(highlighted line 1), but again, there are no options specied. In highlighted line 2, another CCP
CONFREQ is received from the remote access client/PNS. Once again, no options are
specied. The PAC then responds with a CCP CONFACK (highlighted line 3). This species
no options either. This denitely does not look like a healthy MPPE negotiation exchange.
In highlighted line 4, the message Jan 21 20:52:38.587 UTC: Vi1 MPPE: Required
encryption not negotiated reveals that MPPE has not been negotiated, and in highlighted line
5, the CCP state changes to Closed.
In Example 3-41, PPP negotiation is terminated.
The PPP phase now changes to TERMINATING (highlighted line 1, Example 3-41).
Then in highlighted line 2, the PAC sends a Terminate-Request (TERMREQ) to the remote
access client/PNS, and in highlighted line 3, the PPP phase changes to DOWN. PPP negotiation
has been unsuccessful.
Example 3-40 MPPE Negotiation Fails
Jan 21 20:52:38.583 UTC: Vi1 CCP: I CONFACK [REQsent] id 5 len 4
Jan 21 20:52:38.583 UTC: Vi1 CCP: I CONFREQ [ACKrcvd] id 7 len 4
Jan 21 20:52:38.587 UTC: Vi1 CCP: O CONFACK [ACKrcvd] id 7 len 4
Jan 21 20:52:38.587 UTC: Vi1 CCP: State is Open
Jan 21 20:52:38.587 UTC: Vi1 MPPE: Required encryption not negotiated
Jan 21 20:52:38.587 UTC: Vi1 IPCP: State is Closed
Jan 21 20:52:38.587 UTC: Vi1 CCP: State is Closed
Jan 21 20:52:38.587 UTC: Vi1 MPPE: Required encryption not negotiated
Example 3-41 PPP Negotiation Is Terminated
Jan 21 20:52:38.587 UTC: Vi1 PPP: Phase is TERMINATING [0 sess, 2 load]
Jan 21 20:52:38.587 UTC: Vi1 LCP: O TERMREQ [Open] id 23 len 4
Jan 21 20:52:38.587 UTC: Vi1 LCP: State is Closed
Jan 21 20:52:38.587 UTC: Vi1 PPP: Phase is DOWN [0 sess, 2 load]
Jan 21 20:52:38.587 UTC: Vi1 PPP: Phase is ESTABLISHING, Passive Open [0 sess, 2 load]
Jan 21 20:52:38.587 UTC: Vi1 LCP: State is Listen
Jan 21 20:52:40.587 UTC: Vi1 LCP: Missed link down notification
Jan 21 20:52:40.587 UTC: Vi1 LCP: State is Closed
Jan 21 20:52:40.587 UTC: Vi1 PPP: Phase is DOWN [0 sess, 2 load]
Arizona_PAC#
CH01i.book Page 185 Friday, April 30, 2004 8:58 AM
186 Chapter 3: Troubleshooting Point-to-Point Tunneling Protocol VPNs
What went wrong? A close look at highlighted lines 3, 4, and 5 all the way back in Example
3-37 reveals that the authentication protocol in use is regular MD-5 CHAP, not the MS-CHAP
essential for successful MPPE negotiation.
The remote access client/PNS user conrms that MS-CHAP is specied as an authentication
protocol on the remote access client/PNS. This leaves only one possibility: MS-CHAP is not
specied as an authentication protocol on the PAC. You can conrm the authentication protocol
that is congured using the show running-cong command.
Example 3-42 shows the conguration of the virtual template interface.
As you can see from the conguration, only standard MD5 CHAP is specied, not MS-CHAP.
The conguration is then modied to allow MS-CHAP authentication.
Example 3-43 shows the reconguration of authentication protocols on the virtual template
interface.
The remote access client/PNS then successfully reconnects.
Successful PPTP session establishment is veried using the show vpdn session all command,
as shown in Example 3-44.
Example 3-42 Virtual Template Configuration
Arizona_PAC#show running-config
!
interface Virtual-Template1
ip unnumbered Ethernet1/1
peer default ip address pool PPTPPool
ppp encrypt mppe 40 required
ppp authentication chap
!
Example 3-43 MS-CHAP Authentication Is Configured on the Virtual Template
Arizona_PAC#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Arizona_PAC(config)#interface virtual-template 1
Arizona_PAC(config-if)#ppp authentication ms-chap
Arizona_PAC(config-if)#exit
Arizona_PAC#
Example 3-44 Verifying PPTP Session Establishment
Arizona_PAC#show vpdn session all
%No active L2TP tunnels
%No active L2F tunnels
PPTP Session Information Total tunnels 1 sessions 1
Call id 9 is up on tunnel id 9
Remote tunnel name is
Internet Address is 172.16.1.2
Session username is mjlnet, state is estabd
CH01i.book Page 186 Friday, April 30, 2004 8:58 AM
Troubleshooting PPTP 187
In highlighted line 1, you can see that one PPTP tunnel and one session have been successfully
established.
Then in highlighted lines 2 and 3, you can see the IP address (172.16.1.2) and username
(mjlnet) of the remote access client/PNS.
Note that the error reported by Microsoft remote access client/PNSs in the event of a MPPE
failure due to the lack of MS-CHAP authentication is as follows:
Error 619: The specified port is not connected.
As previously noted, if the required keyword is specied with the ppp encrypt mppe
command under the virtual template, and MPPE encryption is not congured on the remote
access client/PNS, MPPE negotiation will also fail. In this case, the error reported by Microsoft
(Windows 2000) client/PNSs will again be:
Error 619: The specified port is not connected.
If a Microsoft remote access client/PNS is congured to require data encryption (the Require
data encryption box is checked under the Security tab of the Network/Dial-Up connection
conguration in Windows 2000), but the PAC is not congured for MPPE, MPPE negotiation
will fail. The error seen on the remote access client will be as follows:
Error 742: The remote computer does not support the required data encryption type.
Finally, if you are using remote AAA, also see Case Study 1: MPPE Attributes Are Not
Returned from the RADIUS Server.
IPCP Negotiation Failure
Once LCP negotiation and authentication have taken place, the IPCP can be negotiated.
Two common reasons for IPCP negotiation failure are:
No IP address has been congured on the virtual template interface associated with the
PPTP VPDN group.
No IP address is supplied by the PAC to the remote access client/PNS.
Time since change 00:00:15, interface Vi1
Remote call id is 49152
14 packets sent, 39 received, 498 bytes sent, 3194 received
Ss 15, Sr 39, Remote Nr 14, peer RWS 64
0 out of order packets
Flow alarm is clear.
%No active PPPoE tunnels
Arizona_PAC#
Example 3-44 Verifying PPTP Session Establishment (Continued)
CH01i.book Page 187 Friday, April 30, 2004 8:58 AM
188 Chapter 3: Troubleshooting Point-to-Point Tunneling Protocol VPNs
Before examining what happens when IPCP negotiation is unsuccessful, it is useful to rst have
a look at a successful IPCP negotiation sequence.
Use the debug ppp negotiation command to examine IPCP negotiation as shown in Examples
3-45 to 3-53. Only the relevant output is shown.
In highlighted line 1, the PPP phase changes to UP. NCP negotiation is about to begin.
In highlighted line 2, the PAC sends a CONFREQ including IPCP option 0x03 (IP-Address).
This is used to specify the PACs own IP address (192.16.1.1).
The remote access client/PNS now sends a CONFREQ as shown in Example 3-46.
In Example 3-46, the PAC receives a CONFREQ from the remote access client/PNS (highlighted
line 1). This CONFREQ includes Address, Primary DNS, Primary WINS, Secondary DNS, and
Secondary WINS IPCP options (0x03, 0x81, 0x82, 0x83, and 0x84, respectively).
Note that all of these options specify a 0.0.0.0 address. This is used by the remote access client/
PNS to indicate to the PAC that these addresses should be supplied.
In highlighted line 2, the PAC obtains an IP address (for the remote access client/PNS) from the
IP address pool.
The PAC then sends a CONFREJ to the remote access client/PNS rejecting usage of the
Secondary DNS and Secondary WINS options, as shown in Example 3-47. This is because, in
this example, the PAC is not congured to supply these options.
Example 3-45 Successful IPCP Negotiation
Arizona_PAC#debug ppp negotiation
Arizona_PAC#
Jan 20 10:37:13.479 UTC: Vi1 PPP: Phase is UP [0 sess, 1 load]
Jan 20 10:37:13.479 UTC: Vi1 IPCP: O CONFREQ [Not negotiated] id 12 len 10
Jan 20 10:37:13.479 UTC: Vi1 IPCP: Address 192.168.1.1 (0x0306C0A80101)
Jan 20 10:37:13.479 UTC: Vi1 CCP: O CONFREQ [Not negotiated] id 4 len 10
Jan 20 10:37:13.479 UTC: Vi1 CCP: MS-PPC supported bits 0x01000020 (0x120601000020)
Jan 20 10:37:13.483 UTC: Vi1 CCP: I CONFREQ [REQsent] id 5 len 10
Jan 20 10:37:13.483 UTC: Vi1 CCP: MS-PPC supported bits 0x010000B1 (0x1206010000B1)
Jan 20 10:37:13.483 UTC: Vi1 CCP: O CONFNAK [REQsent] id 5 len 10
Jan 20 10:37:13.483 UTC: Vi1 CCP: MS-PPC supported bits 0x01000020 (0x120601000020)
Example 3-46 Remote Access Client Sends a CONFREQ and an IP Address Is Obtained
Jan 20 10:37:13.483 UTC: Vi1 IPCP: I CONFREQ [REQsent] id 6 len 34
Jan 20 10:37:13.483 UTC: Vi1 IPCP: Address 0.0.0.0 (0x030600000000)
Jan 20 10:37:13.483 UTC: Vi1 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000)
Jan 20 10:37:13.483 UTC: Vi1 IPCP: PrimaryWINS 0.0.0.0 (0x820600000000)
Jan 20 10:37:13.487 UTC: Vi1 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000)
Jan 20 10:37:13.487 UTC: Vi1 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000)
Jan 20 10:37:13.487 UTC: Vi1 IPCP: Pool returned 192.168.2.1
CH01i.book Page 188 Friday, April 30, 2004 8:58 AM
Troubleshooting PPTP 189
In Example 3-48, the remote access client/PNS acknowledges the PACs IP address by sending
a CONFACK. Note that the ID (12) of this CONFACK is the same as the ID specied in the
CONFREQ sent by the PAC in Example 3-45.
In Example 3-49, the remote access client/PNS sends another CONFREQ message with the IP
Address, Primary DNS Server, and Primary WINS Server options specied (all other options
in the last IPCP CONFREQ having been rejected by the PAC in Example 3-47). Again, these
addresses are specied as 0.0.0.0 to indicate to the PAC that these options should be supplied.
The PAC then responds by sending a CONFNACK message to the remote access client/PNS,
as shown in Example 3-50. Included are the IP address obtained from the IP pool in Example
3-46, as well as DNS server and WINS server addresses requested by the remote access client/
PNS in Example 3-49.
In Example 3-51, the remote access client/PNS sends a third CONFREQ message to the PAC.
Included in the CONFREQ are the addresses previously supplied by the PAC in Example 3-50.
Example 3-47 PAC Rejects Configuration of Secondary DNS and WINS Servers
Jan 20 10:37:13.487 UTC: Vi1 IPCP: O CONFREJ [REQsent] id 6 len 16
Jan 20 10:37:13.487 UTC: Vi1 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000)
Jan 20 10:37:13.487 UTC: Vi1 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000)
Example 3-48 Remote Access Client Acknowledges the PACs IP Address
Jan 20 10:37:13.487 UTC: Vi1 IPCP: I CONFACK [REQsent] id 12 len 10
Jan 20 10:37:13.487 UTC: Vi1 IPCP: Address 192.168.1.1 (0x0306C0A80101)
Jan 20 10:37:13.487 UTC: Vi1 CCP: I CONFACK [REQsent] id 4 len 10
Jan 20 10:37:13.487 UTC: Vi1 CCP: MS-PPC supported bits 0x01000020 (0x120601000020)
Jan 20 10:37:13.487 UTC: Vi1 CCP: I CONFREQ [ACKrcvd] id 7 len 10
Jan 20 10:37:13.487 UTC: Vi1 CCP: MS-PPC supported bits 0x01000020 (0x120601000020)
Jan 20 10:37:13.487 UTC: Vi1 CCP: O CONFACK [ACKrcvd] id 7 len 10
Jan 20 10:37:13.487 UTC: Vi1 CCP: MS-PPC supported bits 0x01000020 (0x120601000020)
Jan 20 10:37:13.487 UTC: Vi1 CCP: State is Open
Example 3-49 Remote Access Client/PNS Sends Another CONFREQ
Jan 20 10:37:13.491 UTC: Vi1 IPCP: I CONFREQ [ACKrcvd] id 8 len 22
Jan 20 10:37:13.491 UTC: Vi1 IPCP: Address 0.0.0.0 (0x030600000000)
Jan 20 10:37:13.491 UTC: Vi1 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000)
Jan 20 10:37:13.491 UTC: Vi1 IPCP: PrimaryWINS 0.0.0.0 (0x820600000000)
Example 3-50 PAC Supplies an IP Address and DNS and WINS Server Addresses
Jan 20 10:37:13.491 UTC: Vi1 IPCP: O CONFNAK [ACKrcvd] id 8 len 22
Jan 20 10:37:13.491 UTC: Vi1 IPCP: Address 192.168.2.1 (0x0306C0A80201)
Jan 20 10:37:13.491 UTC: Vi1 IPCP: PrimaryDNS 192.168.1.10 (0x8106C0A8010A)
Jan 20 10:37:13.491 UTC: Vi1 IPCP: PrimaryWINS 192.168.1.12 (0x8206C0A8010C)
CH01i.book Page 189 Friday, April 30, 2004 8:58 AM
190 Chapter 3: Troubleshooting Point-to-Point Tunneling Protocol VPNs
The PAC then acknowledges the remote access client/PNSs CONFREQ in Example 3-51 by
sending a CONFACK, as shown in Example 3-52.
In Example 3-53, the IPCP negotiation succeeds.
In highlighted line 1 (Example 3-53), the IPCP state changes to Open, indicating that IPCP
negotiation has succeeded.
A host route to the remote access client/PNS (192.168.2.1) is installed (highlighted line 2), and
the line protocol on virtual access interface 1 changes state to up (highlighted line 3).
IPCP Negotiation Fails Because of a Missing IP Address on the Virtual
Template Interface
As mentioned previously, one possible reason for IPCP negotiation failure is the lack of an IP
address on the virtual template interface. Again, because IPCP negotiation forms part of the
overall PPP negotiation sequence, the debug ppp negotiation command can be used to
examine this issue.
Examples 3-54 to 3-56 show the failure of IPCP negotiation between the remote access client/
PNS and PAC. Only the relevant output is shown.
In highlighted line 1, the PPP phase changes to UP. NCP negotiation is about to begin.
Example 3-51 Remote Access Client Sends a Third CONFREQ
Jan 20 10:37:13.495 UTC: Vi1 IPCP: I CONFREQ [ACKrcvd] id 9 len 22
Jan 20 10:37:13.495 UTC: Vi1 IPCP: Address 192.168.2.1 (0x0306C0A80201)
Jan 20 10:37:13.495 UTC: Vi1 IPCP: PrimaryDNS 192.168.1.10 (0x8106C0A8010A)
Jan 20 10:37:13.495 UTC: Vi1 IPCP: PrimaryWINS 192.168.1.12 (0x8206C0A8010C)
Example 3-52 PAC Acknowledges the Remote Access Client/PNSs CONFREQ
Jan 20 10:37:13.495 UTC: Vi1 IPCP: O CONFACK [ACKrcvd] id 9 len 22
Jan 20 10:37:13.495 UTC: Vi1 IPCP: Address 192.168.2.1 (0x0306C0A80201)
Jan 20 10:37:13.495 UTC: Vi1 IPCP: PrimaryDNS 192.168.1.10 (0x8106C0A8010A)
Jan 20 10:37:13.495 UTC: Vi1 IPCP: PrimaryWINS 192.168.1.12 (0x8206C0A8010C)
Example 3-53 IPCP State Changes to Open, and the Interface Changes State to Up
Jan 20 10:37:13.495 UTC: Vi1 IPCP: State is Open
Jan 20 10:37:13.495 UTC: Vi1 IPCP: Install route to 192.168.2.1
Jan 20 10:37:14.479 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Virtual-Access1, changed state to up
Arizona_PAC#
CH01i.book Page 190 Friday, April 30, 2004 8:58 AM
Troubleshooting PPTP 191
In highlighted line 2, IPCP negotiation begins with the remote access client/PNS sending a
CONFREQ to the PAC. This CONFREQ species the IP address (option 0x03), Primary DNS
address (option 0x81), Primary NetBIOS Name Server address (NBNS or WINS server
address, option 0x82), Secondary DNS server address (option 0x83), and nally Secondary
NBNS Server address (option 0x84).
All the options are specied as 0.0.0.0. This is an indication to the PAC that it should supply
these addresses.
Signicantly, however, the PAC now sends a Protocol-Reject (PROTREJ) message to the
remote access client/PNS indicating that the PAC does not understand or support IPCP. This
PROTREJ message is shown in Example 3-55.
Example 3-54 IPCP Negotiation Fails
Arizona_PAC#debug ppp negotiation
Arizona_PAC#
Jan 20 22:35:27.779 UTC: Vi1 PPP: Phase is UP [0 sess, 1 load]
Jan 20 22:35:27.779 UTC: Vi1 CCP: O CONFREQ [Not negotiated] id 4 len 10
Jan 20 22:35:27.779 UTC: Vi1 CCP: MS-PPC supported bits 0x01000020 (0x120601000020)
Jan 20 22:35:27.783 UTC: Vi1 CCP: I CONFREQ [REQsent] id 5 len 10
Jan 20 22:35:27.783 UTC: Vi1 CCP: MS-PPC supported bits 0x010000B1 (0x1206010000B1)
Jan 20 22:35:27.783 UTC: Vi1 CCP: O CONFNAK [REQsent] id 5 len 10
Jan 20 22:35:27.783 UTC: Vi1 CCP: MS-PPC supported bits 0x01000020 (0x120601000020)
Jan 20 22:35:27.783 UTC: Vi1 IPCP: I CONFREQ [Not negotiated] id 6 len 34
Jan 20 22:35:27.783 UTC: Vi1 IPCP: Address 0.0.0.0 (0x030600000000)
Jan 20 22:35:27.783 UTC: Vi1 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000)
Jan 20 22:35:27.783 UTC: Vi1 IPCP: PrimaryWINS 0.0.0.0 (0x820600000000)
Jan 20 22:35:27.783 UTC: Vi1 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000)
Jan 20 22:35:27.783 UTC: Vi1 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000)
Example 3-55 PAC Rejects Configuration of IPCP
Jan 20 22:35:27.783 UTC: Vi1 LCP: O PROTREJ [Open] id 10 len 40 protocol IPCP
Jan 20 22:35:27.783 UTC: Vi1 LCP: (0x80210106002203060000000081060000)
Jan 20 22:35:27.783 UTC: Vi1 LCP: (0x00008206000000008306000000008406)
Jan 20 22:35:27.783 UTC: Vi1 LCP: (0x00000000)
Jan 20 22:35:27.787 UTC: Vi1 CCP: I CONFACK [REQsent] id 4 len 10
Jan 20 22:35:27.787 UTC: Vi1 CCP: MS-PPC supported bits 0x01000020 (0x120601000020)
Jan 20 22:35:27.787 UTC: Vi1 CCP: I CONFREQ [ACKrcvd] id 7 len 10
Jan 20 22:35:27.787 UTC: Vi1 CCP: MS-PPC supported bits 0x01000020 (0x120601000020)
Jan 20 22:35:27.787 UTC: Vi1 CCP: O CONFACK [ACKrcvd] id 7 len 10
Jan 20 22:35:27.787 UTC: Vi1 CCP: MS-PPC supported bits 0x01000020 (0x120601000020)
Jan 20 22:35:27.787 UTC: Vi1 CCP: State is Open
Jan 20 22:35:27.803 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state
to down
Jan 20 22:35:27.803 UTC: Vi1 CCP: State is Closed
Jan 20 22:35:27.803 UTC: Vi1 MPPE: Required encryption not negotiated
CH01i.book Page 191 Friday, April 30, 2004 8:58 AM
192 Chapter 3: Troubleshooting Point-to-Point Tunneling Protocol VPNs
PPP negotiation is now terminated, as demonstrated in Example 3-56.
In highlighted line 1 (Example 3-56), the PPP phase changes to TERMINATING.
The PAC sends a Terminate-Request (TERMREQ, highlighted line 2) to the remote access
client/PNS. This indicates that the PAC is terminating the PPP connection.
The PPP phase then changes to DOWN in highlighted line 3.
Why exactly did the PAC inform the remote access client/PNS that it did not understand or
support IPCP (in Example 3-55)? The title and introduction to this section may be a bit of a
giveaway. The PACs conguration is examined using the show running-cong command, as
shown in Example 3-57.
As you can see, the virtual template interface has not been congured with an IP address. This
can be easily resolved.
Example 3-58 shows the conguration of ip unnumbered on the virtual template interface.
ip unnumbered is congured on the virtual template interface in Example 3-58. The remote
access client/PNS now successfully connects to the PAC.
Example 3-59 shows the successful session establishment from the remote access client/PNS
(veried using the show vpdn session all command).
Example 3-56 PPP Negotiation Is Terminated
Jan 20 22:35:27.803 UTC: Vi1 PPP: Phase is TERMINATING [0 sess, 2 load]
Jan 20 22:35:27.803 UTC: Vi1 LCP: O TERMREQ [Open] id 11 len 4
Jan 20 22:35:27.803 UTC: Vi1 LCP: State is Closed
Jan 20 22:35:27.803 UTC: Vi1 PPP: Phase is DOWN [0 sess, 2 load]
Jan 20 22:35:29.803 UTC: Vi1 LCP: Missed link down notification
Jan 20 22:35:29.803 UTC: Vi1 LCP: State is Closed
Arizona_PAC#
Example 3-57 Verifying the Virtual Template Configuration
Arizona_PAC#show running-config
!
interface Virtual-Template1
no ip address
peer default ip address pool PPTPPool
ppp encrypt mppe 40 required
ppp authentication ms-chap
!
Example 3-58 IP Address Is Configured on the Virtual Template
Arizona_PAC#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Arizona_PAC(config)#interface virtual-template 1
Arizona_PAC(config-if)#ip unnumbered ethernet 1/1
Arizona_PAC(config-if)#exit
Arizona_PAC#
CH01i.book Page 192 Friday, April 30, 2004 8:58 AM
Troubleshooting PPTP 193
As you can see, a PPTP tunnel is established from IP address 172.16.1.2 (highlighted line 1).
One session is established within that tunnel, and the username associated with this session is
mjlnet (highlighted line 2). The issue has been resolved.
Note that the error reported by Microsoft (Windows 2000) remote access client/PNSs in the
event of this type of IPCP failure is as follows:
TCP/IP CP reported error 733: Your computer and the remote computer could not agree
on PPP control protocols.
IPCP Negotiation Fails Because of Insufcient IP Addresses or a Missing IP
Address Pool
A second reason that IPCP negotiation can fail between the remote access client/PNS and the
PAC is insufcient IP addresses within the IP address pool, or the lack of a congured IP
address pool.
IP addresses can be supplied to remote access client/PNSs using DHCP or even using IP
addresses supplied by an AAA server. If DHCP or the AAA server fails to supply an IP address,
the same kind of IPCP negotiation failure can result.
Note that in this scenario, the lack of a local IP address pool is used to illustrate this problem.
The debug ppp negotiation command is again used to examine the IPCP negotiation failure as
shown in Examples 3-60 to 3-66. Only the relevant portion of the output is shown.
Example 3-59 Verifying Successful PPTP Session Establishment
Arizona_PAC#show vpdn session all
%No active L2TP tunnels
%No active L2F tunnels
PPTP Session Information Total tunnels 1 sessions 1
Call id 6 is up on tunnel id 6
Remote tunnel name is
Internet Address is 172.16.1.2
Session username is mjlnet, state is estabd
Time since change 00:00:30, interface Vi1
Remote call id is 49152
16 packets sent, 50 received, 562 bytes sent, 4695 received
Ss 17, Sr 50, Remote Nr 16, peer RWS 64
0 out of order packets
Flow alarm is clear.
%No active PPPoE tunnels
Arizona_PAC#
Example 3-60 IPCP Negotiation Fails
Arizona_PAC#debug ppp negotiation
Arizona_PAC#
Jan 20 22:42:48.323 UTC: Vi1 PPP: Phase is UP [0 sess, 2 load]
Jan 20 22:42:48.323 UTC: Vi1 IPCP: O CONFREQ [Not negotiated] id 8 len 10
Jan 20 22:42:48.323 UTC: Vi1 IPCP: Address 192.168.1.1 (0x0306C0A80101)
CH01i.book Page 193 Friday, April 30, 2004 8:58 AM
194 Chapter 3: Troubleshooting Point-to-Point Tunneling Protocol VPNs
In highlighted line 1 (Example 3-60), the PPP phase changes to UP. NCP negotiation is about
to begin.
IPCP negotiation starts with the PAC sending a CONFREQ to the remote access client/PNS
specifying its own IP address (IPCP option 0x03, highlighted line 2).
In Example 3-61, the remote access client/PNS sends a CONFREQ.
In highlighted line 1 (Example 3-61), the remote access client/PNS sends an CONFREQ to the
PAC, in which it species IP address (0x03), Primary DNS server address (0x81), Primary
WINS (0x82), Secondary DNS server address (0x83), and lastly Secondary WINS address
(0x84). All of these options are set to 0.0.0.0, indicating to the PAC that they should be supplied
to the remote access client/PNS.
Something very interesting now happens: In highlighted line 2, the message IPCP: Cannot
satisfy pool request appears. This is a pretty clear indication that the PAC cannot supply the
required IP address to the remote access client/PNS.
In Example 3-62, the PAC communicates this problem to the remote access client/PNS by
sending a CONFREJ. This message rejects conguration of IP address, Secondary DNS Server,
and Secondary WINS Server options on this link.
In Example 3-63, the remote access client/PNS sends a CONFACK to acknowledge the PACs
CONFREQ sent in Example 3-60 (highlighted line 2).
Jan 20 22:42:48.323 UTC: Vi1 CCP: O CONFREQ [Not negotiated] id 8 len 10
Jan 20 22:42:48.323 UTC: Vi1 CCP: MS-PPC supported bits 0x01000020 (0x120601000020)
Jan 20 22:42:48.327 UTC: Vi1 CCP: I CONFREQ [REQsent] id 5 len 10
Jan 20 22:42:48.327 UTC: Vi1 CCP: MS-PPC supported bits 0x010000B1 (0x1206010000B1)
Jan 20 22:42:48.327 UTC: Vi1 CCP: O CONFNAK [REQsent] id 5 len 10
Jan 20 22:42:48.327 UTC: Vi1 CCP: MS-PPC supported bits 0x01000020 (0x120601000020)
Example 3-61 Remote Access Client/PNS Sends a CONFREQ
Jan 20 22:42:48.327 UTC: Vi1 IPCP: I CONFREQ [REQsent] id 6 len 34
Jan 20 22:42:48.327 UTC: Vi1 IPCP: Address 0.0.0.0 (0x030600000000)
Jan 20 22:42:48.327 UTC: Vi1 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000)
Jan 20 22:42:48.327 UTC: Vi1 IPCP: PrimaryWINS 0.0.0.0 (0x820600000000)
Jan 20 22:42:48.327 UTC: Vi1 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000)
Jan 20 22:42:48.327 UTC: Vi1 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000)
Jan 20 22:42:48.327 UTC: Vi1 IPCP: Cannot satisfy pool request
Jan 20 22:42:48.327 UTC: Vi1 IPCP: Neither side knows remote address
Example 3-62 PAC Rejects Configuration of IP Address and Secondary DNS and WINS Server Addresses
Jan 20 22:42:48.327 UTC: Vi1 IPCP: O CONFREJ [REQsent] id 6 len 22
Jan 20 22:42:48.327 UTC: Vi1 IPCP: Address 0.0.0.0 (0x030600000000)
Jan 20 22:42:48.327 UTC: Vi1 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000)
Jan 20 22:42:48.327 UTC: Vi1 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000)
Example 3-60 IPCP Negotiation Fails (Continued)
CH01i.book Page 194 Friday, April 30, 2004 8:58 AM
Troubleshooting PPTP 195
Notwithstanding the CONFREJ sent by the PAC in Example 3-62, the remote access client/PNS
makes another attempt to request an IP address by sending a CONFREQ in Example 3-64
(highlighted line 1).
In highlighted line 2, the PAC again indicates that it cannot satisfy this request.
Conguration of an IP address is again rejected when the PAC sends another CONFREJ to the
remote access client/PNS, as shown in Example 3-65.
PPP negotiation is now terminated, as demonstrated in Example 3-66.
Example 3-63 Remote Access Client/PNS Acknowledges the PACs CONFREQ
Jan 20 22:42:48.331 UTC: Vi1 IPCP: I CONFACK [REQsent] id 8 len 10
Jan 20 22:42:48.331 UTC: Vi1 IPCP: Address 192.168.1.1 (0x0306C0A80101)
Jan 20 22:42:48.331 UTC: Vi1 CCP: I CONFACK [REQsent] id 8 len 10
Jan 20 22:42:48.331 UTC: Vi1 CCP: MS-PPC supported bits 0x01000020 (0x120601000020)
Jan 20 22:42:48.331 UTC: Vi1 CCP: I CONFREQ [ACKrcvd] id 7 len 10
Jan 20 22:42:48.331 UTC: Vi1 CCP: MS-PPC supported bits 0x01000020 (0x120601000020)
Jan 20 22:42:48.331 UTC: Vi1 CCP: O CONFACK [ACKrcvd] id 7 len 10
Jan 20 22:42:48.331 UTC: Vi1 CCP: MS-PPC supported bits 0x01000020 (0x120601000020)
Jan 20 22:42:48.331 UTC: Vi1 CCP: State is Open
Example 3-64 Remote Access Client/PNS Sends Another CONFREQ
Jan 20 22:42:48.335 UTC: Vi1 IPCP: I CONFREQ [ACKrcvd] id 8 len 10
Jan 20 22:42:48.335 UTC: Vi1 IPCP: Address 0.0.0.0 (0x030600000000)
Jan 20 22:42:48.335 UTC: Vi1 IPCP: Cannot satisfy pool request
Jan 20 22:42:48.335 UTC: Vi1 IPCP: Neither side knows remote address
Example 3-65 PAC Again Rejects Configuration of an IP Address
Jan 20 22:42:48.335 UTC: Vi1 IPCP: O CONFREJ [ACKrcvd] id 8 len 10
Jan 20 22:42:48.335 UTC: Vi1 IPCP: Address 0.0.0.0 (0x030600000000)
Example 3-66 PPP Negotiation Is Terminated
Jan 20 22:42:48.335 UTC: Vi1 IPCP: I TERMREQ [ACKrcvd] id 9 len 16
(0x5176655B003CCD74000002E2)
Jan 20 22:42:48.335 UTC: Vi1 IPCP: O TERMACK [ACKrcvd] id 9 len 4
Jan 20 22:42:48.347 UTC: Vi1 LCP: I TERMREQ [Open] id 10 len 16
(0x5176655B003CCD7400000000)
Jan 20 22:42:48.347 UTC: Vi1 LCP: O TERMACK [Open] id 10 len 4
Jan 20 22:42:48.347 UTC: Vi1 PPP: Phase is TERMINATING [0 sess, 1 load]
Jan 20 22:42:48.351 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state
to down
Jan 20 22:42:48.351 UTC: Vi1 LCP: State is Closed
Jan 20 22:42:48.351 UTC: Vi1 IPCP: State is Closed
Jan 20 22:42:48.351 UTC: Vi1 CCP: State is Closed
Jan 20 22:42:48.351 UTC: Vi1 MPPE: Required encryption not negotiated
Jan 20 22:42:48.351 UTC: Vi1 PPP: Phase is DOWN [0 sess, 1 load]
Arizona_PAC#
CH01i.book Page 195 Friday, April 30, 2004 8:58 AM
196 Chapter 3: Troubleshooting Point-to-Point Tunneling Protocol VPNs
In Example 3-66, the remote access client/PNS initiates termination of IPCP negotiation by
sending a Terminate-Request (TERMREQ) in highlighted line 1. The PAC responds with a
Terminate-Ack (TERMACK) in line 2. Finally, in highlighted line 3, the PPP phase changes to
DOWN. PPP negotiation has failed.
One thing to note is that the connection is not necessarily terminated if IPCP negotiation fails.
If, for example, another NCP, such as IPXCP, is successfully negotiated, the connection is not
terminated.
The PACs conguration is then examined using the show running-cong command.
Example 3-67 shows the PACs conguration.
As you can see, the PAC is congured to supply an IP address to the remote access client/PNS
(peer default ip address pool PPTPPool), but unfortunately, the IP address pool PPTPPool
does not exist.
The IP address pool is then congured, as shown in Example 3-68.
Once an IP address pool has been congured, PPTP tunnel and session setup succeeds.
Successful tunnel and session setup between the remote access client/PNS and the PAC is now
veried using the show vpdn session all command, as shown in Example 3-69.
Example 3-67 Verifying the PACs Configuration
Arizona_PAC#show running-config
!
interface Virtual-Template1
ip unnumbered Ethernet1/1
peer default ip address pool PPTPPool
ppp encrypt mppe 40 required
ppp authentication ms-chap
!
Example 3-68 IP Address Pool Is Configured on the PAC
Arizona_PAC#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Arizona_PAC(config)#ip local pool PPTPPool 192.168.2.1 192.168.2.10
Arizona_PAC(config)#exit
Arizona_PAC#
Example 3-69 Verifying PPTP Session Setup
Arizona_PAC#show vpdn session all
%No active L2TP tunnels
%No active L2F tunnels
PPTP Session Information Total tunnels 1 sessions 1
Call id 10 is up on tunnel id 10
Remote tunnel name is
Internet Address is 172.16.1.2
Session username is mjlnet, state is estabd
CH01i.book Page 196 Friday, April 30, 2004 8:58 AM
Case Studies 197
Highlighted line 1 shows that a PPTP tunnel has been established from a remote access client/
PNS with IP address 172.16.1.2. A session has been established within that tunnel, with
username mjlnet (highlighted line 2).
Note that the error reported by Microsoft (Windows 2000) remote access client/PNSs in the
event of an IP address assignment failure is as follows:
TCP/IP CP reported error 738: The server did not assign an address.
Case Studies
This section contains solutions for other issues not covered in the main troubleshooting section.
Case Study 1: MPPE Attributes Are Not Returned from the RADIUS Server
When using MPPE in conjunction with a RADIUS server, you must be careful to ensure that
Microsoft vendor-specic attributes are correctly congured. If these attributes are incorrectly
congured, MPPE negotiation may fail between the remote access client/PNS and the PAC.
Figure 3-33 illustrates the topology used in this case study.
Figure 3-33 Topology for Case Study 1
Time since change 00:00:28, interface Vi1
Remote call id is 49152
15 packets sent, 52 received, 530 bytes sent, 4906 received
Ss 16, Sr 52, Remote Nr 15, peer RWS 64
0 out of order packets
Flow alarm is clear.
%No active PPPoE tunnels
Arizona_PAC#
Example 3-69 Verifying PPTP Session Setup (Continued)
RADIUS Server
Username / Password /
MPPE Attributes Stored Here
Remote Access
Client/PNS
(172.16.1.2) Arizona_PAC
(10.10.10.100)
Internet
User: mjlnet
CH01i.book Page 197 Friday, April 30, 2004 8:58 AM
198 Chapter 3: Troubleshooting Point-to-Point Tunneling Protocol VPNs
In this scenario, the Microsoft MPPE vendor-specic attributes have been incorrectly
congured on the RADIUS server.
The rst command to use when troubleshooting this issue is debug ppp negotiation, as shown
in Examples 3-70 to 3-72. Only the relevant output is shown.
In highlighted line 1, the PPP phase changes state to UP. NCP negotiation is about to begin.
Immediately after that, in highlighted line 2, CCP negotiation begins with the PAC sending a
CONFREQ to the remote access client/PNS. Notice that this CONFREQ is used to request
conguration of MS-PPC with supported bits 0x01000020. If you have read the section MPPE
Negotiation Failure, you will know that this indicates support for stateless encryption and 40-
bit session keys.
The remote access client/PNS then responds with a CONFREQ (highlighted line 3), again
requesting conguration of MS-PPC but with supported bits 0x010000B1. These bits indicate
support for stateless encryption, 56- and 40-bit session keys, and MS-PPC itself.
The PAC then sends a CONFNACK in highlighted line 4, indicating that some of the options
in the remote access client/PNSs CONFREQ (highlighted line 3) are recognized but not
acceptable. The PAC again species supported bits 0x01000020 as a hint to the remote access
Example 3-70 PPP Negotiation Fails
Arizona_PAC#debug ppp negotiation
Jan 22 17:17:37.347 UTC: Vi1 PPP: Phase is UP [0 sess, 1 load]
Jan 22 17:17:37.347 UTC: Vi1 IPCP: O CONFREQ [Not negotiated] id 5 len 10
Jan 22 17:17:37.347 UTC: Vi1 IPCP: Address 192.168.1.1 (0x0306C0A80101)
Jan 22 17:17:37.347 UTC: Vi1 CCP: O CONFREQ [Closed] id 5 len 10
Jan 22 17:17:37.347 UTC: Vi1 CCP: MS-PPC supported bits 0x01000020 (0x120601000020)
Jan 22 17:17:37.351 UTC: Vi1 CCP: I CONFREQ [REQsent] id 5 len 10
Jan 22 17:17:37.351 UTC: Vi1 CCP: MS-PPC supported bits 0x010000B1 (0x1206010000B1)
Jan 22 17:17:37.351 UTC: Vi1 CCP: O CONFNAK [REQsent] id 5 len 10
Jan 22 17:17:37.351 UTC: Vi1 CCP: MS-PPC supported bits 0x01000020 (0x120601000020)
Jan 22 17:17:37.351 UTC: Vi1 IPCP: I CONFREQ [REQsent] id 6 len 34
Jan 22 17:17:37.351 UTC: Vi1 IPCP: Address 0.0.0.0 (0x030600000000)
Jan 22 17:17:37.351 UTC: Vi1 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000)
Jan 22 17:17:37.351 UTC: Vi1 IPCP: PrimaryWINS 0.0.0.0 (0x820600000000)
Jan 22 17:17:37.355 UTC: Vi1 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000)
Jan 22 17:17:37.355 UTC: Vi1 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000)
Jan 22 17:17:37.355 UTC: Vi1 AAA/AUTHOR/IPCP: Start. Her address 0.0.0.0,
we want 0.0.0.0
Jan 22 17:17:37.355 UTC: Vi1 AAA/AUTHOR/IPCP: Done. Her address 0.0.0.0,
we want 0.0.0.0
Jan 22 17:17:37.355 UTC: Vi1 IPCP: Pool returned 192.168.2.1
Jan 22 17:17:37.355 UTC: Vi1 IPCP: O CONFREJ [REQsent] id 6 len 16
Jan 22 17:17:37.355 UTC: Vi1 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000)
Jan 22 17:17:37.355 UTC: Vi1 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000)
Jan 22 17:17:37.355 UTC: Vi1 IPCP: I CONFACK [REQsent] id 5 len 10
Jan 22 17:17:37.355 UTC: Vi1 IPCP: Address 192.168.1.1 (0x0306C0A80101)
CH01i.book Page 198 Friday, April 30, 2004 8:58 AM
Case Studies 199
client/PNS as to what would be acceptable (that is, stateless encryption and 40-bit session
keys only).
In Example 3-71 CCP negotiation continues.
In highlighted line 1 (Example 3-71), the remote access client/PNS continues CCP (MS-PPC/
MPPE) negotiation by sending a CONFACK to acknowledge that stateless encryption and
40-bit session keys are acceptable.
Then in highlighted line 2, the remote access client/PNS sends a CONFREQ, again specifying
stateless encryption and 40-bit session keys, which the PAC acknowledges with a CONFACK
in highlighted line 3. The CCP state then changes to Open. CCP has apparently been
successfully negotiated.
Unfortunately, PPP negotiation now fails, as shown in Example 3-72.
Everything looked good until the PAC suddenly sends a TERMREQ (highlighted line 1 in
Example 3-72). Things then start to go downhill at a rapid rate. In highlighted line 2, the PAC
reports MPPE: Required encryption not negotiated. Finally, the PPP phase changes to
DOWN in highlighted line 3.
Why did the connection suddenly terminate? CCP (including MS-PPC/MPPE) was looking
good, and then it all went wrong.
Example 3-71 CCP Negotiation Continues
Jan 22 17:17:37.355 UTC: Vi1 CCP: I CONFACK [REQsent] id 5 len 10
Jan 22 17:17:37.355 UTC: Vi1 CCP: MS-PPC supported bits 0x01000020 (0x120601000020)
Jan 22 17:17:37.359 UTC: Vi1 CCP: I CONFREQ [ACKrcvd] id 7 len 10
Jan 22 17:17:37.359 UTC: Vi1 CCP: MS-PPC supported bits 0x01000020 (0x120601000020)
Jan 22 17:17:37.359 UTC: Vi1 CCP: O CONFACK [ACKrcvd] id 7 len 10
Jan 22 17:17:37.359 UTC: Vi1 CCP: MS-PPC supported bits 0x01000020 (0x120601000020)
Jan 22 17:17:37.359 UTC: Vi1 CCP: State is Open
Example 3-72 PPP Negotiation Fails
Jan 22 17:17:37.359 UTC: Vi1 CCP: O TERMREQ [Open] id 6 len 4
Jan 22 17:17:37.359 UTC: Vi1 PPP: Phase is TERMINATING [0 sess, 2 load]
Jan 22 17:17:37.359 UTC: Vi1 IPCP: PPP phase is TERMINATING, discarding packet
Jan 22 17:17:37.363 UTC: Vi1 CCP: PPP phase is TERMINATING, discarding packet
Jan 22 17:17:37.371 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state to
down
Jan 22 17:17:37.371 UTC: Vi1 IPCP: State is Closed
Jan 22 17:17:37.371 UTC: Vi1 CCP: State is Closed
Jan 22 17:17:37.371 UTC: Vi1 MPPE: Required encryption not negotiated
Jan 22 17:17:37.371 UTC: Vi1 LCP: O TERMREQ [Open] id 45 len 4
Jan 22 17:17:37.371 UTC: Vi1 LCP: State is Closed
Jan 22 17:17:37.371 UTC: Vi1 PPP: Phase is DOWN [0 sess, 2 load]
Jan 22 17:17:39.371 UTC: Vi1 LCP: Missed link down notification
Jan 22 17:17:39.371 UTC: Vi1 LCP: State is Closed
Arizona_PAC#
CH01i.book Page 199 Friday, April 30, 2004 8:58 AM
200 Chapter 3: Troubleshooting Point-to-Point Tunneling Protocol VPNs
Because MPPE attributes are congured on the RADIUS server, the debug radius command
is used, as shown in Examples 3-73 to 3-74.
In highlighted line 1, virtual access interface 1 changes state to up. The remote access client/
PNS is connected to the PAC.
The PAC then sends an Access-Request message to the RADIUS server (highlighted line 2).
This message is used to request authentication (and authorization) for the remote access client/
PNS. It contains a number of attributes, which are listed below the highlighted line. These
include the remote access client/PNSs username and password.
In Example 3-74, the RADIUS server responds with an Access-Accept message.
Example 3-73 Output of the debug radius Command
Arizona_PAC#debug radius
Radius protocol debugging is on
Arizona_PAC#
Jan 22 17:24:22.882 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state
to up
Jan 22 17:24:24.905 UTC: RADIUS: ustruct sharecount=1
Jan 22 17:24:24.905 UTC: Radius: radius_port_info() success=1 radius_nas_port=1
Jan 22 17:24:24.905 UTC: RADIUS: Initial Transmit Virtual-Access1 id 27
192.168.1.2:1645, Access-Request, len 132
Jan 22 17:24:24.905 UTC: Attribute 4 6 C0A80101
Jan 22 17:24:24.909 UTC: Attribute 5 6 00000001
Jan 22 17:24:24.909 UTC: Attribute 61 6 00000005
Jan 22 17:24:24.909 UTC: Attribute 1 8 6D6A6C6E
Jan 22 17:24:24.909 UTC: Attribute 26 16 000001370B0A26A4
Jan 22 17:24:24.909 UTC: Attribute 26 58 0000013701341C01
Jan 22 17:24:24.909 UTC: Attribute 6 6 00000002
Jan 22 17:24:24.909 UTC: Attribute 7 6 00000001
Example 3-74 RADIUS Server Responds with an Access-Accept Message
Jan 22 17:24:24.921 UTC: RADIUS: Received from id 27 192.168.1.2:1645, Access-Accept,
len 68
Jan 22 17:24:24.921 UTC: Attribute 6 6 00000002
Jan 22 17:24:24.921 UTC: Attribute 7 6 00000001
Jan 22 17:24:24.921 UTC: Attribute 8 6 FFFFFFFF
Jan 22 17:24:24.921 UTC: Attribute 25 30 43495343
Jan 22 17:24:24.929 UTC: RADIUS: allowing negotiated framed address
Jan 22 17:24:24.941 UTC: RADIUS: allowing negotiated framed address
Jan 22 17:24:24.953 UTC: RADIUS: allowing negotiated framed address
Jan 22 17:24:24.977 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state
to down
Arizona_PAC#
CH01i.book Page 200 Friday, April 30, 2004 8:58 AM
Case Studies 201
The RADIUS server responds with the Access-Accept message indicating that authentication
for the remote access client/PNS has succeeded (highlighted line 1, Example 3-74). A number
of RADIUS attributes are also contained within this message, and they are listed in highlighted
lines 2 to 5. These attributes (6, 7, 8, and 25) are Service-Type, Framed-Protocol, Framed-IP-
Address, and Class.
The attributes for MPPE that may be sent by the RADIUS server are as follows: vendor-specic
attribute 26, vendor-ID 311 (Microsoft), with subattributes 007 (MS-MPPE-Encryption-
Policy), 008 (MS-MPPE-Encryption-Types), 012 (MS-CHAP-MPPE-Keys), and optionally
016 (MS-MPPE-Send-Key) and 017 (MS-MPPE-Recv-Key).
The problem here is that none of these Microsoft vendor-specic attributes are included in the
Access-Accept message from the RADIUS server in Example 3-74. This is ultimately the
reason for the PPP authentication failure.
Now that the cause of the connection failure has been discovered, it is easy to resolve.
The RADIUS server must be congured to supply MPPE attributes for the remote access
client/PNS.
In this case, a CiscoSecure ACS 3.0 server is being used, and although MPPE attributes have
been congured under Interface Conguration, they have not been enabled in the group under
which the user mjlnet has been congured.
Under Group Conguration, Microsoft RADIUS attributes (vendor-specic attribute 26,
vendor-ID 311) 007, 008, 012 are congured as shown in Figure 3-34.
Note that subattribute 7 (MS-MPPE-Encryption-Policy) is used to specify whether an MPPE
encryption policy is allowed or required. Subattribute 8 (MS-MPPE-Encryption-Types) is used
to specify the types of encryption available (40 or 128-bit encryption). Subattribute 12
(MS-CHAP-MPPE-Keys) contains session keys used by MPPE. Finally, subattributes 17 and
16 specify session keys for encrypting packets sent to and from the PAC, respectively.
Once the RADIUS server has been recongured, the remote access client/PNS successfully
connects. This is veried using the show vpdn session all command, as shown in
Example 3-75.
CH01i.book Page 201 Friday, April 30, 2004 8:58 AM
202 Chapter 3: Troubleshooting Point-to-Point Tunneling Protocol VPNs
Figure 3-34 MPPE Attributes Under Group Configuration
Example 3-75 Verifying PPTP Session Establishment
Arizona_PAC#show vpdn session all
%No active L2TP tunnels
%No active L2F tunnels
PPTP Session Information Total tunnels 1 sessions 1
Call id 11 is up on tunnel id 11
Remote tunnel name is
Internet Address is 172.16.1.2
Session username is mjlnet, state is estabd
Time since change 00:00:14, interface Vi1
Remote call id is 49152
22 packets sent, 37 received, 1362 bytes sent, 2986 received
Ss 23, Sr 37, Remote Nr 22, peer RWS 64
0 out of order packets
Flow alarm is clear.
%No active PPPoE tunnels
Arizona_PAC#
CH01i.book Page 202 Friday, April 30, 2004 8:58 AM
Case Studies 203
As you can see, a remote access client/PNS with IP address 172.16.1.2 (highlighted line 1) has
successfully established a PPTP tunnel with the PAC, and a session has been started with user
mjlnet (highlighted line 2).
NOTE Note that starting in Cisco IOS Software Release 12.2(4)T, RADIUS attributes are decoded in
the output of the debug radius command.
You can also use the Output Interpreter on the Cisco Web site to verify the meaning of the
output of the debug radius command. The Output Interpreter is available at the following URL
(requires a CCO account):
https://www.cisco.com/cgi-bin/Support/OutputInterpreter/home.pl
For more details on Microsoft vendor-specic attributes, see RFC 2548. See also RFC 2865 for
more information about RADIUS in general.
Case Study 2: Split Tunnel
Although not a problem directly associated with a Cisco PAC or its conguration, this issue is
briey mentioned here because it is so often the cause of problems after a PPTP tunnel has been
established from a Microsoft remote access client/PNS.
A split tunnel is an issue that causes Microsoft remote access client/PNSs to lose Internet
connectivity. After a PPTP tunnel has been established with the PAC, Microsoft remote access
client/PNSs modify their routing tables so that the default route points to the PAC (via the
tunnel) instead of pointing to the NAS to which the client established initial connectivity (that
is, their ISP NAS).
The solution to this issue is to modify the remote access client/PNS routing table so that the
default route points to the NAS instead of the PAC. This can be accomplished using the
following sequence of commands (on the Windows workstation).
Example 3-76 shows the sequence of commands necessary to resolve the split tunnel issue on
a Windows workstation.
Once these commands are entered, the remote access client/PNS will be able to both connect
to hosts within the corporate (enterprise) network over the PPTP tunnel and to the Internet via
its local ISP NAS.
Example 3-76 Resolving a Split Tunnel Issue on Microsoft Remote Access Client/PNS
route delete 0.0.0.0
route add 0.0.0.0 mask 0.0.0.0 interface address metric 1
route add enterprise network mask net.mask tunnel interface address metric 1
CH01i.book Page 203 Friday, April 30, 2004 8:58 AM
204 Chapter 3: Troubleshooting Point-to-Point Tunneling Protocol VPNs
Note that you should always check your organizations security policy before implementing
this solution. This solution might open a back door into your corporate network via your PPTP
tunnel for other users on the Internet (that is, hackers). One possible way to prevent this is by
installing a personal rewall on all remote access clients.
Additional Troubleshooting Commands
This section introduces some additional commands that might be useful when troubleshooting
PPTP.
show vpdn
The show vpdn command can be used to view basic information regarding any PPTP tunnels
that have been established.
Example 3-77 illustrates the show vpdn command output.
In Example 3-77, you can see that one PPTP tunnel has been established, with one active
session within it (highlighted line 1).
The IP address of the remote access client/PNS (172.16.1.2), together with the TCP (source)
port the remote access client/PNS is using for control connection connectivity, are shown in
highlighted line 2. In this case, the source port is 1058.
In highlighted line 3, the local and remote (peer) Call IDs can be seen. They are 16 and 32768,
respectively.
Additionally, the virtual access interface being used by the active session is displayed (Vi1,
virtual access interface 1), together with the username for the session (mjlnet). Finally, the
tunnel/session uptime is shown (16 seconds).
Example 3-77 show vpdn Command Output
Arizona_PNS#show vpdn
%No active L2TP tunnels
%No active L2F tunnels
PPTP Tunnel and Session Information Total tunnels 1 sessions 1
LocID Remote Name State Remote Address Port Sessions
23 estabd 172.16.1.2 1058 1
LocID RemID TunID Intf Username State Last Chg
16 32768 23 Vi1 mjlnet estabd 00:00:16
%No active PPPoE tunnels
Arizona_PNS#
CH01i.book Page 204 Friday, April 30, 2004 8:58 AM
Additional Troubleshooting Commands 205
show vpdn tunnel
The show vpdn tunnel command shows basic information regarding specic tunnels, as shown
in Example 3-78.
In highlighted line 1, you can see that there is one PPTP tunnel active. Within it, there is one
active session.
Highlighted line 2 shows the IP address of the remote access client/PNS, together with the TCP
(source) port being used by the remote access client/PNS for control channel connectivity.
One thing to note in highlighted line 2 is the absence of any remote name. A remote name is
supplied by Windows 98 remote access client/PNS but might not be supplied by Windows 2000
or Windows NT remote access client/PNS. The remote name is the DNS name of the remote
access client/PNS and should not be confused with the username used for PPP authentication
on the tunnel session.
show vpdn session
As the command syntax suggests, the show vpdn session command displays summary
information regarding sessions within the PPTP tunnels, as shown in Example 3-79.
In highlighted line 1, you can see that one tunnel, and within it, one session, are active.
Highlighted line 2 shows the local and remote (peer) Call IDs (16 and 32768, respectively). The
session terminates on virtual access interface 1 (Vi1), and the username for the session is
mjlnet. Finally, the session uptime is 34 seconds.
Example 3-78 show vpdn tunnel Command Output
Arizona_PNS#show vpdn tunnel
%No active L2TP tunnels
%No active L2F tunnels
PPTP Tunnel Information Total tunnels 1 sessions 1
LocID Remote Name State Remote Address Port Sessions
23 estabd 10.10.10.15 1058 1
%No active PPPoE tunnels
Arizona_PNS#
Example 3-79 show vpdn session Command Output
Arizona_PNS#show vpdn session
%No active L2TP tunnels
%No active L2F tunnels
PPTP Session Information Total tunnels 1 sessions 1
LocID RemID TunID Intf Username State Last Chg
16 32768 23 Vi1 mjlnet estabd 00:00:34
%No active PPPoE tunnels
Arizona_PNS#
CH01i.book Page 205 Friday, April 30, 2004 8:58 AM
206 Chapter 3: Troubleshooting Point-to-Point Tunneling Protocol VPNs
show ppp mppe virtual-access number
To view MPPE information and statistics for a certain interface, the show ppp mppe virtual-
access number command can be used. Output for this command is shown in Example 3-80.
In this case, MPPE information for virtual access interface 1 is displayed.
The session key length and encryption mode is shown in highlighted line 1. In this case, 40-bit
session keys and the stateless encryption are being used.
In highlighted line 2, the number of encrypted and decrypted packets is displayed (0 and 25,
respectively).
The number of CCP resets is shown in highlighted line 3. CCP resets are sent when packet loss
is detected in stateful encryption mode. Because the mode being used in this case is stateless
encryption, these numbers will remain 0.
Highlighted line 4 shows the transmit (tx) and receive (rx) coherency counts. The transmit
coherency count corresponds to the sequence number of the next packet to be encrypted, and
the receive coherency count corresponds to the sequence number of the next packet to be
decrypted.
The next highlighted line shows the number of transmit (tx) and receive (rx) key changes.
Because the encryption mode being used in stateless encryption (the key changes on a packet-
by-packet basis), you would expect to see the number of transmit and receive key changes as
equal to the number of packets sent and received. If you compare the number of key changes to
the number of encrypted (sent) and decrypted (received) packets in highlighted line 2, you can
see that they do, in fact, match.
Note that for stateful encryption mode, the key is reinitialized (changed) every 256 packets or
when a CCP reset is received.
Highlighted line 6 shows the number of packets received and dropped and the number of
packets that are received out of order. Note that packets are dropped if they are duplicates of
packets already received.
Finally, in highlighted line 7, the number of missed packets is shown.
Example 3-80 show ppp mppe virtual-access Command Output
Arizona_PNS#show ppp mppe virtual-access 1
Interface Virtual-Access1 (current connection)
Software encryption, 40 bit encryption, Stateless mode
packets encrypted = 0 packets decrypted = 25
sent CCP resets = 0 receive CCP resets = 0
next tx coherency = 0 next rx coherency = 25
tx key changes = 0 rx key changes = 25
rx pkt dropped = 0 rx out of order pkt= 0
rx missed packets = 0
Arizona_PNS#
CH01i.book Page 206 Friday, April 30, 2004 8:58 AM
Additional Troubleshooting Commands 207
debug ppp mppe packet
The debug mppe packet command can be used to view MPPE packet information, as the
sample output in Example 3-81 demonstrates.
In highlighted line 1, a MPPE packet is received on virtual access interface 1. A coherency
count of 70 is shown, together with the packet length (100).
debug ppp mppe event
This command displays MPPE event information, including the method of key generation, the
session key length, and the encryption mode.
Example 3-82 shows debug ppp mppe event command output.
In this case, keys are generated using the local database (highlighted line 1), and 40-bit session
keys and stateless encryption are being used (highlighted lines 2 and 3).
Example 3-81 debug mppe packet Command Output
Arizona_PAC#debug ppp mppe packet
MPPE Packets debugging is on
Arizona_PAC#
*Aug 17 21:00:31.867 UTC: Vi1 MPPE: I coh 70 len 100 ENC FLUSH
*Aug 17 21:00:33.371 UTC: Vi1 MPPE: I coh 71 len 100 ENC FLUSH
*Aug 17 21:00:34.323 UTC: Vi1 MPPE: I coh 72 len 109 ENC FLUSH
*Aug 17 21:00:39.379 UTC: Vi1 MPPE: I coh 73 len 100 ENC FLUSH
*Aug 17 21:00:40.331 UTC: Vi1 MPPE: I coh 74 len 109 ENC FLUSH
*Aug 17 21:00:40.879 UTC: Vi1 MPPE: I coh 75 len 100 ENC FLUSH
*Aug 17 21:00:42.383 UTC: Vi1 MPPE: I coh 76 len 100 ENC FLUSH
*Aug 17 21:00:46.339 UTC: Vi1 MPPE: I coh 77 len 109 ENC FLUSH
*Aug 17 21:00:48.391 UTC: Vi1 MPPE: I coh 78 len 100 ENC FLUSH
Arizona_PAC#
Example 3-82 debug ppp mppe event Command Output
Arizona_PAC#debug ppp mppe event
MPPE Events debugging is on
Arizona_PAC#
*Aug 17 21:01:41.683 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state
to up
*Aug 17 21:01:43.711 UTC: Vi1 MPPE: Generate keys using local database
*Aug 17 21:01:43.711 UTC: Vi1 MPPE: Initialize keys
*Aug 17 21:01:43.715 UTC: Vi1 MPPE: [40 bit encryption] [stateless mode]
*Aug 17 21:01:44.703 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Virtual-Access1, changed state to up
Arizona_PAC#
CH01i.book Page 207 Friday, April 30, 2004 8:58 AM
208 Chapter 3: Troubleshooting Point-to-Point Tunneling Protocol VPNs
debug ppp mppe detailed
Detailed MPPE encryption and decryption information can be displayed using the debug ppp
mppe detailed command. Extra caution is advised in using this command as it can produce
large amounts of output.
Example 3-83 shows debug ppp mppe detailed command output.
In highlighted line 1, an encrypted packet is received (RX) on virtual access interface 1.
In highlighted line 2, the packet is shown after decryption.
Example 3-83 debug ppp mppe detailed Command Output
Arizona_PAC#debug ppp mppe detailed
MPPE Packet Details debugging is on
Arizona_PAC#
*Aug 17 21:03:34.511 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state
to up
*Aug 17 21:03:36.663 UTC: Vi1 MPPE: CCP RX (rx, includes MPPE header) len 100
*Aug 17 21:03:36.663 UTC: 90 0 B9 30 8 72 9D D5 DE 2B AA 8D 78 8D E5 F6
*Aug 17 21:03:36.663 UTC: C EB AF 2 D4 0 55 A1 6 7E 3 38 72 4C 15 8B
*Aug 17 21:03:36.663 UTC: 23 E1 57 9 79 7A F5 24 99 F9 94 76 46 BB EA C9
*Aug 17 21:03:36.663 UTC: ...
*Aug 17 21:03:36.663 UTC: Vi1 MPPE: CCP RX (after decryption) len 98
*Aug 17 21:03:36.663 UTC: 0 21 45 0 0 60 88 E6 0 0 80 11 EE FD C0 A8
*Aug 17 21:03:36.663 UTC: 2 1 FF FF FF FF 0 89 0 89 0 4C 9F 26 83 38
*Aug 17 21:03:36.663 UTC: 29 10 0 1 0 0 0 0 0 1 20 45 4E 45 4D 45
*Aug 17 21:03:36.663 UTC: ...
*Aug 17 21:03:36.663 UTC: Vi1 MPPE: CCP RX (rx, includes MPPE header) len 36
*Aug 17 21:03:36.663 UTC: 90 1 9B 2 ED 17 AB A7 38 62 CD 29 D6 F B7 29
*Aug 17 21:03:36.667 UTC: 46 1C 4B 1A B4 61 1 6A E5 DC 91 7 C4 F0 B5 EE
*Aug 17 21:03:36.667 UTC: 8D 16 72 29
*Aug 17 21:03:36.667 UTC: Vi1 MPPE: CCP RX (after decryption) len 34
*Aug 17 21:03:36.667 UTC: 0 21 46 0 0 20 88 E9 0 0 1 2 F9 3B C0 A8
*Aug 17 21:03:36.667 UTC: 2 1 E0 0 0 9 94 4 0 0 16 0 9 F6 E0 0
*Aug 17 21:03:36.667 UTC: 0 9
*Aug 17 21:03:36.667 UTC: Vi1 MPPE: CCP RX (rx, includes MPPE header) len 56
*Aug 17 21:03:36.667 UTC: 90 2 A4 2A 8F A3 64 66 A6 F 56 86 76 DF 9 8A
*Aug 17 21:03:36.667 UTC: E 4D 46 7B 40 0 90 17 81 D8 8A FF D7 E8 5D C2
*Aug 17 21:03:36.667 UTC: F 9F D0 1 67 D3 8 A0 1E 4C B5 E1 DC 1F F 7D
*Aug 17 21:03:36.667 UTC: ...
*Aug 17 21:03:36.667 UTC: Vi1 MPPE: CCP RX (after decryption) len 54
*Aug 17 21:03:36.667 UTC: 0 21 45 0 0 34 88 ED 0 0 1 11 8E 19 C0 A8
*Aug 17 21:03:36.667 UTC: 2 1 E0 0 0 9 2 8 2 8 0 20 57 D9 1 2
*Aug 17 21:03:36.667 UTC: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
*Aug 17 21:03:36.667 UTC: ...
CH01i.book Page 208 Friday, April 30, 2004 8:58 AM
Additional Troubleshooting Commands 209
debug vpdn error
PPTP error information can be displayed using the debug vpdn error command, as shown in
Example 3-84.
A PPTP packet is received on virtual access interface 1 (in highlighted line 1). This packet is
discarded.
debug vpdn event
This command displays PPTP event information, as shown in Example 3-85.
In highlighted line 1, the virtual access interface is created, and in line 2, conguration is cloned
(copied) from virtual template interface 1.
In highlighted line 3, the bind direction is shown (2=inbound).
Finally, in highlighted line 4, the virtual access interface changes state to up.
Example 3-84 debug vpdn error Command Output
Arizona_PAC#debug vpdn error
VPDN errors debugging is on
Arizona_PAC#
Jan 20 10:57:05.679 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state
to up
Jan 20 10:57:07.711 UTC: Vi1 PPTP: No session owner. Discarded
Jan 20 10:57:07.711 UTC: Vi1 PPTP: No session owner. Discarded
Jan 20 10:57:07.711 UTC: Vi1 PPTP: No session owner. Discarded
Jan 20 10:57:07.711 UTC: Vi1 PPTP: No session owner. Discarded
Arizona_PAC#
Example 3-85 debug vpdn event Command Output
Arizona_PAC#debug vpdn event
VPDN events debugging is on
Arizona_PAC#
Jan 20 10:50:20.527 UTC: Vi1 VPDN: Virtual interface created
Jan 20 10:50:20.527 UTC: Vi1 VPDN: Clone from Vtemplate 1
Jan 20 10:50:20.543 UTC: Vi1 VPDN: Bind interface direction=2
Jan 20 10:50:20.547 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state
to up
Jan 20 10:50:22.583 UTC: Vi1 VPDN: Cleanup
Jan 20 10:50:22.583 UTC: Vi1 VPDN: Reset
Jan 20 10:50:22.583 UTC: Vi1 VPDN: Reset
Jan 20 10:50:22.583 UTC: Vi1 VPDN: Unbind interface
Jan 20 10:50:22.583 UTC: Vi1 VPDN: Unbind interface
Jan 20 10:50:22.583 UTC: Vi1 VPDN: Reset
Jan 20 10:50:22.583 UTC: Vi1 VPDN: Unbind interface
Arizona_PAC#
CH01i.book Page 209 Friday, April 30, 2004 8:58 AM
210 Chapter 3: Troubleshooting Point-to-Point Tunneling Protocol VPNs
clear vpdn tunnel pptp remote access client/PNS_name PAC_name
The clear vpdn tunnel pptp remote access client/PNS_name PAC_name command is used to
teardown a PPTP tunnel and associated session.
Note that this command can be used only where the remote access client/PNS supplies a DNS
name. Windows 98 remote access client/PNSs supply a DNS name, but Windows NT and 2000
remote access client/PNSs might not.
The DNS name for a remote access client/PNS can be found by using the show vpdn command.
show and debug Command Summary
Table 3-4 summarizes show and debug commands used for troubleshooting PPTP in this
chapter.
Table 3-5 PPTP Troubleshooting Commands
Command Parameter Description
show vpdn Displays summary tunnel and session information
tunnel Displays tunnel information
tunnel all Displays all tunnel information
session Displays session information
session all Displays all session information
show ppp mppe virtual-access number Displays MPPE information for virtual-access
interfaces
debug vpdn errors Displays PPTP error conditions
events Displays PPTP events
l2x-packets Displays detailed PPTP packet information
debug ppp negotiation Displays PPP negotiation information
authentication Displays PPP authentication sequence
mppe detailed Displays detailed MPPE information
mppe event Displays MPPE events
mppe packet Displays MPPE packet information
debug aaa authentication Displays AAA authentication information
authorization Displays AAA authorization information
debug radius Displays RADIUS specic information
CH01i.book Page 210 Friday, April 30, 2004 8:58 AM
Review Questions 211
Review Questions
1 What is the initial message used in PPTP tunnel negotiation?
2 If the remote access client/PNS is sending PPTP control channel messages, but those
messages are not being received by the PAC, what are some possible causes?
3 How is the tunnel session established between the remote access client/PNS and the PAC?
4 How are data tunnel packets transmitted between the remote access client/PNS and the
PAC?
5 The remote access client/PNS and the PAC successfully authenticate each other using
standard MD5 CHAP, but then MPPE negotiation fails. What is the issue here?
6 Tunnel setup fails between the remote access client/PNS and the PAC. When debugging
PPP negotiation, the following message is seen: O PROTREJ [Open] id 232 len 16
protocol CCP. What does this message reveal?
7 During IPCP negotiation, the following message is seen, IPCP: Cannot satisfy pool
request. What does this indicate? Assume that local IP address assignment is being used.
8 The network administrator issues the command clear vpdn tunnel pptp
remote_access_client/PNS_name PAC_name. What messages are exchanged between the
remote access client/PNS and the PAC as the tunnel is terminated?
9 Windows remote access client/PNS users are complaining of Internet reachability issues
when connected to the PAC via a PPTP tunnel. What is most likely the issue here?
10 A remote access client/PNS user wishes to congure Multilink PPP on the PPTP tunnel
to the PAC. How can this be supported on the PAC?
CH01i.book Page 211 Friday, April 30, 2004 8:58 AM
CH01i.book Page 212 Friday, April 30, 2004 8:58 AM
C H A P T E R
4
Troubleshooting the
Layer 2 Tunneling Protocol
Version 2 VPNs
Layer Two Tunneling Protocol (L2TP) version 2 is dened in RFC 2661 and combines the
best features of Layer Two Forwarding (L2F) and Point-to-Point Tunneling Protocol
(PPTP). L2TP, like L2F and PPTP, is designed to separate the functionality of the
traditional Network Access Server (NAS). Calls from remote access clients are terminated
at a local access concentrator known as the L2TP Access Concentrator (LAC), but PPP
connections are terminated on a separate device called an L2TP Network Server (LNS).
PPP connections are tunneled from the LAC to the LNS over an intervening network.
This separation of traditional NAS functionality can potentially lead to cost savings
because calls no longer need to be made directly to a distant NAS but, instead, can be made
to a LAC at the local service provider Point-of-Presence (POP).
It is worth noting that the LAC could, for example, be a traditional dial-in access server or
could be a digital subscriber line access multiplexer (DSLAM).
The functionality of L2TP can extended to allow separate links in a Multilink PPP group to
be terminated on different NASs and then bundled together by tunneling them to one device
using L2TP. On Cisco routers, Multichassis Multilink PPP (MMP) provides this
functionality.
L2TP operates in two different modes, compulsory tunnel mode and voluntary tunnel
mode. In compulsory tunnel mode, the LAC terminates calls from remote access clients
locally and tunnels their PPP sessions across the intervening network to an LNS. This mode
does not require the remote access clients to have any knowledge of L2TP. Remote access
clients simply need to dial into the LAC using PPP.
Figure 4-1 illustrates compulsory tunnel mode.
CH01i.book Page 213 Friday, April 30, 2004 8:58 AM
214 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
Figure 4-1 L2TP Compulsory Tunnel Mode
In voluntary tunnel mode, on the other hand, remote access clients run L2TP software natively
and function as the LAC in the L2TP connection model. The remote access client/LAC
(referred to as the LAC Client in RFC 2661) connects to the LNS, and PPP frames are
tunneled through the L2TP tunnel directly between the client and the LNS.
Figure 4-2 illustrates voluntary tunnel mode.
Figure 4-2 L2TP Voluntary Tunnel Mode
As previously mentioned, L2TPv2 is derived from L2F and PPTP. Some of the main similarities
and differences between L2TPv2 and L2F/PPTP are as follows:
L2F was developed by Cisco Systems, and PPTP was developed by a consortium of
vendors. L2TPv2 is an industry standard and was developed within the Internet
Engineering Task Force (IETF).
L2TP is more easily extensible than L2F and PPTP because L2TP control messages are
made up of attribute-value-pairs (AVPs).
L2TPv2 and PPTP are designed to tunnel PPP. L2F, on the other hand, can tunnel both
PPP and SLIP.
Note that L2TPv3 is designed to tunnel a wide variety of Layer 2 protocols; see Chapter
5, Troubleshooting L2TPv3 Based VPNs, for more details.
Remote Access
Client
LAC
PSTN/
ISDN
LNS
Corporate
Network
Service Provider
Backbone
L2TP Tunnel
PPP PPP
Corporate
Network
Remote Access
Client / LAC
LNS
Internet
L2TP Tunnel
PPP PPP
CH01i.book Page 214 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 215
L2TPv2 is similar to L2F with regard to its control connection. In both L2TP and L2F,
control messages are transmitted in-band (using the same transport mechanism as data
messages, UDP in an IP network), whereas in PPTP, control messages are transmitted
out-of-band over a separate TCP connection.
Both L2TPv2 and PPTP include the capability to make outgoing calls, whereas L2F
does not.
L2TPv2 and PPTP can operate in both compulsory and voluntary tunnel modes. L2F, on
the other hand, can operate only in compulsory tunnel mode.
Both L2TPv2 and L2F support authentication of tunnel endpoints (LAC/LNS and L2F
NAS/Home Gateway in L2TPv2 and L2F, respectively) during tunnel setup, whereas
PPTP does not (it relies on authentication of PPP peers instead).
L2TPv2 and L2F both transport data and control messages over UDP in an IP network
(using UDP port 1701). The L2TPv2 and L2F headers are both derived from Generic
Routing Encapsulation (GRE). PPTP data messages are transported over Enhanced GRE
(IP protocol 47), and PPTP control messages are transported over TCP (using port 1723).
Reliable delivery of control messages is included in L2TPv2, PPTP, and L2F, but is
implemented in different ways. L2TP uses either implicit or explicit acknowledgment,
and PPTP control messages are delivered over an inherently reliable TCP connection. In
L2F, control messages are exchanged in lock-step.
L2TPv2 uses similar control messages to PPTP.
The LAC and the L2F NAS (the functional equivalent of the LAC) both have the ability
to negotiate LCP and authenticate the remote access client then pass this information to
the LNS or the L2F Home Gateway (the functional equivalent of the LNS). PPTP has no
such capability.
L2TPv2 has the built-in capability to hide the content of control messages (AVP hiding),
whereas L2F and PPTP do not.
It is not the purpose of this book to provide an exhaustive examination of the operation and
conguration of the L2TP protocol, but it is useful to provide a review so that you have a good
basis for the troubleshooting section that follows. This review is provided in the next section.
L2TPv2 Technical Overview
This section provides an overview of the operation of the L2TP. Note that although voluntary
tunnel mode is discussed, the focus remains on compulsory tunnel mode.
L2TP uses two kinds of messages:
Control messagesUsed in L2TP tunnel and session setup, maintenance, and teardown.
Control messages are reliably transmitted in-band over a control connection between the
LAC and the LNS. Only one control connection is required for each L2TP tunnel
regardless of the number of data sessions.
CH01i.book Page 215 Friday, April 30, 2004 8:58 AM
216 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
Data messagesUsed to transport PPP frames between the LAC and the LNS. Each PPP
connection is carried over a separate data session within the L2TP tunnel.
Note that many PPP connections can be carried over a single L2TP tunnel between the LAC
and the LNS (theoretically 65,535 connections).
Figure 4-3 shows the control connection and data session between the LAC and the LNS.
Figure 4-3 Control Connection and Data Session Between the LAC and the LNS
According to RFC 2661, L2TP messages can be carried via a number of packet transports,
including UDP, Frame Relay, and ATM. This chapter focuses on transport over UDP.
NOTE Note that RFC 2661 species UDP destination port 1701 but leaves the source port up to the
implementer. Cisco routers use port 1701 for both source and destination.
Figure 4-4 shows the overall format of L2TP packets for both control and data messages.
Note that although a L2TP payload is shown in Figure 4-4, there is one L2TP message that does
not include a payload. This is the Zero-Length-Body Acknowledgment (ZLB Ack). ZLB Acks
are used to explicitly acknowledge control channel messages.
Control and data message types share a common header.
Figure 4-5 illustrates the L2TP message header.
L2FP Tunnel
Remote Access
Client
LAC
PSTN/
ISDN
LNS
Corporate
Network
Service Provider
Backbone
PPP
Data
Session
Control
Connection
Data
Session
Control
Connection
PPP
CH01i.book Page 216 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 217
Figure 4-4 Overall L2TPv2 Packet Format
Figure 4-5 L2TPv2 Message Header
The L2TP header consists of the following bits and elds:
The T bit indicates what type of message it is. If the T bit is set to 0, it is a data message,
and if the T bit is set to 1, it is a control message.
The L bit indicates whether the Length eld is present. If the L bit is set to 1, the Length
eld is present. The Length eld must be present in all control messages.
The next two bits in the header (shown as x) must be set to zero. All bits marked as x are
reserved for future use and must be set to 0.
The S bit is the sequence bit, and if set to 1 the Ns (Next sent) and Nr (Next received) elds
must be present. The S bit must be set to 1 for control messages.
The Offset (O) bit, if set to 1, mandates the presence of the Offset eld. The Offset bit must
be set to zero for all control messages.
IP Header
UDP Header
L2TP Header
L2TP Payload
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Length (opt) Ver T L x x S x O P x x x x
Session ID Tunnel ID
Nr (opt) Ns (opt)
Offset Pad... (opt) Offset Size (opt)
0 1 2 3
CH01i.book Page 217 Friday, April 30, 2004 8:58 AM
218 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
The P bit is the priority bit and indicates whether this message should receive preferential
treatment. The P bit is used only with data messages and, therefore, must be set to 0 for
all control messages. An example of the usage of the P bit is with LCP Echo-Requests.
LCP Echo-Request messages are used as keepalives on the PPP link, and any delay in their
processing could potentially lead to the link being dropped.
The Ver eld is 4 bits long and indicates the version of the protocol being used. In this case,
the version must be set to 2. You might be a bit confused as to why this is version 2 of L2TP.
What happened to version 1 of L2TP, you might be asking. In fact, version 1 was not L2TP
at all but instead was L2F. Remember that L2TP is derived from both PPTP and L2F.
If the L bit is set to 1, after the Ver eld comes the Length eld. The Length eld is 16 bits
long and indicates the total length for the message in octets.
The Tunnel ID and Session ID elds are both 16 bits long. The Tunnel ID uniquely
identies the tunnel. This identier is locally signicant only. Therefore, the same tunnel
could have different tunnel IDs at either end. The local tunnel ID is passed by either the
LAC or the LNS to its peer in the Assigned Tunnel ID AVP during tunnel setup.
Figure 4-6 illustrates Tunnel IDs.
Figure 4-6 L2TP Tunnel IDs
In Figure 4-6, the L2TP tunnel between SP_LAC1 and CorpX_LNS is identied
by tunnel ID 52 at the SP_LAC1 end and by tunnel ID 62 at the CorpX_LNS end.
Similarly, the tunnel from SP_LAC2 and CorpX_LNS is identied by tunnel ID
51 at the SP_LAC2 end and by tunnel ID 61 at the CorpX_LNS end.
SP_LAC1
SP_LAC2
CorpX_LNS
TunnelID = 51
TunnelID = 52
TunnelID = 62
TunnelID = 61
CH01i.book Page 218 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 219
The Session ID uniquely identies the data session within the overall tunnel. Again,
Session IDs are locally signicant only. The same PPP session can have a different
Session ID at either end of the tunnel. Local session IDs are passed to the L2TP peer in
the Assigned Session ID AVP during session setup.
Figure 4-7 illustrates session IDs.
Figure 4-7 L2TP Session IDs
In Figure 4-7, the data session used to carry PPP frames from remote access
client A over the L2TP tunnel to the LNS is identied by Session ID 1 at the LAC
and by Session ID 11 at the LNS.
Similarly, the data session used to transport PPP frames from remote access
client B over the L2TP tunnel to the LNS is identied by Session ID 2 at the LAC
and by Session ID 12 at the LNS.
After the Session ID come the Ns (Next sent) and Nr (Next received) elds. The Ns eld
is 16 bits long and indicates the sequence number for this data or control message. The Nr
eld is also 16 bits long and indicates the sequence number of the next message to be
received. Nr serves as an acknowledgment of all messages received with sequence
numbers of up to one less than the number specied.
The two nal elds in the message header are the Offset size and Offset pad elds. The
Offset size eld and the Offset pad eld are present only if the O bit is set to 1. The Offset
size eld indicates the size of the offset pad in octets. The Offset pad is the padding itself.
The data to be contained within the Offset pad is undened in RFC 2661.
SessionID = 2 (Client B)
Remote Access
Client B
Remote Access
Client A
LAC
SessionID = 1 (Client A)
SessionID = 12 (Client B)
SessionID = 11 (Client A)
L2TP Tunnel
LNS
CH01i.book Page 219 Friday, April 30, 2004 8:58 AM
220 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
Now that the common packet header has been examined, it is now time to examine more closely
the precise makeup of the control and data messages. The next section begins with the
composition of L2TP control messages.
L2TP Control Messages
Control messages are used to establish, maintain, and tear down L2TP tunnels.
Table 4-1 summarizes the L2TP control message types.
Note that the precise function of each message type is discussed in the following sections.
Control messages are made up of the common packet header and a number of AVPs. AVPs are
constructs that are used to indicate the value of a particular variable (the attribute). AVPs allow
the L2TP to be very extensible.
AVPs have a common encoding format, as illustrated in Figure 4-8.
Table 4-1 L2TP Control Message Types
Message
Type Description Function
1 Start-Control-Connection-Request (SCCRQ) Control Channel Setup
2 Start-Control-Connection-Reply (SCCRP) Control Channel Setup
3 Start-Control-Connection-Connected (SCCCN) Control Channel Setup
4 Stop-Control-Connection-Notication
(StopCCN)
Control Channel Teardown
6 Hello (HELLO) Control Channel Maintenance
7 Outgoing-Call-Request (OCRQ) Data Session Setup (Outgoing Calls)
8 Outgoing-Call-Reply (OCRP) Data Session Setup (Outgoing Calls)
9 Outgoing-Call-Connected (OCCN) Data Session Setup (Outgoing Calls)
10 Incoming-Call-Request (ICRQ) Data Session Setup (Incoming Calls)
11 Incoming-Call-Reply (ICRP) Data Session Setup (Incoming Calls)
12 Incoming-Call-Connected (ICCN) Data Session Setup (Incoming Calls)
14 Call-Disconnect-Notify (CDN) Data Session Teardown
15 WAN-Error-Notify (WEN) Call Status
16 Set-Link-Info (SLI) Call Status
CH01i.book Page 220 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 221
Figure 4-8 L2TP AVP Encoding Format
The bits and elds that make up the L2TP AVP encoding format are as follows:
The mandatory (M) bit indicates whether recognition of an AVP is mandatory. If the M bit
is set (1) on a particular AVP associated with the session, and that AVP is not recognized
by the receiving peer, the session must be dropped. If, however, the M bit is not set (0) and
the AVP is not recognized by the receiving peer, the AVP can simply be ignored.
Similarly, if the M bit is set on an AVP associated with the overall tunnel and the
AVP is not recognized by the receiving peer, the entire tunnel must be torn down.
Finally, if the M bit is not set on an AVP associated with an entire tunnel and the
AVP is not recognized, it can simply be ignored.
The hidden (H) bit, if set to 1, indicates that the value or data in the AVP should be hidden.
The hiding of data in AVPs is particularly useful when passing sensitive data such as
passwords.
The method of encoding used by hidden AVPs involves hashing the data using
the Message Digest 5 (MD5) algorithm, and XORing the resulting values. The
precise mechanics of the algorithm are detailed in section 4.3 of RFC 2661.
The four bits labeled RSVD are reserved bits and must be set to 0.
The Length eld is ten bits long and indicates the overall length of the AVP in octets. The
minimum length of the AVP is six. If the length of the AVP is six, the attribute value eld
itself is not present.
The Vendor-ID eld is 16 bits long and allows vendors to implement their own AVPs. The vendor
IDs themselves correspond to SMI Network Management Private Enterprise Codes (see RFC
1700). If the value of the vendor-ID eld is 0, then the AVP is one of those dened in RFC 2661.
The Attribute Type eld is 16 bits long and indicates the type of message or data being
passed in the AVP.
The Attribute Value eld (which is of variable length) indicates the precise value of the
message or data being passed in the AVP.
Thirty-eight AVPs are dened in RFC 2661. These fall into the following categories:
AVPs applicable to all control messages
The Result Code AVP
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Vendor ID Length rsvd M H
Attribute Value... Attribute Type
(Until Length is Reached)...
0 1 2 3
CH01i.book Page 221 Friday, April 30, 2004 8:58 AM
222 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
Control connection management AVPs
Call management AVPs
Proxy LCP and authentication AVPs
Call status AVPs
AVPs Applicable to All Control Messages
AVPs applicable to all control messages can, as the category suggests, be carried in any control
messages.
Table 4-2 summarizes AVPs applicable to all control messages.
Note, in particular, the Message Type AVP. This must be carried in every control message and
is used to specify the control message type itself. See Table 4-1 for a list of message type values
carried in this AVP.
Result Code AVP
The Result Code AVP sits in its own category.
Table 4-3 shows a description of the Result Code AVP.
The precise meaning of the result code depends on whether it is carried within the StopCCN or
CDN message.
Table 4-2 AVPs Applicable to All Control Messages
Attribute Type Attribute Name Description Present In
0 Message Type Identies the control message type All message types
36 Random Vector Used with hidden AVPs All message types
Table 4-3 Result Code AVP
Attribute Type Attribute Name Description Present In
1 Result Code Indicates the reason for control channel
or session teardown. This AVP can also
contain an Error Code and Error
Message.
CDN / StopCCN
CH01i.book Page 222 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 223
Table 4-4 shows result codes carried in StopCCN messages.
Table 4-5 shows result codes carried in CDN messages.
In addition to the Result Code itself, an Error Code and Error Message can also optionally be
carried in the Result Code AVP.
Table 4-4 Result Codes Carried in StopCCN Messages
Result Code Description
1 General request to clear control connection
2 General error (Error code indicates problem see Table 4-6)
3 Control channel already exists
4 Requestor is not authorized to establish a control channel
5 Protocol version of requestor is not supported
6 Requestor is being shut down
7 Finite state machine error
Table 4-5 Result Codes Carried in CDN Messages
Result Code Description
1 Call disconnected because of loss of carrier
2 Call disconnected for reason indicated by error code (see Table 4-6)
3 Call disconnected for administrative reasons
4 Call failed because of lack of appropriate facilities (temporary condition)
5 Call failed because of lack of appropriate facilities (permanent condition)
6 Invalid destination
7 Call failed because of no carrier detected
8 Call failed because of detection of busy tone
9 Call failed because of lack of dial tone
10 Call was not established within time allotted by LAC
11 Call was connected but no appropriate framing was detected
CH01i.book Page 223 Friday, April 30, 2004 8:58 AM
224 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
Table 4-6 shows possible Error Code values.
Error messages, if carried, contain human-readable text.
Control Connection Management AVPs
Control connection management AVPs are carried in control messages during control
connection setup and teardown.
Table 4-7 summarizes control connection management AVPs.
Table 4-6 Error Code Values
Error Code Description
0 No general error
1 No control connection exists yet for this LAC/LNS pair
2 Length is wrong
3 One of the elds was out of range or reserved eld was nonzero
4 Insufcient resources to handle this operation now
5 The session ID is invalid in this context
6 A generic vendor-specic error occurred on the LAC
7 Try another (the LAC should try another LNS)
8 Session or tunnel was shut down because of receipt of unknown AVP with
M-bit set (Error code should contain offending attribute)
Table 4-7 Control Connection Management AVPs
Attribute Type Attribute Name Description Present In
2 Protocol Version Indicates protocol version and revision SCCRQ / SCCRP
3 Framing Capabilities Indicates acceptable framing types SCCRQ / SCCRP
4 Bearer Capabilities Indicates bearer device types supported SCCRQ /SCCRP
5 Tie Breaker Tie breaker in the event of both L2TP
peers attempting to set up a tunnel
concurrently
SCCRQ
6 Firmware Revision Indicates the rmware revision SCCRQ / SCCRP
7 Hostname Hostname of the LAC or LNS SCCRQ / SCCRP
8 Vendor Name String describing type of LAC or LNS SCCRQ / SCCRP
9 Assigned Tunnel ID Indicates local tunnel ID to peer SCCRQ / SCCRP/ StopCCN
10 Receive Window Size Species receive window size to peer
(used for ow control)
SCCRQ / SCCRP
CH01i.book Page 224 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 225
Note, in particular, attribute types 11 and 13 (Challenge and Challenge Response). These are
used during tunnel authentication.
Call Management AVPs
Call management AVPs are carried in control messages used for data session setup and
teardown.
Table 4-8 shows call management AVPs.
11 Challenge Authentication challenge used during
tunnel authentication
SCCRQ / SCCRP
13 Challenge Response Response to authentication challenge
received from peer
SCCRP / SCCCN
Table 4-8 Call Management AVPs
Attribute Type Attribute Name Description Present In
12 Q.931 Cause Code Indicates ISDN Q.931 cause
code in the case of unsolicited
call disconnection
CDN
14 Assigned Session ID Indicates local Session ID to
peer
ICRP / ICRQ / OCRQ / OCRP/ CDN
15 Call Serial Number Indicates globally signicant
identier for this call
ICRQ / OCRQ
16 Minimum BPS Indicates lowest acceptable line
speed (bits per second)
OCRQ
17 Maximum BPS Indicates highest acceptable line
speed (bits per second)
OCRQ
18 Bearer Type Indicate bearer type for call
(analog or digital)
ICRQ / OCRQ
19 Framing Type Indicates framing type for call
(synchronous or asynchronous)
ICCN / OCRQ / OCCN
21 Called Number Number to be called (OCRQ),
or called number (ICRQ)
ICRQ / OCRQ
22 Calling Number The number from which the call
was made
ICRQ
23 Sub-Address Indicates additional dialing
information
ICRQ / OCRQ
continues
Table 4-7 Control Connection Management AVPs (Continued)
Attribute Type Attribute Name Description Present In
CH01i.book Page 225 Friday, April 30, 2004 8:58 AM
226 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
Proxy LCP and Authentication AVPs
Proxy LCP and authentication AVPs are carried in the Incoming-Call-Connected (ICCN)
message.
During initial call setup between the remote access client and the LAC, the Link Control
Protocol (LCP) is negotiated, and the remote access client is partially authenticated.
LCP parameters, together with authentication information, are passed to the LNS by the LAC
during data session setup using proxy LCP and authentication AVPs. This information can be
used by the LNS to rapidly initialize LCP and authentication, without having to renegotiate
them with the remote access client.
Note, however, that should it chose to do so, the LNS can renegotiate both LCP and
authentication with the remote access client.
Table 4-9 summarizes proxy LCP and authentication AVPs.
24 (TX) Connect Speed (Transmit) speed of facility for
call connection attempt
ICCN / OCCN
38 RX Connect Speed (Receive) Speed of facility for
call connection
ICCN / OCCN
25 Physical Channel ID Identies physical channel used
for call (vendor-specic
encoding)
ICRQ / OCRP
37 Private Group ID Indicates customer group with
which call is associated
ICCN
39 Sequencing Required Indicates that Sequence
Numbering must be present on
data channel
ICCN / OCCN
Table 4-9 Proxy LCP and Authentication AVPs
Attribute Type Attribute Name Description Present In
26 Initial Received LCP
CONFREQ
Initial CONFREQ received by LAC from remote
access client
ICCN
27 Last Sent LCP CONFREQ Final LCP CONFREQ sent by LAC to remote
access client
ICCN
28 Last received LCP
CONFREQ
Final LCP CONFREQ received by LAC from
remote access client
ICCN
29 Proxy Authen Type Indicates authentication type used by LAC with
remote access client
ICCN
Table 4-8 Call Management AVPs (Continued)
Attribute Type Attribute Name Description Present In
CH01i.book Page 226 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 227
Call Status AVPs
Call status AVPs are carried in control messages to communicate error information or
negotiated Asynchronous Control Character Map (ACCM) values.
Table 4-10 shows call status AVPs.
AVPs are sent in combination depending upon the specic control message type being sent. The
function of specic control messages is explained in the following sections.
Now that the format of both control and data message types has been detailed, it is time to
examine the behavior of L2TP with regard to tunnel establishment, maintenance, and teardown.
L2TP Tunnel (Control Connection) Establishment
The establishment of a L2TP tunnel involves the reception of a call from a remote system on
the LAC (assuming an incoming call), the establishment of a control connection between the
LAC and the LNS, and the establishment of data sessions to carry PPP frames between remote
access clients and the LNS.
As mentioned, the rst event involved with tunnel establishment is the reception of a call from
a remote access client on the LAC. The LAC then negotiates the LCP, and partially
authenticates the remote access client. Information regarding LCP negotiation and
authentication is later passed to the LNS during session setup.
30 Proxy Authen Name Species the name used by the remote access
client during authentication with the LAC
ICCN
31 Proxy Authen Challenge Indicates the challenge sent by the LAC to the
remote access client during authentication
ICCN
32 Proxy Authen ID Species the ID used during authentication
between the LAC and remote access client
ICCN
33 Proxy Authen Response Species the authentication response received by
the LAC from the remote access client
ICCN
Table 4-10 Call Status AVPs
Attribute Type Attribute Name Description Present In
34 Call Errors (WEN) Used by LAC to communicate error information to the LNS WEN
35 ACCM (SLI) Used by the LNS to communicate ACCM to LAC SLI
Table 4-9 Proxy LCP and Authentication AVPs (Continued)
Attribute Type Attribute Name Description Present In
CH01i.book Page 227 Friday, April 30, 2004 8:58 AM
228 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
Based upon the domain name of the remote access client (contained within the remote access
clients username), the Dialed Number Identication Service (DNIS) string, or the complete
remote access client username (if using per-user virtual private dialup networks [VPDN]), the
LAC associates the PPP call to a L2TP tunnel to a particular LNS.
Note that the DNIS is the number that the remote access client dials to connect to the LAC, and
it is passed to the LAC in ISDN Q.931 messages during call setup.
When using per-user VPDN, the LAC sends the complete remote access client username to the
AAA server, and the AAA server sends back tunnel information for that username.
NOTE For more information on per-user VPDN, see the following URL:
http://www.cisco.com/en/US/tech/tk801/tk703/
technologies_conguration_example09186a0080094860.shtml
Figure 4-9 illustrates call reception, LCP negotiation, and partial authentication.
Figure 4-9 Call Reception, LCP Negotiation, and Partial Authentication
Once the LAC has associated the remote access clients PPP session with a L2TP tunnel, it
begins to forward the PPP session over the tunnel, if it already exists. If the tunnel does not yet
exist, the LAC begins the establishment of the tunnel.
This section assumes that there is no existing tunnel between the LAC and the LNS. It is worth
emphasizing at this point that a tunnel between a particular LAC and LNS is capable of carrying
multiple PPP sessions within it.
Remote Access
Client LAC
PSTN/
ISDN
LNS
Service Provider
Backbone
1. Client Calls
LAC
2. LCP
Negotiation
Authentication
3. Partial
CH01i.book Page 228 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 229
The rst stage in the establishment of the L2TP tunnel between the LAC and the LNS is the
setup of the control connection. Setup of the control connection is initiated by the LAC using a
Start-Control-Connection-Request (SCCRQ) message. Assuming that the LNS has sufcient
resources, and the LAC is authorized to build a tunnel, the LNS responds with a Start-Control-
Connection-Reply (SCCRP) message. The SCCRP message indicates to the LAC that it can
proceed with control connection establishment. The LAC then responds to the LNS with a
Start-Control-Connection-Connected (SCCCN) message. This is used to conrm the
establishment of the control connection. Finally, if there are no other messages waiting in the
queue to be sent from the LNS to the LAC, the LNS acknowledges the SCCCN using a ZLB
ACK message.
Information contained within AVPs that is exchanged by the LAC and the LNS during L2TP
tunnel setup includes (but is not limited to) L2TP version number, hostname, assigned tunnel
IDs, as well as authentication challenges and challenge responses (if authentication is enabled).
For a complete list of AVPs that can be exchanged in SCCRQ, SCCRP, and SCCCN messages,
see Table 4-7.
It is worth noting that RFC 2661 does dene an optional tunnel authentication mechanism. This
allows the LNS to authenticate the LAC and vice-versa before allowing establishment of the
tunnel. The password used in tunnel authentication takes the form of a single shared secret. This
password is also used with AVP hiding (if enabled).
Note that AVP hiding can be enabled on Cisco routers using the l2tp hidden command (under
the VPDN group).
Figure 4-10 illustrates establishment of the control connection between the LAC and the LNS.
Once the control connection has been established between the LAC and the LNS, data session
establishment is ready to begin.
CH01i.book Page 229 Friday, April 30, 2004 8:58 AM
230 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
Figure 4-10 Control Connection Establishment
L2TP Session Establishment
Session establishment involves the establishment of a data session over the tunnel. PPP frames
passing between the remote access client and the LNS are then carried over this data session.
The rst message in the establishment of a data session is the Incoming-Call-Request (ICRQ)
message. If there are sufcient resources available and the new session should be
administratively permitted, the LNS responds to the LACs ICRQ message with an Incoming-
Call-Reply (ICRP) message. The LAC then responds with an ICCN message. This indicates
that the LAC is proceeding with session establishment. If no other messages are waiting to be
sent to the LAC, the LNS acknowledges the ICCN with a ZLB Ack.
During session setup, information contained in AVPs that is exchanged between the LAC and
the LNS includes (but is not limited to) assigned session IDs, called number, calling number,
connect speed, as well as proxy LCP and authentication information. See Tables 4-8 and 4-9 for
a complete list of AVPs that can be exchanged in ICRQ, ICRP, and ICCN messages.
Figure 4-11 shows establishment of an L2TP session between the LAC and the LNS.
Remote Access
Client
LAC
PSTN/
ISDN
LNS
Service Provider
Backbone
Client
Calls LAC
LCP
Negotiation
Authentication
Partial PPP
SCCRP
SCCCN
SCCRQ
CH01i.book Page 230 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 231
Figure 4-11 L2TP Session Establishment
At this point, the L2TP tunnel and a data session within it to transport PPP frames have been
established between the LAC and the LNS. The LAC now begins to forward PPP frames from
the remote access client over the L2TP tunnel to the LNS.
It is worth briey examining in what form PPP frames from the remote access client are
forwarded over the tunnel (data session). The LAC does not send the complete PPP frame
received from the remote access client to the LNS. Instead, redundant information such as
Frame Check Sequence (FCS), link framing, and transparency bytes are stripped from the PPP
frames received from the remote access client. The resulting PPP frame is encapsulated in a
L2TP packet and forwarded over the tunnel to the LNS. The same process happens in reverse
for PPP frames being forwarded from the LNS to the remote access client.
Once a data session has been established, LCP negotiation and PPP authentication are
completed, and Network Control Protocol (NCP) negotiation takes place between the remote
access client and the LNS.
Remote Access
Client
LAC
PSTN/
ISDN
LNS
Service Provider
Backbone
Client Calls
LAC
LCP
Negotiation
Authentication
Partial PPP
SCCRP
SCCCN
SCCRQ
ICRQ
ICRP
ICCN
CH01i.book Page 231 Friday, April 30, 2004 8:58 AM
232 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
Figure 4-12 illustrates LCP negotiation, PPP authentication, NCP negotiation, and PPP frame
forwarding between the remote access client and the LNS.
Figure 4-12 LCP Negotiation, PPP Authentication, NCP Negotiation, and PPP Frame Forwarding
L2TP Tunnel Maintenance
Now that the setup of the L2TP tunnel and data sessions has been described, it is now time to
describe the mechanism that is used to maintain the tunnel.
Remote Access
Client
LAC
PSTN/
ISDN
LNS
Service Provider
Backbone
Client Calls
LAC
LCP
Negotiation
Authentication
Partial PPP
LCP Negotiation / PPP
Authentication Completed
NCP
Negotiation
SCCRP
SCCCN
PPP
Frames
SCCRQ
ICRQ
ICRP
ICCN
CH01i.book Page 232 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 233
RFC 2661 describes a keepalive mechanism used to maintain the L2TP tunnel during an
extended period of inactivity. This keepalive mechanism takes the form of L2TP hello control
messages sent over the control connection. If no other messages are waiting to be sent, hello
messages are acknowledged with a ZLB Ack.
Figure 4-13 illustrates the keepalive mechanism used between the LAC and the LNS.
Note that L2TP hello messages can be sent by either the LAC or the LNS.
There a default inactivity interval of 60 seconds before a hello message is sent.
Figure 4-13 L2TP Keepalive Mechanism
L2TP Session Teardown
Session teardown can occur for a number of reasons. The most common is that the remote
access client disconnects from the LAC.
Session teardown can be initiated by either the LAC or the LNS and is signaled by the Call-
Disconnect-Notify (CDN) message. Upon receipt of the CDN, the L2TP peer acknowledges
with a ZLB Ack message, assuming that no other messages are waiting to be transmitted.
Figure 4-14 illustrates session teardown.
Figure 4-14 L2TP Session Teardown
The reason for the session teardown is given by the reason code carried in the CDN
(see Table 4-5).
Remote Access
Client
LAC
PSTN/
ISDN
LNS
Service Provider
Backbone
HELLO
Remote Access
Client
LAC
PSTN/
ISDN
LNS
Service Provider
Backbone
CDN
CH01i.book Page 233 Friday, April 30, 2004 8:58 AM
234 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
L2TP Tunnel Teardown
There are a number of reasons for tunnel teardown. One reason might be that the last data
session within the tunnel is terminated, although teardown is not mandatory. Also, a tunnel
might be torn down if it is manually cleared.
Tunnel teardown can be signaled by either the LAC or the LNS using the Stop-Control-
Connection-Notication (StopCCN) message. If no other messages are waiting to be
transmitted, the L2TP peer will acknowledge the StopCCN with a ZLB Ack.
Figure 4-15 shows tunnel teardown.
Figure 4-15 L2TP Tunnel Teardown
The reason for the tunnel teardown is given by the reason code carried in the StopCCN (see
Table 4-4).
Other L2TP Messages
Other message types used on the control connection are the WAN-Error-Notify (WEN)
message and the Set-Link-Info (SLI) message.
WEN Message
The WEN message is used by the LAC to inform the LNS when errors occur on the PPP
interface connected to the remote access client. Note that this error message should not be sent
more than once every 60 seconds.
Assuming that no other messages are waiting to be transmitted, the L2TP peer acknowledges
receipt of the WEN with a ZLB Ack message.
Figure 4-16 illustrates transmission of the WEN message.
Remote Access
Client
LAC
PSTN/
ISDN
LNS
Service Provider
Backbone
StopCCN
CH01i.book Page 234 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 235
Figure 4-16 L2TP WEN Message
SLI Message
The SLI message is sent by the LNS to the LAC to set PPP negotiated options. At present in
L2TPv2, the SLI message can be used only to update the PPP ACCM.
Assuming that no other messages are waiting to be transmitted, receipt of the SLI is
acknowledged with a ZLB Ack message.
Figure 4-17 illustrates transmission of the SLI message from the LNS to the LAC.
Figure 4-17 L2TP SLI Message Transmission
Outgoing Calls
L2TP has the additional capability of making outgoing calls. This means that the LNS can
signal the LAC to place an outgoing call to a remote client.
Outgoing call initiation is signaled by the LNS to the LAC using an Outgoing-Call-Request
(OCRQ) message. Upon receipt of the OCRQ, the LAC determines whether proper facilities
exist to make the outgoing call. If those facilities exist, the LAC responds to the LNS using an
Outgoing-Call-Reply (OCRP) message. The LAC then attempts to complete the outgoing call
and, if successful, informs the LNS using an Outgoing-Call-Connected (OCCN) message. If no
other messages are waiting to be transmitted, the OCCN is acknowledged by the LNS with a
ZLB Ack message.
Remote Access
Client
LAC
PSTN/
ISDN
LNS
Service Provider
Backbone
1. Error Detected on
PPP Interface
2. WEN
Remote Access
Client
LAC
PSTN/
ISDN
LNS
Service Provider
Backbone
2. Modify ACCM
1. SLI
CH01i.book Page 235 Friday, April 30, 2004 8:58 AM
236 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
Information contained within AVPs that is exchanged by the LNS and the LAC during outgoing
call setup includes (but is not limited to) assigned session IDs, minimum and maximum bits per
second (bps), bearer type, called number, and connect speed. For a complete list of AVPs that
may be exchanged in OCRQ, OCRP, and OCCN messages, see Table 4-8.
Figure 4-18 illustrates outgoing call initiation.
Figure 4-18 L2TP Outgoing Call Initiation
Note that Figure 4-18 assumes that a L2TP tunnel has already been established between the
LAC and the LNS.
L2TP Security
Although the only inherent security provided by L2TP itself (as distinct from PPP) is tunnel
authentication and hidden AVPs, additional security can be provided by conguring the L2TP
tunnel over IPSec. IPSec can provide packet level security via the Encapsulating Security
Payload (ESP) or the Authentication Header (AH) protocols.
ESP is a protocol that can provide condentiality, data origin authentication, antireply, and data
integrity services. AH can provide data integrity, data origin authentication, and antireply
services.
Figure 4-19 shows L2TP tunnel security using IPSec.
For more information on L2TP security, see RFC 3193. For more information on IPSec, see
Chapter 8, Troubleshooting IPSec VPNs.
Remote Access
Client
LAC
PSTN/
ISDN
LNS
Service Provider
Backbone
Outgoing Call
OCCN
OCRQ
OCRP
CH01i.book Page 236 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 237
Conguring L2TPv2
Although L2TPv2 conguration is not the primary objective of this chapter, it is worthwhile to
review basic L2TPv2 conguration on Cisco routers. L2TPv2 conguration is discussed in this
section.
Figure 4-19 L2TP Tunnel Security Using IPSec
Conguring L2TP Compulsory Tunnel Mode
There are several steps in the conguration of both the LAC and the LNS in compulsory tunnel
mode. Each will be examined in turn.
Conguring the LAC
The steps involved in the conguration of the L2TP LAC are summarized below. Note that this
conguration assumes that the LAC is congured with a Primary Rate ISDN interface, together
with internal digital (MICA) modems.
Step 1 Congure the E1/T1 controllers.
Step 2 Congure global ISDN parameters.
Step 3 Congure the D channels.
Step 4 Congure parameters for asynchronous lines.
Step 5 Congure group asynchronous interfaces.
Step 6 Congure remote AAA (optional).
Step 7 Globally enable VPDNs.
Step 8 Congure VPDN groups.
The next few sections discuss each step in depth.
IPSec
Remote Access
Client
LAC
PSTN/
ISDN
LNS
Service Provider
Backbone
PPP
L2TP L2TP
PPP
CH01i.book Page 237 Friday, April 30, 2004 8:58 AM
238 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
Step 1: Congure the E1/T1 Controllers
The rst step is the conguration of the E1 or T1 controllers. This involves specifying the
framing, linecode, clock source, and timeslots. These parameters should be congured per your
service providers specications.
Example 4-1 shows an example of the conguration of an E1 Controller.
Youll notice in this conguration that only the pri-group timeslots are specied. This is because
this conguration is making use of the default framing (CRC4), linecode (HDB3), and clock
source (line). To modify framing, linecode, and clock source, use the framing {crc4 | no-
crc4}[australia], linecode {ami | hdb3}, and clock source {line | internal | loop-timed}
commands, respectively.
Step 2: Congure Global ISDN Parameters
After conguring the E1 or T1 controller, the next step is to congure global ISDN parameters.
In this case, only conguration of the global ISDN switch-type is required.
Example 4-2 shows conguration of global ISDN parameters.
The ISDN switch-type congured is Primary-net5, a switch-type common in Europe, Australia,
New Zealand, and Asia.
Again, the ISDN switch type should be congured per your service providers
recommendation.
Step 3: Congure the D Channels
The next step is to congure the ISDN D channel or channels.
Example 4-3 shows conguration of a D channel.
Example 4-1 Configuring the E1 Controller
controller E1 0/0
pri-group timeslots 1-31
Example 4-2 Configuring the Global ISDN Switch Type
isdn switch-type primary-net5
Example 4-3 Configuring the D channel
interface Serial0/0:15
no ip address
encapsulation ppp
isdn switch-type primary-net5
isdn incoming-voice modem
CH01i.book Page 238 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 239
No IP address is applied to interface serial 0/0:15 in Example 4-3 because no ISDN calls are
being terminated on this LAC. PPP encapsulation is then applied using the encapsulation ppp
command.
The ISDN switch-type is set with the command isdn switch-type primary-net5. Note that the
ISDN switch-type applied to an interface takes precedence over that applied globally, although
in this case they are the same.
The isdn incoming-voice modem causes incoming asynchronous calls to be rerouted to the
internal digital (MICA) modems.
Step 4: Congure Parameters for Asynchronous Lines
Once the D channel conguration has been completed, the next step is the conguration of the
modems and their corresponding asynchronous lines.
Example 4-4 shows conguration of the asynchronous lines.
The rst line in Example 4-4 (line 33-38) allows lines 33 to 38 to be congured in one go. Lines
33 to 38 correspond to the six internal MICA modems installed on the LAC. The show line
command can be used to conrm the line numbering of internal modems.
The next line shows the modem InOut command. The modem InOut command is used to
congure the modems so that they are able to both receive and make calls.
Following modem InOut is modem autocongure type mica. This command allows the LAC
to congure the internal modems automatically.
In the last line is the autoselect ppp command. This allows PPP to be autodetected and
congured on the line.
Step 5: Congure Group Asynchronous Interfaces
Once the modem lines have been congured, it is time to congure the corresponding
asynchronous interfaces. Logical conguration, such as IP addresses, is applied to the
asynchronous interfaces. Again, the most efcient way to congure the asynchronous interfaces
is in a group.
Example 4-4 Configuring the Asynchronous Lines
line 3338
modem InOut
modem autoconfigure type mica
autoselect ppp
CH01i.book Page 239 Friday, April 30, 2004 8:58 AM
240 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
Example 4-5 shows conguration of the asynchronous interfaces.
The rst command is no ip address. The no ip address command is required in this example
because no PPP connections from remote access clients are being terminated locally on the
LAC (rather than being tunneled to the LNS).
Next is encapsulation ppp. This command is used to apply PPP encapsulation.
The next command is async mode interactive. This allows remote users connecting to the
asynchronous interfaces to start interactive mode on the line. Should you wish to limit remote
users so that an interactive session cannot be started, the command async mode dedicated
should be used. The async mode dedicated command allows only PPP or SLIP sessions (but
not exec sessions) on the interface.
The no peer default ip address command is used to ensure that no IP address is supplied by
the LAC to the remote access client. IP addresses are supplied to remote access clients by
the LNS.
The next line of the conguration in Example 4-5 contains the command ppp authentication
chap. This command is used to congure the Challenge Handshake Authentication Protocol
(CHAP) on the asynchronous interfaces. CHAP authentication is assumed throughout this
chapter. You might be wondering why, if the PPP session from remote access clients are to be
tunneled from the LAC to the LNS, CHAP authentication is required on the LAC at all. Its
required to authenticate partially L2TP remote access clients.
When the remote access client dials in to the LAC, the LAC partially authenticates the remote
access client. This partial authentication consists of a CHAP challenge sent by the LAC and a
response from the remote access client. Contained within the response message is the remote
access clients username, and within that, its domain name (in the format @domain_name). The
domain name is then used to associate the remote access clients PPP session to the appropriate
L2TP tunnel.
Note that it is also possible to associate the remote access clients PPP session with the
appropriate tunnel using the DNIS or the complete username (with per-user VPDN). The DNIS
corresponds to the number dialed by the remote access client to connect to the LAC.
The nal command in Example 4-5 is group-range 33-38. This command is used to apply the
group-async conguration to each of the internal digital modem lines in turn.
Example 4-5 Configuring the Asynchronous Interfaces
interface Group-Async1
no ip address
encapsulation ppp
async mode interactive
no peer default ip address
ppp authentication chap
group-range 33-38
CH01i.book Page 240 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 241
Step 6: Congure Remote AAA (Optional)
The next optional step in conguring the LAC is the conguration of remote authentication,
authorization, and accounting (AAA).
Two methods that can be used for remote AAA are the Remote Authentication Dial-In User
Service (RADIUS) and Terminal Access Controller Access Control Server plus (TACACS+).
In this environment, RADIUS is more common.
PPP connections (from remote access clients and tunneled by the LAC) are terminated on the
LNS. Therefore, remote AAA is necessary on the LAC only if you are conguring per-user
VPDN or you are using tunnel denitions (tunnel conguration stored on a AAA server). If you
are terminating some PPP connections locally on the LAC rather than tunneling them to the
LNS, remote AAA may also be useful.
Example 4-6 shows a sample remote AAA conguration.
The rst line in Example 4-6 is the aaa new-model command. This command is simply used
to enable remote AAA on the LAC.
CAUTION A word of caution when using the aaa new-model command: If you congure this command
and allow your console or Telnet session to expire, you will be unable to log back into your
router. Password recovery is then required.
The next command in Example 4-6 is aaa authentication login default group radius local,
which congures the default method list for logins to the LAC. The rst authentication method
used with the default method list is RADIUS. Should the RADIUS server be unreachable, the
LAC defaults to local authentication to authenticate login users.
The default method list is applied on any lines not explicitly congured with another method
list. Note that the aaa authentication login default group radius local command is not
necessary for L2TPv2 but is included here as part of a complete AAA conguration.
Next is the aaa authentication ppp default group radius command. This command
congures the default method list for PPP authentication on the LAC. The method list species
RADIUS authentication.
Example 4-6 Configuring Remote AAA
aaa new-model
aaa authentication login default group radius local
aaa authentication ppp default group radius
aaa authorization network default group radius
aaa accounting network default start-stop group radius
radius-server host 10.20.10.5 auth-port 1645 acct-port 1646 key cisco
CH01i.book Page 241 Friday, April 30, 2004 8:58 AM
242 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
The fourth line in the conguration (aaa authorization network default group radius) is used
to congure authorization for network connections from the LAC. Once again, network
authorization is congured using the default method list. In this case, RADIUS is specied by
the method list for authorization of network connections.
Following network authorization, AAA accounting is congured for network connections using
the default method list (aaa accounting network default start-stop group radius).
Accounting is congured on start and stop events. This means that an accounting notication is
sent to the RADIUS server when a network connection is initiated. Similarly, an accounting
notication is also sent to the RADIUS server when that network connection is terminated.
The aaa accounting network default start-stop group radius command is again not
necessary for L2TPv2 but is shown as part of a complete AAA conguration.
The nal line of the conguration is the radius-server host command. This command is used
to specify the IP address of the RADIUS server (in this case 10.20.10.5). You also notice that
the port on which authentication and authorization requests are sent is UDP port 1645, with
accounting requests being sent on UDP port 1646. These two ports are the defaults for Cisco
routers, but note that some RADIUS servers might require you to congure authentication and
authorization on port 1812 and accounting on port 1813.
The nal part of the radius-server host command is the key parameter. This corresponds to the
secret key used to authenticate communications between the RADIUS server and the LAC. This
key is also used to encrypt user passwords sent to the RADIUS server.
See Case Study 1: Miscongured L2TP Tunnel Denition on an AAA RADIUS Server for
more details on tunnel denitions and Cisco.com for more details on per-user VPDN.
Step 7: Globally Enable VPDNs
The next step in the conguration of the LAC is to enable VPDNs globally, of which L2TP is
one type. Other types are L2F and PPTP.
To enable VPDNs globally, use the following command:
vpdn enable
Step 8: Congure VPDN Groups
The nal mandatory step in the conguration of the LAC is the conguration of the L2TP tunnel
itself. The conguration of the L2TP tunnel can be stored locally on the LAC in the form of a
VPDN group, or it can be stored on the RADIUS server in the form of a tunnel denition.
Example 4-7 shows an example of the conguration of a VPDN group.
CH01i.book Page 242 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 243
The rst command in Example 4-7 is vpdn search-order domain. This command is optional, and
it is used to specify that the LAC will attempt to associate the remote access clients PPP session
with an L2TP tunnel using a domain name. The default search order is DNIS, then domain.
Note that the dnis string VPDN group conguration command can be used to associate a DNIS
string (number) with an L2TP tunnel.
The second line in the conguration is the command vpdn-group 1. This command is used to
begin the conguration of the VPDN group 1. The 1 is actually the VPDN group name.
In line 3 is the request-dialin command. The request-dialin command is used to congure the
LAC to accept remote access client PPP sessions and attempt to tunnel them to a specied LNS.
Following request-dialin is the protocol l2tp command. It will come as no surprise to learn that
this command is used to specify that the VPDN protocol to be used when building tunnels is L2TP.
The fth line of the conguration is domain mjlnet.com. This command is used to congure
the VPDN group so that any remote access clients with a domain name corresponding to
mjlnet.com will have their PPP sessions tunneled to the LNS specied in this VPDN group.
Note that it is possible to specify more than one domain name per VPDN group.
The next line is the initiate-to ip 172.16.5.5 command, which is used to specify the address of
the LNS to which the tunnel will be built.
The nal command is l2tp authentication password cisco, which is used to specify the shared
secret used to authenticate the LNS to the LAC and the LAC to the LNS. In this example, the
shared secret is cisco.
Example 4-8 shows a complete basic conguration for a LAC.
Example 4-7 Configuring the VPDN Group
vpdn search-order domain
vpdn-group 1
request-dialin
protocol l2tp
domain mjlnet.com
initiate-to ip 172.16.5.5
l2tp tunnel password cisco
Example 4-8 Complete Basic LAC Configuration
CalCity_LAC#show running-config
Building configuration...
Current configuration : 1896 bytes
!
version 12.2
service nagle
no service pad
service tcp-keepalives-in
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
CH01i.book Page 243 Friday, April 30, 2004 8:58 AM
244 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
service password-encryption
!
hostname CalCity_LAC
!
logging buffered 16384 debugging
enable secret 5 $1$FLX7$fBY0xo2WPq/bpSLs/IlVw0
!
username mark password 7 05080F1C2243
ip subnet-zero
no ip source-route
!
no ip domain-lookup
!
no ip bootp server
! Enable VPDNs (including L2TP)
vpdn enable
! Match the remote access clients domain for client to tunnel assignment
vpdn search-order domain
!
! Configure the VPDN group for domain mjlnet.com to 172.16.5.5 (the LNS)
vpdn-group 1
request-dialin
protocol l2tp
domain mjlnet.com
initiate-to ip 172.16.5.5
l2tp tunnel password 7 045802150C2E
!
! Configure the PRI switch type
isdn switch-type primary-net5
!
! Configure the E1 controller
controller E1 0/0
pri-group timeslots 1-31
!
interface FastEthernet0/0
ip address 172.16.1.1 255.255.255.0
no ip redirects
no ip proxy-arp
duplex auto
speed auto
!
! Configure the D channel
interface Serial0/0:15
no ip address
encapsulation ppp
isdn switch-type primary-net5
isdn incoming-voice modem
no peer default ip address
ppp authentication chap
!
! Configure the group asynchronous interface
Example 4-8 Complete Basic LAC Configuration (Continued)
CH01i.book Page 244 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 245
Note that in Example 4-8, a static route is used for IP reachability between the LAC and the LNS.
That completes the examination of LAC conguration.
Conguring the LNS
Conguration of the LNS can be summarized as follows:
Step 1 Globally enable VPDNs.
Step 2 Congure VPDN groups.
Step 3 Congure the virtual templates.
Step 4 Create IP pool(s) and congure DNS/WINS server addresses.
Step 5 Congure either local authentication or remote AAA.
interface Group-Async1
ip unnumbered FastEthernet0/0
encapsulation ppp
async mode interactive
no peer default ip address
ppp authentication chap
group-range 33 38
!
! Static route for IP reachability to the LNS (172.16.5.5)
ip route 172.16.5.0 255.255.255.0 172.16.1.2
!
ip classless
no ip http server
ip pim bidir-enable
!
no cdp run
!
line con 0
password 7 13081D1E050910
logging synchronous
login
!
! Configure parameters for asynchronous lines
line 33 38
modem InOut
modem autoconfigure type mica
autoselect ppp
line aux 0
line vty 0 4
password 7 0456010A012458
login
!
end
Example 4-8 Complete Basic LAC Configuration (Continued)
CH01i.book Page 245 Friday, April 30, 2004 8:58 AM
246 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
Step 1: Globally Enable VPDNs
The rst step in the conguration of the LNS is to globally enable VPDNs on the LNS.
VPDNs can be globally enabled on the LNS using the following command:
vpdn enable
Step 2: Congure VPDN Groups
After globally enabling VPDNs, the next step is the conguration of the VPDN group or groups.
Example 4-9 shows the conguration of a VPDN group.
The rst line in the conguration given in Example 4-9 is the vpdn-group name command. In
this example, 1 is the VPDN group name.
The next line is the accept-dialin command. This command is used on the LNS to specify that
tunnels and sessions will be accepted from the LAC.
The next part of the conguration is the specication of the VPDN protocol. This is congured
using the protocol l2tp command.
The fourth line is the virtual-template virtual-template_number command. In this example, this
command causes any PPP sessions inbound through the tunnel from the LAC to be terminated on
virtual-access interfaces with conguration cloned (copied) from virtual template interface 1.
Virtual-access interfaces are virtual interfaces that are dynamically created as required and take
their conguration from a virtual template interface. One virtual access interface is created per
PPP session.
Once the virtual template interface has been specied, the next step is to allow termination of
VPDN tunnels from the specied LAC, using the terminate-from hostname command. In this
case, VPDN tunnels from CalCity_LAC are allowed.
The nal step is the shared L2TP tunnel password. This is congured using the l2tp
authentication password command.
If you do not wish to use tunnel authentication, it can be disabled using the no l2tp tunnel
authentication command (on both the LAC and LNS). Note that disabling L2TP tunnel
authentication is not, generally speaking, a good idea, for obvious reasons.
Example 4-9 Configuring the VPDN Groups
vpdn-group 1
accept-dialin
protocol l2tp
virtual-template 1
terminate-from hostname CalCity_LAC
l2tp tunnel password cisco
CH01i.book Page 246 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 247
Step 3: Congure the Virtual Templates
After conguring the VPDN group, the next step is the conguration of the virtual template
interface.
Example 4-10 shows the conguration for a virtual template interface.
The conguration of the virtual template interface begins with the command ip unnumbered
ethernet 0/0. This is used to specify that the IP address congured on the Ethernet 0/0 interface
should be borrowed for the virtual template interface. In this case, the LNS has only two
interfaces (see Example 4-15), but if your LNS has more than two interfaces, a loopback
interface is a better choice for use with the ip unnumbered command (it is always up).
Next is the peer default ip address pool pool_name command. This species that remote
access clients should be assigned an IP address from the specied pool, which in this example
is SKYDANCE_POOL.
Another option for IP address assignment is the Dynamic Host Conguration Protocol (DHCP).
This can be specied using the peer default ip address dhcp and ip dhcp-server
{server_name | server_ip_address} commands.
Example 4-11 shows the conguration for assigning IP addresses to remote access clients
using DHCP.
In Example 4-11, the ip dhcp-server {server_name | server_ip_address} global conguration
command is used to specify the DHCP server name or IP address. The peer default ip address
dhcp interface conguration command is then used to specify that addresses should be assigned
to clients using DHCP.
The third line in the conguration (in Example 4-10) is the ppp authentication chap
command. This command ensures that PPP sessions from remote access clients are
authenticated using CHAP.
Example 4-10 Configuring Virtual Template Interfaces
interface Virtual-Template1
ip unnumbered Ethernet1/0
peer default ip address pool SKYDANCE_POOL
ppp authentication chap
ppp multilink
Example 4-11 Assigning IP Addresses to Remote Access Clients Using DHCP
ip dhcp-server 172.16.4.1
!
interface Virtual-Template1
peer default ip address dhcp
!
CH01i.book Page 247 Friday, April 30, 2004 8:58 AM
248 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
The nal command in the conguration of virtual template is the optional ppp multilink
command. This command enables multilink PPP (MP).
Note that it is also possible to store user-specic interface conguration on a AAA server, and
this conguration is downloaded to the Home Gateway as remote access clients connect. For
some examples of this (in the form cisco-avpair = lcp:interface-cong=) refer to the
document entitled Conguring Virtual Proles on www.cisco.com.
Another command that might be useful on the virtual template interface is the mtu command.
This can help to prevent fragmentation of large packets sent over the L2TP tunnel, which can
cause high CPU overhead as fragmentation and reassembly is handled at the process level.
Fragmentation can occur because of the tunnel protocol overhead added by L2TP itself (40
bytes without sequencing).
When the mtu command is congured in conjunction with the lcp renegotiation (VPDN
group) command, the LNS is allowed to renegotiate the Maximum Receive Unit (MRU) with
the remote access client, although this is effective with only some client operating systems.
MRU is negotiated as part of LCP, and by default, LCP is negotiated only between the remote
access client and the LAC. The LAC then informs the LNS of negotiated LCP options during
L2TPv2 session setup.
NOTE See the following URL for more information on MTU tuning with L2TP:
http://www.cisco.com/en/US/tech/tk801/tk703/
technologies_tech_note09186a0080094c4f.shtml
If you have Microsoft remote access clients, it may also be worth taking a look at Microsoft
Knowledge Base articles 159211 and 314825 (available at www.microsoft.com).
Another article that may be useful if you have Microsoft or Sun remote access clients can be
found at the following URL:
http://www.cisco.com/en/US/tech/tk870/tk472/tk473/
technologies_tech_note09186a008011a218.shtml
It is also worth noting that cloning of virtual access interfaces on the LNS can cause high CPU
overhead. This can be reduced using the virtual-template template_number pre-clone number
command to preclone virtual access interfaces.
Step 4: Create IP Pools and Congure DNS/WINS Server Addresses
The next step is the conguration of the local IP address pool and BootP DNS and WINS server
addresses. Note that although in this case a local IP address pool is used, IP address assignment
via DHCP (see Step 3: Congure the Virtual Templates) or from a AAA server can also be
used. Example 4-12 shows the conguration of a local IP address pool and DNS and WINS
server addresses.
CH01i.book Page 248 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 249
In Example 4-12, an IP address pool named SKYDANCE_POOL is created. The pool name
must correspond to that given in the virtual template interface conguration. In this case, there
are 50 IP addresses in the local IP address pool (10.1.1.1 to 10.1.1.50). DNS and WINS server
addresses are also specied (10.2.2.99 and 10.2.2.100, respectively).
Step 5: Congure Either Local Authentication or Remote AAA
The last step in the conguration of the LNS is the conguration of either local authentication
or remote AAA for remote access clients.
Local authentication can be congured by simply specifying usernames and passwords.
Example 4-13 shows the conguration of usernames and passwords for local authentication.
A more scalable solution is to congure remote AAA on the LNS. In this example, RADIUS is
used for remote AAA.
Example 4-14 shows a sample conguration for remote AAA.
The aaa new-model command is used to enable AAA on the LNS.
The second command in the conguration is the aaa authentication login default group
radius local, which congures the default method list for logins to the LNS. The rst
authentication method in the default method list is RADIUS. If the RADIUS server is
unreachable, then the LNS will default to local authentication.
The aaa authentication login default group radius local command is not required for
L2TPv2 but is shown here as part of a complete AAA conguration.
Next comes the aaa authentication ppp default group radius command, which denes a
default method list for PPP. The method specied for authentication is RADIUS.
Example 4-12 Configuring the IP Address Pool and DNS/WINS Server Addresses
ip local pool SKYDANCE_POOL 10.1.1.1 10.1.1.50
async-bootp dns-server 10.2.2.99
async-bootp nbns-server 10.2.2.100
Example 4-13 Configuring Local Authentication
username TATEBAYASHI@mjlnet.com password cisco1
username joebloggs@mjlnet.com password cisco2
username ltahoe@mjlnet.com password cisco3
Example 4-14 Configuring Remote AAA
aaa new-model
aaa authentication login default group radius local
aaa authentication ppp default group radius
aaa authorization network default group radius
aaa accounting network default start-stop group radius
radius-server host 10.20.10.5 auth-port 1645 acct-port 1646 key cisco
CH01i.book Page 249 Friday, April 30, 2004 8:58 AM
250 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
The fourth line in the conguration contains the command aaa authorization network default
group radius, which congures a default method list for network connections, with RADIUS
specied for authorization.
The aaa accounting network default start-stop group radius command is next. Accounting
is congured on start and stop events. When a network connection is initiated, an accounting
notication is sent to the RADIUS server. Furthermore, when that network connection is
terminated, an accounting notication is also sent to the RADIUS server. Again, the aaa
accounting network default start-stop group radius is not required for L2TPv2 but is shown
as part of a complete AAA conguration.
The nal command is radius-server host, which species the IP address of the RADIUS
server, as well as the UDP ports for authentication/authorization and accounting (1645 and
1646, respectively).
The key parameter is the secret key used to authenticate communications between the RADIUS
server and the LNS. It is also used to encrypt user passwords sent to the RADIUS server.
Example 4-15 shows a complete basic conguration for the LNS using local authentication.
Example 4-15 Complete Basic LNS Configuration
Skydance_LNS#show running-config
Building configuration...
Current configuration : 2224 bytes
!
version 12.2
service nagle
no service pad
service tcp-keepalives-in
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
service password-encryption
!
hostname Skydance_LNS
!
logging buffered 16384 debugging
enable secret 5 $1$48vv$OokKQ69up4Kf95QMo.k5L.
!
username mark password 7 121A0C041104
! Configure the username and password database for remote access clients
username TATEBAYASHI@mjlnet.com password 7 14141B180F0B
username joebloggs@mjlnet.com password 7 00071A150754
username ltahoe@mjlnet.com password 7 1043080B0E
ip subnet-zero
no ip source-route
ip cef
!no ip domain-lookup
!
no ip bootp server
! Enable VPDNs (including L2TP)
vpdn enable
CH01i.book Page 250 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 251
!
! Configure the VPDN group for CalCity_LAC
vpdn-group 1
accept-dialin
protocol l2tp
virtual-template 1
terminate-from hostname CalCity_LAC
l2tp tunnel password 7 01100F175804
!
! Configure the DNS and WINS server addresses
async-bootp dns-server 10.2.2.99
async-bootp nbns-server 10.2.2.100
!
interface Ethernet1/0
ip address 172.16.5.5 255.255.255.0
no ip redirects
no ip proxy-arp
!
interface Ethernet1/1
ip address 10.2.2.1 255.255.255.0
no ip redirects
no ip proxy-arp
!
!
! Configure the virtual template
interface Virtual-Template1
ip unnumbered Ethernet1/0
peer default ip address pool SKYDANCE_POOL
ppp authentication chap
ppp multilink
!
! Static route for IP reachability to the LAC (CalCity_LAC)
ip route 172.16.1.0 255.255.255.0 172.16.5.1
!
! Configure the IP address pool
ip local pool SKYDANCE_POOL 10.1.1.1 10.1.1.50
ip classless
no ip http server
ip pim bidir-enable
!
no cdp run
!
line con 0
password 7 05060C032F495A logging synchronous
login
line aux 0
line vty 0 4
password 7 07022B40400C0D
login
!
end
Example 4-15 Complete Basic LNS Configuration (Continued)
CH01i.book Page 251 Friday, April 30, 2004 8:58 AM
252 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
As a nal word before completing this section, many problems can be avoided by conguring
both the LAC and the LNS incrementally. For example, when conguring the LAC, rst
congure and verify basic asynchronous dialin. Then congure and enable VPDN groups. Also,
even if the intent is to use remote AAA, it might be a good idea rst to congure local
authentication to test the VPDN conguration before introducing remote AAA.
Conguring L2TP Voluntary Tunnel Mode
Conguration of L2TP voluntary tunneling mode is similar to that of compulsory tunneling
mode. The main difference is that the Cisco router acts as the LNS, with a remote access client
acting as the LAC. The conguration of the LNS remains largely the samethe difference is
the conguration of the VPDN group.
Example 4-16 shows the conguration of the VPDN group in voluntary tunneling mode.
There are two differences in the conguration of the VPDN group when compared to that for
compulsory tunnel mode:
The terminate-from command is not required.
L2TP tunnel authentication is disabled with the command no l2tp tunnel authentication.
In this case, PPP authentication (congured on the virtual template interface using the ppp
authentication command) is used to authenticate the client/LAC.
Conguring IPSec Protection for L2TP in Compulsory Tunnel
Mode with Preshared Keys
The conguration of IPSec for L2TP with preshared keys can be broken down into six steps.
The steps are as follows:
Step 1 Congure the Internet Key Exchange (IKE) policy
Step 2 Congure the preshared key
Step 3 Congure the transform set
Step 4 Congure the crypto map
Example 4-16 VPDN Group Configuration for L2TP Voluntary Tunnel Mode
vpdn-group 1
!
accept-dialin
protocol l2tp
virtual-template 1
no l2tp tunnel authentication
CH01i.book Page 252 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 253
Step 5 Enable IPSec protection for the VPDN
Step 6 Apply the crypto map to the interface (facing the LAC)
Example 4-17 shows the conguration of IPSec on the LAC.
In highlighted line 1, IPSec protection for L2TP tunnels is congured. Note the policy name
referenced (l2tp).
Highlighted lines 2 and 3 show the conguration of the IKE policy. This policy congures
authentication with preshared keys, encryption as DES, Dife-Hellman group 1 (768-bit), and
the lifetime as 86,400 seconds (1 day). All of these parameters are the defaults, except for
preshared key authentication, and so are not displayed in the conguration.
Conguration of the preshared key (mark) and peer address (the LNS, 172.16.5.5) is shown in
highlighted line 4. Note that this preshared key (mark) is not secure, and is used for illustrative
purposes only.
The transform set is congured next (highlighted lines 5 and 6). The name of the transform set
is l2tptransform, and it species ESP DES encryption and SHA-1 authentication. Note that the
mode is congured as transport. This is because the L2TP packets are being protected, and the
L2TP tunnel terminates on the LNS.
Example 4-17 Configuring IPSec on the LAC
!
vpdn-group 1
request-dialin
protocol l2tp
domain mjlnet.com
initiate-to ip 172.16.5.5
l2tp security crypto-profile l2tp
l2tp tunnel password cisco
!
crypto isakmp policy 1
authentication pre-share
crypto isakmp key mark address 172.16.5.5
!
crypto ipsec transform-set l2tptransform esp-des esp-sha-hmac
mode transport
!
crypto map l2tpcryptomap 10 ipsec-isakmp profile l2tp
set transform-set l2tptransform
!
interface FastEthernet0/0
ip address 172.16.1.1 255.255.255.0
duplex auto
speed auto
crypto map l2tpcryptomap
!
CH01i.book Page 253 Friday, April 30, 2004 8:58 AM
254 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
Highlighted lines 7 and 8 dene the crypto map. The crypto map is called l2tpcryptomap and
species that ISAKMP will be used to establish IPSec security associations. The prole
keyword designates this crypto map as a template so that individual crypto maps can be created
on demand. The prole name is l2tp. Additionally, the set transform-set transform-set-name
command is used to specify that the transform set called l2tptransform should be used.
Finally, in highlighted line 9, the crypto map is congured on the interface (Fast Ethernet 0/0)
on which the IPSec tunnel will be established.
Conguration of the LNS is almost identical.
Example 4-18 shows the conguration of IPSec on the LNS.
As you can see, the only difference in the conguration is that the address of the LAC
(172.16.1.1) is specied as the peer address.
One additional consideration when protecting the L2TP tunnel using IPSec is the additional
IPSec tunnel overhead. This overhead can cause fragmentation of large packets transmitted
over the L2TP tunnel. See the section entitled Conguring the LNS, as well as Chapter 8 for
more details. Also see Chapter 8 if you want to congure IPSec with digital certicates instead
of preshared keys.
Example 4-18 Configuring IPSec on the LNS
vpdn enable
!
vpdn-group 1
accept-dialin
protocol l2tp
virtual-template 1
terminate-from hostname CalCity_LAC
l2tp security crypto-profile l2tp
l2tp tunnel password cisco
!
crypto isakmp policy 1
authentication pre-share
crypto isakmp key mark address 172.16.1.1
!
crypto ipsec transform-set l2tptransform esp-des esp-sha-hmac
mode transport
!
crypto map l2tpcryptomap 10 ipsec-isakmp profile l2tp
set transform-set l2tptransform
!
interface Ethernet1/0
ip address 172.16.5.5 255.255.255.0
duplex half
crypto map l2tpcryptomap
!
CH01i.book Page 254 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 255
Conguring IPSec Protection for L2TP in Voluntary Tunnel Mode with
Preshared Keys
Certain client/LACs, such as Microsoft Windows 2000, protect L2TP with IPSec by default. To
support client/LACs congured for L2TP over IPSec, the LNS must also be congured to
support IPSec.
Example 4-19 shows a sample conguration for L2TP over IPSec in voluntary tunnel mode
using preshared keys.
Again, the IPSec conguration is identical to that for compulsory tunnel mode, with the
exception that the peer address is congured as a wildcard (0.0.0.0).
Also, if you want to congure IPSec with digital certicates instead of preshared keys, see
Chapter 8.
Troubleshooting L2TPv2
If you want to troubleshoot L2TP in a fast and efcient manner, a good knowledge of the
underlying theory of operation and conguration is essential. In addition, if the LAC is
Example 4-19 Configuring L2TP over IPSec in Voluntary Tunnel Mode
vpdn enable
!
vpdn-group 1
accept-dialin
protocol l2tp
virtual-template 1
l2tp security crypto-profile l2tp
no l2tp tunnel authentication
!
crypto isakmp policy 1
authentication pre-share
crypto isakmp key mark address 0.0.0.0 0.0.0.0
!
crypto ipsec transform-set l2tptransform esp-des esp-sha-hmac
mode transport
!
crypto map l2tpcryptomap 10 ipsec-isakmp profile l2tp
set transform-set l2tptransform
!
interface Ethernet1/0
ip address 172.16.5.5 255.255.255.0
duplex half
crypto map l2tpcryptomap
!
CH01i.book Page 255 Friday, April 30, 2004 8:58 AM
256 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
receiving calls from remote access clients on dialin lines, it is also essential to have a good
knowledge of ISDN and asynchronous modems.
Before detailing end-to-end troubleshooting of L2TP, it is worth briey re-examining the
overall tunnel establishment model for L2TP.
Figure 4-20 shows the L2TP tunnel establishment model.
Figure 4-20 L2TP Tunnel Establishment
Figure 4-20 illustrates the following steps:
1 Assuming that the remote access client is using asynchronous dial to connect to the LAC,
the rst step in the tunnel establishment model is the reception of the call from the remote
access client on the LAC.
Remote Access
Client
LAC
PSTN/
ISDN
LNS
Service Provider
Backbone
1. Call
Reception
2. LCP
Negotiation
Authentication
3. Partial PPP
8. LCP Negotiation / PPP
Authentication Completed
9. NCP
Negotiation
5. Control Connection 5.Confirm Valid
Source / Protocol /
Resources
7. Virtual Template
Configuration Cloned to
Virtual Access Interface
Establishment
6. Session
Establishment
4. Associate
Domain/DNIS/
Username to Tunnel
10. PPP
Frame Forwarding
CH01i.book Page 256 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 257
During call reception, ISDN call setup messages are received on the primary rate interface
via the ISDN Q.931 protocol. Because the call from a remote access client is
asynchronous, it is switched to an internal digital (MICA) modem.
2 PPP is then autodetected on the line and LCP negotiation begins.
3 Once LCP negotiation has completed, partial PPP authentication takes place. If the
authentication protocol is CHAP, the LAC issues a CHAP challenge to the remote access
client. The remote access client replies to the CHAP challenge with a CHAP response
message.
4 The LAC parses the name eld in the response message to see whether there is a domain
name (in the form @domain_name) that corresponds to a domain specied in one of the
VPDN groups. Alternatively, the LAC uses the DNIS or the complete username (with per-
user VPDN) to associate the call with an L2TP tunnel.
5 Assuming there is no existing tunnel, the LAC begins L2TP tunnel establishment to the
LNS (specied in the VPDN group). To establish a tunnel, a control connection must be
set up.
During control connection setup, the LNS checks to see whether any of its VPDN groups
are congured to terminate a L2TP tunnel from the LAC in question. Additionally, the
LNS checks to see whether it has resources available to terminate the tunnel.
Assuming that L2TP tunnel authentication is congured, the LAC and LNS also
authenticate each other.
6 The data session that will transport PPP frames between the remote access client and the
LNS (via the LAC) is now established.
7 Following data session establishment, conguration is cloned from the virtual template
interface to the next available virtual-access interface.
8 LCP negotiation and PPP authentication are now completed.
9 As soon as LCP negotiation and PPP authentication have been completed on the LNS,
NCP negotiation begins. NCP negotiation could include the IP Control Protocol (IPCP),
and the IPX Control Protocol (IPXCP), for example.
10 Once NCP negotiation has been completed, forwarding of PPP data frames begins
between the remote access client and the LNS over the L2TP tunnel.
These ten steps detail what should happen when a L2TP tunnel is established. However, as you
can see, there are many things that can go wrong.
Before diving into the troubleshooting of L2TP, it is worth summarizing some of the potential
problems that can occur in compulsory tunnel mode.
Together, Figure 4-21 and Table 4-11 illustrate some potential problems that can occur in L2TP
compulsory tunnel mode.
CH01i.book Page 257 Friday, April 30, 2004 8:58 AM
258 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
Figure 4-21 Potential Issues with L2TP Compulsory Tunnel Mode
Remember that the problems noted in Table 4-11 are just some of the things that can go wrong.
However, if you have a good understanding of the underlying operation of L2TP and its
conguration, you should have an excellent foundation for quickly and efciently
troubleshooting L2TP end-to-end.
In Table 4-11, you will notice that some of the issues relate to the remote access client operating
system and modem. It is not the intent of this chapter to detail troubleshooting of remote access
client operating systems. Instead, this chapter focuses on the troubleshooting of L2TP on Cisco
routers.
The owchart in Figure 4-22 describes the troubleshooting process used with L2TP version 2.
You can use this owchart to access quickly the section of the chapter relevant to problems you
are experiencing on your network.
Table 4-11 Potential Problems at Each Point Along the Tunnel
Potential Problems at
the Remote Access
Client
Potential Problems at
the LAC
Potential Problems in
Service Provider
Backbone
Potential Problems at
the LNS
OS Issues Cabling issue Cabling/physical layer
issue
Cabling issue
Incorrect modem driver ISDN conguration Data link issue Data link issue
DUN miscongured Modem conguration IP connectivity broken Tunnel protocol mismatch
TCP/IP not installed Authentication IP/UDP/L2TP blocked
(ACL/Firewall)
Tunnel authentication
TCP/IP not bound to
dialup networking adapter
Tunnel protocol mismatch Resource issue
Modem Issues Wrong IP address for LNS Virtual template
misconguration
Not switched on Tunnel authentication PPP authentication
mismatch
Cabling issue AAA server issues Authentication failure
Remote Access
Client LAC
PSTN/
ISDN
LNS
Service Provider
Backbone
CH01i.book Page 258 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 259
Figure 4-22 L2TP Troubleshooting Flowchart
CH01i.book Page 259 Friday, April 30, 2004 8:58 AM
260 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
The following sections detail end-to-end troubleshooting of L2TP, beginning with call
reception on the LAC.
Call Reception on the LAC
The rst step in troubleshooting compulsory tunnel mode is to conrm that calls are being
successfully received on the LAC. This section assumes that the LAC is congured with a
Primary Rate ISDN interface, together with internal digital (MICA) modems.
Figure 4-23 illustrates reception of the remote access clients call on the LAC.
Figure 4-23 Call Reception on the LAC
Call reception on the LAC is a multistep process. Therefore, troubleshooting also consists of
several steps.
The rst step is the reception of the call on the Primary Rate ISDN interface. Therefore, the rst
thing that you need to do is to conrm that the Primary Rate ISDN interface is in fact active and
ready to receive calls. A very good command for verifying the status of the ISDN interface is
the show isdn status command.
Example 4-20 shows an example of good output from the show isdn status command.
Example 4-20 Good Output of the show isdn status Command
CalCity_LAC#show isdn status
Global ISDN Switchtype = primary-net5
ISDN Serial0/0:15 interface
dsl 0, interface ISDN Switchtype = primary-net5
Layer 1 Status:
ACTIVE
Layer 2 Status:
TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
Layer 3 Status:
0 Active Layer 3 Call(s)
Active dsl 0 CCBs = 0
The Free Channel Mask: 0xFFFF7FFF
Number of L2 Discards = 0, L2 Session ID = 2
Total Allocated ISDN CCBs = 0
CalCity_LAC#
Remote Access
Client
PSTN/
ISDN
Service Provider
Backbone
1. Call
Reception
LAC
(172.16.1.1)
LNS
(172.16.5.5)
CH01i.book Page 260 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 261
The rst highlighted line in Example 4-20 shows the globally congured isdn switch-type
(Primary-net5).
The next highlighted line shows that the ISDN switch type is congured on interface serial
0/0:15. In this case, the switchtype is primary-net 5. You should make sure that the switch type
corresponds to that specied by your service provider.
Highlighted line 3 shows the status of the physical layer of the ISDN interface. The status is
ACTIVE, indicating that physical connectivity has been established.
Highlighted line 4 shows the Layer 2 status of the interface. The status is MULTIPLE FRAME
ESTABLISHED. This is good. It indicates that the primary rate interface has established
communications with the ISDN switch at the service provider Central Ofce (CO).
The nal highlighted line shows that there are currently zero active Layer 3 calls. Of course, if
remote access clients were connected, then this would show one or more active Layer 3 calls.
That is an example of good output from the show isdn status command. Now it is time to have
a look at the output when things are not so good.
Example 4-21 shows the output of the show isdn status command when things are not so good.
The rst thing that should draw your eye as you are looking down the output is the status of
Layer 1. The status is DEACTIVATED (highlighted line 1). This indicates that there is a
problem with physical connectivity on the primary rate ISDN interface.
To gain further insight into the problem, you can use the show controller e1 0/0 command, as
demonstrated in Example 4-22.
Example 4-21 Not So Good Output of the show isdn status Command
CalCity_LAC#show isdn status
Global ISDN Switchtype = primary-net5
ISDN Serial0/0:15 interface
dsl 0, interface ISDN Switchtype = primary-net5
Layer 1 Status:
DEACTIVATED
Layer 2 Status:
TEI = 0, Ces = 1, SAPI = 0, State = TEI_ASSIGNED
Layer 3 Status:
0 Active Layer 3 Call(s)
Active dsl 0 CCBs = 0
The Free Channel Mask: 0x0
Number of L2 Discards = 0, L2 Session ID = 4
Total Allocated ISDN CCBs = 0
CalCity_LAC#
CH01i.book Page 261 Friday, April 30, 2004 8:58 AM
262 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
Highlighted line 1 shows that E1 0/0 is down. In the second highlighted line, the transmitter is
sending a remote alarm. Additionally, the third highlighted line shows that the receiver has loss
of signal.
A loss of signal usually indicates a cable problem. In this case, the cable is replaced and the
status of the controller is checked again.
Example 4-23 shows the status of the E1 controller after replacing the cable.
As you can see in the rst highlighted line, the E1 is now up. Also, in the second highlighted
line, you can see that no alarms are detected.
The show isdn status command is again used to check overall status.
Example 4-24 shows the output of the show isdn status command.
Example 4-22 show controller e1 Command Shows a Loss of Signal
CalCity_LAC#show controller e1 0/0
E1 0/0 is down.
Applique type is Channelized E1 - balanced
Transmitter is sending remote alarm.
Receiver has loss of signal.
alarm-trigger is not set
Framing is CRC4, Line Code is HDB3, Clock Source is Line.
Data in current interval (60 seconds elapsed):
0 Line Code Violations, 0 Path Code Violations
0 Slip Secs, 42 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 42 Unavail Secs
Example 4-23 show controller e1 Command Shows No Alarms
CalCity_LAC#show controller e1 0/0
E1 0/0 is up.
Applique type is Channelized E1 - balanced
No alarms detected.
alarm-trigger is not set
Framing is CRC4, Line Code is HDB3, Clock Source is Line.
Data in current interval (899 seconds elapsed):
0 Line Code Violations, 0 Path Code Violations
0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 0 Degraded Mins
0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs, 0 Unavail Secs
Example 4-24 ISDN Layer 2 Status Is Now MULTIPLE_FRAME_ESTABLISHED
CalCity_LAC#show isdn status
Global ISDN Switchtype = primary-net5
ISDN Serial0/0:15 interface
dsl 0, interface ISDN Switchtype = primary-net5
Layer 1 Status:
ACTIVE
Layer 2 Status:
TEI = 0, Ces = 1, SAPI = 0, State = MULTIPLE_FRAME_ESTABLISHED
CH01i.book Page 262 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 263
The rst highlighted line indicates that Layer 1 is now ACTIVE. Furthermore, highlighted line
2 shows that Layer 2 status is now MULTIPLE_FRAME_ESTABLISHED.
TIP One other useful command when troubleshooting ISDN Layer 2 issues is the debug isdn q921
command, which displays ISDN Q.921 messages sent between the LAC and the local ISDN
switch.
The issue has been resolved.
It is worth remembering that most E1 (and T1) controller problems are caused by incorrect
conguration of framing, line code, or clock source. Always make sure that these parameters
are congured per your service providers recommendations. Additionally, ensure that the
ISDN switch type and encapsulation are set correctly.
Now that you have veried that the Primary Rate Interface (PRI) is functioning correctly, it is
time to verify correct call reception on the interface.
ISDN call signaling is performed using the ISDN Q.931 protocol. To check that call setup is
functioning correctly, the best command to use is the debug isdn q931 command.
Example 4-25 shows some good output from the debug isdn q931 command.
Layer 3 Status:
0 Active Layer 3 Call(s)
Active dsl 0 CCBs = 0
The Free Channel Mask: 0xFFFF7FFF
Number of L2 Discards = 0, L2 Session ID = 4
Total Allocated ISDN CCBs = 0
CalCity_LAC#
Example 4-25 Good Output of the debug isdn q931 Command
CalCity_LAC#debug isdn q931
ISDN Q931 packets debugging is on
CalCity_LAC#
Feb 5 20:16:58.690 UTC: ISDN Se0/0:15: RX <- SETUP pd = 8 callref = 0x0014
Feb 5 20:16:58.690 UTC: Sending Complete
Feb 5 20:16:58.690 UTC: Bearer Capability i = 0x8090A3
Feb 5 20:16:58.694 UTC: Channel ID i = 0xA98381
Feb 5 20:16:58.694 UTC: Calling Party Number i = 0xA1, 1111, Plan:ISDN,
Type:National
Feb 5 20:16:58.694 UTC: Called Party Number i = 0xA1, 7777, Plan:ISDN,
Type:National
Feb 5 20:16:58.698 UTC: Low Layer Compat i = 0x8090A3
Feb 5 20:16:58.706 UTC: ISDN Se0/0:15: llc valid, speed 64, call type is VOICE
speed:0 async:N
Example 4-24 ISDN Layer 2 Status Is Now MULTIPLE_FRAME_ESTABLISHED (Continued)
CH01i.book Page 263 Friday, April 30, 2004 8:58 AM
264 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
In the rst highlighted line, a Call Setup message is received (RX) on the ISDN D channel
(serial 0/0:15).
Highlighted line 2 shows the number of the calling party (the remote access client). In this case,
the number of the calling party is 1111.
Highlighted line 3 shows the called party number. The called party number is the number that
the remote access client dialed to connect to the LAC (7777).
Call reception proceeds normally, and in highlighted line 4, you can see that serial interface
0/0:0 connected to 1111 (the remote access client).
The call from the remote access client has been successfully received on the ISDN interface. To
verify whether the call is successfully switched internally to the digital modems, the debug
modem command can be used.
Example 4-26 shows the output of the debug modem command.
Feb 5 20:16:58.762 UTC: ISDN Se0/0:15: TX -> CALL_PROC pd = 8 callref = 0x8014
Feb 5 20:16:58.762 UTC: Channel ID i = 0xA98381
Feb 5 20:16:58.766 UTC: ISDN Se0/0:15: TX -> ALERTING pd = 8 callref = 0x8014
Feb 5 20:16:58.766 UTC: ISDN Se0/0:15: TX -> CONNECT pd = 8 callref = 0x8014
Feb 5 20:16:58.794 UTC: ISDN Se0/0:15: RX <- CONNECT_ACK pd = 8 callref = 0x0014
Feb 5 20:16:58.802 UTC: ISDN Se0/0:15: CALL_PROGRESS: CALL_CONNECTED call id 0x14,
bchan 0, dsl 0
Feb 5 20:16:58.806 UTC: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected
to 1111
Feb 5 20:17:04.806 UTC: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected to
1111
Feb 5 20:17:28.402 UTC: %LINK-3-UPDOWN: Interface Async34, changed state to up
Feb 5 20:17:34.674 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async34,
changed state to up
CalCity_LAC#
Example 4-26 Verifying Call Reception on the Digital Modems
CalCity_LAC#debug modem
Modem control/process activation debugging is on
CalCity_LAC#
Feb 5 20:21:25.810 UTC: Modem 1/2 Mica: configured for Answer mode, with Null
signaling, 0x0 tone detection.
Feb 5 20:21:25.810 UTC: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected
to 1111
Feb 5 20:21:25.898 UTC: Modem 1/2 Mica: in modem state CALL_SETUP
Feb 5 20:21:26.978 UTC: Modem 1/2 Mica: in modem state CONNECT
Feb 5 20:21:31.374 UTC: Modem 1/2 Mica: in modem state LINK
Feb 5 20:21:31.810 UTC: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected to
1111
Feb 5 20:21:42.722 UTC: Modem 1/2 Mica: in modem state TRAINUP
Feb 5 20:21:50.718 UTC: Modem 1/2 Mica: in modem state EC_NEGOTIATING
Feb 5 20:21:51.214 UTC: Modem 1/2 Mica: in modem state STEADY
Feb 5 20:21:51.226 UTC: Modem 1/2 Mica: CONNECT at 48000/28800 (Tx/Rx), V90,
Example 4-25 Good Output of the debug isdn q931 Command (Continued)
CH01i.book Page 264 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 265
In highlighted line 1, interface serial 0/0:0 is connected to the remote access client. Soon after,
in highlighted line 2, one of the MICA modems goes off the hook.
Then in highlighted line 3, the modem is connected at a transmit and receive speed of 48,000
bps and 28,800 bps, respectively.
From highlighted line 4 to highlighted 7, the modem samples the data arriving on the line and,
in highlighted line 8, autodetects PPP.
In highlighted line 9, interface async 35 changes state to up. Interface async 35 is the logical
interface associated with the modem on line 35.
Finally, in highlighted line 10, the line protocol on interface async 35 changes state to up, and
the logical interface is connected to the remote access client.
If the debug modem command does not produce any output, two things that you should check
are that the isdn incoming voice-modem command is congured on the ISDN D channel and
that the modem InOut command is congured on the modem lines.
At this point, call reception has been successful, and the LAC is ready to begin PPP negotiation
with the remote access client.
LAPM, V42bis
Feb 5 20:21:51.946 UTC: TTY35: DSR came up
Feb 5 20:21:51.946 UTC: tty35: Modem: IDLE->(unknown)
Feb 5 20:21:51.950 UTC: TTY35: Autoselect started
Feb 5 20:21:51.950 UTC: TTY35: create timer type 0, 120 seconds
Feb 5 20:21:53.354 UTC: TTY35: Autoselect sample 7E
Feb 5 20:21:53.354 UTC: TTY35: Autoselect sample 7EFF
Feb 5 20:21:53.354 UTC: TTY35: Autoselect sample 7EFF7D
Feb 5 20:21:53.358 UTC: TTY35: Autoselect sample 7EFF7D23
Feb 5 20:21:53.358 UTC: TTY35 Autoselect cmd: ppp negotiate
Feb 5 20:21:53.358 UTC: TTY35: destroy timer type 0
Feb 5 20:21:53.358 UTC: TTY35: EXEC creation
Feb 5 20:21:53.362 UTC: TTY35: create timer type 1, 600 seconds
Feb 5 20:21:53.362 UTC: TTY35: destroy timer type 1
Feb 5 20:21:53.362 UTC: TTY35: no timer type 0 to destroy
Feb 5 20:21:55.362 UTC: %LINK-3-UPDOWN: Interface Async35, changed state to up
Feb 5 20:22:00.454 UTC: Modem 1/2 Mica: PPP escape_map: Tx map = 0, Rx map = 0
Feb 5 20:22:01.626 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async35,
changed state to up
Feb 5 20:22:12.330 UTC: Modem 1/2 Mica: in modem state SS_SHIFTINGSPEED
Feb 5 20:22:15.046 UTC: Modem 1/2 Mica: in modem state STEADY
Feb 5 20:22:15.054 UTC: Modem 1/2 Mica: SpeedShifted to 48000/31200 (Tx/Rx)
CalCity_LAC#
Example 4-26 Verifying Call Reception on the Digital Modems (Continued)
CH01i.book Page 265 Friday, April 30, 2004 8:58 AM
266 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
Troubleshooting PPP on the LAC
If call reception on the LAC is successful, you are now ready to move on to debugging PPP
negotiation between the remote access client and the LAC.
Before examining the relevant troubleshooting commands for PPP negotiation, it is worth briey
looking at what form PPP negotiation takes between the remote access client and the LAC.
Figure 4-24 illustrates PPP negotiation between the remote access client and the LAC.
Figure 4-24 PPP Negotiation Between the Remote Access Client and the LAC
PPP negotiation consists of LCP negotiation, authentication (optionally), and NCP negotiation.
LCP negotiation and partial authentication take place between the remote access client and the
LAC. NCP negotiation occurs between the remote access client and the LNS.
LCP Negotiation Between the Remote Access Client and the LAC
The rst part of PPP negotiation is LCP negotiation. There are a number of useful commands
you can use when verifying PPP negotiation on the LAC.
The rst command that can be used is the show user command, as demonstrated in
Example 4-27.
Example 4-27 Verifying Active Lines on the LAC
CalCity_LAC#show user
Line User Host(s) Idle Location
* 0 con 0 idle 00:00:00
36 tty 36 ltahoe@mjl Async interface -
Interface User Mode Idle Peer Address
CalCity_LAC#
Remote Access
Client
LAC
(172.16.1.1)
PSTN/
ISDN
LNS
(172.16.5.5)
Service Provider
Backbone
1. Call
Reception
2. LCP
Negotiation
Authentication
3. Partial PPP
4. Associate
Domain/DNIS/
Username with Tunnel
CH01i.book Page 266 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 267
Highlighted line 1 shows that user ltahoe@mjlnet.com is connected to line 36.
If more detail is required about the user, use the show caller user command.
Example 4-28 shows output from the show caller user command.
In highlighted line 1, you can see that remote access client ltahoe@mjlnet.com is connected
to asynchronous line 36, and that the service running on that line is PPP.
Additionally, in highlighted line 2, you can see that the LCP state is open. This means that LCP
has been successfully negotiated between remote access client ltahoe@mjlnet.com and
the LAC.
In highlighted line 2, you can see that partial CHAP authentication has taken place between the
LAC and the remote access client.
If LCP negotiation is unsuccessful between the LAC and the remote access client, you can use
the debug ppp negotiation command to see what went wrong.
Example 4-28 Verifying Caller Information on the LAC
CalCity_LAC#show caller user ltahoe@mjlnet.com
User: ltahoe@mjlnet.com, line tty 36, service Async
Active time 00:01:00, Idle time 00:00:04
Timeouts: Absolute Idle Idle
Session Exec
Limits: - - 00:10:00
Disconnect in: - - -
TTY: Line 36, running PPP on As36
Line: Baud rate (TX/RX) is 115200/115200, no parity, 2 stopbits, 8 databits
Status: Ready, Active, No Exit Banner, Async Interface Active
HW PPP Support Active, Modem Detected
Capabilities: Modem Callout, Modem RI is CD,
Line usable as async interface, Modem Autoconfigure
Integrated Modem
Modem State: Ready, Modem Configured
User: ltahoe@mjlnet.com, line As36, service PPP
Active time 00:00:50, Idle time 00:00:00
Timeouts: Absolute Idle
Limits: - -
Disconnect in: - -
PPP: LCP Open, CHAP (<- none)
IP: Local 172.16.1.1
VPDN: NAS , MID 13, MID Unknown
HGW , NAS CLID 0, HGW CLID 0, tunnel open
Counts: 84 packets input, 5453 bytes, 0 no buffer
4 input errors, 4 CRC, 0 frame, 0 overrun
66 packets output, 2322 bytes, 0 underruns
0 output errors, 0 collisions, 3 interface resets
CalCity_LAC#
CH01i.book Page 267 Friday, April 30, 2004 8:58 AM
268 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
Examples 4-29 to 4-41 show successful LCP negotiation between LAC and remote access
client.
In highlighted line 1, interface serial 0/0:0 is connected to the remote access client (1111).
Shortly thereafter, in highlighted line 2, interface async 33 changes state to up.
In highlighted line 3, the PPP phase is ESTABLISHING. PPP negotiation is about to
commence. The rst stage of PPP negotiation is LCP negotiation.
The LAC now sends an LCP Congure-Request (CONFREQ) to the remote access client as
shown in Example 4-30 (the O indicates that the CONFREQ is outgoing).
The CONFREQ in Example 4-30 is used by the LAC to indicate to the remote access client
which LCP options it would like to congure. The LCP options are shown in the ve following
lines. These options are ACCM, Authentication Protocol, MagicNumber, Protocol Field
Compression (PFC), and Address and Control Field Compression (ACFC).
It is worth taking a quick look at these options. The rst LCP option specied in the CONFREQ
is ACCM. The ACCM LCP option is used to specify how data sent over the link will be escaped.
Escaping data sent over the link ensures that certain data patterns that could otherwise be
misinterpreted by the receiving modem as commands are avoided. In this case, the ACCM that
the LAC would like to use on the link has a value of 0x000A0000. This particular ACCM is
often used over lines with XON/XOFF software ow control.
The hexadecimal number contained within the parentheses (0x0206000A0000) is the
numerical value of the LCP option (0x02, ACCM), the overall length (0x06), and the ACCM
itself (0x000A0000). Note that the option number, length, and value encoding format is
common to PPP options.
Example 4-29 Successful LCP Negotiation Between the LAC and the Remote Access Client
CalCity_LAC#debug ppp negotiation
PPP protocol negotiation debugging is on
CalCity_LAC#
Feb 5 20:39:21.269 UTC: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected
to 1111
Feb 5 20:39:27.265 UTC: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected to
1111
Feb 5 20:39:50.837 UTC: %LINK-3-UPDOWN: Interface Async33, changed state to up
Feb 5 20:39:50.837 UTC: As33 PPP: Treating connection as a dedicated line
Feb 5 20:39:50.837 UTC: As33 PPP: Phase is ESTABLISHING, Active Open [0 sess, 0 load]
Example 4-30 Outbound CONFREQ from the LAC
Feb 5 20:39:50.837 UTC: As33 LCP: O CONFREQ [Closed] id 20 len 25
Feb 5 20:39:50.837 UTC: As33 LCP: ACCM 0x000A0000 (0x0206000A0000)
Feb 5 20:39:50.837 UTC: As33 LCP: AuthProto CHAP (0x0305C22305)
Feb 5 20:39:50.837 UTC: As33 LCP: MagicNumber 0x12072037 (0x050612072037)
Feb 5 20:39:50.841 UTC: As33 LCP: PFC (0x0702)
Feb 5 20:39:50.841 UTC: As33 LCP: ACFC (0x0802)
CH01i.book Page 268 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 269
The second LCP option in the CONFREQ is authentication protocol (0x03). The authentication
protocol specied is MD5 CHAP (0xC22305).
MagicNumber is next (0x05). This LCP option is used to detect looped back links. The actual
MagicNumber sent by the LAC is 0x12072037.
PFC (0x07) is the fourth LCP option in the CONFREQ. This indicates that the LAC can receive
PPP protocol elds that are compressed.
The nal LCP option specied is ACFC (0x08). PPP frames are normally sent with leading
HDLC Address and Control elds. In this case, the LAC is telling the remote access client that
it can receive PPP frames without these HDLC elds.
The remote access client responds with an LCP Congure-Ack (CONFACK) (incoming [I]) as
shown in Example 4-31.
In the CONFACK (Example 4-31), the remote access client acknowledges the CONFREQ sent
by the LAC (note that it has the same id [20] as the CONFREQ in Example 4-30). Once again,
the next ve lines in the output show the LCP options contained in the CONFACK. The LCP
options contained in CONFACK are almost exactly the same as those in the LACs CONFREQ.
There is, however, one minor difference. You will notice that the MagicNumber specied is
different than that specied in the LACs CONFREQ message. This is good. If the number were
the same, it would indicate a looped line.
In Example 4-32, the remote access client sends an LCP CONFREQ to the LAC.
The LCP options contained in the remote access clients CONFREQ (Example 4-32) have all
been described previously, with the exception of Callback (0x0D), Multilink-Maximum-
Example 4-31 Inbound CONFACK from the Remote Access Client
Feb 5 20:39:50.961 UTC: As33 LCP: I CONFACK [REQsent] id 20 len 25
Feb 5 20:39:50.965 UTC: As33 LCP: ACCM 0x000A0000 (0x0206000A0000)
Feb 5 20:39:50.965 UTC: As33 LCP: AuthProto CHAP (0x0305C22305)
Feb 5 20:39:50.965 UTC: As33 LCP: MagicNumber 0x12072037 (0x050612072037)
Feb 5 20:39:50.965 UTC: As33 LCP: PFC (0x0702)
Feb 5 20:39:50.965 UTC: As33 LCP: ACFC (0x0802)
Example 4-32 Inbound CONFREQ from the Remote Access Client
Feb 5 20:39:51.829 UTC: As33 LCP: I CONFREQ [ACKrcvd] id 2 len 50
Feb 5 20:39:51.829 UTC: As33 LCP: ACCM 0x00000000 (0x020600000000)
Feb 5 20:39:51.829 UTC: As33 LCP: MagicNumber 0x06E435E9 (0x050606E435E9)
Feb 5 20:39:51.829 UTC: As33 LCP: PFC (0x0702)
Feb 5 20:39:51.829 UTC: As33 LCP: ACFC (0x0802)
Feb 5 20:39:51.829 UTC: As33 LCP: Callback 6 (0x0D0306)
Feb 5 20:39:51.829 UTC: As33 LCP: MRRU 1614 (0x1104064E)
Feb 5 20:39:51.833 UTC: As33 LCP: EndpointDisc 1 Local
Feb 5 20:39:51.833 UTC: As33 LCP: (0x13170190699D7655924F3481F6E9E6D7)
Feb 5 20:39:51.833 UTC: As33 LCP: (0x6EFD0A00000000)
CH01i.book Page 269 Friday, April 30, 2004 8:58 AM
270 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
Reconstructed-Receive-Unit (MRRU) (0x11), and Multilink-Endpoint-Discriminator (ED)
(0x13).
With the Callback option, the remote access client indicates that it would like to be called back.
The MRRU and ED options are used with MP.
The LAC responds by sending a Congure-Reject (CONFREJ) to the remote access client, as
demonstrated in Example 4-33. This CONFREJ is used by the LAC to reject both Callback and
MRRU.
Shortly after sending the CONFREJ, the LAC sends another CONFREQ to the remote access
client, as shown in Example 4-34.
Again, the LCP options specied by the LAC in the CONFREQ in Example 4-34 are ACCM,
Authentication Protocol, MagicNumber, PFC, and ACFC. This is simply a reiteration of the rst
CONFREQ sent by the LAC.
In Example 4-35, the remote access client again acknowledges the LCP options sent in the
LACs CONFREQ.
Example 4-33 Outbound CONFREJ from the LAC
Feb 5 20:39:51.833 UTC: As33 LCP: O CONFREJ [ACKrcvd] id 2 len 11
Feb 5 20:39:51.833 UTC: As33 LCP: Callback 6 (0x0D0306)
Feb 5 20:39:51.833 UTC: As33 LCP: MRRU 1614 (0x1104064E)
Feb 5 20:39:52.837 UTC: As33 LCP: TIMEout: State ACKrcvd
Example 4-34 Second CONFREQ from the LAC
Feb 5 20:39:52.837 UTC: As33 LCP: O CONFREQ [ACKrcvd] id 21 len 25
Feb 5 20:39:52.837 UTC: As33 LCP: ACCM 0x000A0000 (0x0206000A0000)
Feb 5 20:39:52.837 UTC: As33 LCP: AuthProto CHAP (0x0305C22305)
Feb 5 20:39:52.837 UTC: As33 LCP: MagicNumber 0x12072037 (0x050612072037)
Feb 5 20:39:52.837 UTC: As33 LCP: PFC (0x0702)
Feb 5 20:39:52.837 UTC: As33 LCP: ACFC (0x0802)
Example 4-35 Second CONFACK from the Remote Access Client
Feb 5 20:39:52.949 UTC: As33 LCP: I CONFACK [REQsent] id 21 len 25
Feb 5 20:39:52.949 UTC: As33 LCP: ACCM 0x000A0000 (0x0206000A0000)
Feb 5 20:39:52.949 UTC: As33 LCP: AuthProto CHAP (0x0305C22305)
Feb 5 20:39:52.953 UTC: As33 LCP: MagicNumber 0x12072037 (0x050612072037)
Feb 5 20:39:52.953 UTC: As33 LCP: PFC (0x0702)
Feb 5 20:39:52.953 UTC: As33 LCP: ACFC (0x0802)
Feb 5 20:39:54.837 UTC: As33 LCP: TIMEout: State ACKrcvd
CH01i.book Page 270 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 271
The LAC now sends yet another CONFREQ with the same LCP options, as shown in Example 4-36.
Once again, in Example 4-37, the remote access client acknowledges the CONFREQ from the
LAC with a CONFACK.
What is happening here? Why is the LAC resending the CONFREQ in Examples 4-34 and
4-36? The answer can be found by looking a little more closely at the debug output. Notice the
timeouts all the way back in Examples 4-33 and 4-35LCP is timing out on the LAC.
The LAC receives another CONFREQ from the remote access client in Example 4-38. This
contains the same options specied in the previous CONFREQ (Example 4-32).
Once again, the LAC rejects both the Callback and MRRU options by sending a CONFREJ
message, as shown in Example 4-39.
Example 4-36 Third CONFREQ from the LAC
Feb 5 20:39:54.837 UTC: As33 LCP: O CONFREQ [ACKrcvd] id 22 len 25
Feb 5 20:39:54.837 UTC: As33 LCP: ACCM 0x000A0000 (0x0206000A0000)
Feb 5 20:39:54.837 UTC: As33 LCP: AuthProto CHAP (0x0305C22305)
Feb 5 20:39:54.837 UTC: As33 LCP: MagicNumber 0x12072037 (0x050612072037)
Feb 5 20:39:54.837 UTC: As33 LCP: PFC (0x0702)
Feb 5 20:39:54.837 UTC: As33 LCP: ACFC (0x0802)
Example 4-37 Third CONFACK from the Remote Access Client
Feb 5 20:39:54.945 UTC: As33 LCP: I CONFACK [REQsent] id 22 len 25
Feb 5 20:39:54.945 UTC: As33 LCP: ACCM 0x000A0000 (0x0206000A0000)
Feb 5 20:39:54.945 UTC: As33 LCP: AuthProto CHAP (0x0305C22305)
Feb 5 20:39:54.945 UTC: As33 LCP: MagicNumber 0x12072037 (0x050612072037)
Feb 5 20:39:54.945 UTC: As33 LCP: PFC (0x0702)
Feb 5 20:39:54.945 UTC: As33 LCP: ACFC (0x0802)
Example 4-38 Second CONFREQ from the Remote Access Client
Feb 5 20:39:55.829 UTC: As33 LCP: I CONFREQ [ACKrcvd] id 3 len 50
Feb 5 20:39:55.829 UTC: As33 LCP: ACCM 0x00000000 (0x020600000000)
Feb 5 20:39:55.829 UTC: As33 LCP: MagicNumber 0x06E435E9 (0x050606E435E9)
Feb 5 20:39:55.829 UTC: As33 LCP: PFC (0x0702)
Feb 5 20:39:55.829 UTC: As33 LCP: ACFC (0x0802)
Feb 5 20:39:55.829 UTC: As33 LCP: Callback 6 (0x0D0306)
Feb 5 20:39:55.829 UTC: As33 LCP: MRRU 1614 (0x1104064E)
Feb 5 20:39:55.829 UTC: As33 LCP: EndpointDisc 1 Local
Feb 5 20:39:55.833 UTC: As33 LCP: (0x13170190699D7655924F3481F6E9E6D7)
Feb 5 20:39:55.833 UTC: As33 LCP: (0x6EFD0A00000000)
Example 4-39 The LAC Again Rejects Callback and MRRU
Feb 5 20:39:55.833 UTC: As33 LCP: O CONFREJ [ACKrcvd] id 3 len 11
Feb 5 20:39:55.833 UTC: As33 LCP: Callback 6 (0x0D0306)
Feb 5 20:39:55.833 UTC: As33 LCP: MRRU 1614 (0x1104064E)
CH01i.book Page 271 Friday, April 30, 2004 8:58 AM
272 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
Another CONFREQ is received from the remote access client in Example 4-40.
The CONFREQ shown in Example 4-40 is the third sent by the remote access client, but if you
look closely, you will see that it no longer contains the Callback and MRRU options rejected
by the LAC (compare with Example 4-38).
In Example 4-41, the LAC acknowledges the remote access clients CONFREQ, and the LCP
state changes to Open.
In highlighted line 1 (Example 4-41), the LAC acknowledges the LCP options in the remote
access clients last CONFREQ (Example 4-40) with a CONFACK message.
Finally, in highlighted line 2, the LCP state changes to Open. LCP negotiation has succeeded.
At this point, the LAC and the remote access client are ready to begin the second stage of PPP
negotiation, authentication.
Note that LCP negotiation will fail if the LAC and the remote access client do not agree on the
conguration of LCP options. LCP negotiation failure can occur for a number of reasons, the
most common being failure to agree an authentication protocol. This would occur, for example,
if the LAC was congured to authenticate using only CHAP, but the remote access client was
congured to authenticate using only PAP.
Example 4-40 Third CONFREQ from the Remote Access Client
Feb 5 20:39:55.945 UTC: As33 LCP: I CONFREQ [ACKrcvd] id 4 len 43
Feb 5 20:39:55.945 UTC: As33 LCP: ACCM 0x00000000 (0x020600000000)
Feb 5 20:39:55.945 UTC: As33 LCP: MagicNumber 0x06E435E9 (0x050606E435E9)
Feb 5 20:39:55.945 UTC: As33 LCP: PFC (0x0702)
Feb 5 20:39:55.945 UTC: As33 LCP: ACFC (0x0802)
Feb 5 20:39:55.945 UTC: As33 LCP: EndpointDisc 1 Local
Feb 5 20:39:55.945 UTC: As33 LCP: (0x13170190699D7655924F3481F6E9E6D7)
Feb 5 20:39:55.949 UTC: As33 LCP: (0x6EFD0A00000000)
Example 4-41 The LAC Sends a CONFACK, and the LCP State Changes to Open
Feb 5 20:39:55.949 UTC: As33 LCP: O CONFACK [ACKrcvd] id 4 len 43
Feb 5 20:39:55.949 UTC: As33 LCP: ACCM 0x00000000 (0x020600000000)
Feb 5 20:39:55.949 UTC: As33 LCP: MagicNumber 0x06E435E9 (0x050606E435E9)
Feb 5 20:39:55.949 UTC: As33 LCP: PFC (0x0702)
Feb 5 20:39:55.949 UTC: As33 LCP: ACFC (0x0802)
Feb 5 20:39:55.949 UTC: As33 LCP: EndpointDisc 1 Local
Feb 5 20:39:55.949 UTC: As33 LCP: (0x13170190699D7655924F3481F6E9E6D7)
Feb 5 20:39:55.949 UTC: As33 LCP: (0x6EFD0A00000000)
Feb 5 20:39:55.953 UTC: As33 LCP: State is Open
CalCity_LAC#
CH01i.book Page 272 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 273
Partial PPP Authentication Fails on the LAC
Once you have veried that LCP negotiation between the LAC and a remote access client has
been successful, the next stage is to verify that partial PPP authentication completes
successfully.
To examine the PPP authentication sequence between the LAC and the remote access client,
you can again use the debug ppp negotiation command.
Before taking a look at an authentication failure between the LAC and a remote access client,
it is useful to examine the output of the debug ppp negotiation command when authentication
is successful. Note that the debug ppp authentication command can also be used for this
purpose.
In Example 4-42, debug ppp negotiation shows successful authentication between the LAC
and the remote access client. Only the relevant portion of the output is shown.
PPP negotiation between the LAC and a remote access client consists of two stages, LCP
negotiation and partial PPP authentication. In highlighted line 1, you will notice that LCP
negotiation has been successful and the LCP state has changed to open. This is the point at
which PPP authentication begins.
In highlighted line 2, the PPP phase changes to AUTHENTICATING. In highlighted line 3,
the LAC sends a CHAP challenge to the remote access client. Notice the O herethis indicates
that the challenge is outgoing.
The remote access client replies to the CHAP challenge with a CHAP response in highlighted
line 4. This CHAP response message is incoming, which is indicated by the I in the output. Note
that the remote access client identies itself as ltahoe@mjlnet.com. This is the remote access
clients user name.
Example 4-42 Successful Partial PPP Authentication on the LAC
CalCity_LAC#debug ppp negotiation
PPP protocol negotiation debugging is on
CalCity_LAC#
Feb 5 20:39:55.953 UTC: As33 LCP: State is Open
Feb 5 20:39:55.953 UTC: As33 PPP: Phase is AUTHENTICATING, by this end
[0 sess, 0 load]
Feb 5 20:39:55.953 UTC: As33 CHAP: O CHALLENGE id 6 len 32 from "CalCity_LAC"
Feb 5 20:39:56.065 UTC: As33 LCP: I IDENTIFY [Open] id 5 len 18 magic 0x06E435E9
MSRASV5.00
Feb 5 20:39:56.081 UTC: As33 LCP: I IDENTIFY [Open] id 6 len 25 magic 0x06E435E9 MSRAS-
1-MLEWIS
Feb 5 20:39:56.097 UTC: As33 CHAP: I RESPONSE id 6 len 37
from "ltahoe@mjlnet.com"
Feb 5 20:39:56.097 UTC: As33 PPP: Phase is FORWARDING [0 sess, 0 load]
Feb 5 20:39:57.117 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async33,
changed state to up
CalCity_LAC#
CH01i.book Page 273 Friday, April 30, 2004 8:58 AM
274 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
Then in highlighted line 5, the line protocol on interface async 36 changes state to up.
What is going on here? The LAC received the CHAP response from the remote access client,
and you might have expected it to send back either a success or failure message, but it sent
neither. The reason for this is that the remote access client is only partially authenticated on
LAC. In other words, the LAC challenges the remote access client, receives the response, and
uses the domain name contained within the response to associate the remote access client with
an L2TP tunnel to the LNS. It is the LNS that completes authentication and sends either a
success or a failure message back to the remote access client. In Example 4-42, partial
authentication has completed successfully.
Before moving on to examine the output of the debug ppp negotiation command when partial
authentication is not so successful, it is worth having another quick look at the output in
Example 4-42. Specically, take a look at the output between highlighted lines 3 and 4. You will
notice two LCP Identify messages from the remote access client. The LCP Identify messages
(0x0C, Identication) allow a remote access client to identify itself to its PPP peer (the LAC).
In this case, the remote access client informs the LAC that it is a Microsoft client running RAS
version 5 and that the computer name is MLEWIS.
Now you know what a successful partial authentication sequence looks like, it is time to
examine what happens when partial authentication is not successful.
Example 4-43 shows the output of the debug ppp negotiation command when partial
authentication is not successful. Note that only the relevant portion of the debug output is
shown.
Example 4-43 Unsuccessful Partial PPP Authentication on the LAC
CalCity_LAC#debug ppp negotiation
PPP protocol negotiation debugging is on
CalCity_LAC#
Feb 5 20:44:02.449 UTC: As34 LCP: State is Open
Feb 5 20:44:02.449 UTC: As34 PPP: Phase is AUTHENTICATING, by this end
[0 sess, 0 load]
Feb 5 20:44:02.449 UTC: As34 CHAP: O CHALLENGE id 6 len 32 from "CalCity_LAC"
Feb 5 20:44:02.569 UTC: As34 LCP: I IDENTIFY [Open] id 5 len 18 magic 0x4F3947BA
MSRASV5.00
Feb 5 20:44:02.585 UTC: As34 LCP: I IDENTIFY [Open] id 6 len 25 magic 0x4F3947BA
MSRAS-1-MLEWIS
Feb 5 20:44:02.601 UTC: As34 CHAP: I RESPONSE id 6 len 37
from "ltahoe@mjlnet.com"
Feb 5 20:44:02.601 UTC: As34 PPP: Phase is FORWARDING [0 sess, 0 load]
Feb 5 20:44:02.605 UTC: As34 PPP: Phase is AUTHENTICATING [0 sess, 0 load]
Feb 5 20:44:02.605 UTC: As34 CHAP: O FAILURE id 6 len 25 msg is
"MD/DES compare failed"
Feb 5 20:44:02.609 UTC: As34 PPP: Phase is TERMINATING [0 sess, 0 load]
Feb 5 20:44:02.609 UTC: As34 LCP: O TERMREQ [Open] id 22 len 4
Feb 5 20:44:02.725 UTC: As34 LCP: I TERMACK [TERMsent] id 22 len 4
Feb 5 20:44:02.725 UTC: As34 LCP: State is Closed
Feb 5 20:44:02.729 UTC: As34 PPP: Phase is DOWN [0 sess, 0 load]
Feb 5 20:44:02.729 UTC: As34 PPP: Phase is ESTABLISHING, Passive Open
CH01i.book Page 274 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 275
Highlighted line 1 shows the LCP state changing to OPEN. This indicates that LCP negotiation
has completed successfully.
Shortly thereafter, in highlighted line 2, the PPP phase changes to AUTHENTICATING.
Then, in highlighted line 3, the LAC sends a CHAP challenge to the remote access client. The
remote access client responds with a CHAP response in highlighted line 4. Again, you can see
that the remote access client identies itself as ltahoe@mjlnet.com. So far so good.
But now something goes wrong. Highlighted line 5 shows the LAC sending a CHAP failure
message to the remote access client. What is going on here? Should not PPP authentication be
completed on the LNS? Why is the LAC sending a CHAP failure message?
Once CHAP authentication has failed, things start to go downhill rapidly. In highlighted line 6,
the LAC sends a Terminate-Request (TERMREQ). As the name implies, this message is used
by a PPP peer to indicate its desire to terminate the connection.
In highlighted line 7, the remote access client responds with a Terminate-Ack (TERMACK).
The remote access client has acknowledged the TERMREQ, and the PPP connection is about
to be closed.
Highlighted line 8 shows the PPP phase changing state to down. Then in highlighted line 9,
interface async 34 goes down. The connection has been terminated. What went wrong? A bit
more digging is necessary.
The next command to use is debug vpdn event. This command will give you more insight into
what is happening.
When the remote access client reconnects to the LAC, the debug vpdn event command is used,
as shown in Example 4-44.
[0 sess, 0 load]
Feb 5 20:44:02.729 UTC: As34 LCP: State is Listen
Feb 5 20:44:02.821 UTC: %ISDN-6-DISCONNECT: Interface Serial0/0:0 disconnected from
1111 , call lasted 35 seconds
Feb 5 20:44:04.729 UTC: %LINK-5-CHANGED: Interface Async34, changed state to reset
Feb 5 20:44:04.729 UTC: As34 LCP: State is Closed
Feb 5 20:44:04.729 UTC: As34 PPP: Phase is DOWN [0 sess, 0 load]
Feb 5 20:44:09.729 UTC: %LINK-3-UPDOWN: Interface Async34, changed state to down
Feb 5 20:44:09.729 UTC: As34 LCP: State is Closed
CalCity_LAC#
Example 4-44 LAC Cannot Find a Tunnel for Domain mjlnet.com
CalCity_LAC#debug vpdn event
VPDN events debugging is on
CalCity_LAC#
Feb 5 20:44:54.501 UTC: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected
to 1111
Feb 5 20:45:00.497 UTC: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected
Example 4-43 Unsuccessful Partial PPP Authentication on the LAC (Continued)
CH01i.book Page 275 Friday, April 30, 2004 8:58 AM
276 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
Highlighted line 1 in Example 4-44 shows interface serial 0/0:0 connected to the remote access
client (1111).
Then in highlighted line 2, interface async 35 changes state to up. The remote access client is
now connected to the internal digital modem.
This is when things start to get interesting. Highlighted line 3 shows the LAC obtaining the
DNIS (7777). Remember, this is the number that the remote access client dialed to connect to
the LAC.
In highlighted line 4, the LAC tries to associate the remote access clients domain name
(obtained during authentication) to a L2TP tunnel. The remote access clients domain name is
mjlnet.com.
Something goes wrong in highlighted line 5. This line reveals that either authorization failed or
there was a local tunnel problem. This indicates that the LAC was unable to associate the
domain (mjlnet.com) with a L2TP tunnel.
Having failed to associate the domain name with a tunnel, the LAC then tries to associate the
DNIS with a tunnel (highlighted line 6). Unfortunately, as highlighted line 7 reveals, once again
either authorization has failed or the DNIS could not be associated with a tunnel.
In this case, authorization is not the problem (for more about this, see the case studies at the end
of the chapter). The problem, therefore, must relate to the failure of the LAC to associate either
the domain name or the DNIS to a tunnel. This, however, does not explain the PPP failure
message sent by the LAC to the remote access client in Example 4-43.
Highlighted line 8 in Example 4-44, shows the message Continue PPP authentication for
ltahoe@mjlnet.com. This message is quite revealing. It shows that having failed to associate
the domain name or the DNIS to an L2TP tunnel, the LAC is now trying to locally complete
authentication of the remote access client. Unfortunately, this local authentication fails, and in
to 1111
Feb 5 20:45:24.345 UTC: %LINK-3-UPDOWN: Interface Async35, changed state to up
Feb 5 20:45:29.605 UTC: As35 VPDN: Got DNIS string 7777
Feb 5 20:45:29.605 UTC: As35 VPDN: Looking for tunnel -- mjlnet.com --
Feb 5 20:45:29.609 UTC: VPDN/mjlnet.com: Authorization failed, could not
talk to AAA server or local tunnel problem
Feb 5 20:45:29.609 UTC: As35 VPDN: Looking for tunnel -- dnis:7777 --
Feb 5 20:45:29.609 UTC: VPDN/dnis:7777: Authorization failed, could not talk to
AAA server or local tunnel problem
Feb 5 20:45:29.613 UTC: As35 VPDN: Continue PPP authentication for
ltahoe@mjlnet.com
Feb 5 20:45:30.141 UTC: %ISDN-6-DISCONNECT: Interface Serial0/0:0 disconnected
from 1111 , call lasted 35 seconds
Feb 5 20:45:33.553 UTC: %LINK-5-CHANGED: Interface Async35, changed state to reset
Feb 5 20:45:38.553 UTC: %LINK-3-UPDOWN: Interface Async35, changed state to down
CalCity_LAC#
Example 4-44 LAC Cannot Find a Tunnel for Domain mjlnet.com (Continued)
CH01i.book Page 276 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 277
highlighted line 9, interface serial 0/0:0 is disconnected from the remote access client. Finally,
in highlighted line 10, interface async 36 changes state to down.
The problem is clear. The LAC is unable to associate the remote access clients domain name
or the DNIS to a tunnel. The LAC is congured to associate domain name with the L2TP tunnel,
so this would indicate that either the remote access clients domain name is incorrectly
congured or the domain name specied in the VPDN group is wrong.
It should be clear from the output in Example 4-44 that the remote access clients domain name
(mjlnet.com) is in fact correctly congured. The problem, therefore, must be with the VPDN
group.
The conguration of the LAC is examined and the problem is revealed. Example 4-45 shows
the incorrect conguration for the VPDN group domain name on the LAC. Note that only the
relevant portion of the output is shown.
As you can see, the domain name congured for the VPDN group (disco.com) is not consistent
with the remote access clients domain name (mjlnet.com). The issue is resolved by modifying
the domain name congured under the VPDN group.
Example 4-46 shows reconguration of the domain name under the VPDN group.
When the remote access client reconnects to the LAC, L2TP tunnel establishment succeeds.
This is veried using the show vpdn tunnel all command.
Example 4-47 shows the successful establishment of the L2TP tunnel between the LAC and
the LNS.
Example 4-45 VPDN Group Configuration
CalCity_LAC#show running-config
Building configuration...
!
vpdn-group 1
request-dialin
protocol l2tp
domain disco.com
initiate-to ip 172.16.5.5
l2tp tunnel password 7 060506324F41
!
Example 4-46 Reconfiguration of the Domain Name
CalCity_LAC#conf t
Enter configuration commands, one per line. End with CNTL/Z.
CalCity_LAC(config)#vpdn-group 1
CalCity_LAC(config-vpdn)#request-dialin
CalCity_L(config-vpdn-req-in)#no domain disco.com
CalCity_L(config-vpdn-req-in)#domain mjlnet.com
CalCity_L(config-vpdn-req-in)#exit
CalCity_LAC#
CH01i.book Page 277 Friday, April 30, 2004 8:58 AM
278 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
As you can see in highlighted line 1, one tunnel and one session have been established. The
tunnel state (established) is shown in highlighted line 2.
Highlighted lines 3 and 4 show the LNSs name (Skydance_LNS), IP address (172.16.5.5), and
UDP port on which the tunnel is established (1701).
Additionally, the local LAC name (CalCity_LAC), IP address (172.16.1.1), and UDP port on
which the tunnel is established (1701) are shown in highlighted lines 5 and 6. The issue has been
resolved.
L2TPv2 Tunnel Establishment Failure
Once the inbound call has been successfully received on the LAC, and the domain name, DNIS,
or complete username (if you are using per-user VPDN) has been successfully matched, the
next stage (assuming that it has not already been set up) is to initiate tunnel setup to the LNS.
Figure 4-25 illustrates initiation of L2TP tunnel setup initiation from the LAC to the LNS.
The rst thing that happens during the tunnel setup process is that the LAC sends a SCCRQ
message to the LNS. Upon receipt of the SCCRQ message, the LNS checks that it is from a
valid source and that sufcient resources are available. If these conditions are met, the LNS
responds to the SCCRQ with a SCCRP message. This indicates to the LAC to the LNS is
willing to proceed with tunnel setup. Note, however, that if the LNS is not congured to
terminate L2TP tunnels from the LAC in question, it simply discards the message.
Example 4-47 Verifying Successful L2TP Tunnel Establishment
CalCity_LAC#show vpdn tunnel all
L2TP Tunnel Information Total tunnels 1 sessions 1
Tunnel id 19773 is up, remote id is 37111, 1 active sessions
Tunnel state is established, time since change 00:00:14
Remote tunnel name is Skydance_LNS
Internet Address 172.16.5.5, port 1701
Local tunnel name is CalCity_LAC
Internet Address 172.16.1.1, port 1701
34 packets sent, 16 received
5201 bytes sent, 772 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
%No active L2F tunnels
%No active PPTP tunnels
%No active PPPoE tunnels
CalCity_LAC#
CH01i.book Page 278 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 279
Figure 4-25 L2TP Tunnel Setup Initiation
When the LAC receives the SCCRP, it then responds with a SCCN. This indicates successful
tunnel setup. Once the control connection is set up, data session establishment can take place.
Before taking a look at how tunnel setup can fail, it is worth examining successful tunnel setup,
using the debug vpdn l2x-events command.
Example 4-48 shows the output of the debug vpdn l2x-events command. This output shows
successful tunnel setup. Note that only the relevant portion of the output is shown.
Example 4-48 Successful L2TPv2 Tunnel Setup
CalCity_LAC#debug vpdn l2x-events
L2X protocol events debugging is on
CalCity_LAC#
Feb 5 23:50:34.992 UTC: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected
to 1111
Feb 5 23:50:40.988 UTC: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected
to 1111
Feb 5 23:51:04.592 UTC: %LINK-3-UPDOWN: Interface Async38, changed state to up
Feb 5 23:51:09.848 UTC: Tnl 63403 L2TP: SM State idle
Feb 5 23:51:09.848 UTC: Tnl 63403 L2TP: O SCCRQ
Feb 5 23:51:09.848 UTC: Tnl 63403 L2TP: Tunnel state change from idle to
wait-ctl-reply
Feb 5 23:51:09.852 UTC: Tnl 63403 L2TP: SM State wait-ctl-reply
Feb 5 23:51:09.856 UTC: Tnl 63403 L2TP: I SCCRP from Skydance_LNS
Feb 5 23:51:09.856 UTC: Tnl 63403 L2TP: Got a challenge from remote peer,
Skydance_LNS
Remote Access
Client
LAC
(172.16.1.1)
PSTN/
ISDN
LNS
(172.16.5.5)
Service Provider
Backbone
1. Call
Reception
2. LCP
Negotiation
Authentication
3. Partial PPP
5. Control Connection 5. Confirm Valid
Source / Protocol /
Resources
Establishment
4. Associate
Domain/DNIS/
Username with Tunnel
CH01i.book Page 279 Friday, April 30, 2004 8:58 AM
280 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
In highlighted line 1, interface serial 0/0:0 his connected to the remote access client (1111), and
in highlighted line 2, interface async 38 changes state to up. The remote access clients call has
been received on the LAC.
Highlighted line 3 shows the rst L2TP message activity, with the LAC sending an outgoing
(O) SCCRQ to the LNS. The LNS responds with an SCCRP in highlighted line 4. Note the
name of the LNS, Skydance_LNS. In highlighted line 5, the LAC reports successful tunnel
authentication. The SCCCN is sent to the LNS in highlighted line 6. The control connection is
now established. To conrm this, use the show vpdn tunnel all command, as demonstrated in
Example 4-49.
Feb 5 23:51:09.856 UTC: Tnl 63403 L2TP: Got a response from remote peer, Skydance_LNS
Feb 5 23:51:09.856 UTC: Tnl 63403 L2TP: Tunnel Authentication success
Feb 5 23:51:09.856 UTC: Tnl 63403 L2TP: Tunnel state change from wait-ctl-reply
to established
Feb 5 23:51:09.856 UTC: Tnl 63403 L2TP: O SCCCN to Skydance_LNS tnlid 52441
Feb 5 23:51:09.860 UTC: Tnl 63403 L2TP: SM State established
CalCity_LAC#
Example 4-49 Verifying L2TP Tunnel Setup
CalCity_LAC#show vpdn tunnel all
L2TP Tunnel Information Total tunnels 1 sessions 1
Tunnel id 12471 is up, remote id is 42221, 1 active sessions
Tunnel state is established, time since change 00:01:09
Remote tunnel name is Skydance_LNS
Internet Address 172.16.5.5, port 1701
Local tunnel name is CalCity_LAC
Internet Address 172.16.1.1, port 1701
48 packets sent, 43 received
6898 bytes sent, 2436 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
%No active L2F tunnels
%No active PPTP tunnels
%No active PPPoE tunnels
CalCity_LAC#
Example 4-48 Successful L2TPv2 Tunnel Setup (Continued)
CH01i.book Page 280 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 281
Highlighted line 1 shows that one tunnel and one session have been established. In highlighted
line 2, the remote tunnel name is shown. It is the name of the LNS, Skydance_LNS. Below
that, in highlighted line 3, the IP address of the LNS (172.16.5.5), and UDP port on which the
connection to the LNS has been made (1701) are shown.
Highlighted lines 4 and 5 show the local end of the L2TP tunnel. The local tunnel name is the
name of the LAC (CalCity_LAC). The local IP address (172.16.1.1) is also shown, together
with the local UDP port number on which the connection has been established (1701).
Below that is a plethora of information, including the number of packets and bytes sent and
received, the latest control channel Ns (Next sent) and Nr (Next received), the local and remote
receive window sizes, the retransmission time, unsent and resend queue sizes, the total number
of resends and ZLB Acks sent, retransmission time distribution (1, 2, 4, 8 seconds, and so on),
and nally the number of sessions disconnected because of a lack of resources.
Example 4-49 showed successful tunnel setup. Now it is time to examine what happens when
tunnel establishment is not so successful.
L2TP tunnel establishment can fail for a number of reasons, including:
There is no IP connectivity between the LAC and the LNS. This can be tested using ping.
You should also verify that there are no access lists (or rewalls) blocking L2TP itself
(UDP port 1701).
The LNSs IP address is incorrectly specied on the LAC. Check this by examining the
IP address for the LNS congured using the initiateto ip LNS_address command under
the VPDN group. If you are using tunnel denitions, also check the IP address specied
on the AAA server.
The LNS does not recognize the LAC. Verify this by checking that the LACs name is
specied correctly with the terminate-from hostname LAC_name under the VPDN
group.
The LNS is not congured to terminate L2TP tunnels (there is a VPDN protocol
mismatch).
There is an L2TP tunnel authentication failure.
This section examines troubleshooting a VPDN protocol mismatch, as well as L2TP tunnel
authentication failure.
VPDN Protocol Mismatch
If there is a VPDN protocol mismatch between the LAC and the LNS, L2TP tunnel
establishment will fail. Use the debug vpdn l2x-events command to troubleshoot this issue.
CH01i.book Page 281 Friday, April 30, 2004 8:58 AM
282 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
Examples 4-50 to 4-53 show the output of the debug vpdn l2x-events command when tunnel
setup is not successful.
Highlighted line 1 (Example 4-50) shows that serial interface 0/0:0 is connected to the remote
access client (1111), and in highlighted line 2, interface async 37 changes state to up.
In Example 4-51, the LAC sends a SCCRQ message to the LNS.
The LAC now resends the SCCRQ, as demonstrated in Example 4-52.
Example 4-50 L2TPv2 Tunnel Setup Is Unsuccessful
CalCity_LAC#debug vpdn l2x-events
L2X protocol events debugging is on
CalCity_LAC#
Feb 6 00:04:10.573 UTC: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected
to 1111
Feb 6 00:04:16.573 UTC: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected
to 1111
Feb 6 00:04:53.101 UTC: %LINK-3-UPDOWN: Interface Async37, changed state to up
CalCity_LAC#
Feb 6 00:04:58.417 UTC: Tnl 12380 L2TP: SM State idle
Example 4-51 LAC Sends a SCCRQ
Feb 6 00:04:58.417 UTC: Tnl 12380 L2TP: O SCCRQ
Feb 6 00:04:58.421 UTC: Tnl 12380 L2TP: Tunnel state change from idle to
wait-ctl-reply
Feb 6 00:04:58.421 UTC: Tnl 12380 L2TP: SM State wait-ctl-reply
Example 4-52 LAC Resends the SCCRQ
Feb 6 00:04:59.421 UTC: Tnl 12380 L2TP: O Resend SCCRQ, flg TLS, ver 2, len 136,
tnl 0, cl 0, ns 0, nr 0
Feb 6 00:04:59.421 UTC: Tnl 12380 L2TP: Control channel retransmit delay set to
1 seconds
Feb 6 00:05:00.421 UTC: Tnl 12380 L2TP: O Resend SCCRQ, flg TLS, ver 2, len 136,
tnl 0, cl 0, ns 0, nr 0
Feb 6 00:05:00.421 UTC: Tnl 12380 L2TP: Control channel retransmit delay set to
2 seconds
Feb 6 00:05:02.421 UTC: Tnl 12380 L2TP: O Resend SCCRQ, flg TLS, ver 2, len 136,
tnl 0, cl 0, ns 0, nr 0
Feb 6 00:05:02.421 UTC: Tnl 12380 L2TP: Control channel retransmit delay set to
4 seconds
Feb 6 00:05:06.421 UTC: Tnl 12380 L2TP: O Resend SCCRQ, flg TLS, ver 2, len 136,
tnl 0, cl 0, ns 0, nr 0
Feb 6 00:05:06.421 UTC: Tnl 12380 L2TP: Control channel retransmit delay set to
8 seconds
Feb 6 00:05:14.421 UTC: Tnl 12380 L2TP: O Resend SCCRQ, flg TLS, ver 2, len 136,
tnl 0, cl 0, ns 0, nr 0
Feb 6 00:05:22.421 UTC: Tnl 12380 L2TP: O Resend SCCRQ, flg TLS, ver 2, len 136,
tnl 0, cl 0, ns 0, nr 0
Feb 6 00:05:30.421 UTC: Tnl 12380 L2TP: O Resend SCCRQ, flg TLS, ver 2, len 136,
CH01i.book Page 282 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 283
Highlighted line 1 (Example 4-52) shows the LAC resending the SCCRQ. Shortly thereafter,
in highlighted line 2, the SCCRQ is again resent to the LAC. Clearly the LNS is not responding
to the SCCRQ messages sent by the LAC. The LAC continues resending the SCCRQ in
highlighted lines 3, 4, 5, 6, 7, and 8.
One thing to notice as the LAC repeatedly resends the SCCRQ message is how the LAC
increases the retransmit delay between successive SCCRQ messages. Between the rst and fth
retransmissions, the retransmit delay increases from 1 second to 8 seconds, shown between the
highlighted lines. Finally, as shown in Example 4-53, the LAC shuts down the tunnel.
In highlighted line 1 (Example 4-53), the L2TP tunnel is shut down. Then in highlighted line 2,
interface async 37 changes state to down. Tunnel establishment has failed.
You can see from the output of debug vpdn l2x-events that the LAC was sending L2TP
SCCRQ messages to the LNS, but there was no response from the LNS.
The conguration of the VPDN group on the LNS is now examined. Example 4-54 shows the
output of the show running-cong command on the LNS. Only the relevant portion of the
output is shown.
As you can see, highlighted line 2 shows that the LNS is correctly congured to terminate
tunnels from the LAC (CalCity_LAC).
tnl 0, cl 0, ns 0, nr 0
Feb 6 00:05:38.153 UTC: %ISDN-6-DISCONNECT: Interface Serial0/0:0 disconnected
from 1111 , call lasted 87 seconds
Feb 6 00:05:38.421 UTC: Tnl 12380 L2TP: O Resend SCCRQ, flg TLS, ver 2, len 136,
tnl 0, cl 0, ns 0, nr 0
Example 4-53 LAC Shuts Down the Tunnel
Feb 6 00:05:39.865 UTC: Tnl 12380 L2TP: Shutdown tunnel
Feb 6 00:05:39.865 UTC: Tnl 12380 L2TP: Tunnel state change from wait-ctl-reply
to idle
Feb 6 00:05:41.861 UTC: %LINK-5-CHANGED: Interface Async37, changed state to reset
Feb 6 00:05:46.861 UTC: %LINK-3-UPDOWN: Interface Async37, changed state to down
CalCity_LAC#
Example 4-54 Verifying VPDN Group Configuration
Skydance_LNS#show running-config
Building configuration...
!
vpdn-group 1
accept-dialin
protocol l2f
virtual-template 1
terminate-from hostname CalCity_LAC
!
Example 4-52 LAC Resends the SCCRQ (Continued)
CH01i.book Page 283 Friday, April 30, 2004 8:58 AM
284 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
Highlighted line 1, however, shows that the LNS is unfortunately congured to terminate not
L2TP but instead L2F tunnels. There is no way that is going to work. The VPDN group needs
to be recongured to terminate L2TP instead of L2F tunnels.
Example 4-55 shows reconguration of the VPDN group to terminate L2TP tunnels.
In highlighted line 1, the protocol is changed to L2TP.
One thing to notice in the reconguration of the VPDN group is that after the protocol has been
modied to L2TP, it is also necessary to re-enter the hostname of the LAC from which the
tunnel will be terminated (highlighted line 2).
After the tunnel protocol on the LNS is recongured, the remote access client reconnects to the
LAC. This time tunnel setup is successful. Successful tunnel establishment is veried using the
show vpdn tunnel all command. Example 4-56 shows the output of the show vpdn tunnel all
command after successful tunnel establishment.
Example 4-55 Reconfiguration of the VPDN Group
Skydance_LNS#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Skydance_LNS(config)#vpdn-group 1
Skydance_LNS(config-vpdn)#accept-dialin
Skydance_(config-vpdn-acc-in)#protocol l2tp
Skydance_(config-vpdn-acc-in)#exit
Skydance_LNS(config-vpdn)#terminate-from hostname CalCity_LAC
Skydance_LNS(config-vpdn)#exit
Skydance_LNS#
Example 4-56 Verifying L2TPv2 Tunnel Setup
CalCity_LAC#show vpdn tunnel all
L2TP Tunnel Information Total tunnels 1 sessions 1
Tunnel id 41497 is up, remote id is 22228, 1 active sessions
Tunnel state is established, time since change 00:00:57
Remote tunnel name is Skydance_LNS
Internet Address 172.16.5.5, port 1701
Local tunnel name is CalCity_LAC
Internet Address 172.16.1.1, port 1701
49 packets sent, 35 received
6778 bytes sent, 1924 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
%No active L2F tunnels
%No active PPTP tunnels
%No active PPPoE tunnels
CalCity_LAC#
CH01i.book Page 284 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 285
In highlighted line 1, you can see that one L2TP tunnel and one session have been established
successfully. The remote tunnel name is shown in highlighted line 2 (Skydance_LNS).
The IP address of the LNS (172.16.5.5), along with the UDP port (1701) on which the L2TP
connection has been made, is shown in highlighted line 3.
The local hostname (CalCity_LAC) is shown in highlighted line 4. In the next line, the IP
address of the local host, along with the UDP port upon which the L2TP connection has been
made, is shown.
Tunnel Authentication Failure
If tunnel authentication is being used between the LAC and the LNS (and it should be),
authentication failure is another possible cause of tunnel establishment failure.
Before diving into an examination of the output of the applicable show and debug commands,
it is worth re-examining the mechanics of L2TP tunnel setup with particular emphasis on
authentication.
When the LAC sends the SCCRQ message to the LNS to initiate control connection (tunnel)
setup, included with it is an authentication challenge.
The LNS responds to the SCCRQ with an SCCRP. Contained within the SCCRP are two things
that are directly relevant to tunnel authentication:
A response to the authentication challenge sent by the LAC in the SCCRQ.
An authentication challenge from the LNS.
The LAC receives the SCCRP and authenticates the response from the LNS. If the response is
no good, the LAC responds with a StopCCN. The StopCCN, as the name implies, is used to
inform the LNS that the control connection is to be torn down.
If the authentication response from the LNS is good, the LAC responds with a SCCCN. The
SCCCN contains the response to the challenge in the SCCRP. When the LNS receives the
SCCCN, it authenticates the response. If the response is no good, it noties the LAC using a
StopCCN message.
Once the LNS has successfully authenticated the LAC, the control connection is successfully
established, and session establishment can begin. That is what should happen, in theory.
To begin, have a look at what happens in practice by rst examining the output of the debug
vpdn l2x-events command when successful tunnel setup is successful. This output will then be
compared to output of the same command when tunnel setup does not succeed because of an
authentication failure.
CH01i.book Page 285 Friday, April 30, 2004 8:58 AM
286 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
Examples 4-57 to 4-60 show the output of the debug vpdn l2x-events command when tunnel
setup is successful. Only the relevant portion of the output is shown.
Highlighted line 1 shows interface serial 0/0:0 connected to the remote access client (1111). In
highlighted line 2, interface async 35 changes state to up. The remote access client is connected
to one of the LACs internal digital modems.
An SCCRQ is then sent by the LAC to the LNS, as demonstrated in Example 4-58. Remember
that this SCCRQ contains an authentication challenge.
In Example 4-59, the LNS responds with an SCCRP.
In highlighted line 1 (Example 4-59), the LNS responds to the SCCRQ with an SCCRP.
Highlighted lines 2 and 3 show that the LAC has received a challenge from the remote peer
(Skydance_LNS), together with a response. Both the challenge and response are contained
within the SCCRP.
The rst thing that LAC does is to examine the response from the LNS. This is the point at
which, if the response is incorrect, the LAC will send a StopCCN to the LNS.
Example 4-57 L2TP Tunnel Authentication Succeeds
CalCity_LAC#debug vpdn l2x-events
L2X protocol events debugging is on
CalCity_LAC#
Feb 6 00:17:21.462 UTC: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected
to 1111
Feb 6 00:17:27.462 UTC: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected
to 1111
Feb 6 00:17:50.994 UTC: %LINK-3-UPDOWN: Interface Async35, changed state to up
Feb 6 00:17:56.266 UTC: Tnl 63312 L2TP: SM State idle
Example 4-58 LAC Sends a SCCRQ
Feb 6 00:17:56.266 UTC: Tnl 63312 L2TP: O SCCRQ
Feb 6 00:17:56.266 UTC: Tnl 63312 L2TP: Tunnel state change from idle to
wait-ctl-reply
Feb 6 00:17:56.266 UTC: Tnl 63312 L2TP: SM State wait-ctl-reply
Example 4-59 LNS Responds with a SCCRP
Feb 6 00:17:56.274 UTC: Tnl 63312 L2TP: I SCCRP from Skydance_LNS
Feb 6 00:17:56.274 UTC: Tnl 63312 L2TP: Got a challenge from remote peer,
Skydance_LNS
Feb 6 00:17:56.274 UTC: Tnl 63312 L2TP: Got a response from remote peer, Skydance_LNS
Feb 6 00:17:56.274 UTC: Tnl 63312 L2TP: Tunnel Authentication success
Feb 6 00:17:56.274 UTC: Tnl 63312 L2TP: Tunnel state change from wait-ctl-reply to
Established
CH01i.book Page 286 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 287
Happily, in highlighted line 4, you can see that tunnel authentication has been a success.
Because the response in the SCCRP was good, the LAC sends an SCCCN to the LNS in
Example 4-60.
The SCCCN shown in Example 4-50 contains the LACs response to the challenge contained
within the SCCRP. The LNS authenticates the response, and if this is unsuccessful, it sends a
StopCCN to the LAC.
No such message is received from the LNS, implying that authentication was successful. The
LAC can now begin session setup (not shown).
That is successful tunnel setup including authentication. What happens when things do not go
so well? By using the debug vpdn l2x-events command, the sequence of events can again be
examined.
Examples 4-61 to 4-65 show the output of the debug vpdn l2x-events command when tunnel
setup is unsuccessful.
Interface serial 0/0:0 is shown connected to the remote access client (1111) in highlighted line 1.
Highlighted line 2 shows interface async 38 changing state to up. The remote access client is
now connected to the internal digital modem on line 38.
The LAC now sends an SCCRQ to the LNS, as shown in Example 4-62. Remember, this
SCCRQ contains an authentication challenge.
Example 4-60 LAC Sends an SCCN
Feb 6 00:17:56.274 UTC: Tnl 63312 L2TP: O SCCCN to Skydance_LNS tnlid 62661
Feb 6 00:17:56.278 UTC: Tnl 63312 L2TP: SM State established
Feb 6 00:17:56.282 UTC: Tnl/Cl 63312/26 L2TP: Session FS enabled
Feb 6 00:17:56.282 UTC: Tnl/Cl 63312/26 L2TP: Session state change from idle to
wait-for-tunnel
Feb 6 00:17:56.282 UTC: As35 Tnl/Cl 63312/26 L2TP: Create session
Feb 6 00:17:56.282 UTC: Tnl 63312 L2TP: SM State established
Example 4-61 L2TP Tunnel Authentication Fails
CalCity_LAC#debug vpdn l2x-events
L2X protocol events debugging is on
CalCity_LAC#
Feb 6 00:23:05.702 UTC: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected
to 1111
Feb 6 00:23:11.702 UTC: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected
to 1111
Feb 6 00:23:35.270 UTC: %LINK-3-UPDOWN: Interface Async38, changed state to up
CalCity_LAC#
Feb 6 00:23:40.530 UTC: Tnl 19591 L2TP: SM State idle
CH01i.book Page 287 Friday, April 30, 2004 8:58 AM
288 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
The LNS responds with a SCCRP, as shown in Example 4-63.
Highlighted line 1 (Example 4-63) shows an inbound SCCRP from the LNS (Skydance_LNS).
The response to the challenge in the SCCRQ and the LNSs own challenge to the LAC are
contained within the SCCRP, as shown in highlighted lines 2 and 3.
But take a look at highlighted line 4. The LAC has examined the response from the LNS, and
an authentication failure has resulted.
Further information is revealed in highlighted lines 5 and 6. Highlighted line 5 shows the MD5
hash (response) that the LAC was expecting from the LNS in the SCCRP. Highlighted line 6
shows the MD5 hash that was in fact received. As you can see, they are quite different, and so
authentication failed.
Unsurprisingly, the LAC now terminates the control connection by sending a StopCCN
message to the LNS, as demonstrated in Example 4-64.
The L2TP tunnel is nally shut down in Example 4-65.
Example 4-62 LAC Sends a SCCRQ
Feb 6 00:23:40.530 UTC: Tnl 19591 L2TP: O SCCRQ
Feb 6 00:23:40.534 UTC: Tnl 19591 L2TP: Tunnel state change from idle to
wait-ctl-reply
Feb 6 00:23:40.534 UTC: Tnl 19591 L2TP: SM State wait-ctl-reply
Example 4-63 LNS Responds with a SCCRP
Feb 6 00:23:40.538 UTC: Tnl 19591 L2TP: I SCCRP from Skydance_LNS
Feb 6 00:23:40.538 UTC: Tnl 19591 L2TP: Got a challenge from remote peer,
Skydance_LNS
Feb 6 00:23:40.538 UTC: Tnl 19591 L2TP: Got a response from remote peer, Skydance_LNS
Feb 6 00:23:40.538 UTC: Tnl 19591 L2TP: Tunnel auth failed for Skydance_LNS
Feb 6 00:23:40.538 UTC: Tnl 19591 L2TP: Expected
AD 08 DF AD 63 44 1A 57 85 56 B3 D5 83 A6 35 33
Feb 6 00:23:40.542 UTC: Tnl 19591 L2TP: Got
5D ED C2 31 4D 33 CF 82 33 06 E0 61 E0 BB 2A 2C
Example 4-64 LAC Sends a StopCCN
Feb 6 00:23:40.542 UTC: Tnl 19591 L2TP: O StopCCN to Skydance_LNS tnlid 37558
Feb 6 00:23:40.542 UTC: Tnl 19591 L2TP: Tunnel state change from wait-ctl-reply to
shutting-down
Example 4-65 L2TP Tunnel Is Shut Down
Feb 6 00:23:40.546 UTC: Tnl 19591 L2TP: Shutdown tunnel
Feb 6 00:23:40.546 UTC: Tnl 19591 L2TP: Tunnel state change from shutting-down to
idle
Feb 6 00:23:40.702 UTC: %ISDN-6-DISCONNECT: Interface Serial0/0:0 disconnected
from 1111 , call lasted 35 seconds
CH01i.book Page 288 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 289
Highlighted line 1 (Example 4-65) shows that the tunnel has now been shut down, and in
highlighted line 2, interface serial 0/0:0 is disconnected from the remote access client. Finally,
in highlighted line 3, interface async 38 changes state to down. The tunnel setup attempt has
failed, and the connection has been terminated.
Although the output in Example 4-63 shows authentication failing on the LAC, that does not
necessarily indicate that the tunnel password is incorrectly congured on the LNS. It could be
that the password is incorrectly congured on the LAC, and the LAC is simply expecting a hash
calculated using an incorrect password.
Because service password-encryption is enabled (and tunnel passwords are encrypted in the
LAC and LNSs conguration les), it is impossible to know whether the password is
incorrectly congured on the LAC or the LNS. The password must, therefore, by recongured
on both.
Example 4-66 shows the reconguration of the L2TP tunnel password on the LAC and the LNS.
After the L2TP tunnel passwords on the LAC and the LNS are recongured, the remote access
client reconnects. This time, L2TP tunnel setup is successful. This is conrmed using the show
vpdn tunnel all command.
Example 4-67 shows the output of the show vpdn tunnel all command.
Highlighted line 1 shows that one tunnel and one session have been successfully established.
Highlighted lines 2 and 3 show the hostname of the remote peer (Skydance_LNS), along with
Feb 6 00:23:42.550 UTC: %LINK-5-CHANGED: Interface Async38, changed state to reset
Feb 6 00:23:49.414 UTC: %LINK-3-UPDOWN: Interface Async38, changed state to down
CalCity_LAC#
Example 4-66 Reconfiguration of the L2TP Tunnel Password on the LAC and LNS
! On the LAC:
Calcity_LAC#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Calcity_LAC (config)#vpdn-group 1
Calcity_LAC(config-vpdn)#l2tp tunnel password cisco
Calcity_LAC(config-vpdn)#exit
Calcity_LAC#
! On the LNS:
Skydance_LNS#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Skydance_LNS(config)#vpdn-group 1
Skydance_LNS(config-vpdn)#l2tp tunnel password cisco
Skydance_LNS(config-vpdn)#exit
Skydance_LNS#
Example 4-65 L2TP Tunnel Is Shut Down (Continued)
CH01i.book Page 289 Friday, April 30, 2004 8:58 AM
290 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
its IP address and the UDP port over which the connection has been established (172.16.5.5 and
1701, respectively).
Highlighted lines 4 and 5 show the local hostname (Calcity_LAC), as well as the local IP
address and the UDP port over which the connection was established (172.16.1.1 and 1701).
L2TPv2 Session Establishment Failure
As soon as tunnel establishment has succeeded, session setup can begin. If session setup is not
successful, user trafc will not be passed over the tunnel between the LAC and the LNS.
L2TP session setup is illustrated in Figure 4-26.
To establish the data session, the LAC sends an ICRQ message. Assuming that sufcient
resources are available, the LNS replies with an ICRP. Finally, the LAC sends an ICCN
message to the LNS. The data session is now established.
Before looking at session setup failure, it is worth examining successful session setup using the
debug vpdn l2x-events command.
Example 4-68 shows the output of the debug vpdn l2x-events command.
Example 4-67 Verifying Successful L2TP Tunnel Setup
CalCity_LAC#show vpdn tunnel all
L2TP Tunnel Information Total tunnels 1 sessions 1
Tunnel id 5078 is up, remote id is 57551, 1 active sessions
Tunnel state is established, time since change 00:00:27
Remote tunnel name is Skydance_LNS
Internet Address 172.16.5.5, port 1701
Local tunnel name is CalCity_LAC
Internet Address 172.16.1.1, port 1701
46 packets sent, 28 received
6628 bytes sent, 1556 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
%No active L2F tunnels
%No active PPTP tunnels
%No active PPPoE tunnels
CalCity_LAC#
CH01i.book Page 290 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 291
Figure 4-26 L2TP Session Establishment
Example 4-68 Successful L2TP Session Establishment
CalCity_LAC#debug vpdn l2x-events
L2X protocol events debugging is on
CalCity_LAC#
Feb 5 23:50:85.862 UTC: %ISDN-6-CONNECT: Interface Serial0/0:1 is now connected
to 1111
Feb 5 23:51:06.550 UTC: %LINK-3-UPDOWN: Interface Async35, changed state to up
Feb 5 23:51:09.860 UTC: Tnl 63403 L2TP: SM State established
Feb 5 23:51:09.864 UTC: Tnl/Cl 63403/22 L2TP: Session FS enabled
Feb 5 23:51:09.864 UTC: Tnl/Cl 63403/22 L2TP: Session state change from idle
to wait-for-tunnel
Feb 5 23:51:09.864 UTC: As38 Tnl/Cl 63403/22 L2TP: Create session
Feb 5 23:51:09.864 UTC: Tnl 63403 L2TP: SM State established
Feb 5 23:51:09.864 UTC: As38 Tnl/Cl 63403/22 L2TP: O ICRQ to Skydance_LNS 52441/0
Feb 5 23:51:09.868 UTC: As38 Tnl/Cl 63403/22 L2TP: Session state change from
wait-for-tunnel to wait-reply
Feb 5 23:51:09.872 UTC: As38 Tnl/Cl 63403/22 L2TP: O ICCN to Skydance_LNS 52441/22
Feb 5 23:51:09.876 UTC: As38 Tnl/Cl 63403/22 L2TP: Session state change from
wait-reply to established
Feb 5 23:51:10.868 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Async38,
changed state to up
CalCity_LAC#
Remote Access
Client
LAC
(172.16.1.1)
PSTN/
ISDN
LNS
(172.16.5.5)
Service Provider
Backbone
1. Call
Reception
2. LCP
Negotiation
Authentication
3. Partial PPP
5. Control Connection 5. Confirm Valid
Source / Protocol /
Resources
Establishment
6. Session
Establishment
4. Associate
Domain/DNIS/
Username with Tunnel
CH01i.book Page 291 Friday, April 30, 2004 8:58 AM
292 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
In highlighted line 1, interface serial 0/0:1 is connected to the 1111. Then in highlighted line 2,
interface async 35 changes state to up. The remote access client is connected to the digital
modem on line 35.
The LAC now initiates data session setup with the LNS by sending an ICRQ (highlighted line 3).
Note that no SCCRQ message is sent. This is because the SCCRQ message is used during L2TP
tunnel (control connection) setup but is not necessary when establishing a new session within
a tunnel that already exists.
In highlighted line 4, an ICCN is shown being sent from the LAC to the LNS. What happened to
the ICRP? It is sent by the LNS and received by the LAC, but it is not shown in this debug output.
For more information on the L2TP session, you can use the show vpdn session command, as
demonstrated in Example 4-69.
Highlighted line 1 shows the local and remote session IDs (18/18), the local tunnel ID (12471),
the username associated with the session (ltahoe@mjlnet.com), the session state
(ESTABLISHED), the length of time since the last session state change, and whether fast
switching is enabled for this session.
If L2TP session setup fails, the most common cause is the conguration of a session limit or
VPDN softshut. VPDN softshut is a mechanism that allows graceful shutdown of L2TP (or
other VPDN) tunnels and sessions. By using this command, the administrator can cause the
LNS or LAC to refuse any more L2TP sessions. Existing sessions, however, continue until
naturally disconnected. When congured, VPDN softshut can give the appearance of an error.
When troubleshooting this issue, the rst command to use is again debug vpdn l2x-events.
Examples 4-70 to 4-73 show the output of the debug vpdn l2x-events command when VPDN
softshut is congured on the LNS.
Example 4-69 Verifying L2TP Session Establishment
CalCity_LAC#show vpdn session
L2TP Session Information Total tunnels 1 sessions 1
LocID RemID TunID Intf Username State Last Chg Fastswitch
18 18 12471 As34 ltahoe@mjlnet.com est 00:01:17 enabled
%No active L2F tunnels
%No active PPTP tunnels
%No active PPPoE tunnels
CalCity_LAC#
Example 4-70 L2TP Session Setup Fails
CalCity_LAC#debug vpdn l2x-events
L2X protocol events debugging is on
CalCity_LAC#
Feb 11 21:55:04.106 UTC: %ISDN-6-CONNECT: Interface Serial0/0:1 is now connected
to 1111
CH01i.book Page 292 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 293
Highlighted line 1 shows interface serial 0/0:1 connected to 1111. Then in highlighted line 2,
interface async 35 changes state to up. The remote access client is connected to the internal
digital modem on line 35.
In Example 4-71, L2TP session setup begins.
In highlighted line 1 (Example 4-71), a new L2TP session is created for the remote access
client. An ICRQ is sent to the LNS to initiate session setup in highlighted line 2. The LNS now
sends a CDN, as shown in Example 4-72.
In Example 4-72, highlighted line 1 shows the CDN from the LNS. The CDN is used by the
LNS to request that the LAC disconnect the call session from the remote access client. The
session is then shut down by the LAC in highlighted line 2. Finally, in Example 4-73, the remote
access client is disconnected.
Feb 11 21:55:25.666 UTC: %LINK-3-UPDOWN: Interface Async35, changed state to up
Feb 11 21:55:28.918 UTC: Tnl/Sn16357/28 L2TP: Session FS enabled
Feb 11 21:55:28.918 UTC: Tnl/Sn16357/28 L2TP: Session state change from idle to
wait-for-tunnel
Example 4-71 L2TP Session Setup Begins
Feb 11 21:55:28.922 UTC: As35 Tnl/Sn16357/28 L2TP: Create session
Feb 11 21:55:28.922 UTC: Tnl16357 L2TP: SM State established
Feb 11 21:55:28.922 UTC: As35 Tnl/Sn16357/28 L2TP: O ICRQ to Skydance_LNS 7063/0
Feb 11 21:55:28.922 UTC: Tnl16357 L2TP: Control channel retransmit delay set to
1 seconds
Feb 11 21:55:28.922 UTC: As35 Tnl/Sn16357/28 L2TP: Session state change from
wait-for-tunnel to wait-reply
Example 4-72 LNS Sends a CDN
Feb 11 21:55:28.930 UTC: As35 Tnl/Sn16357/28 L2TP: I CDN from Skydance_LNS
tnl 7063, cl 0
Feb 11 21:55:28.930 UTC: As35 Tnl/Sn16357/28 L2TP: Destroying session
Feb 11 21:55:28.930 UTC: As35 Tnl/Sn16357/28 L2TP: Session state change from
wait-reply to idle
Feb 11 21:55:28.930 UTC: As35 Tnl/Sn16357/28 L2TP: Releasing idb for LAC/LNS
tunnel 16357/7063 session 28 state idle
Example 4-73 Remote Access Client Is Disconnected
Feb 11 21:55:29.026 UTC: %ISDN-6-DISCONNECT: Interface Serial0/0:1 disconnected
from 1111 , call lasted 30 seconds
Feb 11 21:55:30.938 UTC: %LINK-5-CHANGED: Interface Async35, changed state to reset
Feb 11 21:55:35.938 UTC: %LINK-3-UPDOWN: Interface Async35, changed state to down
CalCity_LAC#
Example 4-70 L2TP Session Setup Fails (Continued)
CH01i.book Page 293 Friday, April 30, 2004 8:58 AM
294 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
In highlighted line 1 (Example 4-73), interface serial 0/0:1 is disconnected, and interface async
35 changes state to DOWN (highlighted line 2). The remote access client has been
disconnected.
The reason that the LNS requested disconnection of the session from the remote access client
can be seen by examining the Result and Error codes contained within the CDN message sent
by the LNS to the LAC (Example 4-72, highlighted line 1).
To examine the Result and Error codes in the CDN, use the debug vpdn l2x-errors command
when the remote access client reconnects, as demonstrated in Example 4-74.
Interface serial 0/0:1 is connected to 1111 in highlighted line 1. Interface async 36 then changes
state to up (highlighted line 2). The remote access client is now connected to the internal digital
modem on line 36.
In highlighted line 3, the Result Code contained within the CDN message sent by the LNS to
the LAC is displayed. The Result Code is 2, indicating that the reason for the disconnect is
shown by the Error Code.
The Error Code 6 in highlighted line 4 indicates that this is a vendor-specic error. That does
not tell you very much, but the Error Message Field included in the CDN indicates that call
disconnection was requested because of a session-limit congured on the LNS (highlighted
line 5).
More information regarding Result and Error Codes carried in CDN messages can be found in
Tables 4-5 and 4-6 at the beginning of this chapter.
Highlighted line 6 then shows interface serial 0/0:1 disconnecting from the remote access
client, and in highlighted line 7 interface async 36 changes state to down.
The error message shown means one of two things: either a session limit or VPDN softshut is
congured on the LNS.
Example 4-74 Verifying the Result and Error Codes in the CDN
CalCity_LAC#debug vpdn l2x-errors
L2X protocol errors debugging is on
CalCity_LAC#
Feb 11 21:56:16.330 UTC: %ISDN-6-CONNECT: Interface Serial0/0:1 is now connected
to 1111
Feb 11 21:56:39.874 UTC: %LINK-3-UPDOWN: Interface Async36, changed state to up
Feb 11 21:56:45.130 UTC: As36 Tnl/Sn16357/29 L2TP: Result code(2): 2: Call
disconnected, refer to error msg
Feb 11 21:56:45.130 UTC: Error code(6): Vendor specific
Feb 11 21:56:45.130 UTC: Optional msg: Session limit
Feb 11 21:56:45.226 UTC: %ISDN-6-DISCONNECT: Interface Serial0/0:1 disconnected
from 1111 , call lasted 34 seconds
Feb 11 21:56:47.138 UTC: %LINK-5-CHANGED: Interface Async36, changed state to reset
Feb 11 21:56:52.138 UTC: %LINK-3-UPDOWN: Interface Async36, changed state to down
CalCity_LAC#
CH01i.book Page 294 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 295
Using the show vpdn tunnel all command, you can see the current number of sessions
established within the tunnel to the LNS, as demonstrated in Example 4-75.
Highlighted line 1 shows that one tunnel and one session are established.
The conguration of the LNS is then examined using the show running-cong command.
Example 4-76 shows the output of the show running-cong command on the LNS. Note that
only the relevant portion of the output is shown.
Example 4-75 Verifying the L2TP Tunnel and Associated Sessions
CalCity_LAC#show vpdn tunnel all
L2TP Tunnel Information Total tunnels 1 sessions 1
Tunnel id 46935 is up, remote id is 61101, 1 active sessions
Tunnel state is established, time since change 00:01:01
Remote tunnel name is Skydance_LNS
Internet Address 172.16.5.5, port 1701
Local tunnel name is CalCity_LAC
Internet Address 172.16.1.1, port 1701
VPDN group for tunnel is 1
43 packets sent, 33 received
5796 bytes sent, 1880 received
Control Ns 4, Nr 3
Local RWS 800 (default), Remote RWS 800 (max)
Tunnel PMTU checking disabled
Retransmission time 1, max 1 seconds
Unsent queuesize 0, max 0
Resend queuesize 0, max 2
Total resends 0, ZLB ACKs sent 1
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
%No active L2F tunnels
%No active PPTP tunnels
%No active PPPoE tunnels
CalCity_LAC#
Example 4-76 VPDN Group Configuration
Skydance_LNS#show running-config
Building configuration...
vpdn enable
vpdn softshut
!
vpdn-group 1
accept-dialin
protocol l2tp
virtual-template 1
terminate-from hostname CalCity_LAC
l2tp tunnel password 7 01100F175804
!
CH01i.book Page 295 Friday, April 30, 2004 8:58 AM
296 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
In highlighted line 1, you can see that VPDN softshut is indeed congured on the LNS. This
will prevent any new sessions been established within the L2TP tunnel from the LAC.
To allow new sessions to be established within the L2TP tunnel, VPDN softshut must be
disabled. The VPDN softshut is disabled using the no vpdn softshut command on the LNS.
Example 4-77 shows vpdn softshut being disabled on the LNS.
Once VPDN softshut has been disabled on the LNS, the remote access client reconnects to the
LAC, and session setup succeeds. To verify this, the show vpdn tunnel all command is used.
Example 4-78 shows the output of the show vpdn tunnel all command.
Note that there are now two sessions within the tunnel to the LNS (highlighted line 1). The issue
has been resolved.
Example 4-77 VPDN Softshut Is Disabled on the LNS
Skydance_LNS#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Skydance_LNS(config)#no vpdn softshut
Skydance_LNS(config)#exit
Skydance_LNS#
Example 4-78 L2TP Session Setup Succeeds
CalCity_LAC#show vpdn tunnel all
L2TP Tunnel Information Total tunnels 1 sessions 2
Tunnel id 46935 is up, remote id is 61101, 2 active sessions
Tunnel state is established, time since change 00:03:27
Remote tunnel name is Skydance_LNS
Internet Address 172.16.5.5, port 1701
Local tunnel name is CalCity_LAC
Internet Address 172.16.1.1, port 1701
VPDN group for tunnel is 1
77 packets sent, 103 received
8603 bytes sent, 5976 received
Control Ns 6, Nr 4
Local RWS 800 (default), Remote RWS 800 (max)
Tunnel PMTU checking disabled
Retransmission time 1, max 1 seconds
Unsent queuesize 0, max 0
Resend queuesize 0, max 2
Total resends 0, ZLB ACKs sent 1
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
%No active L2F tunnels
%No active PPTP tunnels
%No active PPPoE tunnels
CalCity_LAC#
CH01i.book Page 296 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 297
As previously mentioned, this issue can also occur if a session limit is congured using the vpdn
session-limit sessions command. This command limits the number of sessions to the number
specied. If a new session causes this limit to be exceeded, session setup will fail. In this case,
either remove the session limit (no vpdn session-limit sessions) or revise the limit upward.
LNS/Remote Access Client PPP Negotiation Failure
After the L2TP tunnel and session have been established between the LAC and the LNS, the
next stage is for the LNS to complete PPP negotiation with the remote access client.
Specically, the LNS must complete LCP negotiation and PPP authentication and then
negotiate NCPs with the remote access client. Note that the LNS can be congured to
renegotiate LCP with the remote access client using the lcp renegotiation command under the
VPDN group.
Before the LNS can begin PPP negotiation with the remote access client, a virtual access
interface must be cloned from the virtual template interface.
Figure 4-27 shows cloning of the virtual access interface from the virtual template.
Figure 4-27 Virtual Access Interface Is Cloned
Remote Access
Client
LAC
(172.16.1.1)
PSTN/
ISDN
LNS
(172.16.5.5)
Service Provider
Backbone
1. Call
Reception
2. LCP
Negotiation
Authentication
3. Partial PPP
5. Control Connection 5.Confirm Valid
Source / Protocol /
Resources
7. Virtual Template
Configuration Cloned to
Virtual Access Interface
Establishment
6. Session
Establishment
4. Associate
Domain/DNIS/
Username with Tunnel
CH01i.book Page 297 Friday, April 30, 2004 8:58 AM
298 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
You can use the debug vtemplate command to verify cloning of virtual template conguration
to virtual access interfaces, as demonstrated in Example 4-79.
Highlighted line 1 indicates that conguration is about to be cloned to virtual access interface
1. In highlighted line 2, conguration is cloned from virtual template interface 1 to virtual
access interface 1.
From highlighted lines 3 to 7, the conguration from the virtual template interface is shown as
it is copied to the virtual access interface. If the virtual access interface is not successfully
cloned from the virtual template, check that the virtual template is correctly referenced under
the VPDN group.
Use the show running-cong command to verify that the virtual template is corrected
referenced, as shown in Example 4-80.
Example 4-79 Cloning the Virtual Access Interface from the Virtual Template
CalCity_LAC#debug vtemplate
Virtual Template debugging is on
Skydance_LNS#
Feb 6 01:22:30.925 UTC: Vt1 VTEMPLATE: Unable to create and clone vaccess
Feb 6 01:22:30.925 UTC: Vi1 VTEMPLATE: Reuse Vi1, recycle queue size 0
Feb 6 01:22:30.925 UTC: Vi1 VTEMPLATE: Hardware address 00d0.6354.7000
Feb 6 01:22:30.925 UTC: Vi1 VTEMPLATE: Has a new cloneblk vtemplate, now it has
vtemplate
Feb 6 01:22:30.925 UTC: Vi1 VTEMPLATE: ************* CLONE VACCESS1 *****************
Feb 6 01:22:30.925 UTC: Vi1 VTEMPLATE: Clone from Virtual-Template1interface
Virtual-Access1
default ip address
no ip address
encap ppp
ip unnumbered Ethernet1/0
peer default ip address pool PERRIS_POOL
ppp authentication chap
ppp multilink
end
Feb 6 01:22:30.985 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state
to up
Feb 6 01:22:31.985 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Virtual-Access1, changed state to up
Skydance_LNS#
Example 4-80 Verifying the Virtual Template Reference Under the VPDN Group
Skydance_LNS#show running-config
Building configuration...
!
vpdn-group 1
accept-dialin
protocol l2tp
virtual-template 1
terminate-from hostname CalCity_LAC
l2tp tunnel password 7 01100F175804
!
CH01i.book Page 298 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 299
In this example, the virtual template interface is correctly referenced under the VPDN group.
If user-specic conguration is stored on a AAA server, make sure that as you troubleshoot PPP
negotiation you verify this conguration, and ensure that it is being downloaded to the LNS.
LCP Negotiation or PPP Authentication Failure on the LNS
After the virtual access interface has been cloned from the virtual template interface, PPP
negotiation begins between the LNS and the remote access client. PPP negotiation involves
forced LCP, PPP authentication, and NCP setup. If LCP negotiation or PPP authentication fails
on the LNS, NCPs are not negotiated, and the remote access client is disconnected.
Figure 4-28 shows LCP Negotiation and PPP authentication on the LNS.
Figure 4-28 LCP Negotiation and PPP Authentication on the LNS
The LNS can complete LCP negotiation and PPP authentication using information sent to it by
the LAC during L2TP session setup, or it can choose to renegotiate LCP or reauthenticate the
remote access client.
Remote Access
Client
LAC
(172.16.1.1)
PSTN/
ISDN
LNS
(172.16.5.5)
Service Provider
Backbone
1. Call
Reception
2. LCP
Negotiation
Authentication
3. Partial PPP
8. LCP Negotiation / PPP
Authentication Completed
5. Control Connection 5. Confirm Valid
Source / Protocol /
Resources
7. Virtual Template
Configuration Cloned to
Virtual Access Interface
Establishment
6. Session
Establishment
4. Associate
Domain/DNIS/
Username with Tunnel
CH01i.book Page 299 Friday, April 30, 2004 8:58 AM
300 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
Before examining LCP negotiation or PPP authentication failure on the LNS, it is useful to
examine what happens when LCP negotiation and PPP authentication is successful.
Use the debug ppp negotiation command to examine the LCP negotiation and PPP
authentication sequence. Note that the debug ppp authentication command can also be used
to examine the PPP authentication sequence.
Examples 4-81 to 4-84 show the output of the debug ppp negotiation command when LCP
negotiation and PPP authentication is successful. Only the relevant portion of the output is shown.
In highlighted line 1, virtual-access interface 1 changes state to up. Then in highlighted line 2,
the PPP phase changes to ESTABLISHING. This indicates that LCP negotiation is about to
begin. LCP negotiation begins in Example 4-82.
Highlighted line 1 (Example 4-82) shows an inbound (I) FORCED CONFREQ. This
CONFREQ has special signicance. If you have already read the technical overview at the
beginning of this chapter, this may seem familiar. It is in fact the last CONFREQ sent by the
LAC to the remote access client during initial PPP negotiation and passed to the LNS by the
LAC (in the ICCN message) during session setup.
LCP negotiation continues in Example 4-83.
Example 4-81 Successful PPP Authentication on the LNS
Skydance_LNS#debug ppp negotiation
PPP protocol negotiation debugging is on
Skydance_LNS#
Feb 6 01:29:07.677 UTC: Vi1 PPP: Phase is DOWN, Setup
Feb 6 01:29:07.749 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state
to up
Feb 6 01:29:07.749 UTC: Vi1 PPP: Using set call direction
Feb 6 01:29:07.749 UTC: Vi1 PPP: Treating connection as a callin
Feb 6 01:29:07.749 UTC: Vi1 PPP: Phase is ESTABLISHING, Passive Open
Feb 6 01:29:07.749 UTC: Vi1 LCP: State is Listen
Example 4-82 Incoming FORCED CONFREQ
Feb 6 01:29:07.749 UTC: Vi1 LCP: I FORCED CONFREQ len 21
Feb 6 01:29:07.749 UTC: Vi1 LCP: ACCM 0x000A0000 (0x0206000A0000)
Feb 6 01:29:07.749 UTC: Vi1 LCP: AuthProto CHAP (0x0305C22305)
Feb 6 01:29:07.749 UTC: Vi1 LCP: MagicNumber 0x130FE417 (0x0506130FE417)
Feb 6 01:29:07.749 UTC: Vi1 LCP: PFC (0x0702)
Feb 6 01:29:07.749 UTC: Vi1 LCP: ACFC (0x0802)
Example 4-83 Incoming FORCED CONFACK
Feb 6 01:29:07.749 UTC: Vi1 LCP: I FORCED CONFACK len 39
Feb 6 01:29:07.749 UTC: Vi1 LCP: ACCM 0x00000000 (0x020600000000)
Feb 6 01:29:07.749 UTC: Vi1 LCP: MagicNumber 0x1D9A61B9 (0x05061D9A61B9)
Feb 6 01:29:07.749 UTC: Vi1 LCP: PFC (0x0702)
Feb 6 01:29:07.749 UTC: Vi1 LCP: ACFC (0x0802)
Feb 6 01:29:07.749 UTC: Vi1 LCP: EndpointDisc 1 Local
Feb 6 01:29:07.749 UTC: Vi1 LCP: (0x13170190699D7655924F3481F6E9E6D7)
Feb 6 01:29:07.749 UTC: Vi1 LCP: (0x6EFD0A00000000)
CH01i.book Page 300 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 301
The LNS now begins processing an inbound FORCED CONFACK (Example 4-83). This
CONFACK is in fact the CONFREQ received by the LAC from the remote access client
during initial PPP negotiation. Again, this is forwarded to the LNS in the ICCN message.
The purpose of the FORCED CONFREQ and CONFACK (CONFREQ) is to allow the LNS not
to have to renegotiate LCP with the remote access client. These two CONFREQs tell the LNS
what LCP options were negotiated between the LAC and the remote access client.
See Table 4-9 at the beginning of the chapter for more details on LCP and PPP authentication
information passed to the LNS by the LAC during session setup.
The LNS now has a choice. It can either accept the LCP options negotiated between the remote
access client and the LAC, or it can renegotiate LCP. This can be useful when, for example, the
LAC rejects conguration of certain LCP options that the LNS is able to support. If you want
the LNS to renegotiate LCP with the remote access client, you can congure the lcp
renegotiation {always | on-mismatch} command under the VPDN group on the LNS.
The lcp renegotiation {always | on-mismatch} command can also be very useful if the LNS
rejects LCP options negotiated between the remote access client and the LAC and passed to the
LNS by the LAC during L2TP session setup. In this case, you will see a message such as PPP
LCP not accepting sent CONFACK when using the debug ppp negotiation command on
the LNS.
In Example 4-84, PPP authentication begins.
Highlighted line 1 (Example 4-84) shows the PPP phase change to AUTHENTICATING.
Authentication is about to begin.
In highlighted line 2, the LNS sends a CHAP challenge to the remote access client, and in
highlighted line 3, the remote access client sends its response.
Finally, a CHAP success message is sent by the LNS to the remote access client in highlighted
line 4, indicating authentication has been successful.
That is successful PPP authentication, but what happens when authentication is unsuccessful?
In Examples 4-85 to 4-86, PPP authentication is not successful, as shown in output from the
debug ppp negotiation command. Note that only the relevant portion of the output is shown.
Example 4-84 PPP Authentication Begins
Feb 6 01:29:07.749 UTC: Vi1 PPP: Phase is AUTHENTICATING, by this end
Feb 6 01:29:07.753 UTC: Vi1 CHAP: O CHALLENGE id 12 len 33 from "Skydance_LNS"
Feb 6 01:29:07.753 UTC: Vi1 CHAP: I RESPONSE id 11 len 37 from
"ltahoe@mjlnet.com"
Feb 6 01:29:07.753 UTC: Vi1 CHAP: O SUCCESS id 11 len 4
Feb 6 01:29:07.753 UTC: Vi1 PPP: Phase is UP
CH01i.book Page 301 Friday, April 30, 2004 8:58 AM
302 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
PPP authentication begins in highlighted line 1, with the PPP phase changing to
AUTHENTICATING. In highlighted line 2, the LNS sends a CHAP challenge to the remote
access client, and the remote access client replies with a CHAP response message shown in
highlighted line 3. Note the name of the remote access client (ltahoe@mjlnet.com).
Everything looks good until highlighted line 3, when the LNS sends a CHAP failure message
to the remote access client. Authentication of the remote access client by the LNS has failed.
PPP negotiation now terminates, as shown in Example 4-86.
The PPP phase then changes to TERMINATING (highlighted line 1), and in highlighted line
2, the LNS sends a termination request (TERMREQ) to the remote access client. In highlighted
line 3, the virtual-access interface changes state to down. Finally, in highlighted line 4, the PPP
phase changes to DOWN. Authentication has failed, and PPP negotiation has been terminated.
Authentication failure can be due to an incorrect username or password congured on either the
remote access client or the LNS. In this case, the remote user conrms that the username and
password are correct. This means that either the username or password for the remote access
client is incorrectly congured on the LNS. The username and password are then recongured
on the LNS.
Example 4-85 PPP Authentication Is Unsuccessful
Skydance_LNS#debug ppp negotiation
PPP protocol negotiation debugging is on
Feb 6 01:31:16.993 UTC: Vi1 PPP: Phase is AUTHENTICATING, by this end
Feb 6 01:31:16.997 UTC: Vi1 CHAP: O CHALLENGE id 12 len 33 from "Skydance_LNS"
Feb 6 01:31:16.997 UTC: Vi1 CHAP: I RESPONSE id 11 len 37 from
"ltahoe@mjlnet.com"
Feb 6 01:31:16.997 UTC: Vi1 CHAP: O FAILURE id 11 len 25 msg is
"MD/DES compare failed"
Example 4-86 PPP Negotiation Terminates
Feb 6 01:31:16.997 UTC: Vi1 PPP: Phase is TERMINATING
Feb 6 01:31:16.997 UTC: Vi1 LCP: O TERMREQ [Open] id 1 len 4
Feb 6 01:31:18.997 UTC: Vi1 LCP: TIMEout: State TERMsent
Feb 6 01:31:18.997 UTC: Vi1 LCP: O TERMREQ [TERMsent] id 2 len 4
Feb 6 01:31:20.641 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state
to down
Feb 6 01:31:20.641 UTC: Vi1 LCP: State is Closed
Feb 6 01:31:20.641 UTC: Vi1 PPP: Phase is DOWN
Skydance_LNS#
CH01i.book Page 302 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 303
Example 4-87 shows the reconguration of the remote access clients username and password
on the LNS.
Once the remote access clients username and password are recongured, the remote access
client reconnects. PPP negotiation is now successful.
Successful PPP negotiation, including authentication, is veried using the show caller user
command, as demonstrated in Example 4-88.
Highlighted line 1 shows the username (ltahoe@mjlnet.com), the line (virtual-access interface
1), and the service (PPP over L2TP) associated with the user.
Highlighted line 2 shows the negotiated PPP options. As you can see, LCP is in an open state,
PPP multilink has not been negotiated, the local host is authenticating the remote access client,
and IPCP has been negotiated.
Highlighted line 3 shows the local and remote access clients IP addresses (172.16.5.5 and
10.1.1.1, respectively). Finally, in highlighted line 4, the name of the LAC (CalCity_LAC) is
shown. Successful PPP negotiation has been conrmed, and the issue has been resolved.
If you are using a AAA server to authenticate and authorize remote access clients, also see
Case Study 2: Remote AAA (RADIUS) Authentication Failure on the LNS, Case Study 3:
Remote AAA (RADIUS) Authorization Failure on the LNS, and Case Study 4: AAA
(RADIUS) Server Unreachable from the LNS.
Example 4-87 Remote Access Clients Username and Password Are Reconfigured
Skydance_LNS#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Skydance_LNS(config)#username ltahoe@mjlnet.com password cisco
Skydance_LNS(config)#exit
Skydance_LNS#
Example 4-88 Verifying Successful PPP Negotiation
Skydance_LNS#show caller user ltahoe@mjlnet.com
User: ltahoe@mjlnet.com, line Vi1, service PPP L2TP
Active time 00:00:33, Idle time 00:00:00
Timeouts: Absolute Idle
Limits: - -
Disconnect in: - -
PPP: LCP Open, multilink Closed, CHAP (<- local), IPCP
IP: Local 172.16.5.5, remote 10.1.1.1
VPDN: NAS CalCity_LAC, MID 34, MID Unknown
HGW , NAS CLID 0, HGW CLID 0, tunnel open
Counts: 41 packets input, 3990 bytes, 0 no buffer
0 input errors, 0 CRC, 0 frame, 0 overrun
28 packets output, 1200 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
Skydance_LNS#
CH01i.book Page 303 Friday, April 30, 2004 8:58 AM
304 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
NCP Negotiation Failure on the LNS
Once PPP authentication has succeeded for the remote access client on the LNS, the next stage
in the PPP negotiation sequence is negotiation of NCPs. NCPs include the IPCP and the IPXCP.
A common cause of NCP negotiation failure is misconguration of network layer protocols (for
example, IP or IPX) on the virtual template interface. NCP negotiation between the remote
access client and the LNS is shown in Figure 4-29.
Figure 4-29 NCP Negotiation Between the Remote Access Client and the LNS
Before examining what happens when NCP negotiation fails, it is worth taking a look at what
happens when NCP negotiation succeeds. Use the debug ppp negotiation command to
examine NCP negotiation between the remote access client and the LNS.
Remote Access
Client
LAC
(172.16.1.1)
PSTN/
ISDN
LNS
(172.16.5.5)
Service Provider
Backbone
1. Call
Reception
2. LCP
Negotiation
Authentication
3. Partial PPP
8. LCP Negotiation / PPP
Authentication Completed
9. NCP
Negotiation
5. Control Connection 5. Confirm Valid
Source / Protocol /
Resources
7. Virtual Template
Configuration Cloned to
Virtual Access Interface
Establishment
6. Session
Establishment
4. Associate
Domain/DNIS/
Username with Tunnel
CH01i.book Page 304 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 305
Examples 4-89 to 4-101 show the output of the debug ppp negotiation command when NCP
negotiation is successful. Note that only the relevant portion of the output is shown.
In Example 4-89, the PPP phase changes to UP, and NCP negotiation begins.
In Example 4-90, the LNS sends an outgoing (O) IPCP CONFREQ to the remote access client.
Contained within this CONFREQ is the IPCP address option (0x03, IP Address). This IPCP
option is used to communicate the IP address of the local system, which in this case is the IP
address applied to virtual-access interface 1 (172.16.5.5).
In Example 4-91, the remote access client then sends a Compression Control Protocol (CCP)
CONFREQ to the LNS. This CONFREQ contains one CCP option, which is Microsoft Point-
to-Point Compression (MS-PPC) (0x12).
Notice the supported bits contained within the MS-PPC option in Example 4-91 (0x00000001).
These supported bits indicate that the remote access client would like to use MS-PPC alone (in
other words, without Microsoft Point-to-Point Encryption (MPPE), which can be congured in
conjunction with MS-PPC).
As shown in Example 4-92, the LNS sends a Protocol-Reject (PROTREJ) to the remote access
client to reject conguration of the CCP, including MS-PPC.
The remote access client then sends an IPCP CONFREQ to the LNS, as demonstrated in
Example 4-92. This CONFREQ contains a number of options. These options are
CompressTypeVJ (0x02, IP Compression Protocol), address (0x03, IP Address), Primary DNS
(0x81, Primary DNS Address), Primary WINS (0x82, Primary NBNS Address), Secondary
Example 4-89 Successful NCP Negotiation
Skydance_LNS#debug ppp negotiation
PPP protocol negotiation debugging is on
Skydance_LNS#
Feb 6 01:36:10.445 UTC: Vi1 PPP: Phase is UP
Example 4-90 LNS Sends a CONFREQ
Feb 6 01:36:10.445 UTC: Vi1 IPCP: O CONFREQ [Closed] id 1 len 10
Feb 6 01:36:10.445 UTC: Vi1 IPCP: Address 172.16.5.5 (0x0306AC100505)
Example 4-91 Remote Access Client Sends a CONFREQ
Feb 6 01:36:10.565 UTC: Vi1 CCP: I CONFREQ [Not negotiated] id 7 len 10
Feb 6 01:36:10.565 UTC: Vi1 CCP: MS-PPC supported bits 0x00000001 (0x120600000001)
Example 4-92 LNS Responds with a PROTREJ
Feb 6 01:36:10.565 UTC: Vi1 LCP: O PROTREJ [Open] id 1 len 16 protocol
CCP (0x80FD0107000A120600000001)
CH01i.book Page 305 Friday, April 30, 2004 8:58 AM
306 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
DNS (0x83, Secondary DNS Address), and nally Secondary WINS (0x84, Secondary NBNS
Address).
The CompressTypeVJ option in Example 4-93 indicates that the remote access client would like
to use Van Jacobson (VJ) Compression on the PPP connection.
Note, however, that all of the options contained within the CONFREQ, with the exception of
IP Compression Protocol, are specied as 0.0.0.0. Here, the remote access client is indicating
to the LNS that it would like all of these addresses to be supplied.
As Example 4-94 shows, because the remote access client has requested an IP address, the LNS
obtains one from an IP address pool. The address obtained from the pool is 10.1.1.1.
As shown in Example 4-95, The LNS then sends a CONFREJ to the remote access client. This
CONFREJ is used to reject the CompressTypeVJ, Secondary DNS, and Secondary WINS
options. This means that the LNS will not support Van Jacobson Compression on the PPP
connection and will not supply secondary DNS and WINS server addresses to the remote access
client.
It is worth noting that if you congure the ip tcp header-compression command on the virtual
template interface (it is not congured in this example), and TCP header compression is
negotiated with a large number of remote access clients, this may cause high CPU overhead on
the LNS.
In Example 4-96, the remote access client acknowledges the LNSs IP address (172.16.5.5)
using a CONFACK message. This CONFACK is an acknowledgment of the LNSs rst
Example 4-93 Remote Access Client Sends a CONFREQ
Feb 6 01:36:10.581 UTC: Vi1 IPCP: I CONFREQ [REQsent] id 8 len 40
Feb 6 01:36:10.581 UTC: Vi1 IPCP: CompressType VJ 15 slots CompressSlot
ID (0x0206002D0F01)
Feb 6 01:36:10.581 UTC: Vi1 IPCP: Address 0.0.0.0 (0x030600000000)
Feb 6 01:36:10.581 UTC: Vi1 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000)
Feb 6 01:36:10.581 UTC: Vi1 IPCP: PrimaryWINS 0.0.0.0 (0x820600000000)
Feb 6 01:36:10.581 UTC: Vi1 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000)
Feb 6 01:36:10.581 UTC: Vi1 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000)
Example 4-94 LNS Obtains an IP Address from the IP Address Pool
Feb 6 01:36:10.581 UTC: Vi1 IPCP: Pool returned 10.1.1.1
Example 4-95 LNS Sends a CONFREJ to the Remote Access Client
Feb 6 01:36:10.581 UTC: Vi1 IPCP: O CONFREJ [REQsent] id 8 len 22
Feb 6 01:36:10.581 UTC: Vi1 IPCP: CompressType VJ 15 slots CompressSlot
ID (0x0206002D0F01)
Feb 6 01:36:10.581 UTC: Vi1 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000)
Feb 6 01:36:10.581 UTC: Vi1 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000)
CH01i.book Page 306 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 307
CONFREQ message sent to the remote access client in Example 4-90. Notice that the ID of
CONFACK is the same as that for the original CONFREQ (1).
As demonstrated in Example 4-97, the remote access client now sends a second IPCP
CONFREQ message to the LNS. This CONFREQ message is similar to the rst one that it sent
in Example 4-93. However, this one contains only three IPCP options: address, Primary DNS,
and Primary WINS. The other options were previously rejected by the LNS in Example 4-95.
The LNS now sends a Congure-Nak (CONFNAK) message to the remote access client, as
shown in Example 4-98. This CONFNACK message is used to supply the addresses requested
by the remote access client (using the CONFREQ message in Example 4-97).
In Example 4-98, the LNS supplies the address 10.1.1.1 to the remote access client, together
with the addresses of the primary DNS and WINS servers (10.2.2.99 and 10.2.2.100).
As Example 4-99 shows, the remote access client then sends another CONFREQ message to
the LNS. This CONFREQ message is used to conrm the addresses sent by the LNS in the
CONFNAK message in Example 4-98.
Example 4-96 Remote Access Client Sends a CONFACK to the LNS
Feb 6 01:36:10.589 UTC: Vi1 IPCP: I CONFACK [REQsent] id 1 len 10
Feb 6 01:36:10.589 UTC: Vi1 IPCP: Address 172.16.5.5 (0x0306AC100505)
Example 4-97 Remote Access Client Sends a CONFREQ
Feb 6 01:36:10.697 UTC: Vi1 IPCP: I CONFREQ [ACKrcvd] id 9 len 22
Feb 6 01:36:10.697 UTC: Vi1 IPCP: Address 0.0.0.0 (0x030600000000)
Feb 6 01:36:10.697 UTC: Vi1 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000)
Feb 6 01:36:10.697 UTC: Vi1 IPCP: PrimaryWINS 0.0.0.0 (0x820600000000)
Example 4-98 LNS Sends a CONFNACK
Feb 6 01:36:10.697 UTC: Vi1 IPCP: O CONFNAK [ACKrcvd] id 9 len 22
Feb 6 01:36:10.697 UTC: Vi1 IPCP: Address 10.1.1.1 (0x03060A010101)
Feb 6 01:36:10.697 UTC: Vi1 IPCP: PrimaryDNS 10.2.2.99 (0x81060A010163)
Feb 6 01:36:10.697 UTC: Vi1 IPCP: PrimaryWINS 10.2.2.100 (0x82060A010164)
Example 4-99 Remote Access Client Sends a CONFREQ
Feb 6 01:36:10.813 UTC: Vi1 IPCP: I CONFREQ [ACKrcvd] id 10 len 22
Feb 6 01:36:10.813 UTC: Vi1 IPCP: Address 10.1.1.1 (0x03060A010101)
Feb 6 01:36:10.813 UTC: Vi1 IPCP: PrimaryDNS 10.2.2.99 (0x81060A010163)
Feb 6 01:36:10.813 UTC: Vi1 IPCP: PrimaryWINS 10.2.2.100 (0x82060A010164)
CH01i.book Page 307 Friday, April 30, 2004 8:58 AM
308 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
Finally, in Example 4-100, the LNS acknowledges the CONFREQ (in Example 4-99) using a
CONFACK.
Example 4-101 shows that the LNS and the remote access client have successfully negotiated
IPCP.
The IPCP state is now Open (highlighted line 1, Example 4-101), and the LNS installs a route
to the remote access client (highlighted line 2). The line protocol on interface virtual-access 1
now changes state to up (highlighted line 3). NCP (IPCP portion) negotiation has completed
successfully.
Now that you have seen successful NCP negotiation, it is time to take a look at an example of
unsuccessful NCP negotiation. Examples 4-102 to 4-107 show the output of the debug ppp
negotiation command when NCP negotiation is not successful. Note that only the relevant
portion of the output is shown.
The PPP phase changes to UP, and NCP negotiation begins.
As Example 4-103 shows, the remote access client then sends a CCP CONFREQ to the LNS
specifying MS-PPC.
Example 4-100 LNS Sends a CONFACK
Feb 6 01:36:10.813 UTC: Vi1 IPCP: O CONFACK [ACKrcvd] id 10 len 22
Feb 6 01:36:10.813 UTC: Vi1 IPCP: Address 10.1.1.1 (0x03060A010101)
Feb 6 01:36:10.813 UTC: Vi1 IPCP: PrimaryDNS 10.2.2.99 (0x81060A010163)
Feb 6 01:36:10.813 UTC: Vi1 IPCP: PrimaryWINS 10.2.2.100 (0x82060A010164)
Example 4-101 IPCP Is Successfully Negotiated
Feb 6 01:36:10.813 UTC: Vi1 IPCP: State is Open
Feb 6 01:36:10.813 UTC: Vi1 IPCP: Install route to 10.1.1.1
Feb 6 01:36:11.445 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Virtual-Access1, changed state to up
Feb 6 01:36:12.441 UTC: Vi1 LCP: TIMEout: State Open
Skydance_LNS#
Example 4-102 NCP Negotiation Fails
Skydance_LNS#debug ppp negotiation
PPP protocol negotiation debugging is on
Skydance_LNS#
Feb 6 01:39:13.353 UTC: Vi1 PPP: Phase is UP
Example 4-103 Remote Access Client Sends a CONFREQ
Feb 6 01:39:13.465 UTC: Vi1 CCP: I CONFREQ [Not negotiated] id 6 len 10
Feb 6 01:39:13.465 UTC: Vi1 CCP: MS-PPC supported bits 0x00000001 (0x120600000001)
CH01i.book Page 308 Friday, April 30, 2004 8:58 AM
L2TPv2 Technical Overview 309
In Example 4-104, the LNS rejects conguration of the CCP by sending a Protocol-Reject
(PROTREJ) to the remote access client.
Now this is where things start to get interesting. Example 4-105 shows an incoming (I) IPCP
CONFREQ from the remote access client. This CONFREQ includes six IPCP options:
CompressTypeVJ, Address, Primary DNS, Primary WINS, Secondary DNS, and Secondary
WINS.
Then something strange happens, as Example 4-106 demonstrates. The LNS sends a PROTREJ
message to the remote access client rejecting conguration of IPCP.
PPP is nally terminated in Example 4-107.
Example 4-104 LNS Sends a PROTREJ
Feb 6 01:39:13.465 UTC: Vi1 LCP: O PROTREJ [Open] id 1 len 16 protocol
CCP (0x80FD0106000A120600000001)
Example 4-105 Remote Access Client Sends a CONFREQ
Feb 6 01:39:13.473 UTC: Vi1 IPCP: I CONFREQ [Not negotiated] id 7 len 40
Feb 6 01:39:13.473 UTC: Vi1 IPCP: CompressType VJ 15 slots CompressSlot
ID (0x0206002D0F01)
Feb 6 01:39:13.473 UTC: Vi1 IPCP: Address 0.0.0.0 (0x030600000000)
Feb 6 01:39:13.473 UTC: Vi1 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000)
Feb 6 01:39:13.473 UTC: Vi1 IPCP: PrimaryWINS 0.0.0.0 (0x820600000000)
Feb 6 01:39:13.473 UTC: Vi1 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000)
Feb 6 01:39:13.473 UTC: Vi1 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000)
Example 4-106 LNS Rejects Configuration of IPCP
Feb 6 01:39:13.473 UTC: Vi1 LCP: O PROTREJ [Open] id 2 len 46 protocol IPCP
Feb 6 01:39:13.473 UTC: Vi1 LCP: (0x8021010700280206002D0F0103060000)
Feb 6 01:39:13.473 UTC: Vi1 LCP: (0x00008106000000008206000000008306)
Feb 6 01:39:13.473 UTC: Vi1 LCP: (0x00000000840600000000)
Example 4-107 PPP Negotiation Is Terminated
Feb 6 01:39:14.353 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Virtual-Access1, changed state to up
Feb 6 01:39:15.349 UTC: Vi1 LCP: TIMEout: State Open
Skydance_LNS#
Feb 6 01:39:16.897 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state
to down
Feb 6 01:39:16.897 UTC: Vi1 PPP: Phase is TERMINATING
Feb 6 01:39:16.897 UTC: Vi1 LCP: State is Closed
Feb 6 01:39:16.897 UTC: Vi1 PPP: Phase is DOWN
Feb 6 01:39:17.897 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface
Virtual-Access1, changed state to down
Skydance_LNS#
CH01i.book Page 309 Friday, April 30, 2004 8:58 AM
310 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
Following the rejection of IPCP by the LNS, virtual-access interface 1 changes state to down
(highlighted line 1, Example 4-107). In highlighted line 2, the PPP phase changes to
TERMINATING and then DOWN (highlighted line 3). Finally, in highlighted line 4, the line
protocol on virtual-access interface 1 changes state to down. NCP negotiation has failed.
So what went wrong? Why did the LNS reject conguration of IPCP on virtual-access interface
1? The LNS will reject conguration of IPCP on the virtual-access interface if the virtual-access
interface is not congured with an IP address. The virtual-access interface is dynamic in nature
and takes its conguration from virtual template interface.
The next step is to examine the conguration of the virtual template interface associated with
the VPDN group using the show running-cong command.
Example 4-108 shows the output of the show running-cong command. Only the relevant
parts of the conguration are shown.
As you can see, no IP address has been congured on virtual template interface 1 (highlighted
line 3). This is the conguration that is copied to the virtual-access interfaces as they are
dynamically created when PPP connections from remote access clients are terminated on the
LNS. To resolve this issue, an IP address is congured on the virtual template interface.
Example 4-109 shows the conguration of an IP address on the virtual template interface.
Example 4-108 Verifying Virtual Template Interface Configuration
Skydance_LNS#show running-config
Building configuration...
!
vpdn-group 1
accept-dialin
protocol l2tp
virtual-template 1
terminate-from hostname CalCity_LAC
l2tp tunnel password 7 060506324F41
!
!
interface Virtual-Template1
no ip address
peer default ip address pool SKYDANCE_POOL
ppp authentication chap
ppp multilink
!
Example 4-109 Configuration of ip unnumbered on the Virtual Template Interface
Skydance_LNS#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Skydance_LNS(config)#interface virtual-template 1
Skydance_LNS(config-if)#ip unnumbered ethernet 1/0
Skydance_LNS(config-if)#exit
Skydance_LNS#
CH01i.book Page 310 Friday, April 30, 2004 8:58 AM
Case Studies 311
Once an IP address (ip unnumbered ethernet 1/0) is congured on the virtual template
interface, the remote access client reconnects and NCP (IPCP portion) negotiation is successful.
Use the show caller user command to verify successful IPCP negotiation with the remote
access client.
Example 4-110 shows the output of the show caller user command.
Highlighted line 1 shows that user ltahoe@mjlnet.com is connected to interface virtual-access
1 (vi1). In highlighted line 2, you can see that LCP is in an open state, PPP multilink was not
negotiated and is in a closed state, the authentication protocol used is CHAP, and IPCP was
negotiated. Highlighted line 3 shows the IP address congured on virtual-access interface 1
(172.16.5.5), together with the IP address congured on the remote access client (10.1.1.1).
Finally, in highlighted line 4, the hostname of the LAC (CalCity_LAC) is shown. IPCP
negotiation has been successful, and the issue is resolved.
Case Studies
This section contains solutions for issues not covered in the main troubleshooting section of this
chapter.
Figure 4-30 illustrates the topology used in Case Studies 1 through 4.
The RADIUS server used in Case Studies 1 through 4 is a CiscoSecure Access Control Server
(ACS) 3.0 running on a Windows 2000 server.
Example 4-110 Checking Successful IPCP Negotiation
Skydance_LNS#show caller user ltahoe@mjlnet.com
User: ltahoe@mjlnet.com, line Vi1, service PPP L2TP
Active time 00:00:25, Idle time 00:00:00
Timeouts: Absolute Idle
Limits: - -
Disconnect in: - -
PPP: LCP Open, multilink Closed, CHAP (<- local), IPCP
IP: Local 172.16.5.5, remote 10.1.1.1
VPDN: NAS CalCity_LAC, MID 37, MID Unknown
HGW , NAS CLID 0, HGW CLID 0, tunnel open
Counts: 47 packets input, 4448 bytes, 0 no buffer
0 input errors, 0 CRC, 0 frame, 0 overrun
26 packets output, 1119 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
Skydance_LNS#
CH01i.book Page 311 Friday, April 30, 2004 8:58 AM
312 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
Figure 4-30 Topology for Case Studies 1 Through 4
Case Study 1: Miscongured L2TP Tunnel Denition on an AAA
RADIUS Server
An alternative to storing tunnel conguration within VPDN groups on the LAC is to store it on
an AAA server as tunnel denitions. Storing tunnel denitions on an AAA server is a
convenient and easy way to administer tunnels, particularly if there are a large number of them.
Note that tunnel denitions can be specied using either Cisco AVPs or IETF standard VPDN
tunnel attributes as dened in RFC 2868.
NOTE More information on IETF tunnel attributes can be found at the following URL:
http://www.cisco.com/en/US/products/sw/iosswrel/ps1830/
products_feature_guide09186a00800879eb.html
In this case study, a RADIUS server is used to store Cisco AVP L2TP tunnel denitions.
However, misconguration of the L2TP tunnel denition prevents successful establishment of
the L2TP tunnel. Call reception on the LAC has been successful, but L2TP tunnel setup has
failed.
When troubleshooting tunnel denitions stored on a RADIUS server, one of the most useful
commands to use is the debug aaa authorization command. This command is used when the
remote access client (joebloggs@mjlnet.com) reconnects to the LAC. Examples 4-111 to
4-113 show the output of the debug aaa authorization command when the remote access
client connects to the LAC.
joebloggs@mjlnet.com
Calcity_LAC
(172.16.1.1)
PSTN/
ISDN
Skydance_LNS
(172.16.5.5)
Service Provider
Backbone
RADIUS Server
(Tunnel Definition
Stored Here)
RADIUS Server
(Remote Access Client
Username and Passwords
Stored Here)
CH01i.book Page 312 Friday, April 30, 2004 8:58 AM
Case Studies 313
In Example 4-111, you can see that user mjlnet.com has been created. This shows that the
domain name (mjlnet.com) has been correctly parsed from the PPP authentication response
sent by the remote access client to the LAC. Note that the tunnel denition on the RADIUS
server is associated with user mjlnet.com.
Authorization of user mjlnet.com now begins, as shown in Example 4-112.
In highlighted line 1 (Example 4-112), the LAC begins authorization for the network service
(NET) using the default method list. Highlighted line 2 shows that authorization is being sought
for user mjlnet.com. In highlighted lines 3 and 4, the LAC reports the service (PPP) and
protocol (VPDN) for which it will seek authorization. Highlighted line 5 indicates that the
default method list will be used. Then in highlighted line 6, the authorization method
(RADIUS) is selected from the method list. Authorization is then sought from the RADIUS
server, as demonstrated in Example 4-113.
Example 4-111 Misconfigured L2TP Tunnel Definition Is Sent from the RADIUS Server
CalCity_LAC#debug aaa authorization
AAA Authorization debugging is on
CalCity_LAC#
Feb 11 00:13:48.560 UTC: AAA/ACCT/DS0: channel=0, ds1=0, t3=0, slot=0, ds0=0
Feb 11 00:13:48.560 UTC: AAA/ACCT/DS0: channel=0, ds1=0, t3=0, slot=0, ds0=0
Feb 11 00:13:48.596 UTC: %LINK-3-UPDOWN: Interface Serial0/0:0, changed state to up
Feb 11 00:13:48.596 UTC: AAA/ACCT/DS0: channel=0, ds1=0, t3=0, slot=0, ds0=0
Feb 11 00:13:48.664 UTC: Se0/0:0 AAA/AUTHOR/FSM: (0): LCP succeeds trivially
Feb 11 00:13:48.676 UTC: AAA/ACCT/DS0: channel=0, ds1=0, t3=0, slot=0, ds0=0
Feb 11 00:13:48.696 UTC: AAA: parse name=Serial0/0:0 idb type=13 tty=-1
Feb 11 00:13:48.696 UTC: AAA: name=Serial0/0:0 flags=0x55 type=1 shelf=0 slot=0
adapter=0 port=0 channel=0
Feb 11 00:13:48.700 UTC: AAA: parse name=<no string> idb type=-1 tty=-1
Feb 11 00:13:48.700 UTC: AAA/ACCT/DS0: channel=0, ds1=0, t3=0, slot=0, ds0=0
Feb 11 00:13:48.700 UTC: AAA/MEMORY: create_user (0x6274E164)
user=mjlnet.com ruser=NULL ds0=0 port=Serial0/0:0 rem_addr=2222/7777
authen_type=NONE service=LOGIN priv=0 initial_task_id=0
Example 4-112 Authorization for User mjlnet.com Begins
Feb 11 00:13:48.700 UTC: Serial0/0:0 AAA/AUTHOR/VPDN (32057272): Port=Serial0/0:0
list=default service=NET
Feb 11 00:13:48.700 UTC: AAA/AUTHOR/VPDN: Serial0/0:0 (32057272)
user=mjlnet.com
Feb 11 00:13:48.700 UTC: Serial0/0:0 AAA/AUTHOR/VPDN (32057272): send AV service=ppp
Feb 11 00:13:48.700 UTC: Serial0/0:0 AAA/AUTHOR/VPDN (32057272): send AV protocol=vpdn
Feb 11 00:13:48.700 UTC: Serial0/0:0 AAA/AUTHOR/VPDN (32057272): found list "default"
Feb 11 00:13:48.700 UTC: Serial0/0:0 AAA/AUTHOR/VPDN (32057272): Method=radius
(radius)
CH01i.book Page 313 Friday, April 30, 2004 8:58 AM
314 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
Authorization for user mjlnet.com has succeeded in highlighted line 1 (Example 4-113), and a
number of attributes that make up the tunnel denition are sent from the RADIUS server
(highlighted lines 2 to 7). The attributes sent from the RADIUS server are tunnel ID, tunnel
type, IP addresses, and L2TP tunnel password.
Note, however, that in highlighted line 8, the LAC disconnects from the remote access client
(2222). Everything looked ne, and then it all went wrong. You can obtain more information
using the debug radius command, as demonstrated in Example 4-114.
Example 4-113 Authorization Is Successful for mjlnet.com
Feb 11 00:13:48.716 UTC: AAA/AUTHOR (32057272): Post authorization status = PASS_ADD
Feb 11 00:13:48.716 UTC: AAA/AUTHOR/VPDN: Processing AV service=ppp
Feb 11 00:13:48.716 UTC: AAA/AUTHOR/VPDN: Processing AV protocol=vpdn
Feb 11 00:13:48.716 UTC: AAA/AUTHOR/VPDN: Processing AV tunnel-id=12
Feb 11 00:13:48.720 UTC: AAA/AUTHOR/VPDN: Processing AV tunnel-type=l2tp
Feb 11 00:13:48.720 UTC: AAA/AUTHOR/VPDN: Processing AV ip-addresses=172.16.5.5
Feb 11 00:13:48.720 UTC: AAA/AUTHOR/VPDN: Processing AV l2tp-tunnel-password=cisco
Feb 11 00:13:48.720 UTC: AAA/MEMORY: free_user (0x6274E164) user=mjlnet.com
ruser=NULL port=Serial0/0:0 rem_addr=2222/7777 authen_type=NONE service=LOGIN
priv=0
Feb 11 00:13:54.596 UTC: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected
to 2222
CalCity_LAC#
Feb 11 00:14:16.840 UTC: %ISDN-6-DISCONNECT: Interface Serial0/0:0 disconnected
from 2222 , call lasted 28 seconds
Feb 11 00:14:16.888 UTC: %LINK-3-UPDOWN: Interface Serial0/0:0, changed state to down
CalCity_LAC#
Example 4-114 debug radius Command Output
CalCity_LAC#debug radius
Radius protocol debugging is on
CalCity_LAC#
Feb 11 00:14:44.304 UTC: %LINK-3-UPDOWN: Interface Serial0/0:0, changed state to up
Feb 11 00:14:44.408 UTC: RADIUS: authenticating to get author data
Feb 11 00:14:44.408 UTC: RADIUS: ustruct sharecount=2
Feb 11 00:14:44.408 UTC: Radius: radius_port_info() success=1 radius_nas_port=1
Feb 11 00:14:44.412 UTC: RADIUS: Initial Transmit Serial0/0:0 id 14 10.20.10.5:1645,
Access-Request, len 85
Feb 11 00:14:44.412 UTC: Attribute 4 6 0A140A01
Feb 11 00:14:44.412 UTC: Attribute 5 6 00004E20
Feb 11 00:14:44.412 UTC: Attribute 61 6 00000002
Feb 11 00:14:44.412 UTC: Attribute 1 11 63697363
Feb 11 00:14:44.412 UTC: Attribute 30 6 37373737
Feb 11 00:14:44.412 UTC: Attribute 31 6 32323232
Feb 11 00:14:44.412 UTC: Attribute 2 18 FB9F485B
Feb 11 00:14:44.412 UTC: Attribute 6 6 00000005
Feb 11 00:14:44.428 UTC: RADIUS: Received from id 14 10.20.10.5:1645, Access-Accept,
len 155
Feb 11 00:14:44.428 UTC: Attribute 26 25 0000000901137670
Feb 11 00:14:44.428 UTC: Attribute 26 29 0000000901177670
Feb 11 00:14:44.428 UTC: Attribute 26 36 00000009011E7670
CH01i.book Page 314 Friday, April 30, 2004 8:58 AM
Case Studies 315
Highlighted line 1 shows interface serial 0/0:0 changing state to up. The remote access client
has connected to the LAC.
In highlighted line 2, the LAC transmits an access-request message to the RADIUS server. The
access-request message contains a number of attributes, including the username (in this case
mjlnet.com), and password.
Then in highlighted line 3, the RADIUS server responds with an access-accept message. The
access-accept message (which also contains a number of attributes) indicates that
authentication and authorization have been successful.
The attributes contained within the access-accept message are listed directly below highlighted
line 3. This output will probably be indecipherable unless you are very familiar with RADIUS.
Thankfully, in highlighted lines 4, 5, 6, and 7, the attributes are listed in a much more readable
format. As you can see, the attributes include the VPDN tunnel ID, tunnel type, IP addresses,
and L2TP tunnel password. All seems wellthe RADIUS server has authenticated user
mjlnet.com, and the tunnel attributes have been sent.
Unfortunately, in highlighted line 8, interface serial one 0/0:0 disconnects from the remote
access client (2222). Clearly, something is wrong.
TIP You can use the Output Interpreter on the Cisco Web site (https://www.cisco.com/cgi-bin/
Support/OutputInterpreter/home.pl) to get an explanation of the output of the debug radius
command (simply paste the output of the command). A CCO account is required.
Also note that from Cisco IOS Software Release 12.2(4)T, attributes are decoded in the output
of the debug radius command.
Feb 11 00:14:44.428 UTC: Attribute 26 39 0000000901217670
Feb 11 00:14:44.428 UTC: Attribute 6 6 00000005
Feb 11 00:14:44.432 UTC: RADIUS: saved authorization data for user 6274E028 at 62750008
Feb 11 00:14:44.432 UTC: RADIUS: cisco AVPair "vpdn:tunnel-id=12"
Feb 11 00:14:44.432 UTC: RADIUS: cisco AVPair "vpdn:tunnel-type=l2tp"
Feb 11 00:14:44.432 UTC: RADIUS: cisco AVPair "vpdn:ip-addresses=172.16.5.5"
Feb 11 00:14:44.432 UTC: RADIUS: cisco AVPair "vpdn:l2tp-tunnel-password=cisco"
Feb 11 00:14:50.308 UTC: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected to
2222
CalCity_LAC#
Feb 11 00:15:31.848 UTC: %ISDN-6-DISCONNECT: Interface Serial0/0:0 disconnected
from 2222 , call lasted 47 seconds
Feb 11 00:15:31.900 UTC: %LINK-3-UPDOWN: Interface Serial0/0:0, changed state to down
CalCity_LAC#
Example 4-114 debug radius Command Output (Continued)
CH01i.book Page 315 Friday, April 30, 2004 8:58 AM
316 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
The tunnel denition is being downloaded successfully from the RADIUS server, but the LAC
is still disconnecting. Something must be going wrong with tunnel establishment to the LNS.
To get a clearer picture of what is going wrong, use the debug vpdn l2x-events command.
Example 4-115 shows the output of the debug vpdn l2x-events command on the LAC.
Highlighted line 1 shows interface serial 0/0:0 changing state to up. The remote access client
has connected to the LAC. In highlighted line 2, the LAC sends a SCCRQ to the LNS. So far,
so good.
But in highlighted lines 3 to 8, the SCCRQ is retransmitted. The LAC is receiving no response
from the LNS. Finally, in highlighted line 9, interface serial 0/0:0 is disconnected from the
remote access client (2222).
Example 4-115 Verifying L2TP Tunnel Establishment on the LAC
CalCity_LAC#debug vpdn l2x-events
L2X protocol events debugging is on
CalCity_LAC#
Feb 11 00:16:06.616 UTC: %LINK-3-UPDOWN: Interface Serial0/0:0, changed state to up
Feb 11 00:16:06.740 UTC: Tnl 3260 L2TP: SM State idle
Feb 11 00:16:06.744 UTC: Tnl 3260 L2TP: O SCCRQ
Feb 11 00:16:06.744 UTC: Tnl 3260 L2TP: Tunnel state change from idle to
wait-ctl-reply
Feb 11 00:16:06.744 UTC: Tnl 3260 L2TP: SM State wait-ctl-reply
Feb 11 00:16:07.744 UTC: Tnl 3260 L2TP: O Resend SCCRQ, flg TLS, ver 2, len 127,
tnl 0, cl 0, ns 0, nr 0
Feb 11 00:16:07.744 UTC: Tnl 3260 L2TP: Control channel retransmit delay set to
1 seconds
Feb 11 00:16:08.744 UTC: Tnl 3260 L2TP: O Resend SCCRQ, flg TLS, ver 2, len 127,
tnl 0, cl 0, ns 0, nr 0
Feb 11 00:16:08.744 UTC: Tnl 3260 L2TP: Control channel retransmit delay set to
2 seconds
Feb 11 00:16:10.744 UTC: Tnl 3260 L2TP: O Resend SCCRQ, flg TLS, ver 2, len 127,
tnl 0, cl 0, ns 0, nr 0
Feb 11 00:16:10.744 UTC: Tnl 3260 L2TP: Control channel retransmit delay set to
4 seconds
Feb 11 00:16:12.620 UTC: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected
to 2222
Feb 11 00:16:14.744 UTC: Tnl 3260 L2TP: O Resend SCCRQ, flg TLS, ver 2, len 127,
tnl 0, cl 0, ns 0, nr 0
Feb 11 00:16:14.744 UTC: Tnl 3260 L2TP: Control channel retransmit delay set to
8 seconds
Feb 11 00:16:22.744 UTC: Tnl 3260 L2TP: O Resend SCCRQ, flg TLS, ver 2, len 127,
tnl 0, cl 0, ns 0, nr 0
Feb 11 00:16:30.744 UTC: Tnl 3260 L2TP: O Resend SCCRQ, flg TLS, ver 2, len 127,
tnl 0, cl 0, ns 0, nr 0
Feb 11 00:16:44.456 UTC: %ISDN-6-DISCONNECT: Interface Serial0/0:0 disconnected
from 2222 , call lasted 37 seconds
Feb 11 00:16:44.508 UTC: %LINK-3-UPDOWN: Interface Serial0/0:0, changed state to down
CalCity_LAC#
CH01i.book Page 316 Friday, April 30, 2004 8:58 AM
Case Studies 317
So far, you know that the call is being received from the remote access client, authentication
and authorization are successful, and the tunnel denition is being downloaded. You also know
that the LAC is attempting to initiate tunnel setup by sending SCCRQ message to the LNS. All
of this looks OK, so why is there no response from the LNS?
The next step therefore is to have a look at what, if anything, is being received on the LNS.
When the remote access client reconnects, use the debug vpdn l2x-events command on the
LNS to examine what is being received.
Example 4-116 shows the output of the debug vpdn l2x-events command on the LNS.
As you can see, the output is pretty repetitive. Highlighted lines 1 to 6 show incoming (I)
SCCRQ messages from the LAC. However, there is no response from the LNS. Again, you need
to dig a little bit deeper to nd out why. You can accomplish this with the debug vpdn l2x-
errors command, as demonstrated in Example 4-117.
Example 4-116 Verifying L2TP Tunnel Establishment on the LNS
Skydance_LNS#debug vpdn l2x-events
L2X protocol events debugging is on
Skydance_LNS#
Feb 11 00:21:42.391 UTC: L2TP: I SCCRQ from 12 tnl 42472
Skydance_LNS#
Feb 11 00:21:43.391 UTC: L2TP: I SCCRQ from 12 tnl 42472
Skydance_LNS#
Feb 11 00:21:44.391 UTC: L2TP: I SCCRQ from 12 tnl 42472
Skydance_LNS#
Feb 11 00:21:46.391 UTC: L2TP: I SCCRQ from 12 tnl 42472
Skydance_LNS#
Feb 11 00:21:50.391 UTC: L2TP: I SCCRQ from 12 tnl 42472
Skydance_LNS#
Feb 11 00:21:58.391 UTC: L2TP: I SCCRQ from 12 tnl 42472
Skydance_LNS#
Example 4-117 debug vpdn l2x-errors Command Output
Skydance_LNS#debug vpdn l2x-errors
L2X protocol errors debugging is on
Skydance_LNS#
Feb 11 00:22:27.099 UTC: L2TP: Could not find info block for 12
Feb 11 00:22:28.099 UTC: L2TP: Could not find info block for 12
Skydance_LNS#
Feb 11 00:22:29.099 UTC: L2TP: Could not find info block for 12
Skydance_LNS#
Feb 11 00:22:31.099 UTC: L2TP: Could not find info block for 12
Skydance_LNS#
Feb 11 00:22:35.099 UTC: L2TP: Could not find info block for 12
Skydance_LNS#
Feb 11 00:22:43.099 UTC: L2TP: Could not find info block for 12
Skydance_LNS#
Feb 11 00:22:51.099 UTC: L2TP: Could not find info block for 12
Skydance_LNS#
Feb 11 00:22:59.099 UTC: L2TP: Could not find info block for 12
Skydance_LNS#
CH01i.book Page 317 Friday, April 30, 2004 8:58 AM
318 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
The output is reporting the error L2TP: Could not nd info block for 12. You will notice that
this error is reported several times. This is because the error is reported each time an SCCRQ
message is received.
But what does it mean? In particular, what is the signicance of the 12? If you look back to
Example 4-114, highlighted line 4, you will see that the tunnel ID downloaded with the tunnel
denition from the RADIUS server was, in fact, 12. The LNS is clearly unable to nd an info
block corresponding to this tunnel ID.
But what is the tunnel ID? The tunnel ID should correspond to the hostname of the LAC, as
specied by the terminate-from command in the VPDN group on the LNS. The VPDN group
is then examined using the show running-cong command.
Example 4-118 shows the conguration of the VPDN group on the LNS. Note that only the
relevant portion of the output is shown.
As you can see, the LNS is not congured to terminate tunnels from a LAC with hostname 12.
It is congured to terminate tunnels from CalCity_LAC. So the problem is with the tunnel ID
dened on the RADIUS server. It must be modied to correspond to the hostname of the LAC
(CalCity_LAC).
Figure 4-31 shows the erroneous L2TP tunnel denition conguration within Group Setup on
the CiscoSecure ACS. Note that the group corresponds to user mjlnet.com.
Example 4-118 Configuration of the VPDN Group on the LNS
Skydance_LNS#show running-config
Building configuration...
!
vpdn-group 1
accept-dialin
protocol l2tp
virtual-template 1
terminate-from hostname CalCity_LAC
l2tp tunnel password 7 01100F175804
!
CH01i.book Page 318 Friday, April 30, 2004 8:58 AM
Case Studies 319
Figure 4-31 Erroneous L2TP Tunnel Definition
As you can see, the VPDN tunnel ID is congured as 12. The tunnel ID is modied to reect
the hostname of the LAC (Calcity_LAC).
Figure 4-32 shows the new conguration of the VPDN tunnel ID within Group Setup on the
CiscoSecure ACS.
CH01i.book Page 319 Friday, April 30, 2004 8:58 AM
320 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
Figure 4-32 Modified Tunnel ID
Once the VPDN tunnel ID has been corrected, the remote access client reconnects to the LAC,
and L2TP tunnel establishment is successful.
To verify successful tunnel establishment, use the show vpdn tunnel all, as demonstrated in
Example 4-119.
Example 4-119 Verifying Successful L2TP Tunnel Establishment
CalCity_LAC#show vpdn tunnel all
L2TP Tunnel Information Total tunnels 1 sessions 1
Tunnel id 16148 is up, remote id is 63863, 1 active sessions
Tunnel state is established, time since change 00:00:58
Remote tunnel name is Skydance_LNS
Internet Address 172.16.5.5, port 1701
Local tunnel name is CalCity_LAC
CH01i.book Page 320 Friday, April 30, 2004 8:58 AM
Case Studies 321
Highlighted line 1 shows that one L2TP tunnel and one session have been successfully
established. Highlighted lines 2 and 3 show the remote tunnel name (Skydance_LNS), together
with the LNSs IP address and UDP port over which the L2TP tunnel has been established.
Highlighted lines 4 and 5 show the local tunnel name (CalCity_LAC), together with the LACs
IP address and UDP port over which the will to tunnel has been established. L2TP tunnel setup
is successful, and the issue has been resolved.
Other common issues with tunnel denitions are user password misconguration, service-type
(attribute 6) misconguration, and IP address assignment. When conguring tunnel denitions,
ensure that the password of the user (domain) associated with the tunnel denition is cisco on
the RADIUS server. This must be used because it is hard-coded on Cisco routers.
Additionally, the service-type (attribute 6) should be congured as outbound or dialout
framed. This attribute can be found in group setup if you are using a CiscoSecure ACS.
If you are using a CiscoSecure ACS, ensure that No IP Assignment is specied in either the
user or group setup (remember that IPCP will be negotiated with the LNS, and not the LAC).
Finally, it is also worth briey examining an L2TP tunnel denition in Merit format using
Cisco AVPs.
Example 4-120 shows an L2TP tunnel denition on a Merit RADIUS server.
Internet Address 172.16.1.1, port 1701
20 packets sent, 34 received
1574 bytes sent, 1776 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
%No active L2F tunnels
%No active PPTP tunnels
%No active PPPoE tunnels
CalCity_LAC#
Example 4-120 L2TP Tunnel Definition on a Merit RADIUS Server
mjlnet.com Password = "cisco"
Service-Type = Outbound-User,
cisco-avpair = "vpdn:tunnel-id=CalCity_LAC",
cisco-avpair = "vpdn:tunnel-type=l2tp",
cisco-avpair = "vpdn:ip-addresses=172.16.5.5",
cisco-avpair = "vpdn:l2tp-tunnel-password=cisco"
Example 4-119 Verifying Successful L2TP Tunnel Establishment (Continued)
CH01i.book Page 321 Friday, April 30, 2004 8:58 AM
322 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
Highlighted line 1 shows the username (mjlnet.com). This is the domain name contained
within the usernames of remote access clients (username@domain_name) connecting to the
LAC. Also in highlighted line 1 is the hard-coded password for Cisco routers (cisco). The
service type (Outbound-User) is shown in highlighted line 2.
Highlighted lines 3 to 6 show the tunnel ID (CalCity_LAC), the IP address of the LNS
(172.16.5.5), and the shared tunnel password (cisco in this example).
Case Study 2: Remote AAA (RADIUS) Authentication Failure on the LNS
When supporting more than a handful of remote access clients, authentication using remote
AAA is a much more viable option than local authentication on the LNS. Troubleshooting
remote AAA authentication on the LNS does not need to be that much more difcult than
troubleshooting local authentication.
The rst command used when troubleshooting this issue is debug ppp negotiation. You can
use this command to conrm that authentication is indeed causing PPP negotiation failure
between the remote access client and the LNS.
Example 4-121 shows the output of the debug ppp negotiation command with authentication
failure. Note that only the relevant portion of the output is shown.
The PPP authentication phase begins in highlighted line 1. In highlighted line 2, the LNS sends
a CHAP challenge to the remote access client. Then in highlighted line 3, the remote access
client (joebloggs@mjlnet.com) sends its response.
Highlighted line 4 is where things start to go downhill. The LNS reports that it is unable to
validate the remote access client response. A CHAP failure message is then sent to the remote
access client (highlighted line 5). The PPP phase changes to TERMINATING in highlighted
Example 4-121 PPP Authentication Failure on the LNS
Skydance_LNS#debug ppp negotiation
PPP protocol negotiation debugging is on
Skydance_LNS#
Feb 11 00:38:30.811 UTC: Vi1 PPP: Phase is AUTHENTICATING, by this end
Feb 11 00:38:30.811 UTC: Vi1 CHAP: O CHALLENGE id 24 len 33 from "Skydance_LNS"
Feb 11 00:38:30.811 UTC: Vi1 CHAP: I RESPONSE id 24 len 40
from "joebloggs@mjlnet.com"
Feb 11 00:38:30.975 UTC: Vi1 CHAP: Unable to validate Response. Username
joebloggs@mjlnet.com: Authentication failure
Feb 11 00:38:30.975 UTC: Vi1 CHAP: O FAILURE id 24 len 14 msg is "RejectedJM"
Feb 11 00:38:30.975 UTC: Vi1 PPP: Phase is TERMINATING
Feb 11 00:38:30.979 UTC: Vi1 LCP: O TERMREQ [Open] id 1 len 4
Feb 11 00:38:30.991 UTC: Vi1 LCP: I TERMACK [TERMsent] id 1 len 4
Feb 11 00:38:30.991 UTC: Vi1 LCP: State is Closed
Feb 11 00:38:30.991 UTC: Vi1 PPP: Phase is DOWN
Skydance_LNS#
CH01i.book Page 322 Friday, April 30, 2004 8:58 AM
Case Studies 323
line 6, and in highlighted line 7, the LNS sends an LCP Terminate-Request (TERMREQ) to the
remote access client. The client responds with a Terminate-Ack (TERMACK) in highlighted
line 8. The PPP phase changes state to DOWN in highlighted line 9, and the connection is
terminated. It seems that the problem is an authentication failure.
Because RADIUS is being used, two more commands that can be used to clarify what is going
on are debug aaa authentication and debug radius. When the remote access client reconnects,
the debug aaa authentication command is used.
Example 4-122 shows the output of the debug aaa authentication command.
Virtual-access interface 1 changes state to up in highlighted line 1. The remote access client has
connected to the LNS. In highlighted line 2, user joebloggs@mjlnet.com is created.
Highlighted line 3 shows that login authentication for service ppp is taking place. Highlighted
line 4 then shows that the default method list has been chosen, and that the authentication
method is RADIUS (highlighted line 5). Unfortunately, as you can see in highlighted line 6,
RADIUS authentication fails.
The debug radius command shows this process a little more clearly, as demonstrated in
Example 4-123.
Example 4-122 debug aaa authentication Command Output
Skydance_LNS#debug aaa authentication
AAA Authentication debugging is on
Skydance_LNS#
Feb 11 00:39:17.271 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state
to up
Skydance_LNS#
Feb 11 00:39:17.391 UTC: AAA: parse name=Virtual-Access1 idb type=21 tty=-1
Feb 11 00:39:17.391 UTC: AAA: name=Virtual-Access1 flags=0x11 type=5 shelf=0 slot=0
adapter=0 port=1 channel=0
Feb 11 00:39:17.391 UTC: AAA/MEMORY: create_user (0x62ED5038)
user=joebloggs@mjlnet.com ruser=NULL ds0=0 port=Virtual-Access1
rem_addr=1111/7777 authen_type=CHAP service=PPP priv=1 initial_task_id=0
Feb 11 00:39:17.391 UTC: AAA/AUTHEN/START (1139933244): port=Virtual-Access1
list= action=LOGIN service=PPP
Feb 11 00:39:17.391 UTC: AAA/AUTHEN/START (1139933244): using "default" list
Feb 11 00:39:17.391 UTC: AAA/AUTHEN/START (1139933244): Method=radius (radius)
Feb 11 00:39:17.395 UTC: AAA/AUTHEN (1139933244): status = FAIL
Feb 11 00:39:17.395 UTC: AAA/MEMORY: free_user (0x62ED5038)
user=joebloggs@mjlnet.com ruser=NULL port=Virtual-Access1
rem_addr=1111/7777 authen_type=CHAP service=PPP priv=1
Feb 11 00:39:21.239 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state
to down
Skydance_LNS#
CH01i.book Page 323 Friday, April 30, 2004 8:58 AM
324 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
In highlighted line 1, the virtual-access interface 1 changes state to up. The remote access client
is now connected to the LNS.
Highlighted line 2 shows the LNS transmitting an access-request message to the RADIUS
server. This access-request message is used to authenticate the remote access client and
contains a number of attributes, such as the remote access clients username and password.
Then in highlighted line 3, a response is received from the RADIUS server. This takes the form
of an access-reject message. The access-reject message indicates that the information contained
in the access-request message was invalid. Authentication has failed.
An authentication failure indicates that the username or the password is incorrectly congured
on either the remote access client or the RADIUS server. In this case, the remote access client
conrms that the username and password are correctly congured. Therefore, one or the other
must be incorrectly congured on the RADIUS server.
The username is correct on the RADIUS server, so the only other possibility is that the
password is incorrect. The password, therefore, must be corrected. A CiscoSecure ACS is being
used in this case, and the password is corrected within the user setup.
Figure 4-33 shows the password conguration within the user setup.
Example 4-123 debug radius Command Output
Skydance_LNS#debug radius
Radius protocol debugging is on
Skydance_LNS#
Feb 11 00:39:41.315 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state
to up
Feb 11 00:39:41.315 UTC: RADIUS: ustruct sharecount=1
Feb 11 00:39:41.315 UTC: RADIUS: Initial Transmit Virtual-Access1 id 39
10.20.10.5:1645, Access-Request, len 102
Feb 11 00:39:41.315 UTC: Attribute 4 6 0A020201
Feb 11 00:39:41.315 UTC: Attribute 5 6 00000001
Feb 11 00:39:41.315 UTC: Attribute 61 6 00000005
Feb 11 00:39:41.315 UTC: Attribute 1 21 6A6F6562
Feb 11 00:39:41.315 UTC: Attribute 30 6 37373737
Feb 11 00:39:41.319 UTC: Attribute 31 6 32323232
Feb 11 00:39:41.319 UTC: Attribute 3 19 21C686AF
Feb 11 00:39:41.319 UTC: Attribute 6 6 00000002
Feb 11 00:39:41.319 UTC: Attribute 7 6 00000001
Feb 11 00:39:41.803 UTC: RADIUS: Received from id 39 10.20.10.5:1645, Access-Reject,
len 32
Feb 11 00:39:41.803 UTC: Attribute 18 12 52656A65
Skydance_LNS#
CH01i.book Page 324 Friday, April 30, 2004 8:58 AM
Case Studies 325
Figure 4-33 Password Configuration
The remote access client reconnects, and authentication succeeds. This is conrmed using the
show caller user command, as demonstrated in Example 4-124.
Example 4-124 Verifying PPP Negotiation Success
Skydance_LNS#show caller user joebloggs@mjlnet.com
User: joebloggs@mjlnet.com, line Vi1, service PPP L2TP
Connected for 00:06:44, Idle for 00:00:26
Timeouts: Limit Remaining Timer Type
- - -
PPP: LCP Open, multilink Closed, CHAP (<- none), IPCP
IP: Local 172.16.5.5, remote 10.1.1.1
VPDN: NAS CalCity_LAC, MID 2, MID Unknown
HGW , NAS CLID 0, HGW CLID 0, tunnel open
Counts: 116 packets input, 8192 bytes, 0 no buffer
CH01i.book Page 325 Friday, April 30, 2004 8:58 AM
326 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
In highlighted line 1, you can see that user joebloggs@mjlnet.com is connected to interface
virtual-access 1 (vi1).
Highlighted line 2 shows that LCP is in an open state, that PPP multilink was not negotiated
and is in a closed state, that the authentication protocol used is CHAP, and that IPCP was
negotiated.
Highlighted line 3 shows the IP address congured on virtual-access interface 1 (172.16.5.5),
together with the IP address assigned to the remote access client (10.1.1.1).
Finally, in highlighted line 4, the hostname of the LAC (CalCity_LAC) is shown. The issue has
been resolved.
Case Study 3: Remote AAA (RADIUS) Authorization Failure on the LNS
When using remote AAA on the LNS, the RADIUS server not only authenticates but also
authorizes remote access clients. If RADIUS attributes are not congured correctly,
authorization will fail. If authorization fails, PPP negotiation with the remote access client will
also fail.
To debug an authorization failure, the rst command to use is the debug ppp negotiation
command, as demonstrated in Example 4-125. Only the relevant portion of the output is shown.
0 input errors, 0 CRC, 0 frame, 0 overrun
176 packets output, 8698 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
Skydance_LNS#
Example 4-125 debug ppp negotiation Command Output
Skydance_LNS#debug ppp negotiation
PPP protocol negotiation debugging is on
Skydance_LNS#
Feb 11 00:50:23.511 UTC: Vi1 PPP: Phase is AUTHENTICATING, by this end
Feb 11 00:50:23.511 UTC: Vi1 CHAP: O CHALLENGE id 55 len 33 from "Skydance_LNS"
Feb 11 00:50:23.511 UTC: Vi1 CHAP: I RESPONSE id 55 len 40 from
"joebloggs@mjlnet.com"
Feb 11 00:50:23.527 UTC: Vi1 CHAP: O FAILURE id 55 len 24 msg is
"Authorization failed"
Feb 11 00:50:23.527 UTC: Vi1 PPP: Phase is TERMINATING
Feb 11 00:50:23.527 UTC: Vi1 LCP: O TERMREQ [Open] id 1 len 4
Feb 11 00:50:23.543 UTC: Vi1 LCP: I TERMACK [TERMsent] id 1 len 4
Feb 11 00:50:23.543 UTC: Vi1 LCP: State is Closed
Feb 11 00:50:23.543 UTC: Vi1 PPP: Phase is DOWN
Skydance_LNS#
Example 4-124 Verifying PPP Negotiation Success (Continued)
CH01i.book Page 326 Friday, April 30, 2004 8:58 AM
Case Studies 327
In highlighted line 1, the PPP phase changes to AUTHENTICATING, and authentication
begins. The rst thing that happens during the authentication phase is that the LNS sends a
CHAP challenge to the remote access client (highlighted line 2). The remote access client
replies with a CHAP response message (highlighted line 3). Note the username of the remote
access client shown in the response message (joebloggs@mjlnet.com).
Then in highlighted line 4, the LNS sends a CHAP failure message to the remote access client.
Note that the accompanying message indicates that authorization has failed.
Once authorization has failed, the PPP phase changes to TERMINATING (highlighted line 5),
and the LNS sends a TERMREQ message to the remote access client (highlighted line 6).
In highlighted line 7, the remote access client responds with a TERMACK, and nally in
highlighted line 8, the PPP phase changes to DOWN. Authorization has failed, and PPP
negotiation between the remote access client and the LNS has been terminated.
To debug AAA authorization failures, the debug aaa authorization and debug radius
commands are very useful. When the remote access client reconnects, the debug aaa
authorization command is used.
Examples 4-126 to 4-127 show the output of the debug aaa authorization command.
Virtual-access interface 1 changes state to up in highlighted line 1 (Example 4-126), indicating
that the remote access client has connected to the LNS. In highlighted line 2, user
joebloggs@mjlnet.com is created. Authorization then fails, as shown in Example 4-127.
Example 4-126 debug aaa authorization Command Output
Skydance_LNS#debug aaa authorization
AAA Authorization debugging is on
Skydance_LNS#
Feb 11 00:51:25.475 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state
to up
Feb 11 00:51:25.475 UTC: AAA: parse name=Virtual-Access1 idb type=21 tty=-1
Feb 11 00:51:25.475 UTC: AAA: name=Virtual-Access1 flags=0x11 type=5 shelf=0 slot=0
adapter=0 port=1 channel=0
Feb 11 00:51:25.475 UTC: AAA/MEMORY: create_user (0x628581B0)
user=joebloggs@mjlnet.com ruser= port=Virtual-Access1 rem_addr=2222/7777
authen_type=CHAP service=PPP priv=1
Feb 11 00:51:25.867 UTC: Vi1 AAA/AUTHOR/LCP: Authorize LCP
Feb 11 00:51:25.867 UTC: Vi1 AAA/AUTHOR/LCP (463461848): Port=Virtual-Access1
list= service=NET
Feb 11 00:51:25.867 UTC: AAA/AUTHOR/LCP: Vi1 (463461848) user=joebloggs@mjlnet.com
CH01i.book Page 327 Friday, April 30, 2004 8:58 AM
328 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
Authorization is sought for service ppp and protocol lcp (highlighted lines 1 and 2, Example
4-127). The default method list is selected, and RADIUS authorization is chosen (highlighted
lines 3 and 4). Authorization with the RADIUS server now begins.
The RADIUS server responds to the authorization request, and in highlighted line 5, the
response is shown. Authorization has failed.
The debug radius command can be used to show the authorization process in greater detail.
When the remote access client reconnects to the LNS, the debug radius command is used.
Example 4-128 shows the output of the debug radius command when the remote access client
reconnects.
Example 4-127 Authorization Fails
Feb 11 00:51:25.867 UTC: Vi1 AAA/AUTHOR/LCP (463461848): send AV service=ppp
Feb 11 00:51:25.867 UTC: Vi1 AAA/AUTHOR/LCP (463461848): send AV protocol=lcp
Feb 11 00:51:25.867 UTC: Vi1 AAA/AUTHOR/LCP (463461848): found list "default"
Feb 11 00:51:25.867 UTC: Vi1 AAA/AUTHOR/LCP (463461848): Method=radius (radius)
Feb 11 00:51:25.867 UTC: Vi1 AAA/AUTHOR (463461848): Post authorization status = FAIL
Feb 11 00:51:25.867 UTC: Vi1 AAA/AUTHOR/LCP: Denied
Feb 11 00:51:25.867 UTC: AAA/MEMORY: free_user (0x628581B0)
user=joebloggs@mjlnet.com ruser= port=Virtual-Access1 rem_addr=2222/7777
authen_type=CHAP service=PPP priv=1
Skydance_LNS#
Example 4-128 debug radius Command Output
Skydance_LNS#debug radius
Radius protocol debugging is on
Skydance_LNS#
Feb 11 00:51:55.643 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state
to up
Feb 11 00:51:55.643 UTC: RADIUS: ustruct sharecount=1
Feb 11 00:51:55.643 UTC: RADIUS: Initial Transmit Virtual-Access1 id 80
10.20.10.5:1645, Access-Request, len 102
Feb 11 00:51:55.643 UTC: Attribute 4 6 0A020201
Feb 11 00:51:55.643 UTC: Attribute 5 6 00000001
Feb 11 00:51:55.643 UTC: Attribute 61 6 00000005
Feb 11 00:51:55.647 UTC: Attribute 1 21 6A6F6562
Feb 11 00:51:55.647 UTC: Attribute 30 6 37373737
Feb 11 00:51:55.647 UTC: Attribute 31 6 32323232
Feb 11 00:51:55.647 UTC: Attribute 3 19 46F252F6
Feb 11 00:51:55.647 UTC: Attribute 6 6 00000002
Feb 11 00:51:55.647 UTC: Attribute 7 6 00000001
Skydance_LNS#
Feb 11 00:51:55.659 UTC: RADIUS: Received from id 80 10.20.10.5:1645, Access-Accept,
len 38
Feb 11 00:51:55.659 UTC: Attribute 6 6 00000001
Feb 11 00:51:55.659 UTC: Attribute 7 6 00000001
Feb 11 00:51:55.659 UTC: Attribute 8 6 FFFFFFFF
Feb 11 00:51:55.659 UTC: RADIUS: no appropriate authorization type for user.
Skydance_LNS#
CH01i.book Page 328 Friday, April 30, 2004 8:58 AM
Case Studies 329
Highlighted line 1 shows virtual-access interface 1 changing state to up. The remote access
client has connected.
Highlighted line 2 shows the LNS trying to authenticate and authorize the remote access client
by sending an access-request message to the RADIUS server.
Highlighted line 3 shows that a response has been received from the RADIUS server. The
response is an access-accept message.
The access-accept message seems to indicate all is well, but in highlighted line 4, the LNS reports
no appropriate authorization type for user. This indicates that authorization has failed.
An investigation of the user and group setup on the CiscoSecure ACS reveals the problem.
Figure 4-34 shows the IETF RADIUS attributes congured within the users group settings.
Figure 4-34 IETF RADIUS Attributes Configured in the Group Settings
CH01i.book Page 329 Friday, April 30, 2004 8:58 AM
330 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
As you can see, the Service-Type attribute is congured as Framed, but the Framed-protocol
is not checked. This is the problem. The Framed-protocol should be checked and specied as
PPP, as shown in Figure 4-35.
Figure 4-35 Framed-protocol Is Specified as PPP
Once the group settings (IETF RADIUS attributes) have been corrected, the remote access
client reconnects. PPP negotiation between the remote access client is now successful, which
you can conrm using the show caller user command, as demonstrated in Example 4-129.
Example 4-129 Verifying PPP Negotiation
Skydance_LNS#show caller user joebloggs@mjlnet.com
User: joebloggs@mjlnet.com, line Vi1, service PPP L2TP
Connected for 00:01:02, Idle for 00:00:45
Timeouts: Limit Remaining Timer Type
- - -
PPP: LCP Open, multilink Closed, CHAP (<- none), IPCP
CH01i.book Page 330 Friday, April 30, 2004 8:58 AM
Case Studies 331
Highlighted line 1 shows that user joebloggs@mjlnet.com is connected to interface virtual-
access 1 (vi1). In highlighted line 2, you can see that LCP is in an open state, PPP multilink was
not negotiated and is in a closed state, the authentication protocol is CHAP, and IPCP was
negotiated. Then in highlighted line 3, you can see the IP address congured on virtual-access
interface 1 (172.16.5.5), together with the IP address assigned to the remote access client
(10.1.1.1). Finally, in highlighted line 4, the hostname of the LAC (CalCity_LAC) is shown.
Case Study 4: AAA (RADIUS) Server Unreachable from the LNS
When using RADIUS servers, you must of course ensure that the server or servers (if more than
one is congured) are reachable. To troubleshoot AAA server connectivity problems, the rst
command to use is the debug ppp negotiation command.
Examples 4-130 to 4-131 show the output of the debug ppp negotiation command when the
RADIUS server is unreachable. Note that only the relevant portion of the output is shown.
In highlighted line 1, the PPP phase changes to AUTHENTICATING. Highlighted line 2 shows
the LNS sending a CHAP challenge to the remote access client, and in highlighted line 3, the
IP: Local 172.16.5.5, remote 10.1.1.1
VPDN: NAS CalCity_LAC, MID 3, MID Unknown
HGW , NAS CLID 0, HGW CLID 0, tunnel open
Counts: 40 packets input, 3864 bytes, 0 no buffer
0 input errors, 0 CRC, 0 frame, 0 overrun
34 packets output, 1567 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
Skydance_LNS#
Example 4-130 debug ppp negotiation Command Output
Skydance_LNS#debug ppp negotiation
PPP protocol negotiation debugging is on
Skydance_LNS#
Feb 11 00:59:00.827 UTC: Vi1 PPP: Phase is AUTHENTICATING, by this end
Feb 11 00:59:00.827 UTC: Vi1 CHAP: O CHALLENGE id 76 len 33 from "Skydance_LNS"
Feb 11 00:59:00.827 UTC: Vi1 CHAP: I RESPONSE id 77 len 40 from
"joebloggs@mjlnet.com"
Feb 11 00:59:02.827 UTC: Vi1 LCP: TIMEout: State Open
Feb 11 00:59:10.711 UTC: Vi1 CHAP: I RESPONSE id 77 len 40 from
"joebloggs@mjlnet.com"
Feb 11 00:59:10.711 UTC: Vi1 AUTH: Duplicate authentication request id=77 already
in progress
Feb 11 00:59:20.711 UTC: Vi1 CHAP: I RESPONSE id 77 len 40 from
"joebloggs@mjlnet.com"
Feb 11 00:59:20.711 UTC: Vi1 AUTH: Duplicate authentication request id=77 already
in progress
Example 4-129 Verifying PPP Negotiation (Continued)
CH01i.book Page 331 Friday, April 30, 2004 8:58 AM
332 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
response is received (joebloggs@mjlnet.com). This all looks good, and now either a success
or failure message should be sent by the LNS to indicate whether or not authentication was
successful.
But in highlighted line 4, another CHAP response message is received from the remote access
client. Then in highlighted line 5, yet another response message is received. But no success or
failure message is sent to the remote access client by the LNS.
In Example 4-131, the LNS is unable to validate the remote access clients CHAP response.
In highlighted line 1 (Example 4-131), the LNS reports that it is unable to validate the remote
access clients response message, and authentication has failed. This is communicated to the
remote access client when the LNS sends it a failure message in highlighted line 2. Notice the
text sent with the failure message: No response from server. This is a pretty hefty hint as to
the problem.
In highlighted line 3, the PPP phase changes to TERMINATING, and in highlighted line 4, the
LNS sends a Terminate-Request (TERMREQ) message to the remote access client.
Immediately thereafter, in highlighted line 5, the remote access client replies with a Terminate-
Ack (TERMACK) message. Finally, in highlighted line 6, the PPP phase changes to DOWN.
The remote access client has disconnected.
You can also use the debug aaa authentication and debug radius commands to troubleshoot
this issue.
Example 4-132 shows the output of the debug aaa authentication command.
Example 4-131 LNS Is Unable to Validate the Remote Access Clients CHAP Response
Feb 11 00:59:20.831 UTC: Vi1 CHAP: Unable to validate Response. Username
joebloggs@mjlnet.com: Authentication failure
Feb 11 00:59:20.831 UTC: Vi1 CHAP: O FAILURE id 77 len 27 msg is
"No response from server"
Feb 11 00:59:20.831 UTC: Vi1 PPP: Phase is TERMINATING
Feb 11 00:59:20.831 UTC: Vi1 LCP: O TERMREQ [Open] id 1 len 4
Feb 11 00:59:20.843 UTC: Vi1 LCP: I TERMACK [TERMsent] id 1 len 4
Feb 11 00:59:20.843 UTC: Vi1 LCP: State is Closed
Feb 11 00:59:20.847 UTC: Vi1 PPP: Phase is DOWN
Skydance_LNS#
Example 4-132 debug aaa authentication Command Output
Skydance_LNS#debug aaa authentication
AAA Authentication debugging is on
Skydance_LNS#
Feb 11 00:56:05.539 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state
to up
Feb 11 00:56:05.663 UTC: AAA: parse name=Virtual-Access1 idb type=21 tty=-1
Feb 11 00:56:05.663 UTC: AAA: name=Virtual-Access1 flags=0x11 type=5 shelf=0 slot=0
adapter=0 port=1 channel=0
Feb 11 00:56:05.663 UTC: AAA/MEMORY: create_user (0x62ED4E24)
user=joebloggs@mjlnet.com ruser=NULL ds0=0 port=Virtual-Access1
CH01i.book Page 332 Friday, April 30, 2004 8:58 AM
Case Studies 333
Interface virtual-access 1 changes state to up in highlighted line 1, and the remote access client
is connected to the LNS. User joebloggs@mjlnet.com is created in highlighted line 2. The
authentication type is listed as CHAP, and the service as PPP. In highlighted line 3, the action
is shown as LOGIN, and again the service is shown as PPP. The default method list is selected
for authentication in highlighted line 4, and the method is RADIUS (highlighted line 5).
In highlighted line 6, an error is returned. This is not good. Notice that the status is neither pass
nor fail. The error actually tells you that communication was not successfully established with
the RADIUS server.
Then in highlighted line 7, the LNS indicates that there are no other authentication methods left
to try, and that authentication has failed (highlighted line 8).
This can be seen more clearly using the debug radius command, as demonstrated in Example 4-133.
rem_addr=1111/7777 authen_type=CHAP service=PPP priv=1 initial_task_id=0
Feb 11 00:56:05.663 UTC: AAA/AUTHEN/START (3169148055): port=Virtual-Access1 list=
action=LOGIN service=PPP
Feb 11 00:56:05.663 UTC: AAA/AUTHEN/START (3169148055): using "default" list
Feb 11 00:56:05.663 UTC: AAA/AUTHEN/START (3169148055): Method=radius (radius)
Feb 11 00:56:25.663 UTC: AAA/AUTHEN (3169148055): status = ERROR
Feb 11 00:56:25.663 UTC: AAA/AUTHEN/START (3169148055): no methods left to try
Feb 11 00:56:25.663 UTC: AAA/AUTHEN (3169148055): status = ERROR
Feb 11 00:56:25.663 UTC: AAA/AUTHEN/START (3169148055): failed to authenticate
Feb 11 00:56:25.663 UTC: AAA/MEMORY: free_user (0x62ED4E24)
user=joebloggs@mjlnet.com ruser=NULL port=Virtual-Access1 rem_addr=1111/7777
authen_type=CHAP service=PPP priv=1
Skydance_LNS#
Example 4-133 debug radius Command Output
Skydance_LNS#debug radius
Radius protocol debugging is on
Skydance_LNS#
Feb 11 01:01:23.763 UTC: %LINK-3-UPDOWN: Interface Virtual-Access1, changed state
to up
Skydance_LNS#
Feb 11 01:01:23.763 UTC: RADIUS: ustruct sharecount=1
Feb 11 01:01:23.763 UTC: RADIUS: Initial Transmit Virtual-Access1 id 91
10.20.10.5:1645, Access-Request, len 102
Feb 11 01:01:23.763 UTC: Attribute 4 6 0A020201
Feb 11 01:01:23.763 UTC: Attribute 5 6 00000001
Feb 11 01:01:23.763 UTC: Attribute 61 6 00000005
Feb 11 01:01:23.763 UTC: Attribute 1 21 6A6F6562
Feb 11 01:01:23.767 UTC: Attribute 30 6 37373737
Feb 11 01:01:23.767 UTC: Attribute 31 6 32323232
Feb 11 01:01:23.767 UTC: Attribute 3 19 50A99C0E
Feb 11 01:01:23.767 UTC: Attribute 6 6 00000002
Feb 11 01:01:23.767 UTC: Attribute 7 6 00000001
Example 4-132 debug aaa authentication Command Output (Continued)
CH01i.book Page 333 Friday, April 30, 2004 8:58 AM
334 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
Highlighted line 1 shows virtual-access interface 1 changing state to up. In highlighted line 2,
an access-request message is sent to the RADIUS server. This access-request message includes
a number of attributes, such as the remote access clients username and password.
The message is retransmitted by the LNS in highlighted lines 3, 4, and 5. No response is
received from the RADIUS server, and in highlighted line 6, the LNS indicates that it considers
the RADIUS server (10.20.10.5) to be dead. In highlighted line 7, the LNS indicates that no
valid server has been found, and that it will try any valid server. Then nally in highlighted line
8, the LNS reports that there has been no response.
The lack of response from the RADIUS server could be due to a number of reasons. Some
common reasons are a lack of IP connectivity between the LNS and the RADIUS server,
misconguration of the RADIUS servers IP address on the LNS (or vice-versa), or a
mismatched RADIUS server key. You should test IP connectivity using a ping.
Example 4-134 shows the output of the ping command when pinging the RADIUS server.
As you can see, there is no IP connectivity to the RADIUS server from the LNS.
In this case, removing an access list on an intermediate router (not shown) restores IP
connectivity to the RADIUS server. The remote access client reconnects to the LNS, and
authentication succeeds, as veried by using the show caller user command in Example 4-135.
Skydance_LNS#
Feb 11 01:01:28.767 UTC: RADIUS: Retransmit id 91
Skydance_LNS#
Feb 11 01:01:33.767 UTC: RADIUS: Retransmit id 91
Skydance_LNS#
Feb 11 01:01:38.767 UTC: RADIUS: Retransmit id 91
Skydance_LNS#
Feb 11 01:01:43.767 UTC: RADIUS: Marking server 10.20.10.5:1645,1646 dead
Feb 11 01:01:43.767 UTC: RADIUS: Tried all servers.
Feb 11 01:01:43.767 UTC: RADIUS: No valid server found. Trying any viable server
Feb 11 01:01:43.767 UTC: RADIUS: Tried all servers.
Feb 11 01:01:43.767 UTC: RADIUS: No response for id 91
Feb 11 01:01:43.767 UTC: RADIUS: No response from server
Skydance_LNS#
Example 4-134 Testing IP Connectivity to the RADIUS Server
Skydance_LNS#ping 10.20.10.5
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.20.10.5, timeout is 2 seconds:
U.U.U
Success rate is 0 percent (0/5)
Skydance_LNS#
Example 4-133 debug radius Command Output (Continued)
CH01i.book Page 334 Friday, April 30, 2004 8:58 AM
Case Studies 335
Highlighted line 1 shows that user joebloggs@mjlnet.com is connected to interface virtual-
access 1 (vi1).
In highlighted line 2, you can see that LCP is in an open state, PPP multilink is in a closed state,
the authentication protocol is CHAP, and IPCP was negotiated.
Highlighted line 3 shows the IP address congured on virtual-access interface 1 (172.16.5.5),
together with the IP address assigned to the remote access client (10.1.1.1). Then in highlighted
line 4, the hostname of the LAC (CalCity_LAC) is shown. The remote access client has
successfully connected to the LNS, and the issue is resolved.
Case Study 5: Voluntary Tunnel Mode Connectivity from a Windows
2000 Workstation Fails
In voluntary tunnel mode, two of the most popular client/LACs are Windows 2000 and
Windows XP. However, the conguration of voluntary tunnel mode connectivity from these
clients is not quite as simple as that for PPTP.
In this scenario, a Cisco router has been congured as an LNS, and a Windows 2000 client/LAC
is attempting to connect to it. When the Windows 2000 client/LAC attempts to connect to the
LNS, the result is the error message shown in Figure 4-36.
Example 4-135 Verifying PPP Negotiation
Skydance_LNS#show caller user joebloggs@mjlnet.com
User: joebloggs@mjlnet.com, line Vi1, service PPP L2TP
Connected for 00:01:03, Idle for 00:00:45
Timeouts: Limit Remaining Timer Type
- - -
PPP: LCP Open, multilink Closed, CHAP (<- none), IPCP
IP: Local 172.16.5.5, remote 10.1.1.1
VPDN: NAS CalCity_LAC, MID 4, MID Unknown
HGW , NAS CLID 0, HGW CLID 0, tunnel open
Counts: 40 packets input, 3864 bytes, 0 no buffer
0 input errors, 0 CRC, 0 frame, 0 overrun
30 packets output, 1339 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
Skydance_LNS#
CH01i.book Page 335 Friday, April 30, 2004 8:58 AM
336 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
Figure 4-36 Error Message on the Windows 2000/Client LAC
The Error Message in Figure 4-36 reveals that the Windows 2000 client/LAC does not have a
certicate. You may be wondering what a certicate has to do with an L2TP tunnel. The
certicate is needed because, by default, Windows 2000 is congured to secure L2TP tunnels
with IPSec.
Figure 4-37 illustrates a L2TP tunnel secured with IPSec from the Windows 2000 client/LAC
to the LNS.
CH01i.book Page 336 Friday, April 30, 2004 8:58 AM
Case Studies 337
Figure 4-37 L2TPv2 over IPSec Between a Windows 2000 Client/LAC and the LNS
There are two choices, therefore, when conguring a voluntary tunnel between a Windows 2000/
XP client/LAC and an LNS: either IPSec must be disabled on the Windows 2000/XP client/LAC
(consider the security implications before you do this), or the L2TP tunnel must be secured with
IPSec using certicates or a preshared key.
L2TP Without IPSec
To disable IPSec on the Windows 2000/LAC, you must modify the Registry.
To disable IPSec protection for the L2TP tunnel, complete the following steps:
Step 1 Run regedt32.exe.
Step 2 Open the following key in the Registry:
\HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rasman\
Parameters
Step 3 Add the following value:
Value Name: ProhibitIpSec
Data Type: REG_DWORD
Value:1
Step 4 Reboot the Windows 2000/XP client/LAC.
Always be very careful when modifying the Windows Registry because a mistake can, in
extreme cases, make your machine unbootable.
Figure 4-38 shows the Registry on the Windows 2000/LAC being modied to disable IPSec
protection for L2TP tunnels.
IPSec
Remote Access
Client / LAC
(W2K)
LNS
Internet
PPP
L2TP L2TP
PPP
CH01i.book Page 337 Friday, April 30, 2004 8:58 AM
338 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
Figure 4-38 Modification of the Registry on the Windows 2000/LAC
Once IPSec has been disabled for L2TP on the Windows 2000 client/LAC, it reconnects to the
LNS successfully.
Use the show vpdn tunnel all command to verify this is a successful connection, as
demonstrated in Example 4-136.
Example 4-136 Verifying L2TP Tunnel Setup
Skydance_LNS#show vpdn tunnel all
L2TP Tunnel Information Total tunnels 1 sessions 1
Tunnel id 2597 is up, remote id is 9, 1 active sessions
Tunnel state is established, time since change 00:00:57
Remote tunnel name is mark3-note
Internet Address 10.10.10.54, port 1701
Local tunnel name is Skydance_LNS
Internet Address 172.16.5.5, port 1701
CH01i.book Page 338 Friday, April 30, 2004 8:58 AM
Case Studies 339
Highlighted line 1 reveals that one tunnel and one session have been established.
In highlighted lines 2 and 3, the computer name of the remote access client/LAC (mark3-note)
is shown, together with its IP address and UDP port over which the tunnel is established.
In highlighted lines 4 and 5, the local hostname (Skydance_LNS), IP address, and UDP port
for the tunnel are shown.
L2TP tunnel connectivity between the Windows 2000 client/LAC and the LNS has been
successfully established.
L2TP over IPSec with Preshared Keys
The other option to ensure that L2TP tunnel establishment is successful is to congure L2TP
over IPSec on both the Windows 2000 client/LAC and the LNS.
In the following example, the Windows 2000 client/LAC and the LNS are congured for L2TP
over IPSec using preshared keys.
NOTE To congure Windows 2000 client/LACs for preshared key authentication, see Knowledge
Base article 240262 on the Microsoft web site (www.microsoft.com).
For Windows XP client/LACs, see Knowledge Base article 281555.
Congure the Cisco LNS according to the instructions contained in the section entitled
Conguring IPSec Protection for L2TP in Voluntary Tunnel Mode with Pre-Shared Keys at
the beginning of this chapter.
46 packets sent, 71 received
2632 bytes sent, 7425 received
Control Ns 2, Nr 4
Local RWS 10000 (default), Remote RWS 8
Tunnel PMTU checking disabled
Retransmission time 1, max 1 seconds
Unsent queuesize 0, max 0
Resend queuesize 0, max 1
Total resends 0, ZLB ACKs sent 2
Current nosession queue check 0 of 5
Retransmit time distribution: 0 2 0 0 0 0 0 0 0
Sessions disconnected due to lack of resources 0
%No active L2F tunnels
%No active PPTP tunnels
%No active PPPoE tunnels
Skydance_LNS#
Example 4-136 Verifying L2TP Tunnel Setup (Continued)
CH01i.book Page 339 Friday, April 30, 2004 8:58 AM
340 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
Once IPSec has been congured, the Windows 2000 client/LAC successfully connects to
the LNS. Verify connectivity using the show vpdn tunnel command, as demonstrated in
Example 4-137.
Highlighted line 1 shows that one tunnel and one session have been established with the
Windows 2000 client/LAC. Highlighted lines 2 and 3 show the remote tunnel name (computer
name of the Windows 2000 client/LAC), together with its IP address and UDP port on which
the connection has been established. In highlighted lines 4 and 5, the local tunnel name, IP
address, and UDP port over which the tunnel is established are shown.
You can verify the IPSec tunnel between the remote access client/LAC and the LNS using the
show crypto engine connections active and show crypto ipsec sa commands.
Example 4-138 shows the output of the show crypto engine connections active command.
Example 4-137 Verifying L2TP Tunnel Establishment
Skydance_LNS#show vpdn tunnel all
L2TP Tunnel Information Total tunnels 1 sessions 1
Tunnel id 52577 is up, remote id is 3, 1 active sessions
Tunnel state is established, time since change 00:00:14
Remote tunnel name is mark3-note
Internet Address 10.10.10.54, port 1701
Local tunnel name is Skydance_LNS
Internet Address 172.16.5.5, port 1701
21 packets sent, 54 received
1067 bytes sent, 5348 received
Control Ns 2, Nr 4
Local RWS 10000 (default), Remote RWS 8
Tunnel PMTU checking disabled
Retransmission time 1, max 1 seconds
Unsent queuesize 0, max 0
Resend queuesize 0, max 1
Total resends 0, ZLB ACKs sent 2
Current nosession queue check 0 of 5
Retransmit time distribution: 0 2 0 0 0 0 0 0 0
Sessions disconnected due to lack of resources 0
%No active L2F tunnels
%No active PPTP tunnels
%No active PPPoE tunnels
Skydance_LNS#
Example 4-138 Verifying IPSec
Skydance_LNS#show crypto engine connections active
ID Interface IP-Address State Algorithm Encrypt Decrypt
1 Ethernet1/0 172.16.5.5 set HMAC_SHA+DES_56_CB 0 0
2000 Ethernet1/0 172.16.5.5 set HMAC_SHA+DES_56_CB 0 84
2001 Ethernet1/0 172.16.5.5 set HMAC_SHA+DES_56_CB 47 0
Skydance_LNS#
CH01i.book Page 340 Friday, April 30, 2004 8:58 AM
Case Studies 341
Highlighted line 1 shows the security association for ISAKMP. Note the hashing and encryption
algorithms (SHA-1 and DES, respectively).
The IPSec security associations (inbound/outbound) are shown in highlighted lines 2 and 3.
Again, the hashing and encryption algorithms are SHA-1 and DES.
You can obtain more detailed information about the IPSec security associations by using the
show crypto ipsec sa command, as demonstrated in Example 4-139.
Example 4-139 Verifying IPSec Security Associations
Skydance_LNS#show crypto ipsec sa
interface: Ethernet1/0
Crypto map tag: l2tpcryptomap, local addr. 172.16.5.5
local ident (addr/mask/prot/port): (172.16.5.5/255.255.255.255/0/0)
remote ident (addr/mask/prot/port): (10.10.10.54/255.255.255.255/0/0)
current_peer: 10.10.10.54
PERMIT, flags={transport_parent,}
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 172.16.5.5, remote crypto endpt.: 10.10.10.54
path mtu 1500, media mtu 1500
current outbound spi: 0
inbound esp sas:
inbound ah sas:
inbound pcp sas:
outbound esp sas:
outbound ah sas:
outbound pcp sas:
local ident (addr/mask/prot/port): (172.16.5.5/255.255.255.255/17/0)
remote ident (addr/mask/prot/port): (10.10.10.54/255.255.255.255/17/1701)
current_peer: 10.10.10.54
PERMIT,
flags={origin_is_acl,reassembly_needed,transport_parent,parent_is_transport,ident_po
rt_range,}
#pkts encaps: 58, #pkts encrypt: 58, #pkts digest 58
#pkts decaps: 91, #pkts decrypt: 91, #pkts verify 91
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0
#send errors 0, #recv errors 0
local crypto endpt.: 172.16.5.5, remote crypto endpt.: 10.10.10.54
path mtu 1500, media mtu 1500
current outbound spi: B6146600
inbound esp sas:
spi: 0x24121892(605165714)
transform: esp-des esp-sha-hmac ,
in use settings ={Transport, }
slot: 0, conn id: 2000, flow_id: 1, crypto map: l2tpcryptomap
sa timing: remaining key lifetime (k/sec): (99971/56)
IV size: 8 bytes
replay detection support: Y
CH01i.book Page 341 Friday, April 30, 2004 8:58 AM
342 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
Example 4-139 shows a huge amount of information. The name of the crypto map applied to
the L2TP tunnel and the local IP address are shown in highlighted line 1. Highlighted lines 2
and 3 show the local and remote identities (IP addresses).
Then starting from highlighted lines 4 and 5, information concerning inbound and outbound
ESP security associations is shown. This information includes the Security Parameter Index
(SPI), transform set, and IPSec mode.
L2TP over IPSec tunnel connectivity has been successfully established between the Windows
2000 client/LAC and the LNS. The issue is resolved.
Note that more information about the conguration and troubleshooting of IPSec can be found
in Chapter 8.
Additional L2TP Troubleshooting Commands
This section contains some additional commands that may be useful when troubleshooting
L2TP.
show vpdn history failure
The show vpdn history failure command is very useful for examining the VPDN failure
history table.
Example 4-140 shows the output of the show vpdn history failure command.
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xB6146600(3054790144)
transform: esp-des esp-sha-hmac ,
in use settings ={Transport, }
slot: 0, conn id: 2001, flow_id: 2, crypto map: l2tpcryptomap
sa timing: remaining key lifetime (k/sec): (99993/56)
IV size: 8 bytes
replay detection support: Y
outbound ah sas:
outbound pcp sas:
Skydance_LNS#
Example 4-140 show vpdn history failure Command Output
CalCity_LAC#show vpdn history failure
Table size: 20
Number of entries in table: 1
User: joebloggs@mjlnet.com, MID = 32
NAS: CalCity_LAC, IP address = 172.16.1.1, CLID = 0
Example 4-139 Verifying IPSec Security Associations (Continued)
CH01i.book Page 342 Friday, April 30, 2004 8:58 AM
Additional L2TP Troubleshooting Commands 343
Highlighted line 1 shows the history table size (20, the default), and in highlighted line 2, the
current size is shown (1). The username corresponding to the entry in the table is shown in
highlighted line 3. The LAC hostname and IP address are shown in highlighted line 4. In
highlighted line 5, the time the failure was last logged is shown, together with the number of
times this failure has occurred. Finally, in highlighted lines 6 and 7, a description of the failure,
as well as the associated Reason and Error codes (see Tables 4-4, 4-5, and 4-6) are shown.
Note that the size of the failure history table can be modied using the vpdn history failure
table-size command. Additionally, the table can be cleared using the clear vpdn history
failure command.
show vpdn session all
The show vpdn session all command displays detailed information about L2TP sessions.
Example 4-141 shows the output of the show vpdn session all command.
Highlighted line 1 shows the number of tunnels and sessions established. In highlighted line 2,
the Call (session) ID is displayed, together with its associated tunnel ID.
Gateway: Information is not applicable
Log time: Feb 11 22:01:39.962, Error repeat count: 7
Failure type: The remote server closed this session
Failure reason: Result 2, Error 6, Session limit
CalCity_LAC#
Example 4-141 show vpdn session all Command Output
CalCity_LAC#show vpdn session all
L2TP Session Information Total tunnels 1 sessions 1
Call id 18 is up on tunnel id 12471
Call serial number is 2364200016
Remote tunnel name is Skydance_LNS
Internet Address is 172.16.5.5
Session username is ltahoe@mjlnet.com, state is established
Time since change 00:01:21, interface As34
Remote call id is 18
Fastswitching is enabled
50 packets sent, 47 received
7118 bytes sent, 2672 received
Sequencing is off
%No active L2F tunnels
%No active PPTP tunnels
%No active PPPoE tunnels
CalCity_LAC#
Example 4-140 show vpdn history failure Command Output (Continued)
CH01i.book Page 343 Friday, April 30, 2004 8:58 AM
344 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
Next, the Call Serial Number is shown (highlighted line 3). The Call Serial Number is used to
identify the session, but unlike the Session ID, it is globally unique. Note that the Call Serial
Number is used for administrative purposes.
The remote tunnel name is shown in highlighted line 4. This corresponds to the L2TP peers
hostname. After the remote tunnel name is the IP address of the remote peer (highlighted line
5). Highlighted line 6 displays the username associated with this L2TP session. The session
state is also shown in this line. The time since the session state last changed, as well as the
interface with which the session is associated, is shown in highlighted line 7. Highlighted line
8 shows the remote Call (session) ID.
Highlighted line 9 shows whether fast switching is enabled for this session. If it is disabled,
there are a number of possible causes, the most likely of which are that either UDP checksums
have been enabled for L2TP packets (using the l2tp ip udp checksum command) or that L2TP
packets are being fragmented on the link between the LAC and LNS. To solve the rst problem,
simply disable UDP checksums using the no l2tp ip udp checksum command. It is worth
noting that Cisco routers do not have checksums enabled by default.
The second problem is caused when large packets are sent over the link between the LAC and
LNS. This issue is caused because the original (large) PPP frame plus the L2TP, UDP, and IP
headers exceeds the link MTU. See the section entitled Conguring the LNS earlier in this
chapter for more details on this.
The number of packets and bytes sent and received are shown in highlighted lines 10 and 11.
Highlighted line 12 shows whether or not sequencing has been enabled for this session. L2TP
sequencing can be enabled using the l2tp sequencing command.
debug vpdn error
The debug vpdn error command displays VPDN protocol errors.
Example 4-142 shows the output of the debug vpdn error command.
Example 4-142 debug vpdn error Command Output
CalCity_LAC#debug vpdn error
VPDN errors debugging is on
CalCity_LAC#
Feb 5 20:33:53.925 UTC: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected
to 1111
Feb 5 20:33:59.925 UTC: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected
to 1111
Feb 5 20:34:35.041 UTC: %LINK-3-UPDOWN: Interface Async36, changed state to up
Feb 5 20:34:40.397 UTC: VPDN/mjlnet.com: Authorization failed, could not
talk to AAA server or local tunnel problem
Feb 5 20:34:40.401 UTC: VPDN/dnis:7777: Authorization failed, could not talk to
AAA server or local tunnel problem
Feb 5 20:34:40.985 UTC: %ISDN-6-DISCONNECT: Interface Serial0/0:0 disconnected from
1111 , call lasted 47 seconds
CH01i.book Page 344 Friday, April 30, 2004 8:58 AM
Additional L2TP Troubleshooting Commands 345
Highlighted line 1 indicates that authorization for the tunnel has failed based on the domain
name (mjlnet.com). This error means that either connectivity to the AAA server has been lost
or there is no locally congured VPDN group that corresponds to this domain name.
Similarly, in highlighted line 2, authorization for the tunnel has failed based on the DNIS string
(7777). Again, this error means that connectivity to the AAA server has been lost or that the
DNIS does not correspond to any locally congured VPDN groups.
debug vpdn l2x-data
The debug vpdn l2x-data command shows L2TP data packets. Extra care should be taken
when using this command, as it can produce a large amount of output.
Example 4-143 shows the output of the debug vpdn l2x-data command.
Feb 5 20:34:44.105 UTC: %LINK-5-CHANGED: Interface Async36, changed state to reset
Feb 5 20:34:49.105 UTC: %LINK-3-UPDOWN: Interface Async36, changed state to down
Feb 5 20:35:48.937 UTC: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected
to 1111
Feb 5 20:35:52.577 UTC: %ISDN-6-CONNECT: Interface Serial0/0:0 is now connected
to 1111
Feb 5 20:35:52.577 UTC: %ISDN-6-DISCONNECT: Interface Serial0/0:0 disconnected from
1111 , call lasted 3 seconds
CalCity_LAC#
Example 4-143 debug vpdn l2x-data Command Output
CalCity_LAC#debug vpdn l2x-data
L2X data packets debugging is on
CalCity_LAC#
*Mar 1 01:20:29.811 UTC: As36 Tnl/Sn31626/5 L2TP: FS rcvd pkt from tunnel data,
flg L, ver 2, len 16, tnl 31626, cl 5
00 10 7B 79 C5 40 00 04 9B D6 0C 38 08 00 45 00
00 2C 04 16 00 00 FD 11 F4 80 AC 10 05 05 0A 14
0A 01 06 A5 06 A5 00 18 00 00 40 02 00 10 7B ...
*Mar 1 01:20:29.815 UTC: As36 Tnl/Sn31626/5 L2TP: FS rcvd pkt from tunnel data,
flg L, ver 2, len 22, tnl 31626, cl 5
00 10 7B 79 C5 40 00 04 9B D6 0C 38 08 00 45 00
00 32 04 17 00 00 FD 11 F4 79 AC 10 05 05 0A 14
0A 01 06 A5 06 A5 00 1E 00 00 40 02 00 16 7B ...
*Mar 1 01:20:29.927 UTC: As36 Tnl/Sn31626/5 L2TP: FS into tunnel,
src 172.16.1.1(1701), dst 172.16.5.5(1701), len 62
*Mar 1 01:20:29.931 UTC: As36 Tnl/Sn31626/5 L2TP: FS rcvd pkt from tunnel data,
flg L, ver 2, len 28, tnl 31626, cl 5
00 10 7B 79 C5 40 00 04 9B D6 0C 38 08 00 45 00
00 38 04 18 00 00 FD 11 F4 72 AC 10 05 05 0A 14
0A 01 06 A5 06 A5 00 24 00 00 40 02 00 1C 7B ...
Example 4-142 debug vpdn error Command Output (Continued)
CH01i.book Page 345 Friday, April 30, 2004 8:58 AM
346 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
Highlighted line 1 shows a L2TP data packet being received. Notice the Length (L) ag is set,
the Length is 16, and the Tunnel ID is 31626. Directly below this is the raw data contained
within the packet.
In highlighted line 2, a data packet is sent (fast switched) to into the tunnel. The source and
destination IP addresses and UDP ports are also shown.
debug vpdn l2x packets
The debug vpdn l2x-packets command displays L2TP control packets. Again, extra care
should be taken when using this command, as it can produce large amounts of output.
Example 4-144 shows the output of the debug vpdn l2x-packets command.
Example 4-144 debug vpdn l2x-packets Command Output
CalCity_LAC#debug vpdn l2x-packets
L2X control packets debugging is on
CalCity_LAC#
*Mar 1 01:23:34.475 UTC: Tnl63051 L2TP: O SCCRQ
*Mar 1 01:23:34.475 UTC: Tnl63051 L2TP: O SCCRQ, flg TLS, ver 2, len 136, tnl 0,
cl 0, ns 0, nr 0
C8 02 00 88 00 00 00 00 00 00 00 00 80 08 00 00
00 00 00 01 80 08 00 00 00 02 01 00 80 0A 00 00
00 03 00 00 00 00 80 0A 00 00 00 04 00 00 00 ...
*Mar 1 01:23:34.483 UTC: Tnl63051 L2TP: Parse AVP 0, len 8, flag 0x8000 (M)
*Mar 1 01:23:34.483 UTC: Tnl63051 L2TP: Parse SCCRP
*Mar 1 01:23:34.483 UTC: Tnl63051 L2TP: Parse AVP 2, len 8, flag 0x8000 (M)
*Mar 1 01:23:34.483 UTC: Tnl63051 L2TP: Protocol Ver 256
*Mar 1 01:23:34.483 UTC: Tnl63051 L2TP: Parse AVP 3, len 10, flag 0x8000 (M)
*Mar 1 01:23:34.483 UTC: Tnl63051 L2TP: Framing Cap 0x0
*Mar 1 01:23:34.483 UTC: Tnl63051 L2TP: Parse AVP 4, len 10, flag 0x8000 (M)
*Mar 1 01:23:34.483 UTC: Tnl63051 L2TP: Bearer Cap 0x0
*Mar 1 01:23:34.483 UTC: Tnl63051 L2TP: Parse AVP 6, len 8, flag 0x0
*Mar 1 01:23:34.483 UTC: Tnl63051 L2TP: Firmware
CalCity_LAC# Ver 0x1120
*Mar 1 01:23:34.487 UTC: Tnl63051 L2TP: Parse AVP 7, len 18, flag 0x8000 (M)
*Mar 1 01:23:34.487 UTC: Tnl63051 L2TP: Hostname Skydance_LNS
*Mar 1 01:23:34.487 UTC: Tnl63051 L2TP: Parse AVP 8, len 25, flag 0x0
*Mar 1 01:23:34.487 UTC: Tnl63051 L2TP: Vendor Name Cisco Systems, Inc.
*Mar 1 01:23:34.487 UTC: Tnl63051 L2TP: Parse AVP 9, len 8, flag 0x8000 (M)
*Mar 1 01:23:34.487 UTC: Tnl63051 L2TP: Assigned Tunnel ID 8409
*Mar 1 01:23:34.487 UTC: Tnl63051 L2TP: Parse AVP 10, len 8, flag 0x8000 (M)
*Mar 1 01:23:34.491 UTC: Tnl63051 L2TP: Rx Window Size 10000
*Mar 1 01:23:34.491 UTC: Tnl63051 L2TP: Parse AVP 11, len 22, flag 0x8000 (M)
*Mar 1 01:23:34.491 UTC: Tnl63051 L2TP: Chlng
88 CF E6 16 6C B5 90 BB EC 6B BC 6B DB 82 23 DF
*Mar 1 01:23:34.491 UTC: Tnl63051 L2TP: Parse AVP 13, len 22, flag 0x8000 (M)
*Mar 1 01:23:34.491 UTC: Tnl63051 L2TP: Chlng Resp
F2 3E E7 94 F3 30 C2 FE 20 70 BC 29 5C 4D 0E A4
*Mar 1 01:23:34.495 UTC: Tnl63051 L2TP: No missing AVPs in SCCRP
*Mar 1 01:23:34.495 UTC: Tnl63051 L2TP: I SCCRP, flg TLS, ver 2, len 159,
CH01i.book Page 346 Friday, April 30, 2004 8:58 AM
Additional L2TP Troubleshooting Commands 347
Highlighted line 1 shows the packet header of an outgoing SCCRQ. The Type (T), Length (L),
and Sequencing (S) bits are set to 1 in the L2TP header. These bit settings indicate that this is
a control packet, and that the Length and Sequencing (Nr/Ns) elds are present. The version is
shown as 2 (L2TPv2), the Length is 136, the tunnel and session IDs are both 0, and the Ns and
Nr elds are also both set to 0.
In highlighted line 12, a SCCRP is received. Again, the packet header is shown. More
interestingly, however, are the AVPs that are contained within the SCCRP message. These are
shown in highlighted lines 2 to 11. See Table 4-2 and 4-7 at the beginning of this chapter for
more details on these AVPs.
AVP type numbers, together with the Length and ags set in the AVP headers are shown. Note
that each AVP is marked as mandatory (M). Finally, in highlighted line 13, an outgoing SCCCN
is shown.
debug vpdn packet
The debug vpdn packet command displays VPDN packets.
Example 4-145 shows the output of the debug vpdn packet command.
tnl 63051, cl 0, ns 0, nr 1
C8 02 00 9F F6 4B 00 00 00 00 00 01 80 08 00 00
00 00 00 02 80 08 00 00 00 02 01 00 80 0A 00 00
00 03 00 00 00 00 80 0A 00 00 00 04 00 00 00 ...
*Mar 1 01:23:34.495 UTC: Tnl63051 L2TP: I SCCRP from Skydance_LNS
*Mar 1 01:23:34.495 UTC: Tnl63051 L2TP: O SCCCN to Skydance_LNS tnlid 8409
*Mar 1 01:23:34.495 UTC: Tnl63051 L2TP: O SCCCN, flg TLS, ver 2, len 42, tnl 8409,
cl 0, ns 0, nr 1
C8 02 00 2A 20 D9 00 00 00 00 00 01 80 08 00 00
00 00 00 03 80 16 00 00 00 0D 6F 12 DE 59 3A 61
07 60 9A 08 47 1C C2 80 B5 63
Example 4-145 debug vpdn packet Command Output
CalCity_LAC#debug vpdn packet
VPDN packet debugging is on
CalCity_LAC#
*Mar 1 01:25:58.307 UTC: As38 Tnl/Sn28940/7 L2TP: I FS OUT from LAC
*Mar 1 01:25:58.307 UTC: As38 Tnl/Sn28940/7 L2TP: I FS OUT from LAC
*Mar 1 01:25:58.415 UTC: As38 Tnl/Sn28940/7 L2TP: FS into tnl successful, len 62
*Mar 1 01:25:58.415 UTC: As38 Tnl/Sn28940/7 L2TP: I FS OUT from LAC
*Mar 1 01:25:58.431 UTC: As38 Tnl/Sn28940/7 L2TP: FS into tnl successful, len 92
*Mar 1 01:25:58.435 UTC: As38 Tnl/Sn28940/7 L2TP: I FS OUT from LAC
*Mar 1 01:25:58.435 UTC: As38 Tnl/Sn28940/7 L2TP: FS into tnl successful, len 62
*Mar 1 01:25:58.547 UTC: As38 Tnl/Sn28940/7 L2TP: FS into tnl successful, len 74
*Mar 1 01:25:58.547 UTC: As38 Tnl/Sn28940/7 L2TP: I FS OUT from LAC
CalCity_LAC#
Example 4-144 debug vpdn l2x-packets Command Output (Continued)
CH01i.book Page 347 Friday, April 30, 2004 8:58 AM
348 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
Highlighted lines 1, 2, and 3 show L2TP packets being fast switched out of and into the L2TP
tunnel.
clear vpdn tunnel
The clear vpdn tunnel command can be used to manually tear down L2TP tunnels.
Example 4-146 shows a L2TP tunnel with remote name Skydance_LNS and local name
CalCity_LAC being torn down.
Error Messages
This section explains L2TP error messages and associated solutions. Note that these error
messages are visible only if VPDN logging is enabled.
Example 4-147 shows how to enable VPDN logging.
Note that VPDN logging is enabled by default.
%VPDN-6-AUTHENERR
This error can be seen on either the LAC or the LNS when using remote AAA to authenticate
either an L2TP tunnel or remote access client (user). It indicates that the AAA server is
unreachable.
To resolve this issue, ensure that the address of the AAA server is correctly congured on the
LAC/LNS. Also, ensure reachability from the LAC/LNS to the AAA server.
%VPDN-6-AUTHENFAIL
This error can be seen on either the LAC or the LNS and indicates that authentication for the
remote access client (user) or tunnel has failed.
Example 4-146 clear vpdn tunnel Command Output
CalCity_LAC#clear vpdn tunnel l2tp Skydance_LNS CalCity_LAC
Clearing all sessions and dropping the tunnel
CalCity_LAC#
Example 4-147 Enabling VPDN Logging
CalCity_LAC#conf t
Enter configuration commands, one per line. End with CNTL/Z.
CalCity_LAC(config)#vpdn logging
CalCity_LAC(config)#exit
CalCity_LAC#
CH01i.book Page 348 Friday, April 30, 2004 8:58 AM
Error Messages 349
If local authentication is congured for the remote access client, check the username/password
database to ensure that both username and password are correctly congured. If remote AAA
is being used, check that the username and password are correctly congured on the AAA
server. Finally, ensure that username and password are correctly congured on the remote
access client.
In the case of tunnel authentication failure, ensure that the tunnel password is correctly
congured either locally on the LAC/LNS (vpdn group group_name..l2tp tunnel password
password) or on the AAA server with the tunnel denition.
%VPDN-6-AUTHORERR
This indicates that an error has resulted on the LAC/LNS when authorizing either a L2TP tunnel
or a remote access client (user). This is caused when the AAA server is unreachable.
Again, resolve this issue by examining the conguration of the LAC/LNS (ensure that the IP
address/UDP port of the AAA server is correctly congured). Also, ensure that there is
reachability from the LAC/LNS to the AAA server.
%VPDN-6-AUTHORFAIL
This error message indicates that authorization for the remote access client (user) or L2TP
tunnel has failed.
Ensure that authorization is correctly congured on the LAC/LNS (aaa authorization), and
make sure that attributes are correctly congured on the AAA server.
%VPDN-6-CLOSED
This error indicates that an L2TP session has been disconnected by the LNS. The Result/Error
codes contained within the CDN specify the cause.
Tables 4-5 and 4-6 detail L2TP result and error codes contained within CDN messages.
%VPDN-6-MAX_SESS_EXCD
This error message indicates that the maximum number of sessions in a L2TP tunnel has been
exceeded. This session maximum is congurable via the vpdn session-limit command. To
resolve this error, either remove the session limit or adjust it upward.
CH01i.book Page 349 Friday, April 30, 2004 8:58 AM
350 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
%VPDN-4-MIDERROR
This is a generic error that indicates that there is a conguration or resource issue on the LNS.
Check the LNS to ensure correct conguration.
%VPDN-5-NOIDB
The NOIDB error can be seen on the LNS when it runs out of Interface Descriptor Blocks
(IDBs) to terminate sessions. The IDB is a data structure associated with each physical or
logical interface.
Use the show idb command to verify the maximum number of available IDBs, together with
IDBs in use. The maximum number of IDBs available depends on the hardware platform and
Cisco IOS version. In Cisco IOS 12.2, for 2500 series access servers, there are 300 IDBs; for
3620s and 3640s, 800 IDBs; for AS5300s, 800 IDBs; and for AS5800s, there are 2048 IDBs.
To resolve this issue, you should contact the Cisco Technical Assistance Center (TAC).
%VPDN-3-NORESOURCE
This error indicates that the LAC/LNS is out of resources needed to either forward or terminate
a session or tunnel. Contact Cisco TAC to resolve this issue.
%VPDN-4-REFUSED
This error shows that the LNS has refused to terminate a session. Examine the LNSs
conguration to ensure that it is correct.
%VPDN-6-SOFTSHUT
If you see this message, it indicates that VPDN softshut has been congured on the LAC/LNS.
VPDN softshut allows graceful L2TP session/tunnel shutdown, by not allowing the
establishment of new sessions, while at the same time allowing the existing session to terminate
naturally.
To resolve this issue, use the no vpdn softshut command to disable VPDN softshut.
%VPDN-6-TIMEOUT
You will see this error if a session within the L2TP tunnel has timed out. This can be because
of either PPP negotiation failure or the expiration of the timer for the session. This absolute
timeout is used to close user sessions if there is no user activity.
To resolve this issue, ensure that PPP negotiation for the remote access client (user) succeeds.
CH01i.book Page 350 Friday, April 30, 2004 8:58 AM
show and debug Command Summary 351
%VPDN-5-UNREACH
You can see this error on the LAC/LNS if it fails to establish connectivity to the LNS/LAC.
Ensure that the IP address of the LNS is correctly congured on the LAC with the initiate-to
ip command within the VPDN group. If tunnel denitions are stored on the RADIUS server,
ensure that the IP address is correctly congured within the tunnel denition.
Also, ensure that there is IP connectivity between the LAC and the LNS.
%VPDN-6-DOWN
This error indicates that an L2TP tunnel has been shut down by either the LAC or the LNS.
The cause of the tunnel shutdown is indicated by the Result code contained within the StopCCN
used by the LAC/LNS to initiate tunnel shutdown.
See Table 4-4 for possible result codes contained within StopCCN messages.
show and debug Command Summary
Table 4-12 summarizes show and debug commands used to troubleshoot L2TP in this chapter.
Table 4-12 show and debug Commands Used to Troubleshoot L2TP
Command Parameter Description
show caller username Displays a summary of information about the user
show user Displays a list of users
show vpdn tunnel all Displays detailed L2TP tunnel information
session Displays L2TP session summary
session all Displays detailed L2TP session information
history failure Displays L2TP session/tunnel failure information
debug vpdn error Displays L2TP error conditions
event Displays L2TP events
packet Displays L2TP packets
debug vpdn l2x- data displays L2TP data packets
errors Displays detailed L2TP error information
events Displays detailed L2TP tunnel/session information
packets Displays L2TP control packets
debug aaa authentication Displays AAA authentication information
authorization Displays AAA authorization information
debug radius Displays RADIUS information
clear vpdn tunnel l2tp Shuts down the specied L2TP tunnel
CH01i.book Page 351 Friday, April 30, 2004 8:58 AM
352 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
Review Questions
1 What is the purpose of the Start-Control-Connection-Request (SCCRQ) message?
2 Assuming that the L2TP tunnel has already been established, what is the sequence of
messages between the LAC and the LNS that is used to set up the data session for an
incoming call?
3 When the LNS wishes to establish an outgoing call to a remote access client, what is the
sequence of messages sent between the LNS and LAC during call setup? Assume that the
control connection is already established.
4 During session setup, the LNS wishes to signal the LAC that there are insufcient resources
and that the session should be disconnected. Which message is used to signal this?
5 How can the number of L2TP sessions be limited?
6 How are remote access client PPP connections associated with a particular L2TP tunnel
by the LAC?
7 Should the network administrator not wish to store tunnel conguration on the LAC, what
is an alternative?
8 What is the signicance of the tunnel ID in the tunnel denitions on an AAA server?
9 You suspect that the remote access clients password is incorrectly congured, and this is
causing L2TP session establishment failure. Where and with what command which you
troubleshoot this issue? Assume local authentication is being used.
10 When troubleshooting L2TP session setup failure on the LNS using the debug ppp
negotiation command, the following message is observed:
Feb 6 01:39:13.473 UTC: Vi1 LCP: O PROTREJ [Open] id 2 len 46 protocol IPCP
What does this message most likely indicate? Assume that local authentication is being
used.
L2TP Troubleshooting Practice Labs
This section provides some troubleshooting labs to help you to consolidate troubleshooting
skills that you have learned in this chapter.
The troubleshooting labs described are based upon the network topology shown in Figure 4-39.
The goal of each lab is to restore connectivity from a remote access client
(joebloggs@mjlnet.com) to Skydance_LNS. Base congurations for the labs can be found on
the Cisco Press Web site (www.ciscopress.com/1587051044). Detailed instructions for loading
these base congurations onto your lab routers can be found in Appendix B.
CH01i.book Page 352 Friday, April 30, 2004 8:58 AM
L2TP Troubleshooting Practice Labs 353
Figure 4-39 L2TPv2 Lab Topology
L2TP Troubleshooting Lab 1
In this scenario, remote client joebloggs@mjlnet.com reports that he is able to dial into
CalCity_LAC, but that the connection is quickly dropped.
Troubleshoot this issue end-to-end and record the symptoms, actions, and resolution in the
space provided below:
Symptoms:
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
Actions:
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
Resolution:
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
CalCity_LAC
ISDN
Skydance_LNS
Intermediate1
Lo0:
192.168.1.1/24
joebloggs@
mjlnet.com
BRI 0/0 BRI 0/0
(Number: 2222)
S 0/0 S 0/0 S 0/1 S 0/0 E 0/0
.1
.2
.1
.1 .2
10.10.10.0/24
172.16.2.0/24 172.16.1.0/24
Lo0:
10.20.10.1/24
CH01i.book Page 353 Friday, April 30, 2004 8:58 AM
354 Chapter 4: Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
L2TP Troubleshooting Lab 2
In this scenario, the remote client joebloggs@mjlnet.com is able to connect to the LAC, but
shortly thereafter, the connection drops.
Troubleshoot this issue end-to-end and record the symptoms, actions, and resolution in the
space provided below:
Symptoms:
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
Actions:
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
Resolution:
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
L2TP Troubleshooting Lab 3
In this scenario, tunnel and session negotiation begins, but the connection from
joebloggs@mljnet.com is dropped shortly thereafter.
Troubleshoot this issue end-to-end, and record the symptoms, actions, and resolution in the
space provided below:
Symptoms:
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
CH01i.book Page 354 Friday, April 30, 2004 8:58 AM
L2TP Troubleshooting Practice Labs 355
Actions:
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
Resolution:
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
__________________________________________________________________________
Note that all the solutions for the L2TP troubleshooting labs are detailed in Appendix B.
CH01i.book Page 355 Friday, April 30, 2004 8:58 AM
CH01i.book Page 356 Friday, April 30, 2004 8:58 AM
C H A P T E R
5
Troubleshooting L2TPv3
Based VPNs
The Layer Two Tunneling Protocol Version 3 (L2TPv3) is described in Internet Draft draft-
ietf-l2tpext-l2tp-base. L2TPv3 provides a mechanism for tunneling Layer 2 frames such as
PPP, HDLC, Frame Relay, and Ethernet over a packet-switched network. This is a key
enhancement over L2TPv2 (as described in RFC 2661), which allows only the tunneling of
PPP frames.
Internet Draft draft-ietf-l2tpext-l2tp-base discusses three L2TPv3 tunneling models:
An L2TP Access Concentrator (LAC) to L2TP Network Server (LNS) tunneling
model
An LNS to LNS tunneling model
A LAC to LAC tunneling model
The LAC to LNS tunneling model (also described in RFC 2661) allows the tunneling of
frames from a remote access client or system via a LAC to an LNS. Figure 5-1 illustrates
this tunneling model.
Figure 5-1 LAC to LNS Tunneling Model
The LNS to LNS tunneling model allows the tunneling of frames over a packet switched
network, with termination of the connection on the LNSs themselves.
Figure 5-2 illustrates the LNS to LNS tunneling model implemented over an IP backbone.
Remote Access
Client
LAC
LNS
Corporate
Network
Service Provider
Backbone
L2TP Layer 2 Layer 2
CH01i.book Page 357 Friday, April 30, 2004 8:58 AM
358 Chapter 5: Troubleshooting L2TPv3 Based VPNs
Figure 5-2 LNS to LNS Tunneling Model
In the LAC to LAC tunneling model, the LAC acts as cross connect forwarding frames received
on an attachment circuit from a remote system over a packet switched network to a remote
LAC.
The LAC to LAC tunneling model implemented over an IP backbone is shown in Figure 5-3.
Figure 5-3 LAC to LAC Tunneling Model
The most common application of the LAC to LAC tunneling model is to provide pseudowire
connections over a service provider backbone. These pseudowires can be used to build Layer
2 VPNs.
Note that a pseudowire is an emulated Layer 2 circuit that crosses a packet switched network.
In this environment, the LACs can also be provider edge (PE) routers. Remote systems can be
customer edge (CE) devices, such as routers.
Technical Overview of L2TPv3
This section contains a brief overview of the L2TPv3. As noted in the introduction, there are
three different L2TPv3 tunneling models: LAC to LNS, LNS to LNS, and LAC to LAC. This
chapter discusses L2TPv3 deployed using the LAC to LAC pseudowire conguration.
L2TP can operate directly over several packet switched network types, including IP, MPLS,
Frame Relay, and ATM. This chapter focuses on operation over an IP backbone network.
LNS
Home
Network
LNS
Home
Network
IP Backbone
L2TP Layer 2 Layer 2
L2TP Layer 2 Layer 2
Remote
System LAC LAC
Remote
System
IP Backbone
Attachment
Circuit
Attachment
Circuit
CH01i.book Page 358 Friday, April 30, 2004 8:58 AM
Technical Overview of L2TPv3 359
Internet Draft draft-ietf-l2tpext-l2tp-base discusses two methods of transporting L2TPv3 over
an IP network:
L2TPv3 directly over IP (using IP Protocol ID 115)
L2TPv3 over UDP (using destination port 1701)
Ciscos current LAC to LAC implementation supports L2TPv3 over IP, so this method of
transport is assumed in this chapter. Note that L2TPv3 over IP has less overhead, but L2TPv3
over UDP can be useful in environments where an L2TP tunnel has to traverse a Network
Address Translation (NAT) device or rewall.
L2TPv3 Message Types
There are two different types of L2TPv3 message:
Control messages are used to establish, maintain, and tear down L2TPv3 control channels
and data sessions. Control messages are reliably transmitted in-band between peer LACs.
One or more control channels can be established between the two L2TPv3
control connection endpoints (LCCEs), which in this case are the peer LACs.
Session data messages are used to transport Layer 2 frames between the peer LACs. Each
Layer 2 connection is carried over a separate data session.
L2TPv3 Control Messages
As previously mentioned, control messages are used for the establishment, maintenance, and
teardown of L2TPv3 control connections and data sessions.
A control connection is not essential to the operation of data sessions between peer LACs.
However, unless otherwise stated, this chapter assumes the existence of a control connection.
Figure 5-4 illustrates the overall packet format of L2TPv3 control messages.
Figure 5-4 L2TPv3 Control Message Packet Format
Control Message (AVPs)
L2TPv3 Control Message
Header
IP Header
(Protocol ID 115)
CH01i.book Page 359 Friday, April 30, 2004 8:58 AM
360 Chapter 5: Troubleshooting L2TPv3 Based VPNs
Note that there is one control message that consists of only the IP and control message headers.
This is called the Zero-Length-Body Acknowledgment (ZLB Ack) and is used to acknowledge
explicitly other control message types. The ZLB Ack is used in the absence of another control
messages that provide implicit acknowledgment. The ZLB Ack can be used only if
authentication is disabled. In cases where authentication is enabled, an Explicit
Acknowledgment message is used instead.
Figure 5-5 shows the format of the L2TPv3 control message.
Figure 5-5 L2TPv3 Control Message Header (over IP)
The rst thing you will notice if you have read Chapter 4, Troubleshooting Layer 2 Tunneling
Protocol Version 2 VPNs, is that the header looks pretty similar (see Figure 4-5 in Chapter 4).
One or two differences do exist, however. The bulleted list that follows discusses the bits and
elds in the L2TPv3 control message:
The rst part of the header is 32 bits, all set to zero. These 32 bits allow an LAC receiving
a control message to distinguish it from a data message (these 32 bits are actually the
reserved session ID of zero).
After the initial 32 bits are the L2TP ags. The rst of these is the T bit. The T bit must be
set to 1, and it is used when L2TPv3 is transported over UDP to indicate that this is a
control message. When L2TPv3 is transported over IP, this function is performed by the
initial 32 bits, so the T bit is somewhat redundant.
The L bit must be set to 1 and indicates that the Length eld is present.
The following two bits shown as x (and, in fact, all bits shown as x) are reserved and must
be set to zero.
The S bit must be set to 1, and it indicates that the Ns (Next sent) and Nr (Next received)
elds are present.
NOTE Before moving on, note the absence of the O (Offset) and P (Priority) bits, when compared to
L2TPv2. The absence of the O bit, of course, also means that the Offset and Offset pad elds
are no longer present.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
T L x x S x x x x x x x Length Ver
Control Connection ID
(32 bits of zeros)
Nr Ns
0 1 2 3
CH01i.book Page 360 Friday, April 30, 2004 8:58 AM
Technical Overview of L2TPv3 361
The Ver (version) eld is 4 bits long and must be set to 3 to indicate that this is an L2TPv3
control message.
The Length eld is 16 bits long and indicates the total length for the message in octets
starting from the T bit.
Next is the 32-bit Control Connection ID eld. Again, if you are familiar with L2TPv2,
you will notice that this eld has replaced the Tunnel ID eld. The Control Connection ID
is locally signicant only. It is possible, therefore, for the same control connection to have
different IDs on either peer LAC.
Note that the local Control Connection ID is passed by the LAC to its peer in the
Assigned Control Connection ID Attribute-Value-Pair (AVP) during control
connection setup.
Figure 5-6 illustrates Control Connection IDs.
Figure 5-6 Control Connection IDs
In Figure 5-6, the L2TPv3 control connection between Stockholm_LCCE and
London_LCCE is identied by Control Connection ID 1002 on
Stockholm_LCCE and by Control Connection ID 2002 on London_LCCE.
The control connection between Frankfurt_LCCE and London_LCCE is
identied by Control Connection ID 3001 on Frankfurt_LCCE and by Control
Connection ID 2001 on London_LCCE.
The Ns (Next sent) eld is 16 bits long and indicates the sequence number for this control
message.
The Nr (Next received) eld is again 16 bits long and indicates the sequence number of
the next message expected from the peer LAC.
Following the control message header is the control message itself.
London_LCCE
Stockholm_LCCE
Frankfurt_LCCE
Control Connection
ID = 1002
Control Connection
ID = 3001
Control Connection
ID = 2002
Control Connection
ID = 2001
CH01i.book Page 361 Friday, April 30, 2004 8:58 AM
362 Chapter 5: Troubleshooting L2TPv3 Based VPNs
Control Message Types
Table 5-1 lists the 14 different types of control messages as dened by L2TPv3.
Note that the OCRQ, OCRP, and OCCN messages are not used in the LAC to LAC model and
are, therefore, not discussed further in this chapter. Also, the Explicit Acknowledgment
message type value is yet to be announced at the time of this writing.
The composition and function of each of the other message types listed in Table 5-1 are
discussed in the following few sections.
AVPs
Control messages are made up of a number of AVPs. AVPs are used to describe a particular
variable (the attribute) and its associated value. These AVPs allow great protocol extensibility.
Table 5-1 L2TPv3 Control Message Types
Message Type Description Function
0 (reserved) (none)
1 Start-Control-Connection-Request (SCCRQ) Control channel setup
2 Start-Control-Connection-Reply (SCCRP) Control channel setup
3 Start-Control-Connection-Connected (SCCCN) Control channel setup
4 Stop-Control-Connection-Notication (StopCCN) Control channel teardown
5 (reserved) (none)
6 Hello (HELLO) Control channel maintenance
7 Outgoing-Call-Request (OCRQ) Outgoing call (session) setup
8 Outgoing-Call-Reply (OCRP) Outgoing call (session) setup
9 Outgoing-Call-Connected (OCCN) Outgoing call (session) setup
10 Incoming-Call-Request (ICRQ) Incoming call (session) setup
11 Incoming-Call-Reply (ICRP) Incoming call (session) setup
12 Incoming-Call-Connected (ICCN) Incoming call (session) setup
13 (reserved) (none)
14 Call-Disconnect-Notify (CDN) Call (session) teardown
15 WAN-Error-Notify (WEN) Call status
16 Set-Link-Info (SLI) Call status
TBA-M1
(to be
announced)
Explicit Acknowledgment Explicitly acknowledges
receipt of control messages
CH01i.book Page 362 Friday, April 30, 2004 8:58 AM
Technical Overview of L2TPv3 363
AVPs have a common encoding format, which is shown in Figure 5-7. Note that this encoding
format is carried over from L2TPv2.
Figure 5-7 AVP Encoding Format
The bits and elds in the AVP encoding format are dened as follows:
The M (mandatory) bit should be checked if the AVP is unrecognized or malformed. If the
LCCE receives an unrecognized or malformed AVP with the M bit set, it tears down the
session or control connection (together with all associated sessions) associated with the
message that contains this AVP. If, on the other hand, the LCCE receives an unrecognized
or malformed AVP without the M bit set, the AVP is ignored.
The H (hidden) bit, if set to 1, indicates that the value or data in the AVP is hidden. The
hiding of data in AVPs can be used to pass sensitive data such as passwords.
The method of hiding data in AVPs is the same as that used by L2TPv2. For more
details, see section 5.3 of draft-ietf-l2tpext-l2tp-base (L2TPv3).
Note that AVP hiding makes use of the shared password congured on peer
LCCEs.
Four reserved bits (RSVD) follow the H bit. These must be set to zero.
The 10-bit Length eld indicates the overall length of the AVP in octets. The minimum
length is 6 (indicating that the value eld is absent), and the maximum length is 1023.
The 16-bit Vendor-ID eld allows vendors to implement proprietary AVPs. Vendor-ID
values correspond to the SMI Network Management Private Enterprise Codes (RFC
1700). The value of zero indicates that the AVP is an Internet Engineering Task Force
(IETF) dened AVP.
The 16-bit Attribute Type eld species the type of AVP.
The variable-length Attribute Value eld species the associated value.
Internet Draft draft-ietf-l2tpext-l2tp-base (L2TPv3) denes a number of different AVPs. These
fall into ve categories:
General control message AVPs
The result code AVP
Control connection management AVPs
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Vendor ID Length rsvd M H
Attribute Value ... Attribute Type
(Until Length is Reached)
0 1 2 3
CH01i.book Page 363 Friday, April 30, 2004 8:58 AM
364 Chapter 5: Troubleshooting L2TPv3 Based VPNs
Session management AVPs
Circuit status AVPs
The sections that follow cover these AVPs in more detail.
General Control Message AVPs The four general control message AVPs are Message
Type, Message Digest, Control Message Authentication Nonce, and Random Vector.
Table 5-2 summarizes general control message AVPs.
The Message Type, Message Digest, and Control Message Authentication Nonce AVPs are of
particular signicance. The Message Type AVP is used to dene the control message type
(described in Table 5-1) itself. The Message Digest and Control Message Authentication Nonce
AVPs are both used for L2TPv3 message authentication. The Message Digest AVP additionally
provides an integrity check over the whole control message. Note that the attribute type values
for these two AVPs are yet to be announced at the time of this writing.
L2TPv3 message authentication is described later in this chapter in the section entitled Control
Connection Establishment.
Result Code AVP The Result Code AVP is functionally in its own category. This AVP is
contained in the Call-Disconnect-Notify (CDN) and Stop-Control-Connection-Notication
(StopCCN) messages. It is used to describe the reason for session or control channel teardown.
The Result Code AVP contains the result code itself, together with an optional Error Code and
Error Message. These collectively describe the reason for session or control connection teardown.
Table 5-3 describes the Result Code AVP.
Table 5-2 General Control Message AVPs
Attribute Type Attribute Name Description Present In
0 Message Type Denes the message type All messages
TBA Message Digest Provides integrity check and
authentication of control
messages
All messages (if
authentication is
enabled)
TBA Control Message
Authentication Nonce
Cryptographically random value
used for Control Connection
message authentication.
SCCRQ, SCCRP
(if authentication is
enabled)
36 Random Vector Contains a cryptographically
random number used with AVP
hiding
ICRQ, ICRP,
ICCN, CDN,
StopCCN, SLI
Table 5-3 Result Code AVP
Attribute Type Attribute Name Description Present In
1 Result Code Indicates the reason for session or
control channel teardown
CDN, StopCCN
CH01i.book Page 364 Friday, April 30, 2004 8:58 AM
Technical Overview of L2TPv3 365
When included with a StopCCN message, the result code values are as shown in Table 5-4.
When included with a CDN message, the result code values are as shown in Table 5-5.
Note result codes values TBA1-4. These are result code values that are yet to be announced (at
the time of this writing). A Result Code AVP can also optionally include Error Code and Error
Message elds. If the Error Code eld is included, the Error Code values are those shown in
Table 5-6.
Table 5-4 Result Code Values (StopCCN)
Result Code Description
0 (reserved)
1 General request to clear control connection
2 General error (Error code indicates problemsee Table 5-6)
3 Control connection already exists
4 Requestor is not authorized to establish control channel
5 Protocol version of peer is not supported
6 LCCE is being shut down
7 Finite state machine error or timeout
Table 5-5 Result Code Values (CDN)
Result Code Description
0 (reserved)
1 Session disconnected because of loss of carrier or circuit disconnect
2 Session disconnected for the reason specied in Error Code
3 Session disconnected for administrative reasons
4 Session establishment failed because of lack of appropriate facilities being available
(temporary condition)
5 Session establishment failed because of lack of appropriate facilities being available
(permanent condition)
6 to 11 Reserved (PPP-specic codes)
TBA1 Session not established because of losing tie breaker
TBA2 Session not established because of unsupported pseudowire type
TBA3 Session not established, sequencing required without valid L2-specic sublayer
TBA4 Finite state machine error or timeout
CH01i.book Page 365 Friday, April 30, 2004 8:58 AM
366 Chapter 5: Troubleshooting L2TPv3 Based VPNs
Finally, the optional Error Message eld in the Result Code AVP contains human-readable text
describing the error condition.
The mechanics of session and control connection teardown are discussed in the sections entitled
Session Teardown and Control Connection Teardown later in this chapter.
Control Connection Management AVPs Control connection management AVPs are
carried in messages used to establish and tear down control connections between LCCEs.
Table 5-7 shows control connection management AVPs.
Table 5-6 Error Code Values
Result Code Description
0 No general error
1 No control connection exists yet for this pair of LCCEs
2 Length is wrong
3 One of the eld values was out of range
4 Insufcient resources to handle this operation now
5 Invalid Session ID
6 A generic vendor-specic error occurred
7 Try another LCCE
8 The session or control connection was shut down due to receipt of an unknown AVP
with the M bit set
9 Try another directed (Error Message must contain a list of addresses of other LCCEs
to try)
Table 5-7 Control Connection Management AVPs
Attribute Type Attribute Name Description Present In
5 Control Connection
Tie Breaker
Used to ensure that only one control
channel is established between peer
LCCEs
SCCRQ
7 Host Name Name of the LAC or LNS SCCRQ / SCCRP
TBA Router ID Identies an LCCE SCCRQ / SCCRP
8 Vendor Name String describing type of LAC or
LNS
SCCRQ / SCCRP
TBA Assigned Control
Connection ID
Used to communicate locally
assigned control connection ID to
peer
SCCRQ / SCCRP
/ StopCCN
CH01i.book Page 366 Friday, April 30, 2004 8:58 AM
Technical Overview of L2TPv3 367
Note that some attribute type values (marked TBA) are yet to be announced at the time of
writing.
Of particular note is the Pseudowire Capabilities List AVP. This is used to inform the remote
LCCE about which pseudowire types are supported by the local LCCE.
Session Management AVPs Call management AVPs are carried in messages used for
session establishment and teardown between peer LCCEs.
Table 5-8 summarizes session management AVPs.
10 Receive Window
Size
Receive window size offered to the
remote LCCE (used for ow
control)
SCCRQ / SCCRP
TBA Pseudowire
Capabilities List
Used to indicate Layer 2 payload
types supported by the sender
SCCRQ / SCCRP
TBA Preferred Language Indicates language in which
human-readable messages should
be composed
SCCRQ / SCCRP
Table 5-8 Session Management AVPs
Attribute Type Attribute Name Description Present In
TBA Local Session ID Used to communicate the locally
assigned session ID to the peer LCCE
ICRQ / ICRP /
ICCN / CDN /
WEN / SLI
TBA Remote Session ID Indicates the session ID assigned by
the peer LCCE
ICRQ / ICRP /
ICCN / CDN /
WEN / SLI
TBA Assigned Cookie Used to communicate locally
assigned cookie value to peer LCCE
ICRQ / ICRP
15 Serial Number Identies a session; used for
administrative purposes
ICRQ
TBA Remote End ID Used to associate a session with a
circuit, interface, or bridging
instance
ICRQ
TBA Application ID Used to identify application types
for a session
ICRQ
TBA Session Tie Breaker Used to ensure that only one
session is established for a given
circuit
ICRQ
continues
Table 5-7 Control Connection Management AVPs (Continued)
Attribute Type Attribute Name Description Present In
CH01i.book Page 367 Friday, April 30, 2004 8:58 AM
368 Chapter 5: Troubleshooting L2TPv3 Based VPNs
Note that the Remote End ID AVP is used to carry the Virtual Circuit ID (VCID) value, which
is discussed in the following sections.
Also note the Data Sequencing AVP. This is used if sequencing is enabled for data sessions.
Circuit Status AVPs The nal category is circuit status AVPs. These are carried in messages
to communicate attachment circuit active/inactive (up/down) or attachment circuit error
information.
Table 5-9 summarizes call status AVPs.
TBA Pseudowire Type Used to specify the Layer 2 payload
type of frames carried by this
session
ICRQ
TBA L2-Specic Sublayer Used to specify the Layer 2 specic
sublayer that the sender requires for
a specic session (if any)
ICRQ / ICRP /
ICCN
TBA Data Sequencing Used to indicate whether the sender
requires sequencing on data packets
for a particular session
ICRQ / ICRP /
ICCN
24 Tx Connect Speed Indicates the transmit speed in bits
per second (bps) from the LAC to
the CE router / remote system (if
Rx Connect Speed attribute is not
also present, indicates bidirectional
speed)
ICRQ / ICRP /
ICCN
38 Rx Connect Speed Indicates the receive speed in bits
per second (bps) from the CE router
/ remote system to the LAC
ICRQ / ICRP /
ICCN
25 Physical Channel ID Indicates the physical channel ID
associated with the call (vendor
specic)
ICRQ / ICRP
Table 5-9 Call Status AVPs
Attribute Type Attribute Name Description Present In
TBA Circuit Status Used to indicate the initial status or
change of status of a circuit
ICRQ / ICRP /
ICCN / SLI
34 Circuit Errors Used to communicate circuit error
information to a peer
WEN
Table 5-8 Session Management AVPs (Continued)
Attribute Type Attribute Name Description Present In
CH01i.book Page 368 Friday, April 30, 2004 8:58 AM
Technical Overview of L2TPv3 369
L2TPv3 Data Messages
L2TPv3 data messages are used to transport frames received on a local attachment circuit to a
peer LAC.
Figure 5-8 shows the overall session data message format.
Figure 5-8 Session Data Message Format
The session data message header used by L2TPv3 over IP is very simple and is shown in Figure 5-9.
Figure 5-9 Session Data Message Header
The 32-bit nonzero session ID carried in the data message header is used to associate incoming
data messages with a particular local attachment circuit. Note that one L2TPv3 session
corresponds to one pseudowire.
Following the session ID is an optional variable length random cookie value (maximum 64
bits). This cookie value can be used in addition to the session ID and adds an extra level of
assurance that the incoming data messages are correctly associated with the local attachment
circuit. Furthermore, a randomly chosen cookie provides protection against blind insertion
attacks. That is, an attacker would nd it very difcult, if not impossible, to insert packets into
a data stream (pseudowire) if the attacker is unable to sniff packets transiting the network
Layer 2 Specific Sublayer
Payload
(Frame Received on Attachment Circuit)
L2TPv3 Session
Header
IP Header
(Protocol ID 115)
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Session ID
Cookie (optional, maximum 64 bits) ...
0 1 2 3
CH01i.book Page 369 Friday, April 30, 2004 8:58 AM
370 Chapter 5: Troubleshooting L2TPv3 Based VPNs
between peer LCCEs. This is because of the difculty of guessing the correct cookie value (0
to 2
64
if the cookie is 64 bits in length).
Session IDs and cookie values are locally signicant to an LCCE. They are communicated to
the peer LCCE during session setup using the Local Session ID and Assigned Cookie AVPs (see
Table 5-8).
Once the locally signicant session ID and cookie values have been communicated to the
remote peer, the remote peer can forward data messages with those values to the local peer.
Figure 5-10 illustrates the function of session IDs and cookies.
Figure 5-10 Session IDs and Cookies
In Figure 5-10, Layer 2 frames received by London_LCCE from mjlnet_CE1 are forwarded to
Frankfurt_LCCE using session ID 11 and cookie 110. Layer 2 frames received by
Frankfurt_LCCE from mjlnet_CE2 are forwarded to London_LCCE using session ID 1 and
cookie 100.
Similarly, Layer 2 frames received by London_LCCE from cisco_CE1 are forwarded to
Frankfurt_LCCE using session ID 2 and cookie 200. Layer 2 frames received by
Frankfurt_LCCE from cisco_CE2 are forwarded to London_LCCE using session ID 22 and
cookie 220.
NOTE The session ID and cookie values shown in Figure 5-10 have no special signicance and are
used only for illustrative purposes.
The next portion of the data message is the Layer 2 specic sublayer. The Layer 2 specic
sublayer can be used to provide additional functionality, such as data message sequencing and
packet priority settings.
Session ID = 1/
Cookie = 100
Session ID = 22/
Cookie = 220
Session ID = 11/
Cookie = 110
Session ID = 2/
Cookie = 200
Pseudowire
Pseudowire
Frankfurt_LCCE London_LCCE
mjlnet_CE1 mjlnet_CE2
cisco_CE1 cisco_CE2
Attachment
Circuits
Attachment
Circuits
CH01i.book Page 370 Friday, April 30, 2004 8:58 AM
Technical Overview of L2TPv3 371
A default Layer 2 specic sublayer is dened in draft-ietf-l2tpext-l2tp-base (L2TP), and this is
shown in Figure 5-11.
Figure 5-11 Default Layer 2 Specific Sublayer
The S bit, if set, is used to specify that sequence numbering is being used. In this case, the
Sequence number eld contains a valid sequence number. Bits marked as x are undened and
should be set to zero.
It is worth noting that other Layer 2 sublayers may be used when transporting particular frame
types, such as Ethernet. An LCCE can signal the use of a particular Layer 2 sublayer during
session setup in an L2 Specic Sublayer AVP (see Table 5-8).
Control Connection Establishment
Before session establishment can begin, a control connection must be established between peer
LCCEs. Control connection establishment is initiated using a Start-Control-Connection-
Request (SCCRQ) message. This message indicates to the peer LCCE that the sending LCCE
wishes to establish a control connection.
The SCCRQ message also carries (among other things) the Pseudowire Capabilities List AVP,
which is used to indicate to the peer LCCE what pseudowire types the sender supports.
Pseudowire types could include Ethernet (port or VLAN), HDLC, and Frame-Relay, for
example. Additionally, the SCCRQ may carry a Control Message Authentication Nonce AVP
(containing a locally generated random number), if authentication is enabled.
Assuming the SCCRQ is acceptable, the peer LCCE responds with a Start-Control-Connection-
Reply (SCCRP) message. This indicates that establishment of the control connection can
proceed. The SCCRP contains (among other things) the peer LCCEs Pseudowire Capabilities
List AVP. If authentication is enabled, the SCCRP will also contain a Message Digest AVP,
together with a Control Message Authentication Nonce AVP containing the peer LCCEs
random number.
The Message Digest AVP contains a hash (HMAC-MD5 or HMAC-SHA-1) value that the
remote LCCE calculates with the following inputs: its random number (nonce), the local
LCCEs random number (nonce), a shared-key generated from a shared L2TPv3 password, and
the L2TPv3 control message itself (header and AVPs).
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Sequence Number x S x x x x x x
0 1 2 3
CH01i.book Page 371 Friday, April 30, 2004 8:58 AM
372 Chapter 5: Troubleshooting L2TPv3 Based VPNs
The local LCCE performs the same calculation, with the same inputs. If the locally calculated
hash value and that contained in the Message Digest AVP are the same, the message from the
remote LCCE is authenticated.
Finally, the control connection initiating LCCE sends a Start-Control-Connection-Connected
(SCCCN) message to the peer LCCE, indicating that control connection establishment has been
completed. If authentication is enabled, the SCCCN will contain a Message Digest AVP. This
is calculated as previously described and is used by the remote LCCE to authenticate the
message.
All control connection messages must carry a Message Digest AVP if authentication is enabled.
The hash value carried in the SCCRQ message is, however, calculated slightly differently. The
inputs are simply the shared key and the control message, including header and AVPs. The
reason for this is that at the time the local LCCE sends the SCCRQ, it does not yet possess the
remote LCCEs nonce value (which is communicated in the SCCRP).
Note that early implementations of L2TPv3 may use AVPs 11 (Challenge) and 13 (Challenge
Response) for authentication. AVPs 11 and 13 were included in early versions of draft-ietf-
l2tpext-l2tp-base but later were replaced by the Message Digest and Control Message
Authentication Nonce AVPs.
Figure 5-12 illustrates control connection establishment.
Figure 5-12 Control Connection Establishment
Note that only one control connection is required between peer LCCEs regardless of the
number of sessions between the two.
Session Establishment
Once the control connection has been established, session setup can begin. Session setup starts
with the initiating LCCE sending a Incoming-Call-Request (ICRQ). Among other things, the
ICRQ includes the pseudowire type and circuit status AVPs. These are used to signal the
4. SCCCN
2. SCCRQ
3. SCCRP
CE Device LCCE LCCE CE Device
IP Backbone
1. Attachment
Circuit Becomes
Active
CH01i.book Page 372 Friday, April 30, 2004 8:58 AM
Technical Overview of L2TPv3 373
payload to be carried in the session (corresponding to the attachment circuit type), and whether
the circuit is active or inactive.
If session setup can proceed, the peer LCCE then responds with an Incoming-Call-Reply
(ICRP). The ICRP carries a number of AVPs, including a circuit status AVP.
The session initiating LCCE now responds to the ICRP with an Incoming-Call-Connected
(ICCN), indicating that the session has been established.
Figure 5-13 illustrates session setup.
Figure 5-13 Session Setup
Once session setup has completed successfully, Layer 2 frames can be transported over the data
session between the LCCEs.
Control Connection Maintenance
If an LCCE does not receive any data or control messages from its peer LCCE for a certain
period, the control connection is maintained by sending a hello message.
Internet Draft draft-ietf-l2tpext-l2tp-base recommends a default inactivity interval of 60
seconds. This is the default on Cisco routers. If the peer LCCE does not acknowledge the hello
message, the control connection is torn down.
Figure 5-14 illustrates the transmission of a hello (keepalive) message.
4. SCCCN
5. ICRQ
2. SCCRQ
3. SCCRP
6. ICRP
7. ICCN
CE Device LCCE LCCE CE Device
IP Backbone
1. Attachment
Circuit Becomes
Active
CH01i.book Page 373 Friday, April 30, 2004 8:58 AM
374 Chapter 5: Troubleshooting L2TPv3 Based VPNs
Figure 5-14 Hello Message
Session Teardown
When either LCCE wishes to tear down a session, it sends a CDN message to its peer. The
reason for the session teardown is contained within the Result Code AVP sent in the CDN.
There are a number of possible reasons for session teardown, including if VCIDs or Layer 2
payload types are mismatched between LCCEs. See Table 5-5 for a list of possible result code
values contained in the CDN (carried in a Result Code AVP).
Figure 5-15 illustrates session teardown when VCIDs are mismatched.
Figure 5-15 Session Teardown
Control Connection Teardown
The control connection can be torn down by either LCCE using a StopCCN message. The
reason for the control connection teardown is contained within the Result Code AVP in the
StopCCN. The control connection can be torn down for a number of reasons, including if a hello
(or other control message) is not acknowledged. For a complete list of results code values
(contained in the StopCCNs Result Code AVP), see Table 5-4. If any sessions remain active,
they are torn down at the same time as the control connection.
2. HELLO
LCCE CE Device CE Device
IP Backbone
1. No Control or
Data Messages
from Peer LCCE
LCCE
1. ICRQ
2. CDN
LCCE CE Device CE Device
IP Backbone
VCID 120
Associated with
Attachment Circuit
VCIS 125 Associated with
Attachment Circuit
(VCID 120 Not Associated
with Any Attachment Circuit)
LCCE
CH01i.book Page 374 Friday, April 30, 2004 8:58 AM
Conguring L2TPv3 375
Figure 5-16 illustrates control connection teardown because of the failure of a peer LCCE to
acknowledge a hello message.
Figure 5-16 Control Connection Teardown
Set-Link-Info (SLI) Message
Another message type that is used by L2TPv3 is Set-Link-Info (SLI). This is used to signal
attachment circuit status.
In Figure 5-17, an LCCE sends an SLI when an attachment circuit changes state to inactive
(down).
Figure 5-17 SLI Message
Conguring L2TPv3
Because misconguration is so often the cause of L2TPv3 issues, this section contains a review
of L2TPv3 (LAC to LAC pseudowire) conguration on Cisco routers.
There are two ways of conguring L2TPv3 on Cisco routers:
Conguring L2TPv3 using dynamic session setup (as described in the section Technical
Overview of L2TPv3)
Conguring L2TPv3 using static sessions
1. HELLO
3. StopCCN
LCCE CE Device CE Device
IP Backbone
2. No
Acknowledgment
Received from Peer
LCCE
LCCE
2. SLI
LCCE CE Device CE Device
IP Backbone
1. Attachment
Circuit Changes
State to Inactive
LCCE
CH01i.book Page 375 Friday, April 30, 2004 8:58 AM
376 Chapter 5: Troubleshooting L2TPv3 Based VPNs
The sections that follow describe these two conguration methods in greater detail.
Note that when reading this section, it may be useful to reference Figure 5-19 on page 390.
Conguring L2TPv3 for Dynamic Session Setup
When conguring L2TPv3 for dynamic session setup, there are ve basic steps to complete on
each LCCE router:
Step 1 Enable Cisco Express Forwarding (CEF).
Step 2 Congure loopback interfaces.
Step 3 Congure the L2TP class.
Step 4 Congure the pseudowire class.
Step 5 Congure the attachment circuits.
The sections that follow describe each of these steps in more detail.
Step 1: Enable CEF
The rst step is to enable CEF, as shown in Example 5-1.
CEF is enabled in Example 5-1 using the ip cef global conguration mode command.
The distributed keyword is used to enable distributed CEF (dCEF), which is available on some
high-end platforms, such as the 7500 and 12000 GSR series.
Step 2: Congure Loopback Interfaces
The next step is to congure a loopback interface to use as a source for L2TPv3 packets. If a
loopback interface is not used, L2TPv3 might not function correctly.
Example 5-2 shows the conguration of the loopback interface.
Note that if you are conguring local switching, multiple loopback interfaces should be
congured. Local switching is used to switch trafc from one interface to another on the same
router.
Example 5-1 Enabling CEF
ip cef [distributed]
Example 5-2 Configuration of the Loopback Interface
interface Loopback0
ip address 10.1.1.1 255.255.255.255
CH01i.book Page 376 Friday, April 30, 2004 8:58 AM
Conguring L2TPv3 377
Step 3: Congure the L2TPv3 Class
The third step is the conguration of the L2TP class. An L2TP class can be used to congure
control connection parameters such as authentication, hidden AVPs, and hello interval. The
L2TP class can later be applied to a particular neighbor or neighbors.
Example 5-3 shows the conguration of the L2TPv3 class.
In Example 5-3, an L2TP class called FrankfurtV3Class is created using the l2tp-class name
command. The authentication command is then used to enable L2TPv3 authentication.
Finally, the shared password is congured using the password password command.
Step 4: Congure the Pseudowire Class
The next step is to congure the pseudowire class. The pseudowire class is used to congure
parameters such as encapsulation and source IP address used when building a pseudowire.
If an L2TP class has been congured (see Step 3), then it is associated with the pseudowire
during this step.
Example 5-4 shows the conguration of a pseudowire class.
In Example 5-4, the pseudowire class FrankfurtPW is congured using the pseudowire-class
name command. The pseudowire encapsulation type is specied using the encapsulation
l2tpv3 command.
The signaling protocol is then specied, and the L2TP class is linked to the pseudowire class
using the protocol l2tpv3 l2tp-class-name command. In this example, the signaling protocol is
specied as L2TPv3, which enables dynamic session setup. The L2TP class is specied as
FrankfurtV3Class.
The local (source) IP address used by L2TPv3 is then congured using the ip local interface
interface command. The interface specied here is the loopback interface congured in Step 2.
Example 5-3 Configuration of the L2TPv3 Class
l2tp-class FrankfurtV3Class
authentication
password 0 cisco
Example 5-4 Configuration of the Pseudowire Class
pseudowire-class FrankfurtPW
encapsulation l2tpv3
protocol l2tpv3 FrankfurtV3Class
ip local interface Loopback0
CH01i.book Page 377 Friday, April 30, 2004 8:58 AM
378 Chapter 5: Troubleshooting L2TPv3 Based VPNs
Step 5: Congure the Attachment Circuits
Once the pseudowire class has been congured, the next step is to congure the attachment
circuits. Precise conguration depends on the attachment circuit type. Types of attachment
circuit include Ethernet, VLAN (802.1Q), Frame Relay, HDLC, PPP, and ATM.
The sections that follow detail the conguration of each of these interface types.
Ethernet Encapsulation
If you are using an Ethernet encapsulation, you should congure the attachment circuit
interface as shown in Example 5-5.
In Example 5-5, the xconnect command is used to bind interface fast Ethernet 1/0 to the
pseudowire to the peer with the IP address 10.1.1.2 (the peers loopback address), VCID 120,
and pseudowire class FrankfurtPW.
Note that the VCID must be the same at both end of the pseudowire on both peers.
VLAN (802.1Q) Encapsulation
Conguration of a VLAN (802.1Q) interface is shown in Example 5-6.
In Example 5-6, interface fast Ethernet 1/0.1 and VLAN 10 is bound to the pseudowire with
VCID 120 to peer 10.1.1.2.
Frame Relay Encapsulation
Two ways exist to congure a Frame Relay pseudowire. You can congure either DLCI-to-
DLCI switching or a Frame Relay trunk.
If DLCI to DLCI switching is used, the router performs Frame Relay switching, and
participates in the Local Management Interface (LMI).
If a Frame Relay trunk is used, Frame Relay frames are transparently forwarded over the
pseudowire by the router.
Frame Relay DLCI-to-DLCI Switching Example 5-7 shows the conguration of Frame
Relay DLCI-to-DLCI switching.
Example 5-5 Configuration of an Ethernet Interface
interface FastEthernet1/0
xconnect 10.1.1.2 120 pw-class FrankfurtPW
Example 5-6 Configuration of a VLAN (802.1Q) Interface
interface FastEthernet1/0.1
encapsulation dot1Q 10
xconnect 10.1.1.2 120 pw-class FrankfurtPW
CH01i.book Page 378 Friday, April 30, 2004 8:58 AM
Conguring L2TPv3 379
In Example 5-7, the frame-relay switching global conguration mode command is used to
enable switching of Frame Relay permanent virtual circuits (PVCs).
The attachment circuit interface is congured for Frame Relay encapsulation using the
encapsulation frame-relay command.
The interface is then congured as type DCE using the frame-relay intf-type [dce | dte | nni]
command. Note that the dce and dte keywords specify User-to-Network-Interface DCE
and DTE interface types, while the nni keyword is used to specify a network-to-network-
interface type.
Once the interface has been congured, the PVC is associated with an L2TPv3 session using
the connect name Serial interface_number dlci l2transport and xconnect peer_ip_address
pw-class name commands, as shown in Example 5-8.
In Example 5-8, a PVC with DLCI 60 on interface serial 4/1 is associated with a pseudowire to
a peer with IP address 10.1.1.2 (its loopback interface) using pseudowire class FrankfurtPW,
dened in Step 3.
Frame Relay Trunks Another option with Frame Relay is to congure a trunk connection
over the pseudowire. In this case, the LCCE does not function as a Frame Relay switch and so
does not participate in LMI.
Example 5-9 shows the conguration of a Frame Relay trunk.
In Example 5-9, interface serial 4/2 is bound to a pseudowire with VCID 121 (to peer 10.1.1.2).
It is worth noting that the encapsulation congured on the interface is HDLC (the default, so it
is not explicitly shown). The fact that HDLC encapsulation is used might be surprising
considering that the pseudowire in Example 5-9 transports Frame Relay trafc. By conguring
HDLC, the pseudowire is congured to transport HDLC or HDLC-like frames (Frame Relay
or PPP, for example).
Example 5-7 Configuration of a Frame Relay DLCI to DLCI Pseudowire
frame-relay switching
interface Serial4/1
encapsulation frame-relay
frame-relay intf-type dce
Example 5-8 Association of PVC to L2TPv3 Session
connect PVCtoFrank Serial4/1 60 l2transport
xconnect 10.1.1.2 121 pw-class FrankfurtPW
Example 5-9 Frame Relay Trunk Configuration
interface Serial4/2
xconnect 10.1.1.2 121 pw-class FrankfurtPW
CH01i.book Page 379 Friday, April 30, 2004 8:58 AM
380 Chapter 5: Troubleshooting L2TPv3 Based VPNs
HDLC and PPP Encapsulations
Conguration for HDLC and PPP encapsulation types is identical to that for a Frame Relay
trunk (shown in Example 5-9).
ATM VP Cell Relay
ATM cells can also be transported over an L2TPv3 pseudowire. To transport ATM cells, a
permanent virtual path (PVP) connection is bound to a pseudowire, as shown in Example 5-10.
In Example 5-10, an ATM PVP with a Virtual Path Identier (VPI) of 10 is bound to a
pseudowire with VCID 131 to peer LCCE 10.1.1.2.
Conguring L2TPv3 for Static Sessions
An alternative to conguring L2TPv3 with dynamic session establishment is to congure
sessions statically. Note that a control connection can still be used with static sessions. In this
case, the control connection can be used to provide authentication and a keepalive mechanism.
Conguration of L2TPv3 with static sessions consists of ve basic steps that must be completed
on each LCCE:
Step 1 Enable CEF.
Step 2 Congure loopback interfaces.
Step 3 Congure the L2TP class (optional).
Step 4 Congure the pseudowire class.
Step 5 Congure the attachment circuit.
Conguration of Step 1 through Step 3 is identical to that described in the previous section,
Conguring L2TPv3 for Dynamic Session Setup, and so is not discussed further here.
The sections that follow discuss the conguration of Step 4 and Step 5.
Step 4: Congure the Pseudowire Class
After enabling CEF, the loopback interfaces, and, optionally, the L2TP class, the next step is to
congure the pseudowire class.
Example 5-11 shows the conguration of the pseudowire class.
Example 5-10 Configuration of a PVP Pseudowire
interface ATM3/0
atm pvp 10 l2transport
xconnect 10.1.1.2 131 pw-class FrankfurtPW
CH01i.book Page 380 Friday, April 30, 2004 8:58 AM
Conguring L2TPv3 381
Most of the conguration of the pseudowire class is the same as that described in the section on
dynamic session setup. The one difference is shown in highlighted line 1, which shows the
protocol none command. The protocol none command congures the router not to use
dynamic session setup.
Step 5: Congure the Attachment Circuit
After conguring the pseudowire class, the next step is to congure the attachment circuits.
When conguring attachment circuits with static sessions, you must specify local and remote
session IDs, together with local and remote cookie values on each peer router. Session IDs and
cookie values must be mirrored between peer routers.
Example 5-12 shows the conguration of attachment circuits when using static sessions. Note
that the conguration of peer routers London_PE and Frankfurt_PE is shown for DLCI-to-
DLCI switching.
Example 5-11 Configuration of the Pseudowire Class
pseudowire-class FrankfurtPW
encapsulation l2tpv3
protocol none
ip local interface Loopback0
Example 5-12 Configuration of Attachment Circuits with Static Sessions
! On London_PE:
frame-relay switching
!
interface Serial4/1
encapsulation frame-relay
frame-relay intf-type dce
!
connect PVCtoFrankfurt Serial4/1 60 l2transport
xconnect 10.1.1.2 123 encapsulation l2tpv3 manual pw-class FrankfurtPW
l2tp id 1002 2001
l2tp cookie local 4 102
l2tp cookie remote 4 201
l2tp hello FrankfurtV3Class
! On Frankfurt_PE:
frame-relay switching
!
interface Serial2/1
encapsulation frame-relay
frame-relay intf-type dce
!
connect PVCtoLondon Serial2/1 70 l2transport
xconnect 10.1.1.1 123 encapsulation l2tpv3 manual pw-class LondonPW
l2tp id 2001 1002
l2tp cookie local 4 201
l2tp cookie remote 4 102
l2tp hello LondonV3Class
CH01i.book Page 381 Friday, April 30, 2004 8:58 AM
382 Chapter 5: Troubleshooting L2TPv3 Based VPNs
As you can see, some of the conguration is the same as that for dynamic session establishment.
The crucial difference is the xconnect peer_ip_address encapsulation l2tpv3 manual
pw-class name command conguration.
In highlighted lines 1 and 2, the PVC with DLCI 60 on interface serial 4/1 is bound to a static
session to peer router 10.1.1.2 (Frankfurt_PE).
Note the VCID (123) congured in highlighted line 2. When using dynamic session
establishment, the VCID must be identical on peer routers, but when using static sessions, there
is no such requirement. It is still good practice, though.
In highlighted line 3, the local and remote session IDs are congured using the l2tp id
local_session_id remote_session_id command. Compare these to the local and remote session
IDs congured on the peer router, Frankfurt_PE in highlighted line 7. Notice that they mirror
each other.
In highlighted lines 4 and 5, local and remote cookie values are congured using the l2tp cookie
local size low_value [high_value] and l2tp cookie remote size low_value [high_value]. Again,
notice that they mirror the cookies on Frankfurt_PE in highlighted lines 8 and 9.
Finally, in highlighted line 6, the (optional) command l2tp hello l2tp_class_name command is
used to specify that a control connection will be setup (and keepalives sent) between the peers.
Again, notice that the peer is similarly congured (highlighted line 10).
Note that session IDs, cookie values, and (optionally) a control connection must similarly be
congured under the xconnect command for other encapsulation types. That concludes the
conguration of L2TPv3.
Complete Sample L2TPv3 Congurations
Example 5-13 shows complete basic congurations of two peer LCCEs using dynamic session
establishment.
Again, it may be useful to reference Figure 5-19 on page 390 when examining these
congurations.
Example 5-13 Complete Configuration of Peer LCCEs
London_LCCE#show running-config
Building configuration...
Current configuration : 2457 bytes
!
version 12.0
service nagle
no service pad
service tcp-keepalives-in
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
service password-encryption
!
CH01i.book Page 382 Friday, April 30, 2004 8:58 AM
Conguring L2TPv3 383
hostname London_LCCE
!
logging buffered 16384 debugging
no logging console
enable secret 5 $1$4vTL$YY8dhLhFk7RAVy.lI.TtH/
!
ip subnet-zero
no ip source-route
! Enable Cisco Express Forwarding (CEF)
ip cef
!
!
no ip finger
no ip bootp server
!
! Configure frame-relay switching (for DLCI-to-DCLI switching)
frame-relay switching
!
! Configure the L2TPv3 class for Stockholm_LCCE
l2tp-class StockholmV3Class
authentication
password 0 cisco
!
! Configure the L2TPv3 class for Frankfurt_LCCE
l2tp-class FrankfurtV3Class
authentication
password 0 cisco
!
! Configure the pseudowire class for Stockholm_LCCE
pseudowire-class StockholmPW
encapsulation l2tpv3
protocol l2tpv3 StockholmV3Class
ip local interface Loopback0
!
! Configure the pseudowire class for Frankfurt_LCCE
pseudowire-class FrankfurtPW
encapsulation l2tpv3
protocol l2tpv3 FrankfurtV3Class
ip local interface Loopback0
!
! Configure the loopback interface
interface Loopback0
ip address 10.1.1.1 255.255.255.255
!
interface FastEthernet1/0
no ip address
no ip directed-broadcast
!
! Configure a VLAN (802.1q) attachment circuit (pseudowire to Frankfurt_LCCE)
interface FastEthernet1/0.1
encapsulation dot1Q 10
Example 5-13 Complete Configuration of Peer LCCEs (Continued)
CH01i.book Page 383 Friday, April 30, 2004 8:58 AM
384 Chapter 5: Troubleshooting L2TPv3 Based VPNs
no ip directed-broadcast
no cdp enable
xconnect 10.1.1.2 120 pw-class FrankfurtPW
!
interface Serial4/0
ip address 172.16.1.1 255.255.255.0
no ip redirects
no ip directed-broadcast
no ip proxy-arp
ip router isis
no cdp enable
!
! Configure frame-relay DLCI-to-DLCI switching
interface Serial4/1
no ip address
no ip redirects
no ip directed-broadcast
no ip proxy-arp
encapsulation frame-relay
frame-relay intf-type dce
!
!
router isis
passive-interface Loopback0
net 49.0001.0000.0000.0001.00
is-type level-2-only
!
ip classless
!
!
logging trap debugging
!
! Bind DLCI 50 to pseudowire (to Stockholm_LCCE)
connect PVCtoStock Serial4/1 50 l2transport
xconnect 10.1.1.3 131 pw-class StockholmPW
!
!
! Bind DLCI 60 to pseudowire (to Frankfurt_LCCE)
connect PVCtoFrank Serial4/1 60 l2transport
xconnect 10.1.1.2 121 pw-class FrankfurtPW
!
!
!
line con 0
password 7 094F471A1A0A
login
line aux 0
line vty 0 4
Example 5-13 Complete Configuration of Peer LCCEs (Continued)
CH01i.book Page 384 Friday, April 30, 2004 8:58 AM
Conguring L2TPv3 385
password 7 094F471A1A0A
login
!
end
Frankfurt_LCCE#show running-config
Building configuration...
Current configuration : 2610 bytes
!
version 12.0
service config
service nagle
no service pad
service tcp-keepalives-in
service timestamps debug datetime msec localtime show-timezone
service timestamps log datetime msec localtime show-timezone
service password-encryption
!
hostname Frankfurt_LCCE
!
!
logging buffered 16384 debugging
enable secret 5 $1$4vTL$YY8dhLhFk7RAVy.lI.TtH/
!
ip subnet-zero
no ip source-route
!
! Enable Cisco Express Forwarding (CEF)
ip cef
no ip finger
no ip bootp server
!
! Configure frame-relay switching (for DLCI-to-DCLI switching)
frame-relay switching
!
! Configure the L2TPv3 class for Stockholm_LCCE
l2tp-class StockholmV3Class
authentication
password 0 cisco
!
! Configure the L2TPv3 class for London_LCCE
l2tp-class LondonV3Class
authentication
password 0 cisco
!
! Configure the pseudowire class for Stockholm_LCCE
pseudowire-class StockholmPW
encapsulation l2tpv3
protocol l2tpv3 StockholmV3Class
ip local interface Loopback0
!
Example 5-13 Complete Configuration of Peer LCCEs (Continued)
CH01i.book Page 385 Friday, April 30, 2004 8:58 AM
386 Chapter 5: Troubleshooting L2TPv3 Based VPNs
! Configure the pseudowire class for London_LCCE
pseudowire-class LondonPW
encapsulation l2tpv3
protocol l2tpv3 LondonV3Class
ip local interface Loopback0
!
! Configure the loopback interface
interface Loopback0
ip address 10.1.1.2 255.255.255.255
no ip directed-broadcast
!
! Configure a VLAN (802.1q) attachment circuit (pseudowire to London_LCCE)
interface FastEthernet0/0.1
encapsulation dot1Q 10
no ip directed-broadcast
no cdp enable
xconnect 10.1.1.1 120 pw-class LondonPW
!
!
interface Serial2/0
ip address 172.16.2.2 255.255.255.0
no ip redirects
no ip directed-broadcast
no ip proxy-arp
ip router isis
no cdp enable
!
! Configure frame-relay DLCI-to-DLCI switching
interface Serial2/1
no ip address
no ip redirects
no ip directed-broadcast
no ip proxy-arp
encapsulation frame-relay
frame-relay intf-type dce
!
!
router isis
net 49.0001.0000.0000.0002.00
is-type level-2-only
passive-interface Loopback0
!
ip classless
!
logging trap debugging
!
! Bind DLCI 80 to pseudowire (to Stockholm_LCCE)
connect PVCtoStock Serial2/1 80 l2transport
xconnect 10.1.1.3 131 pw-class StockholmPW
!
Example 5-13 Complete Configuration of Peer LCCEs (Continued)
CH01i.book Page 386 Friday, April 30, 2004 8:58 AM
Conguring L2TPv3 387
You will notice that the conguration for London_LCCE in Example 5-13 species three
pseudowires:
One VLAN (VCID 120) to Frankfurt_LCCE (10.1.1.2)
One Frame Relay (switching) pseudowire for DLCI 60 (VCID 121) to Frankfurt_LCCE
(10.1.1.2)
One Frame Relay (switching) pseudowire for DLCI 50 to Stockholm_LCCE (10.1.1.3,
not shown in Figure 5-19)
The conguration for Frankfurt_LCCE similarly species three pseudowires:
One VLAN (VCID 120) to London_LCCE (10.1.1.1)
One Frame Relay for DLCI 70 (VCID 121) to London_LCCE (10.1.1.1)
One Frame Relay pseudowire for DLCI 80 to Stockholm_LCCE
MTU Issues with L2TPv3
When conguring L2TPv3, you need to be aware of Maximum Transmission Unit (MTU)
issues that may result from the transport of large data frames.
If large data frames are transported over the pseudowire, this may result in either fragmentation
or even the dropping of L2TPv3 packets. If L2TPv3 packets are fragmented, the receiving
LCCE has to perform packet reassembly, and this increases CPU utilization. The fragmentation
or dropping of L2TPv3 packets can result if the MTU of any links between peer LCCEs is
smaller than the L2TPv3 packet size (see Figure 5-8).
To calculate the L2TPv3 packet size, add the IP header (20 bytes), the L2TPv3 session header
(12 bytes, assuming a 64-bit cookie size), the optional Layer 2 specic sublayer (4 bytes, if
using the default Layer 2 specic sublayer), and the payload (the frame received on the
!
! Bind DLCI 70 to pseudowire (to London_LCCE)
connect PVCtoFrank Serial2/1 70 l2transport
xconnect 10.1.1.1 121 pw-class LondonPW
!
!
line con 0
password 7 094F471A1A0A
login
line aux 0
line vty 0 4
password 7 094F471A1A0A
login
!
end
Example 5-13 Complete Configuration of Peer LCCEs (Continued)
CH01i.book Page 387 Friday, April 30, 2004 8:58 AM
388 Chapter 5: Troubleshooting L2TPv3 Based VPNs
attachment circuit). When calculating the payload size, do not forget to include the attachment
circuit Layer 2 headerthis is in addition to the MTU of the attachment circuit.
For example, a 1504-byte frame received on a Frame Relay attachment circuit (including the 4
byte Frame-Relay header) would yield an L2TPv3 packet size of: 20 bytes (IP packet header)
+ 12 bytes (L2TPv3 session header) + 4 bytes (the default Layer 2 specic sublayer, which only
has to be included if sequencing is enabled) + 1504 (the frame received on the attachment
circuit) = 1540 bytes.
There are several ways to address the MTU issue, including enabling Path MTU Discovery for
L2TPv3.
Enabling Path MTU Discovery allows the LCCE to detect the smallest MTU in the path to its
peer LCCE and dynamically adjust the MTU for L2TPv3 sessions. This feature can be enabled
using the ip dfbit set and ip pmtu commands.
The ip dfbit set command sets the Dont Fragment (DF) bit in the IP header of L2TPv3 packets,
which prevents fragmentation of L2TPv3 packets.
If a router in the path between the peer LCCEs needs to fragment an L2TPv3 packet but is
prevented from doing so because the Dont Fragment (DF) bit is set, it should send an Internet
Control Message Protocol (ICMP) unreachable message (ICMP message type 3, code 4) back
to the sending LCCE specifying that fragmentation is required but that the DF bit is set. If the
ip pmtu command is congured on the sending LCCE, it then reduces the size of L2TPv3
packets it sends.
Example 5-14 shows the conguration of both of these commands.
Example 5-14 shows the conguration of the ip pmtu and ip dfbit set commands within a
pseudowire class called FrankfurtPW.
If switches are being used in the service provider point-of-presence (PoP), also ensure that these
switches are congured to support large L2TPv3 packets. To support large L2TPv3 packets,
you should enable jumbo frame support. See the following URL for more details on the
conguration of jumbo frame support on Cisco Catalyst switches:
http://www.cisco.com/en/US/products/hw/switches/ps700/
products_conguration_example09186a008010edab.shtml
Example 5-14 Configuring the ip pmtu and ip dfbit set Commands
pseudowire-class FrankfurtPW
ip pmtu
ip dfbit set
CH01i.book Page 388 Friday, April 30, 2004 8:58 AM
Troubleshooting L2TPv3 389
Troubleshooting L2TPv3
The L2TPv3 troubleshooting process depends on whether you are using dynamic session
establishment or static session conguration. One common element is the control connection
(assuming that it is congured with static sessions).
This section is split into three subsections:
The rst subsection focuses on control connection establishment.
The second subsection focuses on dynamic session setup.
The third subsection focuses on static session conguration.
Troubleshooting L2TPv3 with dynamic session setup consists of troubleshooting control
connection establishment and then troubleshooting dynamic session setup itself.
Troubleshooting L2TPv3 with static session conguration consists of troubleshooting control
connection establishment (if congured), and then the static session conguration itself.
The owchart in Figure 5-18 describes the troubleshooting process used with L2TPv3. You can
use this owchart to quickly access the section of the chapter relevant to problems you are
experiencing on your network.
Figure 5-18 L2TPv3 Troubleshooting Flowchart
CH01i.book Page 389 Friday, April 30, 2004 8:58 AM
390 Chapter 5: Troubleshooting L2TPv3 Based VPNs
Figure 5-19 shows the sample topology used to illustrate the concepts in the sections that
follow.
Figure 5-19 Sample Topology for Troubleshooting Examples
In Figure 5-19, frames received by London_LCCE/PE on interface serial 4/1 from mjlnet_CE1
are forwarded over an L2TPv3 session to Frankfurt_LCCE/PE. Frankfurt_LCCE/PE then
forwards these frames out of interface serial 2/1 to mjlnet_CE2.
Frames received by London_LCCE/PE on interface Fast Ethernet 1/0.1 are forwarded over an
L2TPv3 session to Frankfurt_LCCE/PE. Frankfurt_LCCE/PE then forwards the frames out of
interface Fast Ethernet 0/0.1.
Similarly, frames received by Frankfurt_LCCE/PE on interface serial 2/1 from mjlnet_CE2 are
forwarded over an L2TPv3 session to London_LCCE/PE. London_LCCE/PE then forwards
these frames out of interface serial 4/1 to mjlnet_CE1.
Frames received by Frankfurt_LCCE/PE on interface Fast Ethernet 0/0.1 are forwarded over an
L2TPv3 session to London_LCCE/PE. London_LCCE/PE then forwards the frames out of
interface Fast Ethernet 1/0.1.
Note that although Figure 5-19 shows only one L2TPv3 session, two would in fact be required,
one for each pair of attachment circuits.
Troubleshooting L2TPv3 Control Connection Setup
The rst step in the L2TPv3 troubleshooting process is to verify control connection
establishment, which is illustrated in Figure 5-20.
In Figure 5-20, the rst attachment circuit changes state to active (up), and control connection
establishment begins.
L2TP Layer 2 Layer 2
mjlnet_CE2
mjlnet_CE1
IP Backbone
FE 1/0.1 FE 0/0.1 192.168.1.1 192.168.1.2
S 4/1 S 4/0 S 2/0 S 2/1
London_LCCE / PE
Lo0: 10.1.1.1
Frankfurt_LCCE / PE
Lo0: 10.1.1.2
CH01i.book Page 390 Friday, April 30, 2004 8:58 AM
Troubleshooting L2TPv3 391
Before examining how control connection establishment can fail, it is useful to rst have a look
at a successful control connection establishment sequence.
Figure 5-20 L2TPv3 Control Connection Establishment
The control connection establishment sequence can be examined using the debug vpdn l2x-
events command, as shown in Example 5-15. Note that only the relevant portion of the output
is shown.
Example 5-15 Successful Control Connection Establishment
London_LCCE#debug vpdn l2x-events
L2X protocol events debugging is on
*Mar 30 18:41:08.751 UTC: L2X: l2tun session [1646198216], event [client request], old
state [open], new state [open]
*Mar 30 18:41:08.751 UTC: L2X: L2TP: Received L2TUN message <Connect>
*Mar 30 18:41:08.755 UTC: Tnl/Sn26577/62344 L2TP: Session state change from idle to
wait-for-tunnel
*Mar 30 18:41:08.755 UTC: Tnl/Sn26577/62344 L2TP: Create session
*Mar 30 18:41:08.755 UTC: Tnl26577 L2TP: SM State idle
*Mar 30 18:41:08.755 UTC: Tnl26577 L2TP: O SCCRQ
*Mar 30 18:41:08.755 UTC: Tnl26577 L2TP: Control channel retransmit delay set to
1 seconds
*Mar 30 18:41:08.755 UTC: Tnl26577 L2TP: Tunnel state change from idle to wait-ctl-
reply
*Mar 30 18:41:08.755 UTC: Tnl26577 L2TP: SM State wait-ctl-reply
*Mar 30 18:41:08.803 UTC: Tnl26577 L2TP: I SCCRP from Frankfurt_LCCE
*Mar 30 18:41:08.803 UTC: Tnl26577 L2TP: Got a challenge from remote peer,
Frankfurt_LCCE
*Mar 30 18:41:08.803 UTC: Tnl26577 L2TP: Got a response from remote peer,
Frankfurt_LCCE
*Mar 30 18:41:08.803 UTC: Tnl26577 L2TP: Tunnel Authentication success
*Mar 30 18:41:08.803 UTC: Tnl26577 L2TP: Tunnel state change from wait-ctl-reply to
established
*Mar 30 18:41:08.803 UTC: Tnl26577 L2TP: O SCCCN to Frankfurt_LCCE tnlid 63650
*Mar 30 18:41:08.803 UTC: Tnl26577 L2TP: Control channel retransmit delay set to
1 seconds
*Mar 30 18:41:08.803 UTC: Tnl26577 L2TP: SM State established
London_LCCE#
2. Control Connection Established
London_LCCE / PE
(10.1.1.1) mjlnet_CE1 mjlnet_CE2
IP Backbone
1. Attachment
Circuit Becomes
Active
Frankfurt_LCCE / PE
(10.1.1.2)
CH01i.book Page 391 Friday, April 30, 2004 8:58 AM
392 Chapter 5: Troubleshooting L2TPv3 Based VPNs
In highlighted line 1, London_LCCE sends a SCCRQ to Frankfurt_LCCE initiating control
connection establishment. Authentication is enabled on London_LCCE, and so this SCCRQ
contains a Challenge AVP.
An SCCRP is then received from Frankfurt_LCCE in highlighted line 2. Note that the hostname
Frankfurt_LCCE is carried in the SCCRP using the Hostname AVP.
Also contained in the SCCRP are an authentication Challenge AVP and a Challenge Response
AVP (highlighted lines 3 and 4). The Challenge Response corresponds to the Challenge in the
SCCRQ sent by London_LCCE in highlighted line 1.
Note that the Challenge and Challenge Response AVPs will be replaced by the Message Digest
and Control Message Authentication Nonce AVPs in later implementations of L2TPv3. Later
versions of Cisco IOS Software will also be able to support Challenge and Challenge Response
AVPs if congured to do so.
In highlighted line 5, London_LCCE reports that authentication has been successful. Then in
highlighted line 6, London_LCCE sends an SCCCN. This completes control connection
establishment, and in highlighted line 7, the L2TPv3 state machine (SM) state changes to
established.
The control connection is now up. This can be conrmed using the show l2tun tunnel
command, as shown in Example 5-16.
Highlighted line 1 shows that one control connection and two data sessions have been
established. Note that session establishment is not shown in Example 5-15.
In highlighted line 2, the local and remote control connection IDs are shown, together with the
remote LCCEs hostname (Frankfurt_LCCE), control connection state (established), the
remote LCCEs IP address (10.1.1.2), the number of sessions established (2), and the associated
L2TP class (FrankfurtV3Class).
Control connection setup can fail for number of reasons, including the following:
There is no IP connectivity between the LCCEs source addresses (loopback interfaces).
The peer LCCEs IP address is miscongured (with the xconnect command).
An access list blocks IP protocol 115.
L2TPv3 authentication fails.
Use extended ping to ensure that there is basic IP connectivity between the local and remote
LCCEs source addresses (usually loopback interface IP addresses). If a ping test fails, begin
Example 5-16 Control Connection Is Established
London_LCCE#show l2tun tunnel
Tunnel Information Total tunnels 1 sessions 2
LocID RemID Remote Name State Remote Address Port Sessions L2TPclass
33028 43495 Frankfurt_LCC est 10.1.1.2 0 2 FrankfurtV3Clas
London_LCCE#
CH01i.book Page 392 Friday, April 30, 2004 8:58 AM
Troubleshooting L2TPv3 393
regular IP troubleshooting. Note that a ping test will test only ICMP ECHO Request and ICMP
ECHO Reply connectivity between LCCEs.
Other issues affecting control connection establishment (listed above) are examined in the
following three sections.
Peer LCCEs IP Address Is Miscongured (with the xconnect Command)
If the remote LCCEs IP address is miscongured on the local LCCE, control connection
establishment will fail.
It is worth noting that if multiple pseudowires are congured between LCCE peers, as long as
one pseudowire is correctly congured (with the xconnect command), then the control
connection will be successfully established.
Use the debug vpdn l2x-events command to troubleshoot this issue, as shown in Example
5-17. Note that only the relevant portion of the output is shown.
Example 5-17 Control Connection Establishment Fails
London_LCCE#debug vpdn l2x-events
L2X protocol events debugging is on
London_LCCE#
*Mar 30 21:20:53.419 UTC: L2TP: I SCCRQ from Frankfurt_LCCE tnl 9449
*Mar 30 21:20:54.419 UTC: L2TP: I SCCRQ from Frankfurt_LCCE tnl 9449
*Mar 30 21:20:56.419 UTC: L2TP: I SCCRQ from Frankfurt_LCCE tnl 9449
*Mar 30 21:20:59.815 UTC: L2X: l2tun session [1646198216], event [client request], old
state [open], new state [open]
*Mar 30 21:20:59.815 UTC: L2X: L2TP: Received L2TUN message <Connect>
*Mar 30 21:20:59.815 UTC: Tnl/Sn49403/30972 L2TP: Session state change from idle to
wait-for-tunnel
*Mar 30 21:20:59.815 UTC: Tnl/Sn49403/30972 L2TP: Create session
*Mar 30 21:20:59.815 UTC: Tnl49403 L2TP: SM State idle
*Mar 30 21:20:59.815 UTC: Tnl49403 L2TP: O SCCRQ
*Mar 30 21:20:59.815 UTC: Tnl49403 L2TP: Control channel retransmit delay set to
1 seconds
*Mar 30 21:20:59.815 UTC: Tnl49403 L2TP: Tunnel state change from idle to
wait-ctl-reply
*Mar 30 21:20:59.815 UTC: Tnl49403 L2TP: SM State wait-ctl-reply
*Mar 30 21:21:00.815 UTC: Tnl49403 L2TP: O Resend SCCRQ, flg TLS, ver 3, len 134,
tnl 0, ns 0, nr 0
*Mar 30 21:21:00.815 UTC: Tnl49403 L2TP: Control channel retransmit delay set to
2 seconds
*Mar 30 21:21:02.815 UTC: Tnl49403 L2TP: O Resend SCCRQ, flg TLS, ver 3, len 134,
tnl 0, ns 0, nr 0
*Mar 30 21:21:02.815 UTC: Tnl49403 L2TP: Control channel retransmit delay set to
4 seconds
*Mar 30 21:21:06.815 UTC: Tnl49403 L2TP: O StopCCN
*Mar 30 21:21:06.815 UTC: Tnl49403 L2TP: Tunnel state change from wait-ctl-reply to
shutting-down
*Mar 30 21:21:06.815 UTC: Tnl/Sn49403/30972 L2TP: Destroying session
*Mar 30 21:21:06.815 UTC: L2X: Sending L2TUN message <Connect Fail>
CH01i.book Page 393 Friday, April 30, 2004 8:58 AM
394 Chapter 5: Troubleshooting L2TPv3 Based VPNs
Highlighted lines 1 to 3 show three SCCRQs from Frankfurt_LCCE. Note that London_LCCE
does not respond with an SCCRP.
Then in highlighted line 4, London_LCCE sends a SCCRQ. This is re-sent in highlighted lines
5 and 6. Note that there is no response (SCCRP) from Frankfurt_LCCE.
London_LCCE is receiving control connection messages from Frankfurt_LCCE but not
responding. Additionally, London_LCCE is sending control messages (to Frankfurt_LCCE)
but receiving no response.
Further clarity can be obtained using the debug vpdn l2x-errors command. This is shown in
Example 5-18.
As you can see, London_LCCE cannot locate any conguration for remote peer
Frankfurt_LCCE (highlighted line 1). Note Frankfurt_LCCEs IP address (10.1.1.2).
London_LCCEs conguration is then examined using the show running-cong command, as
shown in Example 5-19. Note that only the relevant portion of the output is shown.
The highlighted line shows the IP address congured for Frankfurt_LCCE (for the pseudowire
with VCID 121). As you can see it is 10.1.1.3. Unfortunately, Frankfurt_LCCEs IP address is
10.1.1.2.
*Mar 30 21:21:06.815 UTC: Tnl/Sn49403/30972 L2TP: Session state change from
wait-for-tunnel to idle
London_LCCE#
Example 5-18 Remote LCCEs IP Address Is Misconfigured on the Local LCCE
London_LCCE#debug vpdn l2x-errors
L2X protocol errors debugging is on
London_LCCE#
*Mar 30 21:22:11.419 UTC: L2TP: No tunnel config found for remote peer Frankfurt_LCCE,
local/remote address 10.1.1.1/10.1.1.2
*Mar 30 21:22:12.419 UTC: L2TP: No tunnel config found for remote peer Frankfurt_LCCE,
local/remote address 10.1.1.1/10.1.1.2
*Mar 30 21:22:14.419 UTC: L2TP: No tunnel config found for remote peer Frankfurt_LCCE,
local/remote address 10.1.1.1/10.1.1.2
London_LCCE#
Example 5-19 Frankfurt_LCCEs IP Address Is Misconfigured
London_LCCE#show running-config
Building configuration...
!
connect PVCtoFrank Serial4/1 60 l2transport
xconnect 10.1.1.3 121 pw-class FrankfurtPW
!
!
Example 5-17 Control Connection Establishment Fails (Continued)
CH01i.book Page 394 Friday, April 30, 2004 8:58 AM
Troubleshooting L2TPv3 395
The IP address for Frankfurt_LCCE is then recongured, as shown in Example 5-20.
In the highlighted line, the IP address for Frankfurt_LCCE is recongured as 10.1.1.2. Once the
IP address for Frankfurt_LCCE has been recongured, control connection establishment
succeeds. This is veried using the show l2tun tunnel command, as shown in Example 5-21.
As you can see, the control connection has been successfully set up to Frankfurt_LCCE.
It is also worth noting that if the local LCCEs IP address is miscongured on the remote LCCE,
then no control messages from the remote LCCE would be received by the local LCCE.
Access List Is Blocking L2TPv3
If an access list is blocking IP protocol 115, then control connection establishment will fail.
You can use the debug vpdn l2x-events command to troubleshoot this issue, as demonstrated
in Example 5-22.
Example 5-20 IP Address for Frankfurt_LCCE Is Reconfigured
London_LCCE#conf t
Enter configuration commands, one per line. End with CNTL/Z.
London_LCCE(config)#connect PVCtoFrank Serial4/1 60 l2transport
London_LCCE(config-fr-pw-switching)#xconnect 10.1.1.2 121 pw-class FrankfurtPW
London_LCCE(config-fr-pw-switching)#exit
London_LCCE#
Example 5-21 Control Connection Establishment Has Succeeded
London_LCCE#show l2tun tunnel
Tunnel Information Total tunnels 1 sessions 1
LocID RemID Remote Name State Remote Address Port Sessions L2TPclass
8055 44724 Frankfurt_LCC est 10.1.1.2 0 1 FrankfurtV3Clas
London_LCCE#
Example 5-22 Control Connection Establishment Fails
London_LCCE#debug vpdn l2x-events
L2X protocol events debugging is on
*Mar 31 09:48:19.479 UTC: L2X: l2tun session [1646198216], event [client request], old
state [open], new state [open]
*Mar 31 09:48:19.479 UTC: L2X: L2TP: Received L2TUN message <Connect>
*Mar 31 09:48:19.479 UTC: Tnl/Sn35842/42451 L2TP: Session state change from idle to
wait-for-tunnel
*Mar 31 09:48:19.479 UTC: Tnl/Sn35842/42451 L2TP: Create session
*Mar 31 09:48:19.479 UTC: Tnl35842 L2TP: SM State idle
*Mar 31 09:48:19.479 UTC: Tnl35842 L2TP: O SCCRQ
*Mar 31 09:48:19.479 UTC: Tnl35842 L2TP: Control channel retransmit delay set to
1 seconds
*Mar 31 09:48:19.479 UTC: Tnl35842 L2TP: Tunnel state change from idle to
wait-ctl-reply
*Mar 31 09:48:19.479 UTC: Tnl35842 L2TP: SM State wait-ctl-reply
*Mar 31 09:48:20.479 UTC: Tnl35842 L2TP: O Resend SCCRQ, flg TLS, ver 3, len 134,
CH01i.book Page 395 Friday, April 30, 2004 8:58 AM
396 Chapter 5: Troubleshooting L2TPv3 Based VPNs
In highlighted line 1, London_LCCE initiates control connection establishment to
Frankfurt_LCCE by sending a SCCRQ message. Then in highlighted lines 2 and 3, the SCCRQ
is re-sent. No response from Frankfurt_LCCE. This might indicate the presence of an access
list blocking L2TPv3 on any of the routers in the path between London_LCCE and
Frankfurt_LCCE.
Use the show ip interface [interface_name] command to check for the presence of access lists.
When Frankfurt_LCCE is checked, an access list is discovered on its serial 2/0 interface (which
is in the path from London_LCCE), as demonstrated in Example 5-23.
In the highlighted line, you can see that access list 101 is congured in an inbound direction on
interface serial 2/0.
The composition of access list 101 is then veried using the show ip access-lists command, as
shown in Example 5-24.
tnl 0, ns 0, nr 0
*Mar 31 09:48:20.479 UTC: Tnl35842 L2TP: Control channel retransmit delay set to
2 seconds
*Mar 31 09:48:22.479 UTC: Tnl35842 L2TP: O Resend SCCRQ, flg TLS, ver 3, len 134,
tnl 0, ns 0, nr 0
*Mar 31 09:48:22.479 UTC: Tnl35842 L2TP: Control channel retransmit delay set to
4 seconds
London_LCCE#
Example 5-23 Access List on Frankfurt_LCCE
Frankfurt_LCCE#show ip interface serial 2/0
Serial2/0 is up, line protocol is up
Internet address is 172.16.2.1/24
Broadcast address is 255.255.255.255
Address determined by non-volatile memory
MTU is 1500 bytes
Helper address is not set
Directed broadcast forwarding is disabled
Outgoing access list is not set
Inbound access list is 101
Proxy ARP is disabled
Security level is default
Split horizon is enabled
Example 5-24 Composition of Access List 101
Frankfurt_LCCE#show ip access-lists
Extended IP access list 101
permit tcp any any eq www
permit tcp any any eq telnet
permit tcp any any eq ftp
permit tcp any any eq ftp-data
permit udp any any eq tftp
Example 5-22 Control Connection Establishment Fails (Continued)
CH01i.book Page 396 Friday, April 30, 2004 8:58 AM
Troubleshooting L2TPv3 397
As you can see, access list 101 permits a number of protocols, but signicantly not IP protocol
115 (L2TPv3). L2TPv3 is, therefore, denied.
In this case, it is decided that access list 101 is not necessary, and it is removed from interface
serial 2/0, as shown in Example 5-25.
Access list 101 is removed from interface serial 2/0 in the highlighted line.
Once the access list has been removed, the control connection is successfully established
between London_LCCE and Frankfurt_LCCE, as demonstrated in Example 5-26.
The highlighted line shows that a control connection has been successfully established from
London_LCCE to Frankfurt_LCCE.
L2TPv3 Authentication Fails
If L2TPv3 authentication fails (assuming that it is congured), then control connection setup
will fail.
To troubleshoot L2TPv3 authentication issues, use the debug vpdn l2x-events command, as
shown in Example 5-27.
An SCCRQ is sent by London_LCCE to Frankfurt_LCCE is highlighted line 1. Because
authentication is congured in this scenario, this SCCRQ contains a Challenge AVP.
permit udp any any eq ntp
permit udp any any eq snmp
permit udp any any eq snmptrap
deny ip any any log-input (111 matches)
Frankfurt_LCCE#
Example 5-25 Removal of Access List 101
Frankfurt_LCCE#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Frankfurt_LCCE(config)#interface serial 2/0
Frankfurt_LCCE(config-if)#no ip access-group 101 in
Frankfurt_LCCE(config-if)#exit
Frankfurt_LCCE#
Example 5-26 Successful Establishment of the Control Connection
London_LCCE#show l2tun tunnel
Tunnel Information Total tunnels 1 sessions 1
LocID RemID Remote Name State Remote Address Port Sessions L2TPclass
36025 30898 Frankfurt_LCC est 10.1.1.2 0 1 FrankfurtV3Clas
London_LCCE#
Example 5-24 Composition of Access List 101 (Continued)
CH01i.book Page 397 Friday, April 30, 2004 8:58 AM
398 Chapter 5: Troubleshooting L2TPv3 Based VPNs
In highlighted line 2, a SCCRP is received from Frankfurt_LCCE. This SCCRP contains a
Challenge AVP (highlighted line 3), and a Challenge Response AVP (highlighted line 4). The
Challenge Response AVP is Frankfurt_LCCEs response to the Challenge AVP sent by
London_LCCE in the SCCRQ (highlighted line 1).
NOTE Note that the Challenge and Challenge Response AVPs will be replaced by the Message Digest
and Control Message Authentication Nonce AVPs in later implementations of L2TPv3.
Example 5-27 L2TPv3 Authentication Fails
London_LCCE#debug vpdn l2x-events
L2X protocol events debugging is on
London_LCCE#
*Mar 30 19:28:34.551 UTC: L2X: l2tun session [1646198216], event [client request], old
state [open], new state [open]
*Mar 30 19:28:34.551 UTC: L2X: L2TP: Received L2TUN message <Connect>
*Mar 30 19:28:34.551 UTC: Tnl/Sn51926/62398 L2TP: Session state change from idle to
wait-for-tunnel
*Mar 30 19:28:34.551 UTC: Tnl/Sn51926/62398 L2TP: Create session
*Mar 30 19:28:34.551 UTC: Tnl51926 L2TP: SM State idle
*Mar 30 19:28:34.551 UTC: Tnl51926 L2TP: O SCCRQ
*Mar 30 19:28:34.551 UTC: Tnl51926 L2TP: Control channel retransmit delay set to
1 seconds
*Mar 30 19:28:34.551 UTC: Tnl51926 L2TP: Tunnel state change from idle to
wait-ctl-reply
*Mar 30 19:28:34.551 UTC: Tnl51926 L2TP: SM State wait-ctl-reply
*Mar 30 19:28:34.599 UTC: Tnl51926 L2TP: I SCCRP from Frankfurt_LCCE
*Mar 30 19:28:34.599 UTC: Tnl51926 L2TP: Got a challenge from remote peer,
Frankfurt_LCCE
*Mar 30 19:28:34.599 UTC: Tnl51926 L2TP: Got a response from remote peer,
Frankfurt_LCCE
*Mar 30 19:28:34.603 UTC: Tnl51926 L2TP: Tunnel auth failed for Frankfurt_LCCE
*Mar 30 19:28:34.603 UTC: Tnl51926 L2TP: Expected
AA 00 3F A4 76 8A 43 7B 5F CC 28 D1 39 01 B6 FD
*Mar 30 19:28:34.603 UTC: Tnl51926 L2TP: Got
C1 DD 86 6C F7 27 56 AA 71 20 6C 58 9B 7A 9E 6A
*Mar 30 19:28:34.603 UTC: Tnl51926 L2TP: O StopCCN to Frankfurt_LCCE tnlid 51784
*Mar 30 19:28:34.603 UTC: Tnl51926 L2TP: Control channel retransmit delay set to
1 seconds
*Mar 30 19:28:34.603 UTC: Tnl51926 L2TP: Tunnel state change from wait-ctl-reply to
shutting-down
*Mar 30 19:28:34.603 UTC: Tnl/Sn51926/62398 L2TP: Destroying session
*Mar 30 19:28:34.603 UTC: L2X: Sending L2TUN message <Connect Fail>
*Mar 30 19:28:34.603 UTC: Tnl/Sn51926/62398 L2TP: Session state change from
wait-for-tunnel to idle
London_LCCE#
CH01i.book Page 398 Friday, April 30, 2004 8:58 AM
Troubleshooting L2TPv3 399
Things are looking good, but then in highlighted line 5, London_LCCE reports that
authentication has failed. The reason for the authentication failure is shown in highlighted lines
6 and 7. Highlighted line 6 shows the authentication response (hash) that London_LCCE
expected from Frankfurt_LCCE. The actual response is shown in highlighted line 7. As you can
see, they are different, and so authentication fails.
Finally, in highlighted line 8, London_LCCE sends a StopCCN to Frankfurt_LCCE to signal
control connection teardown. The authentication failure indicates that the shared password is
inconsistent between London_LCCE and Frankfurt_LCCE. This is corrected in Example 5-28.
Once the password has been recongured on London_LCCE and Frankfurt_LCCE, control
connection establishment is successful. This is veried using the show l2tun tunnel command,
as shown in Example 5-29.
The highlighted line shows that a control connection has been successfully established to
Frankfurt_LCCE.
Note that if L2TPv3 authentication is congured on the local LCCE but not on the remote
LCCE, no response (SCCRP) to the local LCCEs SCCRQ will be received. Always ensure that
L2TPv3 authentication is consistently congured on peer LCCEs.
Example 5-28 Reconfiguration of Authentication Passwords on London_LCCE and Frankfurt_LCCE
! On London_LCCE:
London_LCCE#conf t
Enter configuration commands, one per line. End with CNTL/Z.
London_LCCE(config)#l2tp-class FrankfurtV3Class
London_LCCE(config-l2tp-class)#password cisco
London_LCCE(config-l2tp-class)#exit
London_LCCE#
! On Frankfurt_LCCE:
Frankfurt_LCCE#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Frankfurt_LCCE(config)#l2tp-class LondonVC3Class
Frankfurt_LCCE(config-l2tp-class)#password cisco
Frankfurt_LCCE(config-l2tp-class)#exit
Frankfurt_LCCE#
Example 5-29 Control Connection Establishment Succeeds
London_LCCE#show l2tun tunnel
Tunnel Information Total tunnels 1 sessions 1
LocID RemID Remote Name State Remote Address Port Sessions L2TPclass
36452 1742 Frankfurt_LCC est 10.1.1.2 0 1 FrankfurtV3Clas
London_LCCE#
CH01i.book Page 399 Friday, April 30, 2004 8:58 AM
400 Chapter 5: Troubleshooting L2TPv3 Based VPNs
Troubleshooting L2TPv3 Dynamic Session Establishment
Once the control connection has been established, session setup can begin. If session setup fails,
pseudowire connectivity will not be established.
Figure 5-21 shows L2TPv3 session setup.
Figure 5-21 L2TPv3 Session Setup
Before beginning to troubleshoot L2TPv3 session establishment failure, it is important to
examine a successful session establishment sequence.
Use the debug vpdn l2x-events command to examine the L2TPv3 session establishment
sequence as demonstrated in Example 5-30. Note that only the relevant portion of the output is
shown.
In highlighted line 1, session establishment begins with London_LCCE sending an ICRQ
message to Frankfurt_LCCE. An ICRP is then received from Frankfurt_LCCE. This message
indicates that session establishment should proceed. Note that the ICRP message is not shown
in Example 5-30.
Example 5-30 Successful L2TPv3 Session Establishment
London_LCCE#debug vpdn l2x-events
L2X protocol events debugging is on
*Mar 30 18:41:08.803 UTC: Tnl/Sn26577/62344 L2TP: O ICRQ to Frankfurt_LCCE 63650/0
*Mar 30 18:41:08.803 UTC: Tnl/Sn26577/62344 L2TP: Session state change from
wait-for-tunnel to wait-reply
*Mar 30 18:41:08.847 UTC: Tnl/Sn26577/62344 L2TP: O ICCN to Frankfurt_LCCE 63650/43444
*Mar 30 18:41:08.847 UTC: Tnl26577 L2TP: Control channel retransmit delay set to
1 seconds
*Mar 30 18:41:08.847 UTC: Tnl/Sn26577/62344 L2TP: Session state change from wait-reply
to established
*Mar 30 18:41:08.847 UTC: L2X: Sending L2TUN message <Connect OK>
*Mar 30 18:41:08.847 UTC: L2X: l2tun session [1646198216], event [server response],
old state [open], new state [open]
*Mar 30 18:41:09.847 UTC: Tnl26577 L2TP: Control channel retransmit delay set to
1 seconds
London_LCCE#
2. Control Connection Established
3. Session Established
London_LCCE / PE
(10.1.1.1) mjlnet_CE1 mjlnet_CE2
IP Backbone
1. Attachment
Circuit Becomes
Active
Frankfurt_LCCE / PE
(10.1.1.2)
CH01i.book Page 400 Friday, April 30, 2004 8:58 AM
Troubleshooting L2TPv3 401
Session establishment is completed in highlighted line 2, when London_LCCE sends a ICCN
message to Frankfurt_LCCE. In highlighted line 3, the session state changes to established
the session is up.
Successful L2TPv3 session establishment can be veried using the show l2tun session
command, as shown in Example 5-31.
Highlighted line 1 shows that two sessions have been established (as well as one control
connection). Highlighted lines 2 and 3 show the local and remote session IDs, control
connection ID, VCID, interface, and state associated with the two L2TPv3 sessions.
L2TPv3 session setup can fail for a number of reasons, including the following:
The attachment circuit is inactive (down) on the peer LCCE.
The peer LCCEs IP address is miscongured (with the xconnect command).
Peer LCCE VCIDs are mismatched.
Peer LCCE payload types are asymmetric.
Check that the attachment circuit is in an up/up (active) state on both of the peer LCCEs, using
the show ip interface [interface_name] command.
The other issues in the preceding list are examined in the sections that follow.
Peer LCCEs IP Address Is Miscongured (with the xconnect Command)
If the peer LCCEs IP address is miscongured, session setup will fail. Use the debug vpdn
l2x-events command to troubleshoot this issue, as shown in Example 5-32. Note that only the
relevant portion of the output is shown.
Example 5-31 Successful L2TPv3 Session Establishment
London_LCCE#show l2tun session
Session Information Total tunnels 1 sessions 2
LocID RemID TunID Username, Intf/ State
Vcid, Circuit
24058 52352 33028 120, Fa1/0.1:10 est
24059 52353 33028 121, Se4/1:60 est
London_LCCE#
Example 5-32 L2TPv3 Session Fails
London_LCCE#debug vpdn l2x-events
L2X protocol events debugging is on
London_LCCE#
*Mar 31 11:45:52.259 UTC: L2X: l2tun session [1646198152], event [client request], old
state [open], new state [open]
*Mar 31 11:45:52.259 UTC: L2X: L2TP: Received L2TUN message <Connect>
*Mar 31 11:45:52.259 UTC: Tnl/Sn51874/32218 L2TP: Session state change from idle to
wait-for-tunnel
*Mar 31 11:45:52.259 UTC: Tnl/Sn51874/32218 L2TP: Create session
CH01i.book Page 401 Friday, April 30, 2004 8:58 AM
402 Chapter 5: Troubleshooting L2TPv3 Based VPNs
Highlighted line 1 shows London_LCCE sending an ICRQ message to Frankfurt_LCCE. Then
in highlighted line 2, a CDN message is received. This signals session teardown. Session
establishment has failed.
The peer IP addresses used for this pseudowire are then veried using the show running-cong
command on London_LCCE and Frankfurt_LCCE, as shown in Example 5-33. Note that only
the relevant portion of the output is shown.
*Mar 31 11:45:52.259 UTC: Tnl/Sn51874/32218 L2TP: O ICRQ to Frankfurt_LCCE 29622/0
*Mar 31 11:45:52.259 UTC: Tnl51874 L2TP: Control channel retransmit delay set to
1 seconds
*Mar 31 11:45:52.259 UTC: Tnl/Sn51874/32218 L2TP: Session state change from
wait-for-tunnel to wait-reply
*Mar 31 11:45:52.287 UTC: Tnl/Sn51874/32218 L2TP: I CDN from Frankfurt_LCCE tnl 29622,
cl 0
*Mar 31 11:45:52.287 UTC: Tnl/Sn51874/32218 L2TP: Destroying session
*Mar 31 11:45:52.287 UTC: L2X: Sending L2TUN message <Connect Fail>
*Mar 31 11:45:52.287 UTC: Tnl/Sn51874/32218 L2TP: Session state change from wait-reply
to idle
*Mar 31 11:45:52.287 UTC: L2X: l2tun session [1646198152], event [server response],
old state [open], new state [open]
*Mar 31 11:45:52.287 UTC: L2X: l2tun session [1646198152], event [client free], old
state [open], new state [open]
London_LCCE#
Example 5-33 Verifying Peer IP Address for the Pseudowire
! On London_LCCE:
London_LCCE#show running-config
Building configuration...
!
interface FastEthernet1/0
no ip address
no ip directed-broadcast
!
interface FastEthernet1/0.1
encapsulation dot1Q 10
no ip directed-broadcast
no cdp enable
xconnect 10.1.1.2 120 pw-class FrankfurtPW
!
! On Frankfurt_LCCE:
Frankfurt_LCCE#show running-config
Building configuration...
!
interface FastEthernet0/0
no ip address
no ip directed-broadcast
!
Example 5-32 L2TPv3 Session Fails (Continued)
CH01i.book Page 402 Friday, April 30, 2004 8:58 AM
Troubleshooting L2TPv3 403
In highlighted line 1, you can see that the peer IP address congured for the pseudowire on
London_LCCE is 10.1.1.2. This address is correctly congured.
Then in highlighted line 2, you can see that the peer IP address congured on Frankfurt_LCCE
is 10.1.1.4. This is incorrectit should be 10.1.1.1.
The peer IP address is then recongured on Frankfurt_LCCE, as shown in Example 5-34.
As the highlighted line indicates, the peer IP address is recongured to be 10.1.1.1. Once the
peer IP address has been recongured, session establishment succeeds.
Successful session establishment is veried using the show l2tun session command, as shown
in Example 5-35.
The highlighted line shows that the session has been successfully established.
Peer LCCE VCIDs Are Mismatched
If VCIDs on peer LCCEs are mismatched, then L2TPv3 session setup will fail.
Use the debug vpdn l2x-events command to troubleshoot this issue, as demonstrated in
Example 5-36. Note that only the relevant portion of the output is shown.
interface FastEthernet0/0.1
encapsulation dot1Q 10
no ip directed-broadcast
no cdp enable
xconnect 10.1.1.4 120 pw-class LondonPW
!
Example 5-34 Reconfiguration of the Peer IP Address on Frankfurt_LCCE
Frankfurt_LCCE#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Frankfurt_LCCE(config)#interface FastEthernet0/0.1
Frankfurt_LCCE(config-subif)#xconnect 10.1.1.1 120 pw-class LondonPW
Frankfurt_LCCE(config-subif)#exit
Frankfurt_LCCE#
Example 5-35 L2TPv3 Session Establishment Succeeds
London_LCCE#show l2tun session
Session Information Total tunnels 1 sessions 2
LocID RemID TunID Username, Intf/ State
Vcid, Circuit
32180 28768 51874 121, Se4/1:60 est

32235 28846 51874 120, Fa1/0.1:10 est

London_LCCE#
Example 5-33 Verifying Peer IP Address for the Pseudowire (Continued)
CH01i.book Page 403 Friday, April 30, 2004 8:58 AM
404 Chapter 5: Troubleshooting L2TPv3 Based VPNs
In highlighted line 1, an ICRQ message is received from Frankfurt_LCCE. This message is
used to initiate session establishment.
Then in highlighted line 2, London_LCCE reports that VCID 125 contained within the ICRQ
message (in a Remote End ID AVPsee Table 5-8) is not consistent with any pseudowire VCID
congured locally. London_LCCE now signals session teardown by sending a CDN message
in highlighted line 3. Session establishment has failed.
The next step is to examine the pseudowire conguration on London_LCCE and
Frankfurt_LCCE using the show running-cong command, as shown in Example 5-37.
Example 5-36 Session Establishment Fails
London_LCCE#debug vpdn l2x-events
L2X protocol events debugging is on
London_LCCE#
*Mar 31 15:45:21.567 UTC: Tnl7185 L2TP: I ICRQ from Frankfurt_LCCE tnl 41528
*Mar 31 15:45:21.567 UTC: Tnl/Sn7185/43552 L2TP: Session state change from idle to
wait-connect
*Mar 31 15:45:21.567 UTC: Tnl/Sn7185/43552 L2TP: Accepted ICRQ, new session created
*Mar 31 15:45:21.567 UTC: Tnl/Sn7185/43552 L2TP: Xconnect VC ID 125 not provisioned
*Mar 31 15:45:21.567 UTC: Tnl/Sn7185/43552 L2TP: O CDN to Frankfurt_LCCE 41528/61379
*Mar 31 15:45:21.567 UTC: Tnl7185 L2TP: Control channel retransmit delay set to
1 seconds
*Mar 31 15:45:21.567 UTC: Tnl/Sn7185/43552 L2TP: Destroying session
*Mar 31 15:45:21.567 UTC: Tnl/Sn7185/43552 L2TP: Session state change from
wait-connect to idle
London_LCCE#
Example 5-37 Pseudowire Configuration on London_LCCE and Frankfurt_LCCE
! On London_LCCE:
London_LCCE#show running-config
Building configuration...
!
interface FastEthernet1/0
no ip address
no ip directed-broadcast
!
interface FastEthernet1/0.1
encapsulation dot1Q 10
no ip directed-broadcast
no cdp enable
xconnect 10.1.1.2 120 pw-class FrankfurtPW
!
! On Frankfurt_LCCE:
Frankfurt_LCCE#show running-config
Building configuration...
Current configuration : 2217 bytes
!
!
CH01i.book Page 404 Friday, April 30, 2004 8:58 AM
Troubleshooting L2TPv3 405
Highlighted line 1 indicates that the VCID congured for the pseudowire on London_LCCE is
120, whereas in highlighted line 2 the VCID on Frankfurt_LCCE is 125clearly a mismatch.
The VCID is then recongured on Frankfurt_LCCE, as shown in Example 5-38.
In the highlighted line, the VCID is recongured as 120.
Once the VCID has been recongured, L2TPv3 session establishment is successful. This is
veried using the show l2tun session command, as shown in Example 5-39.
The highlighted line indicates that a session has been successfully established for VCID 120.
Asymmetric Payload Types
If L2TPv3 payload types are incompatible, session establishment will fail.
You can use the debug vpdn l2x-events command to troubleshoot this issue, as shown in
Example 5-40. Note that only the relevant portion of the output is shown.
interface FastEthernet0/0
no ip address
no ip directed-broadcast
!
interface FastEthernet0/0.1
encapsulation dot1Q 10
no ip directed-broadcast
no cdp enable
xconnect 10.1.1.1 125 pw-class LondonPW
!
Example 5-38 Reconfiguration of the VCID on Frankfurt_LCCE
Frankfurt_LCCE#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Frankfurt_LCCE(config)#interface FastEthernet0/0.1
Frankfurt_LCCE(config-subif)#xconnect 10.1.1.1 120 pw-class LondonPW
Frankfurt_LCCE(config-subif)#end
Frankfurt_LCCE#
Example 5-39 Successful L2TPv3 Session Establishment
London_LCCE#show l2tun session
Session Information Total tunnels 1 sessions 2
LocID RemID TunID Username, Intf/ State
Vcid, Circuit
43517 61344 7185 121, Se4/1:60 est

43562 61389 7185 120, Fa1/0.1:10 est

London_LCCE#
Example 5-37 Pseudowire Configuration on London_LCCE and Frankfurt_LCCE (Continued)
CH01i.book Page 405 Friday, April 30, 2004 8:58 AM
406 Chapter 5: Troubleshooting L2TPv3 Based VPNs
In highlighted line 1, London_LCCE receives an ICRQ message initiating session
establishment, and in highlighted line 2, London_LCCE reports that this has been accepted.
All seems well, and then in highlight line 3, London_LCCE sends a CDN message to
Frankfurt_LCCE signaling session teardown. Session establishment has failed.
To nd out the reason for session establishment failure, you can use the debug vpdn l2x-errors
command, as demonstrated in Example 5-41.
As you can see, London_LCCE is reporting that asymmetric payload types are not supported.
This indicates a compatibility issue between attachment circuit types.
The conguration of the attachment circuits is then examined using the show running-cong
command on London_LCCE and Frankfurt_LCCE, as shown in Example 5-42. Note that only
the relevant portion of the output is shown.
Highlighted lines 1 to 4 show that interface serial 4/0 on London_LCCE is congured for
DLCI-to-DLCI switching.
Example 5-40 L2TPv3 Session Establishment Fails
London_LCCE#debug vpdn l2x-events
L2X protocol events debugging is on
London_LCCE#
*Apr 1 15:58:15.763 UTC: Tnl57072 L2TP: I ICRQ from Frankfurt_LCCE tnl 45648
*Apr 1 15:58:15.763 UTC: Tnl/Sn57072/46769 L2TP: Session state change from idle to
wait-connect
*Apr 1 15:58:15.763 UTC: Tnl/Sn57072/46769 L2TP: Accepted ICRQ, new session created
*Apr 1 15:58:15.763 UTC: Tnl/Sn57072/46769 L2TP: Session state change from
wait-connect to wait-for-service-selection-icrq
*Apr 1 15:58:15.763 UTC: Tnl/Sn57072/46769 L2TP: Started service selection, peer IP
address 10.1.1.2, VCID 121
*Apr 1 15:58:15.763 UTC: Tnl/Sn57072/46769 L2TP: O CDN to Frankfurt_LCCE 45648/34007
*Apr 1 15:58:15.763 UTC: Tnl57072 L2TP: Control channel retransmit delay set to
1 seconds
*Apr 1 15:58:15.763 UTC: Tnl/Sn57072/46769 L2TP: Destroying session
*Apr 1 15:58:15.767 UTC: Tnl/Sn57072/46769 L2TP: Session state change from
wait-for-service-selection-icrq to idle
London_LCCE#
Example 5-41 Asymmetric Payload Types
London_LCCE#debug vpdn l2x-errors
L2X protocol errors debugging is on
London_LCCE#
*Apr 1 15:59:06.091 UTC: Tnl/Sn57072/46779 L2TP: Asymmetric payload types are not
supported
*Apr 1 15:59:07.231 UTC: Tnl/Sn57072/46780 L2TP: Asymmetric payload types are not
supported
*Apr 1 15:59:09.263 UTC: Tnl/Sn57072/46781 L2TP: Asymmetric payload types are not
supported
London_LCCE#
CH01i.book Page 406 Friday, April 30, 2004 8:58 AM
Troubleshooting L2TPv3 407
Highlighted line 5, however, shows that the corresponding interface on Frankfurt_LCCE (serial
2/1) is congured for Frame Relay trunking. In fact, interface serial 2/1 on Frankfurt should be
congured for DLCI-to-DLCI switching.
Frankfurt_LCCE is then recongured, as shown in Example 5-43.
Example 5-42 Configuration of Attachment Circuits on London_LCCE and Frankfurt_LCCE
! On London_LCCE:
London_LCCE#show running-config
Building configuration...
!
interface Serial4/1
no ip address
no ip redirects
no ip directed-broadcast
no ip proxy-arp
encapsulation frame-relay
frame-relay intf-type dce
!
connect PVCtoFrank Serial4/1 60 l2transport
xconnect 10.1.1.2 121 pw-class FrankfurtPW
!
!
! On Frankfurt_LCCE:
Frankfurt_LCCE#show running-config
Building configuration...
Current configuration : 2109 bytes
!
!
interface Serial2/1
no ip address
no ip redirects
no ip directed-broadcast
no ip proxy-arp
no cdp enable
xconnect 10.1.1.1 121 pw-class LondonPW
!
Example 5-43 Reconfiguration of Frankfurt_LCCE
Frankfurt_LCCE#conf t
Enter configuration commands, one per line. End with CNTL/Z.
Frankfurt_LCCE(config)#frame-relay switching
Frankfurt_LCCE(config)#interface serial 2/1
Frankfurt_LCCE(config-if)#encapsulation frame-relay
Frankfurt_LCCE(config-if)#frame-relay intf-type dce
Frankfurt_LCCE(config-if)#exit
Frankfurt_LCCE(config)#connect PVCtoLondon serial 2/1 70 l2transport
Frankfurt_LCCE(config-fr-pw-switching)#xconnect 10.1.1.1 121 pw-class LondonPW
Frankfurt_LCCE(config-fr-pw-switching)#exit
Frankfurt_LCCE#
CH01i.book Page 407 Friday, April 30, 2004 8:58 AM
408 Chapter 5: Troubleshooting L2TPv3 Based VPNs
The highlighted lines indicate that interface serial 2/1 on Frankfurt_LCCE is recongured for
DLCI-to-DLCI switching.
Once Frankfurt_LCCE has been recongured, L2TPv3 session establishment succeeds.
L2TPv3 session establishment is veried using the show l2tun session command, as shown in
Example 5-44.
The highlighted line shows that session establishment has succeeded.
NOTE Cisco supports interworking between certain different Layer 2 circuit types (such as Frame
Relay to Ethernet VLAN) in Cisco IOS Software Release 12.0(26)S and later. This feature is
called L2VPN Interworking. See Cisco.com for more details.
Troubleshooting L2TPv3 with Static Session Conguration
If L2TPv3 sessions are statically congured, troubleshooting consists of verifying peer LCCE
conguration. Always ensure that peer IP addresses are correctly congured and that session
IDs and cookies are mirror images on peer routers.
In this scenario, trafc from CE router mjlnet_CE1 is not arriving at mjlnet_CE2 (see Figure
5-19). This is veried using ping, as shown in Example 5-45.
As you can see, there is no connectivity between the CE routers.
The next step is to verify L2TPv3 conguration on London_LCCE and Frankfurt_LCCE, as
shown in Example 5-46. Note that only the relevant portion of the output is shown.
Example 5-44 L2TPv3 Session Establishment Succeeds
London_LCCE#show l2tun session
Session Information Total tunnels 1 sessions 2
LocID RemID TunID Username, Intf/ State
Vcid, Circuit
46661 33899 57072 120, Fa1/0.1:10 est

46831 34069 57072 121, Se4/1:60 est
London_LCCE#
Example 5-45 No CE Router to CE Router Connectivity
mjlnet_CE1#ping 192.168.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
mjlnet_CE1#
CH01i.book Page 408 Friday, April 30, 2004 8:58 AM
Troubleshooting L2TPv3 409
A close comparison of the conguration on the two PE routers reveals that the peer IP addresses
and the L2TPv3 cookies are correctly congured, but that the L2TPv3 (session) IDs are not.
Remember that the session IDs congured on peer routers must be a mirror image of each other.
If you look at the highlighted lines in Example 5-46, you will notice that the session IDs on
London_PE and Frankfurt_PE are not mirror images. In fact, the local session ID on
London_PE is miscongured. It should be 1002, but it is congured as 1003.
The local session ID on London_PE is then recongured, as shown in Example 5-47.
Once London_PE has been recongured, connectivity is established between mjlnet_CE1 and
mjlnet_CE2, as shown in Example 5-48.
Example 5-46 L2TPv3 Configuration on London_PE and Frankfurt_PE
! On London_PE:
London_LCCE#show running-config
Building configuration...
!
connect PVCtoFrankfurt Serial4/1 60 l2transport
xconnect 10.1.1.2 123 encapsulation l2tpv3 manual pw-class FrankfurtPW
l2tp id 1003 2001
l2tp cookie local 4 102
l2tp cookie remote 4 201
!
!
On Frankfurt_PE:
Frankfurt_LCCE#show running-config
Building configuration...
!
connect PVCtoLondon Serial2/1 70 l2transport
xconnect 10.1.1.1 123 encapsulation l2tpv3 manual pw-class LondonPW
l2tp id 2001 1002
l2tp cookie local 4 201
l2tp cookie remote 4 102
!
!
Example 5-47 Reconfiguration of the Local Session ID on London_PE
London_LCCE#conf t
Enter configuration commands, one per line. End with CNTL/Z.
London_LCCE(config)#connect PVCtoFrankfurt Serial4/1 60 l2transport
London_LCCE(config-fr-pw-switching)#xconnect 10.1.1.2 123 encapsulation l2tpv3 manual
pw-class FrankfurtPW
London_LCCE(config-xconn)#l2tp id 1002 2001
London_LCCE(config-xconn)#end
London_LCCE#
CH01i.book Page 409 Friday, April 30, 2004 8:58 AM
410 Chapter 5: Troubleshooting L2TPv3 Based VPNs
Other Commands
This section briey covers some other commands that might be useful when troubleshooting
L2TPv3.
show l2tun tunnel all
The show l2tun tunnel all command can be used to display information about the L2TPv3
control connection.
Example 5-49 shows output from the show l2tun tunnel all command.
Example 5-48 Connectivity Is Established Between mjlnet_CE1 and mjlnet_CE2
mjlnet_CE1#ping 192.168.1.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 40/43/44 ms
mjlnet_CE2#
Example 5-49 show l2tun tunnel all Command Output
London_LCCE#show l2tun tunnel all
Tunnel Information Total tunnels 1 sessions 1
Tunnel id 61973 is up, remote id is 39248, 1 active sessions
Tunnel state is established, time since change 00:06:01
Tunnel transport is IP (115)
Remote tunnel name is Frankfurt_LCCE
Internet Address 10.1.1.2, port 0
Local tunnel name is London_LCCE
Internet Address 10.1.1.1, port 0
Tunnel domain is
VPDN group for tunnel is -
L2TP class for tunnel is FrankfurtV3Class
126 packets sent, 17 received
5432 bytes sent, 924 received
Control Ns 126, Nr 82
Local RWS 3000 (default), Remote RWS 3000 (max)
Tunnel PMTU checking disabled
Retransmission time 1, max 1 seconds
Unsent queuesize 0, max 0
Resend queuesize 0, max 2
Total resends 0, ZLB ACKs sent 79
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
London_LCCE#
CH01i.book Page 410 Friday, April 30, 2004 8:58 AM
Other Commands 411
Highlighted line 1 shows that there is one tunnel (control connection) and one session
established.
In highlighted line 2, you can see that there is a control connection with local ID 61973 and
remote ID 39248, together with one associated session. Highlighted lines 3 to 20 show details
of this control connection.
Highlighted line 3 shows that the control connection is established and that the time since the
last state change is 6 minutes and 1 second. Highlighted line 4 shows that the control connection
is using IP protocol 115. Highlighted lines 5 to 8 show the remote and local LCCE names and
IP addresses. The remote LCCE name and IP address are Frankfurt_LCCE and 10.1.1.2,
respectively. The local LCCE name and IP address are London_LCCE and 10.1.1.1,
respectively.
The L2TP class is shown in highlighted line 9 (FrankfurtV3Class). The number of packets and
bytes sent and received are shown in highlighted lines 10 and 11. Highlighted line 12 shows the
Next Sent (Ns) and Next Receive (Nr) values.
The local and remote receive window sizes (RWS) are shown in highlighted line 13. The receive
window size can be modied using the receive-window command (within the L2TP class).
Note that the local receive window size is communicated to the remote peer in a Receive
Window Size AVP during control connection setup (see Table 5-7).
In highlighted line 14, you can see that Path MTU (PMTU) checking is disabled. This can be
enabled using the ip pmtu command (within the pseudowire class). The retransmission time
for control messages is shown in highlighted line 15 (1 second). This can be modied using the
retransmit command (within the L2TP class). Unsent and resend queue sizes are shown in
highlighted lines 16 and 17.
The total number of resends (retransmissions) and ZLB Acks sent are shown in highlighted line
18. Highlighted line 19 shows the distribution of retransmission times. Finally, highlighted line
20 shows the number of sessions disconnected because of a lack of resources.
show l2tun session all
This command displays information about L2TPv3 sessions.
Example 5-50 shows output from the show l2tun session all command.
Example 5-50 show l2tun session all Command Output
London_LCCE#show l2tun session all
Session Information Total tunnels 1 sessions 1
Session id 22529 is up, tunnel id 61973
Call serial number is 4093900000
Remote tunnel name is Frankfurt_LCCE
Internet address is 10.1.1.2
Session is L2TP signalled
Session state is established, time since change 00:05:40
CH01i.book Page 411 Friday, April 30, 2004 8:58 AM
412 Chapter 5: Troubleshooting L2TPv3 Based VPNs
Highlighted line 1 shows that there is one tunnel (control connection) and one session.
Highlighted line 2 shows the session ID (22529) and the control connection ID (tunnel ID,
61973). Highlighted lines 3 to 23 show details about the session.
The call serial number is shown in highlighted line 3. The name of the remote LCCE
(Frankfurt_LCCE), toge