- 1. Table of Contents 1Troubleshooting Virtual Private Networks
........................................................................................................................
2Table of Contents
.................................................................................................................................................................................
4Copyright
.....................................................................................................................................................................................................
7About the Author
...................................................................................................................................................................................
8About the Technical Reviewers
....................................................................................................................................................
9Acknowledgments
................................................................................................................................................................................
10Icons Used in This Book
..............................................................................................................................................................
11Command Syntax Conventions
..............................................................................................................................................
12Introduction
.............................................................................................................................................................................................
13Motivation for the Book
.................................................................................................................................................................
14Audience
..............................................................................................................................................................................................
15Organization
......................................................................................................................................................................................
17Chapter 1. Basic Troubleshooting Methodology
.....................................................................................................
18Preparatory Steps: Baselining Your Network
.......................................................................................................................
19What to Do When Problems Occur
.........................................................................................................................................
20Open Systems Interconnection Model
...................................................................................................................................
21End-to-End, Bottom-Up (or Top-Down) Troubleshooting
................................................................................................
23Troubleshooting Tools
....................................................................................................................................................................
25Summary
.............................................................................................................................................................................................
26Chapter 2. Troubleshooting Layer Two Forwarding Protocol VPNs
........................................................
27Technical Overview of L2F
..........................................................................................................................................................
44Configuring L2F
................................................................................................................................................................................
55Troubleshooting L2F
.......................................................................................................................................................................
94Case Studies
.....................................................................................................................................................................................
111Additional Commands for Troubleshooting
........................................................................................................................
115Error Messages
..............................................................................................................................................................................
118show and debug Command Summary
................................................................................................................................
119Review Questions
.........................................................................................................................................................................
120Troubleshooting Practice Labs
...............................................................................................................................................
123Chapter 3. Troubleshooting Point-to-Point Tunneling Protocol
VPNs ................................................ 125Technical
Overview of PPTP
..................................................................................................................................................
140Configuring PPTP
........................................................................................................................................................................
145Troubleshooting PPTP
...............................................................................................................................................................
170Case Studies
..................................................................................................................................................................................
175Additional Troubleshooting Commands
..............................................................................................................................
180show and debug Command Summary
................................................................................................................................
181Review Questions
........................................................................................................................................................................
182Chapter 4. Troubleshooting the Layer 2 Tunneling Protocol
Version 2 VPNs ............................. 185L2TPv2 Technical
Overview
....................................................................................................................................................
251Case Studies
..................................................................................................................................................................................
272Additional L2TP Troubleshooting Commands
..................................................................................................................
277Error Messages
.............................................................................................................................................................................
280%VPDN-6-DOWN
........................................................................................................................................................................
281show and debug Command Summary
................................................................................................................................
282Review Questions
........................................................................................................................................................................
283L2TP Troubleshooting Practice Labs
...................................................................................................................................
286Chapter 5. Troubleshooting L2TPv3 Based VPNs
.............................................................................................
288Technical Overview of L2TPv3
..............................................................................................................................................
303Configuring L2TPv3
....................................................................................................................................................................
313Troubleshooting L2TPv3
...........................................................................................................................................................
2. 329Other Commands
.........................................................................................................................................................................
335Command Summary
...................................................................................................................................................................
336Review Questions
........................................................................................................................................................................
337Chapter 6. Troubleshooting Multiprotocol Label Switching Layer 3
VPNs ..................................... 339Technical Overview
.....................................................................................................................................................................
356Configuring MPLS VPNs
...........................................................................................................................................................
368Configuring MVPNs
.....................................................................................................................................................................
372Configuring TE Tunnels to Carry MPLS VPN Traffic
....................................................................................................
377Troubleshooting MPLS VPNs
..................................................................................................................................................
429Case Studies
..................................................................................................................................................................................
447Additional Troubleshooting Commands
..............................................................................................................................
454show and debug Command Summary
................................................................................................................................
457Review Questions
........................................................................................................................................................................
458MPLS VPN Troubleshooting Practice Labs
.......................................................................................................................
461Chapter 7. Troubleshooting Any Transport over MPLS Based VPNs
................................................. 462Technical
Overview of AToM
...................................................................................................................................................
470Configuring AToM
.........................................................................................................................................................................
484Troubleshooting AToM
................................................................................................................................................................
516Other AToM Troubleshooting Commands
..........................................................................................................................
521Troubleshooting AToM: Command Summary
..................................................................................................................
523Review Questions
........................................................................................................................................................................
524Chapter 8. Troubleshooting IPSec VPNs
..................................................................................................................
525Technical Overview of IPSec
..................................................................................................................................................
536Configuring IPSec VPNs
...........................................................................................................................................................
553Troubleshooting IPSec VPNs
..................................................................................................................................................
586Case Studies
..................................................................................................................................................................................
595Additional Troubleshooting Commands
..............................................................................................................................
599show and debug Command Summary
................................................................................................................................
600Review Questions
........................................................................................................................................................................
601Practice Labs
..................................................................................................................................................................................
604Appendix A. Review Questions and Answers
.........................................................................................................
605Chapter 2 Review Questions & Answers
............................................................................................................................
606Chapter 3 Review Questions & Answers
............................................................................................................................
608Chapter 4 Review Questions & Answers
............................................................................................................................
609Chapter 5 Review Questions & Answers
............................................................................................................................
610Chapter 6 Review Questions & Answers
............................................................................................................................
611Chapter 7 Review Questions & Answers
............................................................................................................................
612Chapter 8 Review Questions & Answers
............................................................................................................................
613Appendix B. Lab Instructions and Solutions
............................................................................................................
614Setting Up Your Routers and Loading the Configuration Files
.................................................................................
618Chapter 2: L2F Troubleshooting Lab Solutions
...............................................................................................................
619Chapter 4: L2TPv2 Troubleshooting Lab Solutions
.......................................................................................................
620Chapter 6: MPLS Layer 3 VPN Troubleshooting Lab Solutions
...............................................................................
621Chapter 8: IPSec Troubleshooting Lab Solutions
...........................................................................................................
622Index
.........................................................................................................................................................................................................
623SYMBOL
...........................................................................................................................................................................................
624A
...........................................................................................................................................................................................................
627B
...........................................................................................................................................................................................................
628C
..........................................................................................................................................................................................................
632D
..........................................................................................................................................................................................................
635E
...........................................................................................................................................................................................................
637F
...........................................................................................................................................................................................................
638G
..........................................................................................................................................................................................................
639H
..........................................................................................................................................................................................................
3. 640I
............................................................................................................................................................................................................
642K
...........................................................................................................................................................................................................
643L
...........................................................................................................................................................................................................
645M
..........................................................................................................................................................................................................
648N
..........................................................................................................................................................................................................
649O
..........................................................................................................................................................................................................
650P
...........................................................................................................................................................................................................
653Q
..........................................................................................................................................................................................................
654R
..........................................................................................................................................................................................................
656S
...........................................................................................................................................................................................................
660T
...........................................................................................................................................................................................................
661U
..........................................................................................................................................................................................................
662V
...........................................................................................................................................................................................................
664W
.........................................................................................................................................................................................................
665Z
...........................................................................................................................................................................................................
4. Troubleshooting Virtual Private Networks By Mark Lewis
............................................... Publisher: Cisco
Press Pub Date: May 27, 2004 Print ISBN: 1-58705-104-4 Pages: 840
Table of Contents | Index Master advanced troubleshooting
techniques for IPSec, MPLS Layer-3, MPLS Layer-2 (AToM), L2TPv3,
L2TPv2, PPTP, and L2F VPNs Learn the step-by-step, end-to-end
methodology essential for troubleshooting virtual private networks
(VPNs) Gain the in-depth knowledge necessary for fast and efficient
troubleshooting of IPSec, MPLS Layer-3, MPLS Layer-2 (AToM),
L2TPv3, L2TPv2, PPTP, and L2F VPNs Master advanced troubleshooting
tools and techniques for all applicable VPN types Debug and fix
IPSec site-to-site and remote access VPN issues, such as IKE
(ISAKMP) phase 1 and phase 2 negotiation failure, ESP and AH
traffic drops, certificate enrollment failures, and maximum
transmission unit (MTU) problems Locate and resolve MPLS Layer-3
VPN problems, such as those involving route exchange and label
switched path (LSP) failure, MPLS VPN over traffic engineering
tunnels, and Multicast VPNs (MVPN) Discover solutions for issues in
AToM and L2TPv3-based Layer-2 VPNs, including pseudowire setup
failures, attachment circuit problems, and MTU issues Obtain
answers for L2TPv2, PPTP, and L2F control connection establishment,
session setup, PPP negotiation, and VPN performance issues Refer to
specially designed flowcharts to identify issues and find solutions
fast Consolidate VPN troubleshooting knowledge through bonus
hands-on labs Read and understand detailed analysis of all relevant
VPN show and debug command output Troubleshooting Virtual Private
Networks presents a systematic troubleshooting methodology for
network engineers, administrators, and architects tasked with
managing and deploying Cisco IOS VPNs. With eight self-contained
chapters designed to facilitate rapid and straightforward
troubleshooting, this book provides detailed information on
addressing all common and not-so-common issues with IPSec VPNs,
MPLS Layer-3 VPNs, Any Transport over MPLS (AToM)-based Layer-2
VPNs, L2TP Version 3 (L2TPv3)-based Layer-2 VPNs, L2TP Version 2
(L2TPv2) VPNs, PPTP VPNs, and L2F VPNs. This book not only shows
you how to correct problems but also how to avoid them in the first
place with expert VPN configuration guidance and optimization tips.
Each chapter in Troubleshooting Virtual Private Networks includes a
step-by-step, end-to-end troubleshooting approach to a different
VPN technology. In-depth technical discussions and configuration
reviews orient you to the VPN technology and get you ready to work.
To help you access the answers you need, you'll find flowcharts in
each chapter that provide a roadmap for rapid issue resolution.
Solutions to complex or unusual issues can be found in case studies
at the end of each chapter, along with review questions that test
your knowledge. Bonus troubleshooting labs are also included to
help you consolidate the skills learned throughout the book.
Whether you are looking to update or hone your skills,
Troubleshooting Virtual Private Networks is your first and last
reference for mastering advanced VPN troubleshooting. This book is
part of the Networking Technology Series from Cisco Press which
offers networking professionals valuable information for
constructing efficient networks, understanding new technologies,
and building successful careers. Troubleshooting Virtual Private
Networks 1 / 665 5. Troubleshooting Virtual Private Networks By
Mark Lewis ...............................................
Publisher: Cisco Press Pub Date: May 27, 2004 Print ISBN:
1-58705-104-4 Pages: 840 Table of Contents | Index Copyright About
the Author About the Technical Reviewers Acknowledgments Icons Used
in This Book Command Syntax Conventions Introduction Motivation for
the Book Audience Organization Chapter 1. Basic Troubleshooting
Methodology Preparatory Steps: Baselining Your Network What to Do
When Problems Occur Open Systems Interconnection Model End-to-End,
Bottom-Up (or Top-Down) Troubleshooting Troubleshooting Tools
Summary Chapter 2. Troubleshooting Layer Two Forwarding Protocol
VPNs Technical Overview of L2F Configuring L2F Troubleshooting L2F
Case Studies Additional Commands for Troubleshooting Error Messages
show and debug Command Summary Review Questions Troubleshooting
Practice Labs Chapter 3. Troubleshooting Point-to-Point Tunneling
Protocol VPNs Technical Overview of PPTP Configuring PPTP
Troubleshooting PPTP Case Studies Additional Troubleshooting
Commands show and debug Command Summary Review Questions Chapter 4.
Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs
L2TPv2 Technical Overview Case Studies Additional L2TP
Troubleshooting Commands Error Messages %VPDN-6-DOWN show and debug
Command Summary Review Questions L2TP Troubleshooting Practice Labs
Chapter 5. Troubleshooting L2TPv3 Based VPNs Technical Overview of
L2TPv3 Configuring L2TPv3 Troubleshooting Virtual Private Networks
2 / 665 6. Troubleshooting L2TPv3 Other Commands Command Summary
Review Questions Chapter 6. Troubleshooting Multiprotocol Label
Switching Layer 3 VPNs Technical Overview Configuring MPLS VPNs
Configuring MVPNs Configuring TE Tunnels to Carry MPLS VPN Traffic
Troubleshooting MPLS VPNs Case Studies Additional Troubleshooting
Commands show and debug Command Summary Review Questions MPLS VPN
Troubleshooting Practice Labs Chapter 7. Troubleshooting Any
Transport over MPLS Based VPNs Technical Overview of AToM
Configuring AToM Troubleshooting AToM Other AToM Troubleshooting
Commands Troubleshooting AToM: Command Summary Review Questions
Chapter 8. Troubleshooting IPSec VPNs Technical Overview of IPSec
Configuring IPSec VPNs Troubleshooting IPSec VPNs Case Studies
Additional Troubleshooting Commands show and debug Command Summary
Review Questions Practice Labs AppendixA. Review Questions and
Answers Chapter 2 Review Questions & Answers Chapter 3 Review
Questions & Answers Chapter 4 Review Questions & Answers
Chapter 5 Review Questions & Answers Chapter 6 Review Questions
& Answers Chapter 7 Review Questions & Answers Chapter 8
Review Questions & Answers Appendix B. Lab Instructions and
Solutions Setting Up Your Routers and Loading the Configuration
Files Chapter 2: L2F Troubleshooting Lab Solutions Chapter 4:
L2TPv2 Troubleshooting Lab Solutions Chapter 6: MPLS Layer 3 VPN
Troubleshooting Lab Solutions Chapter 8: IPSec Troubleshooting Lab
Solutions Index Troubleshooting Virtual Private Networks 3 / 665 7.
Copyright 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 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 fitness 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 professional 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 [email protected]. Please make sure to
include the book title and ISBN in your message. We greatly
appreciate your assistance. Corporate and Government Sales
Troubleshooting Virtual Private Networks 4 / 665 8. 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
[email protected] For sales outside the U.S. please
contact: International Sales [email protected] Credits
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, van Pepelnjak, Tim Sammut, Wen Zhang Team
Coordinator Tammi Barnett Book Designer Louisa Adair Cover Designer
Louisa Adair Composition Argosy Indexer Larry Sweazy Corporate
Headquarters Cisco Systems, Inc. 170 West Tasman Drive San Jose,
CA95134-1706 USA www.cisco.com Tel: 408 526-4000 800 553-NETS
(6387) Fax: 408 526-4100 European Headquarters Cisco Systems
International BV Haarlerbergpark Haarlerbergweg 3-19 1101 CH
Amsterdam Troubleshooting Virtual Private Networks 5 / 665 9. The
Netherlands www-europe.cisco.com Tel: 31 0 20 357 1000 Fax: 31 0 20
357 1100 Americas Headquarters Cisco Systems, Inc. 170 West Tasman
Drive San Jose, CA95134-1706 USA www.cisco.com Tel: 408 526-7660
Fax: 408 527-0883 Asia Pacific Headquarters Cisco Systems, Inc.
Capital Tower 168 Robinson Road #22-01 to #29-01 Singapore 068912
www.cisco.com Tel: +65 6317 7777 Fax: +65 6317 7799 Cisco Systems
has more than 200 offices in the following countries and regions.
Addresses, phone numbers, and fax numbers are listed on the
Cisco.com Web site at www.cisco.com/go/offices. Argentina Australia
Austria Belgium Brazil Bulgaria Canada Chile China PRC Colombia
Costa Rica Croatia Czech Republic Denmark Dubai, UAE Finland France
Germany Greece Hong Kong SAR Hungary India Indonesia Ireland Israel
Italy Japan Korea Luxembourg Malaysia Mexico The Netherlands New
Zealand Norway Peru Philippines Poland Portugal Puerto Rico Romania
Russia Saudi Arabia Scotland Singapore Slovakia Slovenia South
Africa Spain Sweden Switzerland Taiwan Thailand Turkey Ukraine
United Kingdom United States Venezuela Vietnam Zimbabwe Copyright
2003 Cisco Systems, Inc. All rights reserved. CCIP, CCSP, the Cisco
Arrow logo, the Cisco Powered Network mark, the Cisco Systems
Verified logo, Cisco Unity, Follow Me Browsing, FormShare, iQ Net
Readiness Scorecard, Networking Academy, and ScriptShare are
trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live,
Play, and Learn, The Fastest Way to Increase Your Internet
Quotient, and iQuick Study are service marks of Cisco Systems,
Inc.; and Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE, CCNA,
CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco
IOS, the Cisco IOS logo, Cisco Press, Cisco Systems, Cisco Systems
Capital, the Cisco Systems logo, Empowering the Internet
Generation, Enterprise/Solver, EtherChannel, EtherSwitch, Fast
Step, GigaStack, Internet Quotient, IOS, IP/TV, iQ Expertise, the
iQ logo, LightStream, MGX, MICA, the Networkers logo, Network
Registrar, Packet, PIX, Post-Routing, Pre-Routing, RateMUX,
Registrar, SlideCast, SMARTnet, Strata View Plus, Stratm,
SwitchProbe, TeleRouter, TransPath, and VCO are registered
trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S.
and certain other countries. All other trademarks mentioned in this
document or Web site are the property of their respective owners.
The use of the word partner does not imply a partnership
relationship between Cisco and any other company. (0303R) Printed
in the USA Troubleshooting Virtual Private Networks 6 / 665 10.
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 certified Cisco Systems instructor. Mark can
be contacted at [email protected]. Troubleshooting Virtual Private
Networks 7 / 665 11. About the Technical Reviewers Henry Benjamin,
CCIE No. 4695, holds three CCIE certifications (Routing and
Switching, ISP Dial, and Communications 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
member 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
firm in Australia. Robert Brown, CCIE No. 7309, is developer and
technical leader of Cisco Output Interpreter, a powerful online
troubleshooting 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 Specialist. 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
fulfills his fishing 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 Virginia
providing national and international security consulting and
training services. During the past fifteen years he has designed,
tested and certified VPN, firewall, intrusion detection, and
incident response solutions as well as ensuring customer compliance
with HIPAAand 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 qualifications. 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 NIL's
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 covering 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 SNAintegration 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
certifications. 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. Troubleshooting Virtual Private
Networks 8 / 665 12. Acknowledgments I'd 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 don't 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! I'd 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, I'd like to thank W. Mark Townsley for reviewing Chapter
5, as well as Glen Zorn and Luca Martini for confirming 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 Astricom's ISDN
simulators. Troubleshooting Virtual Private Networks 9 / 665 13.
Icons Used in This Book Throughout the book, you will see the
following icons used for networking devices: Troubleshooting
Virtual Private Networks 10 / 665 14. 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 configuration 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. Troubleshooting Virtual Private
Networks 11 / 665 15. 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 difficult 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, you'll
be well on your way to solving your problem. And if your
organization 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
([email protected]), and my very knowledgeable colleagues or I will
soon be on site helping to ensure that the process goes smoothly
(our services are chargeable, of course!). Furthermore, if your
organization would like to improve staff productivity and expertise
through advanced training, again please see the website. Anumber 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.
Troubleshooting Virtual Private Networks 12 / 665 16. 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 necessary 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.
Troubleshooting Virtual Private Networks 13 / 665 17. 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 first place. Because of the range of coverage, and the fact
that each chapter covers not only troubleshooting, but also a
technical overview and configuration guidelines, this book may be
of considerable assistance to CCIE candidates preparing for the
Service Provider and Security exams. Troubleshooting Virtual
Private Networks 14 / 665 18. 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 curious about VPN technologies in
general and want to improve your internetworking skills. Asecond
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 don't
imagine that many people are lucky enough to have 7200s in their
lab! 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 find one or two extra labs for the other technologies
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 troubleshooting 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 first virtual private dialup network technologies to be
deployed. This chapter discusses the technology, its configuration,
and in-depth troubleshooting techniques. Chapter 3,
"Troubleshooting Point-to-Point Tunneling Protocol VPNs" The PPTP
protocol, configuration, 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 configuration, and goes on to
examine in- depth L2TPv2 troubleshooting 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 configuration, 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 configuration, 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, configuration, 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 configuration. The IPSec
technology, configuration, and in- depth troubleshooting are
discussed in this chapter. Troubleshooting Virtual Private Networks
15 / 665 19. 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 chapters include
troubleshooting labs to help readers understand and consolidate
concepts and techniques discussed. This appendix explains how lab
configuration can be loaded onto lab routers from the Cisco Press
Web site (www.ciscopress.com/1587051044) and provides solutions to
the labs themselves. Troubleshooting Virtual Private Networks 16 /
665 20. Chapter 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. Asystematic 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 definitely
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 efficient manner, this approach is
definitely the one to adopt. Troubleshooting Virtual Private
Networks 17 / 665 21. 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. Afirst 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 configurations,
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, you'll be able to spot and
troubleshoot network problems much more easily. Troubleshooting
Virtual Private Networks 18 / 665 22. 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 first 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. Troubleshooting Virtual Private Networks 19 / 665
23. 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 specified at this
layer. The data link layer handles physical addressing, flow
control, access to the physical medium, and error detection. Data
link layer protocols include HDLC, PPP, Frame Relay, and Ethernet.
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 flow 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 fit 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. Troubleshooting Virtual
Private Networks 20 / 665 24. 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 first thing to do is to confirm that remote
clients' calls are being received on the L2TP Access Concentrator
(LAC). Next you should confirm that Link Control Protocol (LCP) and
partial authentication are being successfully completed on the LAC.
Then you should confirm 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 [View
full size image] 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. Agood 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
[View full size image] Troubleshooting Virtual Private Networks 21
/ 665 25. 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 first, then next, then after that for the VPN to function
correctly. Also ask yourself what underlies each particular process
or mechanism. Troubleshooting Virtual Private Networks 22 / 665 26.
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. 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
identified 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 filter 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 first 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 first 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. 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
Troubleshooting Virtual Private Networks 23 / 665 27. *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] In the first 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 fulfill 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. 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# As you can see, the condition AToM VC ID 123 has been
configured. 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 first. The output of a number of debug
commands can also be filtered using an access list. Agood 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
prefixes specified by the access list. Troubleshooting Virtual
Private Networks 24 / 665 28. 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 configurations,
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.
Troubleshooting Virtual Private Networks 25 / 665 29. Chapter 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 defined 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 ISP's nearest Point-of-Presence (POP). Figure 2-1
illustrates this concept. Figure 2-1. L2F Topology [View full size
image] 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. Troubleshooting
Virtual Private Networks 26 / 665 30. Technical Overview of L2F
This chapter focuses on in-depth troubleshooting of L2F. Fast and
efficient troubleshooting requires a good knowledge of both L2F and
its configuration, 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. Figure 2-3.
L2F Packet Header [View full size image] The following list
provides an analysis of the L2F header, starting with the header
flags: The F, K, S, and C bits, if set to 1, indicate that the
optional fields (shown as opt in Figure 2-3) should be present: -
F, if set, indicates that the Offset field should be present. - K,
if set, indicates that the Key field should be present.
Troubleshooting Virtual Private Networks 27 / 665 31. - 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 specifically define what type of packet should constitute
a priority packet but instead leaves this up to the implementer.
The Version (Ver) field is a 3-bit field 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 field 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 field
values. 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 If the value in the Protocol field
specifies 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 field 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 flexibility with regard to the Sequence number field.
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 field, 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. Figure 2-4. Multiple Sessions Within the L2F Tunnel [View
full size image] Troubleshooting Virtual Private Networks 28 / 665
32. 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 A's PPP connection uses MID 17, and user B's PPP
connection uses MID 18. Note that MID 17 and 18 have no special
significance 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. The Client ID
(CLID) is a 16-bit field, 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 field 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
identified 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 field 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 field. 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 field. The next field in the packet
header is Length. The Length field is 16 bits long, and it reflects
the length of the header and payload but does not include the
checksum if one is present. The Offset field, if present, is used
to specify how many bytes after the L2F header the payload starts.
For some transport architectures, it might be more efficient if the
payload is aligned with a 32-bit boundary, and the Offset field can
be used to ensure this (with an offset of 0). The Offset is present
only if the F bit is set. Troubleshooting Virtual Private Networks
29 / 665 33. The Key is a 32-bit field, 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. 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 field 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 field, the packet is a tunnel
management packet. Within the payload of a tunnel management
packet, various options and suboptions can be carried. The option
specified 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 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 Troubleshooting Virtual Private Networks 30 /
665 34. 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 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.
AChallenge 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. 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 sender's name (which is also
contained within the response). If this PPP connection is one that
should be tunneled to a Home Gateway, the sender's 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 modified 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 AAAserver responds with tunnel
information based on this username. Configuration 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_configuration_example09186a0080094860.shtml
Troubleshooting Virtual Private Networks 31 / 665 35. 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. Figure 2-6. L2F_CONF Sent by the NAS
Within the L2F packet header, the protocol type field 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) 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 first confirms that the incoming L2F_CONF
message is from a recognized NAS. If it is, the Home Gateway takes
the random number specified in L2F_CONF_CHAL (call it Random1) and
the tunnel secret (password) corresponding to the NAS's name
(specified in L2F_CONF_NAME suboption) and performs a hash. The
password corresponding to the NAS's 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 Troubleshooting Virtual Private Networks 32 / 665 36.
[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 NAS's 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 [View full
size image] Within the L2F header, the protocol field 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. 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.
Troubleshooting Virtual Private Networks 33 / 665 37. 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. Figure 2-10. L2F_OPEN sent by the NAS
[View full size image] The packet header for this message is
constructed as follows: The Protocol field contains the value 0x01.
The Sequence field (number) is set to 1 (the next exchange in the
sequence, following the exchange of L2F_CONF messages). The MID
field 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. Figure 2-11 shows the L2F_OPEN
message sent by the NAS. Figure 2-11. The L2F_OPEN Message Sent by
the NAS Troubleshooting Virtual Private Networks 34 / 665 38. 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
field 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. Figure 2-13. Packet Format of the L2F_OPEN
Sent by the Home Gateway to the NAS 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. 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. Troubleshooting
Virtual Private Networks 35 / 665 39. 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. You'll remember that when the client first 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 client's 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. Figure 2-14. Session Setup L2F_OPEN Sent by the NAS The
L2F_OPEN message header takes the following form: The Protocol
field contains the value 0x01 (because this is still a tunnel
management message). The Sequence number field is set to the value
2 (this is the next in the sequence). The MID field 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. Anumber of
suboptions are included: L2F_OPEN_TYPE (indicating authentication
type) L2F_OPEN_NAME (the remote access client's 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). In addition to client authentication information, the
NAS passes some client LCP negotiation messages to the Home
Gateway: Troubleshooting Virtual Private Networks 36 / 665 40. The
last LCP Configure-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 first Configure-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 configure 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 specified in the first 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 Upon
receiving this L2F_OPEN message, the Home Gateway responds to the
NAS with a L2F_OPEN. This L2F_OPEN serves to confirm 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 Troubleshooting Virtual Private Networks 37 /
665 41. The L2F_OPEN message header takes the following format: The
Protocol field is set to 0x01 (L2F_PROTO). The Sequence number
field 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.
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. Figure 2-18. NAS Forwards PPP Frames
Troubleshooting Virtual Private Networks 38 / 665 42. It is worth
qualifying the statement word transparently. PPP frames are
unescaped, and any bit-stuffing is removed before forwarding.
Additionally, PPP flags (excluding the address and control flags,
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 field 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. 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 field 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. 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
Troubleshooting Virtual Private Networks 39 / 665 43. 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 Tunnel Maintenance RFC 2341 specifies 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 Arecommended practice is that
if a tunnel peer (NAS or Home Gateway) transmits at least five
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. Troubleshooting Virtual Private
Networks 40 / 665 44. 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). Apossible
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-22. L2F_ECHO Message Figure 2-23 illustrates the L2F_ECHO_RESP.
Figure 2-23. L2F_ECHO_RESP Message 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. L2F
Tunnel Teardown The final 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. Troubleshooting Virtual Private Networks 41 / 665 45.
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 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