Troubleshooting Virtual Private Networks

Next Page

Book Cover
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
Overview

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.

Next Page


Table of Contents

Previous Page
Next Page

Book Cover
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 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
Appendix A. 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

Previous Page


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

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, CA 95134-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
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, CA 95134-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


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 mark@mjlnet.com.


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


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.


Icons Used in This Book

Throughout the book, you will see the following icons used for networking devices:


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.


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 (mark@mjlnet.com), 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.

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


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.


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.

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

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


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


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


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.


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.


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

[View full size image]

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 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
*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. 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 prefixes specified by the access list.


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.


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.


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.

    - 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]

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.

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

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 AAA server 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

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

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

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.

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. A number 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:

  • 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

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

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

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

A recommended 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.

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

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

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 configuration 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

Additionally, L2F_CLOSE_WHY failure codes that can be masked by the value 0xFF000000 (0x01000000 to 0xFF000000) are reserved for vendor-specified 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.


Configuring L2F

Misconfiguration is the most common cause of L2F tunnel failure. Although L2F configuration is not a primary goal of this chapter, this section discusses basic L2F configuration.

The next two sections step through the configurations for the NAS and the Home Gateway.

Configuring the L2F NAS

The configuration for the NAS discussed here assumes a typical hardware configuration including either E1 or T1 ISDN Primary Rate Interfaces (PRIs), together with asynchronous digital (MICA) modems.

Configuration of the NAS involves nine basic steps, as summarized in the list that follows:

Step 1. | Configure the E1/T1 controllers.
Step 2. | Configure global ISDN parameters.
Step 3. | Configure the D channels.
Step 4. | Configure parameters for asynchronous lines.
Step 5. | Configure group asynchronous interfaces.
Step 6. | Configure remote AAA (optional).
Step 7. | Configure the tunnel secrets.
Step 8. | Globally enable VPDNs.
Step 9. | Configure the VPDN groups.

It is worth pointing out that many possible permutations exist; however, this section concentrates on only the most common configuration.

The sections that follow discuss each step of the configuration in detail.

Step 1: Configure the E1/T1 Controllers

The first step is to configure either the E1 or T1 controllers. Configuration of the E1 or T1 controllers involves specifying the framing, line code, clock source, and timeslots.

Example 2-1 shows a sample configuration of an E1 controller.

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

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

Ensure that the E1/T1 framing, linecode, and clock source are configured per your service provider's recommendations.

Step 2: Configure Global ISDN Parameters

The next step is to configure global ISDN parameters. In Example 2-2, only the global ISDN switch-type is specified.

Example 2-2. Configuring the Global ISDN Switch-type
isdn switch-type primary-net5

Example 2-2 specifies 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 specified per your provider's specifications.

Step 3: Configure the D Channels

Next, you should configure the ISDN D channels to receive asynchronous modem calls. To do this, the configuration in Example 2-3 is required.

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

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 configured next. Note that this is not strictly necessary, as it has already been configured 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: Configure Parameters for Asynchronous Lines

Once the configuration of the E1/T1 controllers and the D channel configuration is completed, it is time to configure the modems and their corresponding asynchronous lines.

Example 2-4 shows the configuration of the asynchronous lines.

Example 2-4. Configuring the Modem and Corresponding Asynchronous Lines
line 33 38
 modem InOut
 modem autoconfigure type mica
 autoselect ppp

The command line 33 38 allows you to configure 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 confirm line numbering.

The first command in the line configuration is the modem InOut command. This allows the modems to both receive and initiate calls. The modem autoconfigure type mica command allows the NAS to automatically configure 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 configuration is applied to all six lines without having to configure the lines individually.

Step 5: Configure Group Asynchronous Interfaces

The corresponding logical configuration is now applied to the asynchronous interfaces. It is again possible to apply this configuration individually or to a group of interfaces together. A group configuration is usually used because it saves time and ensures that all interfaces are consistently configured.

Example 2-5 shows the configuration for the asynchronous interfaces.

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

The first command in the configuration is no ip address. The command no IP address is configured 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 configures 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 configures 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 configures CHAP authentication. Finally, the group-range 33-38 command causes the group-async 1 interface configuration to be applied to lines 33 to 38.

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: Configure 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 configuring per-user VPDN, if you have tunnel definitions (tunnel configuration) 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 definitions stored on a AAA server is beyond the scope of this chapter, more information can be found in the case study entitled "Misconfigured L2F Tunnel Definition 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 configuration.

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

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 specifies that the first 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 configuration.

Authentication for PPP is then enabled with the default method list (aaa authentication ppp default local group radius). This method list specifies that PPP should authenticate first 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.

The command radius-server ip_address auth-port 1645 acct-port 1646 key key is used to configure 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 official 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, configuration of accounting is not mandatory on the L2F NAS, but it is shown for completeness.

Step 7: Configure the Tunnel Secrets

The passwords used by the NAS and the Home Gateway to authenticate each other are now configured. These can again be configured locally or on the AAA server.

To configure 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 configuration 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: Configure the VPDN Groups

Finally, the VPDN groups need to be configured (that is, if their configurations are not stored on the AAA server as tunnel definitions). To enable the VPDN groups, use the sample configuration 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

The configuration of the VPDN groups is relatively easy. One VPDN group should be configured for each tunnel.

In Example 2-7, vpdn-group 1 is configured. The group name, in this case 1, must be unique among all VPDN groups configured on this NAS.

The second command, request dialin, configures 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 specified 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 first 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 configures the NAS to match the remote access client's 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 configuration 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
!
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 user's 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
!
! 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

Note that a static route is used in Example 2-8 for IP reachability to the Home Gateway.

Configuring the L2F Home Gateway

Compared to that for the NAS, the configuration of the Home Gateway is pretty simple. Basic configuration of the L2F Home Gateway consists of the following six steps:

Step 1. | Configure either local authentication or remote AAA configuration.
Step 2. | Configure the tunnel secret.
Step 3. | Globally enable VPDNs.
Step 4. | Configure VPDN groups.
Step 5. | Configure virtual templates.
Step 6. | Create IP pools and configure DNS/WINS server addresses.

The sections that follow cover each step of the configuration in detail.

Step 1: Configure Either Local Authentication or Remote AAA Configuration

The first step is the configuration of either local authentication or remote AAA on the Home Gateway.

To configure 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 configuration of remote AAA on the Home Gateway.

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

The remote AAA configuration is largely the same as that for the NAS. Please refer to the previous section for a complete explanation.

Step 2: Configure the Tunnel Secret

To configure 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 configuration again follows that for the NAS.

To enable VPDNs globally, use the following command:

vpdn enable

Step 4: Configure VPDN Groups

Configuration of the VPDN groups is slightly different than that on the NAS.

Configuration of the VPDN groups on the Home Gateway can be accomplished as follows:

vpdn-group 1
 accept-dialin
  protocol l2f
  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 configuration 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 specifies the hostname of the NAS from which tunnels are accepted.

Step 5: Configure Virtual Templates

The virtual template specified in the VPDN group must be configured next.

Example 2-10 shows a sample configuration of the virtual template 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

Most of the configuration in Example 2-10 is fairly self-explanatory.

The virtual template is not configured with a specific 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 specifies that the remote access client should be assigned an IP address from address pool PERRIS_POOL.

CHAP authentication is then specified, 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-specific interface configuration on a AAA server (this configuration is downloaded to the Home Gateway as remote access clients connect). Configuration of user-specific interface configuration on a AAA server is beyond the scope of this book, but for more information refer to the document entitled "Configuring Virtual Profiles" on www.cisco.com.

Note that two other commands that you may want to configure 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.

NOTE

For more information on the configuration 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 Configure DNS/WINS Server Addresses

The final step is to configure the IP address pool on the Home Gateway. At the same time, any DNS and WINS (NetBios Name) server addresses can be configured.

The IP address pool called PERRIS_POOL, together with DNS and WINS server addresses, are configured 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 first 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 configuration for the Home Gateway.

Example 2-11. Sample Configuration for the L2F Home Gateway
[View full width]
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
!
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

!

! 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

You will notice in Example 2-11 that a static route is again configured for IP connectivity to the NAS.

To avoid simple misconfiguration errors, you should always incrementally configure and test your NAS and Home Gateway. This means that the dial configuration of the NAS should be completed first, then tested. Then the VPDN groups should be configured with local authentication and tested. And finally, the NAS/Home Gateway should be configured to use a remote AAA server, if required.


Troubleshooting L2F

Fast and efficient troubleshooting of L2F is dependent upon a good understanding of L2F protocol operation, L2F configuration, 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 flowchart in Figure 2-26 describes the troubleshooting process used with L2F. You can use this flowchart to quickly access the section of the chapter relevant to problems you are experiencing on your network.

Figure 2-26. L2F Troubleshooting Flowchart

[View full size image]

Before beginning the troubleshooting process, it is worth briefly 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

[View full size image]

Figure 2-27 illustrates the following steps:

1. | If the remote access client is using asynchronous dial, the first 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 client's call is then switched internally on the NAS to the digital (MICA) modems.
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 field 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 confirms that a VPDN group is configured to terminate a L2F tunnel from the NAS and that there are sufficient 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. | Configuration 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.

That's 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.

Figure 2-28. Potential Problems with L2F Tunnel Setup

[View full size image]

Together, Figure 2-28 and Table 2-4 illustrate some potential problems.

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 configuration

Data link issue

Data link issue

DUN misconfigured

Modem configuration

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 misconfiguration

Cabling issue

AAA server issues

PPP authentication mismatch

Authentication failure

The first 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, misconfiguration 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 first thing that needs to be confirmed 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.

Figure 2-29 illustrates call reception on the NAS.

Figure 2-29. Call Reception on the NAS

The first thing to do is to confirm 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.

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#

Highlighted line 1 shows the globally configured 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 provider's ISDN 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.

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#

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.

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#

You can see in the first 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-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#

In the first 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.

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#

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 configured framing, linecode, or clock source. Make sure that these are configured as per your service provider's 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 first highlighted line of Example 2-17, a call setup message is received (RX) on the D channel (serial0/0:15).

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#

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-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#

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 autoconfigures 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 configured on the ISDN D channel. Also make sure that the modem InOut command is configured on the modem lines.

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 confirmed that the call setup is completing successfully.

Troubleshooting PPP on the NAS

If you have confirmed 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

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 Configure-Request (CONFREQ) to the remote access client, as shown in 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)

The highlighted line in Example 2-20 shows the outbound (O) Configure-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 defines 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 specified is standard MD5 CHAP (0xC22305).

The third option is Magic Number (0x05). The Magic Number specified by the NAS is 0x115342A4. The Magic Number is used for loop detection.

PFC (0x07) is the next option specified. The NAS uses this option to inform the client that it can receive PPP protocol fields that are compressed.

The final option is ACFC (0x08). This option is used to indicate that the NAS can receive PPP frames without HDLC Address and Control fields.

The client then acknowledges the NAS's CONFREQ with a Configure-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-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)

All the options contained in the CONFACK are the same as those in the CONFREQ in Example 2-20.

The first inbound (I) CONFREQ is now received from the client (see Example 2-22).

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)

Most of the options are the same as those specified in the NAS's CONFREQ, but there is one addition: The client has specified 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 first 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 Configure-Reject (CONFREJ) to the remote access client, as shown in Example 2-23.

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

The NAS uses the Configure-Reject (CONREJ) in Example 2-23 to reject configuration 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 specifies the same options as the first CONFREQ (see Example 2-20).

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)

A second CONFACK is received from the client in Example 2-25.

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

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.

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)

The CONFREQ in Example 2-26 contains the same options as the two previous CONFREQs.

The third CONFREQ is acknowledged by a final inbound CONFACK from the client in Example 2-27.

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)

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

The options contained in the CONFREQ in Example 2-28 are the same as those specified in the client's first CONFREQ (see Example 2-22).

Callback is then rejected by the NAS using a CONFREJ in Example 2-29.

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)

The client now sends its third CONFREQ (in Example 2-30), and this time you will notice there is no Callback option included.

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)

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-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 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-32. debug ppp negotiation Command Output (Continued)
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
*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#

In highlighted line 1, the NAS sends an LCP CONFREQ to the client. Note that the authentication protocol (AuthProto) specified 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 configured to accept MS-CHAP, or the client can be configured to accept standard MD5 CHAP. In this case, the client is reconfigured to accept standard MD5 CHAP. The client now reconnects, and LCP negotiates successfully. This is verified using the show user and show caller user commands.

Example 2-33 shows the output of the show user command.

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#

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.

Example 2-34 shows the output of the show caller user command.

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#

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.

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.

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

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.

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 first, 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 field (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 client's CHAP Response, together with other information, to the Home Gateway.

In this case, the username supplied in the client's 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 specific 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
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

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 find 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 find a L2F tunnel corresponding to domain name mjlnet.com. The VPDN configuration is then examined and the problem is revealed.

Example 2-37 shows the output of the show running-config command on the NAS. Note that only the relevant portion of the output is shown.

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
!

As you can see, the domain for the VPDN group has been incorrectly configured as disco.com. To correct this, use the configuration in Example 2-38.

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#

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 verified using the show vpdn tunnel all command.

Example 2-39 shows the output of the show vpdn tunnel all command.

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#

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

[View full size image]

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

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

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.

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

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.

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

The NAS successfully authenticates the Home Gateway, and the L2F tunnel is now established.

The show vpdn tunnel all command can be used to confirm L2F tunnel establishment, as shown in Example 2-43.

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#

Highlighted line 1 shows that there is one L2F tunnel and one L2F session established. Highlighted lines 2 to 4 show the NAS's name (LODI_NAS1), CLID (32), and IP address (172.16.1.1). The Home Gateway's 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 configured with an incorrect IP address for the Home Gateway. To verify that the NAS is configured 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 specified in the tunnel definition on the RADIUS server.

  • Home Gateway does not recognize the NAS. Check that the Home Gateway is correctly configured to terminate tunnels from the NAS. Ensure that the NAS's name is specified 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 definition is stored on a AAA server, be sure to see the case study entitled "Misconfigured L2F Tunnel Definition on the AAA Server" toward the end of this chapter.

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.

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

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 NAS's L2F_CONF, and in Example 2-45 (highlighted line 1), the NAS resends it.

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

The NAS now sends an L2F_CLOSE to request tunnel shutdown as shown in Example 2-46.

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#

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 configuration on the Home Gateway shows the results in Example 2-47. Note that only the relevant portion of the output is shown.

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
!

As you can see, the Home Gateway is correctly configured to terminate a tunnel from the NAS but, unfortunately, is configured to terminate L2TP tunnels and not L2F tunnels.

The configuration is modified as in Example 2-48.

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#

When the client reconnects, tunnel establishment is successful. The output of the show vpdn tunnel command confirms this, as demonstrated in Example 2-49.

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

Highlighted line 1 shows that one tunnel and one session have been established. In highlighted lines 2 to 5, the Home Gateway's 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.

Figure 2-33. L2F Tunnel Establishment

[View full size image]

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.

Examples 2-50 and 2-51 show the L2F tunnel establishment process.

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

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.

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 configured tunnel password, calculate a MD5 hash value.

The NAS and the Home Gateway now begin tunnel establishment (Example 2-51).

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

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 configured 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 configured 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-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

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.

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

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 Gateway's challenge that it sent in its L2F_CONF (Example 2-52, highlighted line 4).

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

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#

The NAS sends a L2F_CLOSE message to the Home Gateway (Example 2-54, highlighted line 1). This serves as notification 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-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#

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 Gateway's challenge is incorrect. This can mean only one thing. Tunnel passwords must be configured inconsistently on the NAS and the Home Gateway.

The service password-encryption command is configured on both the NAS and the Home Gateway, so it is impossible to be sure where the tunnel password is misconfigured. The passwords are, therefore, reconfigured on both the NAS and the Home Gateway using the configuration in Example 2-56.

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#

When the client reconnects, L2F tunnel establishment succeeds. This is configured using the show vpdn tunnel all command.

Example 2-57 shows the output of the show vpdn tunnel all command.

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#

Highlighted line 1 reveals that one tunnel and one session have been established. Highlighted lines 2 to 4 show the Home Gateway's 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

[View full size image]

Before examining what happens when there is an L2F session setup failure, it is a good idea to first 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.

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#

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) confirms 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 confirm successful L2F session setup, as shown in Example 2-59.

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#

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

Examples 2-60 to 2-62 show the output from the debug vpdn l2x-errors command.

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

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.

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

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.

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#

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.

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

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 configuration of the Home Gateway in Example 2-63 reveals the source of the "problem."

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
!

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 configured limit or revising it upward. In Example 2-64, the limit is removed.

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#

When the client reconnects, L2F session setup succeeds. This is verified using the show vpdn tunnel all command, as shown in Example 2-65.

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#

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 Gateway's 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. Specifically, 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 first thing to do is to verify that configuration is being correctly cloned from the virtual template to the virtual access interface.

Figure 2-35 shows the cloning of configuration from the virtual template to the virtual access interface.

Figure 2-35. Cloning Configuration from the Virtual Template to the Virtual Access Interface

[View full size image]

Cloning of configuration from the virtual template to the virtual access interface can be verified 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
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#

Highlighted line 1 shows that configuration is about to be cloned from the virtual template to virtual access interface 1. Highlighted lines 2 to 7 show the precise configuration 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 configuration has been successfully cloned to the virtual access interface.

If no configuration is cloned to the virtual access interface, use the show running-config command to verify that the virtual template is correctly referenced in the VPDN group configuration, as demonstrated in Example 2-67.

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
!

In this case, the virtual template is correctly referenced in the configuration of the VPDN group.

If you have user-specific configuration stored on a AAA server, as you troubleshooting PPP negotiation be sure to verify that this configuration is correct, and that it is being downloaded to the Home Gateway. One useful command when troubleshooting the download of user-specific configuration is debug aaa per-user.

LCP Negotiation or PPP Authentication Failures

Once the virtual template configuration 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.

Figure 2-36. Home Gateway Negotiates LCP and Authenticates the Remote Access Client

[View full size image]

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 client's username and authentication response), or it can restart LCP negotiation or authentication.

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

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.

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)

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.

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)

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.

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

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.

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"

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-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#

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 client's username or password is misconfigured on the client or Home Gateway. In this case, the client confirms that he is using the correct username and password, and so one or the other must be misconfigured on the Home Gateway.

The client's username and password are then reconfigured on the Home Gateway, as shown in Example 2-74.

Example 2-74. Reconfiguration of the Client's 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#

When the client reconnects, PPP authentication succeeds. This is verified using the show caller user on the Home Gateway, as shown in Example 2-75.

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#

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.

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, reconfigure 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) Authentication 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 configure 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 configuration 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.

Figure 2-37. NCP Negotiation Between the Home Gateway and the Remote Access Client

[View full size image]

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.

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.

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

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

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 specifies its own IP address (IPCP option 0x03, IP-Address).

The remote access client then requests configuration of Microsoft Point-to-Point Compression (MS-PPC), as shown in Example 2-78.

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)

The Home Gateway receives an inbound (I) Compression Control Protocol (CCP) CONFREQ from the client (in Example 2-78).

Within it, the client requests configuration of MS-PPC (option 0x12).

The Home Gateway rejects configuration of MS-PPC in Example 2-79 by sending a PROTREJ message.

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)

Following the rejection of MS-PPC, the client sends an IPCP CONFREQ to the Home Gateway in Example 2-80.

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)

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

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

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)

The client acknowledges the Home Gateway's IP address with a CONFACK (Example 2-83). This is in response to the CONFREQ sent by the Home Gateway in Example 2-77.

Example 2-83. Client Acknowledges the Home Gateway's 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)

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 Gateway's CONFREJ (see Example 2-82).

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)

The Home Gateway responds with a Configure-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.

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)

The client then responds with another CONFREQ in Example 2-86. This serves to confirm the IP and DNS server address just supplied by the Home Gateway.

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)

The Home Gateway now acknowledges the client's IP address and primary DNS server addresses with a CONFACK (see Example 2-87).

Example 2-87. Home Gateway Acknowledges the Client's 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)

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

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#

NCP negotiation has been completed successfully.

Note that in this example, IP is the only network layer protocol configured on the Home Gateway and the client. If other protocols such as IPX are configured, 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.

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

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 configuration of MS-PPC.

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)

The Home Gateway, however, rejects CCP (including MS-PPC), as shown in Example 2-91.

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)

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.

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)

At this point, the Home Gateway sends a PROTREJ to the client rejecting configuration of IPCP (see Example 2-93).

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)

Once the Home Gateway has rejected the configuration of IPCP, things go downhill very quickly.

In Example 2-94, the remote access client connection is torn down.

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#

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 Gateway's 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?

The answer is in Example 2-93. At this point in the NCP negotiation sequence, the Home Gateway rejected configuration of IPCP. There is only one reason that the Home Gateway would reject configuration of IPCP: if there is no IP address configured on the virtual template.

The virtual template configuration is then examined using the show running-config command, as shown in Example 2-95. Note that only the relevant portion of the output is shown.

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
!

As expected, there is no IP address on the virtual template interface.

This is remedied by configuring ip unnumbered on the virtual template, as shown in Example 2-96.

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#

Once ip unnumbered has been configured 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-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
          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#

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 configuration 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

[View full size image]

Issue 1: Misconfigured L2F Tunnel Definition on the AAA Server

Storing tunnel definitions and configuration on a AAA server can be a convenient way of managing your L2F VPDNs. If the tunnel definition is misconfigured, however, tunnel setup will fail.

Tunnel definitions can be configured using either Cisco AV-pairs or standard IETF attributes. In this scenario, Cisco AV-pairs are used.

When troubleshooting this issue, the first thing to do is to confirm that the tunnel definition 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.

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

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 client's authentication response.

Note that the tunnel definition is stored on the AAA server under the username that corresponds to the client's domain name.

Authorization for user mjlnet.com now begins (see Example 2-99).

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)

Highlighted line 1 shows that authorization for the network service (NET) is sought by LODI_NAS1. Note that the network service includes PPP. Specifically, 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.

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#

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-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
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#

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

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 definition from the RADIUS server and then almost immediately disconnects the client. This might indicate a problem with the tunnel definition itself. The tunnel definition 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 definition on the RADIUS server.

Figure 2-39. Tunnel Definition on the RADIUS Server

[View full size image]

If you look closely at the tunnel definition, you can see that one crucial attribute is missingthe IP address of the Home Gateway.

The IP address of the Home Gateway is defined using the Cisco AV pair (009/001) vpdn:ip-addresses=ip_address. This attribute is then added to the tunnel definition on the RADIUS server.

Note that the tunnel definition 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 reconfiguration of the tunnel definition.

Figure 2-40. Reconfiguration of Tunnel Definition

[View full size image]

Once the tunnel definition has been reconfigured, the client reconnects, and tunnel establishment succeeds.

Successful tunnel establishment is verified using the show vpdn tunnel all command, as demonstrated in Example 2-102.

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#

Highlighted line 1 shows that one tunnel and one session have been established. Highlighted lines 2 through 4 show the Home Gateway's 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.

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#

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 definition, there are a number of other issues for which to look out. Ensure that the user (domain) associated with the tunnel definition on the RADIUS server is configured with the password cisco. This password is hard-coded for tunnel definitions on Cisco routers. Also, make sure that the Service-Type (attribute 6) is configured 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 configured within the User or Group setup if you are configuring 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://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.

Before finishing this case study, it worth also taking a look at an L2F tunnel definition (using Cisco AV pairs) in Merit format.

A correctly configured L2F tunnel definition for a Merit RADIUS server is shown in Example 2-104.

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"

The tunnel definition is pretty self-explanatory. In line 1, the domain name is specified (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 specified here (cisco). In line 2, the service type (Outbound-User) is shown.

The remainder of the tunnel definition 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 first command to use is debug aaa authentication.

Example 2-105 shows the output of the debug aaa authentication command.

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

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

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#

In highlighted line 1, login authentication for service PPP begins. Highlighted lines 2 and 3 show that the first 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-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
*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#

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 client's username or password may be misconfigured on either the client workstation or the RADIUS server. The client confirms that his username and password are correctly configured. This leaves only the RADIUS server. The username on the RADIUS server is correctly configured. This means that the password must be incorrectly configured. The password is then reconfigured.

Figure 2-41 shows the reconfiguration of the client password in the user setup (or at least the User Setup configuration boxtake my word that the password has been reconfigured).

Figure 2-41. Reconfiguration of the User Password

[View full size image]

As soon as the password has been reconfigured, the client reconnects, and this time, authentication is successful. This is verified using the show user caller command, as demonstrated in Example 2-108.

Example 2-108. Output of the show caller user Command (Continued)
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
        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#

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 configured, 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.

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

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

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#

Highlighted line 1 shows that the Home Gateway is seeking authorization for the Network (NET) service. Note that the Network service includes PPP. Specifically, 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-111 shows the output of the debug radius command.

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#

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 client's user amd group setup on the RADIUS server.

Figure 2-42 shows the client's group setup on the RADIUS server.

Figure 2-42. Client's User Setup

[View full size image]

As you can see, in the IETF RADIUS Attributes configuration, the Service-Type (attribute 6) is configured as Login, and the Framed-Protocol (attribute 7) is configured as PPP.

The Framed-Protocol is correctly configured, but the Service-Type is misconfigured. Instead of Login, the Service-Type should be configured as Framed.

The Service-Type is then reconfigured as Framed, as shown in Figure 2-43.

Figure 2-43. Reconfiguration of the Service-Type

[View full size image]

Once the Service-Type has been reconfigured, the client reconnects, and authorization succeeds. This is verified using the show caller user command.

Example 2-112 shows the output of the show caller user command.

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
          31 packets output, 0 bytes, 0 underruns
          0 output errors, 0 collisions, 0 interface resets

PERRIS_HGW1#

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 Offload Server to the Home Gateway

When configuring an L2F tunnel from an offload server in a Multichassis Multilink PPP (MMP) environment, the tunnel from the offload 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 offload 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 traffic arriving in these MMP L2F tunnels from the offload server to a Home Gateway, you are in effect connecting inbound tunnels from SGBP members to the outbound tunnel to the Home Gateway. This interconnection of tunnels requires careful configuration.

In the following scenario, two front-end NASsLODI_NAS1 and LODI_NAS2are configured to forward PPP traffic to an offload server, LODI_OFFLOAD. LODI_OFFLOAD is then configured 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

[View full size image]

It is apparent, however, that although PPP traffic is being tunneled successfully from LODI_NAS1 and LODI_NAS2 to the offload 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#

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.

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#

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

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#

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 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 configured 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 verified 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.

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#

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

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.

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

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

Next, L2F tunnel setup from LODI_NAS2 begins (see Example 2-119).

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

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

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#

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 from LODI_OFFLOAD to the Home Gateway (PERRIS_HGW1). This points to a possible configuration error on LODI_OFFLOAD. Example 2-121 shows the relevant portion of LODI_OFFLOAD's configuration.

Example 2-121 shows the VPDN configuration on LODI_OFFLOAD.

Example 2-121. LODI_OFFLOAD's 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
!

At first glance, this configuration 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 configuration is corrected in Example 2-122.

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#

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

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

L2F tunnel establishment is then verified 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-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#

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

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#

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.

NOTE

For more information about configuring 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.

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#

Highlighted line 1 shows the default VPDN history failure table size (20 entries). The default VPDN history failure table size can be modified 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 NAS's and Home Gateway's 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.

debug vpdn error

The debug vpdn error command displays VPDN error information.

Example 2-127 shows the output of the debug vpdn error 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#

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 configured VPDN group configured 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 configured 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 first, 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-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#

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 find a tunnel corresponding to the DNIS string. The LODI_NAS1 now looks for and finds 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.

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

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

The first two highlighted lines show the header of an L2F control packet.

Highlighted line 1 shows that the flags and Version fields have a value of 0x9001. This indicates that the Offset and Sequence flags are set and that the Version is 1. The protocol field 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 field 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.

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.

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

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.

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#

Note that VPDN logging is enabled by default.

%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 misconfiguration 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 offline.

To resolve this issue, check the AAA configuration 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 client's domain name or DNIS corresponds to a tunnel configuration/definition 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 configured.

%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 configuration 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 configuration on the NAS/Home Gateway, as well as the configuration 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.

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, insufficient 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 configurable using the vpdn session-limit command.

To remedy this error, examine the configuration, 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 configuration or resource issue on the Home Gateway. You should check the configuration 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 Gateway's configuration to ensure that it is correct.

%VPDN-6-RESIZE Error Message

This indicates that the MID table size has been altered on the NAS or Home Gateway. Examine your configurations to ensure that they are correct.

%VPDN-6-SOFTSHUT Error Message

This message tells you that the vpdn softshut command has been configured 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 configuration 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 NAS's configuration to ensure that the IP address of the Home Gateway is configured 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 fields 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.

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


Review Questions

1: | Which L2F message type is the first 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 configured 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 significance of MID 0?
10: | How is the L2F tunnel maintained in the absence of client traffic?


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

[View full size image]

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_HGW1's loopback interface (10.20.10.1) from TATEBAYASHI@mjlnet.com.

Base configurations for the labs can be found on the Cisco Press Web site (www.ciscopress.com/1587051044). Detailed instructions for loading these base configurations onto your lab routers, as well as solutions can be found in Appendix B.

Troubleshooting Lab 1

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:

________________________________________________________________

________________________________________________________________

________________________________________________________________

________________________________________________________________

Actions:

________________________________________________________________

________________________________________________________________

________________________________________________________________

________________________________________________________________

Resolution:

________________________________________________________________

________________________________________________________________

________________________________________________________________

________________________________________________________________

Troubleshooting Lab 2

Q1:

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:

________________________________________________________________

________________________________________________________________

________________________________________________________________

________________________________________________________________

Troubleshooting Lab 3

1:

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:

________________________________________________________________

________________________________________________________________

________________________________________________________________

________________________________________________________________


Chapter 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

[View full size image]

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.

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

When troubleshooting PPTP, it is important to have a firm grasp both of its underlying operation and basic configuration. The next two sections examine the operation and configuration 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/channel The 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 configuration.

  • The (user) data tunnel The 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.

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

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)

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.

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.

Figure 3-5. SCCRQ Message Format

[View full size image]

As Figure 3-5 depicts, the SCCRQ message format consists of the following fields:

  • As the name suggests, the Length field indicates the length of the PPTP message, including the PPTP header itself.

  • The PPTP Message Type field is set to a value of 1 to indicate that this is a Control Message.

  • The Magic Cookie field 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 field value for the SCCRQ is 1.

  • The Reserved0 field is set to a value of 0. This field is designed to allow future expansibility of PPTP.

  • Protocol Version defines the version and revision number of PPTP being requested by the sender (the remote access client/PNS in this case). This field is four octets wide, with the first two octets describing the version number, and the last two octets the revision number.

  • The Reserved1 field is also reserved for future use and should be set to a value of 0.

NOTE

Note that the Length, PPTP Message Type, Magic Cookie, and Reserved0 fields are present in all PPTP control messages.

  • Framing Capabilities indicates the type of framing that the sender of the SCCRQ can support. Although this field is 32 bits wide, only two bit settings are currently defined. If bit 1 is set, asynchronous framing is supported, and if bit 2 is set, synchronous framing is supported.

  • Bearer Capabilities, the next field, is similar. Although 32 bits wide, only two bit settings are defined. Bit setting 1 indicates that analog access is supported, and bit setting 2 indicates that digital access is supported.

  • The Maximum Channels field 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 field to a value of 0.

    The Firmware Revision field specifies the firmware revision number or software driver version of the remote access client/PNS.

  • The Host Name field contains the DNS name of the sender of the SCCRQ.

  • The Vendor Name field contains vendor-specific information, such as the type of software being used by the remote access client/PNS.

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

[View full size image]

The SCCRP message format consists of many of the same fields as the SCCRQ message format. After the Protocol Version field, the message format begins to look a little different than that of the SCCRQ (see Figure 3-5). The significant fields for the SCCRP message format that differ from the SCCRQ message format are described as follows:

  • The Control Message Type field contains a value of 2, which indicates that this message is a SCCRP.

  • The Result Code field is an 8-bit field that is used to indicate one of five 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 specifies)

    3

    Command channel already exists

    4

    Requester is not authorized to establish command channel

    5

    Protocol version of the requester is not supported

  • Should a General Error be indicated by the Result Code (code 2), the next field, Error Code, indicates the specific error that has caused the control connection to fail.

    Table 3-3 summarizes the Error Codes, together with their meanings.

    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 field values was out of range/reserved field was non-zero

    4

    Insufficient resources to handle this command now

    5

    The Call ID is invalid in this context

    6

    Vendor specific error (for errors on PAC)

    Note that if a General Error should not be indicated in the Result Code field (in other words, any value other than 2 is contained within the field), the Error Code field 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.

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

[View full size image]

As Figure 3-8 depicts, the OCRQ message format consists of the following fields. (Explanations of fields already described have been omitted unless they differ based on packet relevance.)

  • The Control Message Type field is set to a value of 7 to indicate that this message is an OCRQ.

  • Skipping the Reserved0 field, the next field is Call ID. This field is a unique identifier 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.

    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 field 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 field specifies the minimum line speed (in bits per second) that would be acceptable to the remote access client/PNS.

  • The Maximum BPS field specifies the maximum line speed (in bits per second) that would be acceptable to the remote access client/PNS.

  • The Bearer Type field 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 field is similar in nature to the Bearer Type field 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 field is used for flow control and specifies the number of packets that are buffered for a particular session.

  • The Packet Processing Delay (PPD) field is again used for flow control purposes and specifies the time required to process the maximum amount of data in the buffer. The time is specified in tenths of a second.

  • The final three fields (excluding Reserved1, which has been previously described) are Phone Number Length, Phone Number, and Subaddress.

    Again, these three fields 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 fields 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.

Figure 3-9. OCRP Packet Format

[View full size image]

As Figure 3-9 depicts, the OCRP message format consists of the following fields (explanations of fields already described have been omitted unless they differ based on packet relevance):

  • The Control Message Type field is set to a value of 8, which indicates that this message is an OCRP.

  • The Call ID field 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 field, the Peer's 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 field is significant. It is used to indicate the success or failure of the session establishment attempt (the OCRQ).

    Although RFC 2637 specifies 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 specified in the Error Code field (this is known as a General Error), and 7 = Outgoing call (session) administratively prohibited.

  • The Error Code field is a nonzero value if the Result Code field is set to a value of 2 (General Error). Table 3-3 summarizes the possible error codes.

  • The Cause Code field 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 field, for example.

  • The Physical Channel ID field is used in compulsory tunnel mode and specifies 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).

Figure 3-11. PPP Negotiation and Frame Forwarding

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 flow control (something not provided by regular GRE).

Figure 3-12 shows the Enhanced GRE header.

Figure 3-12. Enhanced GRE Header

[View full size image]

The bits and fields 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.

  • The Flags bits are all set to 0.

  • Importantly, the Ver (Version) field is set to a value of 1. This indicates Enhanced GRE.

  • The Protocol Type field must be set to a value of 0x880B (the Ethertype for PPP).

  • The low two octets of the Key field are set to equal the Call ID for this session. PPTP uses the high two octets of the key field to indicate the size of the packet payload (not including the GRE header).

  • The two final fields are the Sequence Number and Acknowledgement Number fields. The presence of these two fields is dependent on the setting of the S and A bits, respectively.

    The Sequence Number field contains the sequence number of the payload, and the Acknowledgement Number field contains the sequence number of the highest numbered Enhanced GRE packet received. Note that the Acknowledgement field 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.

Figure 3-14. Echo-Request Packet Format

[View full size image]

As you can see, the message format is very simple:

  • The Control Message Type field is set to a value of 5 to identify this message as an Echo-Request.

  • The Identifier field 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

[View full size image]

Again, the message format is very simple:

  • The Control Message Type field is set to a value of 6 to indicate that this message is an Echo-Reply.

  • The Identifier field is set to the same value as the Identifier field 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 field 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 field.

    The Error Code field is set to 0 if the Result Code was 1. If the Result Code is 2, the General Error condition is indicated in this field. 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 first 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

[View full size image]

The CCRQ packet fields of significance are as follows:

  • The Control Message Type field is set to a value of 12 to indicate that this is a CCRQ message.

  • The Call ID field 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

[View full size image]

The CDN packet fields of significance are as follows:

  • The Control Message Type field is set to 13 to indicate that this is CDN message.

  • The Call ID field is set to identify the particular call (session) that is being cleared down.

  • The Result Code field 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 field (known as General Error), 3 = call disconnected for administrative reasons, and finally, 4 = call disconnected in response to CCRQ.

  • The Error Code field 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 field are the final two fields 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.

Figure 3-19. StopCCRQ Packet Format

[View full size image]

The StopCCRQ packet fields of significance are as follows:

  • The Control Message Type field is set to 3 to indicate that this is a StopCCRQ.

  • The Reason field 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 peer's PPTP version, and 3 = this machine is being shut down.

  • The Reserved2 field 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

[View full size image]

The StopCCRQ packet fields of significance are as follows:

  • The Control Message Type field has a value of 4 to indicate that this is a StopCCRP.

  • In the Result Code field, 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 field (this is known as a General Error).

  • The Error Code field is set to a value of 0, unless the Result Code field 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.

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

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

[View full size image]

The SLI packet fields of significance are as follows:

  • The Control Message type field is set to a value of 15. This indicates that this is a SLI message.

  • The Peer's 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 fields 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

Previous Page
Next Page


Configuring PPTP

Cisco routers support PPTP voluntary tunnel mode and function as the PAC, with the client functioning as the PNS.

Configuration is not the main theme of this chapter, but because misconfiguration is always one of the most common causes of problems, basic configuration of PPTP on Cisco routers is briefly reviewed here.

A number of configuration tasks have to be completed to enable PPTP. These steps are summarized as follows:

Step 1. | Configure local authentication or remote AAA.
Step 2. | Globally enable VPDNs.
Step 3. | Configure the VPDN group.
Step 4. | Configure the virtual-template.
Step 5. | Create the IP pools.
Step 6. | Verify each step of the configuration.

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

Alternatively, remote AAA can be configured. Remote AAA is much more scalable than local authentication.

Example 3-1 shows the configuration of remote AAA.

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

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 configuration but is included to illustrate a complete remote AAA configuration. It configures a default method list for login authentication. This default method list specifies 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.

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 configure 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 specifies 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 configuration.

Finally, the RADIUS server IP address, authentication/authorization and accounting ports, and the key are specified 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 specified 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 configuration 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 configured.

Example 3-2 shows the configuration of the VPDN group.

Example 3-2. Configuring the VPDN Group
vpdn-group 1
 accept-dialin
  protocol pptp
  virtual-template 1

The first line in the configuration, vpdn-group 1, defines the name of the VPDN group. In this case it is 1.

The second line of the configuration (accept-dialin) allows the router to accept inbound VPDN connections.

The third line (protocol pptp) specifies that the VPDN protocol to be used is PPP.

The last line in the configuration (virtual-template 1) specifies that any inbound PPP connections should be terminated on virtual access interfaces whose configuration 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 defined, the next step is the configuration of the virtual template.

Example 3-3 shows the configuration of the virtual template.

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

In the first line of the virtual template configuration, ip unnumbered is applied to the interface. In this case, when the configuration 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, specifies 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 Configuration Protocol (DHCP). In this case, the peer default ip address dhcp command should be used. The DHCP server address can then be specified using the ip dhcp-server {server_name | server_ip_address} global configuration mode command.

The ppp encrypt mppe 40 required command is next. This is an optional command, which specifies 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 configurable: 40-bit and 128-bit. In this case, the key is specified 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 configured with the passive keyword, as follows: ppp encrypt mppe 40 passive. If this configuration 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 configured for Microsoft CHAP authentication. Note that this is a Microsoft requirement when using MPPE.

User-specific interface configuration can also be stored on a AAA server and downloaded by the PAC when users connect. This configuration is beyond the scope of this chapter, so for some examples of this (in the form cisco-avpair = "lcp:interface-config=") see the document entitled "Configuring Virtual Profiles" on www.cisco.com.

The final part of the configuration involves the configuration 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-4 shows the configuration of the address pool, together with DNS and WINS server addresses.

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

In this example, ten IP addresses are configured 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 specified as 192.168.1.10 and 192.168.1.12, respectively.

Example 3-5 shows a complete basic PAC configuration using local authentication.

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

Before finishing this section, it is worth noting that PPTP traffic 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 configuration 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.

The flowchart in Figure 3-25 describes the troubleshooting process used with PPTP. You can use this flowchart to quickly access the section of the chapter relevant to problems you are experiencing on your network.

Figure 3-25. PPTP Troubleshooting Flowchart

[View full size image]

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.

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 configuration 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

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

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 misconfigured

IP connectivity "broken"

Tunnel protocol mismatch

TCP/IP not installed

TCP port 1723/GRE blocked (ACL/Firewall)

Virtual template misconfiguration

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 misconfiguration

Authentication failure

MPPE Issue

Modem Issues

Not switched on

Cabling issue

Note that many of the potential problems do not directly relate to configuration 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.

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 first 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 firewall 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.

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

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 (fields) of this message. Of particular interest is the Vendor field, which indicates that the remote access client/PNS is a Windows NT workstation.

Note also that the Framing and Bearer Capabilities fields are both set to a value of 1, indicating asynchronous framing and analog access support. These are simply defaults and may not in fact reflect 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 fields 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-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
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

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, fields 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 fields to note are the Bearer and Framing fields, 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) field 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 configuration 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.

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
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#

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.

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
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#

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, "isn't 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 first 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 modified their client code to make it work in the same way as other vendor implementations. So, there's been a certain amount of confusion regarding PPTP and L2TPv2 voluntary tunnel mode, but it's really just terminological confusion (neither protocol is inhibited in operation).

To resolve this issue, the remote access client tunnel protocol needs to be reconfigured as PPTP. Once the remote access client is reconfigured (not shown), the PPTP tunnel is successfully established. This is verified using the show vpdn tunnel all command, as shown in Example 3-10.

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#

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/PNS's and PAC's 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-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
*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#

In highlighted lines 1 and 2, configuration is copied from virtual template interface 1 to virtual access interface 1. The following four lines show the configuration 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-config command. This is shown in Example 3-12. Note that only the relevant portion of the output is shown.

Example 3-12. Verifying the VPDN Group
!
vpdn-group 1
! Default PPTP VPDN group
 accept-dialin
  protocol pptp
  virtual-template 1
!

In this example, the virtual template is correctly referenced under the VPDN group.

If you have user-specific configuration stored on a AAA server, be sure to verify this configuration 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 configured to authenticate using only the Microsoft Challenge Handshake Authentication Protocol (MS-CHAP), and the PAC is configured only for standard Message Digest 5 Challenge Handshake Authentication Protocol (MD5 CHAP), authentication protocol negotiation failure will occur.

Figure 3-29 illustrates LCP negotiation.

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.

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]

In the first 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) Configure-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.

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)

In Example 3-14, the CONFREQ includes two options: option 0x03, Authentication Protocol, and option 0x05, Magic Number. The authentication protocol specified is MS-CHAPv1 (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 specified. 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) Configure-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.

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

In Example 3-16, the PAC sends another CONFREQ to the remote access client/PNS. This contains the same options as the first CONFREQ (see Example 3-14). This is sent because LCP timed out in Example 3-15 (see the final line in the output).

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)

The remote access client/PNS acknowledges the CONFREQ in Example 3-16 with a CONFACK, as shown in Example 3-17.

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)

In Example 3-18, an incoming (I) CONFREQ is received from the remote access client/PNS. The options specified in the message are shown in the following eight lines.

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)

The first option specified 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 fields. 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 fields.

The final 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 Configure-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.

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)

Having received the CONFREJ, the remote access client/PNS now sends another CONFREQ, as shown in Example 3-20. This CONFREQ specifies all of the options included in its previous CONFREQ in Example 3-18 minus those rejected by the PAC in Example 3-19.

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)

In Example 3-21, the PAC responds with a CONFACK.

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

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/PNS's 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.

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)

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 specifies two LCP options, Authentication Protocol (option 0x03), and Magic Number (option 0x05). The authentication protocol specified by the PAC is standard MD5 CHAP (CHAP, option 0xC22305).

In the third highlighted line, the remote access client/PNS responds with a Configure-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 final two numerals indicate the specific CHAP algorithmin this case, MS-CHAPv2 (0x81). 0x81 is 129 in decimal hence the CHAP/129.

The PAC then tries again to negotiate standard MD5 CHAP with the remote access client/PNS, as shown in Example 3-23.

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)

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.

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#

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 configuration needs to be examined. This is done using the show running-config command.

Example 3-25 shows the configuration of the virtual template on the PAC. Only the relevant portion of the output is shown.

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
!

It is no surprise that the only authentication protocol configured on the virtual template interface is CHAP. To resolve this, authentication protocols must be modified 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 reconfiguration of the PPP authentication protocol on the virtual template interface.

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#

The remote access client/PNS now successfully connects to the PAC. This is verified using the show vpdn tunnel all command, as shown in Example 3-27.

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#

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

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 firewall 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 first 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

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.

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

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 identifies itself as Arizona_PAC.

After the MS-CHAP challenge has been sent to the remote access client/PNS, two Identification 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 specified 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-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
  [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#

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 confirms 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 configured on the PAC. This is corrected as shown in Example 3-30.

Example 3-30. Reconfiguration of the Remote Access Client's 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#

Once the username and password is reconfigured correctly, the remote access client/PNS reconnects and authentication succeeds. This is verified using the show vpdn session all command, as shown in Example 3-31.

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#

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 finally 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 configured 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 specified on both the PAC and the AAA server. Also ensure that the user password is correctly configured.

Finally, if you are using a RADIUS server, ensure that attribute type 6 (Service-Type) is configured as Framed, and that attribute type 7 (Framed-Protocol) is configured 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 traffic. MPPE is negotiated via the CCP. A number of MPPE configuration 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 configured, 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 configured to require encryption, and if the peer system is not configured for MPPE, negotiation failure will result.

As previously mentioned, one way in which tunnel establishment can fail is if MPPE is configured, but MS-CHAP is not specified 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.

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

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 PAC's hostname is identifiable 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.

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)

In highlighted line 1 (Example 3-33), the PPP phase changes to UP, and NCP negotiation begins.

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 significant because MPPE is a suboption of MS-PPC.

Have a close look at the supported bits specified in this CONFREQ: 0x01000020. Here the PAC is specifying that it supports stateless encryption (indicated by the most significant octet, 0x01), and that it also supports 40-bit MPPE session keys (least significant octet, 0x20). Note that stateless encryption means that session keys are calculated on a packet-by-packet basis.

Before continuing, it is worth briefly examining the MS-PPC supported bits.

Figure 3-32 illustrates the supported bits format.

Figure 3-32. MS-PPC Supported Bits

The supported bits field is four octets in length. Only the H (first octet), M, S, L, D, and C (least significant 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 configured to support both 40-bit and 128-bit session keys, the least significant 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 specified.

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)

In highlighted line 1 (Example 3-34), the remote access client/PNS sends a CONFREQ to the PAC. Once again, MS-PPC is specified, 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 specified.

The PAC then sends a CONFNACK in highlighted line 2, which again specifies 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.

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)

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 configuration of the same.

In Example 3-36, CCP negotiation succeeds.

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#

The PAC now sends a CONFACK to the remote access client/PNS acknowledging configuration 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 specified, 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 specified. Once again, for the sake of clarity, only the relevant section of the output is shown.

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

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.

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

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). There's something funny going on here.

CCP negotiation continues in Example 3-39.

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)

In highlighted line 1 (Example 3-39), a CCP CONFREQ is received from the remote access client/PNS. In it, MS-PPC is specified, 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 specified (stateless encryption and 40-bit session keys).

MPPE negotiation now fails, as shown in Example 3-40.

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

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 specified. In highlighted line 2, another CCP CONFREQ is received from the remote access client/PNS. Once again, no options are specified. The PAC then responds with a CCP CONFACK (highlighted line 3). This specifies no options either. This definitely 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.

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#

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.

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 confirms that MS-CHAP is specified as an authentication protocol on the remote access client/PNS. This leaves only one possibility: MS-CHAP is not specified as an authentication protocol on the PAC. You can confirm the authentication protocol that is configured using the show running-config command.

Example 3-42 shows the configuration of the virtual template interface.

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
!

As you can see from the configuration, only standard MD5 CHAP is specified, not MS-CHAP. The configuration is then modified to allow MS-CHAP authentication.

Example 3-43 shows the reconfiguration of authentication protocols on the virtual template interface.

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#

The remote access client/PNS then successfully reconnects.

Successful PPTP session establishment is verified using the show vpdn session all command, as shown in Example 3-44.

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
    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#

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 specified with the ppp encrypt mppe command under the virtual template, and MPPE encryption is not configured 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 configured to require data encryption (the Require data encryption box is checked under the Security tab of the Network/Dial-Up connection configuration in Windows 2000), but the PAC is not configured 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 configured 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.

Before examining what happens when IPCP negotiation is unsuccessful, it is useful to first 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.

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)

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 PAC's own IP address (192.16.1.1).

The remote access client/PNS now sends a CONFREQ as shown in Example 3-46.

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

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 configured to supply these options.

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)

In Example 3-48, the remote access client/PNS acknowledges the PAC's IP address by sending a CONFACK. Note that the ID (12) of this CONFACK is the same as the ID specified in the CONFREQ sent by the PAC in Example 3-45.

Example 3-48. Remote Access Client Acknowledges the PAC's 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

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 specified (all other options in the last IPCP CONFREQ having been rejected by the PAC in Example 3-47). Again, these addresses are specified as 0.0.0.0 to indicate to the PAC that these options should be supplied.

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)

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.

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)

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

The PAC then acknowledges the remote access client/PNS's CONFREQ in Example 3-51 by sending a CONFACK, as shown in Example 3-52.

Example 3-52. PAC Acknowledges the Remote Access Client/PNS's 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)

In Example 3-53, the IPCP negotiation succeeds.

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#

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

In highlighted line 2, IPCP negotiation begins with the remote access client/PNS sending a CONFREQ to the PAC. This CONFREQ specifies 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 finally Secondary NBNS Server address (option 0x84).

All the options are specified as 0.0.0.0. This is an indication to the PAC that it should supply these addresses.

Significantly, 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-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

PPP negotiation is now terminated, as demonstrated in Example 3-56.

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#

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 PAC's configuration is examined using the show running-config command, as shown in Example 3-57.

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
!

As you can see, the virtual template interface has not been configured with an IP address. This can be easily resolved.

Example 3-58 shows the configuration of ip unnumbered on the virtual template interface.

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#

ip unnumbered is configured 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 (verified using the show vpdn session all command).

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#

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:

[View full width]

TCP/IP CP reported error 733: Your computer and the remote computer could not agree on PPP
   control protocols.

IPCP Negotiation Fails Because of Insufficient 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 insufficient IP addresses within the IP address pool, or the lack of a configured 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-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)
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)

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.

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

In highlighted line 1 (Example 3-61), the remote access client/PNS sends an CONFREQ to the PAC, in which it specifies 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 configuration of IP address, Secondary DNS Server, and Secondary WINS Server options on this link.

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)

In Example 3-63, the remote access client/PNS sends a CONFACK to acknowledge the PAC's CONFREQ sent in Example 3-60 (highlighted line 2).

Example 3-63. Remote Access Client/PNS Acknowledges the PAC's 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

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.

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

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

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)

PPP negotiation is now terminated, as demonstrated in Example 3-66.

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#

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 PAC's configuration is then examined using the show running-config command.

Example 3-67 shows the PAC's configuration.

Example 3-67. Verifying the PAC's 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
!

As you can see, the PAC is configured 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 configured, as shown in Example 3-68.

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#

Once an IP address pool has been configured, PPTP tunnel and session setup succeeds.

Successful tunnel and session setup between the remote access client/PNS and the PAC is now verified using the show vpdn session all command, as shown in Example 3-69.

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
    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#

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-specific attributes are correctly configured. If these attributes are incorrectly configured, 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

In this scenario, the Microsoft MPPE vendor-specific attributes have been incorrectly configured on the RADIUS server.

The first 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.

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)

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 configuration 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 configuration 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/PNS's CONFREQ (highlighted line 3) are recognized but not acceptable. The PAC again specifies supported bits 0x01000020 as a hint to the remote access 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.

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

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.

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#

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.

Because MPPE attributes are configured on the RADIUS server, the debug radius command is used, as shown in Examples 3-73 to 3-74.

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

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/PNS's username and password.

In Example 3-74, the RADIUS server responds with an Access-Accept message.

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#

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-specific 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-specific 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 configured 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 configured under Interface Configuration, they have not been enabled in the group under which the user mjlnet has been configured.

Under Group Configuration, Microsoft RADIUS attributes (vendor-specific attribute 26, vendor-ID 311) 007, 008, 012 are configured as shown in Figure 3-34.

Figure 3-34. MPPE Attributes Under Group Configuration

[View full size image]

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 reconfigured, the remote access client/PNS successfully connects. This is verified using the show vpdn session all command, as shown in Example 3-75.

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#

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-specific 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 configuration, this issue is briefly 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.

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

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.

Note that you should always check your organization's 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 firewall 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.

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#

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

show vpdn tunnel

The show vpdn tunnel command shows basic information regarding specific tunnels, as shown in Example 3-78.

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#

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.

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#

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.

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.

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#

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.

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.

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#

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.

Example 3-82. debug ppp mppe eventCommand 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#

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

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.

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

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.

debug vpdn error

PPTP error information can be displayed using the debug vpdn error command, as shown in Example 3-84.

Example 3-84. debug vpdn errorCommand 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#

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.

Example 3-85. debug vpdn eventCommand 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#

In highlighted line 1, the virtual access interface is created, and in line 2, configuration 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.

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 specific information


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 configure Multilink PPP on the PPTP tunnel to the PAC. How can this be supported on the PAC?


Chapter 4. Troubleshooting the Layer 2 Tunneling Protocol Version 2 VPNs

Layer Two Tunneling Protocol (L2TP) version 2 is defined 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.

Figure 4-1. L2TP Compulsory Tunnel Mode

[View full size image]

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

[View full size image]

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.

  • 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 configuration 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 messages Used 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.

  • Data messages Used 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

[View full size image]

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

Figure 4-4. Overall L2TPv2 Packet Format

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.

Figure 4-5. L2TPv2 Message Header

The L2TP header consists of the following bits and fields:

  • 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 field is present. If the L bit is set to 1, the Length field is present. The Length field 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) fields 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 field. The Offset bit must be set to zero for all control messages.

  • 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 field 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 field comes the Length field. The Length field is 16 bits long and indicates the total length for the message in octets.

  • The Tunnel ID and Session ID fields are both 16 bits long. The Tunnel ID uniquely identifies the tunnel. This identifier is locally significant 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 identified 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 identified by tunnel ID 51 at the SP_LAC2 end and by tunnel ID 61 at the CorpX_LNS end.

  • The Session ID uniquely identifies the data session within the overall tunnel. Again, Session IDs are locally significant 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

    [View full size image]

    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 identified 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 identified 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) fields. The Ns field is 16 bits long and indicates the sequence number for this data or control message. The Nr field 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 specified.

  • The two final fields in the message header are the Offset size and Offset pad fields. The Offset size field and the Offset pad field are present only if the O bit is set to 1. The Offset size field 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 undefined in RFC 2661.

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.

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-Notification (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

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.

Figure 4-8. L2TP AVP Encoding Format

[View full size image]

The bits and fields 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 field 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 field itself is not present.

The Vendor-ID field 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 field is 0, then the AVP is one of those defined in RFC 2661.

  • The Attribute Type field is 16 bits long and indicates the type of message or data being passed in the AVP.

  • The Attribute Value field (which is of variable length) indicates the precise value of the message or data being passed in the AVP.

Thirty-eight AVPs are defined in RFC 2661. These fall into the following categories:

  • AVPs applicable to all control messages

  • The Result Code AVP

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

Table 4-2. AVPs Applicable to All Control Messages

Attribute Type

Attribute Name

Description

Present In

0

Message Type

Identifies the control message type

All message types

36

Random Vector

Used with hidden AVPs

All message types

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.

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

The precise meaning of the result code depends on whether it is carried within the StopCCN or CDN message.

Table 4-4 shows result codes carried in StopCCN messages.

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-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 fields was out of range or reserved field was nonzero

4

Insufficient resources to handle this operation now

5

The session ID is invalid in this context

6

A generic vendor-specific 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-5 shows result codes carried in CDN messages.

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

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-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-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 firmware 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

Specifies receive window size to peer (used for flow control)

SCCRQ / SCCRP

11

Challenge

Authentication challenge used during tunnel authentication

SCCRQ / SCCRP

13

Challenge Response

Response to authentication challenge received from peer

SCCRP / SCCCN

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.

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 significant identifier 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

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

Identifies physical channel used for call (vendor-specific 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

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.

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

30

Proxy Authen Name

Specifies 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

Specifies the ID used during authentication between the LAC and remote access client

ICCN

33

Proxy Authen Response

Specifies the authentication response received by the LAC from the remote access client

ICCN

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.

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

AVPs are sent in combination depending upon the specific control message type being sent. The function of specific 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 first 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.

Based upon the domain name of the remote access client (contained within the remote access client's username), the Dialed Number Identification 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_configuration_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 client's 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.

The first 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 sufficient 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 confirm 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 define 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.

Figure 4-10. Control Connection Establishment

Once the control connection has been established between the LAC and the LNS, data session establishment is ready to begin.

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 first message in the establishment of a data session is the Incoming-Call-Request (ICRQ) message. If there are sufficient resources available and the new session should be administratively permitted, the LNS responds to the LAC's 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.

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

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.

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.

Figure 4-13. L2TP Keepalive Mechanism

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.

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

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-Notification (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.

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.

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 configuring 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 confidentiality, 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.

Figure 4-19. 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."

Configuring L2TPv2

Although L2TPv2 configuration is not the primary objective of this chapter, it is worthwhile to review basic L2TPv2 configuration on Cisco routers. L2TPv2 configuration is discussed in this section.

Configuring L2TP Compulsory Tunnel Mode

There are several steps in the configuration of both the LAC and the LNS in compulsory tunnel mode. Each will be examined in turn.

Configuring the LAC

The steps involved in the configuration of the L2TP LAC are summarized below. Note that this configuration assumes that the LAC is configured with a Primary Rate ISDN interface, together with internal digital (MICA) modems.

Step 1. | Configure the E1/T1 controllers.
Step 2. | Configure global ISDN parameters.
Step 3. | Configure the D channels.
Step 4. | Configure parameters for asynchronous lines.
Step 5. | Configure group asynchronous interfaces.
Step 6. | Configure remote AAA (optional).
Step 7. | Globally enable VPDNs.
Step 8. | Configure VPDN groups.

The next few sections discuss each step in depth.

Step 1: Configure the E1/T1 Controllers

The first step is the configuration of the E1 or T1 controllers. This involves specifying the framing, linecode, clock source, and timeslots. These parameters should be configured per your service provider's specifications.

Example 4-1 shows an example of the configuration of an E1 Controller.

Example 4-1. Configuring the E1 Controller
controller E1 0/0
 pri-group timeslots 1-31

You'll notice in this configuration that only the pri-group timeslots are specified. This is because this configuration 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: Configure Global ISDN Parameters

After configuring the E1 or T1 controller, the next step is to configure global ISDN parameters. In this case, only configuration of the global ISDN switch-type is required.

Example 4-2 shows configuration of global ISDN parameters.

Example 4-2. Configuring the Global ISDN Switch Type
isdn switch-type primary-net5

The ISDN switch-type configured is Primary-net5, a switch-type common in Europe, Australia, New Zealand, and Asia.

Again, the ISDN switch type should be configured per your service provider's recommendation.

Step 3: Configure the D Channels

The next step is to configure the ISDN D channel or channels.

Example 4-3 shows configuration of a D channel.

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

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: Configure Parameters for Asynchronous Lines

Once the D channel configuration has been completed, the next step is the configuration of the modems and their corresponding asynchronous lines.

Example 4-4 shows configuration of the asynchronous lines.

Example 4-4. Configuring the Asynchronous Lines
line 3338
 modem InOut
 modem autoconfigure type mica
 autoselect ppp

The first line in Example 4-4 (line 33-38) allows lines 33 to 38 to be configured 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 confirm the line numbering of internal modems.

The next line shows the modem InOut command. The modem InOut command is used to configure the modems so that they are able to both receive and make calls.

Following modem InOut is modem autoconfigure type mica. This command allows the LAC to configure the internal modems automatically.

In the last line is the autoselect ppp command. This allows PPP to be autodetected and configured on the line.

Step 5: Configure Group Asynchronous Interfaces

Once the modem lines have been configured, it is time to configure the corresponding asynchronous interfaces. Logical configuration, such as IP addresses, is applied to the asynchronous interfaces. Again, the most efficient way to configure the asynchronous interfaces is in a group.

Example 4-5 shows configuration of the asynchronous interfaces.

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

The first 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 configuration in Example 4-5 contains the command ppp authentication chap. This command is used to configure 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. It's 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 client's username, and within that, its domain name (in the format @domain_name). The domain name is then used to associate the remote access client's PPP session to the appropriate L2TP tunnel.

Note that it is also possible to associate the remote access client's 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 final command in Example 4-5 is group-range 33-38. This command is used to apply the group-async configuration to each of the internal digital modem lines in turn.

Step 6: Configure Remote AAA (Optional)

The next optional step in configuring the LAC is the configuration 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 configuring per-user VPDN or you are using tunnel definitions (tunnel configuration 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 configuration.

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

The first 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 configure 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 configures the default method list for logins to the LAC. The first 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 configured 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 configuration.

Next is the aaa authentication ppp default group radius command. This command configures the default method list for PPP authentication on the LAC. The method list specifies RADIUS authentication.

The fourth line in the configuration (aaa authorization network default group radius) is used to configure authorization for network connections from the LAC. Once again, network authorization is configured using the default method list. In this case, RADIUS is specified by the method list for authorization of network connections.

Following network authorization, AAA accounting is configured for network connections using the default method list (aaa accounting network default start-stop group radius). Accounting is configured on start and stop events. This means that an accounting notification is sent to the RADIUS server when a network connection is initiated. Similarly, an accounting notification 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 configuration.

The final line of the configuration 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 configure authentication and authorization on port 1812 and accounting on port 1813.

The final 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: Misconfigured L2TP Tunnel Definition on an AAA RADIUS Server" for more details on tunnel definitions and Cisco.com for more details on per-user VPDN.

Step 7: Globally Enable VPDNs

The next step in the configuration 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: Configure VPDN Groups

The final mandatory step in the configuration of the LAC is the configuration of the L2TP tunnel itself. The configuration 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 definition.

Example 4-7 shows an example of the configuration of a VPDN group.

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

The first 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 client's 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 configuration command can be used to associate a DNIS string (number) with an L2TP tunnel.

The second line in the configuration is the command vpdn-group 1. This command is used to begin the configuration 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 configure the LAC to accept remote access client PPP sessions and attempt to tunnel them to a specified 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 fifth line of the configuration is domain mjlnet.com. This command is used to configure 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 specified 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 final 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 configuration for a LAC.

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
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 client's 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
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

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

Configuring the LNS

Configuration of the LNS can be summarized as follows:

Step 1. | Globally enable VPDNs.
Step 2. | Configure VPDN groups.
Step 3. | Configure the virtual templates.
Step 4. | Create IP pool(s) and configure DNS/WINS server addresses.
Step 5. | Configure either local authentication or remote AAA.
Step 1: Globally Enable VPDNs

The first step in the configuration 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: Configure VPDN Groups

After globally enabling VPDNs, the next step is the configuration of the VPDN group or groups.

Example 4-9 shows the configuration of a VPDN group.

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

The first line in the configuration 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 configuration is the specification of the VPDN protocol. This is configured 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 configuration cloned (copied) from virtual template interface 1.

Virtual-access interfaces are virtual interfaces that are dynamically created as required and take their configuration from a virtual template interface. One virtual access interface is created per PPP session.

Once the virtual template interface has been specified, the next step is to allow termination of VPDN tunnels from the specified LAC, using the terminate-from hostname command. In this case, VPDN tunnels from CalCity_LAC are allowed.

The final step is the shared L2TP tunnel password. This is configured 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.

Step 3: Configure the Virtual Templates

After configuring the VPDN group, the next step is the configuration of the virtual template interface.

Example 4-10 shows the configuration for a virtual template interface.

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

The configuration of the virtual template interface begins with the command ip unnumbered ethernet 0/0. This is used to specify that the IP address configured 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 specifies that remote access clients should be assigned an IP address from the specified pool, which in this example is SKYDANCE_POOL.

Another option for IP address assignment is the Dynamic Host Configuration Protocol (DHCP). This can be specified using the peer default ip address dhcp and ip dhcp-server {server_name | server_ip_address} commands.

Example 4-11 shows the configuration for assigning IP addresses to remote access clients using DHCP.

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
!

In Example 4-11, the ip dhcp-server {server_name | server_ip_address} global configuration command is used to specify the DHCP server name or IP address. The peer default ip address dhcp interface configuration command is then used to specify that addresses should be assigned to clients using DHCP.

The third line in the configuration (in Example 4-10) is the ppp authentication chap command. This command ensures that PPP sessions from remote access clients are authenticated using CHAP.

The final command in the configuration of virtual template is the optional ppp multilink command. This command enables multilink PPP (MP).

Note that it is also possible to store user-specific interface configuration on a AAA server, and this configuration is downloaded to the Home Gateway as remote access clients connect. For some examples of this (in the form cisco-avpair = "lcp:interface-config=") refer to the document entitled "Configuring Virtual Profiles" 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 configured 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 Configure DNS/WINS Server Addresses

The next step is the configuration 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: Configure the Virtual Templates") or from a AAA server can also be used. Example 4-12 shows the configuration of a local IP address pool and DNS and WINS server addresses.

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

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 configuration. 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 specified (10.2.2.99 and 10.2.2.100, respectively).

Step 5: Configure Either Local Authentication or Remote AAA

The last step in the configuration of the LNS is the configuration of either local authentication or remote AAA for remote access clients.

Local authentication can be configured by simply specifying usernames and passwords.

Example 4-13 shows the configuration of usernames and passwords for local authentication.

Example 4-13. Configuring Local Authentication
username TATEBAYASHI@mjlnet.com password cisco1
username joebloggs@mjlnet.com password cisco2
username ltahoe@mjlnet.com password cisco3

A more scalable solution is to configure remote AAA on the LNS. In this example, RADIUS is used for remote AAA.

Example 4-14 shows a sample configuration for remote AAA.

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

The aaa new-model command is used to enable AAA on the LNS.

The second command in the configuration is the aaa authentication login default group radius local, which configures the default method list for logins to the LNS. The first 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 configuration.

Next comes the aaa authentication ppp default group radius command, which defines a default method list for PPP. The method specified for authentication is RADIUS.

The fourth line in the configuration contains the command aaa authorization network default group radius, which configures a default method list for network connections, with RADIUS specified for authorization.

The aaa accounting network default start-stop group radius command is next. Accounting is configured on start and stop events. When a network connection is initiated, an accounting notification is sent to the RADIUS server. Furthermore, when that network connection is terminated, an accounting notification 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 configuration.

The final command is radius-server host, which specifies 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 configuration 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
!
!  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

As a final word before completing this section, many problems can be avoided by configuring both the LAC and the LNS incrementally. For example, when configuring the LAC, first configure and verify basic asynchronous dialin. Then configure and enable VPDN groups. Also, even if the intent is to use remote AAA, it might be a good idea first to configure local authentication to test the VPDN configuration before introducing remote AAA.

Configuring L2TP Voluntary Tunnel Mode

Configuration 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 configuration of the LNS remains largely the samethe difference is the configuration of the VPDN group.

Example 4-16 shows the configuration of the VPDN group in voluntary tunneling mode.

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

There are two differences in the configuration 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 (configured on the virtual template interface using the ppp authentication command) is used to authenticate the client/LAC.

Configuring IPSec Protection for L2TP in Compulsory Tunnel Mode with Preshared Keys

The configuration of IPSec for L2TP with preshared keys can be broken down into six steps. The steps are as follows:

Step 1. | Configure the Internet Key Exchange (IKE) policy
Step 2. | Configure the preshared key
Step 3. | Configure the transform set
Step 4. | Configure the crypto map
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 configuration of IPSec on the LAC.

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
!

In highlighted line 1, IPSec protection for L2TP tunnels is configured. Note the policy name referenced (l2tp).

Highlighted lines 2 and 3 show the configuration of the IKE policy. This policy configures authentication with preshared keys, encryption as DES, Diffie-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 configuration.

Configuration 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 configured next (highlighted lines 5 and 6). The name of the transform set is l2tptransform, and it specifies ESP DES encryption and SHA-1 authentication. Note that the mode is configured as transport. This is because the L2TP packets are being protected, and the L2TP tunnel terminates on the LNS.

Highlighted lines 7 and 8 define the crypto map. The crypto map is called l2tpcryptomap and specifies that ISAKMP will be used to establish IPSec security associations. The profile keyword designates this crypto map as a template so that individual crypto maps can be created on demand. The profile 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 configured on the interface (Fast Ethernet 0/0) on which the IPSec tunnel will be established.

Configuration of the LNS is almost identical.

Example 4-18 shows the configuration of IPSec on the LNS.

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
!

As you can see, the only difference in the configuration is that the address of the LAC (172.16.1.1) is specified 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 "Configuring the LNS," as well as Chapter 8 for more details. Also see Chapter 8 if you want to configure IPSec with digital certificates instead of preshared keys.

Configuring 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 configured for L2TP over IPSec, the LNS must also be configured to support IPSec.

Example 4-19 shows a sample configuration for L2TP over IPSec in voluntary tunnel mode using preshared keys.

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
!

Again, the IPSec configuration is identical to that for compulsory tunnel mode, with the exception that the peer address is configured as a wildcard (0.0.0.0).

Also, if you want to configure IPSec with digital certificates instead of preshared keys, see Chapter 8.

Troubleshooting L2TPv2

If you want to troubleshoot L2TP in a fast and efficient manner, a good knowledge of the underlying theory of operation and configuration is essential. In addition, if the LAC is 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 briefly re-examining the overall tunnel establishment model for L2TP.

Figure 4-20 shows the L2TP tunnel establishment model.

Figure 4-20. L2TP Tunnel Establishment

[View full size image]

Figure 4-20 illustrates the following steps:

1. | Assuming that the remote access client is using asynchronous dial to connect to the LAC, the first step in the tunnel establishment model is the reception of the call from the remote access client on the LAC. 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 field in the response message to see whether there is a domain name (in the form @domain_name) that corresponds to a domain specified 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 (specified 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 configured 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 configured, 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, configuration 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.

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 configuration

Data link issue

Data link issue

DUN misconfigured

Modem configuration

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 misconfiguration

Not switched on

Tunnel authentication

PPP authentication mismatch

Cabling issue

AAA server issues

Authentication failure

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 configuration, you should have an excellent foundation for quickly and efficiently 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 flowchart in Figure 4-22 describes the troubleshooting process used with L2TP version 2. You can use this flowchart to access quickly the section of the chapter relevant to problems you are experiencing on your network.

Figure 4-22. L2TP Troubleshooting Flowchart

[View full size image]

The following sections detail end-to-end troubleshooting of L2TP, beginning with call reception on the LAC.

Call Reception on the LAC

The first step in troubleshooting compulsory tunnel mode is to confirm that calls are being successfully received on the LAC. This section assumes that the LAC is configured with a Primary Rate ISDN interface, together with internal digital (MICA) modems.

Figure 4-23 illustrates reception of the remote access client's 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 first step is the reception of the call on the Primary Rate ISDN interface. Therefore, the first thing that you need to do is to confirm 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#

The first highlighted line in Example 4-20 shows the globally configured isdn switch-type (Primary-net5).

The next highlighted line shows that the ISDN switch type is configured 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 specified 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 Office (CO).

The final 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.

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#

The first 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-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

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.

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

As you can see in the first 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-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
    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#

The first 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 configuration of framing, line code, or clock source. Always make sure that these parameters are configured per your service provider's recommendations. Additionally, ensure that the ISDN switch type and encapsulation are set correctly.

Now that you have verified 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.

Example 4-25. Good Output of the debug isdn q931 Command
[View full width]
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
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#

In the first 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.

Example 4-26. Verifying Call Reception on the Digital Modems
[View full width]
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,
   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#

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 configured on the ISDN D channel and that the modem InOut command is configured 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.

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 briefly 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 first 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 first 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#

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.

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#

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.

Examples 4-29 to 4-41 show successful LCP negotiation between LAC and remote access client.

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]

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 first stage of PPP negotiation is LCP negotiation.

The LAC now sends an LCP Configure-Request (CONFREQ) to the remote access client as shown in Example 4-30 (the O indicates that the CONFREQ is outgoing).

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)

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 configure. The LCP options are shown in the five 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 first LCP option specified 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 flow 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.

The second LCP option in the CONFREQ is authentication protocol (0x03). The authentication protocol specified 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 fields that are compressed.

The final LCP option specified is ACFC (0x08). PPP frames are normally sent with leading HDLC Address and Control fields. In this case, the LAC is telling the remote access client that it can receive PPP frames without these HDLC fields.

The remote access client responds with an LCP Configure-Ack (CONFACK) (incoming [I]) as shown in Example 4-31.

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)

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 five 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 LAC's CONFREQ. There is, however, one minor difference. You will notice that the MagicNumber specified is different than that specified in the LAC's 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.

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)

The LCP options contained in the remote access client's CONFREQ (Example 4-32) have all been described previously, with the exception of Callback (0x0D), Multilink-Maximum-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 Configure-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.

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

Shortly after sending the CONFREJ, the LAC sends another CONFREQ to the remote access client, as shown in Example 4-34.

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)

Again, the LCP options specified 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 first CONFREQ sent by the LAC.

In Example 4-35, the remote access client again acknowledges the LCP options sent in the LAC's CONFREQ.

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

The LAC now sends yet another CONFREQ with the same LCP options, as shown in Example 4-36.

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)

Once again, in Example 4-37, the remote access client acknowledges the CONFREQ from the LAC with a CONFACK.

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)

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 specified in the previous CONFREQ (Example 4-32).

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)

Once again, the LAC rejects both the Callback and MRRU options by sending a CONFREJ message, as shown in Example 4-39.

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)

Another CONFREQ is received from the remote access client in Example 4-40.

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)

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 client's CONFREQ, and the LCP state changes to Open.

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#

In highlighted line 1 (Example 4-41), the LAC acknowledges the LCP options in the remote access client's 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 configuration 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 configured to authenticate using only CHAP, but the remote access client was configured to authenticate using only PAP.

Partial PPP Authentication Fails on the LAC

Once you have verified 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.

Example 4-42. Successful Partial PPP Authentication on the LAC
[View full width]
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#

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 identifies itself as ltahoe@mjlnet.com. This is the remote access client's user name.

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. Specifically, 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, Identification) 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
  [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#

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

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
  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#

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 client's domain name (obtained during authentication) to a L2TP tunnel. The remote access client's 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 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 client's domain name or the DNIS to a tunnel. The LAC is configured to associate domain name with the L2TP tunnel, so this would indicate that either the remote access client's domain name is incorrectly configured or the domain name specified in the VPDN group is wrong.

It should be clear from the output in Example 4-44 that the remote access client's domain name (mjlnet.com) is in fact correctly configured. The problem, therefore, must be with the VPDN group.

The configuration of the LAC is examined and the problem is revealed. Example 4-45 shows the incorrect configuration for the VPDN group domain name on the LAC. Note that only the relevant portion of the output is shown.

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
!

As you can see, the domain name configured for the VPDN group (disco.com) is not consistent with the remote access client's domain name (mjlnet.com). The issue is resolved by modifying the domain name configured under the VPDN group.

Example 4-46 shows reconfiguration of the domain name under the VPDN group.

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#

When the remote access client reconnects to the LAC, L2TP tunnel establishment succeeds. This is verified 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-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#

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 LNS's 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.

Figure 4-25. L2TP Tunnel Setup Initiation

[View full size image]

The first 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 sufficient 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 configured to terminate L2TP tunnels from the LAC in question, it simply discards the message.

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
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#

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 client's call has been received on the LAC.

Highlighted line 3 shows the first 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 confirm this, use the show vpdn tunnel all command, as demonstrated in Example 4-49.

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#

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 finally 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 firewalls) blocking L2TP itself (UDP port 1701).

  • The LNS's IP address is incorrectly specified on the LAC. Check this by examining the IP address for the LNS configured using the initiateto ip LNS_address command under the VPDN group. If you are using tunnel definitions, also check the IP address specified on the AAA server.

  • The LNS does not recognize the LAC. Verify this by checking that the LAC's name is specified correctly with the terminate-from hostname LAC_name under the VPDN group.

  • The LNS is not configured 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.

Examples 4-50 to 4-53 show the output of the debug vpdn l2x-events command when tunnel setup is not successful.

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

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.

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

The LAC now resends the SCCRQ, as demonstrated in Example 4-52.

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,
  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

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 first and fifth 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.

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#

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 configuration of the VPDN group on the LNS is now examined. Example 4-54 shows the output of the show running-config command on the LNS. Only the relevant portion of the output is shown.

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
!

As you can see, highlighted line 2 shows that the LNS is correctly configured to terminate tunnels from the LAC (CalCity_LAC).

Highlighted line 1, however, shows that the LNS is unfortunately configured to terminate not L2TP but instead L2F tunnels. There is no way that is going to work. The VPDN group needs to be reconfigured to terminate L2TP instead of L2F tunnels.

Example 4-55 shows reconfiguration of the VPDN group to terminate L2TP tunnels.

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#

In highlighted line 1, the protocol is changed to L2TP.

One thing to notice in the reconfiguration of the VPDN group is that after the protocol has been modified 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 reconfigured, the remote access client reconnects to the LAC. This time tunnel setup is successful. Successful tunnel establishment is verified 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-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#

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 notifies 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 first 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.

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.

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

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 LAC's 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.

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

In Example 4-59, the LNS responds with an SCCRP.

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

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

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.

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

The SCCCN shown in Example 4-50 contains the LAC's 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.

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

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

The LNS responds with a SCCRP, as shown in Example 4-63.

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

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 LNS's 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.

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

The L2TP tunnel is finally shut down in Example 4-65.

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
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#

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 configured on the LNS. It could be that the password is incorrectly configured 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 LNS's configuration files), it is impossible to know whether the password is incorrectly configured on the LAC or the LNS. The password must, therefore, by reconfigured on both.

Example 4-66 shows the reconfiguration of the L2TP tunnel password on the LAC and the LNS.

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#

After the L2TP tunnel passwords on the LAC and the LNS are reconfigured, the remote access client reconnects. This time, L2TP tunnel setup is successful. This is confirmed 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 its IP address and the UDP port over which the connection has been established (172.16.5.5 and 1701, respectively).

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#

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 traffic will not be passed over the tunnel between the LAC and the LNS.

L2TP session setup is illustrated in Figure 4-26.

Figure 4-26. L2TP Session Establishment

[View full size image]

To establish the data session, the LAC sends an ICRQ message. Assuming that sufficient 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-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#

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.

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#

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 configuration 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 configured, VPDN softshut can give the appearance of an error.

When troubleshooting this "issue," the first 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 configured on the LNS.

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

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.

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

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.

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

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.

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#

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.

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#

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-specific 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 configured 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 configured on the LNS.

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.

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#

Highlighted line 1 shows that one tunnel and one session are established.

The configuration of the LNS is then examined using the show running-config command. Example 4-76 shows the output of the show running-config command on the LNS. Note that only the relevant portion of the output is shown.

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
!

In highlighted line 1, you can see that VPDN softshut is indeed configured 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.

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#

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.

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#

Note that there are now two sessions within the tunnel to the LNS (highlighted line 1). The issue has been resolved.

As previously mentioned, this issue can also occur if a session limit is configured using the vpdn session-limit sessions command. This command limits the number of sessions to the number specified. 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. Specifically, the LNS must complete LCP negotiation and PPP authentication and then negotiate NCPs with the remote access client. Note that the LNS can be configured 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

[View full size image]

You can use the debug vtemplate command to verify cloning of virtual template configuration to virtual access interfaces, as demonstrated in Example 4-79.

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#

Highlighted line 1 indicates that configuration is about to be cloned to virtual access interface 1. In highlighted line 2, configuration is cloned from virtual template interface 1 to virtual access interface 1.

From highlighted lines 3 to 7, the configuration 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-config command to verify that the virtual template is corrected referenced, as shown in Example 4-80.

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
!

In this example, the virtual template interface is correctly referenced under the VPDN group.

If user-specific configuration is stored on a AAA server, make sure that as you troubleshoot PPP negotiation you verify this configuration, 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

[View full size image]

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.

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.

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

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.

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)

Highlighted line 1 (Example 4-82) shows an inbound (I) FORCED CONFREQ. This CONFREQ has special significance. 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-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)

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 configuration 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 configure 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.

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

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

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.

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#

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 configured on either the remote access client or the LNS. In this case, the remote user confirms that the username and password are correct. This means that either the username or password for the remote access client is incorrectly configured on the LNS. The username and password are then reconfigured on the LNS.

Example 4-87 shows the reconfiguration of the remote access client's username and password on the LNS.

Example 4-87. Remote Access Client's 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#

Once the remote access client's username and password are reconfigured, the remote access client reconnects. PPP negotiation is now successful.

Successful PPP negotiation, including authentication, is verified using the show caller user command, as demonstrated in Example 4-88.

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#

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 client's 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 confirmed, 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."

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 misconfiguration 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

[View full size image]

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.

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.

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

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

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)

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

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)

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 configured 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 configuration of the CCP, including MS-PPC.

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)

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 DNS (0x83, Secondary DNS Address), and finally Secondary WINS (0x84, Secondary NBNS Address).

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)

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

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

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.

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)

It is worth noting that if you configure the ip tcp header-compression command on the virtual template interface (it is not configured 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 LNS's IP address (172.16.5.5) using a CONFACK message. This CONFACK is an acknowledgment of the LNS's first 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).

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)

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

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)

The LNS now sends a Configure-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).

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)

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 confirm the addresses sent by the LNS in the CONFNAK message in Example 4-98.

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)

Finally, in Example 4-100, the LNS acknowledges the CONFREQ (in Example 4-99) using a CONFACK.

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 shows that the LNS and the remote access client have successfully negotiated IPCP.

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#

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.

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

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

In Example 4-104, the LNS rejects configuration of the CCP by sending a Protocol-Reject (PROTREJ) to the remote access client.

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)

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.

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)

Then something strange happens, as Example 4-106 demonstrates. The LNS sends a PROTREJ message to the remote access client rejecting configuration of IPCP.

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)

PPP is finally terminated in Example 4-107.

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#

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 configuration of IPCP on virtual-access interface 1? The LNS will reject configuration of IPCP on the virtual-access interface if the virtual-access interface is not configured with an IP address. The virtual-access interface is dynamic in nature and takes its configuration from virtual template interface.

The next step is to examine the configuration of the virtual template interface associated with the VPDN group using the show running-config command.

Example 4-108 shows the output of the show running-config command. Only the relevant parts of the configuration are shown.

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
!

As you can see, no IP address has been configured on virtual template interface 1 (highlighted line 3). This is the configuration 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 configured on the virtual template interface.

Example 4-109 shows the configuration of an IP address on the virtual template interface.

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#

Once an IP address (ip unnumbered ethernet 1/0) is configured 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.

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#

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 configured on virtual-access interface 1 (172.16.5.5), together with the IP address configured 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.

Figure 4-30. Topology for 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.

Case Study 1: Misconfigured L2TP Tunnel Definition on an AAA RADIUS Server

An alternative to storing tunnel configuration within VPDN groups on the LAC is to store it on an AAA server as tunnel definitions. Storing tunnel definitions 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 definitions can be specified using either Cisco AVPs or IETF standard VPDN tunnel attributes as defined 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 definitions. However, misconfiguration of the L2TP tunnel definition prevents successful establishment of the L2TP tunnel. Call reception on the LAC has been successful, but L2TP tunnel setup has failed.

When troubleshooting tunnel definitions 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.

Example 4-111. Misconfigured L2TP Tunnel Definition Is Sent from the RADIUS Server
[View full width]
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'

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 definition on the RADIUS server is associated with user mjlnet.com.

Authorization of user mjlnet.com now begins, as shown in Example 4-112.

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)

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-113. Authorization Is Successful for mjlnet.com
[View full width]
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#

Authorization for user mjlnet.com has succeeded in highlighted line 1 (Example 4-113), and a number of attributes that make up the tunnel definition 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 fine, and then it all went wrong. You can obtain more information using the debug radius command, as demonstrated in Example 4-114.

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
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#

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.

The tunnel definition 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.

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#

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

So far, you know that the call is being received from the remote access client, authentication and authorization are successful, and the tunnel definition 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.

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#

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 find out why. You can accomplish this with the debug vpdn l2x-errors command, as demonstrated in Example 4-117.

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#

The output is reporting the error L2TP: Could not find 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 significance 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 definition from the RADIUS server was, in fact, 12. The LNS is clearly unable to find 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 specified by the terminate-from command in the VPDN group on the LNS. The VPDN group is then examined using the show running-config command.

Example 4-118 shows the configuration of the VPDN group on the LNS. Note that only the relevant portion of the output is shown.

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
!

As you can see, the LNS is not configured to terminate tunnels from a LAC with hostname 12. It is configured to terminate tunnels from CalCity_LAC. So the problem is with the tunnel ID defined on the RADIUS server. It must be modified to correspond to the hostname of the LAC (CalCity_LAC).

Figure 4-31 shows the erroneous L2TP tunnel definition configuration within Group Setup on the CiscoSecure ACS. Note that the group corresponds to user mjlnet.com.

Figure 4-31. Erroneous L2TP Tunnel Definition

[View full size image]

As you can see, the VPDN tunnel ID is configured as 12. The tunnel ID is modified to reflect the hostname of the LAC (Calcity_LAC).

Figure 4-32 shows the new configuration of the VPDN tunnel ID within Group Setup on the CiscoSecure ACS.

Figure 4-32. Modified Tunnel ID

[View full size image]

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
    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#

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 LNS's 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 LAC's 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 definitions are user password misconfiguration, service-type (attribute 6) misconfiguration, and IP address assignment. When configuring tunnel definitions, ensure that the password of the user (domain) associated with the tunnel definition 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 configured 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 specified 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 briefly examining an L2TP tunnel definition in Merit format using Cisco AVPs.

Example 4-120 shows an L2TP tunnel definition on a Merit RADIUS server.

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"

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 difficult than troubleshooting local authentication.

The first command used when troubleshooting this issue is debug ppp negotiation. You can use this command to confirm 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.

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#

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

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#

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-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#

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 client's 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 configured on either the remote access client or the RADIUS server. In this case, the remote access client confirms that the username and password are correctly configured. Therefore, one or the other must be incorrectly configured 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 configuration within the user setup.

Figure 4-33. Password Configuration

[View full size image]

The remote access client reconnects, and authentication succeeds. This is confirmed 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
          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#

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 configured 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 configured correctly, authorization will fail. If authorization fails, PPP negotiation with the remote access client will also fail.

To debug an authorization failure, the first command to use is the debug ppp negotiation command, as demonstrated in Example 4-125. Only the relevant portion of the output is shown.

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#

In highlighted line 1, the PPP phase changes to AUTHENTICATING, and authentication begins. The first 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 finally 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.

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'

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-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#

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-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#

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 configured within the user's group settings.

Figure 4-34. IETF RADIUS Attributes Configured in the Group Settings

[View full size image]

As you can see, the Service-Type attribute is configured as Framed, but the Framed-protocol is not checked. This is the problem. The Framed-protocol should be checked and specified as PPP, as shown in Figure 4-35.

Figure 4-35. Framed-protocol Is Specified as PPP

[View full size image]

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 confirm 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
  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#

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 configured 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 configured) are reachable. To troubleshoot AAA server connectivity problems, the first 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.

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

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 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 client's CHAP response.

Example 4-131. LNS Is Unable to Validate the Remote Access Client's 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#

In highlighted line 1 (Example 4-131), the LNS reports that it is unable to validate the remote access client's 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-132. debug aaa authentication Command Output
[View full width]
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'
  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#

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.

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
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#

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 client's 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 finally 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, misconfiguration of the RADIUS server's 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.

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#

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 verified by using the show caller user command in Example 4-135.

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#

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 configured 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 configuration 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 configured 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.

Figure 4-36. Error Message on the Windows 2000/Client LAC

[View full size image]

The Error Message in Figure 4-36 reveals that the Windows 2000 client/LAC does not have a certificate. You may be wondering what a certificate has to do with an L2TP tunnel. The certificate is needed because, by default, Windows 2000 is configured 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.

Figure 4-37. L2TPv2 over IPSec Between a Windows 2000 Client/LAC and the LNS

There are two choices, therefore, when configuring 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 certificates 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 modified to disable IPSec protection for L2TP tunnels.

Figure 4-38. Modification of the Registry on the Windows 2000/LAC

[View full size image]

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
  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#

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 configure 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 configured for L2TP over IPSec using preshared keys.

NOTE

To configure 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.

Configure the Cisco LNS according to the instructions contained in the section entitled "Configuring IPSec Protection for L2TP in Voluntary Tunnel Mode with Pre-Shared Keys" at the beginning of this chapter.

Once IPSec has been configured, the Windows 2000 client/LAC successfully connects to the LNS. Verify connectivity using the show vpdn tunnel command, as demonstrated in Example 4-137.

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#

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-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#

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
[View full width]
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_port_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
     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-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 configuration 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.

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
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#

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

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#

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.

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 peer's 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 first 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 "Configuring 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
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#

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

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

Highlighted line 1 shows a L2TP data packet being received. Notice the Length (L) flag 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,
  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

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) fields 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 fields 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 flags 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.

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#

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.

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#


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.

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#

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

If local authentication is configured for the remote access client, check the username/password database to ensure that both username and password are correctly configured. If remote AAA is being used, check that the username and password are correctly configured on the AAA server. Finally, ensure that username and password are correctly configured on the remote access client.

In the case of tunnel authentication failure, ensure that the tunnel password is correctly configured either locally on the LAC/LNS (vpdn group group_name…..l2tp tunnel password password) or on the AAA server with the tunnel definition.

%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 configuration of the LAC/LNS (ensure that the IP address/UDP port of the AAA server is correctly configured). 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 configured on the LAC/LNS (aaa authorization…), and make sure that attributes are correctly configured 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 configurable via the vpdn session-limit command. To resolve this error, either remove the session limit or adjust it upward.

%VPDN-4-MIDERROR

This is a generic error that indicates that there is a configuration or resource issue on the LNS. Check the LNS to ensure correct configuration.

%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 LNS's configuration to ensure that it is correct.

%VPDN-6-SOFTSHUT

If you see this message, it indicates that VPDN softshut has been configured 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.

%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 configured on the LAC with the initiate-to ip command within the VPDN group. If tunnel definitions are stored on the RADIUS server, ensure that the IP address is correctly configured within the tunnel definition.

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 specified L2TP tunnel


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 insufficient 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 configuration on the LAC, what is an alternative?

8:

What is the significance of the tunnel ID in the tunnel definitions on an AAA server?

9:

You suspect that the remote access client's password is incorrectly configured, 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.

Figure 4-39. L2TPv2 Lab Topology

[View full size image]

The goal of each lab is to restore connectivity from a remote access client (joebloggs@mjlnet.com) to Skydance_LNS. Base configurations for the labs can be found on the Cisco Press Web site (www.ciscopress.com/1587051044). Detailed instructions for loading these base configurations onto your lab routers can be found in Appendix B.

L2TP Troubleshooting Lab 1

Q1:

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:

________________________________________________________________

________________________________________________________________

________________________________________________________________

________________________________________________________________

L2TP Troubleshooting Lab 2

Q1:

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

Q1:

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:

________________________________________________________________

________________________________________________________________

________________________________________________________________

________________________________________________________________

Actions:

________________________________________________________________

________________________________________________________________

________________________________________________________________

________________________________________________________________

Resolution:

________________________________________________________________

________________________________________________________________

________________________________________________________________

________________________________________________________________

Note that all the solutions for the L2TP troubleshooting labs are detailed in Appendix B.


Chapter 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

[View full size image]

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.

Figure 5-2. LNS to LNS Tunneling Model

[View full size image]

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

[View full size image]

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

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.

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)

Cisco's 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 firewall.

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

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 first 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 fields in the L2TPv3 control message:

  • The first 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 flags. The first 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 field 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) fields 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 fields are no longer present.

  • The Ver (version) field is 4 bits long and must be set to 3 to indicate that this is an L2TPv3 control message.

  • The Length field 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 field. Again, if you are familiar with L2TPv2, you will notice that this field has replaced the Tunnel ID field. The Control Connection ID is locally significant 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 identified 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 identified by Control Connection ID 3001 on Frankfurt_LCCE and by Control Connection ID 2001 on London_LCCE.

  • The Ns (Next sent) field is 16 bits long and indicates the sequence number for this control message.

  • The Nr (Next received) field 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.

Control Message Types

Table 5-1 lists the 14 different types of control messages as defined by L2TPv3.

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-Notification (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

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.

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 fields in the AVP encoding format are defined 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 configured on peer LCCEs.

  • Four reserved bits (RSVD) follow the H bit. These must be set to zero.

  • The 10-bit Length field indicates the overall length of the AVP in octets. The minimum length is 6 (indicating that the value field is absent), and the maximum length is 1023.

  • The 16-bit Vendor-ID field 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) defined AVP.

  • The 16-bit Attribute Type field specifies the type of AVP.

  • The variable-length Attribute Value field specifies the associated value.

Internet Draft draft-ietf-l2tpext-l2tp-base (L2TPv3) defines a number of different AVPs. These fall into five categories:

  • General control message AVPs

  • The result code AVP

  • Control connection management AVPs

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

Table 5-2. General Control Message AVPs

Attribute Type

Attribute Name

Description

Present In

0

Message Type

Defines 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

The Message Type, Message Digest, and Control Message Authentication Nonce AVPs are of particular significance. The Message Type AVP is used to define 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-Notification (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-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

When included with a StopCCN message, the result code values are as shown in Table 5-4.

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

When included with a CDN message, the result code values are as shown in Table 5-5.

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 specified 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-specific 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-specific sublayer

TBA4

Finite state machine error or timeout

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 fields. If the Error Code field is included, the Error Code values are those shown in Table 5-6.

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 field values was out of range

4

Insufficient resources to handle this operation now

5

Invalid Session ID

6

A generic vendor-specific 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)

Finally, the optional Error Message field 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-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

Identifies 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

10

Receive Window Size

Receive window size offered to the remote LCCE (used for flow 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

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.

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

Identifies 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

TBA

Pseudowire Type

Used to specify the Layer 2 payload type of frames carried by this session

ICRQ

TBA

L2-Specific Sublayer

Used to specify the Layer 2 specific sublayer that the sender requires for a specific 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 specific)

ICRQ / ICRP

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

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

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 find it very difficult, if not impossible, to insert packets into a data stream (pseudowire) if the attacker is unable to sniff packets transiting the network between peer LCCEs. This is because of the difficulty of guessing the correct cookie value (0 to 264 if the cookie is 64 bits in length).

Session IDs and cookie values are locally significant 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 significant 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

[View full size image]

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 significance and are used only for illustrative purposes.

The next portion of the data message is the Layer 2 specific sublayer. The Layer 2 specific sublayer can be used to provide additional functionality, such as data message sequencing and packet priority settings.

A default Layer 2 specific sublayer is defined 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 field contains a valid sequence number. Bits marked as x are undefined 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 Specific 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 LCCE's 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 LCCE's 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 LCCE's random number (nonce), a shared-key generated from a shared L2TPv3 password, and the L2TPv3 control message itself (header and AVPs).

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 LCCE's 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

[View full size image]

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

[View full size image]

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.

Figure 5-14. Hello Message

[View full size image]

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

[View full size image]

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 StopCCN's Result Code AVP), see Table 5-4. If any sessions remain active, they are torn down at the same time as the control connection.

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

[View full size image]

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

[View full size image]


Configuring L2TPv3

Because misconfiguration is so often the cause of L2TPv3 issues, this section contains a review of L2TPv3 (LAC to LAC pseudowire) configuration on Cisco routers.

There are two ways of configuring L2TPv3 on Cisco routers:

  • Configuring L2TPv3 using dynamic session setup (as described in the section "Technical Overview of L2TPv3")

  • Configuring L2TPv3 using static sessions

The sections that follow describe these two configuration methods in greater detail.

Note that when reading this section, it may be useful to reference Figure 5-19 on page 390.

Figure 5-19. Sample Topology for Troubleshooting Examples

[View full size image]

Configuring L2TPv3 for Dynamic Session Setup

When configuring L2TPv3 for dynamic session setup, there are five basic steps to complete on each LCCE router:

Step 1. | Enable Cisco Express Forwarding (CEF).
Step 2. | Configure loopback interfaces.
Step 3. | Configure the L2TP class.
Step 4. | Configure the pseudowire class.
Step 5. | Configure the attachment circuits.

The sections that follow describe each of these steps in more detail.

Step 1: Enable CEF

The first step is to enable CEF, as shown in Example 5-1.

Example 5-1. Enabling CEF
ip cef [distributed]

CEF is enabled in Example 5-1 using the ip cef global configuration 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: Configure Loopback Interfaces

The next step is to configure 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 configuration of the loopback interface.

Example 5-2. Configuration of the Loopback Interface
interface Loopback0
 ip address 10.1.1.1 255.255.255.255

Note that if you are configuring local switching, multiple loopback interfaces should be configured. Local switching is used to switch traffic from one interface to another on the same router.

Step 3: Configure the L2TPv3 Class

The third step is the configuration of the L2TP class. An L2TP class can be used to configure 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 configuration of the L2TPv3 class.

Example 5-3. Configuration of the L2TPv3 Class
l2tp-class FrankfurtV3Class
 authentication
 password 0 cisco

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 configured using the password password command.

Step 4: Configure the Pseudowire Class

The next step is to configure the pseudowire class. The pseudowire class is used to configure parameters such as encapsulation and source IP address used when building a pseudowire.

If an L2TP class has been configured (see Step 3), then it is associated with the pseudowire during this step.

Example 5-4 shows the configuration of a pseudowire class.

Example 5-4. Configuration of the Pseudowire Class
pseudowire-class FrankfurtPW
 encapsulation l2tpv3
 protocol l2tpv3 FrankfurtV3Class
 ip local interface Loopback0

In Example 5-4, the pseudowire class FrankfurtPW is configured using the pseudowire-class name command. The pseudowire encapsulation type is specified using the encapsulation l2tpv3 command.

The signaling protocol is then specified, 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 specified as L2TPv3, which enables dynamic session setup. The L2TP class is specified as FrankfurtV3Class.

The local (source) IP address used by L2TPv3 is then configured using the ip local interface interface command. The interface specified here is the loopback interface configured in Step 2.

Step 5: Configure the Attachment Circuits

Once the pseudowire class has been configured, the next step is to configure the attachment circuits. Precise configuration 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 configuration of each of these interface types.

Ethernet Encapsulation

If you are using an Ethernet encapsulation, you should configure the attachment circuit interface as shown in Example 5-5.

Example 5-5. Configuration of an Ethernet Interface
interface FastEthernet1/0
 xconnect 10.1.1.2 120 pw-class FrankfurtPW

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 peer's loopback address), VCID 120, dand pseudowire class FrankfurtPW.

Note that the VCID must be the same at both end of the pseudowire on both peers.

VLAN (802.1Q) Encapsulation

Configuration of a VLAN (802.1Q) interface is shown in Example 5-6.

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

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 configure a Frame Relay pseudowire. You can configure 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 configuration of Frame Relay DLCI-to-DLCI switching.

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

In Example 5-7, the frame-relay switching global configuration mode command is used to enable switching of Frame Relay permanent virtual circuits (PVCs).

The attachment circuit interface is configured for Frame Relay encapsulation using the encapsulation frame-relay command.

The interface is then configured 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 configured, 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.

Example 5-8. Association of PVC to L2TPv3 Session
connect PVCtoFrank Serial4/1 60 l2transport
 xconnect 10.1.1.2 121 pw-class FrankfurtPW

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, defined in Step 3.

Frame Relay Trunks

Another option with Frame Relay is to configure 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 configuration of a Frame Relay trunk.

Example 5-9. Frame Relay Trunk Configuration
interface Serial4/2
 xconnect 10.1.1.2 121 pw-class FrankfurtPW

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 configured 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 traffic. By configuring HDLC, the pseudowire is configured to transport HDLC or HDLC-like frames (Frame Relay or PPP, for example).

HDLC and PPP Encapsulations

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

Example 5-10. Configuration of a PVP Pseudowire
interface ATM3/0
 atm pvp 10 l2transport
  xconnect 10.1.1.2 131 pw-class FrankfurtPW

In Example 5-10, an ATM PVP with a Virtual Path Identifier (VPI) of 10 is bound to a pseudowire with VCID 131 to peer LCCE 10.1.1.2.

Configuring L2TPv3 for Static Sessions

An alternative to configuring L2TPv3 with dynamic session establishment is to configure 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.

Configuration of L2TPv3 with static sessions consists of five basic steps that must be completed on each LCCE:

Step 1. | Enable CEF.
Step 2. | Configure loopback interfaces.
Step 3. | Configure the L2TP class (optional).
Step 4. | Configure the pseudowire class.
Step 5. | Configure the attachment circuit.

Configuration of Step 1 through Step 3 is identical to that described in the previous section, "Configuring L2TPv3 for Dynamic Session Setup," and so is not discussed further here.

The sections that follow discuss the configuration of Step 4 and Step 5.

Step 4: Configure the Pseudowire Class

After enabling CEF, the loopback interfaces, and, optionally, the L2TP class, the next step is to configure the pseudowire class.

Example 5-11 shows the configuration of the pseudowire class.

Example 5-11. Configuration of the Pseudowire Class
pseudowire-class FrankfurtPW
 encapsulation l2tpv3
 protocol none
 ip local interface Loopback0

Most of the configuration 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 configures the router not to use dynamic session setup.

Step 5: Configure the Attachment Circuit

After configuring the pseudowire class, the next step is to configure the attachment circuits. When configuring 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 configuration of attachment circuits when using static sessions. Note that the configuration of peer routers London_PE and Frankfurt_PE is shown for DLCI-to-DLCI switching.

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

As you can see, some of the configuration 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 configuration.

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) configured 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 configured using the l2tp id local_session_id remote_session_id command. Compare these to the local and remote session IDs configured 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 configured 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 configured (highlighted line 10).

Note that session IDs, cookie values, and (optionally) a control connection must similarly be configured under the xconnect command for other encapsulation types. That concludes the configuration of L2TPv3.

Complete Sample L2TPv3 Configurations

Example 5-13 shows complete basic configurations of two peer LCCEs using dynamic session establishment.

Again, it may be useful to reference Figure 5-19 on page 390 when examining these configurations.

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
!
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
 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
 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
!
! 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
 !
!
! 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

You will notice that the configuration for London_LCCE in Example 5-13 specifies 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 configuration for Frankfurt_LCCE similarly specifies 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 configuring 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 specific sublayer (4 bytes, if using the default Layer 2 specific sublayer), and the payload (the frame received on the 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 specific 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 Don't 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 Don't 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 configured on the sending LCCE, it then reduces the size of L2TPv3 packets it sends.

Example 5-14 shows the configuration of both of these commands.

Example 5-14. Configuring the ip pmtu and ip dfbit set Commands
pseudowire-class FrankfurtPW
 ip pmtu
 ip dfbit set

Example 5-14 shows the configuration 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 configured 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 configuration of jumbo frame support on Cisco Catalyst switches:

http://www.cisco.com/en/US/products/hw/switches/ps700/products_configuration_example09186a008010edab.shtml


Troubleshooting L2TPv3

The L2TPv3 troubleshooting process depends on whether you are using dynamic session establishment or static session configuration. One common element is the control connection (assuming that it is configured with static sessions).

This section is split into three subsections:

  • The first subsection focuses on control connection establishment.

  • The second subsection focuses on dynamic session setup.

  • The third subsection focuses on static session configuration.

Troubleshooting L2TPv3 with dynamic session setup consists of troubleshooting control connection establishment and then troubleshooting dynamic session setup itself.

Troubleshooting L2TPv3 with static session configuration consists of troubleshooting control connection establishment (if configured), and then the static session configuration itself.

The flowchart in Figure 5-18 describes the troubleshooting process used with L2TPv3. You can use this flowchart to quickly access the section of the chapter relevant to problems you are experiencing on your network.

Figure 5-18. L2TPv3 Troubleshooting Flowchart

[View full size image]

Figure 5-19 shows the sample topology used to illustrate the concepts in the sections that follow.

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 first step in the L2TPv3 troubleshooting process is to verify control connection establishment, which is illustrated in Figure 5-20.

Figure 5-20. L2TPv3 Control Connection Establishment

[View full size image]

In Figure 5-20, the first attachment circuit changes state to active (up), and control connection establishment begins.

Before examining how control connection establishment can fail, it is useful to first have a look at a successful control connection establishment sequence.

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#

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 configured 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 confirmed using the show l2tun tunnel command, as shown in Example 5-16.

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#

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 LCCE's hostname (Frankfurt_LCCE), control connection state (established), the remote LCCE's 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 LCCE's IP address is misconfigured (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 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 LCCE's IP Address Is Misconfigured (with the xconnect Command)

If the remote LCCE's IP address is misconfigured on the local LCCE, control connection establishment will fail.

It is worth noting that if multiple pseudowires are configured between LCCE peers, as long as one pseudowire is correctly configured (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>
*Mar 30 21:21:06.815 UTC: Tnl/Sn49403/30972 L2TP: Session state change from
  wait-for-tunnel to idle
London_LCCE#

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.

Example 5-18. Remote LCCE's 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#

As you can see, London_LCCE cannot locate any configuration for remote peer Frankfurt_LCCE (highlighted line 1). Note Frankfurt_LCCE's IP address (10.1.1.2).

London_LCCE's configuration is then examined using the show running-config command, as shown in Example 5-19. Note that only the relevant portion of the output is shown.

Example 5-19. Frankfurt_LCCE's 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
 !
!

The highlighted line shows the IP address configured for Frankfurt_LCCE (for the pseudowire with VCID 121). As you can see it is 10.1.1.3. Unfortunately, Frankfurt_LCCE's IP address is 10.1.1.2.

The IP address for Frankfurt_LCCE is then reconfigured, as shown in Example 5-20.

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#

In the highlighted line, the IP address for Frankfurt_LCCE is reconfigured as 10.1.1.2. Once the IP address for Frankfurt_LCCE has been reconfigured, control connection establishment succeeds. This is verified using the show l2tun tunnel command, as shown in Example 5-21.

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#

As you can see, the control connection has been successfully set up to Frankfurt_LCCE.

It is also worth noting that if the local LCCE's IP address is misconfigured 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-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,
  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#

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.

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

In the highlighted line, you can see that access list 101 is configured in an inbound direction on interface serial 2/0.

The composition of access list 101 is then verified using the show ip access-lists command, as shown in Example 5-24.

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
    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#

As you can see, access list 101 permits a number of protocols, but significantly 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.

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#

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.

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#

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 configured), 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 configured in this scenario, this SCCRQ contains a Challenge AVP.

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#

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_LCCE's 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.

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.

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#

Once the password has been reconfigured on London_LCCE and Frankfurt_LCCE, control connection establishment is successful. This is verified using the show l2tun tunnel command, as shown in Example 5-29.

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#

The highlighted line shows that a control connection has been successfully established to Frankfurt_LCCE.

Note that if L2TPv3 authentication is configured on the local LCCE but not on the remote LCCE, no response (SCCRP) to the local LCCE's SCCRQ will be received. Always ensure that L2TPv3 authentication is consistently configured on peer LCCEs.

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

[View full size image]

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.

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#

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.

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 establishedthe session is up.

Successful L2TPv3 session establishment can be verified using the show l2tun session command, as shown in Example 5-31.

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#

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 LCCE's IP address is misconfigured (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 LCCE's IP Address Is Misconfigured (with the xconnect Command)

If the peer LCCE's IP address is misconfigured, 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-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
*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#

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 verified using the show running-config command on London_LCCE and Frankfurt_LCCE, as shown in Example 5-33. Note that only the relevant portion of the output is shown.

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
!
interface FastEthernet0/0.1
 encapsulation dot1Q 10
 no ip directed-broadcast
 no cdp enable
 xconnect 10.1.1.4 120 pw-class LondonPW
!

In highlighted line 1, you can see that the peer IP address configured for the pseudowire on London_LCCE is 10.1.1.2. This address is correctly configured.

Then in highlighted line 2, you can see that the peer IP address configured on Frankfurt_LCCE is 10.1.1.4. This is incorrectit should be 10.1.1.1.

The peer IP address is then reconfigured on Frankfurt_LCCE, as shown in Example 5-34.

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#

As the highlighted line indicates, the peer IP address is reconfigured to be 10.1.1.1. Once the peer IP address has been reconfigured, session establishment succeeds.

Successful session establishment is verified using the show l2tun session command, as shown in Example 5-35.

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#

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.

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#

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 configured 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 configuration on London_LCCE and Frankfurt_LCCE using the show running-config command, as shown in Example 5-37.

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
!
!
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
!

Highlighted line 1 indicates that the VCID configured 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 reconfigured on Frankfurt_LCCE, as shown in Example 5-38.

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#

In the highlighted line, the VCID is reconfigured as 120.

Once the VCID has been reconfigured, L2TPv3 session establishment is successful. This is verified using the show l2tun session command, as shown in Example 5-39.

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#

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.

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#

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 find out the reason for session establishment failure, you can use the debug vpdn l2x-errors command, as demonstrated in Example 5-41.

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#

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 configuration of the attachment circuits is then examined using the show running-config 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 configured for DLCI-to-DLCI switching.

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
!

Highlighted line 5, however, shows that the corresponding interface on Frankfurt_LCCE (serial 2/1) is configured for Frame Relay trunking. In fact, interface serial 2/1 on Frankfurt should be configured for DLCI-to-DLCI switching.

Frankfurt_LCCE is then reconfigured, as shown in Example 5-43.

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#

The highlighted lines indicate that interface serial 2/1 on Frankfurt_LCCE is reconfigured for DLCI-to-DLCI switching.

Once Frankfurt_LCCE has been reconfigured, L2TPv3 session establishment succeeds.

L2TPv3 session establishment is verified using the show l2tun session command, as shown in Example 5-44.

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#

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 Configuration

If L2TPv3 sessions are statically configured, troubleshooting consists of verifying peer LCCE configuration. Always ensure that peer IP addresses are correctly configured and that session IDs and cookies are mirror images on peer routers.

In this scenario, traffic from CE router mjlnet_CE1 is not arriving at mjlnet_CE2 (see Figure 5-19). This is verified using ping, as shown in Example 5-45.

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#

As you can see, there is no connectivity between the CE routers.

The next step is to verify L2TPv3 configuration 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-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
 !
!

A close comparison of the configuration on the two PE routers reveals that the peer IP addresses and the L2TPv3 cookies are correctly configured, but that the L2TPv3 (session) IDs are not.

Remember that the session IDs configured 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 misconfigured. It should be 1002, but it is configured as 1003.

The local session ID on London_PE is then reconfigured, as shown in Example 5-47.

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#

Once London_PE has been reconfigured, connectivity is established between mjlnet_CE1 and mjlnet_CE2, as shown in Example 5-48.

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#


Other Commands

This section briefly 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-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#

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 modified 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 modified 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
    28 Packets sent, 4 received
    1130 Bytes sent, 136 received
    Receive packets dropped:
      out-of-order:             0
      total:                    0
    Send packets dropped:
      exceeded session MTU:     0
      total:                    0
  Session vcid is 121
  Session Layer 2 circuit, type is Frame Relay, name is Serial4/1:60
  Circuit state is UP
    Remote session id is 52765, remote tunnel id 39248
  DF bit off, ToS reflect disabled, ToS value 0, TTL value 255
  No session cookie information available
  SSS switching enabled
  Sequencing is on
    Ns 28, Nr 4, 0 out of order packets received
London_LCCE#

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), together with its IP address (10.1.1.2) are shown in highlighted lines 4 and 5. Highlighted line 6 shows this L2TP session was dynamically signaled.

The session state (established), as well as the time since the last session state change, are shown in highlighted line 7. The number of packets and bytes sent and received are shown in highlighted lines 8 and 9. Highlighted lines 10 and 11 show the number of receive packets dropped, and highlighted lines 12 and 13 show the number of send packets dropped.

The VCID associated with the session is shown in highlighted line 14 (121), and the Layer 2 circuit type (Frame Relay), interface (serial 4/1), and DLCI (60) are shown in highlighted line 15. Highlighted line 16 shows the circuit state (UP).

The remote session and tunnel (control connection) IDs are shown in highlighted line 17 (52765 and 39248, respectively). Highlighted line 18 shows that the Don't Fragment (DF) bit is not set in the IP header of L2TPv3 packets. If you want to set the DF bit, use the ip dfbit set command (in the pseudowire class).

Highlighted line 18 also shows that Type of Service (ToS) reflection is disabled and that the IP header of L2TPv3 packets contains a ToS value of zero and a Time-to-Live (TTL) value of 255. ToS reflection can be enabled using the ip tos reflect pseudowire class command. This command configures the LCCE to copy the ToS value from tunneled packets to the IP header of L2TPv3 packets.

If ToS reflection is not configured, the ToS value shown in highlighted line 18 is copied into the IP header of L2TPv3 packets. The default ToS value is zero, but this can be modified using the ip tos value under the pseudowire class configuration. The TTL copied to the IP header of L2TPv3 packets can be set using the ip ttl pseudowire command (the default is 255).

Highlighted line 19 shows that Subscriber Switch Service (SSS) is enabled (see www.cisco.com for more on this). In highlighted line 20, you can see that L2TPv3 packet sequencing is enabled. This is disabled by default, but can be enabled using the sequencing {transmit | receive | both} pseudowire class command. Highlighted line 21 shows the Next sent (Ns) and Next received (Nr) values, together with the number of packets received out of order.

debug acircuit [error | event]

The debug acircuit [error | event] commands display attachment circuit error and event information, including provisioning events, circuit up/down events, and setup or configuration failures.

Example 5-51 shows output from the debug acircuit event command. Information regarding a circuit on interface serial 4/1 is shown.

Example 5-51. debug acircuit event Command Output
London_LCCE#debug acircuit event
Attachment Circuit events debugging is on
London_LCCE#
*Apr  2 20:04:52.263 UTC: %LINK-3-UPDOWN: Interface Serial4/1, changed state to up
*Apr  2 20:04:52.263 UTC: ACMGR: Receive <Circuit Up> msg
*Apr  2 20:04:52.263 UTC: Se4/1 ACMGR: circuit up event, SIP state chg down to
  connecting, action is service request
*Apr  2 20:04:52.263 UTC: Se4/1 ACMGR: Sent a sip service request
*Apr  2 20:04:52.263 UTC: ACMGR: Receive <Circuit Up> msg
*Apr  2 20:04:52.263 UTC: Se4/1 ACMGR: circuit up event, SIP state chg down to
  connecting, action is service request
*Apr  2 20:04:52.263 UTC: Se4/1 ACMGR: Sent a sip service request
*Apr  2 20:04:52.267 UTC: Se4/1 ACMGR: Rcv SIP msg: resp connect forwarded,
  hdl 2A0001BD, sss_hdl EE0001C1
*Apr  2 20:04:52.267 UTC: Se4/1 ACMGR: service connected event, SIP state chg
  connecting to conne
10:02:39: %LINK-3-UPDOWN: Interface Serial0, changed state to up
10:02:40: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial0, changed state to
  upcted, action is respond forwarded
*Apr  2 20:04:53.263 UTC: Se4/1 ACMGR: Receive <Circuit Down> msg
*Apr  2 20:04:53.263 UTC: Se4/1 ACMGR: circuit down event, SIP state chg connecting to
  end, action is service disconnect
*Apr  2 20:04:53.263 UTC: Se4/1 ACMGR: Sent a sip service disconnect
*Apr  2 20:04:53.263 UTC: Se4/1 ACMGR: Receive <Circuit Down> msg
*Apr  2 20:04:53.263 UTC: Se4/1 ACMGR: circuit down event, SIP state chg connected to
  end, action is service disconnect
*Apr  2 20:04:53.263 UTC: Se4/1 ACMGR: Sent a sip service disconnect
London_LCCE#

debug xconnect [error | event]

This command displays xconnect configuration error and event information.

Example 5-52 shows output from the debug xconnect event command. In this case, event information is shown for DLCIs 50 and 60 on interface serial 4/1.

Example 5-52. debug xconnect event Command Output
[View full width]
London_LCCE#debug xconnect event
*Apr  2 20:05:40.771 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial4/1,
   changed state to up
Xconnect author events debugging is on
London_LCCE#
*Apr  2 20:06:10.327 UTC: %LINEPROTO-5-UPDOWN: Line protocol on Interface Serial4/1,
   changed state to up
*Apr  2 20:06:10.327 UTC: XC AUTH [Se4/1, 50]: Event: start xconnect authorization,
  state changed from IDLE to AUTHORIZING
*Apr  2 20:06:10.327 UTC: XC AUTH [Se4/1, 50]: Event: found xconnect authorization,
  state changed from AUTHORIZING to DONE
*Apr  2 20:06:10.327 UTC: XC AUTH [Se4/1, 60]: Event: start xconnect authorization,
  state changed from IDLE to AUTHORIZING
*Apr  2 20:06:10.327 UTC: XC AUTH [Se4/1, 60]: Event: found xconnect authorization,
  state changed from AUTHORIZING to DONE
*Apr  2 20:06:10.327 UTC: XC AUTH [Se4/1, 50]: Event: free xconnect authorization
  request, state changed from DONE to END
*Apr  2 20:06:10.327 UTC: XC AUTH [Se4/1, 60]: Event: free xconnect authorization
  request, state changed from DONE to END
London_LCCE#

debug vpdn l2tp-sequencing

The debug vpdn l2tp-sequencing command displays the Next sent (Ns) and Next received (Nr) sequence numbers contained in L2TPv3 packets.

Example 5-53 shows output from the debug vpdn l2tp-sequencing command.

Example 5-53. debug vpdn l2tp-sequencing Command Output
London_LCCE#debug vpdn l2tp-sequencing
L2TP data sequencing debugging is on
London_LCCE#
*Apr  2 20:09:49.935 UTC: Tnl61973 L2TP: Update ns/nr, peer ns/nr 72/101, our ns/nr
  102/72
*Apr  2 20:09:49.935 UTC: Tnl61973 L2TP: Peer acknowledging through 101
*Apr  2 20:09:49.935 UTC: Tnl61973 L2TP: Dropped ZLB ACK
*Apr  2 20:09:49.935 UTC: Tnl61973 L2TP: Update ns/nr, peer ns/nr 72/101, our ns/nr
  102/72
*Apr  2 20:09:49.939 UTC: Tnl61973 L2TP: Dropped ZLB ACK
*Apr  2 20:09:49.951 UTC: Tnl61973 L2TP: Update ns/nr, peer ns/nr 72/102, our ns/nr
  102/72
*Apr  2 20:09:49.951 UTC: Tnl61973 L2TP: Peer acknowledging through 102
*Apr  2 20:09:49.951 UTC: Tnl61973 L2TP: Dropped ZLB ACK
London_LCCE#

Highlighted line 1 shows the peer and local Ns and Nr sequence numbers. In highlighted line 2, you can see that the peer LCCE has acknowledged L2TPv3 packets up to sequence number 101.

debug vpdn packet

The debug vpdn packet displays L2TPv3 packets CEF and fast switched to and from the peer LCCE.

Example 5-54 shows output from the debug vpdn packet command.

Example 5-54. debug vpdn packet Command Output
London_LCCE#debug vpdn packet
VPDN packet debugging is on
London_LCCE#
*Apr  2 20:13:33.551 UTC: VPDN CEF From tunnel: Received 48 byte pak
*Apr  2 20:13:33.551 UTC: VPDN CEF From tunnel: Pak consumed
*Apr  2 20:13:33.551 UTC: L2X: IP socket write 40 bytes, 10.1.1.1 to 10.1.1.2, prot
  115
*Apr  2 20:13:33.571 UTC: L2X: IP socket write 48 bytes, 10.1.1.1 to 10.1.1.2, prot
  115
*Apr  2 20:13:33.583 UTC: VPDN CEF From tunnel: Received 40 byte pak
*Apr  2 20:13:33.583 UTC: VPDN CEF From tunnel: 40 byte buffer returned
*Apr  2 20:13:33.583 UTC: VPDN FS From tunnel: Received 40 byte pak
*Apr  2 20:13:33.583 UTC: VPDN FS From tunnel: 40 byte buffer returned
*Apr  2 20:13:35.695 UTC: L2X: IP socket write 92 bytes, 10.1.1.1 to 10.1.1.3, prot
  115
*Apr  2 20:13:37.695 UTC: L2X: IP socket write 158 bytes, 10.1.1.1 to 10.1.1.3, prot
  115
*Apr  2 20:13:38.695 UTC: L2X: IP socket write 158 bytes, 10.1.1.1 to 10.1.1.3, prot
  115
*Apr  2 20:13:39.695 UTC: L2X: IP socket write 92 bytes, 10.1.1.1 to 10.1.1.3, prot
  115
*Apr  2 20:13:40.695 UTC: L2X: IP socket write 158 bytes, 10.1.1.1 to 10.1.1.3, prot
  115
*Apr  2 20:13:44.695 UTC: L2X: IP socket write 92 bytes, 10.1.1.1 to 10.1.1.3, prot
  115

*Apr  2 20:13:46.087 UTC: aie_sid:6 VPDN FS Into tunnel (SSS): Sending pak
*Apr  2 20:13:46.087 UTC: aie_sid:6 VPDN FS/CEF Into tunnel: Sending 80 byte pak
*Apr  2 20:13:46.087 UTC: aie_sid:6 VPDN CEF Into tunnel (SSS): Pak send successful
London_LCCE#

Highlighted line 1 shows that a 48-byte packet has been received by the local LCCE. In highlighted line 2, you can see that an 80-byte packet has been sent by the local LCCE.

CAUTION

Note that extra caution should be exercised when using this command because it can produce copious output.

debug vpdn l2x-packets

You can use the debug vpdn l2x-packets command to display detailed L2TPv3 control packet information.

Example 5-55 shows output from the debug vpdn l2x-packets command.

Example 5-55. debug vpdn l2x-packets Command Output
London_LCCE#debug vpdn l2x-packets
L2X control packets debugging is on
London_LCCE#
*Mar 29 22:26:13.171 UTC: Tnl51541 L2TP: O Hello  to Stockholm_LCCE tnlid 20631
*Mar 29 22:26:13.171 UTC: Tnl51541 L2TP: O Hello, flg TLS, ver 3, len 20, tnl 20631,
  ns 47, nr 45
     00 00 00 00 C8 03 00 14 00 00 50 97 00 2F 00 2D
     80 08 00 00 00 00 00 06
*Mar 29 22:26:35.243 UTC: Tnl/Sn58687/53867 L2TP: O CDN to Frankfurt_LCCE 34029/60109
*Mar 29 22:26:35.243 UTC: Tnl/Sn58687/53867 L2TP: O CDN, flg TLS, ver 3, len 50,
  tnl 34029, lsid 53867, rsid 60109, ns 38, nr 39
     00 00 00 00 C8 03 00 32 00 00 84 ED 00 26 00 27
     80 08 00 00 00 00 00 0E 80 0A 00 00 00 01 00 01
     00 00 80 0A 00 09 00 03 00 00 D2 6B 80 0A 00 09
     00 04 00 00 EA CD
London_LCCE#

Highlighted line 1 shows that a L2TPv3 Hello message has been sent to Stockholm_LCCE.

In highlighted line 2, you can see the contents of the L2TPv3 packet header for the hello message. In particular, you can see that the Type (T), Length (L), and Sequence number (S) flags are set in the L2TPv3 header. You can also see that the version is 3 (L2TPv3), the length is 20, the control connection ID is 20631, and that the Next sent (Ns) and Next received (Nr) values are 47 and 45, respectively.

Highlighted line 3 shows that a CDN message has been sent to Frankfurt_LCCE. Highlighted line 4 shows the TLS flags, version field value, length field value, control connection ID, local (LSID) and remote (RSID) session IDs, and the Next sent (Ns) and Next received (Nr) values of the L2TPv3 header of the CDN message.

CAUTION

Note that extra caution should be exercised when using this command because it can produce copious output.


Command Summary

Table 5-10 lists commands used for troubleshooting L2TPv3 in this chapter.

Table 5-10. L2TPv3 Troubleshooting Commands

Command

Parameter

Description

show l2tun tunnel

Displays information about L2TPv3 control connections

all

Displays information about L2TPv3 control connections

show l2tun session

Displays information about L2TPv3 sessions

all

Displays information about L2TPv3 sessions

debug acircuit

error

Displays attachment circuit errors

event

Displays attachment circuit events

debug xconnect

error

Displays xconnect configuration errors

event

Displays xconnect configuration events

debug vpdn

packet

Displays L2TPv3 packets

l2x-errors

Displays L2TPv3 protocol errors

l2x-events

Displays L2TPv3 protocol events

l2x-packets

Displays detailed information about L2TPv3 control packets

l2tp-sequencing

Displays L2TPv3 sequence number information


Review Questions

1: | What is the function of the control connection?
2: | Is a control connection required? Why or why not?
3: | What is the function of the session ID and the cookie?
4: | For what are the Message Digest and Control Message Authentication Nonce AVPs used?
5: | What three messages are exchanged in order to establish a control connection?
6: | What three messages are exchanged in order to establish a session?
7: | If an LCCE wants to tear down a control connection, what message does it send?
8: | If an LCCE wants to tear down a session, what message does it send?
9: | What message does an LCCE send to its peer to signal that attachment circuit status has changed from active to inactive (or vice-versa)?
10: | What is the major difference between L2TPv2 and L2TPv3 with regard to supported Layer 2 payloads?


Chapter 6. Troubleshooting Multiprotocol Label Switching Layer 3 VPNs

Multiprotocol Label Switching (MPLS) Layer 3 VPNs are described in Internet Draft draft-ietf-l3vpn-rfc2547bis (RFC2547bis). MPLS Layer 3 VPNs allow a service provider to provision IP connectivity for multiple customers over a shared IP backbone, while maintaining complete logical separation of customer traffic and routing information. Each customer VPN consists of a several geographically dispersed sites. IP connectivity between sites is provisioned over the provider backbone.

There are two basic VPN models:

  • The overlay model, in which there is no exchange of routing information between the customer and the service provider

  • The peer model, in which routing information is exchanged between customer and service provider

MPLS Layer 3 VPNs conform to the peer model, but unlike other peer VPN architectures, each customer's routing information is maintained in separate routing and forwarding tables.

Figure 6-1 illustrates a service provider backbone with two MPLS VPNs provisioned.

Figure 6-1. MPLS VPNs

[View full size image]

In Figure 6-1 there are two VPNs, mjlnet_VPN and cisco_VPN. Each VPN has three sites, with site 1 in each VPN connected to Chengdu_PE, site 2 connected to HongKong_PE, and site 3 connected to Shanghai_PE.

The MPLS VPN topology is very flexible. The service provider can configure intranet and extranet topologies, such as hub-and-spoke and full-mesh, simply by controlling the distribution of customer routes between service provider (edge) routers.

The service provider can also act as a backbone to carry traffic between different sites of another service provider. This is known as the carrier's carrier topology.

Finally, service providers can combine to offer VPN connectivity to a customer, with some customer sites connected to one provider and other customer sites connected to other providers. This is called an interprovider VPN.


Technical Overview

There are two main components in an MPLS VPN backbone, the customer routing and forwarding tables maintained on the provider (edge) routers, and the underlying mechanism used to transport customer traffic. When a customer data packet arrives on the ingress service provider edge router, it is encapsulated with a MPLS (VPN) label that corresponds to the best route in the appropriate customer routing and forwarding table. Then it is forwarded over an MPLS label switched path (LSP) to the egress service provider edge router. Alternatively, MPLS VPN traffic may be tunneled over a non-MPLS network using IP or GRE, L2TPv3, or IP/IPSec.

An understanding of both components is essential for fast and effective troubleshooting of MPLS VPNs. A brief review of MPLS and MPLS VPN operation is included here, beginning with a description of the MPLS architecture.

MPLS Architecture

MPLS is an IETF standard, which builds upon early work done by companies such as Cisco, Ipsilon, Toshiba, and IBM. MPLS allows routers to switch packets based on labels rather than doing Layer 3 lookups. Routers that switch packets based upon labels are known as Label Switch Routers (LSRs).

MPLS offers a number of benefits, including closer integration between IP and ATM, the capability to remove BGP configuration from core routers, and applications such as VPNs and traffic engineering (MPLS/TE).

MPLS Forwarding

When an IP packet arrives at the edge of the MPLS network, the ingress LSR classifies the packet into a Forwarding Equivalence Class (FEC). The FEC is a classification that describes how packets are forwarded over an MPLS network. This can be based upon network prefix (route), quality of service, and so on. In this chapter, it is assumed that classification into an FEC is based on a network prefix (an entry in the routing/forwarding table of the ingress LSR).

Once classification has taken place, the ingress LSR imposes a label on the packet. This label corresponds to the FEC and functions as an identifier that allows LSRs to forward the packet without having to do a Layer 3 lookup.

At each hop through the MPLS backbone, the label is swapped, until the packet reaches the penultimate LSR in the path through the MPLS network. Note that, although the label is swapped, it still corresponds to the same FEC.

The penultimate hop LSR may remove or pop the label before forwarding the packet to the egress LSR. This is called penultimate hop popping, and it saves the egress LSR from having to do a label lookup, remove the label, do a Layer 3 lookup, and finally forward the packet. Instead, because the label is removed at the penultimate hop, the egress LSR can simply do a Layer 3 lookup and forward the packet accordingly.

Note that penultimate hop popping is performed only for labels corresponding to directly connected networks or aggregate routes on the egress LSR.

Figure 6-2 illustrates the forwarding of an IP packet across the MPLS backbone.

Figure 6-2. Label Switched Path

[View full size image]

The path that a packet takes across the MPLS network is known as a Label Switched Path (LSP).

MPLS Modes

MPLS can operate in two modes:

  • Frame-mode is used over Ethernet, Frame Relay, PPP (including POS), HDLC, and ATM PVCs.

  • Cell-mode is used between label switching controlled ATM (LC-ATM) interfaces. ATM cells sent and received on LC-ATM interfaces carry labels in the VCI or VPI and VCI fields of the ATM cell headers. A device that switches ATM cells between LC-ATM interfaces using label values contained in the VPI/VCI fields in the cell headers is known as an ATM-LSR.

Labels

The precise form of the MPLS label differs depending on whether frame-mode or cell-mode MPLS is used, as detailed in the sections that follow.

Frame-Mode

In frame-mode, the label is carried as a "shim" header between the Layer 2 and Layer 3 headers. MPLS labels are 4 octets long and consist of a 20-bit label, a 3-bit Experimental (EXP) field, a bottom of label stack (S) bit, and an 8-bit Time-to-Live (TTL) field. This is illustrated in Figure 6-3.

Figure 6-3. MPLS Label

The Label field carries the label value itself. This corresponds to an FEC. The Exp field, in spite of its name, usually carries quality of service information. The bottom of label stack bit is used to indicate the bottom of the stack label. The Time-to-Live (TTL) field serves exactly the same function as that contained within the IP packet header. The TTL field is decremented by 1 at every hop, and if it reaches 0, the labeled packet is discarded. This mechanism provides protection against forwarding loops in the MPLS network, as well as limiting the forwarding scope of the packet.

Cell-Mode

In cell-mode, the label is carried in the VPI/VCI fields of the ATM cell header, as shown in Figure 6-4.

Figure 6-4. MPLS Label Carried in the VPI/VCI Fields of the ATM Cell Header

[View full size image]

Note that when the original packet is segmented into cells on the ingress ATM-LSR, the first of those cells also carries the label or labels in the form shown in Figure 6-3. This is to preserve any other information, such as quality of service, carried in the EXP bits.

Label Stack

A labeled packet is said to contain a label stack. The label stack consists of one or more labels. In a simple MPLS VPN environment, the label stack consists of two labels. If MPLS VPN traffic is being carried over an MPLS traffic-engineering (TE) tunnel, the label stack may consist of two, three, or four labels, depending on how TE is configured.

The outermost (top) label in a stack is used to carry the packet over the MPLS backbone between ingress and egress LSRs. This outer label is the IGP label.

Because the outermost label has only local significance, LSRs must use a signaling protocol to exchange label to prefix bindings. The signaling protocol can be either Cisco's proprietary Tag Distribution Protocol (TDP) or the Label Distribution Protocol (LDP).

If traffic is being carried over a traffic engineering (TE) tunnel, the outermost label corresponds to the TE tunnel. In this case, the label signaling protocol can be either the Resource Reservation Protocol (RSVP), or Constraint-based Routed Label Distribution Protocol (CR-LDP). Cisco routers use RSVP to signal traffic engineering tunnels.

Note that although the outermost (IGP) label may be either TDP/LDP or RSVP signaled, in this book the term "TE label" is used where appropriate to distinguish RSVP signaled labels.

When MPLS VPN traffic is being transported, the innermost (bottom) label corresponds to either:

  • The VPN Routing and Forwarding instance (VRF, which is discussed later in this chapter)

  • The outgoing interface on the egress PE router

This is called the VPN label. Figure 6-5 illustrates the format of the labeled packet as it is transmitted.

Figure 6-5. Labeled Packet

Label Information Base, Label Forwarding Information Base, and Cisco Express Forwarding

Labels are stored in three separate types of tables on Cisco routers:

  • The Label Information Base (LIB) The LIB contains all label bindings received from peer LSRs, or a subset of label bindings that correspond to the best routes for network prefixes. Whether the LSR retains all labels or just a subset depends on the mode of label retention that it is using.

  • The Label Forwarding Information Base (LFIB) The LFIB contains only those labels that correspond to the next-hop of the best route for each network prefix. The LFIB also contains outgoing interface information.

    The LFIB is used for label swapping within the MPLS backbone.

  • The Cisco Express Forwarding (CEF) tables The CEF tables contain information from the routing table, including prefixes, next-hops, and outgoing interfaces. The CEF tables also interface to the LIB and contain labels associated with prefixes.

    CEF is used for label imposition at the edge of the MPLS network on the ingress LSR.

Control and Data Planes

There are two channels or planes of communication between LSRs in an MPLS network:

  • The control plane Used to exchange routing information and label bindings

  • The data (or forwarding) plane Used for the transmission of labeled or unlabeled packets

LSP Control, Label Assignment, and BGP Routes

The way that LSPs are established within the MPLS network depends on whether the LSRs are using independent or ordered LSP control, as described in the following list:

  • Independent LSP control When independent control is used, LSRs assign labels to prefixes (FECs) independently. This means that labels are assigned irrespective of whether other LSRs have assigned labels.

    Once labels have been assigned (or bound) to prefixes, these bindings are advertised to peer LSRs.

  • Ordered LSP control When ordered control is used, an LSR assigns labels to prefixes (FECs) for which it is the egress LSR. If an LSR is not the egress for a prefix, it does not assign a label until the next-hop LSR has sent a label binding for the prefix in question.

It is possible for both independent and ordered control to coexist within a network.

In both independent and ordered control mode, labels are assigned to all prefixes in the routing table, with the exception of BGP routes (in regular MPLS operation). Instead, BGP routes are assigned the label that corresponds to their next-hop. This means, for example, that if BGP route 172.16.5.0/24 has a next-hop of 10.1.1.4, and prefix 10.1.1.4/32 is assigned label 25, then the BGP route will also be assigned label 25. This seemingly insignificant fact has pretty significant consequences.

When a packet enters an MPLS network, the ingress LSR does a route lookup, and if the longest match is a BGP route, the (IGP) label corresponding to the route's next-hop will be imposed on the packet. The packet is then forwarded across the MPLS backbone, and as long as the LSRs in the path have a label corresponding to the BGP next-hop, they are able to forward the packet.

When the packet arrives at the egress LSR, the packet is forwarded out of the correct customer interface. The upshot is that only edge LSRs need to run BGP. Core LSRs can simply run the IGP used to advertise BGP next-hop information.

It is useful to remember this fact when troubleshooting MPLS VPNs because customer routes are advertised across the MPLS VPN backbone using MP-BGP. VPN packets, therefore, use a label corresponding to the MP-BGP next-hop to cross the backbone. The MP-BGP next-hop for VPN routes is the advertising PE router's BGP update source.

Downstream Label Distribution

Label bindings are distributed from downstream to upstream LSRs. Downstream LSRs are closer to the destination network than upstream LSRs. Label distribution, therefore, takes place in the opposite direction to traffic flow.

Figure 6-6 illustrates downstream label distribution.

Figure 6-6. Downstream Label Distribution

Downstream label distribution can be either one of the following:

  • Unsolicited downstream label distribution LSRs that use unsolicited label distribution do not wait for label bindings to be requested before advertising them to their upstream neighbors.

  • Downstream-on-demand label distribution If LSRs use downstream-on-demand label distribution, an LSR can request a label for a prefix from its downstream peer.

    Figure 6-7 illustrates downstream-on-demand label distribution.

    Figure 6-7. Downstream-on-Demand Label Distribution

    [View full size image]

Label Retention

After receiving label bindings from its peers, an LSR must decide whether to retain all these bindings or only those that correspond to the best routes in the network. The two modes of label retention are as follows:

  • Liberal label retention If an LSR operates in liberal label retention mode, all label bindings sent to it from other LSRs are retained.

    The advantage of this mode of operation is that the LSR can failover to an alternate LSP if the original LSP fails. The disadvantage is that more memory is required to store the labels.

  • Conservative label retention An LSR operating in conservative label retention mode retains only those label bindings that correspond to the best route for each network prefix. Any other label bindings are simply discarded.

    The advantage of this mode is that less memory is required to store label bindings. The disadvantage is that it takes longer to failover to an alternate path if the original LSP fails.

NOTE

More information concerning MPLS architecture and label stack encoding can be found in RFCs 3031 and 3032.

Label Distribution Protocols

A number of label distribution protocols can be used within a MPLS network depending upon the particular applications being used. Label distribution protocols include Tag Distribution Protocol (TDP), Label Distribution Protocol (LDP), RSVP, Multiprotocol Extensions for BGP-4 (MP-BGP), and Protocol Independent Multicast (PIM).

LDP and TDP

The LDP and Cisco's proprietary TDP can both be used to advertise labels bindings for IGP prefixes. Although TDP and LDP are similar, there are a number of differences. Table 6-1 outlines some of the primary differences between LDP and TDP.

Table 6-1. LDP versus TDP

LDP

TDP

IETF standard protocol

Cisco proprietary protocol

Uses an all-routers multicast address (224.0.0.2) for directly connected neighbor discovery

Uses local broadcasts

Uses UDP and TCP port 646 for neighbor discovery and session establishment

Uses UDP and TCP port 711

Provides optional MD5 authentication

No optional MD5 authentication provided

NOTE

Note that this chapter focuses on LDP, although TDP is discussed where relevant.

More information on LDP can be found in RFC 3036. More information on TDP can be found in RFC 2105, as well as draft-doolan-tdp-spec-01.

Extensions to the RSVP

Extended RSVP is used in MPLS networks to signal TE tunnels. TE LSP tunnels can be used to make better use of bandwidth by taking advantage of underutilized paths through the network.

TE LSPs can be reserved based upon bandwidth requirements and administrative policies. TE LSPs can follow an explicit or dynamic path. Irrespective of whether they are explicit or dynamic, however, paths must conform to any bandwidth and administrative requirements.

Extensions to OSPF and IS-IS facilitate the flooding of link bandwidth and policy information throughout the MPLS network. This allows the TE tunnel initiating (head-end) LSR to calculate the path using a constrained shortest path (CSPF) algorithm.

Once the path has been calculated, the tunnel is signaled using RSVP Path and Resv messages. Path messages contain a LABEL_REQUEST object (among others) and travel hop-by-hop along the path described to the tunnel tail-end. Resv messages contain a LABEL object and travel back along the path from the tail-end to the head-end LSR. The purpose of the LABEL_REQUEST object is, as the name suggests, to request a label binding for the LSP. The purpose of the LABEL object is to distribute label bindings for the LSP. TE tunnels use downstream-on-demand label distribution.

Figure 6-8 illustrates TE LSP tunnel signaling using extensions to RSVP.

Figure 6-8. TE LSP Tunnel Signaling Using Extensions to RSVP

Extensions to RSVP for traffic engineering are discussed in RFC 3209. Other useful documents include RFC 2702, which describes requirements for traffic engineering over MPLS, draft-ietf-isis-traffic, which describes IS-IS extensions for traffic engineering, and RFC 3630, which describes TE extensions for OSPF.

MP-BGP

MP-BGP is used in a MPLS VPN environment to advertise customer routes, associated labels, and other attributes. MP-BGP is discussed further in the next section, "MPLS Layer-3 VPNs." Multiprotocol extensions for BGP are discussed in RFC 2858.

MPLS Layer-3 VPNs

MPLS VPNs can be provisioned over a shared provider backbone. They allow IP connectivity between customer sites in a VPN.

RFC2547bis uses a number of terms to describe devices at customer sites and within the service provider's backbone:

  • Customer edge (CE) routers Routers at the customer site that are directly connected to the service provider network.

  • Customer routers Other routers within the customer site that are not directly connected to the service provider network.

  • Provider edge (PE) routers Routers within the service provider backbone that connect to customer sites. Note that in an MPLS network, PE routers also function as edge LSRs.

  • Provider (P) routers Routers within the service provider backbone that do not connect directly to customer sites. Note that in an MPLS network, P routers also function as LSRs.

Figure 6-9 illustrates CE, PE, and P routers.

Figure 6-9. CE, PE, and P Routers

[View full size image]

Overlapping Address Space

Different customers VPNs might use overlapping IP address space. To allow overlapping IP address space to be distinguished within the MPLS VPN backbone, PE routers translate customer routes into VPN-IPv4 prefixes.

A VPN-IPv4 prefix consists of an 8-byte Route Distinguisher (RD) and the original 4-byte IPv4 prefix. RDs are different for customer VPNs, which ensures that VPN-IPv4 prefixes are unique.

Figure 6-10 illustrates the format of a VPN-IPv4 prefix.

Figure 6-10. VPN-IPv4 Prefix Format

[View full size image]

The RD is encoded using the format shown in Figure 6-11.

Figure 6-11. RD Format

The Type field is 2 bytes, and the Value field is 6 bytes. The three currently defined RD types are 0, 1, and 2. The Value field is broken into the Administrator and Assigned Number subfields, as shown in Figure 6-12.

Figure 6-12. Administrator and Assigned Number Subfields

If a Type 0 RD is specified, then the Administrator subfield and Assigned Number subfields are 2 bytes and 4 bytes, respectively, and are encoded as shown in Figure 6-13.

Figure 6-13. RD Type 0 Encoding

[View full size image]

As shown in Figure 6-13, when using a type 0 RD, the Administrator subfield contains an autonomous system (AS) number.

If the service provider is using autonomous system number 64512, and the assigned number is 100, then the IPv4 prefix

172.16.5.0/24

would translate into

0:64512:100:172.16.5.0

If a Type 1 RD is specified, the Administrator subfield and Assigned Number subfields are 4 bytes and 2 bytes, respectively, and they are encoded as shown in Figure 6-14.

Figure 6-14. RD Type 1 Encoding

[View full size image]

As you can see, when using a type 1 RD, the Administrator subfield contains an IP address.

If the service provider is using IP address 192.168.1.1, and the assigned number is 100, then the IPv4 prefix

172.16.5.0/24

would translate into

1:192.168.1.1:100:172.16.5.0

If a Type 2 RD is specified, the Administrator subfield and Assigned Number subfields are 4 and 2 bytes, respectively, and they are encoded as shown in Figure 6-15.

Figure 6-15. RD Type 2 Encoding

[View full size image]

If the service provider is using autonomous system number 64512, and the assigned number is 100, then the IPv4 prefix

172.16.5.0/24

would translate into

2:64512:100:172.16.5.0

If you are the observant type, you might have noticed a striking similarity between the format of type 0 and type 2 RDs. They do, in fact, have a similar format.

Type 0 and 1 RDs are used when translating IPv4 prefixes into VPN-IPv4 prefixes. Type 2 RDs can be used to signal Multicast VPNs (MVPNs).

NOTE

Note that although private autonomous system numbers and IP addresses are used for illustrative purposes in this chapter, their use in the Administrator field in real world deployments in strongly discouraged. This is because these AS numbers and IP addresses are not registered and, therefore, do not offer global uniqueness.

VPN Routing and Forwarding Instances

To allow complete logical separation of routes belonging to different customers, separate routing tables and forwarding tables are used on PE routers. These routing and forwarding tables collectively make up what is known as a VPN Routing and Forwarding (VRF) instance. PE router interfaces connected to different customers are then associated with these VRFs.

Customer routes received on an interface are stored in the associated VRF routing table. Similarly, customer traffic received on an interface is routed according to the associated VRF.

Figure 6-16 illustrates VRF tables on the PE routers.

Figure 6-16. VRF Tables on PE Routers

[View full size image]

The global routing table is still maintained on the PE router and contains backbone IGP routes, as well as any Internet routes.

Note that on Cisco routers it is now possible to associate incoming traffic with a VRF based on its source IP address rather than incoming interface. This feature is known as VRF Selection.

NOTE

See the following URL for more details on VRF Selection:

http://www.cisco.com/en/US/products/sw/iosswrel/ps1829/products_feature_guide09186a008012db6a.html

Route Target Attribute

Although RDs facilitate the disambiguation of overlapping IP address space, they are not flexible enough to allow the provisioning of complex network topologies over an MPLS VPN backbone. To allow this provisioning, a BGP extended community attribute called a Route Target (RT) is used.

The BGP extended community has two fields, the Type field and the Value field. The Type field used with Route Targets is 2 octets (Extended Type), and the Value field is 6 octets. Figure 6-17 illustrates the BGP extended community attribute.

Figure 6-17. BGP Extended Community Attribute (Extended Type)

[View full size image]

The (Extended) Type field is subdivided into high and low order octets. The low order octet has a value of 0x02 when the extended community is a Route Target.

The Value field is subdivided into Global and Local Administrator fields. The length of these fields depends on the value of the Type high order octet. If the Type high order octet has a value of 0x00 or 0x02, the Global Administrator is 2 octets (if the high order octet is 0x00) or 4 octets (if the high order octet is 0x02), and the Local Administrator is 4 or 2 octets. In this case, an autonomous system number (either 2 or 4 octets) is carried in the Global Administrator field. The Local Administrator field is, as the name suggests, a value is assigned by the local administrator.

Figure 6-18 shows the Route Target attribute when the Type high order octet is 0x00 or 0x02.

Figure 6-18. Route Target Attribute (High Order Octet Is 0x00 or 0x02)

[View full size image]

If the service provider uses autonomous system number 64512, and the Local Administrator number is 100, the Route Target attribute would be 64512:100. If the Type high order octet has a value of 0x01, then the Global Administrator is 4 octets, and the Local Administrator is 2 octets. In this case, an IP Address is carried in the Global Administrator field.

Figure 6-19 shows the Route Target attribute when the Type high order octet is 0x01.

Figure 6-19. Route Target Attribute (High Order Octet Is 0x01)

[View full size image]

If the service provider uses IP address 192.168.1.1, and the Local Administrator number is 100, the Route Target attribute would be 192.168.1.1:100.

Each VRF is configured with a set of import and export RTs. When VPN-IPv4 routes are inserted into the MP-BGP table, one or more route targets are attached. These are known as export route targets.

When a PE router receives a VPN-IPv4 route, it compares the attached RTs with the import RTs for each of its VRFs. If there is at least one match, the route is installed into the VRF.

Figure 6-20 illustrates VPN-IPv4 route export and import based on RTs.

Figure 6-20. VPN-IPv4 Route Export and Import

[View full size image]

NOTE

Route targets and other BGP extended communities are discussed in draft-ietf-idr-bgp-ext-communities.

VPN Route Distribution

In a MPLS Layer 3 VPN, customer edge (CE) routers advertise routes to provider edge (PE) routers using Routing Information Protocol (RIP) version 2, Enhanced Interior Gateway Routing Protocol (EIGRP), Open Shortest Path First (OSPF), or Exterior Border Gateway Protocol (EBGP).

After receiving customer routes from the CE, the PE converts them into VPN-IPv4 routes. One or more (export) RTs are then attached, and they are advertised in Multiprotocol BGP (MP-BGP) to other PE routers. The next-hop of these routes is the BGP update source of the advertising PE router.

VPN labels are also advertised, along with VPN-IPv4 prefixes. These labels identify the VRF or outgoing interface on the advertising PE router and are used for packet forwarding.

NOTE

Other standard and extended BGP communities, such as Site of Origin (used for loop prevention in multihomed sites), may also be attached to the VPN-IPv4 routes.

MP-BGP routes received by PE routers are installed into VRFs depending on the attached RTs. Routes installed into a VRF are then advertised to the attached customer sites in the VPN using RIP, EIGRP, OSPF, or EBGP.

Figure 6-21 shows the advertisement of customer routes across a service provider MPLS VPN backbone.

Figure 6-21. Advertisement of Customer Routes Across the Service Provider Backbone

[View full size image]

Although Figure 6-21 illustrates route advertisement only from CE2 to CE1, route advertisement from CE1 to CE2 is identically configured, just in the opposite direction.

The example in this section describes the use of PE-CE routing protocols, but static routes may also be configured for PE to CE connectivity.

NOTE

For more information about carrying label information in BGP, see RFC 3107.

Forwarding VPN Traffic Across the Backbone

When VPN traffic is forwarded across the MPLS VPN backbone, a two-label stack is used. The outer label is known as the IGP label and is used to forward the traffic from the ingress PE to the egress PE. The inner label is known as the VPN label and is used to identify the VRF or outgoing interface on the egress PE.

Figure 6-22 illustrates the forwarding of a packet across an MPLS VPN backbone from host 172.16.1.1 to host 172.16.5.1.

Figure 6-22. Packet Forwarding Across an MPLS VPN Backbone

[View full size image]

In Figure 6-22, an IP packet is sent from host 172.16.1.1 (on the left) to host 172.16.5.1 (on the right).

The IP packet is forwarded by CE1 to Chengdu_PE. Chengdu_PE does a Layer 3 lookup in the VRF mjlnet_VPN routing table and finds a route to network 172.16.5.0/24 with a next-hop of 10.1.1.4. 10.1.1.4 is the BGP update source on HongKong_PE.

Chengdu_PE then imposes a two-label stack, with the inner (VPN) label (36) corresponding to the IP prefix 172.16.5.0/24 in VRF mjlnet_VPN on HongKong_PE, and the outer (IGP) label (29) corresponding to the next-hop of route 172.16.5.0/24 (10.1.1.4).

Chengdu_PE forwards the packet to Chengdu_P. Chengdu_P consults its LFIB and swaps outer label 29 for label 25. The VPN label is unmodified.

Chengdu_P forwards the packet to HongKong_P. HongKong_P consults its LFIB, and pops (removes) outer label 25 (HongKong_P is the penultimate hop). Again, the VPN label is unmodified.

HongKong_P then forwards the packet to HongKong_PE. HongKong_PE examines the VPN label and, having found that it corresponds to VRF mjlnet_VPN, removes the label and forwards the unlabeled IP packet to CE2. Finally, CE2 forwards the packet onwards to host 172.16.5.1.

As previously noted, IP or GRE tunnels can be used to transport VPN traffic over a non-MPLS network between PE routers. In this case, the outermost MPLS label can be replaced by GRE or IP encapsulation.

MPLS VPN traffic can also be transported over a non-MPLS network using an L2TPv3 or IPSec tunnel. When L2TPv3 is used to transport VPN traffic over a non-MPLS network, the outermost MPLS label is replaced by L2TPv3 encapsulation. When MPLS VPN traffic is transported over an IPSec tunnel between PE routers, the outermost MPLS label is replaced by IP/IPSec encapsulation.

When comparing the three methods of encapsulation for transport of MPLS VPN traffic over a non-MPLS network, L2TPv3 allows a compromise between the strong security but high overhead of IP/IPSec and the very limited security of IP/GRE. The L2TPv3 cookie makes blind spoofing attacks more difficult to achieve when compared with IP/GRE because an attacker has to guess the cookie values in use (as well as the MPLS label value).

NOTE

See draft-ietf-mpls-in-ip-or-gre, draft-townsley-l2tpv3-mpls, and draft-ietf-l3vpn-ipsec-2547 for more information on MPLS VPN transport over IP or GRE, L2TPv3, and IP/IPSec respectively. See also Chapter 5, "Troubleshooting L2TP v3 Based VPNs," for more details on L2TPv3.

Unless otherwise specified, this chapter assumes transport of MPLS VPN traffic over an MPLS backbone.

Internet Access

VPN customers often require Internet access. The MPLS VPN provider can configure this in several ways. Two of the most popular ways of configuring Internet access are packet leaking between the VRF and global routing tables via static routes, and using separate interfaces for VPN and Internet access. Other methods of providing Internet access include via a shared service VPN or a separate ISP.

Providing VPN Customers Internet Access with Packet Leaking via Static Routes

Normally, VRF and global routing tables are completely separated. The VRF routing tables contain VPN routes, and the global routing table contains backbone IGP routes and either Internet routes or a route to an Internet gateway.

If packet leaking via static routes is configured, traffic outbound from the customer VPN to the Internet is allowed to "leak" from the VRF routing tables to the global routing table. Similarly, traffic inbound from the Internet is selectively allowed to leak into the customer VPN via the VRF interface.

Leaking from the VRF to the global routing table (for traffic outbound from the customer VPN) is accomplished by configuring a static VRF route with a next-hop in the global routing table. This static VRF route is usually a default route. Similarly, a global static route pointing to the customer networks (for traffic inbound from the Internet) is configured with an outgoing VRF interface.

Figure 6-23 illustrates Internet via route leaking.

Figure 6-23. Internet Access via Route Leaking

[View full size image]

In Figure 6-23, traffic outbound to the Internet from mjlnet_VPN site 1 arrives on the VRF interface of the PE router. The PE router routes the traffic using the default route in the VRF routing table. The next-hop is in the global routing table.

When traffic inbound from the Internet to mjlnet_VPN site 1 arrives on the PE router, the PE router forwards the traffic using the route in the global routing table. The outgoing interface of the route is the mjlnet_VPN VRF interface.

When configuring packet leaking, the global static route that points to the customer network should be redistributed into global BGP. This ensures that hosts on the Internet have a route back to the PE router. Also, the VRF static default route should be redistributed into the PE-CE routing protocol, if one is being used.

Providing VPN Customers Internet Access with a Separate Interface

Another way of configuring Internet access for a customer site is to configure one interface for VPN connectivity on the CE router and another separate interface for Internet connectivity. The interface for Internet connectivity is associated with the global routing table on the PE router.

Figure 6-24 illustrates Internet access via a separate interface.

Figure 6-24. Internet Access via a Separate Interface

[View full size image]

In Figure 6-24, traffic both outbound and inbound from the Internet is routed via the Internet (global) interface on the PE router. Routing can be configured between the CE and PE routers over the Internet interface in the standard way using BGP or static default routes.

Multicast VPNs (MVPNs)

Previously, if a customer required multicast connectivity between sites in an MPLS VPN, a mesh of point-to-point GRE tunnels between the CE routers was required. With the advent of Multicast VPNs (MVPNs), this is no longer necessary. The MVPN feature is based on Multicast Domains (MD), which are described in Internet Draft draft-rosen-vpn-mcast.

MVPNs allow a service provider to tunnel customer multicast traffic between sites over a core multicast tree (in other words, multicast over multicast tunneling).

MVPN presupposes support for PIM within the customer network, as well as the provider backbone. Supported modes include PIM Sparse-Mode (PIM-SM), PIM Bi-directional (PIM-BIDIR), and PIM Source Specific Multicast (PIM-SSM). PIM Dense Mode (PIM-DM) is also supported within the customer network.

When configuring and troubleshooting MVPN, you should have a good understanding of the following elements:

  • MVPN support on PE routers

  • Formation of PIM adjacencies in an MVPN environment

  • Default multicast forwarding in the backbone

  • Optimizing multicast forwarding in the backbone

The sections that follow discuss these elements in greater detail.

MPVN Support on the PE Router: The Multicast VRF, Multicast Tunnel, and Multicast Tunnel Interface

When MVPN is configured for a VRF on a PE router, a Multicast VRF (MVRF) and a Multicast Tunnel Interface (MTI) are created. The MVRF is the multicast routing table for the VRF. The MTI is an endpoint of the Multicast Tunnel (MT) and is used to forward customer multicast traffic between sites in an MVPN.

The MT source address is the MP-BGP update source on the PE router, and the destination address is the Multicast Distribution Tree (MDT) address.

Formation of PIM Adjacencies in an MVPN Environment

Each PE router maintains one instance of PIM for the backbone network, as well as one instance per MVRF. Provider backbone PIM adjacencies are maintained between PE routers' core interfaces and P routers. MVPN PIM adjacencies are maintained between PE and CE routers, as well as between PE routers over the MT.

Figure 6-25 illustrates PIM adjacencies in a MVPN environment.

Figure 6-25. PIM Adjacencies in a MVPN Environment

[View full size image]

Note that each PE router in Figure 6-25 has only one (multipoint) MTI. PE routers create a single MTI per MVRF. This means that each PE router in Figure 6-25 is maintaining two PIM adjacencies on their MTIs.

Default Multicast Forwarding in the Backbone: The Default MDT

A default Multicast Distribution Tree (default MDT) is maintained in the provider backbone for the purpose of forwarding customer multicast traffic and PIM control traffic between the MTIs on the PE routers. All PE routers participating in the MPVN join the default MDT.

Figure 6-26 illustrates the default MDT.

Figure 6-26. Default MDT

[View full size image]

In Figure 6-26, the default MDT (group 239.0.0.1) has been established over the provider backbone between Chengdu_PE, HongKong_PE, and Shanghai_PE. The backbone network in this example is configured for PIM Sparse Mode (PIM-SM), with Chengdu_P as the Rendezvous Point (RP). Customer multicast traffic (in this example, group 233.253.233.1) is forwarded over the default MDT.

Note that in Figure 6-26, HongKong_PE drops multicast traffic for group 233.253.233.1 because there are no receivers at MVPN_mjlnet site 2. This is the disadvantage of forwarding customer multicast traffic over the default MDT. Traffic is forwarded to all PE routers participating in the MVPN, regardless of whether there are any receivers at the site to which they are connected. The solution to this issue is the data MDT.

Optimizing Multicast Forwarding in the Backbone: The Data MDT

A data MDT (see Figure 6-27) is constructed across the provider backbone when traffic for a particular customer multicast group crosses a configured bandwidth threshold. Crucially, only PE routers connected to sites with receivers for this group join the data MDT.

Figure 6-27. Data MDT

[View full size image]

In Figure 6-27, the bandwidth threshold for group 233.253.233.1 has been exceeded, and a data MDT (group 239.0.1.0) has been established.

There is a receiver for group 233.253.233.1 at site 3, and so Shanghai_PE joins the data MDT. There are no receivers for this group at site 2, however, and so HongKong_PE does not join the data MDT.

Note that data MDTs are not established for PIM dense mode groups.


Configuring MPLS VPNs

Misconfiguration is a common cause of problems with MPLS VPNs. In this section, therefore, MPLS VPN configuration is discussed.

When configuring an MPLS VPN, there are three types of devices that must be configured, the CE router, the PE router, and the P router. The configuration of each of these devices is discussed in this section.

It may be useful to reference Figure 6-31 on page 476 while reading this section. Note, however, that not all configuration discussed in this section is illustrated.

Figure 6-31. Sample MPLS VPN Topology

[View full size image]

Configuring the CE Router

Configuration of the CE router is standardnothing special is required. The only restriction is that the routing protocol used between the CE and PE routers must currently be RIP version 2, EIGRP, OSPF, or EBGP. Static routes can also be used.

NOTE

The CE router is not enabled for MPLS unless carrier's carrier MPLS VPNs are configured.

Configuring the PE Router

Configuration of the PE router is much more complicated than that of the CE router.

The 12 basic steps involved are summarized as follows:

Step 1. | Configure the loopback interface to be used as the BGP update source and LDP router ID.
Step 2. | Enable CEF.
Step 3. | Configure the label distribution protocol.
Step 4. | Configure the TDP/LDP router-id (optional).
Step 5. | Configure MPLS on core interfaces.
Step 6. | Configure the MPLS VPN backbone IGP.
Step 7. | Configure global BGP parameters.
Step 8. | Configure MP-BGP neighbor relationships.
Step 9. | Configure the VRF instances.
Step 10. | Configure VRF interfaces.
Step 11. | Configure PE-CE routing protocols / static routes.
Step 12. | Redistribute customer routes into MP-BGP.

The sections that follow examine each step in detail.

Step 1: Configure the Loopback Interface to Be Used as the BGP Update Source and LDP Router ID

A loopback interface should be configured to act as the update source for BGP sessions, as well as the LDP router ID.

Ensure that the IP address on the loopback interface is configured with a 32-bit mask. This will prevent a lot of problems later.

For example, if the IGP used in the MPLS backbone is OSPF, and the loopback interface is not configured with a 32-bit mask, the PE router will advertise a label binding for the loopback address with the mask as specified on the loopback interface. The route advertised in OSPF to neighboring routers, on the other hand, will include a 32-bit mask. This is because OSPF advertises loopback addresses with a 32-bit mask by default (irrespective of the configured mask). The neighboring routers (LSRs) will create a label binding that corresponds to the OSPF route advertised by the PE router (using the advertised 32-bit mask), but because the label binding advertised by the PE router uses the configured non-32-bit mask, an LSP failure will result.

There are two ways around this: either configure the loopback interface on the PE router with a 32-bit mask, or configure the ip ospf network point-to-point command on the loopback interface, which will cause OSPF to advertise the mask as it is actually configured.

It is also very important to configure just one update source for MP-BGP if you intend to configure MVPNs. More than one update source can break MVPN.

Example 6-1 shows the configuration of the loopback interface to be used as the BGP update source and LDP router ID.

Example 6-1. Configuration of the Loopback Interface
interface Loopback0
 ip address 10.1.1.1 255.255.255.255

It's good practice to allocate one address block to use for all PE router loopback interface addresses.

Note that PE router loopback addresses should not be summarized in the core because this will break LSPs within the MPLS backbone.

Step 2: Enable CEF

Be sure to enable CEF. If CEF is not enabled on the PE router, MPLS will not function.

Example 6-2 shows how to enable CEF on the router.

Example 6-2. Enabling CEF
ip cef [distributed]

Note the keyword distributed. This is used to enable distributed CEF (dCEF). dCEF is available on high-end platforms such as the 12000 GSR and 7500 series.

Step 3: Configure the LDP

If using LDP in the MPLS backbone, you should configure LDP next. Note that TDP is the default label distribution protocol on Cisco routers. Example 6-3 shows the global configuration of LDP as the label distribution protocol.

Example 6-3. Configuration of LDP as the Label Distribution Protocol
mpls label protocol ldp

Step 4: Configure the TDP/LDP Router ID (Optional)

The next step is to configure the TDP/LDP router ID. This step is optional, but it can make the troubleshooting process easier if you are able to easily identify TDP/LDP routers in the network.

Example 6-4 shows the configuration of the LDP router ID.

Example 6-4. Configuration of the LDP Router ID
mpls ldp router-id Loopback0 [force]

In Example 6-4, the IP address on interface loopback 0 is configured as the LDP router ID. Note the optional force keyword, which ensures that the IP address on interface loopback 0, and not the IP address of any other interface, becomes the LDP router ID.

If the LDP router ID is not explicitly configured as shown in Example 6-4, the LDP ID will become the highest loopback interface address or, in the absence of a loopback interface, the highest IP address configured on a physical interface. It is definitely a good idea to ensure that the LDP ID corresponds to a loopback interface because loopback interfaces are always in an up state.

Step 5: Configure MPLS on Core Interfaces

The next step is to enable MPLS on interfaces connected to other PE and P routers. Note that when MPLS is enabled on the first interface, it is also globally enabled on the router.

Example 6-5 shows the configuration of MPLS on core frame-mode interfaces.

Example 6-5. Configuring MPLS on Core Frame-Mode Interfaces
interface Serial4/0
 mpls ip

As previously mentioned, ATM interfaces can be configured for either frame-mode or cell-mode.

Frame-mode can be configured over ATM PVCs between edge LSRs. In this case, intervening ATM switches do not participate in MPLS at all and do not need to be MPLS-enabled.

Example 6-6 shows the configuration of an ATM interface for frame-mode MPLS.

Example 6-6. Configuration of Frame-mode MPLS on an ATM Interface
interface ATM3/0.1 point-to-point
 ip address 10.20.100.1 255.255.255.0
 pvc 1/50
  encapsulation aal5snap
 !
 mpls ip

In Example 6-6, MPLS is enabled on an ATM PVC with VPI/VCI 1/50. Note that the subinterface type is point-to-point and that the mpls ip command is configured on the subinterface.

ATM interfaces can also be configured for cell-mode MPLS. These interfaces are known as Label Controlled ATM (LC-ATM) interfaces.

Example 6-7 shows the configuration of cell-mode MPLS on an ATM interface of an IOS router.

Example 6-7. Configuration of Cell-Mode MPLS on an ATM Interface
interface ATM3/0.1 mpls
 ip address 10.20.90.1 255.255.255.0
 mpls ip

In Example 6-7, the subinterface type is mpls. Also note the command mpls ip on the subinterface itself.

When cell-mode MPLS is enabled on an ATM interface, a PVC with VPI/VCI 0/32 (by default) is automatically created for control plane traffic.

Step 6: Configure the MPLS VPN Backbone IGP

Although it is possible to use any IGP for IP reachability within the MPLS VPN backbone, IS-IS and OSPF are the two most commonly chosen because they are the only two IGPs that currently support MPLS traffic engineering.

The OSPF and IS-IS protocol configurations covered in the two sections that follow are only examples.

IS-IS

The configuration of IS-IS on the PE router is, to a large extent, standard.

Example 6-8 shows the configuration of IS-IS for IP reachability within the MPLS VPN backbone.

Example 6-8. Configuration of IS-IS as the MPLS VPN Backbone IGP
router isis
 passive-interface Loopback0
 net 49.0001.0000.0000.0001.00
 is-type level-2-only
 metric-style wide

The router isis command enables IS-IS on the PE router.

Interface loopback 0 is then enabled for IS-IS using the passive-interface loopback0 command. Note that because the interface is passive, no IS-IS packets are needlessly sent on the interface.

Be sure to advertise the BGP update source into the IS-IS. If the update source is not advertised, MPLS VPNs will break.

The third command in the configuration is net 49.0001.0000.0000.0001.00. This is used to configure the network entity title (NET). 49.0001 is the area ID, 0000.0000.0001 is the system ID, and .00 is the selector value.

The next command, is-type level-2-only, configures the PE router as a Level 2 (backbone) router only.

Finally, the command metric-style wide configures the router to send and to receive only new style 24- or 32-bit metrics. Support for new style metrics are essential if you are intending to use MPLS traffic engineering.

Ensure that all IS-IS routers in the backbone are configured to support standard or wide metrics (or both). IS-IS must also be enabled on each of its core interfaces.

Example 6-9 shows the configuration of IS-IS on core interfaces.

Example 6-9. Configuration of IS-IS on Core Interfaces
interface FastEthernet1/0
 ip router isis

In Example 6-9, IS-IS for IP is enabled on interface FastEthernet1/0 using the command ip router isis.

OSPF

OSPF configuration for the backbone is, again, fairly standard.

Example 6-10 shows the configuration of OSPF for IP reachability within the MPLS VPN backbone.

Example 6-10. Configuration of OSPF as the MPLS VPN Backbone IGP
router ospf 100
 passive-interface Loopback0
 network 10.0.0.0 0.255.255.255 area 0

The command router ospf 100 enables OSPF process 100 on the PE router.

All backbone interfaces in network 10.0.0.0/8 are placed in OSPF area 0 using the network 10.0.0.0 0.255.255.255 area 0 command.

Finally, the passive-interface Loopback0 prevents the sending of OSPF packets on interface loopback 0.

Be sure to advertise the BGP update source into OSPF. If the update source is not advertised, MPLS VPNs will break.

Note that if your network consists of ATM-LSRs, make sure that summarization of IGP routes is not configured on P routers. This is because ATM-LSRs have no "IP intelligence" on the data plane.

Step 7: Configure Global BGP Parameters

MP-BGP is used to advertise customer routes across the MPLS VPN backbone between PE routers. The configuration of MP-BGP is a two-step process, with neighbors being configured globally and then activated for MP-BGP route exchange under the VPNv4 (VPN-IPv4) address family.

Example 6-11 shows global BGP configuration on the PE router.

Example 6-11. Global BGP Configuration on the PE Router
router bgp 64512
 no synchronization
 neighbor 10.1.1.4 remote-as 64512
 neighbor 10.1.1.4 update-source Loopback0
 neighbor 10.1.1.6 remote-as 64512
 neighbor 10.1.1.6 update-source Loopback0
 no auto-summary

The first command, router bgp autonomous_system, enables BGP on the PE router.

Global IGP synchronization is then disabled using the no synchronization command.

The command neighbor ip_address remote-as autonomous_system configures the IP address and autonomous system of the remote PE router or route reflector.

Next comes the neighbor ip_address update-source Loopback0. This configures interface loopback 0 as the update source for the BGP session.

It is highly recommended that a single interface (preferably with a 32-bit mask) be configured as the MP-BGP update source. Not doing so might result in broken MPLS VPNs and MVPNs.

The command no auto-summary is used to ensure that routes redistributed into BGP (via the redistribute command) are not summarized at major network boundaries.

One other command that might be useful on the PE router is the no bgp default ipv4-unicast command, which disables the exchange of global BGP (Internet) routes. Only MP-BGP, and not global BGP, routes are required for MPLS VPN functionality.

Step 8: Activate MP-BGP Neighbors

MP-BGP is used for the exchange of VPN routes between the PE routers. MP-BGP route exchange must be activated under the VPNv4 address family.

Example 6-12 shows the activation of MP-BGP route exchange.

Example 6-12. Activation of MP-BGP Route Exchange
router bgp 64512
!
address-family vpnv4
 neighbor 10.1.1.4 activate
 neighbor 10.1.1.4 send-community extended
 neighbor 10.1.1.6 activate
 neighbor 10.1.1.6 send-community extended
 no auto-summary
 exit-address-family

The command address-family vpnv4 is used to enter the VPNv4 address family configuration mode.

The neighbor ip_address activate is used to activate MP-BGP route exchange.

The command neighbor ip_address send-community extended is configured by default and enables the exchange of BGP extended communities, such as route target and site of origin.

TIP

If you want BGP peers to also exchange standard BGP communities, you must use the keyword both in place of the extended keyword.

Finally, the command no auto-summary command specifies that redistributed routes should not be summarized at major network boundaries. This command is configured by default.

Note that if route reflectors are used for VPN route exchange between PE routers, ensure that they are also configured for MP-BGP route exchange between route reflector clients.

Step 9: Configure the VRF Instances

The next step is the configuration of the VRFs, as demonstrated in Example 6-13.

Example 6-13. Configuration of a VRF
ip vrf mjlnet_VPN
 rd 64512:100
 route-target export 64512:100
 route-target import 64512:100

The first line of the configuration enables a VRF named mjlnet_VPN.

NOTE

It is worth noting that VRF names are case-sensitive and have local significance only. They do not need to match between the PE-routers, although it is good practice.

The second line, rd 64512:100, is used to configure the route distinguisher for the VRF. The VRF, in this case, uses the ASN:XX format (autonomous system number : local administrator number).

Next comes the configuration of the export and import route targets. The route targets here also use the ASN:XX format.

The route-target export 64512:100 comand configures an export route target. This route target is attached to customer routes when they are redistributed into MP-BGP.

It is also possible to use an export map to advertise selected routes with certain route targets. This can be useful, for example, when advertising the loopback interface addresses of CE routers with a certain route target. These CE router loopback IP address routes can then be imported into a management VRF so that the provider can remotely manage the CE routers.

NOTE

For more information about the configuration of export-maps, see the following URL:

http://www.cisco.com/en/US/products/sw/iosswrel/ps1831/products_command_reference_chapter09186a0080080c7a.html#1058515

The route-target import 64512:100 command configures an import route target. This command is used to specify which routes are imported into the VRF. In this case, routes with an attached route target of 64512:100 will be imported.

Routes can be more selectively imported into a VRF using an import map.

NOTE

More information on the configuration of import-maps can be found at the following URL:

http://www.cisco.com/en/US/products/sw/iosswrel/ps1831/products_command_reference_chapter09186a0080080c7a.html#1028893

Step 10: Configure VRF Interfaces

After configuring the VRF, the next step is to associate customer interfaces with it.

Example 6-14 shows the configuration of VRF interfaces on PE routers.

Example 6-14. Configuration of VRF Interfaces
interface Serial4/1
 ip vrf forwarding mjlnet_VPN

The ip vrf forwarding mjlnet_VPN command associates an interface with a customer VRF. In this case, interface serial 4/1 is associated with VRF mjlnet_VPN.

Step 11: Configure PE-CE Routing Protocols / Static Routes

Configuration of the PE-CE routing protocol varies according to whether RIP version 2, EIGRP, OSPF, or EBGP is being used. Static routes can also be used for PE-CE connectivity.

The sections that follow describe configuration of the various PE-CE routing protocols.

RIP Version 2

When configuring RIP version 2 for PE-CE routing, most of the configuration is under the IPv4 address family. Example 6-15 shows the configuration of RIP version 2 for PE-CE routing.

Example 6-15. Configuration of RIP Version 2 for PE-CE Routing
router rip
 version 2
 !
 address-family ipv4 vrf mjlnet_VPN
 version 2
 redistribute bgp 64512 metric transparent
 network 172.16.0.0
 no auto-summary
 exit-address-family

The command router rip enables RIP on the PE router. RIP version 2 is then configured using the command version 2.

Next comes the address-family ipv4 vrf vrf_name command. RIP configuration for the VRF is configured under the IPv4 address family.

By specifying version 2 globally (directly under router rip), it is inherited by all the address families configured under RIP.

Under the address family, be sure to specify redistribution from (MP-BGP or BGP into RIP. Alternatively, you can originate a default route into RIP if it is a large network. Remember that customer routes are advertised between PE routers using MP-BGP. These routes are then imported into the customer VRFs. The command redistribute bgp autonomous_system metric transparent can then be used to redistribute these routes into RIP for advertisement to the attached customer site or sites.

Note the use of metric transparent. RIP metrics are preserved when they are advertised in MP-BGP (they are copied into the MED attribute), which ensures that these metrics are redistributed back into RIP unmodified.

Make sure that a metric, whether a specific metric or the keyword transparent, is configured when redistributing MP-BGP routes into RIP. If one is not specified, the routes may not be redistributed.

The rest of the configuration is pretty standard stuff, with the network command used to specify the networks enabled for RIP, and the no-auto-summary command used to ensure that networks are not summarized at major network boundaries. Note that no auto-summary is on by default under the address family.

EIGRP

Configuration of EIGRP is similar to RIP, with most parameters configured under the IPv4 address-family.

Example 6-16 shows a sample configuration of EIGRP for PE-CE routing.

Example 6-16. Configuration of EIGRP for PE-CE Routing
router eigrp 10
 no auto-summary
 !
 address-family ipv4 vrf mjlnet_VPN
 redistribute bgp 64512 metric 1 1 255 1 1500
 network 172.16.0.0
 no auto-summary
 autonomous-system 100
 exit-address-family

The router eigrp 10 command enables EIGRP autonomous system 10 on the PE router.

The second command is no auto-summary. This ensures that networks are not summarized at major network boundaries.

The configuration of EIGRP for PE-CE connectivity itself is specified under an IPv4 address-family (address-family ipv4 vrf vrf_name). Each customer VRF requires a separate address family.

The configuration under the IPv4 address family starts with redistribution of MP-BGP routes from other customer sites into EIGRP using redistribute bgp autonomous_system metric metric (bandwidth, delay, reliability, load, and MTU). Make sure that you specify a metric when redistributing MP-BGP routes into EIGRP. If one is not specified, redistribution may fail. Next is the network command, which is used to specify the networks enabled for EIGRP. The no auto-summary command is configured by default under the address family.

The final command under the address family is autonomous-system autonomous_system. This is the EIGRP autonomous system number for the customer VPN. If this is not the same as that configured as that on the CE router, then no adjacency will be formed.

NOTE

If you want all the sites in the VPN to be in the same EIGRP autonomous system, the autonomous system number must be consistent for the VRF on all PE routers.

OSPF

When configuring OSPF, a separate OSPF process must be configured for each customer VRF running OSPF as the PE-CE routing protocol.

Example 6-17 shows the configuration of OSPF for customer site routing.

Example 6-17. Configuration of OSPF for PE-CE Routing
router ospf 100 vrf mjlnet_VPN
 redistribute bgp 64512 subnets
 network 172.16.4.0 0.0.0.255 area 0

The first command in the configuration is router ospf process_ID vrf vrf_name. In this case, OSPF process 100 is configured for VRF mjlnet_VPN.

NOTE

If you want all the sites in the VPN to be in the same OSPF autonomous system, the process ID configured for the VRF on all PE routers must be the same. Alternatively, use the domain-id command to configure a consistent domain ID number (by default, the domain ID corresponds to the OSPF process ID).

The OSPF domain ID is carried in the Domain Identifier BGP extended community described in Internet Draft draft-ietf-l3vpn-ospf-2547.

The third command is redistribute bgp autonomous_system subnets. This is used to configure redistribution of MP-BGP (routes from remote sites) into OSPF. Note the subnets keyword. This ensures that subnets, and not just major networks, are redistributed.

EBGP

Configuration of EBGP for PE-CE connectivity is pretty straightforward. Again, most of the configuration is under the IPv4 address family.

Example 6-18 shows the configuration of EBGP for PE-CE routing.

Example 6-18. Configuration of EBGP for PE-CE Routing
router bgp 64512
!
address-family ipv4 vrf mjlnet_VPN
 neighbor 172.16.4.2 remote-as 65001
 neighbor 172.16.4.2 activate
 no auto-summary
 no synchronization
 exit-address-family

The address-family ipv4 vrf vrf_name command is used to enter the IPv4 address family configuration mode.

The first command under the IPv4 address family is neighbor ip_address remote-as autonomous_system. This configures the IP address and autonomous system of the CE router.

Next is neighbor ip_address activate. This activates the BGP session with the CE router.

Finally, the no auto-summary and no synchronization commands are used to disable auto summarization at major network boundaries for routes redistributed via the redistribute command into BGP, and to disable IGP synchronization. These two commands are enabled by default.

Note that unlike for other PE-CE routing protocols, redistribution is unnecessary from MP-BGP into EBGP.

Static Routes

Static routes can also be used for PE-CE connectivity. Example 6-19 shows configuration of static routes for PE-CE connectivity.

Example 6-19. Configuration of Static Routes for PE-CE Connectivity
ip route vrf mjlnet_VPN 172.16.1.0 255.255.255.0 172.16.4.2 [permanent]

Configuration of static routes is the same as that for regular static routes with the network, mask, and next-hop specified. The vrf keyword must be used, however, to ensure that the static route is placed in the VRF specified (in this case, mjlnet_VPN).

Note also the permanent keyword. This can optionally be used to ensure that the route will remain in the VRF even if reachability to the next hop is lost. This can be important for stability when redistributing static routes into MP-BGP.

Step 12: Redistribute Customer Routes into MP-BGP

The final step is to configure the redistribution of customer routes into MP-BGP, as demonstrated in Example 6-20.

Example 6-20. Redistribution of Customer Routes into MP-BGP
router bgp 64512
!
address-family ipv4 vrf mjlnet_VPN
 redistribute rip
 no auto-summary
 no synchronization
 exit-address-family

The address-family ipv4 vrf vrf_name command is used to enter the IPv4 address family configuration mode.

The redistribute rip command is used to redistribute customer RIPv2 routes into MP-BGP.

If the PE-CE routing protocol is EIGRP, the command redistribute eigrp autonomous_system is used. Ensure that the autonomous system number configured corresponds to that specified under the EIGRP IPv4 address family.

For OSPF, the command redistribute ospf process_ID match internal external 1 external 2 can be used. Note that in this case, internal and external type 1 and 2 routes are redistributed.

Finally, if static routes are being used, the command redistribute static can be used. It is also worth noting that if EBGP is being used, redistribution is not required.

Finally, the no auto-summary and no synchronization commands are defaults that specify that redistributed routes should not be summarized at major network boundaries, and that synchronization should be disabled.

That concludes the configuration of the PE router.

PE Router Sample Configuration

Example 6-21 shows a complete sample configuration of a PE router.

Example 6-21. Complete Sample Configuration of a PE Router
Chengdu_PE#show running-config
Building configuration...
Current configuration : 3434 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
!
hostname Chengdu_PE
!
logging buffered 16384 debugging
enable secret 5 $1$4pDG$mVThUgDZG33pNYZ20.UKU/
!
ip subnet-zero
no ip source-route
!
! Enable Cisco Express Forwarding (CEF)
ip cef
!
!
no ip finger
no ip bootp server
!
! Configure the VPN Routing and Forwarding (VRF) instances
ip vrf mjlnet_VPN
 rd 64512:100
 route-target export 64512:100
 route-target import 64512:100
!
ip vrf cisco_VPN
 rd 64512:200
 route-target export 64512:200
 route-target import 64512:200
!
! Configure the label distribution protocol
mpls label protocol ldp
no mpls traffic-eng auto-bw timers frequency 0
!
! Configure the TDP/LDP router-id (tag-switching tdp router-id = mpls ldp router-id)
tag-switching tdp router-id Loopback0 force
!
! Configure the loopback interface to be used as the BGP update source and LDP router ID
interface Loopback0
 ip address 10.1.1.1 255.255.255.255
 no ip directed-broadcast
!
! Configure MPLS on core interfaces
interface FastEthernet1/0
 ip address 10.20.10.1 255.255.255.0
 no ip redirects
 no ip directed-broadcast
 no ip proxy-arp
 ip router isis
 tag-switching ip
 no cdp enable
!
! Configure VRF interfaces
interface Serial4/1
 ip vrf forwarding mjlnet_VPN
 ip address 172.16.4.1 255.255.255.0
 no ip redirects
 no ip directed-broadcast
 no ip proxy-arp
 encapsulation ppp
 no cdp enable
!
interface Serial4/2
 ip vrf forwarding cisco_VPN
 ip address 192.168.4.1 255.255.255.0
 no ip redirects
 no ip directed-broadcast
 no ip proxy-arp
 no cdp enable
!
! Configure PE-CE routing protocol for cisco_VPN
router ospf 200 vrf cisco_VPN
 log-adjacency-changes
 redistribute bgp 64512 subnets
 network 192.168.4.0 0.0.0.255 area 0
!
! Configure the MPLS VPN backbone IGP
router isis
 passive-interface Loopback0
 net 49.0001.0000.0000.0001.00
 is-type level-2-only
 metric-style wide
!
! Configure PE-CE routing protocol for mjlnet_VPN
router rip
 version 2
 !
 address-family ipv4 vrf mjlnet_VPN
 version 2
 redistribute bgp 64512 metric transparent
 network 172.16.0.0
 no auto-summary
 exit-address-family
!
! Configure basic BGP parameters
router bgp 64512
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.1.1.4 remote-as 64512
 neighbor 10.1.1.4 update-source Loopback0
 neighbor 10.1.1.6 remote-as 64512
 neighbor 10.1.1.6 update-source Loopback0
 no auto-summary
 !
 ! Configure MP-BGP neighbor relationships
 address-family vpnv4
 neighbor 10.1.1.4 activate
 neighbor 10.1.1.4 send-community extended
 neighbor 10.1.1.6 activate
 neighbor 10.1.1.6 send-community extended
 no auto-summary
 exit-address-family
 !
! Redistribute customer routes into MP-BGP
 address-family ipv4 vrf cisco_VPN
 redistribute ospf 200 match internal external 1 external 2
 no auto-summary
 no synchronization
 exit-address-family
 !
 address-family ipv4 vrf mjlnet_VPN
 redistribute rip
 no auto-summary
 no synchronization
 exit-address-family
!
ip classless
!
logging trap debugging
!
!
line con 0
 exec-timeout 0 0
 password 7 1511021F0725
 login
line aux 0
line vty 0 4
 password 7 110A1016141D
 login
!
end

You might notice that a number of commands discussed in this section are not immediately apparent in the configuration shown in Example 6-21. An example is the mpls ip command. In fact, the mpls keyword is translated into the tag-switching keyword. This allows backward compatibility with versions of the Cisco IOS software that do not support the mpls keyword.

The only exception to this is the mpls label protocol command, which remains in its original form.

Configuring the P Router

Configuration of P routers is, by comparison with that of PE routers, very simple.

The six basic steps in the configuration are as follows:

Step 1. | Configure the loopback interface to be used as the LDP router ID.
Step 2. | Enable CEF.
Step 3. | Configure the label distribution protocol.
Step 4. | Configure the TDP/LDP router ID (optional).
Step 5. | Configure MPLS on core interfaces.
Step 6. | Configure IS-IS or OSPF as the MPLS VPN backbone IGP.

As you can see, these six steps are identical to the first six steps for the configuration of the PE router. Please refer to the previous section for an explanation of each of these steps.

Example 6-22 shows a complete sample configuration of a P router.

Example 6-22. Complete Sample Configuration of a P Router
Chengdu_P#show running-config
Building configuration...
Current configuration : 1991 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
!
hostname Chengdu_P
!
logging buffered 16384 debugging
no logging console
enable secret 5 $1$4pDG$mVThUgDZG33pNYZ20.UKU/
!
ip subnet-zero
no ip source-route
!
! Enable Cisco Express Forwarding (CEF)
ip cef
!
!
no ip finger
no ip bootp server
!
! Configure the label distribution protocol
mpls label protocol ldp
no mpls traffic-eng auto-bw timers frequency 0
!
! Configure the TDP/LDP router-id
tag-switching tdp router-id Loopback0 force
!
! Configure the loopback interface to be used as the LDP router id
interface Loopback0
 ip address 10.1.1.2 255.255.255.255
 no ip directed-broadcast
!
! Configure MPLS on core interfaces
interface FastEthernet1/0
 ip address 10.20.10.2 255.255.255.0
 no ip redirects
 no ip directed-broadcast
 no ip proxy-arp
 ip router isis
 tag-switching ip
 no cdp enable
!
interface Serial1/0
 ip address 10.20.20.1 255.255.255.0
 no ip redirects
 no ip directed-broadcast
 no ip proxy-arp
 ip router isis
 encapsulation ppp
 tag-switching ip
 no fair-queue
 no cdp enable
!
interface Serial1/1
 ip address 10.20.40.1 255.255.255.0
 no ip redirects
 no ip directed-broadcast
 no ip proxy-arp
 ip router isis
 encapsulation ppp
 tag-switching ip
 no fair-queue
 no cdp enable
!
!
! Configure IS-IS as the MPLS VPN backbone IGP
router isis
 passive-interface Loopback0
 net 49.0001.0000.0000.0002.00
 is-type level-2-only
 metric-style wide
!
ip classless
!
logging trap debugging
!
line con 0
 exec-timeout 0 0
 password 7 1511021F0725
 login
line aux 0
line vty 0 4
 password 7 110A1016141D
 login
!
end

Notice again that the mpls keyword has been converted into the tag-switching keyword for backward compatibility. This completes the configuration of MPLS VPNs.


Configuring MVPNs

MVPNs are configured on PE routers in an MPLS VPN backbone. In addition, PIM must be enabled on CE and P routers. This section discusses the configuration of CE, PE, and P routers to enable MPVN in the MPLS VPN backbone.

Configuring the CE Router

MVPN supports the configuration of PIM within customer sites. PIM must be enabled on the CE interface connected to the MVPN-enabled PE router.

Example 6-23 shows the configuration of PIM on the PE router connected interface of the CE router.

Example 6-23. Configuration of PIM on CE Router Interfaces
interface Serial0
 ip pim sparse-dense-mode

In this example, the ip pim sparse-dense-mode command is used to enable PIM sparse-dense mode on the interface connected to the PE router (serial 0, in this case).

NOTE

Any other existing PIM configuration within the customer network can remain unchanged.

Configuring the Backbone (P Routers)

PIM must be configured on P routers within the MPLS VPN backbone. PIM configuration can be flexible, but PIM dense mode is not supported.

The service provider backbone may, for example, be configured for PIM Sparse-Mode (PIM-SM) or PIM Source Specific Multicast (PIM-SSM). If PIM-SSM is configured, then a rendezvous point (RP) is not required.

NOTE

See Developing IP Multicast Networks: The Definitive Guide to Designing and Deploying Cisco IP Multicast Networks by Beau Williamson (Cisco Press) for more on PIM Sparse mode and multicast in general. See Cisco.com for more on PIM Source Specific Multicast.

Because PIM can be configured in a variety of ways within the provider backbone, no particular configuration is given here.

Configuring the PE Router

The five basic steps in the configuration of the PE router are as follows:

Step 1. | Globally enable multicasting and MVRFs.
Step 2. | Configure PIM on the BGP update source interface.
Step 3. | Configure default and (optionally) data MDTs.
Step 4. | Configure PIM on the core interfaces.
Step 5. | Configure PIM on the VRF interface.

The following sections detail each step.

Step 1: Globally Enable Multicasting and MVRFs

Multicasting must be enabled globally and for MVRFs.

Example 6-24 shows the configuration of global multicasting and MVRFs.

Example 6-24. MVRF Configuration
ip multicast-routing [distributed]
ip multicast-routing vrf mjlnet_VPN [distributed]

The command ip multicast-routing [distributed] is used to globally enable multicast on the PE router.

The following command, ip multicast-routing vrf vrf_name [distributed], is then used to enable multicast for a VRF. In this case, multicast is enabled for VRF mjlnet_VPN.

Note that the distributed keyword enables support for Multicast Distributed Switching (MDS). This feature is available on the Cisco 7500 and 12000 series routers.

Step 2: Configure Default and (Optionally) Data MDTs

The next step is to configure the default and data MDTs.

Example 6-25 shows the configuration of default and data MDTs.

Example 6-25. Configuration of the Default and Data MDTs
ip vrf mjlnet_VPN
 mdt default 239.0.0.1
 mdt data 239.0.1.0 0.0.0.7 threshold 50 list 101
!
access-list 101 permit ip any 233.253.233.0 0.0.0.255

The ip vrf vrf_name command is used to begin VRF configuration. The default MDT group is then configured using the mdt default group_address command. In this example, the group address 239.0.0.1 is used.

Note that the group address for the default MDT must be the same on all PE routers for the same VPN. Also, each VPN must have a unique group address for the default MDT.

The command mdt data group_address wildcard_bits [threshold threshold_value] [list access-list] is then used to configure the data MDT groups.

NOTE

The configuration of data MDTs is optional.

In this case, a pool of eight group address (239.0.1.0 to 239.0.1.7) is configured for data MDTs.

A threshold of 50 kbps is specified for those multicast groups that match access list 101 (233.253.233.0 to 233.253.233.255). This means that a data MDT will be dynamically created whenever multicast traffic matching access list 101 exceeds the 50-kbps threshold. When configuring data MDTs, the threshold and list parameters are optional.

Step 3: Configure PIM on the BGP Update Source Interface

The next step is the configuration of PIM on the BGP update source. Example 6-26 shows the configuration of PIM on the BGP update source interface.

Example 6-26. Configuration of PIM on the BGP Update Source Loopback Interface
interface Loopback0
 ip pim sparse-dense-mode

The ip pim sparse-dense-mode command is used to enable PIM sparse-dense mode on the BGP update source (in this case, interface loopback 0).

Make sure that only one MP-BGP update source is used on each PE router. If more than one is used, this can break MVPN.

Also ensure that ip mroute-cache [distributed] is configured on the loopback interface. Again, the distributed keyword enables support for MDS.

Step 4: Configure PIM on the Core Interfaces

Next, you should configure PIM on core interfaces.

Example 6-27 shows the configuration of PIM on the core interfaces.

Example 6-27. Configure PIM on Core Interfaces
interface FastEthernet1/0
 ip pim sparse-dense-mode

The ip pim sparse-dense-mode command is used to enable PIM sparse-dense mode on the core interface (in this case, interface Fast Ethernet 1/0).

Step 5: Configure PIM on the VRF Interfaces

Finally, you should configure PIM on the VRF interfaces.

Example 6-28 shows the configuration of PIM on the VRF interfaces.

Example 6-28. Configuration of PIM on the VRF Interfaces
interface Serial4/1
 ip pim sparse-dense-mode

The ip pim sparse-dense-mode command is used to enable PIM sparse-dense mode on the VRF interface (in this case, interface serial 4/1).


Configuring TE Tunnels to Carry MPLS VPN Traffic

MPLS VPN traffic can be carried over MPLS traffic engineering (TE) tunnels.

Two different configurations are discussed in this section:

  • Transport of MPLS VPN traffic over TE tunnels between PE routers

  • Transport of MPLS VPN traffic over TE tunnels between P routers

Figure 6-28 shows both of these configurations.

Figure 6-28. Transport of MPLS VPN Traffic over PE-PE and P-P Routers

[View full size image]

Configuring TE Tunnels Between PE Routers

In this configuration, PE routers are configured as TE tunnel head-end and tail-end routers. P routers are configured as TE midpoint routers.

Configuring the Head-End Router

The configuration of the head-end (PE) router consists of the following steps, which are examined in detail in the sections that follow:

Step 1. | Globally enable MPLS TE.
Step 2. | Configure interface parameters.
Step 3. | Configure the backbone IGP for MPLS TE.
Step 4. | Configure the MPLS TE tunnel.
Step 1: Globally Enable MPLS TE

The first step in the configuration of the head-end router is to globally enable MPLS TE.

Example 6-29 shows how to enable MPLS TE on the head-end router.

Example 6-29. Enabling MPLS TE on the Head-end Router
mpls traffic-eng tunnels

The mpls traffic-eng tunnels command globally enables MPLS TE on the router.

Step 2: Configure Interface Parameters

The next step is to enable MPLS TE and RSVP on core interfaces.

Example 6-30 shows the configuration of MPLS TE on core interfaces.

Example 6-30. Configuration of MPLS TE on Core Interfaces
interface Serial4/0
 mpls traffic-eng tunnels
 ip rsvp bandwidth 1024

The command mpls traffic-eng tunnels enables MPLS TE on core interfaces.

The ip rsvp bandwidth interface_bandwidth command configures the maximum reservable bandwidth on the interface. In this case, 1024 kbps is configured as the amount of bandwidth reservable on the interface.

NOTE

The ip rsvp bandwidth interface_bandwidth command is not actually required on interfaces if you are using zero-bandwidth TE tunnelsbut that is a pretty rare configuration.

Step 3: Configure the Backbone IGP for MPLS TE

The backbone IGP must be configured to support MPLS TE. The only two IGPs that currently support MPLS TE are IS-IS and OSPF.

Example 6-31 shows the configuration of IS-IS to support MPLS TE.

Example 6-31. Configuration of IS-IS to Support MPLS TE
router isis
 metric-style wide
 mpls traffic-eng router-id Loopback0
 mpls traffic-eng level-2

The router isis command begins IS-IS configuration on the router.

The command metric-style wide configures IS-IS to send and receive 24- and 32-bit metrics. Support for wide metrics is essential for MPLS TE.

The next command, mpls traffic-eng router-id interface, configures a router ID to be used with TE.

The final command in the configuration is mpls traffic-eng level-1 | level-2. This command enables MPLS TE within the specified IS-IS level. The appropriate IS-IS level should be specified, but note that if interarea MPLS TE is being used, both level 1 and level 2 should be specified on level 1/2 routers.

Example 6-32 shows the configuration for OSPF to support MPLS TE.

Example 6-32. Configuration of OSPF to Support MPLS TE
router ospf 10
 mpls traffic-eng router-id Loopback0
 mpls traffic-eng area 0

The router ospf process_id command begins OSPF configuration on the router.

Next is the mpls traffic-eng router-id interface command, which configures a router ID for MPLS TE.

Finally, the command mpls traffic-eng area area_id enables MPLS TE within the specified area. If you are using interarea MPLS TE, ensure that all areas that the tunnel will transit are specified on Area Border Routers (ABRs). On non-ABRs, configure the area in which the router is.

Step 4: Configure the MPLS TE Tunnel

The next step in the configuration of the head-end router is the configuration of the TE tunnel itself.

Example 6-33 shows the configuration of the MPLS TE tunnel.

Example 6-33. Configuration of the MPLS TE Tunnel
interface Tunnel10
 ip unnumbered Loopback0
 tunnel destination 10.1.1.4
 tunnel mode mpls traffic-eng
 tunnel mpls traffic-eng autoroute announce
 tunnel mpls traffic-eng bandwidth 256
 tunnel mpls traffic-eng path-option 10 dynamic

In Example 6-33, tunnel interface 10 is configured for MPLS TE.

The command ip unnumbered interface is configured. MPLS tunnels must be configured with an IP address, and though it is not mandatory, ip unnumbered is recommended. Do not forget this command when configuring the TE tunnel. If an IP address is not configured on the tunnel interface, no traffic will be forwarded over it.

The next command, tunnel destination ip_address, configures the TE tunnel destination. This is the MPLS router ID of the tail-end router.

The command tunnel mode mpls traffic-eng command enables the tunnel interface for MPLS TE.

Following the tunnel mode mpls traffic-eng command is tunnel mpls traffic-eng autoroute announce. This command allows the IGP to use the tunnel in SPF calculations, which, in turn, allows VPN traffic to be forwarded over the tunnel. Note that tunnel mpls traffic-eng autoroute announce is not supported for interarea tunnels.

Another method of forwarding VPN traffic over TE tunnels is to use static routes. Make sure that you configure either autoroute or static routes to direct traffic into the TE tunnel. If you do not do this, the TE tunnel will not carry VPN traffic.

Next is the tunnel mpls traffic-eng bandwidth bandwidth command. This command is optional and specifies an amount of bandwidth to be reserved for the TE tunnel along its path.

The final command is tunnel mpls traffic-eng path-option number dynamic. This command configures the tunnel to take a dynamically calculated route across the network to the tail-end router. Note that this command is not supported for interarea tunnels.

Another option is to use an explicit path. When using explicit paths, the path across the backbone is specified on a hop-by-hop basis.

Example 6-34 shows the configuration of an explicit path.

Example 6-34. Configuration of an Explicit Path for an MPLS TE Tunnel
interface Tunnel10
 tunnel mpls traffic-eng path-option 5 explicit name TEPATH1
!
ip explicit-path name TEPATH1 enable
 next-address 10.20.10.2
 next-address 10.20.40.2
 next-address 10.20.50.2
 next-address 10.20.30.2

In Example 6-34, an explicit path called TEPATH1 is specified on a hop-by-hop basis across the backbone. These hops can be either interface addresses or TE IDs.

When specifying an explicit path for interarea tunnels, be sure to use the loose keyword for each hop that corresponds to an IS-IS level-1/level-2 router or OSPF ABR. In addition, the hop-by-hop path should include the addresses of IS-IS level-1/level-2 routers or OSPF ABRs on the way to the tail-end router.

Configuring the Midpoint and Tail-End Routers

The configuration of the midpoint and the tail-end routers is to a large extent the same as that for the head-end router.

The steps used to configure intermediate and tail-end routers are as follows:

Step 1. | Globally enable MPLS TE.
Step 2. | Configure interface parameters.
Step 3. | Configure the IGP for MPLS TE.

As you can see, the only difference in the configuration is that a tunnel interface is not configured. Refer to the previous section for an explanation of the configuration of these steps. Remember that TE tunnels are unidirectional, so you will need another TE tunnel configured in the opposite direction for bidirectional TE traffic forwarding.

TE Tunnels Between P Routers

The configuration of a TE tunnel to support MPLS VPN traffic between P routers is much the same as that for a tunnel between PE routers but with one key difference on the head-end router: enabling LDP (or TDP) on the tunnel interface.

Because the configuration for intermediate and tail-end routers is the same as that described in the previous section, only the configuration of the head-end router is described here.

Example 6-35 shows the configuration of the MPLS TE tunnel interface.

Example 6-35. Configuration of the MPLS TE Tunnel Interface
interface Tunnel10
 ip unnumbered Loopback0
 no ip directed-broadcast
 mpls ip
 tunnel destination 10.1.1.3
 tunnel mode mpls traffic-eng
 tunnel mpls traffic-eng autoroute announce
 tunnel mpls traffic-eng bandwidth 256
 tunnel mpls traffic-eng path-option 5 dynamic

Highlighted line 1 shows the key difference in the configuration of a MPLS TE tunnel between P routers. The command mpls ip enables LDP (or TDP) on the tunnel interface. This is crucial if VPN traffic is not to be dropped by the tail-end router.

Note that although it is not strictly required, you may also want to configure the mpls ip command on TE tunnels between PE routersit cannot hurt, and you never know when it might become essential because of a network topology change.

Refer to the previous section for an explanation of other commands configured in Example 6-35.

NOTE

For more information regarding MPLS TE, see Traffic Engineering with MPLS by Eric Osborne and Ajay Simha (Cisco Press).


Troubleshooting MPLS VPNs

MPLS VPNs are relatively complex, but by adopting an end-to-end, step-by-step approach, troubleshooting can be relatively fast and efficient. The process of troubleshooting MPLS VPNs can be broken down into two basic elements, troubleshooting route advertisement between the customer sites, and troubleshooting the LSP across the provider backbone.

The flowcharts in Figure 6-29 and 6-30 describe the processes used for troubleshooting route advertisement between the customer sites and troubleshooting the LSPs across the provider backbone. You can use these flowcharts to quickly access the section of the chapter relevant to problems you are experiencing on your network.

Figure 6-29. Flowchart for Troubleshooting Route Advertisement Between the Customer Sites in an MPLS VPN

[View full size image]

Figure 6-30. Flowchart for Troubleshooting the LSPs Across the Provider MPLS Backbone

These two MPLS VPN troubleshooting elements are discussed in the sections that follow. Before diving in, however, it is a good idea to try to locate the issue using the ping and traceroute commands.

The sample topology is used as a reference throughout this section is illustrated in Figure 6-31.

Newer Cisco IOS software commands (such as show mpls ldp bindings) are used in the sections that follow. Table 6-2 at the end of the chapter shows newer commands and their older equivalents (such as show tag-switching tdp bindings). Note, however, that almost without exception, older commands use the tag-switching keyword in place of the mpls keyword, and the tdp keyword in place of the ldp keyword.

Locating the Problem in an MPLS VPN

Two commands that are particularly good for locating problems in the MPLS VPN are ping and traceroute.

The ping command can be used to give you are general idea of the location the problem. The ping command can be used to verify both the LSP and route advertisement across the MPLS VPN backbone.

The traceroute command, on the other hand, can be used for a more detailed examination of the LSP.

Note that if you are using IOS 12.0(27)S or above, you can also take advantage of the ping mpls and trace mpls MPLS Embedded Management feature commands to test LSP connectivity and trace LSPs respectively. These commands use MPLS echo request and reply packets ([labelled] UDP packets on port 3503), and allow you to specify a range of options including datagram size, sweep size range, TTL (maximum number of hops), MPLS echo request timeouts, MPLS echo request intervals, and Experimental bit settings.

Verifying IP Connectivity Across the MPLS VPN

As previously mentioned, the ping command can be useful in locating problems in the MPLS VPN. Two tests that can be very useful are to ping from the PE router to the connected CE router, and from the ingress PE router to the egress PE router.

Can You Ping from the PE to the Connected CE?

The first step in verifying IP connectivity across the MPLS VPN is to check whether you can ping from both the ingress and egress PE routers to their respective connected CE routers. Do not forget to specify the VRF when pinging the CE router.

Example 6-36 shows a ping test from the PE router (Chengdu_PE) to the connected CE router (CE2).

Example 6-36. Pinging the Connected CE Router
Chengdu_PE#ping vrf mjlnet_VPN 172.16.4.2
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.8.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 148/148/152 ms
Chengdu_PE#

If the ping is not successful, there may be a problem with the configuration of the VRF interface, the configuration of the connected CE router, or the PE-CE attachment circuit.

Can You Ping from the Ingress PE to the Egress PE (Globally and in the VRF)?

If you are able to ping from the PE router to the attached CE router, you should now try pinging between the ingress and egress PE routers' BGP update sources (typically loopback interfaces), as shown in Example 6-37.

Example 6-37. Pinging Between the Ingress the Egress Routers' BGP Update Sources
Chengdu_PE#ping
Protocol [ip]:
Target IP address: 10.1.1.4
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 10.1.1.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.1.1.4, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 88/90/92 ms
Chengdu_PE#

If the ping is not successful, there might be a problem with the backbone IGP, or the ingress or egress router's BGP update source is not being advertised into the backbone IGP.

If you are able to ping between the ingress and egress PE routers' BGP update sources, try pinging from the VRF interface on the ingress PE to the VRF interface on the egress PE router.

Example 6-38 shows the output of a ping from the VRF interface on the ingress PE router to the VRF interface on the egress PE router.

Example 6-38. inging the VRF Interface on the Egress PE Router
Chengdu_PE#ping vrf mjlnet_VPN 172.16.8.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.8.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 88/90/92 ms
Chengdu_PE#

If the ping is not successful, it may indicate a problem with the VRF interface on either the ingress or egress PE router; it might indicate a problem with the LSP between the ingress and egress PE routers; or it might indicate a problem with the advertisement of customer VPN routes across the MPLS VPN backbone from the egress PE router to the ingress PE router.

Using traceroute to Verify the LSP

One very useful tool for verifying MPLS LSPs is the traceroute command.

When using traceroute on a PE or P router, the label stack used for packet forwarding is displayed.

Global traceroute can be used to trace an LSP across the MPLS backbone from the ingress to the egress PE router.

In Example 6-39, the LSP is traced from the ingress PE (Chengdu_PE) to the egress PE (HongKong_PE).

Example 6-39. Tracing the LSP from the Ingress PE to the Egress PE Router
Chengdu_PE#traceroute 10.1.1.4
Type escape sequence to abort.
Tracing the route to 10.1.1.4
  1 10.20.10.2 [MPLS: Label 20 Exp 0] 48 msec 48 msec 228 msec
  2 10.20.20.2 [MPLS: Label 17 Exp 0] 32 msec 32 msec 32 msec
  3 10.20.30.2 16 msec 16 msec *
Chengdu_PE#

Highlighted line 1 shows that ingress PE router Chengdu_PE imposes IGP label 20 on the packet and forwards it to Chengdu_P (10.20.10.2).

In highlighted line 2, Chengdu_P swaps label 20 for label 17, and the packet transits the link to HongKong_P (10.20.20.2).

In highlighted line 3, HongKong_P pops the label and forwards the unlabeled packet to egress PE router HongKong_PE (10.20.30.2).

VRF traceroute can used to examine a labeled VPN packet as it crosses the MPLS backbone from the mjlnet_VPN VRF interface of the ingress PE router to mjlnet_VPN site 2, as shown in Example 6-40.

Example 6-40. VRF traceroute from the VRF Interface on the Ingress PE Router to mjlnet_VPN Site 2
Chengdu_PE#traceroute vrf mjlnet_VPN 172.16.8.2
Type escape sequence to abort.
Tracing the route to 172.16.8.2
  1 10.20.10.2 [MPLS: Labels 20/23 Exp 0] 96 msec 96 msec 96 msec
  2 10.20.20.2 [MPLS: Labels 17/23 Exp 0] 80 msec 80 msec 80 msec
  3 172.16.8.1 [MPLS: Label 23 Exp 0] 76 msec 76 msec 76 msec
  4 172.16.8.2 36 msec 136 msec *
Chengdu_PE#

Highlighted line 1 shows that ingress PE router Chengdu_PE imposes IGP label 20, plus VPN label 23, on the packet and forwards it to Chengdu_P (10.20.10.2).

In highlighted line 2, Chengdu_P swaps IGP label 20 for label 17, and the packet transits the link to HongKong_P (10.20.20.2). Note that the VPN label (23) remains unchanged.

In highlighted line 3, HongKong_P pops the IGP label and forwards the packet to egress PE router HongKong_PE (172.16.8.1, its mjlnet_VPN VRF interface address). Again, the VPN label remains unchanged.

Finally, in highlighted line 4, egress PE router HongKong_PE removes the VPN label and forwards the unlabeled packet to the CE router (CE2, 172.16.8.2).

TIP

If the no mpls ip propagate-ttl command is configured on the ingress PE, the MPLS backbone will be represented as 1 hop when tracing from the CE or PE routers. To allow the TTL to be propagated in traceroute on PE routers, the mpls ip propagate-ttl local command can be used.

Troubleshooting the Backbone IGP

Although in-depth troubleshooting of the backbone IGP is beyond the scope of this book, basic issues that will prevent correct operation of both OSPF and IS-IS are briefly discussed here.

Note that the troubleshooting steps for OSPF and IS-IS discussed here are generic in nature; they are equally applicable in a regular IP (non-MPLS) backbone.

Routing Protocol Is Not Enabled on an Interface

Check that OSPF or IS-IS is enabled on the interface using the show ip ospf interface or show clns interface commands.

Routers Are Not on a Common Subnet

Ensure that neighboring routers are configured on the same IP subnet.

Use the show ip interface command to verify interface IP address and mask configuration.

Passive Interface Is Configured

Ensure that an interface that should be transmitting OSPF or IS-IS packets is not configured as a passive interface.

Use the show ip protocols command to verify interface configuration.

Area Mismatch Exists

Ensure that areas are correctly configured on OSPF or IS-IS routers.

Check the OSPF area ID using the show ip ospf interface command.

Check that the IS-IS area is correctly configured using the show clns protocol command.

Network Type Mismatch Exists

Verify that there is not a network type mismatch between the interfaces of neighboring routers.

Use the show ip opsf interface command to verify the OSPF network type. Ensure that neighboring routers are configured with a consistent network type.

Use the show running-config command to check whether there is a network type mismatch between IS-IS routers. If IS-IS is configured on a point-to-point subinterface on one router, but a multipoint interface on the neighboring router, adjacency will fail.

Timer Mismatch Exists

Verify that there is not an OSPF or IS-IS timer mismatch between neighboring routers.

Use the show ip ospf interface command to check that hello and dead intervals are consistent between neighboring OSPF routers.

Use the show running-config command to check the configuration of the hello interval and hello multiplier timers on IS-IS routers.

Authentication Mismatch Exists

Check to see whether there is an authentication mismatch between the routers.

Use the debug ip ospf adj command to troubleshoot OSPF authentication issues.

Use the debug isis adj-packets command to troubleshoot IS-IS authentication issues.

General Misconfiguration Issues

Check the section "Step 6: Configure the MPLS VPN Backbone IGP" on page 449 to ensure that the backbone IGP is correctly configured.

NOTE

For more information on the configuration of OSPF and IS-IS, see Routing TCP/IP, Volume I (CCIE Professional Development) by Jeff Doyle (Cisco Press).

Troubleshooting the LSP

Customer VPN traffic uses an LSP to transit the service provider backbone between the ingress and egress PE routers. When troubleshooting the LSP, you should verify correct operation of CEF, MPLS, and TDP/LDP on all LSRs along the path.

Verifying CEF

If CEF switching is not enabled on all MPLS backbone routers, label switching will not function.

In this section, you will see how to verify that CEF is enabled globally and on an interface.

CEF Is Globally Disabled

To verify that CEF switching is globally enabled on a router, use the show ip cef command, as demonstrated in Example 6-41.

Example 6-41. Verifying CEF Using the show ip cef Command (CEF Is Disabled)
Chengdu_P#show ip cef
%CEF not running
Prefix              Next Hop             Interface
Chengdu_P#

Highlighted line 1 shows that CEF is not enabled on Chengdu_P.

To enable CEF on a router, use the command ip cef [distributed]. The distributed keyword is used only on routers with a distributed architecture such as the 12000 and 7500 series routers.

Example 6-42 shows CEF being enabled on Chengdu_P.

Example 6-42. Globally Enabling CEF
Chengdu_P#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Chengdu_P(config)#ip cef
Chengdu_P(config)#exit
Chengdu_P#

CEF is enabled in the highlighted line in Example 6-42.

In Example 6-43, the show ip cef command is again used to verify CEF.

Example 6-43. CEF Is Enabled
Chengdu_P#show ip cef
Prefix              Next Hop             Interface
0.0.0.0/0           drop                 Null0 (default route handler entry)
0.0.0.0/32          receive
10.1.1.1/32         10.20.10.1           FastEthernet0/0
10.1.1.2/32         receive
10.1.1.3/32         10.20.20.2           Serial1/1
10.1.1.4/32         10.20.20.2           Serial1/1
10.20.10.0/24       attached             FastEthernet0/0
10.20.10.0/32       receive
10.20.10.1/32       10.20.10.1           FastEthernet0/0
10.20.10.2/32       receive
10.20.10.255/32     receive
10.20.20.0/24       attached             Serial1/1
10.20.20.0/32       receive
10.20.20.1/32       receive
10.20.20.2/32       attached             Serial1/1
10.20.20.255/32     receive
10.20.30.0/24       10.20.20.2           Serial1/1
224.0.0.0/4         0.0.0.0
224.0.0.0/24        receive
255.255.255.255/32  receive
Chengdu_P#

Example 6-43 shows a summary of the CEF forwarding information base (FIB).

Highlighted line 1 shows a default route to interface Null0 that reports a drop state. This indicates that packets for this FIB entry will be dropped.

In highlighted line 2, an entry for prefix 10.1.1.1/32 is shown. The entry includes the associated next-hop and (outgoing) interface.

Highlighted line 3 shows an entry for 10.1.1.2/32. This entry indicates a receive state. The receive state is used for host addresses configured on the local router. This entry corresponds to the IP address configured on Chengdu_P's interface loopback 0.

Finally, highlighted line 4 shows an entry for 10.20.10.0/24. This entry indicates an attached state. An attached state indicates that the prefix is directly reachable via the interface indicated (here, Fast Ethernet 0/0).

CEF Is Disabled on an Interface

After verifying that the CEF is globally enabled, also ensure that CEF is enabled on interfaces. CEF is responsible for label imposition and, therefore, must be enabled on the VRF interfaces on PE routers.

Use the show cef interface interface_name command to verify that CEF is enabled on an interface, as shown in Example 6-44.

Example 6-44. show cef interface Command Output
Chengdu_PE#show cef interface serial 4/1
Serial4/1 is up (if_number 6)
  Corresponding hwidb fast_if_number 6
  Corresponding hwidb firstsw->if_number 6
  Internet address is 172.16.4.1/24
  ICMP redirects are never sent
  Per packet load-sharing is disabled
  IP unicast RPF check is disabled
  Inbound access list is not set
  Outbound access list is not set
  IP policy routing is disabled
  BGP based policy accounting is disabled
  Interface is marked as point to point interface
  Hardware idb is Serial4/1
  Fast switching type 7, interface type 67
  IP CEF switching disabled
  IP Feature Fast switching turbo vector
  IP Null turbo vector
  VPN Forwarding table "mjlnet_VPN"
  Input fast flags 0x1000, Output fast flags 0x0
  ifindex 5(5)
  Slot 4 Slot unit 1 Unit 1 VC -1
  Transmit limit accumulator 0x0 (0x0)
  IP MTU 1500
Chengdu_PE#

As you can see in the highlighted line, CEF is disabled on interface serial 4/1.

To enable CEF on the interface, use the ip route-cache cef command, as shown in Example 6-45.

Example 6-45. Configuration of CEF on the Interface
Chengdu_PE#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Chengdu_PE(config)#interface serial 4/1
Chengdu_PE(config-if)#ip route-cache cef
Chengdu_PE(config-if)#end
Chengdu_PE#

The highlighted line indicates that CEF is enabled on interface serial 4/1.

NOTE

Note that some features are not supported by CEF switching. In this case, packets will be punted (sent to) to next fastest switching method.

The fastest switching path is dCEF, followed by CEF, fast switching, and process switching.

12000 series routers do not support fast switching or process switching. Instead of being punted, packets are simply dropped.

Verifying MPLS

If MPLS is disabled either globally or on an interface, label switching will not function.

This section discusses how to verify whether MPLS is either disabled globally or on an interface.

MPLS Is Globally Disabled

If MPLS has been globally enabled, label switching will not function on any interface.

The show mpls interfaces or show mpls forwarding-table commands can be used to verify that MPLS is enabled, as demonstrated in Example 6-46 and Example 6-47.

Example 6-46. Verifying MPLS Using the show mpls interfaces Command
Chengdu_PE#show mpls interfaces
IP MPLS forwarding is globally disabled on this router.
Individual interface configuration is as follows:
Interface              IP            Tunnel   Operational
Chengdu_PE#

The highlighted line clearly shows that MPLS is globally disabled.

Example 6-47. Verifying MPLS Using the show mpls forwarding-table Command
Chengdu_PE#show mpls forwarding-table
Tag switching is not operational.
CEF or tag switching has not been enabled.
No TFIB currently allocated.
Chengdu_PE#

Highlighted line 1 shows that either CEF or MPLS is disabled.

In highlighted line 2, you can see that no LFIB (shown as TFIB here) has been allocated.

MPLS can be enabled using the mpls ip command. In Example 6-48, MPLS is configured on Chengdu_PE.

Example 6-48. Configuration of MPLS on Chengdu_PE
Chengdu_PE#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Chengdu_PE(config)#mpls ip
Chengdu_PE(config)#exit
Chengdu_PE#

In Example 6-48, MPLS is globally enabled using the mpls ip command.

MPLS Is Disabled on an Interface

If MPLS is disabled on an interface, label switching will not function on that interface. Ensure that MPLS is enabled on all core interfaces of all PE and P routers. Note that MPLS should not be enabled on PE routers' VRF interfaces unless carrier's carrier MPLS is being used.

To verify that MPLS is enabled on core interfaces, use the show mpls interfaces command, as shown in Example 6-49.

Example 6-49. Verifying MPLS on an Interface Using the show mpls interfaces Command (MPLS Is Disabled)
Chengdu_PE#show mpls interfaces
Interface              IP            Tunnel   Operational
Chengdu_PE#

As you can see, no interfaces on Chengdu_PE are enabled for MPLS. In this case, MPLS should be enabled on core interface Fast Ethernet 1/0.

The mpls ip command is then used to enable MPLS on interface Fast Ethernet 1/0, as demonstrated in Example 6-50.

Example 6-50. Enabling MPLS on Interface Fast Ethernet 1/0 Using the mpls ip Command
Chengdu_PE#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Chengdu_PE(config)#interface fastethernet 1/0
Chengdu_PE(config-if)#mpls ip
Chengdu_PE(config-if)#end
Chengdu_PE#

In highlighted line 1, MPLS is enabled on interface fastethernet 1/0.

As shown in Example 6-51, the show mpls interfaces command is then used to confirm that MPLS is enabled on the interface.

Example 6-51. Verifying MPLS on an Interface (MPLS Is Enabled)
Chengdu_PE#show mpls interfaces
Interface              IP            Tunnel   Operational
FastEthernet1/0        Yes (ldp)     No       Yes
Chengdu_PE#

As you can see, MPLS is now enabled on interface FastEthernet1/0.

Verifying TDP/LDP

TDP and LDP are used to exchange label bindings, but if they are not functioning correctly, label bindings will not be exchanged, and MPLS will not function.

This section examines how to verify correct operation of TDP or LDP. Note that examples in this section focus on LDP.

LDP Neighbor Discovery and Session Establishment Fails

If LDP neighbor discovery fails, session establishment will fail. Similarly, if LDP session establishment fails, label bindings will not be distributed.

LDP Neighbor Discovery Fails

If LDP discovery fails, session establishment will fail between neighboring LSRs.

Figure 6-32 shows LDP neighbor discovery between Chengdu_PE and Chengdu_P.

Figure 6-32. LDP Neighbor Discovery Between Chengdu_PE and Chengdu_P

Note that Figure 6-32 shows LDP neighbor discovery between directly connected neighbors.

To verify that LDP neighbor discovery has been successful, the show mpls ldp discovery command can be used, as shown in Example 6-52.

Example 6-52. Verifying LDP Neighbor Discovery Using the show mpls ldp discovery Command (Discovery Is Successful)
Chengdu_PE#show mpls ldp discovery
 Local LDP Identifier:
    10.1.1.1:0
    Discovery Sources:
    Interfaces:
        FastEthernet1/0 (ldp): xmit/recv
            LDP Id: 10.1.1.2:0
Chengdu_PE#

Highlighted line 1 shows the local LDP ID (10.1.1.1:0), which is comprised of a 32-bit router ID and a 16-bit label space identifier. In this case, the router ID is 10.1.1.1, and the label space identifier is 0 (which corresponds to a platform-wide label space).

Note that if an interface is using the platform-wide label space, it indicates that labels assigned on this interface are taken from a common pool. If an interface is using an interface label space, it indicates that labels assigned on the interfaces are taken from a pool of labels specific to this interface. Frame-mode interfaces use the platform-wide label space (unless a carrier's carrier architecture is deployed), and cell-mode interfaces use an interface label space.

Highlighted line 2 shows the interface on which LDP hello messages are being transmitted to (xmit) and received from (recv) the peer LSR. Note that the label protocol configured on the interface (in this case, LDP) is also indicated here. In highlighted line 3, the peer LSR's LDP ID is shown (10.1.1.2:0).

LDP neighbor discovery can fail for a number of reasons, including the following:

  • A label protocol mismatch exists.

  • An access list blocks neighbor discovery.

  • A control-VC mismatch exists on LC-ATM interfaces.

These issues are detailed in the following sections.

Label Protocol Mismatch

If there is a mismatch between the label protocol configured on neighboring LSRs, discovery will fail.

To verify neighbor discovery, use the show mpls ldp discovery command.

Example 6-53 shows the output of show mpls ldp discovery when there is a label protocol mismatch between LSRs.

Example 6-53. Label Protocol Mismatch Between Peer LSRs
Chengdu_PE#show mpls ldp discovery
 Local LDP Identifier:
    10.1.1.1:0
    Discovery Sources:
    Interfaces:
        FastEthernet1/0 (ldp): xmit
Chengdu_PE#

As you can see, LDP hello messages are being transmitted (xmit) but not received (recv) on interface FastEthernet1/0. This might indicate that TDP is configured on the peer LSR.

To check the label protocol being used on the peer LSR, use the show mpls interfaces command, as shown in Example 6-54.

Example 6-54. Verifying the Label Protocol on the Peer LSR Using the show mpls interfaces Command
Chengdu_P#show mpls interfaces
Interface              IP            Tunnel   Operational
FastEthernet0/0        Yes (tdp)     No       Yes
Serial1/1              Yes (ldp)     No       Yes
Chengdu_P#

The highlighted line shows that TDP is indeed configured on the peer LSR's connected interface.

As shown in Example 6-55, the label protocol is changed to LDP on the interface using the mpls label protocol command.

Example 6-55. Changing the Label Protocol Using the mpls label protocol Command
Chengdu_P#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Chengdu_P(config)#interface fastethernet0/0
Chengdu_P(config-if)#mpls label protocol ldp
Chengdu_P(config-if)#end
Chengdu_P#

The highlighted line shows that the label protocol is reconfigured to be LDP using the mpls label protocol command. Note that it is possible to configure both LDP and TDP on an interface using the mpls label protocol both command.

Once LDP has been configured on the peer LSR's interface, neighbor discovery is rechecked using the show mpls ldp discovery command, as demonstrated in Example 6-56.

Example 6-56. Verifying Neighbor Discovery (Discovery Is Now Successful)
Chengdu_PE#show mpls ldp discovery
 Local LDP Identifier:
    10.1.1.1:0
    Discovery Sources:
    Interfaces:
        FastEthernet1/0 (ldp): xmit/recv
            LDP Id: 10.1.1.2:0
Chengdu_PE#

In Example 6-56, the highlighted line shows that LDP messages are now being both sent and received on interface FastEthernet1/0. LDP neighbor discovery has been successful.

Access List Blocks LDP Neighbor Discovery

LDP neighbor discovery uses UDP port 646 and the all routers multicast address (224.0.0.2) for directly connected neighbors. If neighbors are not directly connected, then UDP port 646 is also used, but hello messages are unicast.

If an access list blocks UDP port 646 or the all routers multicast address, neighbor discovery will not function.

Note that TDP uses UDP 711 and the local broadcast address (255.255.255.255) for neighbor discovery. If neighbors are not directly connected, then unicast communication is again used.

LDP neighbor discovery can be verified using the show mpls ldp discovery command, as shown in Example 6-57.

Example 6-57. Verifying LDP Neighbor Discovery Using the show mpls ldp discovery Command
Chengdu_PE#show mpls ldp discovery
 Local LDP Identifier:
    10.1.1.1:0
    Discovery Sources:
    Interfaces:
        FastEthernet1/0 (ldp): xmit
Chengdu_PE#

As highlighted line 1 shows, LDP hello messages are being transmitted (xmit), but not received (recv) on interface FastEthernet1/0. This may indicate the presence of an access list.

To check for the presence of an access list on an interface, use the show ip interface command, as demonstrated in Example 6-58.

Note that only the relevant portion of the output is shown.

As you can see, access list 101 is configured inbound on interface FastEthernet 1/0.

Example 6-58. Verifying the Presence of an Access List Using the show ip interface Command
Chengdu_PE#show ip interface fastethernet 1/0
FastEthernet1/0 is up, line protocol is up
  Internet address is 10.20.10.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
  Multicast reserved groups joined: 224.0.0.2
  Outgoing access list is not set
  Inbound  access list is 101
  Proxy ARP is disabled
  Local Proxy ARP is disabled
  Security level is default
  Split horizon is enabled

To examine access list 101, use the show ip access-lists command, as demonstrated in Example 6-59.

Example 6-59. Verifying the Contents of the Access List Using the show ip access-lists Command
Chengdu_PE#show ip access-lists 101

Extended IP access list 101
    permit tcp any any eq bgp
    permit tcp any any eq ftp
    permit tcp any any eq ftp-data
    permit tcp any any eq nntp
    permit tcp any any eq pop3
    permit tcp any any eq smtp
    permit tcp any any eq www
    permit tcp any any eq telnet
    permit udp any any eq snmp
    permit udp any any eq snmptrap
    permit udp any any eq tacacs
    permit udp any any eq tftp
Chengdu_PE#

As you can see, UDP port 646 (LDP) is not permitted by access list 101, and it is, therefore, denied by the implicit deny any statement at the end of the access list.

There are two choices here:

  • Modify the access list

  • Remove the access list

In this case, it is decided that the access list is unnecessary, and so it is removed, as shown in Example 6-60.

Example 6-60. Access List 101 Is Removed
Chengdu_PE#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Chengdu_PE(config)#interface fastethernet 1/0
Chengdu_PE(config-if)#no ip access-group 101 in
Chengdu_PE(config-if)#end
Chengdu_PE#

The highlighted line shows the removal of access list 101 on interface fastethernet 1/0.

After access list 101 is removed, the show mpls ldp discovery command is used to verify that the LDP neighbor discovery is functioning, as demonstrated in Example 6-61.

Example 6-61. LDP Discovery Is Now Successful
Chengdu_PE#show mpls ldp discovery
 Local LDP Identifier:
    10.1.1.1:0
    Discovery Sources:
    Interfaces:
        FastEthernet1/0 (ldp): xmit/recv
            LDP Id: 10.1.1.2:0
Chengdu_PE#

Highlighted line 1 shows that LDP hello messages are now being received (recv) on interface FastEthernet1/0.

Neighbor discovery is now successful.

Control VC Mismatch on LC-ATM Interfaces

On LC-ATM interfaces, if there is a mismatch of the VPI/VCI for the control (plane) VC, LDP neighbor discovery will fail.

Use the show mpls ldp discovery command to view the neighbor discovery status on the LSR, as shown in Example 6-62.

Example 6-62. Verifying LDP Discovery
Chengdu_PE#show mpls ldp discovery
 Local LDP Identifier:
    10.1.1.1:0
    Discovery Sources:
    Interfaces:
        ATM3/0.1 (ldp): xmit
Chengdu_PE#

Highlighted line 1 shows that LDP packets are being transmitted (xmit) but not received (recv) on interface ATM 3/0.1.

The next step is to check the control VC on the interface using the show mpls interfaces detail command, as shown in Example 6-63.

Example 6-63. Checking the Control VC Using the show mpls interfaces detail Command on the Local LSR
Chengdu_PE#show mpls interfaces atm 3/0.1 detail
Interface ATM3/0.1:
        IP labeling enabled (ldp)
        LSP Tunnel labeling not enabled
        BGP labeling not enabled
        MPLS operational
        Optimum Switching Vectors:
          IP to MPLS Turbo Vector
          MPLS Turbo Vector
        Fast Switching Vectors:
          IP to MPLS Fast Switching Vector
          MPLS Turbo Vector
        MTU = 4470
        ATM labels: Label VPI = 1, Control VC = 0/32
Chengdu_PE#

Highlighted line 1 shows that the control VC used on this LC-ATM interface is 0/32 (VPI/VCI). This is the default.

The control VC is then verified on the peer LSR, as shown in Example 6-64.

Example 6-64. Checking the Control VC on the Peer LSR
HongKong_PE#show mpls interfaces atm 4/0.1 detail
Interface ATM4/0.1:
        IP labeling enabled (ldp)
        LSP Tunnel labeling not enabled
        BGP labeling not enabled
        MPLS not operational
        Optimum Switching Vectors:
          IP to MPLS Turbo Vector
          MPLS Turbo Vector
        Fast Switching Vectors:
          IP to MPLS Fast Switching Vector
          MPLS Turbo Vector
        MTU = 4470
        ATM labels: Label VPI = 1, Control VC = 0/40
HongKong_PE#

As you can see, the control VC is 0/40 on HongKong_PE. There is a control VC mismatch between LDP peers.

To resolve this issue, the control VC is modified on HongKong_PE, as shown in Example 6-65.

Example 6-65. Reconfiguration of the Control VC on HongKong_PE
HongKong_PE#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
HongKong_PE(config)#interface ATM4/0.1 mpls
HongKong_PE(config-subif)#mpls atm control-vc 0 32
HongKong_PE(config-subif)#end
HongKong_PE#

The control VC is reset to the default 0/32 values, as the highlighted line indicates.

Once the control VC VPI/VCI is modified, the show mpls ldp discovery command is again used to examine the LDP neighbor discovery state, as shown in Example 6-66.

Example 6-66. LDP Discovery Is Now Successful
Chengdu_PE#show mpls ldp discovery
 Local LDP Identifier:
    10.1.1.1:0
    Discovery Sources:
    Interfaces:
        ATM3/0.1 (ldp): xmit/recv
            LDP Id: 10.1.1.4:1; IP addr: 10.20.60.2
Chengdu_PE#

In highlighted line 1, LDP hello packets are being both transmitted (xmit) and received (recv) on interface ATM 3/0.1. LDP discovery is now successful.

In highlighted line 2, the LDP ID (10.1.1.4:1) of HongKong_PE is shown, together with its IP address on the connected interface (10.20.60.2).

LDP Session Establishment Fails

If LDP session establishment fails, label bindings will not be advertised to neighboring LSRs.

Figure 6-33 illustrates an LDP session between Chengdu_PE and Chengdu_P.

Figure 6-33. An LDP Session Between Chengdu_PE and Chengdu_P

To verify LDP session establishment, use the show mpls ldp neighbor command.

Example 6-67 shows the output of the show mpls ldp neighbor command when session establishment is successful.

Example 6-67. LDP Session Establishment Is Successful
Chengdu_PE#show mpls ldp neighbor
    Peer LDP Ident: 10.1.1.2:0; Local LDP Ident 10.1.1.1:0
        TCP connection: 10.1.1.2.11206 - 10.1.1.1.646
        State: Oper; Msgs sent/rcvd: 76/75; Downstream
        Up time: 00:56:44
        LDP discovery sources:
          FastEthernet1/0, Src IP addr: 10.20.10.2
        Addresses bound to peer LDP Ident:
          10.1.1.2        10.20.20.1      10.20.10.2
        Chengdu_PE#

Highlighted line 1 shows the peer LDP ID (10.1.1.2:0), as well as the local LDP ID (10.1.1.1:0).

In highlighted line 2, the TCP ports open on peer and local LSRs for the LDP session (11206 and 646, respectively) are shown.

In highlighted line 3, the session state is shown as operational (established). The number of messages sent and received (76 and 75), together with the method of label distribution (unsolicited downstream), are also shown.

The LDP session uptime is shown in highlighted line 4 (56 minutes and 44 seconds). In highlighted line 5, the discovery sources (local LSR interface and peer's connected IP address) are shown. Finally, the LDP peer's interface IP addresses are shown.

Numerous issues can prevent LDP session establishment, including the following:

  • The neighbor's LDP ID is unreachable.

  • An access list blocks LDP session establishment.

  • An LDP authentication mismatch exists.

  • VPI ranges do not overlap between LC-ATM interfaces.

The sections that follow discuss these issues in more detail.

Neighbor's LDP ID Is Unreachable

An LDP session is established over a TCP connection between LSRs. On Cisco LSRs, the endpoint of the TCP connection corresponds to the LDP ID address by default, unless peer LSRs are connected via LC-ATM interfaces. If the LDP ID of the peer is unreachable, session establishment will fail.

Use the show mpls ldp discovery command to troubleshoot this issue, as shown in Example 6-68.

Example 6-68. No Route to the LDP ID of the Neighboring LSR Exists
Chengdu_PE#show mpls ldp discovery
 Local LDP Identifier:
    10.1.1.1:0
    Discovery Sources:
    Interfaces:
        FastEthernet1/0 (ldp): xmit/recv
            LDP Id: 10.1.1.2:0; no route
Chengdu_PE#

The highlighted line shows that there is no route to the LDP ID of the neighboring LSR. As previously mentioned, LDP sessions are established between the LDP ID addresses of the neighboring LSRs. The absence of a route to the neighbor's LDP ID can be confirmed using the show ip route command, as demonstrated in Example 6-69.

Example 6-69. No Route to the LDP ID of the Peer LSR Exists in the Routing Table
Chengdu_PE#show ip route 10.1.1.2
% Subnet not in table
Chengdu_PE#

As you can see, there is no route to 10.1.1.2 (the peer's LDP ID).

When the configuration of the backbone IGP (in this case, IS-IS) is examined on the neighboring LSR, the problem is revealed.

Example 6-70 shows the output of the show running-config command. Note that only the relevant portions of the output are shown.

Example 6-70. Interface Loopback0 Is Not Advertised by IS-IS
Chengdu_P#show running-config
Building configuration...
!
tag-switching tdp router-id Loopback0 force
!
!
interface Loopback0
 ip address 10.1.1.2 255.255.255.255
 no ip directed-broadcast
!
!
router isis
 net 49.0001.0000.0000.0002.00
 is-type level-2-only
 metric-style wide
!

In highlighted line 1, the MPLS LDP ID (shown as the TDP ID) is configured as the IP address on interface Loopback0.

The configuration of interface Loopback 0 begins in highlighted line 2. The IP address is 10.1.1.2/32. This is the LDP ID.

Notice that the command ip router isis is not configured on the interface. This command is one way to advertise the interface address in IS-IS.

The configuration of IS-IS begins in highlighted line 3. Notice the absence of the passive-interface Loopback0 command. The passive-interface command alone can also be used to advertise the loopback interface although some versions of IOS may require you to configure the ip router isis on the loopback interface in addition to the passive interface command.

Interface Loopback0 is not being advertised in IS-IS. IS-IS must, therefore, be configured to advertise interface Loopback0, as shown in Example 6-71.

Example 6-71. Configuring IS-IS to Advertise Interface Loopback0
Chengdu_P#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Chengdu_P(config)#router isis
Chengdu_P(config-router)#passive-interface Loopback0
Chengdu_P(config-router)#end
Chengdu_P#

The highlighted line shows where IS-IS is configured to advertise interface loopback 0.

The LDP discovery state is now rechecked using the show mpls ldp discovery command, as shown in Example 6-72.

Example 6-72. LDP Discovery Is Now Successful
Chengdu_PE#show mpls ldp discovery
 Local LDP Identifier:
    10.1.1.1:0
    Discovery Sources:
    Interfaces:
        FastEthernet1/0 (ldp): xmit/recv
            LDP Id: 10.1.1.2:0
Chengdu_PE#

The highlighted line shows the peer LDP ID, and crucially, the absence of the "no route" message (as shown in Example 6-68) indicates that there is now a route to the neighbor's LDP ID.

The LDP session state can then be verified using the show mpls ldp neighbor command, as shown in Example 6-73.

Example 6-73. LDP Session Is Established
Chengdu_PE#show mpls ldp neighbor
    Peer LDP Ident: 10.1.1.2:0; Local LDP Ident 10.1.1.1:0
        TCP connection: 10.1.1.2.11007 - 10.1.1.1.646
        State: Oper; Msgs sent/rcvd: 12/11; Downstream
        Up time: 00:00:43
        LDP discovery sources:
          FastEthernet1/0, Src IP addr: 10.20.10.2
        Addresses bound to peer LDP Ident:
          10.20.10.2      10.1.1.2        10.20.20.1
Chengdu_PE#

Highlighted line 1 shows the peer (10.1.1.2:0) and local LDP IDs (10.1.1.1:0).

In highlighted line 2, the session state is shown as operational (established). The number of messages sent and received (12 and 11), together with the label distribution method (unsolicited downstream) are also shown.

The LDP session uptime is shown in highlighted line 3 (43 seconds). The session has now been established.

It is worth noting that reachability issues between LDP ID addresses in a carrier's carrier configuration between the PE and CE routers can easily be resolved by using the mpls ldp discovery transport-address interface command. If this command is configured on connected PE and CE interfaces, the LDP session will be established between the connected interface addresses rather than LDP ID addresses.

Access List Blocks LDP Session Establishment

LDP sessions are established between two peers over a unicast connection on TCP port 646. The unicast connection is between the LDP ID addresses of the adjacent LSRs. If an access list blocks TCP port 646 or the LDP ID addresses, then session establishment will fail.

When designing access lists, consider that the passive peer (the peer with the lower LDP ID) opens TCP port 646, and the active peer (the peer with the higher LDP ID) opens an ephemeral (short-lived) port for LDP session establishment.

Note that TDP uses TCP port 711 and a unicast connection for session establishment.

Use the show ip interface command to check for an access list on an interface, as demonstrated in Example 6-74.

Example 6-74. Verifying the Presence of an Access List
Chengdu_PE#show ip interface fastethernet 1/0
FastEthernet1/0 is up, line protocol is up
  Internet address is 10.20.10.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
  Multicast reserved groups joined: 224.0.0.2
  Outgoing access list is not set
  Inbound  access list is 101
  Proxy ARP is disabled
  Local Proxy ARP is disabled
  Security level is default
  Split horizon is enabled

The highlighted line shows that access list 101 is configured inbound on interface FastEthernet 1/0.

Use the show ip access-lists command to examine access list 101, as shown in Example 6-75.

Example 6-75. Verifying the Contents of the Access List
Chengdu_PE#show ip access-lists
Extended IP access list 101
    permit icmp any any
    permit gre any any
    permit tcp any any eq bgp
    permit tcp any any eq domain
    permit tcp any any eq ftp
    permit tcp any any eq ftp-data
    permit tcp any any eq telnet
    permit tcp any any eq www
    permit udp any any eq 646
    permit udp any any eq ntp
    permit udp any any eq snmp
    permit udp any any eq snmptrap
    permit udp any any eq tacacs
    permit udp any any eq tftp

Chengdu_PE#

As you can see, access list 101 does not permit TCP port 646 and, therefore, it is blocked by the implicit deny any statement at the end of the access list.

The two choices here are:

  • Modify the access list

  • Remove the access list

In this case, it is decided that the access list is not needed, and it is removed, as shown in Example 6-76.

Example 6-76. Removing the Access List
Chengdu_PE#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Chengdu_PE(config)#interface fastethernet 1/0
Chengdu_PE(config-if)#no ip access-group 101 in
Chengdu_PE(config-if)#end
Chengdu_PE#

The highlighted line shows the removal of access list 101 on interface fastethernet 1/0.

Once the access list is removed, session establishment is verified using the show mpls ldp neighbor command, as demonstrated in Example 6-77.

Example 6-77. LDP Session Establishment Succeeds
Chengdu_PE#show mpls ldp neighbor
    Peer LDP Ident: 10.1.1.2:0; Local LDP Ident 10.1.1.1:0
        TCP connection: 10.1.1.2.11075 - 10.1.1.1.646
        State: Oper; Msgs sent/rcvd: 15/14; Downstream
        Up time: 00:02:49
        LDP discovery sources:
          FastEthernet1/0, Src IP addr: 10.20.10.2
        Addresses bound to peer LDP Ident:
          10.1.1.2        10.20.20.1      10.20.10.2
Chengdu_PE#

Highlighted line 1 shows the peer (10.1.1.2:0) and local LDP IDs (10.1.1.1:0).

Highlighted line 2 shows that the session state is now operational (established). The number of messages sent and received (15 and 14), together with the label distribution method (unsolicited downstream), is also shown.

The LDP session uptime is shown in highlighted line 3 (2 minutes 49 seconds).

LDP Authentication Mismatch

LDP can be configured to use the TCP MD5 authentication for session connections. If LDP authentication is configured on one peer, but not the other, or if passwords are mismatched, session establishment will fail.

LDP Authentication Is Configured on One Peer But Not the Other

If LDP authentication is configured on one LDP peer, but not the other, session establishment will fail, and an error message will be logged.

Example 6-78 shows the error message logged if the LDP session messages do not contain an MD5 digest.

Example 6-78. LDP Authentication Is Not Configured on the Peer LSR
*Jan 20 08:34:16.775 UTC: %TCP-6-BADAUTH: No MD5 digest from 10.1.1.2(11023) to
  10.1.1.1(646)

In Example 6-78, an LDP session message has been received from LDP peer 10.1.1.2 without the expected MD5 digest.

To resolve this issue, either peer 10.1.1.2 can be configured for LDP authentication or LDP authentication can be removed on peer 10.1.1.1. In this case, LDP authentication is configured on peer 10.1.1.2, as shown in Example 6-79.

Example 6-79. Configuration of LDP Authentication on Peer 10.1.1.2
Chengdu_P#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Chengdu_P(config)#mpls ldp neighbor 10.1.1.1 password cisco
Chengdu_P(config)#exit
Chengdu_P#

Once LDP authentication has been configured, the LDP session is established. This is verified using the show mpls ldp neighbor command, as shown in Example 6-80.

Example 6-80. LDP Session Establishment Is Successful
Chengdu_PE#show mpls ldp neighbor
    Peer LDP Ident: 10.1.1.2:0; Local LDP Ident 10.1.1.1:0
        TCP connection: 10.1.1.2.11115 - 10.1.1.1.646
        State: Oper; Msgs sent/rcvd: 12/11; Downstream
        Up time: 00:00:21
        LDP discovery sources:
          FastEthernet1/0, Src IP addr: 10.20.10.2
        Addresses bound to peer LDP Ident:
          10.1.1.2        10.20.20.1      10.20.10.2
Chengdu_PE#

In highlighted line 1, the peer (10.1.1.2:0) and local LDP IDs (10.1.1.1:0) are shown.

Highlighted line 2 shows that the session state is operational (established). This line also shows the number of messages sent and received (12 and 11), together with the label distribution method (unsolicited downstream).

Finally, highlighted line 3 shows the LDP session uptime (21 seconds).

LDP Authentication Password Mismatch

If there is a LDP authentication password mismatch between peers, session establishment will fail, and an error message will be logged.

Example 6-81 shows the error message logged if there is an LDP password mismatch.

Example 6-81. LDP Passwords Are Mismatched
*Jan 20 09:42:54.091 UTC: %TCP-6-BADAUTH: Invalid MD5 digest from 10.1.1.2
  (11034) to 10.1.1.1(646)

As the highlighted portion shows, an invalid MD5 digest is received from LDP peer 10.1.1.2.

To ensure that the LDP password is consistent, reconfigure the password on both peers (10.1.1.1 and 10.1.1.2) as shown in Example 6-82.

Example 6-82. Reconfiguration of the LDP Password
! On Chengdu_PE (10.1.1.1):
Chengdu_PE#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Chengdu_PE(config)#mpls ldp neighbor 10.1.1.2 password cisco
Chengdu_PE(config)#exit
Chengdu_PE#
________________________________________________________________
! On Chengdu_P (10.1.1.2):
Chengdu_P#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Chengdu_P(config)#mpls ldp neighbor 10.1.1.1 password cisco
Chengdu_P(config)#exit
Chengdu_P#

Once the LDP password has been reconfigured, use the show mpls neighbor command to verify LDP session establishment as demonstrated in Example 6-83.

Example 6-83. LDP Session Establishment Is Successful After Reconfiguration of the LDP Password
Chengdu_PE#show mpls ldp neighbor
    Peer LDP Ident: 10.1.1.2:0; Local LDP Ident 10.1.1.1:0
        TCP connection: 10.1.1.2.11118 - 10.1.1.1.646
        State: Oper; Msgs sent/rcvd: 12/11; Downstream
        Up time: 00:00:10
        LDP discovery sources:
          FastEthernet1/0, Src IP addr: 10.20.10.2
        Addresses bound to peer LDP Ident:
          10.1.1.2        10.20.20.1      10.20.10.2
Chengdu_PE#

The peer (10.1.1.2:0) and local LDP IDs (10.1.1.1:0) are shown in highlighted line 1.

In highlighted line 2, you can see that the session state is now operational (established). The number of messages sent and received (12 and 11), together with the label distribution method (unsolicited downstream), are also shown.

Highlighted line 3 shows the LDP session uptime (10 seconds).

VPI Ranges Do Not Overlap Between LC-ATM Interfaces

During LDP session initialization, session parameterssuch as LDP protocol version, label distribution method, and (on LC-ATM interfaces) VPI/VCI ranges used for label switchingare negotiated between peers.

If there is no overlap between VPI ranges configured on LDP peers, an error message is logged and session establishment fails, as shown in Example 6-84.

Example 6-84. VPI Ranges Do Not Overlap Between LC-ATM Interfaces
*Feb  8 14:09:06.038 UTC: %TDP-3-TAGATM_BAD_RANGE: Interface ATM3/0.1, Bad
  VPI/VCI range. Can't start a TDP session

In Example 6-84, the error message indicates that the VPI/VCI negotiation has failed on interface atm3/0.1, and the LSRs are unable to start a LDP (shown as TDP) session.

You can also use the debug mpls atm-ldp api command to troubleshoot this issue, as shown in Example 6-85.

Example 6-85. debug atm-ldp api Command Output
Chengdu_PE#debug mpls atm-ldp api
LC-ATM API debugging is on
Chengdu_PE#
*Feb  8 14:27:07.226 UTC: TAGATM_API: Disjoint VPI local[1-1], peer[2-3]
Chengdu_PE#

The highlighted portion reveals that VPI range 11 is configured locally, and VPI range 23 is configured on the peer LSR. Note that the default VPI range is 11.

To correct this problem, the VPI range is reconfigured on the peer LSR. This is shown in Example 6-86.

Example 6-86. Reconfiguration of the VPI Range on the Peer LSR
HongKong_PE#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
HongKong_PE(config)#interface atm4/0.1 mpls
HongKong_PE(config-subif)#no mpls atm vpi 2-3
HongKong_PE(config-subif)#end
HongKong_PE#

The highlighted line shows that the VPI range 23 is removed. This resets the VPI to the default range of 11.

After the VPI range on the peer LSR (Hongkong_PE) is reconfigured, LDP session establishment is successful.

To verify successful session establishment, the show mpls ldp neighbor command is used on HongKong_PE, as shown in Example 6-87.

Example 6-87. LDP Session Establishment Succeeds After Reconfiguration of the VPI Range on HongKong_PE
Chengdu_PE#show mpls ldp neighbor
    Peer LDP Ident: 10.1.1.4:1; Local LDP Ident 10.1.1.1:1
        TCP connection: 10.20.60.2.11036 - 10.20.60.1.646
        State: Oper; Msgs sent/rcvd: 14/14; Downstream on demand
        Up time: 00:06:03
        LDP discovery sources:
          ATM3/0.1, Src IP addr: 10.20.60.2
Chengdu_PE#

The peer (10.1.1.4:1) and local LDP IDs (10.1.1.1:1) are shown in highlighted line 1.

Note that the label space identifier used here is 1. Remember that LC-ATM interfaces do not use the platform-wide label space, which is indicated by the label space identifier 0.

Highlighted line 2 shows that the session state is now operational (established). The number of messages sent and received (14 and 14) and the label distribution method (downstream-on-demand) are also shown.

Highlighted line 3 shows the LDP session uptime (6 minutes 3 seconds).

Label Bindings Are Not Advertised Correctly

If LDP session establishment is successful, but label bindings are not advertised correctly, label switching will not function correctly.

Figure 6-34 shows the advertisement of label bindings between Chengdu_PE and Chengdu_P.

Figure 6-34. Advertisement of Label Bindings Between Chengdu_PE and Chengdu_P

To verify that labels are being advertised correctly, use the show mpls ldp bindings command, as shown in Example 6-88. The resulting output shows the contents of the Label Information Base (LIB).

Example 6-88. Verifying the Contents of the LIB
Chengdu_PE#show mpls ldp bindings
  tib entry: 10.1.1.1/32, rev 2
        local binding:  tag: imp-null
        remote binding: tsr: 10.1.1.2:0, tag: 19
  tib entry: 10.1.1.2/32, rev 8
        local binding:  tag: 17
        remote binding: tsr: 10.1.1.2:0, tag: imp-null
  tib entry: 10.1.1.3/32, rev 14
        local binding:  tag: 20
        remote binding: tsr: 10.1.1.2:0, tag: 18
  tib entry: 10.1.1.4/32, rev 18
        local binding:  tag: 22
        remote binding: tsr: 10.1.1.2:0, tag: 20
  tib entry: 10.20.10.0/24, rev 4
        local binding:  tag: imp-null
        remote binding: tsr: 10.1.1.2:0, tag: imp-null
  tib entry: 10.20.20.0/24, rev 10
        local binding:  tag: 18
        remote binding: tsr: 10.1.1.2:0, tag: imp-null
  tib entry: 10.20.20.1/32, rev 16
        local binding:  tag: 21
  tib entry: 10.20.20.2/32, rev 6
        local binding:  tag: 16
        remote binding: tsr: 10.1.1.2:0, tag: 16
  tib entry: 10.20.30.0/24, rev 12
        local binding:  tag: 19
        remote binding: tsr: 10.1.1.2:0, tag: 17
Chengdu_PE#

Example 6-88 shows that label bindings are being received for all prefixes from the peer LSR.

For example, highlighted line 1 shows the LIB (shown here as TIB) entry for prefix 10.1.1.4/32. In highlighted line 2, the locally assigned label for this prefix is shown (22). In highlighted line 3, the label assigned by the peer LSR (10.1.1.2:0) for this prefix is shown (20).

The label bindings that correspond to the best routes are also contained within the LFIB. To examine the contents of the LFIB, use the show mpls forwarding-table command, as shown in Example 6-89.

Example 6-89. Verifying the Contents of the LFIB
Chengdu_PE#show mpls forwarding-table
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
tag    tag or VC   or Tunnel Id      switched   interface
16     16          10.20.20.2/32     0          Fa1/0      10.20.10.2
17     Pop tag     10.1.1.2/32       0          Fa1/0      10.20.10.2
18     Pop tag     10.20.20.0/24     0          Fa1/0      10.20.10.2
19     17          10.20.30.0/24     0          Fa1/0      10.20.10.2
20     18          10.1.1.3/32       0          Fa1/0      10.20.10.2
21     Untagged    10.20.20.1/32     0          Fa1/0      10.20.10.2
22     20          10.1.1.4/32       0          Fa1/0      10.20.10.2
23     Untagged    172.16.1.0/24[V]  0          Se4/1      point2point
24     Untagged    172.16.2.0/24[V]  0          Se4/1      point2point
25     Untagged    172.16.3.0/24[V]  0          Se4/1      point2point
26     Aggregate   172.16.4.0/24[V]  2080
27     Untagged    172.16.4.2/32[V]  0          Se4/1      point2point
Chengdu_PE#

The LFIB contains the locally assigned and outgoing (advertised by the peer LSR) labels for each prefix. Additionally, the number of bytes label switched, the outgoing interface, and the next-hop are shown.

As an example, the locally assigned and outgoing labels for prefix 10.1.1.4/32 are 22 and 20 respectively (see highlighted line 1). The number of bytes switched in 0, the outgoing interface is Fast Ethernet 1/0, and the next-hop is 10.20.10.2.

If label bindings are not advertised correctly, it may be because of a number of reasons, including:

  • The no mpls ldp advertise-labels command is configured on the peer LSR.

  • Conditional label advertisement blocks label bindings.

  • CEF disables local label assignment.

The sections that follow discuss these issues.

no mpls ldp advertise-labels Command Is Configured on the Peer LSR

If no label bindings are being received from a peer LSR, this may indicate that the peer LSR is configured not to advertise its locally assigned label bindings.

To verify that label bindings are being received from the peer LSR, use the show mpls ldp bindings command, as shown in Example 6-90.

Example 6-90. No Label Bindings Are Received from the Peer LSR
Chengdu_PE#show mpls ldp bindings
  tib entry: 10.1.1.1/32, rev 2
        local binding:  tag: imp-null
  tib entry: 10.1.1.2/32, rev 8
        local binding:  tag: 17
  tib entry: 10.1.1.3/32, rev 14
        local binding:  tag: 20
  tib entry: 10.1.1.4/32, rev 18
        local binding:  tag: 22
  tib entry: 10.20.10.0/24, rev 4
        local binding:  tag: imp-null
  tib entry: 10.20.20.0/24, rev 10
        local binding:  tag: 18
  tib entry: 10.20.20.1/32, rev 16
        local binding:  tag: 21
  tib entry: 10.20.20.2/32, rev 6
        local binding:  tag: 16
  tib entry: 10.20.30.0/24, rev 12
        local binding:  tag: 19
Chengdu_PE#

In Example 6-90, no label bindings are being received from LSR 10.1.1.2:0.

The highlighted line shows the LIB entry for prefix 10.1.1.4/32. As you can see, there is no label binding from LSR 10.1.1.2:0; there is only a local binding.

The configuration of the peer LSR is checked using the show running-config command, as demonstrated in Example 6-91. Note that only the relevant portion of the output is shown.

Example 6-91. Checking the Configuration of the Peer LSR Using the show running-config Command
Chengdu_P#show running-config
Building configuration...
!
ip multicast-routing
mpls label protocol ldp
no tag-switching advertise-tags
!

As you can see, the no mpls ldp advertise-labels (shown as no tag-switching advertise-tags) command is configured on the peer LSR. This command disables advertisement of label bindings by the LSR.

To enable that the LSR advertises labels, use the mpls ldp advertise-labels command, as shown in Example 6-92.

Example 6-92. Label Advertisement Is Enabled on Chengdu_P
Chengdu_P#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Chengdu_P(config)#mpls ldp advertise-labels
Chengdu_P(config)#exit
Chengdu_P#

Once label advertisement on the peer LSR is enabled, the show mpls ldp bindings command is used to verify that the bindings are being received, as shown in Example 6-93.

Example 6-93. Label Bindings Are Now Received from the Peer LSR
Chengdu_PE#show mpls ldp bindings
  tib entry: 10.1.1.1/32, rev 2
        local binding:  tag: imp-null
        remote binding: tsr: 10.1.1.2:0, tag: 19
  tib entry: 10.1.1.2/32, rev 8
        local binding:  tag: 17
        remote binding: tsr: 10.1.1.2:0, tag: imp-null
  tib entry: 10.1.1.3/32, rev 14
        local binding:  tag: 20
        remote binding: tsr: 10.1.1.2:0, tag: 18
  tib entry: 10.1.1.4/32, rev 18
        local binding:  tag: 22
        remote binding: tsr: 10.1.1.2:0, tag: 20
  tib entry: 10.20.10.0/24, rev 4
        local binding:  tag: imp-null
        remote binding: tsr: 10.1.1.2:0, tag: imp-null
  tib entry: 10.20.20.0/24, rev 10
        local binding:  tag: 18
        remote binding: tsr: 10.1.1.2:0, tag: imp-null
  tib entry: 10.20.20.1/32, rev 16
        local binding:  tag: 21
  tib entry: 10.20.20.2/32, rev 6
        local binding:  tag: 16
        remote binding: tsr: 10.1.1.2:0, tag: 16
  tib entry: 10.20.30.0/24, rev 12
        local binding:  tag: 19
        remote binding: tsr: 10.1.1.2:0, tag: 17
Chengdu_PE#

As you can see, label bindings are now being received from peer LSR 10.1.1.2:0. In highlighted line 1, the LIB entry for prefix 10.1.1.4/32 is shown. Highlighted line 2 shows the label binding for this prefix advertised by LSR 10.1.1.2:0.

Conditional Label Advertisement Blocks Label Bindings

If some, but not all, expected label bindings are being received from a peer LSR, this might indicate the presence of conditional label advertisement on the peer LSR.

You can use the show mpls ldp bindings command to examine label bindings advertised from the peer LSRs, as shown in Example 6-94.

Example 6-94. Verifying Label Bindings Advertised by Peer LSRs
Chengdu_PE#show mpls ldp bindings
  tib entry: 10.1.1.1/32, rev 4
        local binding:  tag: imp-null
        remote binding: tsr: 10.1.1.2:0, tag: 19
  tib entry: 10.1.1.2/32, rev 8
        local binding:  tag: 17
        remote binding: tsr: 10.1.1.2:0, tag: imp-null
  tib entry: 10.1.1.3/32, rev 14
        local binding:  tag: 20
        remote binding: tsr: 10.1.1.2:0, tag: 18
  tib entry: 10.1.1.4/32, rev 18
        local binding:  tag: 22
  tib entry: 10.20.10.0/24, rev 2
        local binding:  tag: imp-null
        remote binding: tsr: 10.1.1.2:0, tag: imp-null
  tib entry: 10.20.20.0/24, rev 10
        local binding:  tag: 18
        remote binding: tsr: 10.1.1.2:0, tag: imp-null
  tib entry: 10.20.20.1/32, rev 16
        local binding:  tag: 21
  tib entry: 10.20.20.2/32, rev 6
        local binding:  tag: 16
        remote binding: tsr: 10.1.1.2:0, tag: 16
  tib entry: 10.20.30.0/24, rev 12
        local binding:  tag: 19
        remote binding: tsr: 10.1.1.2:0, tag: 17
Chengdu_PE#

If you look closely at the output in Example 6-94, you will notice that there are both local and remote bindings for all prefixes, with the exception of 10.1.1.4/32 (highlighted). There is no remote binding for this prefix, which indicates that the peer LSR is not advertising one.

To check for the presence of conditional label advertisement on the peer LSR, use the show running-config command, as demonstrated in Example 6-95. Note that only the relevant portion of the configuration is shown.

Example 6-95. Checking for the Presence of Conditional Label Advertisement
Chengdu_P#show running-config
Building configuration...
!
ip multicast-routing
mpls label protocol ldp
no tag-switching advertise-tags
tag-switching advertise-tags for 1
!
!
access-list 1 permit 10.1.1.2
access-list 1 permit 10.1.1.3
access-list 1 permit 10.1.1.1
access-list 1 permit 10.20.10.0 0.0.0.255
access-list 1 permit 10.20.20.0 0.0.0.255
access-list 1 permit 10.20.30.0 0.0.0.255
!

In highlighted lines 1 and 2, the peer LSR (Chengdu_P) is configured to advertise only labels for those prefixes specified in access list 1.

Highlighted lines 3 to 8 show access list 1. As you can see, prefix 10.1.1.4/32 is not permitted, which prevents the advertisement of a binding for this prefix.

To allow the advertisement of a binding for prefix 10.1.1.4/32, you can either modify or remove access list 1. In this scenario, conditional label advertisement is unnecessary, so it is removed, as shown in Example 6-96.

Example 6-96. Conditional Label Advertisement Is Removed on Chengdu_P
Chengdu_P#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Chengdu_P(config)#mpls ldp advertise-labels
Chengdu_P(config)#no mpls ldp advertise-labels for 1
Chengdu_P(config)#exit
Chengdu_P#

In highlighted lines 1 and 2, conditional label advertisement is removed on Chengdu_P.

Having removed conditional label advertisement on Chengdu_P, use the show mpls ldp bindings command to confirm proper label bindings advertisement, as demonstrated in Example 6-97.

Example 6-97. Confirming Advertisement of a Label Binding for Prefix 10.1.1.4/32
Chengdu_PE#show mpls ldp bindings 10.1.1.4 32
  tib entry: 10.1.1.4/32, rev 18
        local binding:  tag: 22
        remote binding: tsr: 10.1.1.2:0, tag: 20
Chengdu_PE#

As you can see, a label binding for prefix 10.1.1.4/32 has now been received from the Chengdu_P.

Label bindings can also be filtered as they are received on an LSR using the mpls ldp neighbor [vrf vpn-name] neighbor-address labels accept acl command. Labels corresponding to prefixes permitted in a standard access list are accepted from the specified neighbor. Verify the presence of this command using the show mpls ldp neighbor neighbor-address detail command.

CEF Disables Local Label Assignment

If labels are not being bound to prefixes locally, this might indicate that CEF is disabled on the LSR.

You can use the show mpls ldp bindings command to verify local label bindings as shown in Example 6-98.

Example 6-98. Local Label Assignment Is Disabled
Chengdu_P#show mpls ldp bindings
  tib entry: 10.1.1.1/32, rev 5
        remote binding: tsr: 10.1.1.1:0, tag: imp-null
        remote binding: tsr: 10.1.1.3:0, tag: 19
  tib entry: 10.1.1.2/32, rev 2
        remote binding: tsr: 10.1.1.1:0, tag: 17
        remote binding: tsr: 10.1.1.3:0, tag: 17
  tib entry: 10.1.1.3/32, rev 7
        remote binding: tsr: 10.1.1.1:0, tag: 20
        remote binding: tsr: 10.1.1.3:0, tag: imp-null
  tib entry: 10.1.1.4/32, rev 8
        remote binding: tsr: 10.1.1.1:0, tag: 22
        remote binding: tsr: 10.1.1.3:0, tag: 20
  tib entry: 10.20.10.0/24, rev 1
        remote binding: tsr: 10.1.1.1:0, tag: imp-null
        remote binding: tsr: 10.1.1.3:0, tag: 18
  tib entry: 10.20.20.0/24, rev 4
        remote binding: tsr: 10.1.1.1:0, tag: 18
        remote binding: tsr: 10.1.1.3:0, tag: imp-null
  tib entry: 10.20.20.1/32, rev 9
        remote binding: tsr: 10.1.1.1:0, tag: 21
        remote binding: tsr: 10.1.1.3:0, tag: 16
  tib entry: 10.20.20.2/32, rev 3
        remote binding: tsr: 10.1.1.1:0, tag: 16
  tib entry: 10.20.30.0/24, rev 6
        remote binding: tsr: 10.1.1.1:0, tag: 19
        remote binding: tsr: 10.1.1.3:0, tag: imp-null
Chengdu_P#

As you can see, the LIB contains remote label bindings but no local label bindings.

As shown in Example 6-99, you can use the show ip cef summary command to check whether CEF is running.

Example 6-99. Verifying CEF Operation
Chengdu_P#show ip cef summary
IP CEF without switching (Table Version 1), flags=0x0
  4294967293 routes, 0 reresolve, 0 unresolved (0 old, 0 new), peak 0
  0 leaves, 0 nodes, 0 bytes, 4 inserts, 4 invalidations
  0 load sharing elements, 0 bytes, 0 references
  universal per-destination load sharing algorithm, id 88235174
  2(0) CEF resets, 0 revisions of existing leaves
  Resolution Timer: Exponential (currently 1s, peak 0s)
  0 in-place/0 aborted modifications
  refcounts:  0 leaf, 0 node
  Table epoch: 0
%CEF not running
Chengdu_P#

The highlighted line shows that CEF is disabled. To enable CEF, use the ip cef command, as shown in Example 6-100.

Example 6-100. Enabling CEF on Chengdu_P
Chengdu_P#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Chengdu_P(config)#ip cef
Chengdu_P(config)#exit
Chengdu_P#

Once CEF has been enabled, the LIB is again examined using the show mpls ldp bindings command, as shown in Example 6-101.

Example 6-101. Local Label Assignment Is Now Enabled
Chengdu_P#show mpls ldp bindings
  tib entry: 10.1.1.1/32, rev 15
        Local binding:  tag: 19
        remote binding: tsr: 10.1.1.1:0, tag: imp-null
        remote binding: tsr: 10.1.1.3:0, tag: 19
  tib entry: 10.1.1.2/32, rev 12
        Local binding:  tag: imp-null
        remote binding: tsr: 10.1.1.1:0, tag: 17
        remote binding: tsr: 10.1.1.3:0, tag: 17
  tib entry: 10.1.1.3/32, rev 13
        Local binding:  tag: 18
        remote binding: tsr: 10.1.1.1:0, tag: 20
        remote binding: tsr: 10.1.1.3:0, tag: imp-null
  tib entry: 10.1.1.4/32, rev 16
        Local binding:  tag: 20
        remote binding: tsr: 10.1.1.1:0, tag: 22
        remote binding: tsr: 10.1.1.3:0, tag: 20
  tib entry: 10.20.10.0/24, rev 17
        Local binding:  tag: imp-null
        remote binding: tsr: 10.1.1.1:0, tag: imp-null
        remote binding: tsr: 10.1.1.3:0, tag: 18
  tib entry: 10.20.20.0/24, rev 14
        Local binding:  tag: imp-null
        remote binding: tsr: 10.1.1.1:0, tag: 18
        remote binding: tsr: 10.1.1.3:0, tag: imp-null
  tib entry: 10.20.20.1/32, rev 9
        remote binding: tsr: 10.1.1.1:0, tag: 21
        remote binding: tsr: 10.1.1.3:0, tag: 16
  tib entry: 10.20.20.2/32, rev 11
        Local binding:  tag: 17
        remote binding: tsr: 10.1.1.1:0, tag: 16
  tib entry: 10.20.30.0/24, rev 10
        Local binding:  tag: 16
        remote binding: tsr: 10.1.1.1:0, tag: 19
        remote binding: tsr: 10.1.1.3:0, tag: imp-null
Chengdu_P#

As you can see, the LIB now contains local label bindings.

Troubleshooting Route Advertisement Between VPN Sites

When troubleshooting route advertisement across the MPLS VPN backbone, you need to consider a number of issues. Before examining end-to-end troubleshooting of route advertisement, it is worthwhile to briefly review the issues involved.

Figure 6-35 illustrates route advertisement across the MPLS VPN backbone.

Figure 6-35. Route Advertisement Across the MPLS VPN Backbone

[View full size image]

In Figure 6-35, route advertisement from CE2 to CE1 is as follows:

1. | CE2 advertises customer site 2 routes to HongKong_PE using the PE-CE routing protocol (assuming that static routes are not being used).
2. | HongKong_PE redistributes customer routes into MP-BGP.
3. | HongKong_PE advertises the routes across the MPLS VPN backbone to Chengdu_PE, which imports the routes into its VRF.
4. | Chengdu_PE redistributes the MP-BGP routes into the PE-CE routing protocol.
5. | Chengdu_PE advertises the routes to CE1.

Note that Chengdu_PE is the ingress PE-router and HongKong_PE is the egress PE router, with respect to traffic flow (which is in the opposite direction to route advertisement).

Note also that CE1 advertises customer site 1 across the MPLS VPN backbone to CE2 in the same manner as that used for route advertisement from CE2 to CE1.

The next sections discuss troubleshooting itself, beginning with route advertisement from the CE router to connected PE router.

Troubleshooting Route Advertisement Between the PE and CE Routers

The first step in ensuring correct route advertisement is to make sure that the PE router is receiving routes from its connected CE routers.

Figure 6-36 illustrates route advertisement from CE2 to HongKong_PE.

Figure 6-36. Route Advertisement from CE2 to HongKong_PE

[View full size image]

In Figure 6-36, CE2 advertises routes 172.16.5.0/24, 172.16.6.0/24, and 172.16.7.0/24 to the egress PE, HongKong_PE.

To check that the attached customer site routes are being received on the attached PE router, you should use the show ip route vrf vrf_name command.

Example 6-102 shows the output of the show ip route vrf vrf_name on the PE router.

Example 6-102. Verifying That Customer Routes Are Being Received on the Attached PE Router
HongKong_PE#show ip route vrf mjlnet_VPN
Routing Table: mjlnet_VPN
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i  IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
Gateway of last resort is not set
     172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks
B       172.16.4.0/24 [200/0] via 10.1.1.1, 03:04:28
B       172.16.4.2/32 [200/0] via 10.1.1.1, 03:04:28
B       172.16.1.0/24 [200/1] via 10.1.1.1, 03:04:28
B       172.16.2.0/24 [200/1] via 10.1.1.1, 03:04:28
B       172.16.3.0/24 [200/1] via 10.1.1.1, 03:04:28
HongKong_PE#

As you can see, site 2 routes (172.16.5.0/24, 172.16.6.0/24, and 172.16.7.0/24) are not in the VRF mjlnet_VPN routing table.

Note that the routes shown in Example 6-102 are from mjlnet_VPN site 1.

The most likely causes for this are the following:

  • The customer interface is misconfigured or down on either the PE or CE router.

  • There is a problem with PE-CE routing (routing protocol / statics).

The sections that follow examine these issues in more detail.

Customer Interface Is Misconfigured or Down

One common cause of PE to CE routing issues is misconfiguration of the customer interface.

Use the show ip vrf interfaces command to verify the configuration of the customer interface, as shown in Example 6-103.

Example 6-103. Verifying the Configuration of the Customer Interface Using the show ip vrf interfaces Command
HongKong_PE#show ip vrf interfaces
Interface              IP-Address      VRF                              Protocol
Serial2/1              172.16.8.1      cisco_VPN                            up
Serial2/2              192.168.8.1     cisco_VPN                            up
HongKong_PE#

In Example 6-103, you will notice that interface serial 2/1 is assigned to VRF cisco_VPN. In fact, it should be assigned to VRF mjlnet_VPN.

To re-assign interface serial 2/1 to VRF mjlnet_VPN, use the ip vrf forwarding vrf_name command as shown in Example 6-104.

Example 6-104. Reassignment of Interface serial 2/1 to VRF mjlnet_VPN
HongKong_PE#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
HongKong_PE(config)#interface serial 2/1
HongKong_PE(config-if)#ip vrf forwarding mjlnet_VPN
% Interface Serial2/1 IP address 172.16.8.1 removed due to enabling VRF mjlnet_VPN
HongKong_PE(config-if)#ip address 172.16.8.1 255.255.255.0
HongKong_PE(config-if)#end
HongKong_PE#

In highlighted line 1, interface Serial2/1 is reassigned to VRF mjlnet_VPN. Notice that the IP address must be reconfigured when the interface is reassigned to VRF mjlnet_VPN (highlighted lines 2 and 3).

After the interface is reassigned, the interface to VRF assignment is rechecked in Example 6-105.

Example 6-105. Interface Serial2/1 Is Now Correctly Assigned to VRF mjlnet_VPN
HongKong_PE#show ip vrf interfaces
Interface              IP-Address      VRF                              Protocol
Serial2/1              172.16.8.1      mjlnet_VPN                            up
Serial2/2              192.168.8.1     cisco_VPN                            up
HongKong_PE#

As you can see, interface Serial2/1 is now correctly assigned to VRF mjlnet_VPN.

When verifying the configuration of the customer interface, ensure that an IP address is configured on the interface and that the interface is in an up state. Also be sure to check that the CE router interface connected to the PE router is in an up state, and is correctly configured.

Troubleshooting the PE-CE Routing Protocol and Static Routes

If the customer interface is correctly configured and in an up state, the next step is to troubleshoot the PE-CE routing protocol or static routes.

Static Routes Are Misconfigured

If static routes are misconfigured, connectivity between the PE and the customer site will fail.

To check that static routes are correctly configured, use the show ip route vrf vrf_name static command as shown in Example 6-106.

Example 6-106. Checking That Static Routes Are Correctly Configured Using the show ip route vrf vrf_name static Command
HongKong_PE#show ip route vrf mjlnet_VPN static
HongKong_PE#

As you can see, there are no static routes in the VRF routing table.

The next step is to check the configuration of the static routes. This can be done using the show running-configuration | begin ip route command, as shown in Example 6-107.

Example 6-107. Checking the Configuration of Static Routes
Chengdu_PE#show running-config | begin ip route
!
ip route 172.16.5.0 255.255.255.0 Serial2/1
ip route 172.16.6.0 255.255.255.0 Serial2/1
ip route 172.16.7.0 255.255.255.0 Serial2/1
!

The output in Example 6-107 reveals the problem. The static routes are configured as global static routes and not as VRF static routes.

As shown in Example 6-108, the static routes are then reconfigured as VRF static routes.

Example 6-108. Reconfiguration of the Static Routes
HongKong_PE#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
HongKong_PE(config)#no ip route 172.16.5.0 255.255.255.0 Serial2/1
HongKong_PE(config)#no ip route 172.16.6.0 255.255.255.0 Serial2/1
HongKong_PE(config)#no ip route 172.16.7.0 255.255.255.0 Serial2/1
HongKong_PE(config)#ip route vrf mjlnet_VPN 172.16.5.0 255.255.255.0 serial 2/1
HongKong_PE(config)#ip route vrf mjlnet_VPN 172.16.6.0 255.255.255.0 serial 2/1
HongKong_PE(config)#ip route vrf mjlnet_VPN 172.16.7.0 255.255.255.0 serial 2/1
HongKong_PE(config)#exit
HongKong_PE#

The incorrectly configured static routes are removed in highlighted lines 1 to 3. In highlighted lines 4 to 6, the VRF static routes are configured.

The show ip route vrf vrf_name static command is then used to verify that the static routes are in the VRF routing table, as shown in Example 6-109.

Example 6-109. Verifying the VRF Static Routes
HongKong_PE#show ip route vrf mjlnet_VPN static
     172.16.0.0/16 is variably subnetted, 10 subnets, 2 masks
S       172.16.5.0/24 is directly connected, Serial2/1
S       172.16.6.0/24 is directly connected, Serial2/1
S       172.16.7.0/24 is directly connected, Serial2/1
HongKong_PE#

Highlighted lines 1 to 3 show that the VRF static routes are now correctly configured.

When troubleshooting VRF static routes, also ensure that the VRF name, network prefix, mask, outgoing interface, and next-hop (if used) are correctly specified.

NOTE

Do not forget to verify the configuration of any relevant static routes on the CE router.

PE-CE Routing Protocols

If PE-CE routing is not functioning correctly, this may be because of one or more of the following issues:

  • The routing protocol is configured globally.

  • The routing protocol is not enabled on the VRF interface.

  • Routing protocol timers are mismatched.

  • The routers are not on a common subnet.

  • A passive interface is configured.

  • An access list blocks the routing protocol.

  • Distribute lists, prefix lists, or route maps block route updates.

  • An authentication mismatch exists.

  • The PE-CE routing protocol is otherwise misconfigured.

Although in-depth PE-CE IGP troubleshooting is beyond the scope of this book, this section briefly discusses these issues.

These issues are discussed from the perspective of the PE router, but make sure that you also verify the configuration of the PE-CE routing protocol on the CE router.

Routing Protocol Is Configured Globally

Make sure that the PE-CE routing protocol is not configured globally on the PE router. If the PE-CE routing protocol is RIPv2, EIGRP, or EBGP, it should be configured under the IPv4 address family. If the PE-CE routing protocol is OSPF, a separate process should be configured for the VRF.

Use the show ip protocols vrf vrf_name command to troubleshoot this issue.

Routing Protocol Is Not Enabled on the VRF Interface

Verify that the PE-CE routing protocol is enabled on the VRF interface.

Use the show ip protocols vrf vrf_name command to check this.

Routing Protocol Timers Are Mismatched

Ensure that routing protocol timers match between the PE and the CE routers. For example, if the PE-CE routing protocol is OSPF, make sure the hello and dead intervals are the same.

Use the show ip protocols vrf vrf_name command to troubleshoot this issue.

Routers Are Not on a Common Subnet

Check that the VRF interface and the CE router interface that is connected to the PE router are correctly addressed (including the address mask).

Use the show ip vrf interfaces command to verify this on the PE router.

Passive Interface Is Configured

Make sure that the VRF interface is not configured as a passive interface. If the VRF interface is configured as a passive interface, routing updates will not be sent on the interface.

The show ip protocols vrf vrf_name command can be used to verify this.

Access List Blocks the Routing Protocol

Verify that an access list is not blocking the PE-CE routing protocol on the VRF interface.

Check for access lists using the show ip interface command.

Distribute Lists, Prefix Lists, or Route Maps Block Route Updates

Check that distribute lists, prefix lists, or route maps are not blocking route updates.

Use the show ip protocols vrf vrf_name command to verify this.

Authentication Mismatch Exists

Check to see whether there is an authentication mismatch between the PE and the CE routers.

The command to verify this issue depends on the PE-CE routing protocol.

  • For OSPF, use the debug ip ospf adj command.

  • For RIPv2, use the debug ip rip command.

  • For EIGRP, use the debug eigrp packets verbose command.

  • For EBGP, an error message is logged. Use the show logging command to see the message.

PE-CE Routing Protocol Is Otherwise Misconfigured

Simple misconfiguration is the most common cause of PE-CE routing issues.

Check the section, "Step 11: Configure PE-CE Routing Protocols / Static Routes," on page 454. Proper configuration, as well as a number of protocol-specific issues, is discussed in this section.

Other Useful PE-CE Routing Protocol Troubleshooting Commands

Regular routing protocol show and debug commands can be used to troubleshoot PE-CE routing protocols. However, there are some VRF-specific commands for RIPv2 and EIGRP that may be useful:

  • RIP The show ip rip database vrf vrf_name command can be used to examine the RIP database.

  • EIGRP VRF-specific commands for use with EIGRP are as follows:

    - The show ip eigrp vrf vrf_name interfaces command can be used to verify EIGRP VRF interfaces.

    - The show ip eigrp vrf vrf_name neighbors command can be used to verify EIGRP neighbors on VRF interfaces.

    - Use the show ip eigrp vrf vrf_name topology to display the VRF EIGRP topology table.

    - The show ip eigrp vrf vrf_name traffic command can be used to view EIGRP traffic statistics for the VRF.

Redistribution of Customer Routes into MP-BGP Is Not Successful on the Egress PE Router

One you have verified PE-CE routing, the next step in troubleshooting route exchange across the MPLS VPN backbone is to ensure that the redistribution of customer routes into MP-BGP is functioning correctly.

Figure 6-37 illustrates redistribution of customer routes into MP-BGP.

Figure 6-37. Redistribution of Customer Routes into MP-BGP

[View full size image]

To verify that customer routes are being redistributed, use the show ip bgp vpnv4 vrf vrf_name command, as shown in Example 6-110.

Example 6-110. Customer Routes Are Not Redistributed in MP-BGP
HongKong_PE#show ip bgp vpnv4 vrf mjlnet_VPN
BGP table version is 26, local router ID is 10.1.1.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 64512:100 (default for vrf mjlnet_VPN)
*>i172.16.1.0/24    10.1.1.1                 1    100      0 ?
*>i172.16.2.0/24    10.1.1.1                 1    100      0 ?
*>i172.16.3.0/24    10.1.1.1                 1    100      0 ?
*>i172.16.4.0/24    10.1.1.1                 0    100      0 ?
*>i172.16.4.2/32    10.1.1.1                 0    100      0 ?
HongKong_PE#

You will notice that the output of the show ip bgp vpnv4 vrf vrf_name command does not show any of the routes from customer site 2 (172.16.5.0/24, 172.16.6.0/24, and 172.16.7.0/24).

If routes are not being redistributed (as in Example 6-114), the first thing to check is the configuration of redistribution of PE-CE routing protocols or static routes using the show running-config command, as shown in Example 6-111.

Note that only the relevant portion of the output is shown.

Example 6-111. Checking the Configuration of Redistribution on the PE Router
HongKong_PE#show running-config | begin router bgp
router bgp 64512
 no synchronization
 bgp log-neighbor-changes
 redistribute rip
 neighbor 10.1.1.1 remote-as 64512
 neighbor 10.1.1.1 update-source Loopback0
 neighbor 10.1.1.6 remote-as 64512
 neighbor 10.1.1.6 update-source Loopback0
 no auto-summary
 !
address-family ipv4 vrf mjlnet_VPN
 no auto-summary
 no synchronization
 exit-address-family
!

Highlighted line 1 shows the problemRIP is being redistributed into global BGP. RIP redistribution into MP-BGP should be configured under the IPv4 VRF mjlnet_VPN address family (see highlighted line 2).

Redistribution of the PE-CE routing protocol into MP-BGP is then reconfigured, as shown in Example 6-112.

Example 6-112. Reconfiguration of Redistribution from the PE-CE Routing Protocol into MP-BGP
HongKong_PE#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
HongKong_PE(config)#router bgp 64512
HongKong_PE(config-router)#no redistribute rip
HongKong_PE(config-router)#address-family ipv4 vrf mjlnet_VPN
HongKong_PE(config-router-af)#redistribute rip
HongKong_PE(config-router-af)#end
HongKong_PE#

In highlighted line 1, redistribution of the PE-CE routing protocol into global BGP is disabled.

Redistribution of the PE-CE routing protocol into MP-BGP is then configured in highlighted line 2.

To ensure that redistribution of your PE-CE routing protocol is configured correctly, check the section "Step 12: Redistribute Customer Routes into MP-BGP" on page 458.

Once the configuration has been corrected, customer routes are redistributed into MP-BGP. This is verified using the show ip bgp vpnv4 vrf vrf_name command, as shown in Example 6-113.

Example 6-113. Customer Routes Are Now Successfully Redistributed into MP-BGP
HongKong_PE#show ip bgp vpnv4 vrf mjlnet_VPN
BGP table version is 21, local router ID is 10.1.1.4
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 64512:100 (default for vrf mjlnet_VPN)
*>i172.16.1.0/24    10.1.1.1                 1    100      0 ?
*>i172.16.2.0/24    10.1.1.1                 1    100      0 ?
*>i172.16.3.0/24    10.1.1.1                 1    100      0 ?
*>i172.16.4.0/24    10.1.1.1                 0    100      0 ?
*>i172.16.4.2/32    10.1.1.1                 0    100      0 ?
*> 172.16.5.0/24    172.16.8.2               1         32768 ?
*> 172.16.6.0/24    172.16.8.2               1         32768 ?
*> 172.16.7.0/24    172.16.8.2               1         32768 ?
*> 172.16.8.0/24    0.0.0.0                  0         32768 ?
*> 172.16.8.2/32    0.0.0.0                  0         32768 ?
HongKong_PE#

The highlighted lines show that customer site 2 routes are now being successfully redistributed into MP-BGP.

MP-BGP Routes from the Egress PE Router Are Not Installed in the BGP Table of the Ingress PE Router

If customer routes are correctly redistributed into MP-BGP, the next step is to check that the routes advertised by the egress PE are correctly advertised and installed in the BGP table of the ingress PE router.

Figure 6-38 illustrates the advertisement of MP-BGP routes to the ingress PE router.

Figure 6-38. Advertisement of MP-BGP Routes to the Ingress PE Router

[View full size image]

To examine the BGP routing table of the ingress PE router, use the show ip bgp vpnv4 vrf vrf_name command, as shown in Example 6-114.

Example 6-114. Verifying Installation of MP-BGP Routes in the BGP Table of the Ingress PE Router
Chengdu_PE#show ip bgp vpnv4 vrf mjlnet_VPN
BGP table version is 1, local router ID is 10.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 64512:100 (default for vrf mjlnet_VPN)
*> 172.16.1.0/24    172.16.4.2               1         32768 ?
*> 172.16.2.0/24    172.16.4.2               1         32768 ?
*> 172.16.3.0/24    172.16.4.2               1         32768 ?
*> 172.16.4.0/24    0.0.0.0                  0         32768 ?
*> 172.16.4.2/32    0.0.0.0                  0         32768 ?
Chengdu_PE#

As you can see, mjlnet_VPN site 2 routes (172.16.5.0/24, 172.16.6.0/24, and 172.16.7.0/24) are not in the BGP routing table on the ingress PE router (Chengdu_PE).

The show ip route vrf vrf_name command can also be used to verify that mjlnet_VPN site 2 routes are not being installed into the VRF routing table, as demonstrated in Example 6-115.

Example 6-115. Verifying the VRF Routing Table
Chengdu_PE#show ip route vrf mjlnet_VPN
Routing Table: mjlnet_VPN
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i  IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
Gateway of last resort is not set
     172.16.0.0/16 is variably subnetted, 5 subnets, 2 masks
C       172.16.4.0/24 is directly connected, Serial4/1
C       172.16.4.2/32 is directly connected, Serial4/1
R       172.16.1.0/24 [120/1] via 172.16.4.2, 00:00:26, Serial4/1
R       172.16.2.0/24 [120/1] via 172.16.4.2, 00:00:26, Serial4/1
R       172.16.3.0/24 [120/1] via 172.16.4.2, 00:00:26, Serial4/1
Chengdu_PE#

Again, no evidence of mjlnet_VPN site 2 routes. There are several possible causes for this, including the following:

  • The VPN-IPv4 address family is misconfigured on the ingress or egress PE router.

  • Export and import route targets are mismatched on the egress and ingress PE routers.

  • An export map is misconfigured.

  • Routes are blocked by an import map.

These issues are discussed in the sections that follow.

VPN-IPv4 Address Family Is Misconfigured on the Ingress or Egress PE Router

If customer routes are not being advertised to the ingress PE router, the first thing to check is that the VPN-IPv4 (VPNv4) address family is configured correctly on the egress and ingress PE routers.

To verify MP-BGP configuration, use the show ip bgp neighbors [neighbor-address] command, as shown in Example 6-116.

Note that only the relevant portion of the output is shown.

Example 6-116. Verifying MP-BGP Configuration Using the show ip bgp neighbors Command
HongKong_PE#show ip bgp neighbors 10.1.1.1
BGP neighbor is 10.1.1.1,  remote AS 64512, internal link
  BGP version 4, remote router ID 10.1.1.1
  BGP state = Established, up for 00:14:47
  Last read 00:00:47, hold time is 180, keepalive interval is 60 seconds
  Neighbor capabilities:
    Route refresh: advertised and received(new)
    Address family IPv4 Unicast: advertised and received
    Address family VPNv4 Unicast: advertised
  Received 427 messages, 0 notifications, 0 in queue
  Sent 427 messages, 0 notifications, 0 in queue
  Default minimum time between advertisement runs is 5 seconds

Highlighted line 1 shows that the BGP session between the egress and ingress PE routers is Established.

In highlighted line 2, you will notice that the VPNv4 address family is advertised. This indicates that the local router (HongKong_PE) supports the VPNv4 (VPN-IPv4) address family. Unfortunately, there is no indication that the ingress PE router (Chengdu_PE) supports the VPNv4 address family (this would be indicated by the received keyword).

This is not good. If the neighbor does not support the VPNv4 address family, there is no chance of VPN routes being exchanged between BGP peers.

The configuration of the ingress PE router is examined using the show running-config command, as demonstrated in Example 6-117.

Example 6-117. Checking the Configuration of the Ingress PE Router
Chengdu_PE#show running-config | begin router bgp
router bgp 64512
 no synchronization
 bgp log-neighbor-changes
 neighbor 10.1.1.4 remote-as 64512
 neighbor 10.1.1.4 update-source Loopback0
 neighbor 10.1.1.6 remote-as 64512
 neighbor 10.1.1.6 update-source Loopback0
 no auto-summary
 !
 address-family ipv4 vrf cisco_VPN
 Redistribute ospf 200 match internal external 1 external 2
 no auto-summary
 no synchronization
 exit-address-family
 !
 address-family ipv4 vrf mjlnet_VPN
 Redistribute rip
 no auto-summary
 no synchronization
 exit-address-family
!

As you can see, the VPNv4 address family is not configured.

The VPNv4 address family is then configured on the ingress PE router, as shown in Example 6-118.

Example 6-118. Configuration of the VPNv4 Address Family on the Ingress PE Router
Chengdu_PE#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Chengdu_PE(config)#router bgp 64512
Chengdu_PE(config-router)#address-family vpnv4
Chengdu_PE(config-router-af)#neighbor 10.1.1.4 activate
Chengdu_PE(config-router-af)#end
Chengdu_PE#

In Example 6-118, the VPNv4 address family is configured (highlighted line 1), and neighbor 10.1.1.4 (HongKong_PE) is activated (highlighted line 2).

Once the VPNv4 address family has been configured on the ingress PE, the BGP VPNv4 table is again checked for mjlnet_VPN site 2 routes.

Example 6-119 shows the output of the show ip bgp vpnv4 vrf vrf_name command after configuration of the VPNv4 address family.

Example 6-119. mjlnet_VPN Site 2 Routes Are Now Installed into the BGP VPNv4 Table
Chengdu_PE#show ip bgp vpnv4 vrf mjlnet_VPN
BGP table version is 36, local router ID is 10.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 64512:100 (default for vrf mjlnet_VPN)
*> 172.16.1.0/24    172.16.4.2               1         32768 ?
*> 172.16.2.0/24    172.16.4.2               1         32768 ?
*> 172.16.3.0/24    172.16.4.2               1         32768 ?
*> 172.16.4.0/24    0.0.0.0                  0         32768 ?
*> 172.16.4.2/32    0.0.0.0                  0         32768 ?
*>i172.16.5.0/24    10.1.1.4                 1    100      0 ?
*>i172.16.6.0/24    10.1.1.4                 1    100      0 ?
*>i172.16.7.0/24    10.1.1.4                 1    100      0 ?
*>i172.16.8.0/24    10.1.1.4                 0    100      0 ?
*>i172.16.8.2/32    10.1.1.4                 0    100      0 ?
Chengdu_PE#

Highlighted lines 1 to 3 show that mjlnet_VPN site 2 routes are now installed in the BGP VPNv4 table.

Note that if route reflectors are being used, you should ensure that the route reflectors are configured within the VPNv4 address family to reflect MP-BGP (VPNv4) routes to the PE routers.

Export and Import Route Targets Are Mismatched on the Egress and Ingress PE Routers

If export and import route targets are mismatched on the egress and ingress PE routers, MP-BGP routes will not be installed into the ingress PE router's BGP VPNv4 table.

Examine the export route target on the egress PE router using the show ip vrf detail vrf_name command as shown in Example 6-120.

Example 6-120. Verifying the Export Route Target on the Egress PE Router
HongKong_PE#show ip vrf detail mjlnet_VPN
VRF mjlnet_VPN; default RD 64512:100; default VPNID <not set>
  Interfaces:
    Serial2/1
  Connected addresses are not in global routing table
  Export VPN route-target communities
    RT:64512:100
  Import VPN route-target communities
    RT:64512:100
  No import route-map
  No export route-map
HongKong_PE#

Highlighted line 1 shows that the export route target on the egress PE router is 64512:100.

Having ascertained the export route target on the egress PE router, your next step is to verify the import route target on the ingress PE, as demonstrated in Example 6-121.

Example 6-121. Verifying the Import Route Target on the Ingress PE Router
Chengdu_PE#show ip vrf detail mjlnet_VPN
VRF mjlnet_VPN; default RD 64512:100; default VPNID <not set>
  Interfaces:
    Serial4/1
  Connected addresses are not in global routing table
  Export VPN route-target communities
    RT:64512:100
  Import VPN route-target communities
    RT:64512:400
  No import route-map
  No export route-map
Chengdu_PE#

As you can see, the import route target configured on the ingress PE router is 64512:400 (highlighted line 1). Clearly, there is a mismatch between the export route target configured on the egress PE router (64512:100) and the import route target configured on the ingress PE router (64512:400).

You can resolve this problem one of two ways:

  • Reconfigure the export route target on the egress PE router.

  • Reconfigure the import route target on the ingress PE router.

In this case, the import route target is reconfigured on the ingress PE router, as shown in Example 6-122.

Example 6-122. Reconfiguration of the Import Route Target on the Ingress PE Router
Chengdu_PE#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Chengdu_PE(config)#ip vrf mjlnet_VPN
Chengdu_PE(config-vrf)#no route-target import 64512:400
Chengdu_PE(config-vrf)#route-target import 64512:100
Chengdu_PE(config-vrf)#end
Chengdu_PE#

Once the import route target has been reconfigured on the ingress PE router, the BGP VPNv4 table is rechecked using the show ip bgp vpnv4 vrf vrf_name command, as shown in Example 6-123.

Example 6-123. mjlnet_VPN Routes Are Now Installed into the BGP VPNv4 Table on the Ingress PE Router
Chengdu_PE#show ip bgp vpnv4 vrf mjlnet_VPN
BGP table version is 36, local router ID is 10.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 64512:100 (default for vrf mjlnet_VPN)
*> 172.16.1.0/24    172.16.4.2               1         32768 ?
*> 172.16.2.0/24    172.16.4.2               1         32768 ?
*> 172.16.3.0/24    172.16.4.2               1         32768 ?
*> 172.16.4.0/24    0.0.0.0                  0         32768 ?
*> 172.16.4.2/32    0.0.0.0                  0         32768 ?
*>i172.16.5.0/24    10.1.1.4                 1    100      0 ?
*>i172.16.6.0/24    10.1.1.4                 1    100      0 ?
*>i172.16.7.0/24    10.1.1.4                 1    100      0 ?
*>i172.16.8.0/24    10.1.1.4                 0    100      0 ?
*>i172.16.8.2/32    10.1.1.4                 0    100      0 ?
Chengdu_PE#

The highlighted lines show that mjlnet_VPN site 2 routes have now been imported into the BGP VPNv4 table.

Export Map Is Misconfigured

If an export map is misconfigured on the egress PE router, VPNv4 routes advertised from the egress PE router may not be installed in the BGP VPNv4 table on the ingress PE router.

The first step is to examine the import route targets configured on the ingress PE router using the show ip vrf detail vrf_name command, as demonstrated in Example 6-124.

Example 6-124. Verifying Import Route Targets on the Ingress PE Router Using the show ip vrf detail Command
Chengdu_PE#show ip vrf detail mjlnet_VPN
VRF mjlnet_VPN; default RD 64512:100; default VPNID <not set>
VRF Table ID = 1
  Interfaces:
    Serial4/1
  Connected addresses are not in global routing table
  Export VPN route-target communities
    RT:64512:100
  Import VPN route-target communities
    RT:64512:100
  No import route-map
  No export route-map
Chengdu_PE#

As you can see, the only import route target configured for VRF mjlnet_VPN is 64512:100.

Next you should verify MP-BGP routes on the egress PE router using the show ip bgp vpnv4 vrf vrf_name prefix command, as shown in Example 6-125.

Example 6-125. Verifying Route Targets on the Egress PE Router Using the show ip bgp vpnv4 vrf Command
HongKong_PE#show ip bgp vpnv4 vrf mjlnet_VPN 172.16.7.0/24
BGP routing table entry for 64512:100:172.16.7.0/24, version 18
Paths: (1 available, best #1, table mjlnet_VPN)
Flag: 0x820
  Advertised to update-groups:
     1
  Local
    172.16.8.2 (via mjlnet_VPN) from 0.0.0.0 (10.1.1.4)
      Origin incomplete, metric 1, localpref 100, weight 32768, valid, sourced,
  Best
      Extended Community: RT:64512:300
HongKong_PE#

In Example 6-125, the MP-BGP (site 2) route 172.16.7.0/24 is verified on egress router HongKong_PE. As you can see, only route target 64512:300 is attached to this route.

Clearly there is a mismatch between the import route target configured on Chengdu_PE (64512:100) and the export route target attached to routes by egress router HongKong_PE (64512:300).

Having checked the route target attached to MP-BGP routes, you should now verify route target configuration on the egress PE router using the show ip vrf detail vrf_name command, as demonstrated in Example 6-126.

Example 6-126. Verifying Route Target Configuration on the Egress PE Router Using the show ip vrf detail Command
HongKong_PE#show ip vrf detail mjlnet_VPN
VRF mjlnet_VPN; default RD 64512:100; default VPNID <not set>
  Interfaces:
    Serial2/1
  Connected addresses are not in global routing table
  Export VPN route-target communities
    RT:64512:100
  Import VPN route-target communities
    RT:64512:100
  No import route-map
  Export route-map: AddExportRT
HongKong_PE#

In highlighted line 1, you can see that the export route target is configured as 64512:100. This is the same as the import route target configured on the ingress PE router. If the export route target configured on the egress PE router is 64512:100 (the same as the import route target configured on the ingress PE router), why is route target 64512:300 and not route target 64512:100 attached to MP-BGP routes?

If you look a little further down the output, you will see that export map AddExportRT is configured on the egress PE router (highlighted line 2).

The export route map can be examined using the show route-map route_map_name command.

Example 6-127 shows the output of the show route-map route_map_name command on the egress PE router.

Example 6-127. Examining the Export Map
HongKong_PE#show route-map AddExportRT
route-map AddExportRT, permit, sequence 10
  Match clauses:
    ip address (access-lists): 10
  Set clauses:
    extended community RT:64512:300
  Policy routing matches: 0 packets, 0 bytes
HongKong_PE#

The highlighted lines show that the route map has a set clause configured to assign route target 64512:300 to routes that match access list 10.

There is one problem with the set clause in the route map, however. The additive keyword is missing. This means that the route target 64512:300 overwrites route target 64512:100 (shown in Example 6-126).

In this scenario, it is intended that route target 64512:300 be added to routes matching access list 10 in addition to route target 64512:100. The route map must, therefore, be modified so that the set clause includes the additive keyword. If this is included, then route target 64512:300 will be attached in addition to route target 64512:100, rather than overwriting it.

Example 6-128 shows the reconfiguration of the route map to include the additive keyword.

Example 6-128. Reconfiguration of the Route Map to Include the additive Keyword
HongKong_PE#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
HongKong_PE(config)#route-map AddExportRT permit 10
HongKong_PE(config-route-map)#no set extcommunity rt 64512:300
HongKong_PE(config-route-map)#set extcommunity rt 64512:300 additive
HongKong_PE(config-route-map)#end
HongKong_PE#

In highlighted line 1, the existing set clause is removed. In highlighted line 2, the set clause is reconfigured with the additive keyword.

After reconfiguring the export map, check the BGP VPNv4 table on the ingress PE router using the show ip bgp vpnv4 vrf_name command, as shown in Example 6-129.

Example 6-129. MP-BGP Routes Are Now Correctly Installed into the BGP VPN4 Table on the Ingress PE Router
Chengdu_PE#show ip bgp vpnv4 vrf mjlnet_VPN
BGP table version is 36, local router ID is 10.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 64512:100 (default for vrf mjlnet_VPN)
*> 172.16.1.0/24    172.16.4.2               1         32768 ?
*> 172.16.2.0/24    172.16.4.2               1         32768 ?
*> 172.16.3.0/24    172.16.4.2               1         32768 ?
*> 172.16.4.0/24    0.0.0.0                  0         32768 ?
*> 172.16.4.2/32    0.0.0.0                  0         32768 ?
*>i172.16.5.0/24    10.1.1.4                 1    100      0 ?
*>i172.16.6.0/24    10.1.1.4                 1    100      0 ?
*>i172.16.7.0/24    10.1.1.4                 1    100      0 ?
*>i172.16.8.0/24    10.1.1.4                 0    100      0 ?
*>i172.16.8.2/32    10.1.1.4                 0    100      0 ?
Chengdu_PE#

As the highlighted lines indicate, mjlnet_VPN site 2 routes are now in the BGP VPNv4 table on the ingress PE router.

Routes Are Blocked by an Import Map

A misconfigured import map on the ingress PE router can cause routes not to be installed in the BGP VPNv4 table.

To verify whether an import map is configured on the ingress PE router, use the show ip vrf detail vrf_name command, as shown in Example 6-130.

Example 6-130. Verifying Whether an Import Map Is Configured Using the show ip vrf detail Command
Chengdu_PE#show ip vrf detail mjlnet_VPN
VRF mjlnet_VPN; default RD 64512:100; default VPNID <not set>
  Interfaces:
    Serial4/1
  Connected addresses are not in global routing table
  Export VPN route-target communities
    RT:64512:100
  Import VPN route-target communities
    RT:64512:100
  Import route-map: FilterImport
  No export route-map
Chengdu_PE#

The highlighted line shows that import map FilterImport is configured on the ingress PE router.

The import route map can be examined using the show route-map route_map_name command, as shown in Example 6-131.

Example 6-131. Examining the Route Map
Chengdu_PE#show route-map FilterImport
route-map FilterImport, permit, sequence 10
  Match clauses:
    ip address (access-lists): 10
  Set clauses:
  Policy routing matches: 0 packets, 0 bytes
Chengdu_PE#

As the highlighted line shows, there is one match clause in the import route map. This match clause references access list 10.

Access list 10 is then examined using the show ip access-lists access_list_number command, as shown in Example 6-132.

Example 6-132. Verifying Access List 10
Chengdu_PE#show ip access-lists 10
Standard IP access list 10
Standard IP access list 10
    deny   172.16.5.0, wildcard bits 0.0.0.255 (2 matches)
    deny   172.16.6.0, wildcard bits 0.0.0.255 (2 matches)
    deny   172.16.7.0, wildcard bits 0.0.0.255 (2 matches)
    deny   172.16.8.0, wildcard bits 0.0.0.255 (2 matches)
    permit any (15 matches)
Chengdu_PE#

As you can see, the mjlnet_VPN site 2 routes (172.16.5.0/24, 172.16.6.0/24, and 172.16.7.0/24) are denied by access list 10.

To resolve this problem, you can either modify or remove the import map. In this case, it is decided that the import map is unnecessary and is removed, as shown in Example 6-133.

Example 6-133. Removal of the Import Map on the Ingress PE Router
Chengdu_PE#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Chengdu_PE(config)#ip vrf mjlnet_VPN
Chengdu_PE(config-vrf)#no import map FilterImport
Chengdu_PE(config-vrf)#end
Chengdu_PE#

The highlighted line indicates the removal of the import map FilterImport.

After removing the import map, check the BGP VPNv4 table on the ingress PE router using the show ip bgp vpnv4 vrf vrf_name command, as shown in Example 6-134.

Example 6-134. mjlnet_VPN Routes Are Now Correctly Installed in the Ingress PE Router's BGP VPNv4 Table
Chengdu_PE#show ip bgp vpnv4 vrf mjlnet_VPN
BGP table version is 61, local router ID is 10.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete
   Network          Next Hop            Metric LocPrf Weight Path
Route Distinguisher: 64512:100 (default for vrf mjlnet_VPN)
*> 172.16.1.0/24    172.16.4.2               1         32768 ?
*> 172.16.2.0/24    172.16.4.2               1         32768 ?
*> 172.16.3.0/24    172.16.4.2               1         32768 ?
*> 172.16.4.0/24    0.0.0.0                  0         32768 ?
*> 172.16.4.2/32    0.0.0.0                  0         32768 ?
*>i172.16.5.0/24    10.1.1.4                 1    100      0 ?
*>i172.16.6.0/24    10.1.1.4                 1    100      0 ?
*>i172.16.7.0/24    10.1.1.4                 1    100      0 ?
*>i172.16.8.0/24    10.1.1.4                 0    100      0 ?
*>i172.16.8.2/32    10.1.1.4                 0    100      0 ?
Chengdu_PE#

The highlighted lines show that mjlnet_VPN site 2 routes are now in the BGP VPNv4 table on the ingress PE router.

Redistribution from MP-BGP into the PE-CE Routing Protocol on the Ingress PE Router

If routes from the egress PE router are installed into the BGP VPNv4 table of the ingress PE router, the next step is to verify redistribution of those routes into the PE-CE routing protocol (assuming that static routes or default routing are not being used).

Figure 6-39 illustrates the redistribution of MP-BGP routes into the PE-CE routing protocol.

Figure 6-39. Redistribution of MP-BGP Routes into the PE-CE Routing Protocol

[View full size image]

In Figure 6-39, routes advertised across the MPLS VPN backbone by egress PE router HongKong_PE are redistributed into the PE-CE routing protocol on ingress PE router Chengdu_PE.

Redistribution Is Incorrectly Configured on the Ingress PE Router

If redistribution of VPNv4 routes into the PE-CE routing protocol is misconfigured and the PE routers do not advertise a default route to the CE routers, VPN routing will fail.

In this case, the PE-CE routing protocol is RIP version 2, so the redistribution of VPNv4 routes can be verified using the show ip rip database vrf vrf_name command, as shown in Example 6-135.

Example 6-135. Verifying Redistribution of BGP VPNv4 Routes into RIP Using the show ip rip database vrf Command
Chengdu_PE#show ip rip database vrf mjlnet_VPN
172.16.0.0/16    auto-summary
172.16.1.0/24
    [1] via 172.16.4.2, 00:00:15, Serial4/1
172.16.2.0/24
    [1] via 172.16.4.2, 00:00:15, Serial4/1
172.16.3.0/24
    [1] via 172.16.4.2, 00:00:15, Serial4/1
172.16.4.0/24    directly connected, Serial4/1
172.16.4.2/32    directly connected, Serial4/1
Chengdu_PE#

As you can see, none of the mjlnet_VPN site 2 routes (172.16.5.0/24, 172.16.6.0/24, and 172.16.7.0/24) are in the RIP database. Redistribution is not taking place.

The configuration of RIP is then examined using the show running-config command, as shown in Example 6-136.

Example 6-136. Examining the RIP Configuration
Chengdu_PE#show running-config | begin router rip
router rip
 version 2
 Redistribute bgp 64512 metric transparent
 !
 address-family ipv4 vrf mjlnet_VPN
 version 2
 network 172.16.0.0
 no auto-summary
 exit-address-family
!

The highlighted line indicates that MP-BGP routes are being redistributed globally. The redistribute command should be configured under the IPv4 address family.

Redistribution is then reconfigured as shown in Example 6-137.

Example 6-137. Reconfiguration of Redistribution of VPNv4 Routes into RIP on the Ingress PE Router
Chengdu_PE#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Chengdu_PE(config)#router rip
Chengdu_PE(config-router)#no redistribute bgp 64512
Chengdu_PE(config-router)#address-family ipv4 vrf mjlnet_VPN
Chengdu_PE(config-router-af)#redistribute bgp 64512 metric transparent
Chengdu_PE(config-router-af)#end
Chengdu_PE#

Redistribution of MP-BGP into global RIP is disabled in highlighted line 1.

Redistribution of MP-BGP into RIP is then configured under the IPv4 address family in highlighted line 2.

Note that when configuring redistribution of MP-BGP routes into RIP, you should ensure that a metric is configured (through the metric option of the redistribute command or by using the default-metric command). If none is configured, routes will be redistributed with the metric of infinity (that is, not redistributed).

Now, recheck redistribution using the show ip rip database vrf vrf_name command, as shown in Example 6-138.

Example 6-138. MP-BGP Routes Are Now Successfully Redistributed into RIP
Chengdu_PE#show ip rip database vrf mjlnet_VPN
172.16.0.0/16    auto-summary
172.16.1.0/24
    [1] via 172.16.4.2, 00:00:19, Serial4/1
172.16.2.0/24
    [1] via 172.16.4.2, 00:00:19, Serial4/1
172.16.3.0/24
    [1] via 172.16.4.2, 00:00:19, Serial4/1
172.16.4.0/24    directly connected, Serial4/1
172.16.4.2/32    directly connected, Serial4/1
172.16.5.0/24    redistributed
    [2] via 10.1.1.4,
172.16.6.0/24    redistributed
    [2] via 10.1.1.4,
172.16.7.0/24    redistributed
    [2] via 10.1.1.4,
172.16.8.0/24    redistributed
    [1] via 10.1.1.4,
172.16.8.2/32    redistributed
    [1] via 10.1.1.4,
Chengdu_PE#

The highlighted lines show that MP-BGP routes are now being redistributed into RIP correctly.

In the scenario described in this section, RIP is the PE-CE routing protocol. However, if your PE-CE routing protocol is EIGRP, then the show ip eigrp vrf vrf_name topology command can be used to verify redistribution. Also, be sure to specify a metric when configuring redistribution of MP-BGP into EIGRP.

If OSPF is your PE-CE routing protocol, the show ip ospf process_id command can be used to verify redistribution. Do not forget to specify the subnets keyword when redistributing MP-BGP into OSPF. If the subnets keyword is not specified, only major networks will be redistributed.

If your PE-CE routing protocol is EBGP, redistribution is not needed.

For a full description of the configuration of redistribution of MP-BGP into the PE-CE routing protocol, see the section, "Step 11: Configure PE-CE Routing Protocols / Static Routes," on page 454 earlier in this chapter.

PE to CE Route Advertisement

After you have ensured that MP-BGP routes are being successfully redistributed into the PE-CE routing protocol, the next step is to verify that these routes are being advertised from the ingress PE router to the CE router.

Figure 6-40 illustrates the advertisement of routes from the ingress PE router to the CE router.

Figure 6-40. Advertisement of Routes from the Ingress PE Router to the CE Router

[View full size image]

In Figure 6-40, Chengdu_PE advertises mjlnet_VPN site 2 routes to CE1.

To verify that routes are being advertised from the ingress PE router to the CE router, examine the routing table on the CE router using the show ip route command on the CE router, as shown in Example 6-139.

Example 6-139. Verifying that Routes Are Being Advertised from the Ingress PE Router to the CE Router
mjlnet_VPN_CE1#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i  IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
Gateway of last resort is not set
     172.16.0.0/24 is subnetted, 4 subnets
C       172.16.4.0 is directly connected, Serial0
R       172.16.1.0 [120/1] via 172.16.3.2, 00:00:02, Ethernet0
R       172.16.2.0 [120/1] via 172.16.3.2, 00:00:02, Ethernet0
C       172.16.3.0 is directly connected, Ethernet0
mjlnet_VPN_CE1#

As you can see, none of the mjlnet_VPN site 2 routes (172.16.5.0/24, 172.16.6.0/24, and 172.16.7.0/24) are present in CE1's routing table.

There are a number of possible reasons that routes are not being received on the CE router, including that the CE or PE VRF interface is misconfigured or down, or that there is a problem with the PE-CE routing protocol.

To troubleshoot this issue, see the section "Troubleshooting Route Advertisement Between the PE and CE Routers" on page 512.

NOTE

Although this section describes troubleshooting of route advertisement across the MPLS VPN backbone in one direction, be sure to verify route advertisement in the opposite direction (using exactly the same troubleshooting methodology). For example, in the topology used throughout this troubleshooting section (see Figure 6-31), you would now need to verify route advertisement from CE1 via Chengdu_PE and HongKong_PE to CE2.


Case Studies

This section contains descriptions and solutions for a number of issues that do not fit easily into the main troubleshooting section.

MPLS MTU Is Too Small in the MPLS VPN Backbone

If large packets are sent across the MPLS backbone with the Don't Fragment (DF) bit set in the IP packet header, and LSR interfaces and Ethernet switches are not configured to support large labeled packets, the packets will be dropped.

NOTE

In this scenario, end hosts will usually quietly reduce the size of the packets they send unless Path MTU Discovery is brokenwhich usually happens because of a misconfigured router or firewall. Path MTU Discovery is a mechanism that allows hosts to dynamically discover the Maximum Transmission Unit (MTU) of a path across a network. See RFC 1191 as well as the following URL for more information:

http://www.cisco.com/en/US/tech/tk870/tk472/tk473/technologies_tech_note09186a008011a218.shtml#pmtud_fail

In an MPLS network, link MTU sizes must take the label stack into account. In a simple MPLS VPN network without MPLS TE, a label stack depth of two is used (TDP/LDP signaled IGP label + VPN label). If MPLS traffic engineering (TE) is being used between P routers in an MPLS VPN backbone, a label stack depth of three is used (RSVP signaled TE label + TDP/LDP signaled IGP label + VPN label). And if you are using Fast Reroute with MPLS TE, that is four labels. Each label is 4 bytes, so the total size of the label stack is number of labels multiplied by 4 bytes.

In this scenario, large packets are being dropped in the MPLS VPN backbone. Figure 6-41 illustrates the customer VPN and MPLS backbone topology used in this scenario.

Figure 6-41. Customer and MPLS VPN Backbone Topology

[View full size image]

Path MTU across the MPLS VPN backbone is verified using the extended ping vrf vrf_name command, as shown in Example 6-140.

Example 6-140. Extended ping vrf Command Output
HongKong_PE#ping vrf mjlnet_VPN
Protocol [ip]:
Target IP address: 172.16.4.1
Repeat count [5]: 1
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 172.16.8.1
Type of service [0]:
Set DF bit in IP header? [no]: y
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]: y
Sweep min size [36]: 1450
Sweep max size [18024]: 1500
Sweep interval [1]:
Type escape sequence to abort.
Sending 51, [1450..1500]-byte ICMP Echos to 172.16.4.1, timeout is 2 seconds:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!M.M.
Success rate is 92 percent (47/51), round-trip min/avg/max = 12/13/16 ms
HongKong_PE#

Highlighted lines 1 and 3 show the destination and source IP addresses used with the extended ping. In this case, the source is the VRF mjlnet_VPN interface on HongKong_PE (172.16.8.1), and the destination is VRF mjlnet_VPN interface on Chengdu_PE (172.16.4.1).

Repeat count is set to 1 packet in highlighted line 2. This is the repeat count per packet size, which is set in highlighted lines 5 to 7.

In highlighted line 4, the Don't Fragment (DF) bit is set. In highlighted lines 5 to 7, a ping sweep of packet sizes 1450 to 1500 is entered. Highlighted line 8 shows that ping is successful for most packet sizes, but that as the packet size nears 1500 bytes, the pings fail.

Note that the "M" character here indicates reception of an ICMP destination unreachable message (ICMP message type 3) from a router in the path across the network. This ICMP unreachable message carries code 4, which indicates that fragmentation is required on the (ping) packet, but that the Don't Fragment bit is set.

The MPLS MTU size for backbone LSRs is examined using the show mpls forwarding-table prefix detail command.

When the MPLS MTU size is examined on Chengdu_P, it is revealed that it is too small (see Example 6-141).

Example 6-141. Verifying the MPLS MTU Size Using the show mpls forwarding-table Command
Chengdu_P#show mpls forwarding-table 10.1.1.1 detail
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
tag    tag or VC   or Tunnel Id      switched   interface
18     Pop tag     10.1.1.1/32       1544       Fa1/0      10.20.10.1
        MAC/Encaps=14/14, MTU=1500, Tag Stack{}
        00049BD60C1C00D06354701C8847
        No output feature configured
    Per-packet load-sharing
Chengdu_P#

The IP address (BGP update source) of the egress PE router (Chengdu_PE) is specified in highlighted line 1. This address corresponds to the next-hop of all mjlnet_VPN site 1 routes.

Highlighted line 2 shows that the outgoing interface for this prefix is interface Fast Ethernet 1/0.

Highlighted line 3 shows that the maximum packet size that can be label switched out of interface Fast Ethernet 1/0 without being fragmented is 1500 bytes. 1500 bytes is clearly not a sufficient maximum packet size if a two-label stack (IGP + VPN) is included (1500 + 8 = 1508). Note, however, that in this case, Chengdu_P is the penultimate hop router, so it will pop the IGP labelbut it is still a very good idea to accommodate a minimum of two labels here.

Chengdu_P's interface Fast Ethernet 1/0 is then configured to support large labeled packets, using the mpls mtu command as shown in Example 6-142.

Example 6-142. Configuration of the mpls mtu Command on Interface fastethernet 1/0 on Chengdu_P
Chengdu_P#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Chengdu_P(config)#interface fastethernet 1/0
Chengdu_P(config-if)#mpls mtu 1508
Chengdu_P(config-if)#end
Chengdu_P#

The highlighted line indicates that interface fastethernet 1/0 is configured to support a label stack depth of two (1500 + [2 * 4]=1508). In this scenario, Cisco 6500 switches are being used in the POPs (in Chengdu and HongKong), so they are configured for jumbo frame support.

To enable support for jumbo frames on the Cisco 6500 series switch Ethernet ports, use the set port jumbo mod/port enable command, as shown in Example 6-143.

Example 6-143. Configuration of Jumbo Frame Support on the Cisco 6500
Chengdu_POP1> (enable) set port jumbo 3/1 enable
Jumbo frames enabled on port  3/1.

By enabling support for jumbo frames, the MTU is increased to 9216 bytes for most line cards.

After the MPLS MTU on all the applicable LSRs is reconfigured and jumbo frame support on the Cisco 6500 switches is enabled, extended ping is again used to verify that 1500-byte packets can be carried across the backbone without fragmentation.

Example 6-144 shows the output of the extended ping vrf vrf_name command after support for large labeled packets has been enabled in the MPLS VPN backbone.

Example 6-144. 1500-Byte Packets Can Now Be Carried Across the MPLS VPN Backbone
HongKong_PE#ping vrf mjlnet_VPN
Protocol [ip]:
Target IP address: 172.16.4.1
Repeat count [5]:
Datagram size [100]: 1500
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 172.16.8.1
Type of service [0]:
Set DF bit in IP header? [no]: y
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 1500-byte ICMP Echos to 172.16.4.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 12/14/16 ms
HongKong_PE#

Highlighted lines 1 and 3 show the destination and source addresses of the ping packets. These are again the VRF mjlnet_VPN interface on Chengdu_PE and the VRF mjlnet_VPN interface on HongKong_PE, respectively.

In highlighted line 2, the packet size is 1500 bytes, and in highlighted line 4, the Don't Fragment (DF) bit is set.

In highlighted line 5, a success rate of 100 percent is shown.

It is also worth noting that if you are using IOS 12.0(27)S or above in your network, you can use the trace mpls MPLS Embedded Management feature command to verify the MTU that can be supported (without fragmentation) over an LSP in the MPLS backbone. This command can display the maximum receive unit (MRU, the maximum labelled packet size) at each hop across the MPLS backbone.

NOTE

For more information about enabling jumbo support on Cisco Catalyst switches, see the document "Configuring Jumbo/Giant Frame Support on Catalyst Switches," at Cisco.com.

Summarization of PE Router Loopback Addresses Causes VPN Packets to Be Dropped

Routes to the next hops of VPN routes (the BGP updates sources on PE routers) should not be summarized in the MPLS VPN backbone; otherwise, VPN packets will be dropped.

Figure 6-42 illustrates the topology used in this scenario.

Figure 6-42. PE Router Loopback Addresses Are Summarized in the MPLS VPN Backbone

[View full size image]

In this scenario, traffic from mjlnet_VPN site 1 transiting the MPLS VPN backbone to mjlnet_VPN site 2 is dropped.

Example 6-145 shows the output of a ping between the VRF mjlnet_VPN interface on Chengdu_PE and host 172.16.5.1 at site 2.

Example 6-145. Ping from the mjlnet_VPN Interface on Chengdu_PE to Host 172.16.5.1
Chengdu_PE#ping vrf mjlnet_VPN 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 0 percent (0/5)
Chengdu_PE#

In highlighted line 1, a ping test is conducted between the VRF mjlnet_VPN interface on Chengdu_PE and host 172.16.5.1. As you can see, the ping test failed with a success rate of 0 percent (highlighted line 2).

Figure 6-43 shows the routing protocol configuration within the MPLS VPN backbone.

Figure 6-43. Routing Protocol Configuration with the MPLS VPN Backbone

[View full size image]

In this scenario, OSPF is the backbone routing protocol, with Chengdu_PE, Chengdu_P, and HongKong_P in area 0, and HongKong_P and HongKong_PE in area 1.

When mjlnet_VPN packets transiting the network from mjlnet_VPN site 1 to mjlnet_VPN site 2 reach ingress PE Chengdu_PE, a two-label stack is imposed. The outer label is the IGP label (which corresponds to BGP next-hop 10.1.1.4 on egress PE router HongKong_PE), and the inner label is the VPN label.

VPN traffic is not successfully transiting the backbone. But is the problem something to do with the underlying LSP between Chengdu_PE and HongKong_PE, is it with VPN route exchange, or is it something else?

The next step is to verify the LSP between Chengdu_PE (10.1.1.1) and HongKong_PE (10.1.1.4) using the traceroute command, as shown in Example 6-146.

Example 6-146. traceroute to Egress Router HongKong_PE
Chengdu_PE#traceroute 10.1.1.4

Type escape sequence to abort.
Tracing the route to 10.1.1.4

  1 10.20.10.2 [MPLS: Label 17 Exp 0] 0 msec 0 msec 4 msec
  2 10.20.20.2 0 msec 0 msec 4 msec
  3 10.20.30.2 32 msec 0 msec *
Chengdu_PE#

In highlighted line 1, Chengdu_PE imposes (IGP) label 17 to the traceroute packet and forwards it to Chengdu_P.

In highlighted line 2, Chengdu_P forwards the packet to HongKong_P. There is, however, no evidence of a label stack at all. The same is true in highlighted line 3 as the packet is forwarded from HongKong_P to HongKong_PE.

Apparently there is a problem with the LSP. But what exactly is going on here? To track the answer down, it is useful to examine the LFIB/LIBs on the routers in the path. The IGP label (for next-hop 10.1.1.4) is verified on ingress PE router Chengdu_PE using the show mpls forwarding-table prefix detail command. This command displays the LFIB.

Example 6-147 shows the LFIB entry for prefix 10.1.1.4/32 on ingress PE router Chengdu_PE.

Example 6-147. LFIB Entry for Prefix 10.1.1.4
Chengdu_PE#show mpls forwarding-table 10.1.1.4 detail
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
tag    tag or VC   or Tunnel Id      switched   interface
18     17          10.0.0.0/8        0          Fa1/0      10.20.10.2
        MAC/Encaps=14/18, MRU=1500, Tag Stack{17}
        00502AFE080000049BD60C1C8847 00011000
        No output feature configured
    Per-packet load-sharing, slots: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Chengdu_PE#

As you can see, the IGP label used for BGP next-hop 10.1.1.4 is 17 (highlighted line 2). This label corresponds to prefix 10.0.0.0/8 (highlighted line 1). This is a bit of a mystery. Why is there no label corresponding directly to 10.1.1.4/32?

The routing table is then examined using the show ip route command, as shown in Example 6-148.

Example 6-148. Global Routing Table on Chengdu_PE
Chengdu_PE#show ip route
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
       i  IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
Gateway of last resort is not set
     10.0.0.0/8 is variably subnetted, 5 subnets, 3 masks
O       10.1.1.2/32 [110/2] via 10.20.10.2, 01:09:42, FastEthernet1/0
O       10.20.20.0/24 [110/65] via 10.20.10.2, 01:09:42, FastEthernet1/0
O IA    10.0.0.0/8 [110/66] via 10.20.10.2, 01:09:42, FastEthernet1/0
C       10.1.1.1/32 is directly connected, Loopback0
C       10.20.10.0/24 is directly connected, FastEthernet1/0
Chengdu_PE#

Highlighted line 1 shows a summary route (10.0.0.0/8). Notice the absence of a route to the loopback 0 interface on HongKong_PE (10.1.1.4/32). This is the reason that there is no label for prefix 10.1.1.4/32 in the LFIB.

The label stack for mjlnet_VPN site 2 destination 172.16.5.1 is now examined using the show mpls forwarding-table vrf vrf_name prefix detail command, as shown in Example 6-149. Note that destination 172.16.5.1 is used here only for illustrative purposes.

Example 6-149. Label Stack for mjlnet_VPN Site 2 Destination 172.16.5.1
Chengdu_PE#show mpls forwarding-table vrf mjlnet_VPN 172.16.5.1 detail
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
tag    tag or VC   or Tunnel Id      switched   interface
None   17          172.16.5.0/24     0          Fa1/0      10.20.10.2
        MAC/Encaps=14/22, MRU=1496, Tag Stack{17 21}
        00502AFE080000049BD60C1C8847 0001100000015000
        No output feature configured
Chengdu_PE#

The highlighted portion shows the label stack (17, 21) used for mjlnet_VPN site 2 destination 172.16.5.1. The outer label (17) is the IGP label, and the inner label (21) is the VPN label.

The LFIB is then checked on Chengdu_P (the downstream LSR in the LSP to egress PE router HongKong_PE) using the show mpls forwarding-table labels label_value detail command, as shown in Example 6-150.

Example 6-150. Verifying the LFIB on Chengdu_P
Chengdu_P#show mpls forwarding-table labels 17 detail
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
tag    tag or VC   or Tunnel Id      switched   interface
17     Pop tag     10.0.0.0/8        900        Se1/1      point2point
        MAC/Encaps=4/4, MRU=1504, Tag Stack{}
        FF030281
        No output feature configured
    Per-packet load-sharing
Chengdu_P#

The highlighted portion shows that local label 17 (the IGP label on Chengdu_PE) is popped on Chengdu_P. This means that the downstream LSR (HongKong_P) is advertising an implicit-null label for prefix 10.0.0.0/8 (the summary route).

This is verified using the show mpls ldp bindings prefix mask_length detail command on HongKong_P as shown in Example 6-151.

Example 6-151. Verifying the LIB on HongKong_P
HongKong_P#show mpls ldp bindings 10.0.0.0 8 detail
  tib entry: 10.0.0.0/8, rev 12
        Local binding:  tag: imp-null
          Advertised to:
          10.1.1.4:0             10.1.1.2:0
        remote binding: tsr: 10.1.1.2:0, tag: 17
HongKong_P#

The output in Example 6-151 confirms that an implicit-null (highlighted line 1) is advertised to LSR Chengdu_P (10.1.1.2, highlighted line 2) for prefix 10.0.0.0/8.

The effect of Chengdu_P popping the IGP label is that it forwards mjlnet_VPN packets (including those for 172.16.5.1) with a label stack consisting of only the VPN label to HongKong_P.

Unfortunately, HongKong_P has no knowledge of VPN labels (only PE routers do). This is confirmed using the show mpls forwarding-table labels label_value command. Remember that the VPN label is 21 (see Example 6-149).

Example 6-152 shows the LFIB entry corresponding to label value 21.

Example 6-152. LFIB on HongKong_P
HongKong_P#show mpls forwarding-table labels 21
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
tag    tag or VC   or Tunnel Id      switched   interface
HongKong_P#

As you can see, there is no entry. The debug mpls packets command that follows in Example 6-153 is used here to illustrate what happens to mjlnet_VPN packets as they transit HongKong_P from mjlnet_VPN site 1 to mjlnet_VPN site 2.

CAUTION

The debug mpls packet command is used here to illustrate label switching on HongKong_P. Note that you should be especially careful when using the debug mpls packets command because it can produce copious output.

Example 6-153 shows the output of the debug mpls packets command on HongKong_P.

Example 6-153. debug mpls packets Command Output on HongKong_P
HongKong_P#debug mpls packets
MPLS packet debugging is on
HongKong_P#
01:10:26: TAG: Se1/0: recvd: CoS=0, TTL=254, Tag(s)=21
01:10:28: TAG: Se1/0: recvd: CoS=0, TTL=254, Tag(s)=21
01:10:30: TAG: Se1/0: recvd: CoS=0, TTL=254, Tag(s)=21
01:10:32: TAG: Se1/0: recvd: CoS=0, TTL=254, Tag(s)=21
01:10:34: TAG: Se1/0: recvd: CoS=0, TTL=254, Tag(s)=21
HongKong_P#

In highlighted line 1, a packet is received (recvd) with label 21 (the VPN label) on interface serial 1/0 (from Chengdu_P). Notice that the packet is not transmitted (xmit) onward to HongKong_PE (on interface Fast Ethernet 1/0).

Figure 6-44 illustrates label switching of packets across the MPLS VPN backbone when summarization is configured.

Figure 6-44. Label Switching Across the MPLS VPN Backbone When Summarization Is Configured

So, summary route 10.0.0.0/8 is causing VPN packets to be dropped by HongKong_P. The OSPF configuration on HongKong_P is examined using the show running-config command as shown in Example 6-154. Note that only the relevant portion of the output is shown.

Example 6-154. Configuration of OSPF on HongKong_P
HongKong_P#show running-config | begin router ospf
router ospf 100
 log-adjacency-changes
 area 1 range 10.0.0.0 255.0.0.0
 passive-interface Loopback0
 network 10.1.1.3 0.0.0.0 area 1
 network 10.20.20.0 0.0.0.255 area 0
 network 10.20.30.0 0.0.0.255 area 1
!

The highlighted line indicates the cause of the problem. Summary route 10.0.0.0/8 is configured for area 1 addresses. This summary blocks the advertisement of the route 10.1.1.4/32 (the BGP next-hop for mjlnet_VPN site 2 routes) to Chengdu_P and Chengdu_PE.

The summary route is then removed on HongKong_P, as shown in Example 6-155.

Example 6-155. The Summary Route Is Removed on Chengdu_P
HongKong_P#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
HongKong_P(config)#router ospf 100
HongKong_P(config-router)#no area 1 range 10.0.0.0 255.0.0.0
HongKong_P(config-router)#end
HongKong_P#

In highlighted line 1, the summary route is removed on HongKong_P. After the summary route is removed, mjlnet_VPN traffic transits the MPLS VPN backbone successfully from site 1 to site 2.

Example 6-156 shows the output of a ping test from the VRF mjlnet_VPN interface on Chengdu_PE to host 172.16.5.1.

Example 6-156. Ping Now Succeeds Across the MPLS VPN Backbone
Chengdu_PE#ping vrf mjlnet_VPN 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 = 148/148/152 ms
Chengdu_PE#

Highlighted line 1 shows a ping test from the VRF mjlnet_VPN interface on Chengdu_PE to site 2 host 172.16.5.1. Highlighted line 2 indicates the test had a 100 percent success rate.

MPLS VPN Traffic Is Dropped on TE Tunnels Between P Routers

If TE tunnels are configured between P routers in the MPLS VPN backbone, you must take care must to ensure that VPN traffic is not dropped.

Figure 6-45 shows the network topology and TE tunnel configuration used in this scenario.

Figure 6-45. Network Topology and TE Tunnel Configuration

[View full size image]

In this scenario, a TE tunnel is configured from Chengdu_P via Shanghai_P to HongKong_P. A TE tunnel is also configured in the opposite direction from HongKong_P to Chengdu_P.

Unfortunately, when connectivity is tested from Chengdu_PE's VRF mjlnet_VPN interface to HongKong_PE's VRF mjlnet_VPN interface using ping, the success rate is 0 percent.

Examine 6-157 shows the results of a ping test from Chengdu_PE's VRF mjlnet_VPN interface to HongKong_PE's VRF mjlnet_VPN interface (172.16.8.1).

Example 6-157. Ping from Chengdu_PE's VRF mjlnet_VPN Interface to HongKong_PE's VRF mjlnet_VPN Interface Fails
Chengdu_PE#ping vrf mjlnet_VPN 172.16.8.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.8.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Chengdu_PE#

The next step is to verify the LSP from Chengdu_PE to HongKong_PE using traceroute, as shown in Example 6-158.

Example 6-158. Verifying the LSP Using traceroute
Chengdu_PE#traceroute 10.1.1.4

Type escape sequence to abort.
Tracing the route to 10.1.1.4

  1 10.20.10.2 [MPLS: Label 25 Exp 0] 4 msec 4 msec 4 msec
  2 10.20.40.2 [MPLS: Label 23 Exp 0] 8 msec 4 msec 8 msec
  3 10.20.50.2 4 msec 4 msec 4 msec
  4 10.20.30.2 8 msec 4 msec *
Chengdu_PE#

In highlighted line 1, Chengdu_PE imposes TDP/LDP signaled IGP label 25 on the packet and forwards it to Chengdu_P. Chengdu_P then swaps label 25 for (RSVP signaled TE) label 23 and forwards the packet to Shanghai_P over the TE tunnel (highlighted line 2).

Then in highlighted line 3, something strange happens: Shanghai_P forwards the packet unlabeled to HongKong_P. To track down what is happening, the LSP for mjlnet_VPN traffic is examined hop-by-hop from Chengdu_PE to HongKong_P.

The first thing to do is to verify the label stack for prefix 172.16.8.1/32 (the mjlnet_VPN interface on HongKong_PE) on Chengdu_PE using the show mpls forwarding-table vrf vrf_name detail command as shown in Example 6-159.

Example 6-159. Label Stack on Chengdu_PE for Packets to 172.16.8.1
Chengdu_PE#show mpls forwarding-table vrf mjlnet_VPN 172.16.8.1 detail
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
tag    tag or VC   or Tunnel Id      switched   interface
None   25          172.16.8.0/24     0          Fa1/0      10.20.10.2
    MAC/Encaps=14/22, MRU=1496, Tag Stack{25 34}
    00D06354701C00049BD60C1C8847 0001900000022000
    No output feature configured
    Per-packet load-sharing, slots: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Chengdu_PE#

The highlighted portion shows the label stack for mjlnet_VPN destination 172.16.8.1. The outer label is the TDP/LDP signaled IGP label (25), and the inner label is the VPN label (34).

The CEF entry for prefix 10.1.1.4/32 (the next hop for 172.16.8.1) is then examined on Chengdu_P using the show ip cef prefix detail command as shown in Example 6-160.

Example 6-160. CEF Entry for Prefix 10.1.1.4/32 on Chengdu_P
Chengdu_P#show ip cef 10.1.1.4 detail
10.1.1.4/32, version 25
0 packets, 0 bytes
  tag information set
    local tag: 25
    fast tag rewrite with Tu0, point2point, tags imposed: {23}
  via 10.1.1.3, Tunnel0, 0 dependencies
    next hop 10.1.1.3, Tunnel0
    valid adjacency
    tag rewrite with Tu0, point2point, tags imposed: {23}
Chengdu_P#

Highlighted lines 1 and 2 shows that (TDP/LDP signaled IGP) label 25 is removed and outgoing (RSVP signaled TE) label 23 is imposed as packets are switched over the TE tunnel (Tu0, tunnel 0).

The label stack for VPN packets at this point is as follows: the outer label is the TE label (23), and the inner label is the VPN label (34).

The TE tunnel is routed via Shanghai_P, and so the LFIB is now examined on Shanghai_P as shown in Example 6-161.

Example 6-161. LFIB on Shanghai_P
Shanghai_P#show mpls forwarding-table label 23 detail
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
tag    tag or VC   or Tunnel Id      switched   interface
23     Pop tag     10.1.1.2 0 [71]   14618931   Se1/1      point2point
    MAC/Encaps=4/4, MTU=1504, Tag Stack{}
    FF030281
    No output feature configured
Shanghai_P#

The highlighted portion shows that TE tunnel label 23 is popped on Shanghai_P. This is OK because the TE tunnel tail-end is HongKong_P (Shanghai_P is the penultimate hop for the tunnel).

Because the outer (TE) label has now been removed, the label stack at this point consists of only the VPN label (34). Packets are then forwarded to HongKong_P.

The output of the debug mpls packet command on Shanghai_P is shown in Example 6-162.

CAUTION

The debug mpls packet command is used here to illustrate label switching on Shanghai_P. Note that you should exercise extra caution when using this command because it can produce copious output and severely impact router performance.

Example 6-162. Label Switching on Shanghai_P
Shanghai_P#debug mpls packets
Tagswitch packet debugging is on
Shanghai_P#
*Mar  1 05:06:03.562 UTC: TAG: Se1/0: recvd: CoS=0, TTL=254, Tag(s)=23/34
*Mar  1 05:06:03.562 UTC: TAG: Se1/1: xmit: CoS=0, TTL=253, Tag(s)=34
*Mar  1 05:06:05.562 UTC: TAG: Se1/0: recvd: CoS=0, TTL=254, Tag(s)=23/34
*Mar  1 05:06:05.562 UTC: TAG: Se1/1: xmit: CoS=0, TTL=253, Tag(s)=34
*Mar  1 05:06:07.562 UTC: TAG: Se1/0: recvd: CoS=0, TTL=254, Tag(s)=23/34
*Mar  1 05:06:07.562 UTC: TAG: Se1/1: xmit: CoS=0, TTL=253, Tag(s)=34

In highlighted line 1, you can see an mjlnet_VPN packet received on interface serial 1/0 with label stack 23/34 (the TE and VPN labels, respectively). Then in highlighted line 2, you can see that the TE label is popped, and the packet is forwarded with only VPN label 34.

When the LFIB on HongKong_P is examined using the show mpls forwarding-table label label_value command in Example 6-163, there is no entry for incoming (VPN) label 34.

Example 6-163. LFIB on HongKong_P
HongKong_P#show mpls forwarding-table label 34 detail
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
tag    tag or VC   or Tunnel Id      switched   interface
HongKong_P#

The absence of an LFIB entry for VPN label 34 is no surprise because HongKong_P is not a PE routerremember that only PE routers have knowledge of VPN labels. The upshot is that all mjlnet_VPN packets arriving on HongKong_P are dropped.

Figure 6-46 illustrates label switching of packets across the MPLS VPN backbone when LDP is not enabled on a TE tunnel configured between P routers.

Figure 6-46. Packets Are Dropped on HongKong_P

[View full size image]

To solve this issue, you must find a solution where packets do not arrive at the TE tunnel tail-end (HongKong_P) with a label stack consisting of only the VPN label. You can resolve this issue by enabling MPLS (LDP) on the TE tunnel itself. MPLS (LDP) should be enabled on both the tunnel from Chengdu_P to HongKong_P and the tunnel from HongKong_P to Chengdu_P.

Example 6-164 shows the configuration of MPLS (LDP) on the TE tunnels between Chengdu_P and HongKong_P.

Example 6-164. Configuration of MPLS (LDP) on the TE Tunnels
! On Chengdu_P:
Chengdu_P#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Chengdu_P(config)#interface tunnel 0
Chengdu_P(config-if)#mpls ip
Chengdu_P(config-if)#end
Chengdu_P#
________________________________________________________________
! On HongKong_P:
HongKong_P#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
HongKong_P(config)#interface tunnel 0
HongKong_P(config-if)#mpls ip
HongKong_P(config-if)#end
HongKong_P#

Once MPLS has been enabled on the TE tunnels, Chengdu_P and HongKong_P discover each other over the TE tunnel (via LDP neighbor discovery). Crucially, this means that the TDP/LDP signaled IGP label is swapped instead of removed from mjlnet_VPN packets as they enter the TE tunnel.

When packets reach TE tunnel tail-end HongKong_P, it pops the IGP label (because of penultimate hop popping, requested by HongKong_PE) and forwards the packets to HongKong_PE with a label stack consisting only of the VPN label.

The path is now verified from Chengdu_PE's VRF mjlnet_VPN interface to HongKong_PE's VRF mjlnet_VPN interface using VRF traceroute, as shown in Example 6-165.

Example 6-165. traceroute Succeeds from Chengdu_PE's VRF mjlnet_VPN Interface to HongKong_PE's VRF mjlnet_VPN Interface
[View full width]
Chengdu_PE# traceroute    Vrf         mjlnet_VPN
Protocol                  [ip]:
Target                    IP          address:       172.16.8.1
Source                    address:    172.16.4.1
Numeric                   display     [n]:
Timeout                   in          seconds        [3]:
Probe                     count       [3]:
Minimum                   Time        to             Live        [1]:
Maximum                   Time        to             Live        [30]:
Port                      Number      [33434]:
Loose,                    Strict,     Record,        Timestamp,  Verbose[none]:
Type                      escape      sequence       to          abort.
Tracing                   the         route          to          172.16.8.1

                 1        10.20.10.2  [MPLS:         Labels      25/34          Exp    0]
    4   msec   4   msec   4 msec
                 2        10.20.40.2  [MPLS:         Labels      23/16/34       Exp    0]
    4   msec   4   msec   4 msec
                 3        10.20.50.2  [MPLS:         Labels      16/34          Exp    0]
    4   msec   4   msec   4 msec
                 4        172.16.8.1  0              msec        0              msec   *
Chengdu_PE#

In highlighted line 1, Chengdu_PE imposes label stack 25/34 (TDP/LDP signaled IGP and VPN label, respectively) on the packet and forwards it to Chengdu_P.

In highlighted line 2, Chengdu_P swaps IGP label 25 for IGP TDP/LP signaled label 16 and additionally imposes RSVP signaled TE label 23. VPN label 34 is unmodified. The packet is then forwarded over the TE tunnel to Shanghai_P.

Because the next hop, HongKong_P, is the tunnel tail-end, Shanghai_P pops the TE label. IGP label 16 and VPN label 34 are unmodified (highlighted line 3). The packet is then forwarded to HongKong_P.

HongKong_P then pops IGP label 16 because it is the penultimate hop. The VPN label is unmodified (not shown), and the packet is forwarded to HongKong_PE. VPN traffic is now successfully transiting the TE tunnel between Chengdu_P and HongKong_P.

Figure 6-47 illustrates label switching of packets across the MPLS VPN backbone when TE tunnels are configured between P routers with MPLS (LDP) enabled.

Figure 6-47. Label Switching Across the MPLS VPN Backbone When LDP Is Enabled over TE Tunnels Between P Routers

[View full size image]

MVPN Fails When TE Tunnels Are Configured in the MPLS VPN Backbone

When configuring MVPN in a MPLS backbone with TE tunnels, the IGP (IS-IS or OSPF) must be configured to ensure that Reverse Path Forwarding (RPF) checks for multicast traffic do not fail.

In this scenario, MVPN is configured for VRF mjlnet_VPN on PE routers Chengdu_PE, HongKong_PE, and Shanghai_PE. Additionally, TE tunnels are configured between P routers Chengdu_P, HongKong_P, and Shanghai_P. These TE tunnels are configured with autoroute. The backbone is configured for PIM sparse mode, with the Rendezvous Point (RP) on Chengdu_P.

There is a multicast server at mjlnet_VPN site 1 and multicast receivers at mjlnet_VPN sites 2 and 3. Unfortunately, the receivers are unable to receive any multicast traffic from the multicast server.

Figure 6-48 illustrates the MVPN and TE configuration in the MPLS VPN backbone.

Figure 6-48. MVPN and TE Configuration in the MPLS VPN Backbone

[View full size image]

The first step in troubleshooting this issue is to check whether PE routers Chengdu_PE, HongKong_PE, and Shanghai_PE are correctly advertising participation in the MPVN to each other. Each PE router is checked in turn using the show ip pim mdt bgp command, as shown in Example 6-166.

Example 6-166. show ip pim mdt bgp Command Output on the PE Routers
! On Chengdu_PE:
Chengdu_PE#show ip pim mdt bgp
  Peer (Route Distinguisher + IPv4)                               Next Hop
MDT group 239.0.0.1
  2:64512:100:10.1.1.4                                            10.1.1.4
  2:64512:100:10.1.1.6                                            10.1.1.6
Chengdu_PE#
________________________________________________________________
! On HongKong_PE:
HongKong_PE#show ip pim mdt bgp
  Peer (Route Distinguisher + IPv4)                               Next Hop
MDT group 239.0.0.1
  2:64512:100:10.1.1.1                                            10.1.1.1
  2:64512:100:10.1.1.6                                            10.1. 1.6
HongKong_PE#
________________________________________________________________
! On Shanghai_PE:
Shanghai_PE#show ip pim mdt bgp
Peer (Route Distinguisher + IPv4)                                  Next Hop
  MDT group 239.0.0.1
   2:64512:100:10.1.1.1                                            10.1.1.1
   2:64512:100:10.1.1.4                                            10.1.1.4
Shanghai_PE#

Highlighted line 1 shows the default MDT address (239.0.0.1). Highlighted lines 2 and 3 shows that Chengdu_PE has received advertisements signaling participation in the MVPN from both HongKong_PE (10.1.1.4), and Shanghai_PE (10.1.1.6). Note the RD used here (2:ASN:XX). This is a type 2 RD used to advertise MPVN participation.

As you can see, HongKong_PE has received advertisements from Chengdu_PE and Shanghai_PE (10.1.1.1 and 10.1.1.6). Shanghai_PE has received advertisements from Chengdu_PE and HongKong_PE (10.1.1.1 and 10.1.1.4). Participation in the MVPN is being correctly advertised between the PE routers.

Starting at Chengdu_PE, the multicast state for the default MDT is then verified using the show ip mroute command, as shown in Example 6-167.

Example 6-167. Verifying the Multicast State for Chengdu_PE
Chengdu_PE#show ip mroute 239.0.0.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
       L - Local, P - Pruned, R - RP-bit set, F - Register flag,
       T - SPT-bit set, J - Join SPT, M - MSDP created entry,
       X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
       U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel,
       Y - Joined MDT-data group, y - Sending to MDT-data group
Outgoing interface flags: H - Hardware switched
 Timers: Uptime/Expires
 Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.0.0.1), 07:28:15/stopped, RP 10.1.1.2, flags: SJCFZ
  Incoming interface: FastEthernet1/0, RPF nbr 10.20.10.2
  Outgoing interface list:
    MVRF mjlnet_VPN, Forward/Sparse-Dense, 07:28:15/00:00:00
(10.1.1.1, 239.0.0.1), 07:14:24/00:02:53, flags: PFTZ
  Incoming interface: Loopback0, RPF nbr 0.0.0.0
  Outgoing interface list: Null
Chengdu_PE#

Highlighted line 1 shows that a (*, G) entry has been created for the default MDT group address (*, 239.0.0.1). An (S, G) entry for source 10.1.1.1 (Chengdu_PE itself) is shown in highlighted line 2. Notice that the P (Pruned) flag is set. Finally, in highlighted line 3, you can see that the outgoing interface list for source 10.1.1.1 is null. This is consistent with the fact that the P flag is set. Also note the Z flag, which indicates that this entry corresponds to a multicast tunnel.

Two things are wrong here:

  • (S, G) entries should exist for sources 10.1.1.4 (HongKong_PE) and 10.1.1.6 (Shanghai_PE).

  • The outgoing interface list should be populated for source 10.1.1.1.

The next thing to check is whether Chengdu_PE has discovered PIM neighbors (specifically, Chengdu_P).

To verify PIM neighbor discovery on Chengdu_PE, use the show ip pim neighbor command as shown in Example 6-168.

Example 6-168. Verifying PIM Neighbor Discovery
Chengdu_PE#show ip pim neighbor
PIM Neighbor Table
Neighbor          Interface                Uptime/Expires    Ver   DR
Address                                                            Priority/Mode
10.20.10.2        FastEthernet1/0          02:27:46/00:01:43 v2    N / DR
Chengdu_PE#

The highlighted line shows that Chengdu_PE has discovered one neighbor (10.20.10.2)Chengdu_P, which is the Rendezvous Point (RP) in the backbone network.

Moving on to Chengdu_P, the multicast state for the default MDT (group 239.0.0.1) is again checked using the show ip mroute command, as shown in Example 6-169.

Example 6-169. Multicast State for the Default MDT on Chengdu_PE
Chengdu_P#show ip mroute 239.0.0.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
       R  RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
       M - MSDP created entry, X - Proxy Join Timer Running
       A - Candidate for MSDP Advertisement
Outgoing interface flags: H - Hardware switched
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.0.0.1), 02:40:37/00:03:06, RP 10.1.1.2, flags: S
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet1/0, Forward/Sparse-Dense, 02:40:32/00:03:06
    Serial1/0, Forward/Sparse-Dense, 02:19:01/now
    Serial1/1, Forward/Sparse-Dense, 01:57:48/now
(10.1.1.1, 239.0.0.1), 02:40:25/00:01:27, flags: PT
  Incoming interface: FastEthernet1/0, RPF nbr 10.20.10.1
  Outgoing interface list: Null
(10.1.1.4, 239.0.0.1), 02:19:13/00:02:29, flags: T
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet1/0, Forward/Sparse-Dense, 02:19:13/00:02:36
(10.1.1.6, 239.0.0.1), 02:40:06/00:02:36, flags: T
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet1/0, Forward/Sparse-Dense, 02:40:06/00:02:34
Chengdu_P#

Things now get very mysterious. Highlighted line 1 shows the (*, G) entry for the default MDT: (*, 239.0.0.1).

Highlighted line 2 shows the (S, G) entry for source 10.1.1.1: Chengdu_PE. Notice that the P flag is set. This indicates that the outgoing interface list should be null. The incoming interface is Fast Ethernet 1/0, and the RPF neighbor is 10.20.10.1. This is logical because 10.20.10.1 is Chengdu_PE. Again, the outgoing interface list for this source is, as expected, null. This is no good because it should contain the interfaces serial 1/0 and serial 1/1 (toward HongKong_P and Shanghai_P, respectively).

Highlighted lines 3 and 4 show the (S, G) entries for sources 10.1.1.4 (HongKong_PE) and 10.1.1.6 (Shanghai_PE). Notice that the incoming interface is null, and the RPF neighbor is 0.0.0.0. This is very strange. The incoming interface for 10.1.1.4 should be serial 1/0, and the RPF neighbor should be 10.1.1.3 (HongKong_P). Similarly, the incoming interface for 10.1.1.6 should be serial 1/1, and the RPF neighbor 10.1.1.5 (Shanghai_P).

Next, PIM neighbor discovery is checked on Chengdu_P using the show ip pim neighbor command as shown in Example 6-170.

Example 6-170. PIM Neighbor Discovery Is Checked on Chengdu_P
Chengdu_P#show ip pim neighbor
PIM Neighbor Table
Neighbor Address  Interface                Uptime    Expires   Ver  Mode
10.20.10.1        FastEthernet0/0          03:12:17  00:01:25  v2
10.20.20.2        Serial1/0                02:50:47  00:01:15  v2
10.20.40.2        Serial1/1                02:29:29  00:01:19  v2
Chengdu_P#

The highlighted lines show that HongKong_P (10.20.20.2) and Shanghai_P (10.20.40.2) are PIM neighbors, which is as it should be.

The debug ip pim command is then used to check which PIM messages are being received by Chengdu_P from the PE routers, as shown in Example 6-171 (note that only the relevant portions of the output are shown).

Example 6-171. debug ip pim Command Output on Chengdu_P
Chengdu_P#debug ip pim
PIM debugging is on
Chengdu_P#
04:35:56: PIM: Received v2 Register on Serial1/0 from 10.20.30.2
04:35:56:      (Data-header) for 10.1.1.4, group 239.0.0.1
04:35:56: PIM: RPF lookup failed to source 10.1.1.4
04:36:03: PIM: Received v2 Register on Serial1/1 from 10.20.60.2
04:36:03:      (Data-header) for 10.1.1.6, group 239.0.0.1
04:36:03: PIM: RPF lookup failed to source 10.1.1.6
Chengdu_P#

Here are some answers. Highlighted lines 1 to 3 show that HongKong_PE (10.1.1.4) is sending PIM Register messages to Chengdu_P (remember that Chengdu_P is the RP). HongKong_PE is trying to notify Chengdu_P that it is an active source for the default MDT (239.0.0.1). Unfortunately, the RPF check on the encapsulated multicast packet fails. Highlighted lines 4 to 6 show that exactly the same thing is happening for Shanghai_PE (10.1.1.6).

The RPF check state on Chengdu_P can also be verified for sources 10.1.1.4 and 10.1.1.6 using the show ip rpf command, as shown in Example 6-172.

Example 6-172. show ip rpf Command Output on Chengdu_P
! For HongKong_PE (10.1.1.4):
Chengdu_P#show ip rpf 10.1.1.4
RPF information for ? (10.1.1.4) failed, no route exists
Chengdu_P#
________________________________________________________________
! For Shanghai_PE (10.1.1.6):
Chengdu_P#show ip rpf 10.1.1.6
RPF information for ? (10.1.1.6) failed, no route exists
Chengdu_P#

The highlighted lines show that the RPF fails for both source 10.1.1.4 and 10.1.1.6 because no route exists for these sources.

This is verified using the show ip route command as shown in Example 6-173.

Example 6-173. show ip route Command Output
! For source 10.1.1.4 (HongKong_PE):
Chengdu_P#show ip route 10.1.1.4
Routing entry for 10.1.1.4/32
  Known via "isis", distance 115, metric 20, type level-2
  Redistributing via isis
  Last update from 10.1.1.3 on Tunnel20, 03:34:51 ago
  Routing Descriptor Blocks:
  * 10.1.1.3, from 10.1.1.4, via Tunnel20
      Route metric is 20, traffic share count is 1
Chengdu_P#
________________________________________________________________
! For source 10.1.1.6 (Shanghai_PE):
Chengdu_P#show ip route 10.1.1.6
Routing entry for 10.1.1.6/32
  Known via "isis", distance 115, metric 20, type level-2
  Redistributing via isis
  Last update from 10.1.1.5 on Tunnel10, 03:13:46 ago
  Routing Descriptor Blocks:
  * 10.1.1.5, from 10.1.1.6, via Tunnel10
      Route metric is 20, traffic share count is 1
Chengdu_P#

Highlighted line 1 reveals that there is in fact a route to 10.1.1.4 /32 via interface tunnel 20 (a TE tunnel). Similarly, highlighted line 2 shows that there is a route to 10.1.1.6/32 via interface tunnel 10. Why does the show ip rpf command not show a route?

The answer is that multicast packets (Register messages, in this case) are received on interfaces serial 1/0 and serial 1/1, but the unicast routes back to the source of the packets are via the TE tunnels. This causes the RPF check failure. When the RPF check fails, multicast packets are dropped.

You might think that the solution to this problem is to enable PIM on the TE tunnels. Unfortunately, TE tunnels are unidirectional, so that will not work.

The answer is to allow unicast traffic to be forwarded over the TE tunnels, while ensuring that multicast uses the physical interfaces. This can be achieved by configuring the mpls traffic-eng multicast-intact command on the head-end router of each TE tunnel. This command can be configured under either the IS-IS or OSPF process, depending on which IGP you are using. This command is enabled on Chengdu_P, HongKong_P, and Shanghai_P (the TE tunnel head-ends) as shown in Example 6-174.

In Example 6-174, mpls traffic-eng multicast-intact is enabled on Chengdu_P. This command is similarly enabled on HongKong_P and Shanghai_P.

Example 6-174. Configuration of mpls traffic-eng multicast intact on Chengdu_P
Chengdu_P#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Chengdu_P(config)#router isis
Chengdu_P(config-router)#mpls traffic-eng multicast-intact
Chengdu_P(config-router)#end
Chengdu_P#

RPF information for sources 10.1.1.4 (HongKong_PE) and 10.1.1.6 (Shanghai_PE) is now rechecked on Chengdu_P using the show ip rpf command, as shown in Example 6-175.

Example 6-175. Rechecking RPF Information for Sources 10.1.1.4 (HongKong_PE) and 10.1.1.6 (Shanghai_PE)
! For 10.1.1.4 (HongKong_PE):
Chengdu_P#show ip rpf 10.1.1.4
RPF information for ? (10.1.1.4)
  RPF interface: Serial1/0
  RPF neighbor: ? (10.20.20.2)
  RPF route/mask: 10.1.1.4/32
  RPF type: unicast (isis)
  RPF recursion count: 0
  Doing distance-preferred lookups across tables
Chengdu_P#
________________________________________________________________
! For 10.1.1.6 (Shanghai_PE):
Chengdu_P#show ip rpf 10.1.1.6
RPF information for ? (10.1.1.6)
  RPF interface: Serial1/1
  RPF neighbor: ? (10.20.40.2)
  RPF route/mask: 10.1.1.6/32
  RPF type: unicast (isis)
  RPF recursion count: 0
  Doing distance-preferred lookups across tables
Chengdu_P#

As you can see, the RPF check for source 10.1.1.4 (HongKong_PE) now uses interface serial 1/0, and the RPF check for source 10.1.1.6 (Shanghai_PE) now uses interface serial 1/1.

The multicast routing table is then examined using the show ip mroute command, as shown in Example 6-176.

Example 6-176. Examining the Multicast Routing Table
Chengdu_P#show ip mroute 239.0.0.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
       R  RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
       M - MSDP created entry, X - Proxy Join Timer Running
       A - Candidate for MSDP Advertisement
Outgoing interface flags: H - Hardware switched
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 239.0.0.1), 00:19:55/00:03:29, RP 10.1.1.2, flags: S
  Incoming interface: Null, RPF nbr 0.0.0.0
  Outgoing interface list:
    FastEthernet1/0, Forward/Sparse-Dense, 00:19:26/00:02:44
    Serial1/0, Forward/Sparse-Dense, 00:07:51/00:03:29
    Serial1/1, Forward/Sparse-Dense, 00:07:44/00:02:40
(10.1.1.1, 239.0.0.1), 00:19:41/00:02:58, flags: T
  Incoming interface: FastEthernet1/0, RPF nbr 10.20.10.1
  Outgoing interface list:
    Serial1/0, Forward/Sparse-Dense, 00:07:44/00:02:40
    Serial1/1, Forward/Sparse-Dense, 00:07:51/00:03:29
(10.1.1.4, 239.0.0.1), 00:08:31/00:03:25, flags: T
  Incoming interface: Serial1/0, RPF nbr 10.20.20.2
  Outgoing interface list:
    FastEthernet1/0, Forward/Sparse-Dense, 00:08:33/00:02:42
    Serial1/1, Forward/Sparse-Dense, 00:07:46/now
(10.1.1.6, 239.0.0.1), 00:08:45/00:03:28, flags: T
  Incoming interface: Serial1/1, RPF nbr 10.20.40.2
  Outgoing interface list:
    FastEthernet1/0, Forward/Sparse-Dense, 00:08:45/00:02:42
Chengdu_P#

Highlighted line 1 shows the (*, G) entry for the default MDT (239.0.0.1). In highlighted line 2, the (S, G) entry for source 10.1.1.1 (Chengdu_PE) is shown. The incoming interface is now FastEthernet1/0, and the RPF neighbor is 10.20.10.1 (Chengdu_PE). The outgoing interface list is now Serial1/1 (toward Shanghai_PE) and Serial1/0 (toward HongKong_PE).

Highlighted line 3 shows the (S, G) entry for source 10.1.1.4 (HongKong_PE). The incoming interface is Serial1/0. The RPF neighbor is 10.20.20.2 (HongKong_P). The outgoing interface list is Serial1/1 and FastEthernet1/0.

Finally, the entry for source 10.1.1.6 (Shanghai_PE) is shown in highlighted line 4. The incoming interface is Serial1/1. The RPF neighbor is 10.20.40.2 (Shanghai_P). The outgoing interface list is FastEthernet1/0.

Default MDT traffic is now being forwarded correctly across the MPLS VPN backbone, and multicast traffic from the server at site 1 is now being received by multicast receivers at sites 2 and 3.


Additional Troubleshooting Commands

This section introduces additional commands that might be useful in troubleshooting MPLS VPNs.

show ip cef vrf vrf_name detail

The show ip cef [vrf vrf_name] [prefix] detail command can be used to view detailed information about CEF FIB entries.

Example 6-177 shows the VRF mjlnet_VPN CEF FIB entry for prefix 172.16.5.0/24.

Example 6-177. show ip cef vrf vrf_name detail Command Output
Chengdu_PE#show ip cef vrf mjlnet_VPN 172.16.5.0 detail
172.16.5.0/24, version 52, epoch 0, cached adjacency 10.20.10.2
0 packets, 0 bytes
  tag information set, all rewrites owned
    local tag: VPN route head
    fast tag rewrite with Fa1/0, 10.20.10.2, tags imposed {35 16}
  via 10.1.1.4, 0 dependencies, recursive
    next hop 10.20.10.2, FastEthernet1/0 via 10.1.1.4/32 (Default)
    valid cached adjacency
    tag rewrite with Fa1/0, 10.20.10.2, tags imposed {35 16}
Chengdu_PE#

Highlighted line 1 shows the prefix itself (172.16.5.0/24), the FIB version, the epoch, and the cached adjacency for next-hop 10.20.10.2.

The epoch indicates the number of times the CEF table has been rebuilt. The epoch number starts at 0 and increments with each rebuild to a maximum of 255, at which point it loops back to 0. The clear ip cef epoch command can be used to rebuild the CEF table. This command can be used if there are inconsistencies in the CEF table.

The next-hop (10.20.10.2) cached adjacency shows that a Layer 2 header has been built and stored in the adjacency table. Note that this next-hop is the resolved (physical Layer 3) next-hop and not necessarily the next-hop of the route shown in the routing table.

Highlighted line 2 shows the next-hop for the prefix. This next-hop is the one stored in the routing table. Because this is a VPN route, this is the BGP update source of the PE router that sent the route.

Finally, highlighted line 3 shows the outgoing interface (Fast Ethernet 1/0), the resolved next-hop, and the labels to be imposed on packets being forwarded to the prefix (destination).

In this case, there is a two-label stack, with an outer IGP label (35), and an inner VPN label (16). Note that CEF is responsible for imposing a label stack on IP packets as they enter the MPLS backbone.

show adjacency detail

You can use the show adjacency detail command to examine the contents of the CEF adjacency table.

Example 6-178 shows the CEF adjacency table for Chengdu_PE.

Example 6-178. show adjacency detail Command Output
Chengdu_PE#show adjacency detail
Protocol Interface                 Address
IP       Serial4/1                 point2point(20)
                                   8138 packets, 630040 bytes
                                   FF030021
                                   CEF   expires: 00:02:18
                                         refresh: 00:00:18
                                   Epoch: 0
TAG      FastEthernet1/0           10.20.10.2(24)
                                   6467 packets, 3867274 bytes
                                   0006535AEFC0
                                   00049BD60C1C8847
                                   TFIB       02:27:03
                                   Epoch: 0
IP       FastEthernet1/0           10.20.10.2(68)
                                   0 packets, 0 bytes
                                   0006535AEFC0
                                   00049BD60C1C0800
                                   ARP        02:26:54
                                   Epoch: 0
Chengdu_PE#

Highlighted line 1 shows the adjacency table entry used for label (tag) switching packets out of interface FastEthernet1/0. The IP address of the next-hop is also shown, together with (in brackets) the number of times that this adjacency table entry is referenced by CEF FIB table entries (seen with the show ip cef command).

Highlighted line 2 shows CEF accounting statistics, including the number of packets and bytes switched.

Highlighted lines 3 and 4 show the cached Layer 2 header to be used when label switching out of interface FastEthernet1/0. Note in particular the last four hexadecimal numerals (8847). This is the Ethertype for MPLS.

Highlighted line 5 indicates that source of the adjacency table entry. In this case, CEF is interfacing to the LFIB (shown as TFIB). The time until this entry expires is also shown.

Highlighted line 6 indicates the epoch of the adjacency table (0). In highlighted line 7, the adjacency table entry used for switching IP packets out of interface FastEthernet1/0 is shown.

Note highlighted line 8 and 9. These lines show the cached Layer 2 header used when switching IP packets out of the interface. You will notice that this is the same as that shown in highlighted lines 3 and 4. The one difference is the Ethertype shown in the last four numerals (0800) in highlighted line 9. This number (0800) is the Ethertype for IP.

NOTE

The clear adjacency command can be used to clear the adjacency table. This can be used if there are inconsistencies in the adjacency table.

show mpls ldp parameters

The show mpls ldp parameters command is used to examine LDP parameters as demonstrated in Example 6-179.

Example 6-179. show mpls ldp parameters Command Output
Chengdu_PE#show mpls ldp parameters
Protocol version: 1
Downstream label generic region: min label: 16; max label: 100000
Session hold time: 180 sec; keep alive interval: 60 sec
Discovery hello: holdtime: 15 sec; interval: 5 sec
Discovery targeted hello: holdtime: 90 sec; interval: 10 sec
Downstream on Demand max hop count: 255
TDP for targeted sessions
LDP initial/maximum backoff: 15/120 sec
LDP loop detection: off
Chengdu_PE#

Highlighted line 1 shows the LDP version in use. Currently there is only one version. Highlighted line 2 shows the generic label range available for label assignment (16 to 100000). Labels 1 to 15 are reserved.

Label value 0 is "IPv4 Explicit Null," label value 1 is "Router Alert," label value 2 is "IPv6 Explicit Null," and label value 3 is "Implicit Null." Label values 4 to 15 are reserved for future use.

In highlighted line 3, the session holdtime (180 seconds) and keepalive interval (60 seconds) are shown. Note that one session is maintained between LSRs per label space. This means that one session is maintained for all the frame-mode interfaces that connect neighboring LSRs, and another session is maintained per LC-ATM interface that connect LSRs.

Highlighted line 4 shows the discovery holdtime and interval (15 and 5 seconds, respectively). These parameters are used for directly connected neighbors.

Highlighted line 5 shows the discovery parameters for neighbors that are not directly connected (90 seconds for holdtime, and 10 seconds for the hello interval).

Highlighted line 6 shows the maximum hop count for label request messages in a downstream-on-demand environment (255). If an ATM-LSR receives a label request message with this hop count, the message is dropped because it is assumed that the message is looping between adjacent LSRs. This hop count is configurable using the mpls ldp maxhops command.

Highlighted line 7 shows any configured parameters for targeted LDP sessions. Targeted sessions are those between non-directly connected neighbors.

Highlighted line 8 shows the backoff timers (initial and maximum). The backoff mechanism ensures that if two LSRs are configured with incompatible LDP parameters, they will not reattempt session establishment at a constant time interval. Instead, the time interval between session establishment attempts will gradually increase.

Finally, highlighted line 9 shows whether LDP loop detection is enabled.

show mpls atm-ldp capability

The show mpls atm-ldp capability command displays ATM (cell-mode) parameters negotiated during session initialization.

Example 6-180 shows the output of the show mpls atm-ldp capability command.

Example 6-180. show mpls atm-ldp capability Command Output
Chengdu_PE#show mpls atm-ldp capability
               VPI           VCI           Alloc   Odd/Even VC Merge
ATM3/0.1       Range         Range         Scheme  Scheme   IN   OUT
  Negotiated   [1 - 1]       [33 - 1018]   UNIDIR           -    -
  Local        [1 - 1]       [33 - 1018]   UNIDIR           NO   NO
  Peer         [1 - 1]       [33 - 1023]   UNIDIR           -    -
Chengdu_PE#

Highlighted line 2 shows the VPI (1 to 1) and VCI (33 to 1018) ranges used for label switching by the local ATM-LSR. VPI/VCI ranges must overlap between adjacent ATM-LSRs, otherwise the session will not be established. The VPI range can be modified using the mpls atm vpi command.

Highlighted line 2 also shows that the allocation scheme is unidirectional for VCIs with the same VPI value. Highlighted line 2 also shows that VC-merge is not supported in either an inbound or an outbound direction on this ATM interface.

NOTE

VC-merge is enabled by default on capable interfaces. If you want to disable it, use the no mpls ldp vc-merge command.

Highlighted line 3 shows the same information for the peer ATM-LSR. In this case, the peer is using the VPI range 1 to 1 and the VCI range 33 to 1023.

The VPI/VCI ranges negotiated between the local and peer ATM-LSRs during session initialization (1 to 1, and 33 to 1018) are shown in highlighted line 1.

show atm vc

The show atm vc command can be used to verify the control VC, together with any Label Virtual Circuits (LVCs) created on LC-ATM interfaces.

Example 6-181 shows the output of the show atm vc command.

Example 6-181. show atm vc Command Output
Chengdu_PE#show atm vc
           VCD /                                        Peak  Avg/Min Burst
Interface  Name         VPI   VCI  Type   Encaps   SC   Kbps   Kbps   Cells  Sts
3/0.1      1              0    32  PVC    SNAP     UBR  155000                UP
3/0.1      2              1    33  TVC    MUX      UBR  155000                UP
3/0.1      3              1    34  TVC    MUX      UBR  155000                UP
3/0.1      4              1    35  TVC    MUX      UBR  155000                UP
3/0.1      5              1    36  TVC    MUX      UBR  155000                UP
3/0.1      6              1    37  TVC    MUX      UBR  155000                UP
Chengdu_PE#

The control VC is shown in highlighted line 1. It uses the default VPI/VCI of 0/32. Note additionally that it uses a SNAP encapsulation.

Highlighted line 2 shows a LVC (shown as a TVC) created on the LC-ATM interface. This LVC uses VPI/VCI 1/33.

Note the four other LVCs created on the interface, each with a unique VPI/VCI. These LVCs use MUX encapsulation because they will carry only MPLS datagrams. The control VC VPI/VCI can be modified using the mpls atm control-vc command. The LVC VPI range can be modified using the mpls atm vpi command.

show ip bgp vpnv4 vrf vrf_name labels

The show ip bgp vpnv4 vrf vrf_name labels command can be used to examine the VPN labels assigned to VRF prefixes.

Example 6-182 shows the output of the show ip bgp vpnv4 vrf vrf_name labels command.

Example 6-182. show ip bgp vpnv4 vrf vrf_name labels Command Output
HongKong_PE#show ip bgp vpnv4 vrf mjlnet_VPN labels
   Network          Next Hop      In label/Out label
Route Distinguisher: 64512:100 (mjlnet_VPN)
   172.16.1.0/24    10.1.1.1        nolabel/26
   172.16.2.0/24    10.1.1.1        nolabel/27
   172.16.3.0/24    10.1.1.1        nolabel/28
   172.16.4.0/24    10.1.1.1        nolabel/29
   172.16.4.2/32    10.1.1.1        nolabel/30
   172.16.5.0/24    172.16.8.2      26/nolabel
   172.16.6.0/24    172.16.8.2      27/nolabel
   172.16.7.0/24    172.16.8.2      28/nolabel
   172.16.8.0/24    0.0.0.0         29/aggregate(mjlnet_VPN)
   172.16.8.2/32    0.0.0.0         30/nolabel
HongKong_PE#

Highlighted lines 1 to 5 show the VPN labels assigned to remote VRF prefixes. Highlighted lines 6 to 10 show VPN labels assigned to local customer VPN routes.

debug mpls ldp transport events

The LDP peer discovery mechanism can be monitored using the debug mpls ldp transport events command.

Example 6-183 shows the output of the debug mpls ldp transport events command.

Example 6-183. debug mpls ldp transport events Command Output
Chengdu_PE#debug mpls ldp transport events
LDP transport events debugging is on
Chengdu_PE#
*Jan 22 06:12:22.407 UTC: ldp: enabling ldp on Serial4/0
*Jan 22 06:12:22.407 UTC: ldp: Set intf id: intf 0x61F4BBA4, Serial4/0, not
  lc-atm, intf_id 0
*Jan 22 06:12:22.407 UTC: ldp: i/f status change: Serial4/0; cur/des flags
  0x2/0x2mcast 1
*Jan 22 06:12:22.411 UTC: ldp: Send ldp hello; Serial4/0, src/dst
  10.20.10.1/224.0.0.2, inst_id 0
*Jan 22 06:12:26.555 UTC: ldp: Send ldp hello; Serial4/0, src/dst
  10.20.10.1/224.0.0.2, inst_id 0
*Jan 22 06:12:26.695 UTC: ldp: Rcvd ldp hello; Serial4/0, from 10.20.10.2
  (10.1.1.2:0), intf_id 0, opt 0xC
*Jan 22 06:12:26.695 UTC: ldp: ldp Hello from 10.20.10.2 (10.1.1.2:0) to
  224.0.0.2, opt 0xC
*Jan 22 06:12:26.695 UTC: ldp: New adj 0x622FFB10 for 10.1.1.2:0, Serial4/0
*Jan 22 06:12:26.695 UTC: ldp:  adj_addr/xport_addr 10.20.10.2/10.1.1.2
*Jan 22 06:12:26.695 UTC: ldp: local idb = Serial4/0, holdtime = 15000, peer
  10.20.10.2 holdtime = 15000
*Jan 22 06:12:26.695 UTC: ldp: Link intvl min cnt = 2, intvl = 5000,
  idb = Serial4/0
Chengdu_PE#

In highlighted line 1, LDP is enabled on interface serial 4/0. Highlighted line 2 shows that an interface ID has been set for the interface. Note that the interface ID is 0. This indicates that this is not an LC-ATM interface.

In highlighted line 3, the interface status changes, and then in highlighted lines 4 and 5, two LDP neighbor discovery messages are sent. Notice that these messages are sent to the all routers multicast address (224.0.0.2).

In highlighted line 6, a discovery (hello) message is received from the peer LSR. When a discovery message is received on an interface, initiation of a link adjacency is allowed. In highlighted line 7, the receipt of the discovery hello message is reported, and in highlighted lines 8 and 9, the LDP adjacency with the peer is confirmed.

debug mpls ldp messages

The debug mpls ldp messages command shows LDP messages sent and received by the LSR, as demonstrated in the sample output in Example 6-184.

Example 6-184. debug mpls ldp messages Command Output
Chengdu_PE#debug mpls ldp messages sent
LDP sent PDUs, excluding periodic Keep Alives debugging is on
Chengdu_PE#
*Jan 22 06:07:06.079 UTC: ldp: Sent init msg to 10.1.1.2:0 (pp 0x0)
*Jan 22 06:07:06.083 UTC: ldp: Sent keepalive msg to 10.1.1.2:0 (pp 0x0)
*Jan 22 06:07:06.135 UTC: ldp: Sent address msg to 10.1.1.2:0 (pp 0x622AFBE0)
*Jan 22 06:07:06.139 UTC: ldp: Sent label mapping msg to 10.1.1.2:0
  (pp 0x622AFBE0)
*Jan 22 06:07:06.139 UTC: ldp: Sent label mapping msg to 10.1.1.2:0 (pp 0x622AFB
E0)
*Jan 22 06:07:06.139 UTC: ldp: Sent label mapping msg to 10.1.1.2:0 (pp 0x622AFB
E0)
Chengdu_PE#

Highlighted line 1 shows an Initialization message being sent by the local LSR neighboring LSR 10.1.1.2:0. Initialization messages are sent during session establishment and are used to negotiate common parameters such as VPI/VCI range and VC-merge capability.

In highlighted line 2, a keepalive message is sent. This keepalive is used to monitor the underlying LDP session transport connection.

An Address message is sent to LSR 10.1.1.2:0 in highlighted line 3. The Address message is used by an LSR to advertise its interface addresses to a peer.

In highlighted line 4, a Label Mapping message is sent. This is used to advertise a label binding.

debug mpls ldp advertisements

The debug mpls ldp advertisements command is used to monitor address (interface) and label bindings advertisement to peer LSRs.

CAUTION

As with all debug commands, exercise extra caution when using this command because it can produce copious output and impact device performance.

Example 6-185 shows the output of the debug mpls ldp advertisements command.

Example 6-185. debug mpls ldp advertisements Command Output
Chengdu_PE#debug mpls ldp advertisements
LDP label and address advertisements debugging is on
Chengdu_PE#
*Jan 22 06:01:53.347 UTC: tagcon: Assign peer id; 10.1.1.2:0: id 0
*Jan 22 06:01:53.347 UTC: tagcon: peer 10.1.1.2:0 (pp 0x622B0234): advertise
  10.1.1.1
*Jan 22 06:01:53.347 UTC: tagcon: peer 10.1.1.2:0 (pp 0x622B0234): advertise 10.
20.10.1
*Jan 22 06:01:53.347 UTC: tagcon: peer 10.1.1.2:0 (pp 0x622B0234): advertise 10.
1.1.1/32, label 3 (imp-null) (#2)
*Jan 22 06:01:53.351 UTC: tagcon: peer 10.1.1.2:0 (pp 0x622B0234): advertise
  10.20.10.2/32, label 16 (#4)
*Jan 22 06:01:53.351 UTC: tagcon: peer 10.1.1.2:0 (pp 0x622B0234): advertise
  10.20.10.0/24, label 3 (imp-null) (#6)
*Jan 22 06:01:53.351 UTC: tagcon: peer 10.1.1.2:0 (pp 0x622B0234): advertise
  10.20.20.2/32, label 17 (#8)
Chengdu_PE#

In highlighted line 1, Chengdu_PE advertises an interface address (10.1.1.1) to peer LSR 10.1.1.2:0.

In highlighted line 2, a binding for prefix 10.20.10.2/32 with label 16 is advertised to peer 10.1.1.2:0.

debug mpls ldp bindings

The debug mpls ldp bindings command can be used to examine addresses and bindings received from the peer LSR.

CAUTION

As with all debug commands, exercise extra caution when using this command because it can produce copious output and impact device performance.

Example 6-186 shows the output of the debug mpls ldp binding command.

Example 6-186. debug mpls ldp binding Command Output
Chengdu_PE#debug mpls ldp bindings
LDP Label Information Base (LIB) changes debugging is on
Chengdu_PE#
*Jan 22 06:16:33.571 UTC: tagcon: tibent(10.1.1.0/24): label 23 from 10.1.1.2:0
  removed
*Jan 22 06:16:33.571 UTC: tagcon: tibent(10.1.1.1/32): label 21 from 10.1.1.2:0
  removed
*Jan 22 06:16:33.571 UTC: tib: Not OK to announce label; nh 10.1.1.1 not bound
  to 10.1.1.2:0
*Jan 22 06:16:33.571 UTC: tagcon: Omit route_tag_change for: 10.1.1.1/32
        lsr 10.1.1.2:0: connected route
*Jan 22 06:16:33.571 UTC: tagcon: tibent(10.1.1.2/32): label imp-null from
  10.1.1.2:0 removed
*Jan 22 06:16:33.571 UTC: tagcon: tibent(10.1.1.3/32): label 20 from 10.1.1.2:0
  Removed
*Jan 22 06:16:33.571 UTC: tagcon: tibent(10.20.10.0/24): label imp-null from
  10.1.1.2:0 removed
*Jan 22 06:16:33.571 UTC: tagcon: tibent(10.20.10.1/32): label 16 from
  10.1.1.2:0 removed
Chengdu_PE#

Highlighted lines 1 and 2 show label bindings for prefixes 10.1.1.0/24 and 10.1.1.1/32 being removed from the LIB (shown as TIB).


show and debug Command Summary

Table 6-2 summarizes show and debug commands used to troubleshoot MPLS in this chapter. Note that where appropriate, the equivalent old-style TDP command structure is shown.

Table 6-2. show and debug Command Summary

Command

Parameter

Description

show ip cef

<none>

Displays the CEF FIB

summary

Displays a summary of the CEF FIB

vrf vrf_name detail

Shows detailed information about entries in the VRF CEF FIB

show cef

interface

Shows interface CEF information

show adjacency

detail

Displays detailed CEF adjacency table information

show atm vc

<none>

Shows all ATM PVCs, SVCs, and LVCs

show mpls (show tag-switching)

interfaces

Displays information about interfaces configured for MPLS

interfaces detail

Displays detailed information about interfaces configured for MPLS

forwarding-table

Displays the LFIB

forwarding-table prefix detail

Displays detailed information about a prefix in the LFIB

forwarding-table labels label_value

Shows LFIB entry that contains the specified local label

forwarding-table labels label_value detail

Shows detailed information about LFIB entry that contains the specified local label

show mpls ldp (show tag-switching tdp)

discovery

Shows information about LDP neighbor discovery

neighbor

Shows information about LDP sessions

bindings

Displays the LIB

parameters

Shows configured LDP parameters

show mpls atm-ldp (show tag-switching atm-tdp)

capability

Shows LDP parameters negotiated on LC-ATM interfaces

show ip vrf

interfaces

Displays information about VRF interfaces

detail vrf_name

Displays detailed information about VRF interfaces

show ip protocols

vrf vrf_name

Shows routing protocol information for a specified VRF

show ip route

vrf vrf_name

Shows the VRF routing table

show ip rip database

vrf vrf_name

Shows the RIP database for a specified VRF

show ip eigrp vrf vrf_name

interfaces

Shows EIGRP interface information for a specified VRF

neighbors

Shows EIGRP neighbor information for a specified VRF

topology

Displays the EIGRP topology table for the specified VRF

traffic

Shows EIGRP traffic information for the specified VRF

show ip bgp vpnv4 vrf vrf_name

<none>

Shows the (VPN-IPv4 address family) BGP table for the specified VRF

labels

Shows labels associated with VPN-IPv4 prefixes for a specified VRF

show ip pim mdt bgp

<none>

Shows information about MP-BGP neighbors advertising participation in MVPNs

debug mpls (debug tag-switching)

atm-ldp api (atm-tdp api)

Shows information about LVCs

ldp transport events (tdp transport events)

Shows information concerning LDP neighbor discovery

ldp messages (tdp pies sent)

Displays information concerning LDP messages sent to and from the LSR

ldp advertisements (tdp advertisements)

Shows information concerning the advertisement of labels and interface addresses

ldp bindings (tdp bindings)

Displays information about label bindings and addresses received from peer LDP LSRs


Review Questions

1: | What transport mechanism is used for neighbor discovery between directly connected LDP peers?
2: | What is the LIB?
3: | What is the LFIB?
4: | What is a VRF?
5: | How are overlapping customer address spaces disambiguated in the MPLS VPN backbone?
6: | Which BGP extended community is used to control which VPN routes are imported into VRFs?
7: | Which routing protocols can be used between Cisco CE and PE routers?
8: | What label distribution protocol is used to advertise VPN labels?
9: | What label distribution protocol is used with MPLS traffic engineering on Cisco routers?
10: | What are the default and data MDTs?


MPLS VPN Troubleshooting Practice Labs

This section provides some troubleshooting labs to help you to consolidate troubleshooting skills learned in this chapter.

The troubleshooting labs described are based on the network topology shown in Figure 6-49.

Figure 6-49. Figure 649 MPLS VPN Troubleshooting Labs Network Topology

[View full size image]

The goal of each lab is to restore IP connectivity across the MPLS VPN backbone between CE1 and CE2.

Base configurations for the labs can be found on the Cisco Press Web site (www.ciscopress.com/1587051044).

Detailed instructions for loading these base configurations onto your lab routers can be found in Appendix B.

NOTE

Note that TDP is used as the label protocol for all MPLS VPN troubleshooting labs. This is because LDP is not supported (at the time of this writing) on the 2600 platform, with the exception of the 2691.

Use tag-switching troubleshooting commands when doing the labs (see Table 6-2).

Troubleshooting Lab 1

Q1:

mjlnet_CE1 and mjlnet_CE2 have IP connectivity to Chengdu_PE and HongKong_PE, respectively, but no routes are exchanged across the MPLS VPN backbone between the CE routers.

Troubleshoot this issue, and restore end-to-end IP connectivity across the MPLS VPN backbone between mjlnet_CE1 and mjlnet_CE2.

Record symptoms, actions, and solutions in the space provided.

Symptoms:

________________________________________________________________

________________________________________________________________

________________________________________________________________

________________________________________________________________

Actions:

________________________________________________________________

________________________________________________________________

________________________________________________________________

_________________________________________________________________

Solution:

________________________________________________________________

________________________________________________________________

________________________________________________________________

________________________________________________________________

Troubleshooting Lab 2

Q1:

mjlnet_CE1 routes are being received on mjlnet_CE2, but there is still no IP connectivity between the CE routers.

Troubleshoot this issue, and restore end-to-end IP connectivity across the MPLS VPN backbone between mjlnet_CE1 and mjlnet_CE2.

Record symptoms, actions, and solutions in the space provided.

Symptoms:

________________________________________________________________

________________________________________________________________

________________________________________________________________

________________________________________________________________

Actions:

________________________________________________________________

________________________________________________________________

________________________________________________________________

________________________________________________________________

Solution:

________________________________________________________________

________________________________________________________________

________________________________________________________________

________________________________________________________________

Troubleshooting Lab 3

Q1:

Route exchange is successful between mjlnet_CE1 and mjlnet_CE2, but there is no IP connectivity between them.

Troubleshoot this issue, and restore end-to-end IP connectivity across the MPLS VPN backbone between mjlnet_CE1 and mjlnet_CE2.

Record symptoms, actions, and solutions in the space provided.

Symptoms:

________________________________________________________________

________________________________________________________________

________________________________________________________________

________________________________________________________________

Actions:

________________________________________________________________

________________________________________________________________

________________________________________________________________

________________________________________________________________

Solution:

________________________________________________________________

________________________________________________________________

________________________________________________________________

________________________________________________________________


Chapter 7. Troubleshooting Any Transport over MPLS Based VPNs

Any Transport over MPLS (AToM) is based on Internet Drafts draft-martini-l2circuit-trans-mpls and draft-martini-l2circuit-encap-mpls. AToM is a mechanism for transporting Layer 2 protocol data units (PDUs) over a multiprotocol label switching (MPLS) network. Supported Layer 2 PDU types include Ethernet, High-Level Data Link Control (HDLC), Point-to-Point Protocol (PPP), Frame Relay, and Asynchronous Transfer Mode (ATM) (AAL5 and cell relay). AToM allows the provisioning point-to-point circuits, which can then be used to construct Layer 2 VPNs.

Figure 7-1 illustrates AToM.

Figure 7-1. AToM

[View full size image]

In Figure 7-1, Frame Relay traffic is transported over the MPLS backbone between customer edge (CE) devices mjlnet_CE1 and mjlnet_CE3 via an emulated virtual circuit (pseudowire) with a virtual circuit (VC) ID of 126. Similarly, Frame Relay traffic is transported between mjlnet_CE1 and mjlnet_CE2 over a VC with VC ID 123.

Note that the label switched paths (LSPs) required for transport over the MPLS backbone are unidirectional in nature and, therefore, two LSPs are required between each pair of provider edge (PE) routers.


Technical Overview of AToM

A good understanding of AToM is essential to allow fast and efficient troubleshooting. This section, therefore, contains an examination of the operation of AToM.

Note that it is a good idea to read the section entitled "MPLS Architecture" in Chapter 6, "Troubleshooting Multiprotocol Label Switching Layer 3 VPNs," if you do not already have a good understanding of MPLS.

Layer 2 PDU Transport

Layer 2 PDUs are transported over the MPLS backbone between attachment circuits (circuits between PE and CE devices). This transportation occurs by prepending a control word, a VC label, and one or more tunnel labels (assuming PE routers are not in a back-to-back configuration) to the Layer 2 PDU itself. Figure 7-2 illustrates this transport.

Figure 7-2. AToM Layer 2 PDU Transport

The function of the tunnel label is to transport the Layer 2 PDU from the ingress PE router to the egress PE router. This label can be signaled by the Label Distribution Protocol (LDP), the Resource Reservation Protocol (RSVP, if using traffic engineering), or the Tag Distribution Protocol (TDP). Note that LDP is assumed throughout this chapter.

The VC label is a demultiplexer field and serves to identify the correct attachment circuit on the egress PE router. When a Layer 2 PDU arrives at the egress PE router, the PE router examines the VC label and forwards the Layer 2 PDU on the correct attachment circuit. Note that the VC label is locally significant on the egress PE router and is advertised to the ingress PE router using LDP.

The control word carries control information such as sequence numbering (if used), padding, and control bits. For more information, see the section "Control Word."

Finally, the Layer 2 PDU itself is carried in the payload of the packet. Information that is easily replicable by the egress PE router, such as Frame Check Sequence (FCS), is stripped off the Layer 2 PDU before transmission. The exact information that is removed, as well as the information copied into the control word, is dependent on the Layer 2 PDU type.

Figure 7-3 illustrates transport of a Layer 2 PDU (in this example, a Frame Relay PDU) across an AToM pseudowire.

Figure 7-3. Transport of a Frame Relay PDU Across an AToM Pseudowire

[View full size image]

In Figure 7-3, mjlnet_CE1 transmits a Frame Relay PDU to London_PE. London_PE prepends an optional control word, as well as VC and tunnel labels, and forwards the packet to London_P.

Note that London_PE removes extraneous information such as frame header and FCS, and copies appropriate portions of this information, such as Backward Explicit Congestion Notification (BECN) and Forward Explicit Congestion Notification (FECN) flags, into the control word.

London_P swaps the tunnel label and forwards the packet to Paris_P. Note that the VC label remains unchanged. Paris_P (being the penultimate hop) pops the tunnel label and forwards the packet to Paris_PE. Again, the VC label remains unchanged.

Finally, Paris_PE removes the VC label, reconstitutes any information removed by London_PE, and forwards the Frame Relay PDU on the attachment circuit to mjlnet_CE2.

Control Word

As previously mentioned, a control word can be carried as an option when Layer 2 PDUs are transported across the MPLS backbone. Figure 7-4 shows the control word format.

Figure 7-4. Control Word Format

[View full size image]

The contents of the control word are as follows:

  • The first four bits in the control word are reserved (Rsvd) and must be set to zero.

  • The 4-bit Flags field contains information specific to the Layer 2 protocol being transported.

  • Following the Flags are two bits that must be set to zero.

  • Next is the 6-bit Length field. If the length of the control word itself plus the Layer 2 PDU payload is less than 64 bytes, this field is set to the length of the packet. If the length of the control word plus the Layer 2 PDU payload is equal to or greater than 64 bytes, this field is set to zero. The function of this field is to allow the egress PE router to remove any padding.

  • The final field is the Sequence Number field. This can be used to carry sequence numbering that can allow the egress PE router to ensure ordered packet delivery.

Frame Relay Control Word

Frame Relay PDUs are transported over the AToM pseudowire without their header and FCS. The control word is, therefore, required.

The control word used when transporting Frame Relay PDUs takes the form shown in Figure 7-5.

Figure 7-5. Frame Relay Control Word

The Flags field consists of a B (BECN) bit, an F (FECN) bit, a D (Discard Eligible, DE) bit, and a C (Command/Response, C/R) bit.

The ingress PE router can copy the BECN, FECN, DE, and C/R bit settings from the header of the Frame Relay PDU received on the attachment circuit into the control word when transmitting the Frame Relay PDU across the pseudowire.

The egress PE router copies the BECN, FECN, DE, and C/R bit settings from the control word back into the reconstructed Frame Relay header as it transmits the Frame Relay PDU out onto the attachment circuit.

ATM AAL5 CPCS-SDU Control Word

If ATM AAL5 is being used, the ingress PE router reassembles the Common Part Convergence Sublayer-Service Data Units (CPCS-SDUs) received on the attachment circuit. Each CPCS-SDU is then transported over the AToM pseudowire as a single packet, without the AAL5 trailer.

The control word is required and takes the form shown in Figure 7-6.

Figure 7-6. ATM AAL5 CPCS-SDU Control Word

The Flags field now consists of the following bits:

  • The T (transport type) bit is used to indicate whether the packet contains an ATM cell (1) or AAL5 CPCS-SDU (0). Transport of individual ATM cells can be used to enable Operations, Administration, and Maintenance (OAM) over the AAL5 VC.

  • The E (Explicit Forward Congestion Indication, EFCI) bit is set by the ingress PE router if the EFCI bit is set in the final cell of the AAL5 CPCS-SDU, or if the EFCI bit is set in any single ATM cell sent over the pseudowire.

  • The L (Cell Loss Priority, CLP) bit is set if the CLP bit is set in any of the cells that make up the AAL5 CPCS-SDU, or in any single cell sent over the pseudowire.

  • The C (Command / Response) bit may contain the C/R bit when transporting FRF 8.1 (Frame Relay/ATM service internetworking) traffic over the pseudowire.

ATM Cell Relay, Ethernet, HDLC, and PPP Control Words

If ATM cell relay (individual ATM cells), Ethernet, HDLC, or PPP PDUs are being transported, the control may be carried, but all four bits in the control word Flags field are set to zero.

Note that when transporting ATM cells with cell-relay, the entire cell consisting of the 4-byte header and 48-byte payload is transported.

If Ethernet frames are being transported, the entire frame is transmitted, with the exception of the preamble and the FCS. Cisco HDLC frames are transported in their entirety with the exception of the flags (7E) and FCS fields, which are removed. PPP frames are transported in their entirety, with the exception of the flags (7E), HDLC Address, Control, and FCS fields. These are removed.

VC Label Exchange

Before VC labels can be exchanged between peer PE routers, LDP discovery and session establishment must take place.

LDP Discovery

LDP discovery consists of an exchange of hello messages and allows Label Switch Routers (LSRs) to discover each other, forming a hello adjacency. Discovery must be successfully completed before session establishment can begin.

LDP offers two discovery modes:

  • Basic discovery This mode is used between directly connected peers.

  • Extended discovery Extended discovery is used between non-directly connected peers. Peer PE routers use extended discovery. Figure 7-7 illustrates the extended discovery mode.

    Figure 7-7. LDP Extended Discovery

    [View full size image]

    Note that LDP extended discovery, unlike basic discovery, is asymmetric and uses targeted hello messages with unicast transmission on UDP port 646.

    In Figure 7-7, the LDP discovery takes place between interface loopback 0 (the LDP IDs) of London_PE and Paris_PE.

Note that LDP discovery (and session establishment) between PE routers is initiated on Cisco routers when the xconnect command is configured.

LDP Session Establishment

Once LDP discovery has been successful, session establishment can begin.

Session establishment is a two-stage process:

  1. Transport connection establishment A transport connection is initiated by the peer with the higher address (the active peer) to the peer with the lower address (the passive peer), using TCP (destination) port 646.

  2. Session initialization The session is then initialized, and parameters such as LDP version and method of label distribution are negotiated.

Note that the method of label distribution used by AToM PE routers is unsolicited downstream.

Figure 7-8 illustrates an LDP session.

Figure 7-8. LDP Session

[View full size image]

Label Mapping Messages

Once peer PE routers have established an LDP session, they can exchange VC label bindings.

VC labels are assigned to local attachment circuits, and the bindings are advertised to the peer (ingress) PE router in an LDP Label Mapping message.

The VC label binding consists of the VC label itself and associated VC information. This VC information is carried within the Label Mapping message using a new type (type 128) of Forwarding Equivalence Class (FEC) element, which is defined in Internet draft draft-martini-l2circuit-trans-mpls.

Figure 7-9 shows the VC FEC element.

Figure 7-9. VC FEC Element

The contents of the VC FEC element depicted in Figure 7-9 are as follows:

  • The first 8-bit field indicates the FEC element type itself. In this case, it is the VC TLV (Type, Length, Value) type, so a value of 128 is contained in this field.

  • The C bit, if set to 1, signals the presence of the control word in packets sent across the pseudowire (see Figure 7-2).

  • The VC Type is a 15-bit field that, appropriately, indicates the VC type.

    Table 7-1 shows the possible VC types.

    Table 7-1. Possible VC Types

    VC Type

    Description

    0x0001

    Frame Relay DLCI

    0x0002

    ATM AAL5 VCC (virtual channel connection) transport

    0x0003

    ATM transparent cell transport

    0x0004

    Ethernet VLAN

    0x0005

    Ethernet

    0x0006

    HDLC

    0x0007

    PPP

    0x8008

    CEM (circuit emulation)

    0x0009

    ATM VCC cell transport

    0x000A

    ATM VPC (virtual path connection) cell transport

  • Next is the 8-bit VC info Length field. This indicates the length of the VC ID and interface parameters fields in octets.

  • The 32-bit Group ID field is a port or virtual tunnel index and can be used to group VCs associated with the same interface.

    The Group ID field can be used to withdraw the labels associated with a number of VCs at the same time.

  • The 32-bit VC ID field is a globally unique (between PE routers) value that, together with VC type, uniquely identifies a virtual circuit. Note that the VC ID must be a nonzero value.

  • The variable length Interface Parameters field is used to specify parameters associated with the attachment circuit interface.

    Figure 7-10 shows the Interface Parameters field.

    Figure 7-10. Interface Parameters Field

The contents of the Interface Parameters field are as follows:

- The 8-bit Parameter ID field is used to specify the interface parameter type.

Table 7-2 shows the possible Parameter ID values.

Table 7-2. Parameter ID values

Parameter

ID Length

Description

0x01

4

Interface MTU in octets

0x02

4

Maximum number of concatenated ATM cells

0x03

up to 82

Optional interface description string

0x04

4

CEM payload bytes

0x05

4

CEM options

- The Length field specifies the length of the interface parameter starting from the Parameter ID field.

- The parameter value itself is contained in the Variable Length Value field.

Note that VC labels are assigned and advertised to peer PE routers when the local attachment circuit changes state to up.

Figure 7-11 illustrates VC label bindings exchange.

Figure 7-11. VC Label Bindings Exchange

[View full size image]

Label Withdraw Messages

If the attachment circuit changes state to down, or there is another service affecting condition, the ingress PE router signals this to its peer using an LDP Label Withdraw message.

The egress PE router receiving a Label Withdraw message can signal the circuit down state to its attached customer device. If the circuit type is Frame Relay, for example, the circuit state may be signaled to the CE device using the Local Management Interface (LMI).

Figure 7-12 illustrates transmission of the Label Withdraw message.

Figure 7-12. Transmission of the Label Withdraw Message

[View full size image]


Configuring AToM

Simple misconfiguration is a common cause of issues with AToM, so this section focuses on configuration of PE routers in an AToM environment. Configuration of provider (P) routers is identical to that discussed in the section "Configuring the P Router" in Chapter 6.

Note that it may be useful to reference Figure 7-14 as you read this section, although not all attachment circuit types are illustrated.

Figure 7-14. AToM Reference Topology

[View full size image]

Configuration of the PE routers consists of seven steps:

Step 1. | Configure the loopback interface to be used as the LDP router ID.
Step 2. | Enable Cisco Express Forwarding (CEF).
Step 3. | Configure the label protocol.
Step 4. | Configure the LDP router ID (recommended).
Step 5. | Configure MPLS on core interfaces.
Step 6. | Configure the MPLS backbone IGP if not already configured.
Step 7. | Configure the AToM pseudowires.

The sections that follow provide detailed information on each of these steps.

Step 1: Configure the Loopback Interface to Be Used as the LDP Router ID

Example 7-1 shows the configuration of the loopback interface is shown in Example 7-1.

Example 7-1. Configuration of the Loopback Interface
interface Loopback0
 ip address 172.16.1.1 255.255.255.255

Note that the IP address configured on the loopback interface should have a 32-bit mask; otherwise, AToM may not function correctly.

Step 2: Enable CEF

CEF must be enabled on the PE router or MPLS will not function.

Example 7-2 shows the configuration of CEF.

Example 7-2. Configuration of CEF
ip cef [distributed]

The distributed keyword shown in Example 7-2 is used to enable distributed CEF (dCEF). Distributed CEF is available on high-end platforms such as the 7500 and 12000 series routers.

Step 3: Specify LDP as the Label Protocol

LDP should now be specified as the label protocol as demonstrated in Example 7-3.

Example 7-3. LDP Is Specified as the Label Distribution Protocol
mpls label protocol ldp

In Example 7-3, the mpls label protocol ldp command specifies LDP as the label distribution protocol.

Step 4: Configure the LDP Router ID

Once LDP has been specified as the label protocol, the next recommended step is to configure the LDP router ID.

Example 7-4 shows the configuration of the LDP router ID.

Example 7-4. Configuration of the LDP Router ID
mpls ldp router-id Loopback0 force

In Example 7-4, the loopback interface address configured in Step 1 is specified as the LDP router ID. The force keyword ensures that it becomes the LDP router ID.

Step 5: Configure MPLS on Core Interfaces

The mpls ip command is used to enable MPLS on core (frame mode) interfaces, as demonstrated in Example 7-5.

Example 7-5. Configuration of MPLS on Core (Frame Mode) Interfaces
interface FastEthernet2/0
 mpls ip

If LSRs are connected via an ATM PVC, the interface should be configured as shown in Example 7-6.

Example 7-6. Configuration of MPLS over an ATM PVC (Frame Mode)
interface ATM3/0.1 point-to-point
 ip address 172.16.7.1 255.255.255.0
 pvc 1/50
  encapsulation aal5snap
 !
 mpls ip

MPLS is enabled on an ATM PVC with VPI/VCI 1/50 in Example 7-6. Note that the subinterface type is point-to-point.

If LSRs are connected via label switching controlled ATM (LC-ATM) interfaces, then the interface configuration is as shown in Example 7-7.

Example 7-7. Configuration of an LC-ATM Interface (Cell Mode)
interface ATM3/0.1 mpls
 ip address 172.16.7.1 255.255.255.0
 mpls ip

As you can see, the subinterface type specified in Example 7-7 is mpls. Note that the mpls ip command is also configured on the interface itself.

Step 6: Configure the MPLS Backbone IGP

The MPLS backbone Interior Gateway Protocol (IGP) should now be configured.

The two most commonly used IGPs within the MPLS backbone are Intermediate System-to-Intermediate System (IS-IS) and Open Shortest Path First (OSPF). These are often used because they are currently the only two IGPs that support MPLS traffic engineering. This section contains sample configurations for both IS-IS and OSPF.

Configuring IS-IS as the MPLS Backbone IGP

Example 7-8 shows configuration of IS-IS for IP reachability across the MPLS backbone.

Example 7-8. Configuration of IS-IS for IP Reachability
router isis
 passive-interface Loopback0
 net 49.0001.0000.0000.0001.00
 is-type level-2-only
 metric-style wide

The router isis command enables IS-IS on the PE router.

Interface loopback 0 (configured in Step 1) is then enabled for IS-IS using the passive-interface loopback0 command.

Make sure that the loopback interface used as the LDP router ID is enabled for IS-IS using the passive-interface command. If the loopback interface is not advertised in IS-IS, LDP discovery and session establishment will fail. Note that some versions of IOS also require you to configure the ip router isis command on the loopback interface in addition to specifying the passive interface command

The net 49.0001.0000.0000.0001.00 command is used to configure the network entity title (NET). This consists of the area ID (49.0001), the system ID (0000.0000.0001), and the selector (00).

The is-type level-2-only command configures the PE router as a backbone router.

Finally, the PE router is configured to support 24- or 32-bit metrics using the metric-style wide command. Wide metrics are required if you are using MPLS traffic engineering within the backbone.

After globally enabling IS-IS on the PE router, the next step is to configure IS-IS on core interfaces using the ip router isis command, as demonstrated in Example 7-9.

Example 7-9. Configuration of IS-IS on Core Interfaces
interface FastEthernet2/0
 ip router isis

In Example 7-9, IS-IS is enabled on core interface fast Ethernet 2/0 using the ip router isis command.

Configuring OSPF as the MPLS Backbone IGP

As previously mentioned, the other IGP that is commonly used within an MPLS backbone is OSPF.

Example 7-10 shows configuration of OSPF for IP reachability within the MPLS backbone.

Example 7-10. Configuration of OSPF for IP Reachability
router ospf 100
 passive-interface Loopback0
 network 172.16.0.0 0.0.255.255 area 0

The router ospf 100 command enables OSPF process 100 on the PE router.

The passive-interface loopback0 command is used to ensure that OSPF packets are not transmitted on interface loopback 0.

Finally, interface loopback 0, together with core facing interfaces (in this case, fast Ethernet 2/0) are placed in area 0 using the network 172.16.0.0 0.0.255.255 area 0 command.

Step 7: Configure the AToM Pseudowires

The next step is to configure the AToM pseudowires. Configuration depends on the encapsulation type used on the attachment circuits.

Configuration for Ethernet, HDLC, PPP, ATM (AAL5 and cell relay), and Frame Relay encapsulation types is detailed in the sections that follow.

When configuring an AToM pseudowire, ensure that the VC ID is the same on both PE routers.

Ethernet Encapsulation

There are two modes of transport for Ethernet PDUs over an AToM pseudowire:

  • Port mode The entire Ethernet frame (minus the preamble and FCS) is transported over the pseudowire.

  • VLAN (802.1Q) mode Traffic from an 802.1q VLAN is transported over the pseudowire.

Ethernet Port Mode

An Ethernet port mode attachment circuit should be configured as shown in Example 7-11.

Example 7-11. Configuration of an Ethernet Port Mode Attachment Circuit
interface FastEthernet0/0
 xconnect 172.16.1.4 121 encapsulation mpls

In Example 7-11, interface fast Ethernet 0/0 is bound to the pseudowire with VCID 121 to peer PE router 172.16.1.4 using the xconnect peer_LDP_router_id VCID encapsulation mpls command.

Ethernet VLAN (802.1Q) Mode

If the encapsulation type used on the attachment circuit is Ethernet VLAN (802.1q), configuration is as shown in Example 7-12.

Example 7-12. Configuration of an Ethernet VLAN Mode (802.1Q) Attachment Circuit
interface FastEthernet1/0
!
interface FastEthernet1/0.1
 encapsulation dot1Q 10
 xconnect 172.16.1.4 121 encapsulation mpls

In highlighted line 1, 802.1Q encapsulation for VLAN ID 10 is configured on interface fast Ethernet 1/0.1 using the encapsulation dot1q vlan_id command.

The xconnect peer_LDP_router_id VCID encapsulation mpls command is then used to bind interface fast Ethernet 1/0.1 to the AToM pseudowire to peer PE router 172.16.1.4 with VC ID 121.

Frame Relay Encapsulation

A pseudowire used to transport Frame Relay can be configured in two ways:

  • A DLCI-to-DLCI connection When a DLCI-to-DLCI connection is used, the PE router functions as a Frame Relay switch and participates in LMI.

  • A port-to-port connection When a port-to-port connection is used, Frame Relay frames are simply transported transparently over the pseudowire. In this case, the PE router does not participate in LMI.

Frame Relay DLCI-to-DLCI Connections

Example 7-13 shows the configuration of a DLCI-to-DLCI connection.

Example 7-13. Configuration of a DLCI-to-DLCI Connection
frame-relay switching
interface Serial4/0
 encapsulation frame-relay
 frame-relay intf-type dce

The frame-relay switching global configuration mode command is used to enable Frame Relay permanent virtual circuit (PVC) switching.

The encapsulation frame-relay [ietf] command is used to configure Frame Relay encapsulation on the attachment circuit interface. Note that the default encapsulation type is Cisco, and the ietf keyword enables IETF RFC 1490 encapsulation.

The interface type is then configured using the frame-relay intf-type [dce | dte | nni] command. In this case, the interface type is User-to-Network Interface (UNI) data circuit-terminating equipment (DCE). The dte and nni keywords can be used to configure the interface as UNI data terminal equipment (DTE) and Network-to-Network Interface, respectively.

The next step is to bind the attachment circuit to the pseudowire, as shown in Example 7-14.

Example 7-14. Binding the PVC to the Pseudowire
connect PVCtoParis Serial4/0 50 l2transport
 xconnect 172.16.1.4 123 encapsulation mpls

The connect connection_name interface dlci l2transport command is used to specify a locally significant connection name, attachment circuit interface, and DLCI.

The xconnect peer_LDP_router_ID VCID encapsulation mpls command is then used to bind the PVC to the specified VC and peer PE router address. In Example 7-14, DLCI 50 (on interface serial 4/0) is bound to a pseudowire with VC ID 123 to peer 172.16.1.4.

It worth noting that it is possible to use Cisco encapsulation at one end and IETF encapsulation at the other end of the same pseudowire. Similarly, different LMI types (Cisco/ANSI/Q933a) may be used at either end of the same pseudowire.

Frame Relay Port-to-Port Connections

Example 7-15 shows the configuration of a Frame Relay port-to-port connection.

Example 7-15. Configuration of a Frame Relay Port-to-Port Connection
interface Serial4/2
 xconnect 172.16.1.4 125 encapsulation mpls

In Example 7-15, interface serial 4/2 is bound to a pseudowire with VC ID 125 to peer PE router 172.16.1.4. Note that the encapsulation type specified on interface serial 4/2 is HDLC (the default) and not Frame Relay.

AAL5 Encapsulation

Example 7-16 shows the configuration of AAL5 over MPLS.

Example 7-16. Configuration of AAL5 over MPLS
interface ATM3/0
 no ip address
 no ip directed-broadcast
 no atm enable-ilmi-trap
 no atm ilmi-keepalive
!
interface ATM3/0.1 point-to-point
 no ip directed-broadcast
 no atm enable-ilmi-trap
 pvc 1/50 l2transport
  encapsulation aal5
  xconnect 172.16.1.4 122 encapsulation mpls

The pvc vpi/vci l2transport command indicates that the PVC with the specified virtual path indicator (VPI) and virtual circuit indicator (VCI) will be bound to a pseudowire.

The encapsulation aal5 command configures AAL5 encapsulation for the interface.

Finally, the xconnect peer_LDP_router_ID VCID encapsulation mpls command binds the PVC to the pseudowire with the specified VC ID to the peer PE router.

In Example 7-16, the PVC with VCI/VPI 1/50 is bound to the pseudowire with VC ID 122 to peer PE router 172.16.1.4.

ATM Cell Relay

ATM cell relay can be configured in various modes:

  • Virtual circuit (VC) mode

  • Virtual path (VP) mode

  • Port mode

It is also possible to configure single cell relay, in which one ATM cell is transported in each MPLS packet, and packed (concatenated) cell relay, in which multiple cells are transported in each MPLS packet.

ATM Cell Relay: VC Mode

In VC mode, cell relay is configured for a PVC. Example 7-17 shows a sample configuration on a point-to-point subinterface.

Example 7-17. Configuration of ATM Cell Relay: VC Mode
interface ATM3/0
 no ip address
 no ip directed-broadcast
 atm mcpt-timers 250 500 750
 no atm enable-ilmi-trap
 no atm ilmi-keepalive
!
interface ATM3/0.1 point-to-point
 no ip directed-broadcast
 no atm enable-ilmi-trap
 pvc 1/50 l2transport
  encapsulation aal0
  cell-packing 10 mcpt-timer 1
  xconnect 172.16.1.4 122 encapsulation mpls

In highlighted line 2, the pvc vpi/vci l2transport command is used to indicate that the PVC with the specified VPI/VCI will be bound to a pseudowire.

The encapsulation aal0 command in highlighted line 3 is then used to specify ATM adaptation layer 0 (AAL0) (cell relay).

The xconnect peer_LDP_router_id vcid encapsulation mpls command in highlighted line 5 is used to bind the interface to the pseudowire with VC ID 122 to peer PE router 172.16.1.4.

Note also the optional commands in highlighted lines 1 and 4: atm mcpt-timers 250 500 750 and cell-packing 10 mcpt-timer 1. These two commands are used to enable cell packing (single cell relay is used by default).

The atm mcpt-timers timer1-timeout1 timer2-timeout2 timer3-timeout3 command is used to specify maximum cell packing timeouts (MCPT), which control how long the PE router waits for ATM cells on the attachment circuit before packing them into an MPLS packet and transmitting the packet across the backbone. In this example, timeouts of 250, 500, and 750 microseconds are specified.

The cell-packing cells mcpt-timer timer command is used to enable cell packing and specify the maximum number of cells that the router will in pack into an MPLS packet, as well as the MCPT to use. In this example, a maximum of 10 cells and an MCPT of 1 (250 microseconds) are specified.

Note that if the timer specified using the cell-packing cells mcpt-timer timer command is reached before the maximum number of cells has arrived, the packet is transmitted without waiting for more cells.

ATM Cell Relay: VP Mode

If you configure VP mode, cell relay is enabled for a permanent virtual path (PVP), as demonstrated in Example 7-18.

Example 7-18. Configuration of ATM Cell Relay: VP Mode
interface ATM3/0
 no ip address
 no ip directed-broadcast
 atm mcpt-timers 250 500 750
 atm pvp 10 l2transport
  cell-packing 10 mcpt-timer 1
  xconnect 172.16.1.4 122 encapsulation mpls

The atm pvp vpi l2transport command in highlighted line 2 is used to indicate that the PVP with the specified VPI will be bound to a pseudowire.

In highlighted line 4, the xconnect peer_LDP_router_id vcid encapsulation mpls command is used to bind the PVP to a pseudowire with VC ID 122 to peer PE router 172.16.1.4.

Again, the optional atm mcpt-timers timer1-timeout1 timer2-timeout2 timer3-timeout3 and cell-packing cells mcpt-timer timer commands in highlighted lines 1 and 3 are used to configure MCPT timers and enable cell packing. Note that cell packing is currently supported for only VC and VP mode cell relay.

ATM Cell Relay: Port Mode

Port mode, currently supported on only 12000 series routers, allows a single ATM cell arriving on the main ATM interface to be packed into an MPLS packet.

Example 7-19 demonstrates configuration for port mode.

Example 7-19. Configuration of ATM Cell Relay: Port Mode
interface ATM3/0
 xconnect 172.16.1.4 122 encapsulation mpls

In Example 7-19, the xconnect peer_LDP_router_id vcid encapsulation mpls command is used to bind the ATM interface to a pseudowire with VCID 122 to peer 172.16.1.4.

HDLC Encapsulation

Example 7-20 shows the configuration of HDLC over MPLS.

Example 7-20. Configuration of HDLC over MPLS
interface Serial4/1
 xconnect 172.16.1.4 124 encapsulation mpls

In Example 7-20, the xconnect peer_LDP_router_id vcid encapsulation mpls command is used to bind interface serial 4/1 to a pseudowire with VC ID 124 to peer PE router 172.16.1.4.

Note that HDLC is the default encapsulation type, so the command encapsulation hdlc is not shown in Example 7-20.

PPP Encapsulation

Example 7-21 shows configuration of PPP over MPLS.

Example 7-21. Configuration of PPP over MPLS
interface Serial4/2
 encapsulation ppp
 xconnect 172.16.1.4 125 encapsulation mpls

The encapsulation ppp command is used to configure PPP encapsulation on interface serial 4/2.

The xconnect peer_LDP_router_id vcid encapsulation mpls command is then used to bind the interface to a pseudowire with VC ID 125 to peer PE router 172.16.1.4.

That concludes the configuration of the PE router.

Complete Sample Configurations for AToM PE Routers

Example 7-22 shows complete sample configurations for peer PE routers London_PE and Paris_PE.

Example 7-22. Sample AToM PE Router Configurations
! London_PE:
London_PE#show running-config
Building configuration...
Current configuration : 2249 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
!
hostname London_PE
!
logging buffered 16384 debugging
no logging console
enable secret 5 $1$roOI$Lgw4QtRnK/93LeNAkJYAi0
!
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 label protocol (LDP)
mpls label protocol ldp
no mpls traffic-eng auto-bw timers frequency 0
!
! Configure the LDP router ID (= mpls ldp router-id Loopback0 force)
tag-switching tdp router-id Loopback0 force
!
! Configure the loopback interface
interface Loopback0
 ip address 172.16.1.1 255.255.255.255
 no ip directed-broadcast
!
interface FastEthernet1/0
 no ip address
 no ip directed-broadcast
!
! Configure a VLAN (802.1q) attachment circuit (and pseudowire to Paris_PE)
interface FastEthernet1/0.1
 encapsulation dot1Q 10
 no ip directed-broadcast
 xconnect 172.16.1.4 121 encapsulation mpls
 no cdp enable
!
! Configure MPLS on core interfaces (tag-switching ip = mpls ip)
interface FastEthernet2/0
 ip address 172.16.2.1 255.255.255.0
 no ip redirects
 no ip directed-broadcast
 no ip proxy-arp
 ip router isis
 tag-switching ip
 no cdp enable
!
! Configure Frame-Relay DLCI-to-DLCI switching
interface Serial4/0
 no ip address
 no ip directed-broadcast
 encapsulation frame-relay
 no ip mroute-cache
 no fair-queue
 frame-relay intf-type dce
!
! Configure an HDLC pseudowire to Paris_PE
interface Serial4/1
 no ip address
 no ip directed-broadcast
 xconnect 172.16.1.4 124 encapsulation mpls
 no cdp enable
!
!
! Configure the MPLS backbone IGP
router isis
 passive-interface Loopback0
 net 49.0001.0000.0000.0001.00
 is-type level-2-only
 metric-style wide
!
ip classless
!
logging trap debugging
!
! Bind DLCI 50 to a pseudowire (to Paris_PE)
connect PVCtoParis Serial4/0 50 l2transport
 xconnect 172.16.1.4 123 encapsulation mpls
 !
line con 0
 exec-timeout 0 0
 password 7 01100F175804
 login
line aux 0
line vty 0 4
 password 7 094F471A1A0A
 login
!
end
________________________________________________________________
! Paris_PE:
Paris_PE#show running-config
Building configuration...

Current configuration : 1893 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
!
hostname Paris_PE
!
logging buffered 16384 debugging
no logging console
enable secret 5 $1$KwQz$V6quL3xhdKp7yUNosh2/7/
!
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 label protocol (LDP)
mpls label protocol ldp
no mpls traffic-eng auto-bw timers frequency 0
!
! Configure the LDP router ID (= mpls ldp router-id Loopback0 force)
tag-switching tdp router-id Loopback0 force
!
! Configure the loopback interface
interface Loopback0
 ip address 172.16.1.4 255.255.255.255
 no ip directed-broadcast
!
interface FastEthernet0/0
 no ip address
 no ip directed-broadcast
!
! Configure a VLAN (802.1q) attachment circuit (and pseudowire to London_PE)
interface FastEthernet0/0.1
 encapsulation dot1Q 10
 no ip directed-broadcast
 no cdp enable
 xconnect 172.16.1.1 121 encapsulation mpls
!
! Configure MPLS on core interfaces (tag-switching ip = mpls ip)
interface FastEthernet1/0
 ip address 172.16.4.2 255.255.255.0
 no ip redirects
 no ip directed-broadcast
 no ip proxy-arp
 ip router isis
 tag-switching ip
 no cdp enable
!
! Configure Frame-Relay DLCI-to-DLCI switching
interface Serial2/0
 no ip address
 no ip directed-broadcast
 encapsulation frame-relay
 no ip mroute-cache
 no fair-queue
 frame-relay intf-type dce
!
! Configure an HDLC pseudowire to London_PE
interface Serial2/2
 no ip address
 no ip directed-broadcast
 no cdp enable
 xconnect 172.16.1.1 124 encapsulation mpls
!
! Configure the MPLS backbone IGP
router isis
 net 49.0001.0000.0000.0004.00
 is-type level-2-only
 metric-style wide
 passive-interface Loopback0
!
ip classless
!
! Bind DLCI 60 to a pseudowire (to London_PE)
connect PVCtoBank Serial2/0 60 l2transport
 xconnect 172.16.1.1 123 encapsulation mpls
 !
!
line con 0
 exec-timeout 0 0
 password 7 030752180500
 login
line aux 0
Sline vty 0 4
 privilege level 15
 password 7 121A0C041104
 login
!
end

In Example 7-22, three pseudowires are configured between peer PE routers London_PE (172.16.1.1) and Paris_PE (172.16.1.4):

  • One Ethernet VLAN (802.1Q) pseudowire

  • One Frame Relay DLCI-to-DLCI pseudowire

  • One HDLC pseudowire

Note that some commands discussed in this section, such as mpls ip, are not readily apparent in the configurations shown in Example 7-22. This is because the mpls keyword is translated into the tag-switching keyword for backward compatibility with Cisco IOS versions that do not support the mpls keyword.

Maximum Transmission Unit Issues

When configuring AToM, it is important to be aware of possible maximum transmission unit (MTU) issues.

If the size of packets transmitted over the AToM pseudowire (see Figure 7-2) is larger than the MPLS MTU of any of the links between PE routers across the MPLS backbone, then these packets will be dropped.

In this scenario, large packets are not being successfully transmitted across the HDLC pseudowire from router cisco_CE1 to cisco_CE2 (see Figure 7-14). The output of the extended ping in Example 7-23 illustrates the transmission failure of large packets across the pseudowire.

Example 7-23. Large Packets Are Not Successfully Transmitted Across the Pseudowire
cisco_CE1#ping
Protocol [ip]:
Target IP address: 192.168.1.2
Repeat count [5]:
Datagram size [100]: 1500
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 1500-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
cisco_CE1#

In Example 7-23, a 1500 byte ping is sent from router cisco_CE1 to cisco_CE2 (192.168.1.2). As highlighted line 3 shows, the ping is not successful.

The output of the debug mpls l2transport packet error command in Example 7-24 reveals the problem.

NOTE

Note that you should take extra care when using the debug mpls l2transport packet error command because it can produce copious output.

Example 7-24. debug mpls l2transport packet error Command Output
London_PE#debug mpls l2transport packet error
AToM packet errors debugging is on
London_PE#
*Jan 26 19:28:18.507 UTC: ATOM-HDLC imposition: in Se4/1, circuit id 7,
  size 1508, packet dropped, output MTU exceeded
*Jan 26 19:28:20.507 UTC: ATOM-HDLC imposition: in Se4/1, circuit id 7,
  size 1508, packet dropped, output MTU exceeded
London_PE#

In highlighted lines 1 and 2, you can see that the ping packets received by London_PE from cisco_CE1 are being dropped as they are switched across the HDLC pseudowire to Paris_PE. This is because the AToM packet size (1508 bytes) exceeds the output MTU (the MTU of interface Fast Ethernet 2/0 on London_PE). Note that the AToM packet size shown here excludes the tunnel and VC labels.

The MPLS MTU on interface Fast Ethernet is then verified using the show mpls interfaces interface detail command, as demonstrated in Example 7-25.

Example 7-25. Verifying the MTU on Interface Fast Ethernet 2/0
London_PE#show mpls interfaces FastEthernet 2/0 detail
Interface FastEthernet2/0:
        IP labeling enabled (ldp)
        LSP Tunnel labeling not enabled
        BGP labeling not enabled
        MPLS operational
        Optimum Switching Vectors:
          IP to MPLS Turbo Vector
          MPLS Turbo Vector
        Fast Switching Vectors:
          IP to MPLS Fast Switching Vector
          MPLS Turbo Vector
        MTU = 1500
London_PE#

As you can see, the MPLS MTU is 1500 bytes on interface Fast Ethernet 2/0. Far too small!

To ensure that large packets are not dropped, make sure that the MPLS MTU is correctly configured on P and core facing PE router interfaces.

The MPLS MTU on core (backbone) links should be greater than or equal to the following:

label stack (number of labels * 4 bytes)

+ control word (4 bytes)

+ Layer 2 PDU (MTU of attachment circuit + attachment circuit Layer 2 header)

You can verify the presence of the control word (cbit=0 when it is not present, and cbit=1 when it is) on a pseudowire (VC), as well as the attachment circuit MTU using the show mpls l2transport binding command. See the section entitled "Other AToM Troubleshooting Commands" toward the end of this chapter for more information on this command.

If you are transporting HDLC PDUs (attachment circuit MTU of 1500 bytes and attachment circuit Layer 2 header of 4 bytes), and the label stack consists of two labels (each of 4 bytes), the required backbone MTU between the PE routers is as follows:

8 (label stack1 tunnel label + VC label)

+ 4 (control word)

+ 1504 (Layer 2 PDU1500 byte attachment circuit MTU + 4 byte HDLC header)

= 1516 bytes

This MTU (or greater) should be configured on all P and PE core interfaces, using the mtu bytes or mpls mtu bytes command, as shown in Example 7-26. The mpls mtu bytes command is required for some interface types. In fact, the MTU configured on core interfaces should accommodate all pseudowires between PE routers. Although in this example, only the HDLC pseudowire is being considered, in reality, you would also have to consider the Ethernet VLAN and Frame Relay DLCI to DLCI pseudowires between London_PE and Paris_PE.

Example 7-26. Adjusting the MPLS MTU on London_PE, Interface Fast Ethernet 2/0
London_PE#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
London_PE(config)#interface FastEthernet 2/0
London_PE(config-if)#mpls mtu 1516
London_PE(config-if)#end
London_PE#

Example 7-27 shows that once the MPLS MTU has been modified, large packets are successfully transmitted across the HDLC pseudowire.

Example 7-27. Large Packets Are Now Successfully Transmitted Across the HDLC Pseudowire
cisco_CE1#ping
Protocol [ip]:
Target IP address: 192.168.1.2
Repeat count [5]:
Datagram size [100]: 1500
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 1500-byte ICMP Echos to 192.168.1.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 789/790/794 ms
cisco_CE1#

Note that the label stack can be of variable size, as the following list explains:

  • If the PE routers are in a back-to-back configuration, the label stack consists of one label, the VC label.

  • If you are using LDP to signal the tunnel LSP, the label stack consists of two labels, the VC label and the IGP (LDP) label.

  • If you are additionally using traffic engineering tunnels between P routers, the label stack consists of three labels, the VC label, the IGP label, and the TE label.

  • If you are using fast reroute with traffic engineering tunnels between P routers, the label stack consists of four labels, the VC label, the IGP label, the TE label, and the fast reroute label.

If there are any Ethernet switches in the Points-of-Presence (POPs), also ensure that jumbo frame support is configured on these switches.

NOTE

For more information on configuring jumbo frame support on Cisco switches, see the article, "Configuring Jumbo/Giant Frame Support on Catalyst Switches," at the following URL:

http://www.cisco.com/en/US/products/hw/switches/ps700/products_configuration_example09186a008010edab.shtml


Troubleshooting AToM

The AToM troubleshooting process consists of troubleshooting the PE to PE router tunnel label switch path (LSP) and the exchange of VC labels between the peer PE routers.

The flowchart in Figure 7-13 describes the troubleshooting process used with AToM. You can use this flowchart to quickly access the section of the chapter relevant to problems you are experiencing on your network.

Figure 7-13. AToM Troubleshooting Flowchart

[View full size image]

The reference topology shown in Figure 7-14 is used throughout this section.

In Figure 7-14, three virtual circuits (pseudowires) are carried over the MPLS backbone between London_PE and Paris_PE:

  • The Ethernet VLAN VC (VC ID 121) is carried between interface Fast Ethernet 1/0.1 on London_PE and interface Fast Ethernet 0/0.1 on Paris_PE.

  • The Frame Relay DLCI-to-DLCI VC (VC ID 123) is carried between interface serial 4/0 on London_PE and interface serial 2/0 on Paris_PE. This VC provides Frame Relay PVC connectivity between mjlnet_CE1 and mjlnet_CE2.

  • The HDLC VC (VC ID 124) is carried between interface serial 4/1 on London_PE and interface serial 2/1 on Paris_PE. This VC provides HDLC connectivity between cisco_CE1 and cisco_CE2.

Note that the LDP ID on each of the P and PE routers shown in Figure 7-14 corresponds to the IP addresses configured on their respective loopback 0 interfaces.

The sections that follow cover troubleshooting of both the tunnel LSPs and VC label exchange between PE routers.

Verifying and Troubleshooting the Tunnel LSP

If the tunnel LSP between peer PE routers is not operational, one of the following reasons might be to blame:

  • IP connectivity is broken between the peer PE routers.

  • CEF is not operational on one of the LSRs in the path between the PE routers.

  • MPLS is not enabled on one of the LSRs in the path between the PE routers.

  • LDP discovery, session establishment, and label bindings exchange is not successful along the complete path between the PE routers.

Use an extended ping to test IP connectivity between the loopback interfaces (LDP IDs) on peer PE routers. If the ping does not succeed, begin regular IP troubleshooting. The other issues in the preceding list are discussed in the sections that follow.

When troubleshooting the tunnel LSP, the first step is to locate the issue.

Locating the Tunnel LSP Issue

One command that is very useful in locating a tunnel LSP issue is traceroute, which can be used to display the label stack hop-by-hop across the MPLS backbone from PE router to PE router.

In Example 7-28, the LSP is traced from London_PE to Paris_PE (interface loopback 0).

Example 7-28. Tracing the LSP from PE Router to PE Router
London_PE#traceroute 172.16.1.4
Type escape sequence to abort.
Tracing the route to 172.16.1.4
  1 172.16.2.2 [MPLS: Label 22 Exp 0] 92 msec 92 msec 88 msec
  2 172.16.3.2 [MPLS: Label 17 Exp 0] 80 msec 76 msec 76 msec
  3 172.16.4.2 32 msec 28 msec *
London_PE#

In highlighted line 1, London_PE imposes tunnel label 22 on the packet and forwards it to next-hop router 172.16.2.2 (London_P). In highlighted line 2, London_P swaps tunnel label 22 for label 17 and forwards the packet to next-hop router 172.16.3.2 (Paris_P). Finally, in highlighted line 3, Paris_P pops the tunnel label and forwards the packet to router 172.16.4.2 (Paris_PE).

If the command no mpls ip propagate-ttl is configured on the PE routers, the MPLS backbone is represented as one hop. Use the mpls ip propagate-ttl local command to allow TTL to be propagated in traceroute on PE routers.

If traceroute is not successful from PE router to PE router, you should begin regular IP troubleshooting.

If no label stack or only a partial label stack is displayed when using traceroute, you should verify CEF, MPLS, and LDP operation. CEF, MPLS, and LDP must be correctly configured and operational on all routers in the path from PE router to PE router for the tunnel LSP to be established. The sections that follow examine CEF, MPLS, and LDP.

Note that if you are using IOS 12.0(27)S or above, you can use the ping mpls and trace mpls MPLS Embedded Management feature commands to verify tunnel LSP connectivity and trace tunnel LSPs respectively. You can also use the ping mpls command to verify AToM pseudowires between peer PE routers

Verifying and Troubleshooting CEF

If CEF is not enabled, label switching will not operate. Use the show ip cef command to verify that CEF is globally enabled, as shown in Example 7-29.

Example 7-29. CEF Is Disabled
London_P#show ip cef
%CEF not running
Prefix              Next Hop             Interface
London_P#

As you can see, CEF is disabled on London_P. CEF is then enabled on London_P using the ip cef [distributed] command, as shown in Example 7-30. Note that the distributed keyword can be used to enable distributed CEF (dCEF) on high-end platforms, such as the 7500 and 12000 series.

Example 7-30. CEF Is Enabled on London_P
London_P#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
London_P(config)#ip cef
London_P(config)#exit
London_P#

CEF is then verified again using the show ip cef command, as shown in Example 7-31.

Example 7-31. CEF Is Enabled
London_P#show ip cef
Prefix              Next Hop             Interface
0.0.0.0/0           drop                 Null0 (default route handler entry)
0.0.0.0/32          receive
172.16.1.1/32       172.16.2.1           FastEthernet0/0
172.16.1.2/32       receive
172.16.1.3/32       172.16.3.2           Serial1/0
172.16.1.4/32       172.16.3.2           Serial1/0
172.16.2.0/24       attached             FastEthernet0/0
172.16.2.0/32       receive
172.16.2.1/32       172.16.2.1           FastEthernet0/0
172.16.2.2/32       receive
172.16.2.255/32     receive
172.16.3.0/24       attached             Serial1/0
172.16.3.0/32       receive
172.16.3.1/32       receive
172.16.3.2/32       attached             Serial1/0
172.16.3.255/32     receive
172.16.4.0/24       172.16.3.2           Serial1/0
172.16.4.1/32       172.16.3.2           Serial1/0
172.16.4.2/32       172.16.3.2           Serial1/0
224.0.0.0/4         drop
224.0.0.0/24        receive
255.255.255.255/32  receive
London_P#

CEF is now enabled, and the show ip cef command displays a summary of the CEF forwarding information base (FIB).

Verifying and Troubleshooting MPLS

MPLS must be enabled globally and on core interfaces of PE and P routers. If it is not enabled, label switching will not function. The following two sections discuss how to verify whether MPLS is disabled globally or on an interface.

MPLS Has Been Globally Disabled

Label switching will not function on any interface if MPLS has been globally disabled. Use the show mpls interfaces or show mpls forwarding-table commands to verify that MPLS is enabled.

Example 7-32 shows the output of the show mpls interfaces command.

Example 7-32. MPLS Is Globally Disabled
London_PE#show mpls interfaces
IP MPLS forwarding is globally disabled on this router.
Individual interface configuration is as follows:
Interface              IP            Tunnel   Operational
London_PE#

As you can see, MPLS has been globally disabled on London_PE.

Example 7-33 shows the output of the show mpls forwarding-table command.

Example 7-33. MPLS Has Been Disabled and an LFIB Has Not Been Allocated
London_PE#show mpls forwarding-table
Tag switching is not operational.
CEF or tag switching has not been enabled.
No TFIB currently allocated.
London_PE#

In Example 7-33, you can see that MPLS has been disabled, and no Label Forwarding Information Base (LFIB, shown as TFIB) has been allocated.

Use the mpls ip command to globally re-enable MPLS, as shown in Example 7-34.

Example 7-34. Globally Enabling MPLS on the Router
London_PE#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
London_PE(config)#mpls ip
London_PE(config)#end
London_PE#

In Example 7-34, MPLS is re-enabled using the mpls ip command.

MPLS Is Disabled on an Interface

If MPLS is disabled on a core interface, MPLS will not function on that interface.

Use the show mpls interfaces command to verify that MPLS is enabled on an interface, as shown in Example 7-35.

Example 7-35. MPLS Is Disabled on Core Interfaces
London_PE#show mpls interfaces
Interface              IP            Tunnel   Operational
London_PE#

As you can see, MPLS is not enabled on any interfaces on London_PE. In fact, it should be enabled on core interface fast Ethernet 2/0.

Use the mpls ip command to enable MPLS on core interfaces as shown in Example 7-36.

Example 7-36. Enabling MPLS on Core Interfaces
London_PE#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
London_PE(config)#interface fastethernet 2/0
London_PE(config-if)#mpls ip
London_PE(config-if)#exit
London_PE#

In Example 7-36, MPLS is enabled on core interface Fast Ethernet 2/0.

The show mpls interfaces command is then used to verify that MPLS is operational on the core interfaces, as demonstrated in Example 7-37.

Example 7-37. MPLS Is Enabled on Core Interfaces
London_PE#show mpls interfaces
Interface              IP            Tunnel   Operational
FastEthernet2/0        Yes (ldp)     No       Yes
London_PE#

As you can see, MPLS is now enabled on core interface fast Ethernet 2/0.

Troubleshooting LDP for Tunnel LSP Establishment

LDP is used between adjacent LSRs in the path between the PE routers to exchange tunnel label bindings. If LDP discovery or session establishment fails, label bindings will not be exchanged, and label switching will not function.

The sections that follow discuss issues with LDP discovery, session establishment, and advertisement of label bindings.

LDP Neighbor Discovery Fails Between Directly Connected LSRs

As previously mentioned, if LDP neighbor discovery fails, session establishment will not take place, and label bindings will not be exchanged.

Figure 7-15 illustrates the LDP neighbor discovery process between directly connected peers in the MPLS backbone.

Figure 7-15. LDP Discovery Between Directly Connected Peers

[View full size image]

Use the show mpls ldp discovery command to verify successful LDP discovery, as shown in Example 7-38.

Example 7-38. Successful LDP Discovery
London_PE#show mpls ldp discovery
 Local LDP Identifier:
    172.16.1.1:0
    Discovery Sources:
    Interfaces:
        FastEthernet2/0 (ldp): xmit/recv
            LDP Id: 172.16.1.2:0
    Targeted Hellos:
        172.16.1.1 -> 172.16.1.4 (ldp): active, xmit/recv
            LDP Id: 172.16.1.4:0
London_PE#

Highlighted line 1 shows the local LDP ID (172.16.1.1:0). In highlighted line 2, you can see that you can see that LDP packets are being transmitted (xmit) and received (recv) on core interface fast Ethernet 2/0.

LDP discovery between directly connected LSRs can fail for a number of reasons, including the following:

  • There is a label protocol mismatch.

  • An access list blocks LDP neighbor discovery.

  • There is a control VC mismatch between LC-ATM interfaces.

The sections that follow examine these issues in more detail.

Label Protocol Mismatch

If label protocols are mismatched between peer LSRs, neighbor discovery will fail.

Use the show mpls ldp discovery command to verify neighbor discovery between peer LSRs, as shown in Example 7-39.

Example 7-39. LDP Neighbor Discovery Fails
London_PE#show mpls ldp discovery
 Local LDP Identifier:
    172.16.1.1:0
    Discovery Sources:
    Interfaces:
        FastEthernet2/0 (ldp): xmit
    Targeted Hellos:
        172.16.1.1 -> 172.16.1.4 (ldp): active, xmit/recv
            LDP Id: 172.16.1.4:0
London_PE#

As you can see, London_PE is transmitting (xmit) but not receiving (recv) LDP hello messages on interface fast Ethernet 2/0. This may indicate a label distribution protocol mismatch with the peer LSR.

Use the show mpls interfaces command to verify the label protocol used on the peer LSR (London_P), as demonstrated in Example 7-40.

Example 7-40. Verifying the Label Protocol
London_P#show mpls interfaces
Interface              IP            Tunnel   Operational
FastEthernet0/0        Yes (tdp)     No       Yes
Serial1/0              Yes (ldp)     No       Yes
London_P#

The highlighted line indicates that TDP is configured on interface fast Ethernet 0/0, which is connected to London_PE. This clearly indicates a label protocol mismatch.

The label protocol is then configured as LDP on interface fast Ethernet 0/0 using the mpls label protocol ldp command, as shown in Example 7-41.

Example 7-41. LDP Is Configured on Interface Fast Ethernet 0/0
London_P#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
London_P(config)#interface fastethernet 0/0
London_P(config-if)#mpls label protocol ldp
London_P(config-if)#exit
London_PE#

Once the label protocol has been modified, LDP neighbor discovery is verified again using the show mpls ldp discovery command, as demonstrated in Example 7-42.

Example 7-42. LDP Neighbor Discovery Succeeds
London_PE#show mpls ldp discovery
 Local LDP Identifier:
    172.16.1.1:0
    Discovery Sources:
    Interfaces:
        FastEthernet2/0 (ldp): xmit/recv
            LDP Id: 172.16.1.2:0
    Targeted Hellos:
        172.16.1.1 -> 172.16.1.4 (ldp): active, xmit/recv
            LDP Id: 172.16.1.4:0
London_PE#

Highlighted line 1 shows that LDP hello messages are now being both transmitted (xmit) and received (recv) on interface fast Ethernet 2/0. In highlighted line 2, you can see that the LDP ID of the peer LSR (London_P) is 172.16.1.2:0.

Access List Blocks LDP Discovery

LDP discovery between directly connected neighbors uses UDP port 646 and all routers multicast address 224.0.0.2. Ensure that neither UDP port 646 nor multicast address 224.0.0.2 is blocked by an access list.

Similarly, LDP discovery between non-directly connected neighbors (PE routers) uses UDP port 646 and unicast communication between LDP router IDs (loopback IP addresses). Remember that PE routers must perform LDP discovery and establish an LDP session before exchanging VC labels. Ensure that unicast communication on UDP port 646 between PE router LDP ID addresses is not blocked by an access list.

Use the show mpls ldp discovery command to verify LDP discovery, as shown in Example 7-43.

Example 7-43. LDP Discovery Fails
London_PE#show mpls ldp discovery
 Local LDP Identifier:
    172.16.1.1:0
    Discovery Sources:
    Interfaces:
        FastEthernet2/0 (ldp): xmit
    Targeted Hellos:
        172.16.1.1 -> 172.16.1.4 (ldp): active, xmit
London_PE#

In highlighted line 1, you can see that London_PE is transmitting (xmit) but not receiving hello messages on interface Fast Ethernet 2/0 from the directly connected LSR London_P.

Highlighted line 2 shows that London_PE is also transmitting (xmit) but not receiving (recv) targeted hello messages from peer PE router Paris_PE. This may be because of the presence of an access list.

Verify the presence of an access list using the show ip interface [interface_name] command. This is shown in Example 7-44.

Example 7-44. Verifying the Presence of an Access List
London_PE#show ip interface fastethernet 2/0
FastEthernet2/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
  Multicast reserved groups joined: 224.0.0.2
  Outgoing access list is not set
  Inbound  access list is 101
  Proxy ARP is disabled
  Security level is default
  Split horizon is enabled

As you can see, access list 101 is configured in an inbound direction on interface fast Ethernet 2/0.

The composition of the access list is then examined using the show ip access-lists command, as shown in Example 7-45.

Example 7-45. Verifying the Contents of an Access List
London_PE#show ip access-lists 101
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
    permit udp any any eq ntp
    permit udp any any eq snmp
    permit udp any any eq snmptrap
London_PE#

As you can see, access list 101 does not explicitly permit UDP port 646, and so it is blocked by the implicit deny any at the end of the access list.

In this case, it is decided that access list 101 is not required, so it is removed, as shown in Example 7-46.

Example 7-46. Access List 101 Is Removed from Interface Fast Ethernet 2/0
London_PE#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
London_PE(config)#interface fastethernet 2/0
London_PE(config-if)#no ip access-group 101 in
London_PE(config-if)#end
London_PE#

Once access list 101 has been removed, LDP discovery succeeds. This is verified using the show mpls ldp discovery command, as shown in Example 7-47.

Example 7-47. LDP Discovery Succeeds
London_PE#show mpls ldp discovery
 Local LDP Identifier:
    172.16.1.1:0
    Discovery Sources:
    Interfaces:
        FastEthernet2/0 (ldp): xmit/recv
            LDP Id: 172.16.1.2:0
    Targeted Hellos:
        172.16.1.1 -> 172.16.1.4 (ldp): active, xmit/recv
            LDP Id: 172.16.1.4:0
London_PE#

Highlighted line 1 shows that LDP hello messages are now being transmitted (xmit) and received (recv) on interface fast Ethernet 2/0. Highlighted line 2 shows the LDP ID of the peer LSR (172.16.1.2:0, London_P). In highlighted line 3, you can see that targeted hello messages are now being transmitted (xmit) and received (recv) to and from Paris_PE. The LDP ID of Paris_PE (172.16.1.4:0) is shown in highlighted line 4.

Control VC Is Mismatched Between LDP Peers

If the control VC is mismatched on LC-ATM interfaces between peer LSRs, LDP discovery will fail.

Use the show mpls ldp discovery command to verify LDP discovery, as shown in Example 7-48.

Example 7-48. LDP Discovery Fails
London_PE#show mpls ldp discovery
 Local LDP Identifier:
    172.16.1.1:0
    Discovery Sources:
    Interfaces:
        ATM3/0.1 (ldp): xmit
    Targeted Hellos:
        172.16.1.1 -> 172.16.1.4 (ldp): active, xmit/recv
            LDP Id: 172.16.1.4:0; no route
London_PE#

The highlighted line indicates that LDP hello messages are being transmitted (xmit) but not received (recv) on interface ATM 3/0.1. This may indicate that there is a control VC mismatch.

Use the show mpls interfaces atm interface detail command to verify the control VC, as shown in Example 7-49.

Example 7-49. Verifying the Control VC on London_PE
London_PE#show mpls interfaces atm 3/0.1 detail
Interface ATM3/0.1:
        IP labeling enabled (ldp)
        LSP Tunnel labeling not enabled
        BGP labeling not enabled
        MPLS not operational
        Optimum Switching Vectors:
          IP to MPLS Turbo Vector
          MPLS Turbo Vector
        Fast Switching Vectors:
          IP to MPLS Fast Switching Vector
          MPLS Turbo Vector
        MTU = 4470
        ATM labels: Label VPI = 1, Control VC = 0/32
London_PE#

As you can see, the control VC on interface atm 3/0.1 on London_PE uses VPI/VCI 0/32 (the default).

The control VC is then verified on London_P, as shown in Example 7-50.

Example 7-50. Verifying the Control VC on London_P
London_P#show mpls interfaces atm 2/0.1 detail
Interface ATM2/0.1:
        IP labeling enabled (ldp)
        LSP Tunnel labeling not enabled
        BGP labeling not enabled
        MPLS not operational
        Optimum Switching Vectors:
          IP to MPLS Turbo Vector
          MPLS Turbo Vector
        Fast Switching Vectors:
          IP to MPLS Fast Switching Vector
          MPLS Turbo Vector
        MTU = 4470
        ATM labels: Label VPI = 1, Control VC = 0/55
London_P#

The highlighted line indicates that the control VC on interface atm 2/0.1 on London_P is 0/55 (VPI/VCI). Clearly, there is a mismatch between London_PE and London_P.

The control VC must then be modified on either London_PE or London_P so that there is no longer a mismatch. In Example 7-51, the control VC is modified on London_P so that it is the same as that on the connected interface on London_PE (interface atm 2/0.1).

Example 7-51. Control VC Is Modified on London_P
London_P#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
London_P(config)#interface atm 2/0.1
London_P(config-subif)#mpls atm control-vc 0 32
London_P(config-subif)#end
London_P#

In Example 7-51, the control VC is modified so that it is 0/32 (VPI/VCI) on interface atm 2/0.1 on London_P. LDP discovery now succeeds between London_PE and London_P. This is verified using the show mpls ldp discovery command, as shown in Example 7-52.

Example 7-52. LDP Discovery Succeeds
London_PE#show mpls ldp discovery
 Local LDP Identifier:
    172.16.1.1:0
    Discovery Sources:
    Interfaces:
        ATM3/0.1 (ldp): xmit/recv
            LDP Id: 172.16.1.2:1; IP addr: 172.16.7.2
    Targeted Hellos:
        172.16.1.1 -> 172.16.1.4 (ldp): active, xmit
London_PE#

In highlighted line 1, you can see that LDP hello messages are now being transmitted (xmit) and received (recv) on interface atm 3/0.1. Highlighted line 2 shows the LDP ID of London_P (172.16.2.1:1), as well as the IP address on interface atm 2/0.1 on London_P.

LDP Session Establishment Fails Between Directly Connected LSRs

If LDP session establishment fails between directly connected LSRs, tunnel label bindings will not be exchanged.

Figure 7-16 illustrates LDP sessions between directly connected LSRs on the path between the PE routers.

Figure 7-16. LDP Sessions Between Directly Connected LSRs

[View full size image]

Use the show mpls ldp neighbor command to verify LDP session establishment, as shown in Example 7-53.

Example 7-53. LDP Session Establishment Succeeds Between Directly Connected Neighbors
London_PE#show mpls ldp neighbor
    Peer LDP Ident: 172.16.1.2:0; Local LDP Ident 172.16.1.1:0
        TCP connection: 172.16.1.2.11052 - 172.16.1.1.646
        State: Oper; Msgs sent/rcvd: 199/196; Downstream
        Up time: 02:41:28
        LDP discovery sources:
          FastEthernet2/0, Src IP addr: 172.16.2.2
        Addresses bound to peer LDP Ident:
          172.16.1.2      172.16.3.1      172.16.2.2
    Peer LDP Ident: 172.16.1.4:0; Local LDP Ident 172.16.1.1:0
        TCP connection: 172.16.1.4.11056 - 172.16.1.1.646
        State: Oper; Msgs sent/rcvd: 200/196; Downstream
        Up time: 02:41:29
        LDP discovery sources:
          Targeted Hello 172.16.1.1 -> 172.16.1.4, active
        Addresses bound to peer LDP Ident:
          172.16.1.4      172.16.4.2
London_PE#

In highlighted line 1, you can see the peer and local LDP IDs (172.16.1.2:0 and 172.16.1.1:0, respectively). Highlighted line 2 shows that peer and local LSRs have opened TCP ports 11052 and 646 for LDP session establishment.

Highlighted line 3 shows that the session state is operational (established), the number of messages sent and received (199 and 196), and the method of label distribution (unsolicited downstream).

The local interface (Fast Ethernet 2/0) and peer LSR (source) IP address used for LDP discovery are shown in highlighted line 4. The peer LSR's interface IP addresses are shown in highlighted line 5.

LDP session establishment between directly connected neighbors can fail for a number of reasons, including the following:

  • The neighbor's LDP ID is unreachable.

  • An access list blocks LDP session establishment.

  • There is an LDP authentication failure.

  • VPI ranges do not overlap between peers' LC-ATM interfaces.

These issues are examined in the following few sections.

Peer LDP ID Is Unreachable

If the peer's LDP ID is unreachable, session establishment will fail.

Use the show mpls ldp discovery command to troubleshoot this issue, as shown in Example 7-54.

Example 7-54. Peer's LDP ID Is Unreachable
London_PE#show mpls ldp discovery
 Local LDP Identifier:
    172.16.1.1:0
    Discovery Sources:
    Interfaces:
        FastEthernet2/0 (ldp): xmit/recv
            LDP Id: 172.16.1.2:0; no route
    Targeted Hellos:
        172.16.1.1 -> 172.16.1.4 (ldp): active, xmit/recv
            LDP Id: 172.16.1.4:0
London_PE#

The highlighted line shows that London_PE does not have a route to peer (LDP ID) 172.16.1.2.

This is confirmed using the show ip route command, as shown in Example 7-55.

Example 7-55. London_PE Has No Route to Peer 172.16.1.2
London_PE#show ip route 172.16.1.2
% Subnet not in table
London_PE#

As you can see, there is definitely no route to peer (LDP ID) 172.16.1.2. When the configuration of the peer router is examined using the show running-config command, the problem is revealed.

Example 7-56 shows the configuration of the peer router.

Example 7-56. Configuration of London_P
London_P#show running-config
Building configuration...
!
tag-switching tdp router-id Loopback0 force
!
!
interface Loopback0
 ip address 172.16.1.2 255.255.255.255
 no ip directed-broadcast
!
!
router isis
 net 49.0001.0000.0000.0002.00
 is-type level-2-only
 metric-style wide
!

In highlighted line 1, the command tag-switching tdp router-id (mpls ldp router-id) is used to configure the LDP router ID. The LDP router ID itself is shown in highlighted line 2 (172.16.1.2). Finally, the configuration of the IGP (in this example, IS-IS) is shown in highlighted line 3.

The problem is that interface loopback 0 (the LDP ID) is not enabled for IS-IS. Interface loopback 0 is then enabled for IS-IS using the passive-interface interface_name command, as shown in Example 7-57. Some versions of IOS also require you to configure the ip router isis command on the loopback interface in addition to specifying the passive interface command.

Example 7-57. Enabling the Loopback Interface for IS-IS
London_P#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
London_P(config)#router isis
London_P(config-router)#passive-interface loopback0
London_P(config-router)#end
London_P#

Once the loopback interface has been enabled for IS-IS, LDP session establishment is successful. This is verified using the show mpls ldp neighbor command, as shown in Example 7-58.

Example 7-58. LDP Session Establishment Succeeds
London_PE#show mpls ldp neighbor
    Peer LDP Ident: 172.16.1.4:0; Local LDP Ident 172.16.1.1:0
        TCP connection: 172.16.1.4.11056 - 172.16.1.1.646
        State: Oper; Msgs sent/rcvd: 223/218; Downstream
        Up time: 02:58:30
        LDP discovery sources:
          Targeted Hello 172.16.1.1 -> 172.16.1.4, active
        Addresses bound to peer LDP Ident:
          172.16.1.4      172.16.4.2
    Peer LDP Ident: 172.16.1.2:0; Local LDP Ident 172.16.1.1:0
        TCP connection: 172.16.1.2.11058 - 172.16.1.1.646
        State: Oper; Msgs sent/rcvd: 17/16; Downstream
        Up time: 00:02:50
        LDP discovery sources:
          FastEthernet2/0, Src IP addr: 172.16.2.2
        Addresses bound to peer LDP Ident:
          172.16.1.2      172.16.3.1      172.16.2.2
London_PE#

Highlighted line 1 shows the peer and local LDP IDs (172.16.1.2:0 and 172.16.1.1:0, respectively). In highlighted line 2, you can see that the session state is operational (established). In highlighted line 3, you can see that the session has been established for 2 minutes and 50 seconds.

Access List Blocks LDP Session Establishment

LDP sessions are established between peer LSRs over a unicast connection on TCP port 646. The unicast connection is between the peer LSRs' LDP ID addresses. Ensure that an access list is not blocking either TCP port 646 or the LDP ID addresses.

When configuring an access list on an LSR, consider that the passive peer (the peer with the lower LDP ID) opens TCP port 646, and the active peer (the peer with the higher LDP ID) opens an ephemeral port for LDP session establishment.

Use the show ip interface [interface_name] command to verify the presence of an access list, as shown in Example 7-59.

Example 7-59. Verifying the Presence of an Access List
London_PE#show ip interface fastethernet 2/0
FastEthernet2/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
  Multicast reserved groups joined: 224.0.0.2
  Outgoing access list is not set
  Inbound  access list is 101
  Proxy ARP is disabled
  Security level is default
  Split horizon is enabled

As you can see, access list 101 is configured in an inbound direction on interface fast Ethernet 2/0.

The contents of the access list are then verified using the show ip access-lists command, as demonstrated in Example 7-60.

Example 7-60. Verifying the Contents of the Access List
London_PE#show ip access-lists 101
Extended IP access list 101
    permit tcp any any eq ftp
    permit tcp any any eq ftp-data
    permit tcp any any eq telnet
    permit tcp any any eq www
    permit tcp any any eq smtp
    permit udp any any eq tftp
    permit udp any any eq ntp
    permit udp any any eq snmp
    permit udp any any eq snmptrap
London_PE#

As you can see, TCP port 646 is not explicitly permitted and is, therefore, blocked by the implicit deny any at the end of the access list. Because London_PE is the passive peer (in this example), LDP session establishment fails.

Access list 101 is unnecessary in this case and is removed, as shown in Example 7-61.

Example 7-61. Access List Is Removed from the Interface
London_PE#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
London_PE(config)#interface fastethernet 2/0
London_PE(config-if)#no ip access-group 101 in
London_PE(config-if)#end
London_PE#

Once the access list has been removed, LDP session establishment is successful. This is verified using the show mpls ldp neighbor command, as shown in Example 7-62.

Example 7-62. LDP Session Establishment Is Successful
London_PE#show mpls ldp neighbor
    Peer LDP Ident: 172.16.1.4:0; Local LDP Ident 172.16.1.1:0
        TCP connection: 172.16.1.4.11170 - 172.16.1.1.646
        State: Oper; Msgs sent/rcvd: 16/15; Downstream
        Up time: 00:00:49
        LDP discovery sources:
          Targeted Hello 172.16.1.1 -> 172.16.1.4, active
        Addresses bound to peer LDP Ident:
          172.16.1.4      172.16.4.2
    Peer LDP Ident: 172.16.1.2:0; Local LDP Ident 172.16.1.1:0
        TCP connection: 172.16.1.2.11173 - 172.16.1.1.646
        State: Oper; Msgs sent/rcvd: 14/14; Downstream
        Up time: 00:00:47
        LDP discovery sources:
          FastEthernet2/0, Src IP addr: 172.16.2.2
        Addresses bound to peer LDP Ident:
          172.16.1.2      172.16.3.1      172.16.2.2
London_PE#

Highlighted lines 1 to 4 show that LDP session establishment has now been successful with peers 172.16.1.4 (peer PE router, Paris_PE) and 172.16.1.2 (directly connected LSR, London_P).

LDP Authentication Failure

If there is a TCP MD5 authentication password mismatch between peer LSRs, or one peer is configured for authentication but the other is not, session establishment will fail.

In this example, there is an authentication password mismatch between peer LSRs. The message shown in Example 7-63 is logged.

Example 7-63. Authentication Password Mismatch
*Apr 18 17:43:38.335 UTC: %TCP-6-BADAUTH: Invalid MD5 digest from 172.16.1.2
  (11187) to 172.16.1.1(646)

The authentication password is reconfigured on the peer LSRs, as shown in Example 7-64.

Example 7-64. Reconfiguration of Authentication Password on Peer LSRs
London_PE#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
London_PE(config)#mpls ldp neighbor 172.16.1.2 password mjlnet
London_PE(config)#end
London_PE#
________________________________________________________________
London_P#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
London_P(config)#mpls ldp neighbor 172.16.1.1 password mjlnet
London_P(config)#end
London_P#

After the authentication password has been reconfigured, LDP session establishment is successful, as shown in Example 7-65.

Example 7-65. LDP Session Is Successful
London_PE#show mpls ldp neighbor
    Peer LDP Ident: 172.16.1.4:0; Local LDP Ident 172.16.1.1:0
        TCP connection: 172.16.1.4.11172 - 172.16.1.1.646
        State: Oper; Msgs sent/rcvd: 32/30; Downstream
        Up time: 00:14:47
        LDP discovery sources:
          Targeted Hello 172.16.1.1 -> 172.16.1.4, active
        Addresses bound to peer LDP Ident:
          172.16.1.4      172.16.4.2
    Peer LDP Ident: 172.16.1.2:0; Local LDP Ident 172.16.1.1:0
        TCP connection: 172.16.1.2.11193 - 172.16.1.1.646
        State: Oper; Msgs sent/rcvd: 14/13; Downstream
        Up time: 00:00:08
        LDP discovery sources:
          FastEthernet2/0, Src IP addr: 172.16.2.2
        Addresses bound to peer LDP Ident:
          172.16.1.2      172.16.3.1      172.16.2.2
London_PE#

Highlighted line 1 shows the peer and local LDP IDs (172.16.1.2:0 and 172.16.1.1:0, respectively). In highlighted line 2, you can see that the session state is operational (established).

Note that if the local peer has been configured with authentication, but the remote peer has not, the message shown in Example 7-66 is logged.

Example 7-66. Remote Peer Is Not Configured with LDP Authentication.
*Apr 20 20:54:24.027 UTC: %TCP-6-BADAUTH: No MD5 digest from 172.16.1.4(11004) to
  172.16.1.1(646)

To resolve this issue, authentication should be configured on the peer LSR.

VPI Ranges Do Not Overlap Between Peers' LC-ATM Interfaces

During LDP session initialization, various parameters are negotiated between peers. If the peers are connected via LC-ATM interfaces, VPI/VCI ranges used for label switching are negotiated.

If there is no overlap between the VPI ranges configured for label switching on peer LSRs, session initialization will fail, and the message shown in Example 7-67 is logged.

Example 7-67. VPI Ranges Do Not Overlap
*Apr 18 18:29:33.399 UTC: %TDP-3-TAGATM_BAD_RANGE: Interface ATM3/0.1, Bad VPI
  range. Can't start a TDP session

You can obtain more information using the debug mpls atm-ldp api command, as shown in Example 7-68.

Example 7-68. Peer VPI Ranges
London_PE#debug mpls atm-ldp api
LC-ATM API debugging is on
London_PE#
*Apr 18 18:35:30.923 UTC: TAGATM_API: Disjoint VPI local[1-1], peer[3-6]
London_PE#

The highlighted line indicates that the local LSR is configured to use VPI range 1-1 (the default), and the remote (peer) LSR is configured to use VPI range 36.

The VPI range on one of the LSRs must be configured to overlap with the other. In this example, the VPI range on London_P is reconfigured to overlap with the range on London_PE, as shown in Example 7-69.

Example 7-69. VPI Range Is Reconfigured
London_P#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
London_P(config)#interface atm 2/0.1
London_P(config-subif)#no mpls atm vpi 3-6
London_P(config-subif)#end
London_P#

In the highlighted line, the VPI range 36 is removed. This resets the VPI range to the default range (11).

Once the VPI range has been reconfigured on London_P, session establishment succeeds, as confirmed in Example 7-70.

Example 7-70. LDP Session Establishment Succeeds
London_PE#show mpls ldp neighbor
    Peer LDP Ident: 172.16.1.4:0; Local LDP Ident 172.16.1.1:0
        TCP connection: 172.16.1.4.11175 - 172.16.1.1.646
        State: Oper; Msgs sent/rcvd: 47/41; Downstream
        Up time: 00:19:31
        LDP discovery sources:
          Targeted Hello 172.16.1.1 -> 172.16.1.4, active
        Addresses bound to peer LDP Ident:
          172.16.1.4      172.16.4.2
    Peer LDP Ident: 172.16.1.2:1; Local LDP Ident 172.16.1.1:1
        TCP connection: 172.16.7.2.11211 - 172.16.7.1.646
        State: Oper; Msgs sent/rcvd: 12/12; Downstream on demand
        Up time: 00:00:09
        LDP discovery sources:
          ATM3/0.1, Src IP addr: 172.16.7.2
London_PE#

Highlighted line 1 shows the peer and local LDP IDs (172.16.1.2:1 and 172.16.1.1:1, respectively). In highlighted line 2, you can see that the LDP session is operational (established).

Tunnel Label Bindings Are Not Advertised

If label bindings are not advertised for the tunnel LSP, label switching across the MPLS backbone will fail.

Use the show mpls ldp bindings command to verify the advertisement of label bindings, as shown in Example 7-71. This command displays the contents of the Label Information Base (LIB).

Example 7-71. Verifying Label Bindings for the Tunnel LSP
London_PE#show mpls ldp bindings
  tib entry: 172.16.1.1/32, rev 4
        local binding:  tag: imp-null
        remote binding: tsr: 172.16.1.2:0, tag: 16
        remote binding: tsr: 172.16.1.4:0, tag: 24
  tib entry: 172.16.1.2/32, rev 6
        local binding:  tag: 18
        remote binding: tsr: 172.16.1.2:0, tag: imp-null
        remote binding: tsr: 172.16.1.4:0, tag: 23
  tib entry: 172.16.1.3/32, rev 18
        local binding:  tag: 24
        remote binding: tsr: 172.16.1.2:0, tag: 20
        remote binding: tsr: 172.16.1.4:0, tag: 19
  tib entry: 172.16.1.4/32, rev 22
        local binding:  tag: 26
        remote binding: tsr: 172.16.1.4:0, tag: imp-null
        remote binding: tsr: 172.16.1.2:0, tag: 22
  tib entry: 172.16.2.0/24, rev 2
        local binding:  tag: imp-null
        remote binding: tsr: 172.16.1.2:0, tag: imp-null
        remote binding: tsr: 172.16.1.4:0, tag: 22
  tib entry: 172.16.3.0/24, rev 10
        local binding:  tag: 20
        remote binding: tsr: 172.16.1.2:0, tag: imp-null
        remote binding: tsr: 172.16.1.4:0, tag: 20
  tib entry: 172.16.3.1/32, rev 16
        local binding:  tag: 23
        remote binding: tsr: 172.16.1.4:0, tag: 18
  tib entry: 172.16.3.2/32, rev 9
        local binding:  tag: 19
        remote binding: tsr: 172.16.1.2:0, tag: 17
        remote binding: tsr: 172.16.1.4:0, tag: 21
  tib entry: 172.16.4.0/24, rev 12
        local binding:  tag: 21
        remote binding: tsr: 172.16.1.2:0, tag: 18
        remote binding: tsr: 172.16.1.4:0, tag: imp-null
  tib entry: 172.16.4.1/32, rev 20
        local binding:  tag: 25
        remote binding: tsr: 172.16.1.4:0, tag: 16
        remote binding: tsr: 172.16.1.2:0, tag: 21
  tib entry: 172.16.4.2/32, rev 14
        local binding:  tag: 22
        remote binding: tsr: 172.16.1.2:0, tag: 19
London_PE#

As you can see, label bindings are being received from LSRs 172.16.1.2:0 (London_P) and 172.16.1.4:0 (Paris_PE).

Note, in particular, the entry for 172.16.1.4/32 (highlighted line 1). The label advertised by London_P for this entry is 22. This label corresponds to the egress PE router's (Paris_PE in this example) LDP ID, and it is the tunnel label used by London_PE to forward AToM Layer 2 PDUs across the MPLS backbone.

Label bindings that correspond to the best IGP routes can also be seen in the Label Forwarding Information Base (LFIB). The contents of the LFIB can be examined using the show mpls forwarding-table command, as shown in Example 7-72.

Example 7-72. Examining the LFIB
London_PE#show mpls forwarding-table
Local  Outgoing    Prefix            Bytes tag  Outgoing   Next Hop
tag    tag or VC   or Tunnel Id      switched   interface
16     Untagged    l2ckt(121)        71416      Fa1/0.1    point2point
18     Pop tag     172.16.1.2/32     0          Fa2/0      172.16.2.2
19     17          172.16.3.2/32     0          Fa2/0      172.16.2.2
20     Pop tag     172.16.3.0/24     0          Fa2/0      172.16.2.2
21     18          172.16.4.0/24     0          Fa2/0      172.16.2.2
22     19          172.16.4.2/32     0          Fa2/0      172.16.2.2
23     Untagged    172.16.3.1/32     0          Fa2/0      172.16.2.2
24     20          172.16.1.3/32     0          Fa2/0      172.16.2.2
25     21          172.16.4.1/32     0          Fa2/0      172.16.2.2
26     22          172.16.1.4/32     0          Fa2/0      172.16.2.2
27     Untagged    l2ckt(123)        132        Se4/0      point2point
30     Untagged    l2ckt(124)        6775       Se4/1      point2point
London_PE#

As you can see, the LFIB contains both the locally assigned and outgoing (advertised by the peer LSR) labels for each prefix, as well as local VC labels. Also shown are the number of bytes switched, together with the outgoing interface and next-hop associated with the LFIB entry.

In the highlighted line, you can see that the outgoing label for entry 172.16.1.4/32 is again 22, the number of bytes switched is 0, and the outgoing interface and next-hop are fast Ethernet 2/0 and 172.16.2.2 (Paris_P), respectively.

Advertisement of tunnel label bindings can fail for a number of reasons, including the following:

  • The peer LSR is configured not to advertise labels.

  • Conditional label advertisement blocks label bindings.

  • CEF is disabled.

The sections that follow discuss these issues in greater detail.

Peer LSR Is Configured Not to Advertise Label Bindings

If no label bindings are being received from the peer LSR, this might indicate that the peer is configured not to advertise label bindings.

Use the show mpls ldp bindings command to verify advertisement of label bindings from the peer LSR, as shown in Example 7-73.

Example 7-73. Label Bindings Are Not Advertised by the Peer LSR
London_PE#show mpls ldp bindings
  tib entry: 172.16.1.1/32, rev 4
        local binding:  tag: imp-null
        remote binding: tsr: 172.16.1.4:0, tag: 24
  tib entry: 172.16.1.2/32, rev 6
        local binding:  tag: 18
        remote binding: tsr: 172.16.1.4:0, tag: 23
  tib entry: 172.16.1.3/32, rev 18
        local binding:  tag: 24
        remote binding: tsr: 172.16.1.4:0, tag: 19
  tib entry: 172.16.1.4/32, rev 22
        local binding:  tag: 26
        remote binding: tsr: 172.16.1.4:0, tag: imp-null
  tib entry: 172.16.2.0/24, rev 2
        local binding:  tag: imp-null
        remote binding: tsr: 172.16.1.4:0, tag: 22
  tib entry: 172.16.3.0/24, rev 10
        local binding:  tag: 20
        remote binding: tsr: 172.16.1.4:0, tag: 20
  tib entry: 172.16.3.1/32, rev 16
        local binding:  tag: 23
        remote binding: tsr: 172.16.1.4:0, tag: 18
  tib entry: 172.16.3.2/32, rev 9
        local binding:  tag: 19
        remote binding: tsr: 172.16.1.4:0, tag: 21
  tib entry: 172.16.4.0/24, rev 12
        local binding:  tag: 21
        remote binding: tsr: 172.16.1.4:0, tag: imp-null
  tib entry: 172.16.4.1/32, rev 20
        local binding:  tag: 25
        remote binding: tsr: 172.16.1.4:0, tag: 16
  tib entry: 172.16.4.2/32, rev 14
        local binding:  tag: 22
London_PE#

Highlighted line 1 shows the entry for 172.16.1.4/32. The local and remote (from peer 172.16.1.4:0, Paris_PE) bindings for this prefix are shown in highlighted lines 2 and 3.

One thing is missing, however. There is no remote binding for peer 172.16.1.2:0 (London_P). If you examine all the other entries in the LIB, you notice that there are no bindings from London_P. When the configuration of London_P is examined using the show running-config command, the problem is revealed. This is shown in Example 7-74. Note that only the relevant portion of the output is shown.

Example 7-74. Configuration of London_P
London_P#show running-config
Building configuration...
!
no tag-switching advertise-tags
tag-switching tdp router-id Loopback0 force
!

The highlighted line shows that the command no mpls ldp advertise-labels command (shown as no tag-switching advertise-tags) is configured on London_P. This is preventing London_P from advertising any labels to London_PE or other peer LSRs.

Label bindings advertisement is then enabled using the mpls ldp advertise-labels command, as shown in Example 7-75.

Example 7-75. Label Bindings Advertisement Is Enabled
London_P#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
London_P(config)#mpls ldp advertise-labels
London_P(config)#end
London_P#

Label bindings are now received on London_PE. This is verified using the show mpls ldp bindings command, as shown in Example 7-76.

Example 7-76. Label Bindings Are Received from London_P
London_PE#show mpls ldp bindings
  tib entry: 172.16.1.1/32, rev 4
        local binding:  tag: imp-null
        remote binding: tsr: 172.16.1.4:0, tag: 24
        remote binding: tsr: 172.16.1.2:0, tag: 16
  tib entry: 172.16.1.2/32, rev 6
        local binding:  tag: 18
        remote binding: tsr: 172.16.1.4:0, tag: 23
        remote binding: tsr: 172.16.1.2:0, tag: imp-null
  tib entry: 172.16.1.3/32, rev 18
        local binding:  tag: 24
        remote binding: tsr: 172.16.1.4:0, tag: 19
        remote binding: tsr: 172.16.1.2:0, tag: 20
  tib entry: 172.16.1.4/32, rev 22
        local binding:  tag: 26
        remote binding: tsr: 172.16.1.4:0, tag: imp-null
        remote binding: tsr: 172.16.1.2:0, tag: 22
  tib entry: 172.16.2.0/24, rev 2
        local binding:  tag: imp-null
        remote binding: tsr: 172.16.1.4:0, tag: 22
        remote binding: tsr: 172.16.1.2:0, tag: imp-null
  tib entry: 172.16.3.0/24, rev 10
        local binding:  tag: 20
        remote binding: tsr: 172.16.1.4:0, tag: 20
        remote binding: tsr: 172.16.1.2:0, tag: imp-null
  tib entry: 172.16.3.1/32, rev 16
        local binding:  tag: 23
        remote binding: tsr: 172.16.1.4:0, tag: 18
  tib entry: 172.16.3.2/32, rev 9
        local binding:  tag: 19
        remote binding: tsr: 172.16.1.4:0, tag: 21
        remote binding: tsr: 172.16.1.2:0, tag: 17
  tib entry: 172.16.4.0/24, rev 12
        local binding:  tag: 21
        remote binding: tsr: 172.16.1.4:0, tag: imp-null
        remote binding: tsr: 172.16.1.2:0, tag: 18
  tib entry: 172.16.4.1/32, rev 20
        local binding:  tag: 25
        remote binding: tsr: 172.16.1.4:0, tag: 16
        remote binding: tsr: 172.16.1.2:0, tag: 21
  tib entry: 172.16.4.2/32, rev 14
        local binding:  tag: 22
        remote binding: tsr: 172.16.1.2:0, tag: 19
London_PE#

As you can see in highlighted lines 1 and 2, a label binding for prefix 172.16.1.4/32 has now been received from London_P (172.16.1.2:0).

Conditional Label Advertisement Blocks Label Bindings

If conditional label advertisement is configured on a peer LSR, then some, but not all, label bindings may be received.

Use the show mpls ldp bindings command to verify label bindings received from peer LSRs, as demonstrated in Example 7-77.

Example 7-77. Not All Label Bindings Are Received from London_P
London_PE#show mpls ldp bindings
  tib entry: 172.16.1.1/32, rev 4
        local binding:  tag: imp-null
        remote binding: tsr: 172.16.1.4:0, tag: 24
        remote binding: tsr: 172.16.1.2:0, tag: 22
  tib entry: 172.16.1.2/32, rev 10
        local binding:  tag: 22
        remote binding: tsr: 172.16.1.4:0, tag: 23
        remote binding: tsr: 172.16.1.2:0, tag: imp-null
  tib entry: 172.16.1.3/32, rev 18
        local binding:  tag: 26
        remote binding: tsr: 172.16.1.4:0, tag: 19
        remote binding: tsr: 172.16.1.2:0, tag: 19
  tib entry: 172.16.1.4/32, rev 22
        local binding:  tag: 28
        remote binding: tsr: 172.16.1.4:0, tag: imp-null
  tib entry: 172.16.2.0/24, rev 2
        local binding:  tag: imp-null
        remote binding: tsr: 172.16.1.4:0, tag: 22
        remote binding: tsr: 172.16.1.2:0, tag: imp-null
  tib entry: 172.16.3.0/24, rev 8
        local binding:  tag: 21
        remote binding: tsr: 172.16.1.4:0, tag: 20
        remote binding: tsr: 172.16.1.2:0, tag: imp-null
  tib entry: 172.16.3.1/32, rev 16
        local binding:  tag: 25
        remote binding: tsr: 172.16.1.4:0, tag: 18
  tib entry: 172.16.3.2/32, rev 6
        local binding:  tag: 20
        remote binding: tsr: 172.16.1.4:0, tag: 21
        remote binding: tsr: 172.16.1.2:0, tag: 16
  tib entry: 172.16.4.0/24, rev 12
        local binding:  tag: 23
        remote binding: tsr: 172.16.1.4:0, tag: imp-null
        remote binding: tsr: 172.16.1.2:0, tag: 17
  tib entry: 172.16.4.1/32, rev 20
        local binding:  tag: 27
        remote binding: tsr: 172.16.1.4:0, tag: 16
        remote binding: tsr: 172.16.1.2:0, tag: 20
  tib entry: 172.16.4.2/32, rev 14
        local binding:  tag: 24
        remote binding: tsr: 172.16.1.2:0, tag: 18
London_PE#

Highlighted line 1 shows the LIB entry for prefix 172.16.1.4/32. Highlighted lines 2 and 3 show a local label binding, together with a remote binding from peer 172.16.1.4:0 (Paris_PE) for this prefix. You will notice, however, that there is no binding from peer 172.16.1.2:0 (London_P).

A close examination of other entries in the LIB shows that other bindings are being received from London_P. This might indicate that conditional label advertisement is configured on London_P.

The configuration of London_P is then examined using the show running-config command, as shown in Example 7-78. Note that only the relevant portion of the output is shown.

Example 7-78. Configuration of London_P
London_P#show running-config
Building configuration...
!
no tag-switching advertise-tags
tag-switching advertise-tags for 1
!
!
access-list 1 permit 172.16.1.1
access-list 1 permit 172.16.1.3
access-list 1 permit 172.16.1.2
access-list 1 permit 172.16.2.0 0.0.0.255
access-list 1 permit 172.16.3.0 0.0.0.255
access-list 1 permit 172.16.4.0 0.0.0.255
!

Highlighted lines 1 and 2 show that London_P is configured to advertise only those label bindings permitted in access list 1. Access list 1 is shown in highlighted lines 3 to 8. As you can see, prefix 172.16.1.4/32 is not permitted.

To correct this problem, either access list 1 can be modified or conditional label advertisement can be removed. The configuration in Example 7-79 removes conditional label advertisement.

Example 7-79. Conditional Label Advertisement Is Removed
London_P#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
London_P(config)#mpls ldp advertise-labels
London_P(config)#no mpls ldp advertise-labels for 1
London_P(config)#exit
London_P#

Once conditional label advertisement has been removed, London_P advertises the label binding for prefix 172.16.1.4/32. This is verified using the show mpls ldp bindings [prefix] [mask_length] command, as shown in Example 7-80.

Example 7-80. Label Binding for 172.16.1.4/32 Is Received from London_P
London_PE#show mpls ldp bindings 172.16.1.4 32
  tib entry: 172.16.1.4/32, rev 22
        local binding:  tag: 28
        remote binding: tsr: 172.16.1.4:0, tag: imp-null
        remote binding: tsr: 172.16.1.2:0, tag: 21
London_PE#

As you can see, a label binding has now been received from 172.16.1.2:0 (London_P) for prefix 172.16.1.4/32.

It is also possible to filter label bindings as they are received on an LSR using the mpls ldp neighbor [vrf vpn-name] neighbor-address labels accept acl command. Only labels corresponding to prefixes permitted in a standard access list are accepted from the specified neighbor. You can use the show mpls ldp neighbor neighbor-address detail command to verify the presence of this command.

CEF Is Disabled

If no tunnel label bindings are locally assigned to prefixes, this may indicate that CEF is globally disabled on the LSR.

Verify local label assignment using the show mpls ldp bindings command, as shown in Example 7-81.

Example 7-81. No Labels Are Locally Assigned
London_P#show mpls ldp bindings
  tib entry: 172.16.1.1/32, rev 5
        remote binding: tsr: 172.16.1.1:0, tag: imp-null
        remote binding: tsr: 172.16.1.3:0, tag: 21
  tib entry: 172.16.1.2/32, rev 2
        remote binding: tsr: 172.16.1.1:0, tag: 22
        remote binding: tsr: 172.16.1.3:0, tag: 20
  tib entry: 172.16.1.3/32, rev 8
        remote binding: tsr: 172.16.1.1:0, tag: 26
        remote binding: tsr: 172.16.1.3:0, tag: imp-null
  tib entry: 172.16.1.4/32, rev 10
        remote binding: tsr: 172.16.1.1:0, tag: 28
        remote binding: tsr: 172.16.1.3:0, tag: 18
  tib entry: 172.16.2.0/24, rev 1
        remote binding: tsr: 172.16.1.1:0, tag: imp-null
        remote binding: tsr: 172.16.1.3:0, tag: 19
  tib entry: 172.16.3.0/24, rev 4
        remote binding: tsr: 172.16.1.1:0, tag: 21
        remote binding: tsr: 172.16.1.3:0, tag: imp-null
  tib entry: 172.16.3.1/32, rev 11
        remote binding: tsr: 172.16.1.1:0, tag: 25
        remote binding: tsr: 172.16.1.3:0, tag: 17
  tib entry: 172.16.3.2/32, rev 3
        remote binding: tsr: 172.16.1.1:0, tag: 20
  tib entry: 172.16.4.0/24, rev 6
        remote binding: tsr: 172.16.1.1:0, tag: 23
        remote binding: tsr: 172.16.1.3:0, tag: imp-null
  tib entry: 172.16.4.1/32, rev 9
        remote binding: tsr: 172.16.1.1:0, tag: 27
  tib entry: 172.16.4.2/32, rev 7
        remote binding: tsr: 172.16.1.1:0, tag: 24
        remote binding: tsr: 172.16.1.3:0, tag: 16
London_P#

An examination of the output shown in Example 7-81 shows that no labels are locally assigned to prefixes on London_P (there are no local bindings).

CEF is then verified using the show ip cef summary command, as demonstrated in Example 7-82.

Example 7-82. CEF Is Disabled
London_P#show ip cef summary
IP CEF without switching (Table Version 4), flags=0x0, bits=8
  4 routes, 0 reresolve, 0 unresolved (0 old, 0 new), peak 0
  4 leaves, 8 nodes, 8912 bytes, 4 inserts, 0 invalidations
  0 load sharing elements, 0 bytes, 0 references
  universal per-destination load sharing algorithm, id A189DD49
  1(0) CEF resets, 0 revisions of existing leaves
  0 in-place/0 aborted modifications
  Resolution Timer: Exponential (currently 0s, peak 0s)
  refcounts:  2308 leaf, 2304 node
  Table epoch: 0 (4 entries at this epoch)
%CEF not running
London_P#

As you can see, CEF is disabled on London_P.

The ip cef command is then used to enable CEF, as shown in Example 7-83.

Example 7-83. CEF Is Enabled on London_P
London_P#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
London_P(config)#ip cef
London_P(config)#exit
London_P#

After CEF has been enabled, the LIB is re-examined using the show mpls ldp bindings command, as shown in Example 7-84.

Example 7-84. Labels Are Locally Assigned
London_P#show mpls ldp bindings
  tib entry: 172.16.1.1/32, rev 16
        local binding:  tag: 20
        remote binding: tsr: 172.16.1.1:0, tag: imp-null
        remote binding: tsr: 172.16.1.3:0, tag: 21
  tib entry: 172.16.1.2/32, rev 21
        local binding:  tag: imp-null
        remote binding: tsr: 172.16.1.1:0, tag: 22
        remote binding: tsr: 172.16.1.3:0, tag: 20
  tib entry: 172.16.1.3/32, rev 19
        local binding:  tag: 22
        remote binding: tsr: 172.16.1.1:0, tag: 26
        remote binding: tsr: 172.16.1.3:0, tag: imp-null
  tib entry: 172.16.1.4/32, rev 14
        local binding:  tag: 18
        remote binding: tsr: 172.16.1.1:0, tag: 28
        remote binding: tsr: 172.16.1.3:0, tag: 18
  tib entry: 172.16.2.0/24, rev 18
        local binding:  tag: imp-null
        remote binding: tsr: 172.16.1.1:0, tag: imp-null
        remote binding: tsr: 172.16.1.3:0, tag: 19
  tib entry: 172.16.3.0/24, rev 20
        local binding:  tag: imp-null
        remote binding: tsr: 172.16.1.1:0, tag: 21
        remote binding: tsr: 172.16.1.3:0, tag: imp-null
  tib entry: 172.16.3.1/32, rev 11
        remote binding: tsr: 172.16.1.1:0, tag: 25
        remote binding: tsr: 172.16.1.3:0, tag: 17
  tib entry: 172.16.3.2/32, rev 17
        local binding:  tag: 21
        remote binding: tsr: 172.16.1.1:0, tag: 20
  tib entry: 172.16.4.0/24, rev 12
        local binding:  tag: 16
        remote binding: tsr: 172.16.1.1:0, tag: 23
        remote binding: tsr: 172.16.1.3:0, tag: imp-null
  tib entry: 172.16.4.1/32, rev 13
        local binding:  tag: 17
        remote binding: tsr: 172.16.1.1:0, tag: 27
  tib entry: 172.16.4.2/32, rev 15
        local binding:  tag: 19
        remote binding: tsr: 172.16.1.1:0, tag: 24
        remote binding: tsr: 172.16.1.3:0, tag: 16
London_P#

As you can see, labels are now locally assigned to prefixes.

Verifying and Troubleshooting VC Label Exchange

If VC labels are not successfully exchanged between peer PE routers, pseudowire setup will fail.

Use the show mpls l2transport vc vcid detail command to verify VC label exchange, as shown in Example 7-85.

Example 7-85. Verifying VC Label Exchange
London_PE#show mpls l2transport vc 124 detail
Local interface: Se4/1 up, line protocol up, HDLC up
  Destination address: 172.16.1.4, VC ID: 124, VC status: up
    Preferred path: not configured
    Default path: active
    Tunnel label: 21, next hop 172.16.2.2
    Output interface: Fa2/0, imposed label stack {21 17}
  Create time: 00:01:43, last status change time: 00:01:05
  Signaling protocol: LDP, peer 172.16.1.4:0 up
    MPLS VC labels: local 16, remote 17
    Group ID: local 0, remote 4
    MTU: local 1500, remote 1500
    Remote interface description:
  Sequencing: receive disabled, send disabled
  VC statistics:
    packet totals: receive 11, send 7
    byte totals:   receive 1662, send 210
    packet drops:  receive 0, send 0

London_PE#

In the highlighted line, you can see local and remote (advertised by the remote PE router) VC labels for the pseudowire with VC ID 124.

If VC labels are not successfully exchanged between peer PE routers, the cause may be one of the following:

  • LDP is not fully operational between peer PE routers.

  • One or both of the attachment circuits is down on peer PE routers.

  • A VC type mismatch exists between peer PE routers' attachment circuits.

  • A VC ID mismatch exists between peer PE routers' attachment circuits.

  • An MTU mismatch exists between peer PE routers' attachment circuit interfaces.

  • The peer PE router's IP address is misconfigured using the xconnect command.

Use the show interface [interface_name] command to verify that attachment circuits are correctly configured and in an up state.

The sections that follow examine the other issues described in the preceding list.

Note that if you are using IOS 12.0(27)S or above, you can use the ping mpls command to verify AToM pseudowires between peer PE routers. Peer PE routers advertise the capability to support the verification of pseudowires (called Virtual Circuit Connection Verification [VCCV]) to each other. Use the show mpls l2transport binding command to verify PE router VCCV capability.

Troubleshooting LDP Between PE Routers

LDP is used between the PE routers to exchange VC label bindings.

If LDP discovery or session establishment is not successful, label bindings will not be exchanged and pseudowire setup will fail.

Note that it is only necessary for the IP address (LDP IDs) within a single xconnect command on peer PE routers to be correctly configured for LDP discovery and session establishment to succeed between those peers.

Figure 7-17 illustrates VC label exchange.

Figure 7-17. VC Label Exchange

[View full size image]

Issues with LDP discovery and session establishment are discussed in the following two sections.

LDP Neighbor Discovery Fails Between Peer PE Routers

If LDP neighbor discovery fails, session establishment will not take place, and VC label bindings will not be exchanged.

Figure 7-18 illustrates LDP neighbor discovery between PE routers.

Figure 7-18. LDP Discovery Between PE Routers

[View full size image]

Use the show mpls ldp discovery command to verify successful LDP discovery between peer PE routers, as shown in Example 7-86.

Example 7-86. Successful LDP Discovery Between PE Routers
London_PE#show mpls ldp discovery
 Local LDP Identifier:
    172.16.1.1:0
    Discovery Sources:
    Interfaces:
        FastEthernet2/0 (ldp): xmit/recv
            LDP Id: 172.16.1.2:0
    Targeted Hellos:
        172.16.1.1 -> 172.16.1.4 (ldp): active, xmit/recv
            LDP Id: 172.16.1.4:0
London_PE#

In highlighted line 1, you can see the local LDP ID (172.16.1.1:0). Highlighted line 2 shows that targeted hello messages are being transmitted (xmit) and received (recv) between the local (172.16.1.1) and remote (172.16.1.4) PE routers. The LDP ID of the remote PE router (172.16.1.4:0) is shown in highlighted line 3.

LDP discovery between peer PE routers can fail for a number of reasons, including the following:

  • The LDP ID of the peer PE router is unreachable.

  • The IP address of the peer PE router is misconfigured.

  • An access list blocks LDP discovery between PE routers.

See the section entitled "Peer LDP ID Is Unreachable," earlier in the chapter (on page 620) for more information about verifying and troubleshooting peer LDP ID reachability.

For more information about misconfiguration of the IP address of the peer PE router, see the section entitled "Peer PE Router's IP Address Is Misconfigured," later in this chapter (on page 644).

See the section entitled "Access List Blocks LDP Discovery," earlier in this chapter (on page 614) for more information about troubleshooting access lists.

LDP Session Establishment Fails Between PE Routers

If an LDP session is not established between PE routers, VC labels will not be exchanged.

Figure 7-19 illustrates an LDP session between peer PE routers.

Figure 7-19. LDP Session Between PE Routers

[View full size image]

Use the show mpls ldp neighbor command to verify LDP session establishment, as shown in Example 7-87.

Example 7-87. Verifying LDP Session Establishment Between PE Routers
London_PE#show mpls ldp neighbor
    Peer LDP Ident: 172.16.1.2:0; Local LDP Ident 172.16.1.1:0
        TCP connection: 172.16.1.2.11181 - 172.16.1.1.646
        State: Oper; Msgs sent/rcvd: 14/13; Downstream
        Up time: 00:00:19
        LDP discovery sources:
          FastEthernet2/0, Src IP addr: 172.16.2.2
        Addresses bound to peer LDP Ident:
          172.16.1.2      172.16.3.1      172.16.2.2
    Peer LDP Ident: 172.16.1.4:0; Local LDP Ident 172.16.1.1:0
        TCP connection: 172.16.1.4.11172 - 172.16.1.1.646
        State: Oper; Msgs sent/rcvd: 16/14; Downstream
        Up time: 00:00:05
        LDP discovery sources:
          Targeted Hello 172.16.1.1 -> 172.16.1.4, active
        Addresses bound to peer LDP Ident:
          172.16.1.4      172.16.4.2
London_PE#

Highlighted line 1 shows the remote and local LSR LDP IDs (172.16.1.4:0 and 172.16.1.0:0, respectively).

In highlighted line 2, you can see that the session state is operational (established), the number of messages sent and received are 16 and 14, respectively, and the method of label distribution is unsolicited downstream.

Highlighted line 3 shows that the session has been established for 5 seconds. In highlighted line 4, you can see that targeted (unicast) hello messages are being sent from local address 172.16.1.1 to peer address 172.16.1.4. In highlighted line 5, you can see the peer's interface IP addresses.

LDP session establishment between non-directly connected neighbors (PE routers) can fail for a number of reasons, including the following:

  • An access list blocks LDP session establishment.

  • An LDP authentication failure exits between peer PE routers.

See the section, "Access List Blocks LDP Session Establishment," earlier in this chapter (on page 622) for more information about issues with access lists.

See the section "LDP Authentication Failure," earlier in this chapter (on page 624) for more information about issues with LDP authentication.

VC Type Mismatch

If VC types are mismatched on peer PE routers, circuit setup will fail.

Use the debug mpls l2transport vc event command to troubleshoot this issue, as shown in Example 7-88.

Example 7-88. VC Type Mismatch
London_PE#debug mpls l2transport vc event
AToM vc event debugging is on
London_PE#
*Apr 19 16:12:42.275 UTC: AToM MGR [172.16.1.4, 123]: Local end up
*Apr 19 16:12:42.275 UTC: AToM MGR [172.16.1.4, 123]: Mismatch vc type in remote label
  binding, local 1, remote 6
*Apr 19 16:12:43.275 UTC: AToM MGR [172.16.1.4, 123]: Withdraw local vc label binding
London_PE#

As you can see, there is a VC mismatch between the local VC type and the remote VC type for VC ID 123 to PE router 172.16.1.4 (Paris_PE).

The VC type is then verified on London_PE and Paris_PE using the show mpls l2transport vc command, as shown in Example 7-89.

Example 7-89. VC Types on London_PE and Paris_PE
London_PE#show mpls l2transport vc 123
Local intf     Local circuit        Dest address    VC ID      Status
-------------  -------------------- --------------- ---------- ----------
Se4/0          FR DLCI 50           172.16.1.4      123        DOWN
London_PE#
________________________________________________________________
Paris_PE#show mpls l2transport vc 123
Local intf     Local circuit        Dest address    VC ID      Status
-------------  -------------------- --------------- ---------- ----------
Se2/0          HDLC                 172.16.1.1      123        DOWN
Paris_PE#

As you can see, VC ID 123 on London_PE corresponds to a Frame Relay DLCI-to-DLCI connection (highlighted line 1), and on Paris_PE to a HDLC connection (highlighted line 2)clearly a mismatch. In fact, VC ID 123 (on interface serial 2/0) should correspond to a Frame Relay DLCI-to-DLCI connection on Paris_PE. Paris_PE is, therefore, reconfigured, as shown in Example 7-90.

Example 7-90. Paris_PE Is Reconfigured
Paris_PE#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Paris_PE(config)#int s2/0
Paris_PE(config-if)#encapsulation frame-relay
Paris_PE(config-if)#frame-relay intf-type dce
Paris_PE(config-if)#exit
Paris_PE(config)#
Paris_PE(config)#connect PVCtoLondon serial 2/0 60 l2transport
Paris_PE(config-fr-pw-switching)#xconnect 172.16.1.1 123 encapsulation mpls
Paris_PE(config-fr-pw-switching)#end
Paris_PE#

In highlighted lines 1 to 4, a Frame Relay DLCI-to-DLCI connection for DLCI 60 is configured with VC ID 123 to peer 172.16.1.1 (London_PE).

Once the circuit type has been reconfigured on Paris_PE, the circuit changes state to UP. This is verified using the show mpls l2transport vc command, as shown in Example 7-91.

Example 7-91. Circuit Changes State to UP
London_PE#show mpls l2transport vc 123
Local intf     Local circuit        Dest address    VC ID      Status
-------------  -------------------- --------------- ---------- ----------
Se4/0          FR DLCI 50           172.16.1.4      123        UP
London_PE#

Note that Cisco routers now support interworking between circuit types such Frame Relay and Ethernet VLAN. This feature is available with Cisco IOS Software Release 12.0(26)S and later and is called L2VPN Interworking. See Cisco.com for more details.

VC ID Mismatch

If there is a VC ID mismatch for a circuit between peer PE routers, circuit setup will fail.

Use the show mpls l2transport vc command to verify VC IDs on peer PE routers, as shown in Example 7-92.

Example 7-92. VC IDs Are Mismatched
London_PE#show mpls l2transport vc
Local intf     Local circuit        Dest address    VC ID      Status
-------------  -------------------- --------------- ---------- ----------
Fa1/0.1        Eth VLAN 10          172.16.1.4      121        UP
Se4/0          FR DLCI 50           172.16.1.4      123        DOWN
Se4/1          HDLC                 172.16.1.4      124        UP
London_PE#
________________________________________________________________
Paris_PE#show mpls l2transport vc
Local intf     Local circuit        Dest address    VC ID      Status
-------------  -------------------- --------------- ---------- ----------
Fa0/0.1        Eth VLAN 10          172.16.1.1      121        UP
Se2/2          HDLC                 172.16.1.1      124        UP
Se2/0          FR DLCI 60           172.16.1.1      128        DOWN
Paris_PE#

A Frame Relay DLCI-to-DLCI connection should be established between interface serial 4/0 on London_PE (172.16.1.1) and interface serial 2/0 on Paris_PE (172.16.1.4). As you can see in highlighted lines 1 and 2, however, the VC IDs on London_PE and Paris_PE are mismatched (123 and 128). The VC ID for this circuit should, in fact, be 123 on both PE routers.

The VC ID for the circuit is, therefore, reconfigured on Paris_PE, as shown in Example 7-93.

Example 7-93. VC ID Is Reconfigured on Paris_PE
Paris_PE#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Paris_PE(config)#connect PVCtoLondon Serial2/0 60 l2transport
Paris_PE(config-fr-pw-switching)#xconnect 172.16.1.1 123 encapsulation mpls
Paris_PE(config-fr-pw-switching)#end
Paris_PE#

Once the VC ID has been reconfigured on Paris_PE, the circuit state changes to UP, verified using the show mpls l2transport vc command, as shown in Example 7-94.

Example 7-94. Circuit State Has Changed to UP
London_PE#show mpls l2transport vc 123
Local intf     Local circuit        Dest address    VC ID      Status
-------------  -------------------- --------------- ---------- ----------
Se4/0          FR DLCI 50           172.16.1.4      123        UP
London_PE#

The highlighted line indicates that the circuit has now changed state to UP.

MTU Mismatch

If there is an MTU size mismatch between attachment circuits on peer PE routers, VC setup will fail.

Use the debug mpls l2transport vc event or show mpls l2transport vc VCID detail commands to troubleshoot this issue.

Example 7-95 shows the output of the debug mpls l2transport vc event command.

Example 7-95. MTU Mismatch
London_PE#debug mpls l2transport vc event
AToM vc event debugging is on
London_PE#
*Apr 24 21:10:18.615 UTC: AToM MGR [172.16.1.4, 123]: Local end up
*Apr 24 21:10:18.615 UTC: AToM MGR [172.16.1.4, 123]: Mismatch MTU in remote
  label binding, local 1450, remote 1500
*Apr 24 21:10:19.615 UTC: AToM MGR [172.16.1.4, 123]: Withdraw local vc label
  binding
London_PE#

The highlighted line indicates that there is an MTU mismatch between the local and remote attachment circuits for VC ID 123 to peer 172.16.1.4 (Paris_PE). The local MTU size is 1450, and the remote MTU is 1500.

This is confirmed using the show mpls l2transport vc VCID detail command, as shown in Example 7-96.

Example 7-96. Verifying MTU Sizes
London_PE#show mpls l2transport vc 123 detail
Local interface: Se4/0 up, line protocol up, FR DLCI 50 down
  Destination address: 172.16.1.4, VC ID: 123, VC status: down
    Tunnel label: not ready
    Output interface: unknown, imposed label stack {}
  Create time: 00:04:34, last status change time: never
  Signaling protocol: LDP, peer 172.16.1.4:0 up
    MPLS VC labels: local 27, remote 18
    Group ID: local 0, remote 2
    MTU: local 1450, remote 1500
    Remote interface description:
  Sequencing: receive disabled, send disabled
  VC statistics:
    packet totals: receive 0, send 0
    byte totals:   receive 0, send 0
    packet drops:  receive 0, send 0

London_PE#

The solution is to reconfigure either London_PE or Paris_PE so that their attachment circuit MTU sizes match. In this case, the MTU size on London_PE is reconfigured using the mtu bytes command, as shown in Example 7-97.

Example 7-97. Reconfiguration of the MTU Size on London_PE
London_PE#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
London_PE(config)#interface serial 4/0
London_PE(config-if)#mtu 1500
London_PE(config-if)#end
London_PE#

Once the MTU size has been reconfigured on London_PE, the VC changes state to UP. This is verified using the show mpls l2transport vc vcid command, as shown in Example 7-98.

Example 7-98. VC State Has Changed to UP
London_PE#show mpls l2transport vc 123
Local intf     Local circuit        Dest address    VC ID      Status
-------------  -------------------- --------------- ---------- ----------
Se4/0          FR DLCI 50           172.16.1.4      123        UP
London_PE#

Peer PE Router's IP Address Is Misconfigured

If the peer PE router's IP address (LDP ID) is misconfigured in an xconnect peer_LDP_router_id VCID encapsulation mpls command, circuit setup will fail.

Use the show mpls l2transport vc command to troubleshoot this issue, as shown in Example 7-99.

Example 7-99. Peer IP Address Is Misconfigured on Paris_PE
London_PE#show mpls l2transport vc 123
Local intf     Local circuit        Dest address    VC ID      Status
-------------  -------------------- --------------- ---------- ----------
Se4/0          FR DLCI 50           172.16.1.4      123        DOWN
London_PE#
________________________________________________________________
Paris_PE#show mpls l2transport vc 123
Local intf     Local circuit        Dest address    VC ID      Status
-------------  -------------------- --------------- ---------- ----------
Se2/0          FR DLCI 60           172.16.1.11     123        DOWN
Paris_PE#

A careful examination of the destination (peer PE router) IP addresses configured for the circuit with VC ID 123 reveals that the address is correctly configured on London_PE (to 172.16.1.4, Paris_PE) but incorrectly configured on Paris_PE (to 172.16.1.11). The destination address for the circuit on Paris_PE should, in fact, be 172.16.1.1 (London_PE).

The destination IP address is then reconfigured on Paris_PE with the xconnect peer_LDP_router_id VCID encapsulation mpls command, as shown in Example 7-100.

Example 7-100. Destination IP Address Is Reconfigured on Paris_PE
Paris_PE#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Paris_PE(config)#connect PVCtoBank Serial2/0 60 l2transport
Paris_PE(config-fr-pw-switching)#xconnect 172.16.1.1 123 encapsulation mpls
Paris_PE(config-fr-pw-switching)#end
Paris_PE#

Once the destination IP address for the circuit has been reconfigured on Paris_PE, the circuit changes state to UP. This is verified using the show mpls l2transport vc [vcid] command, as shown in Example 7-101.

Example 7-101. Circuit State Is UP
London_PE#show mpls l2transport vc 123
Local intf     Local circuit        Dest address    VC ID      Status
-------------  -------------------- --------------- ---------- ----------
Se4/0          FR DLCI 50           172.16.1.4      123        UP
London_PE#


Other AToM Troubleshooting Commands

This section contains other commands and more information that may be useful when troubleshooting AToM.

show mpls l2transport vc vcid detail

The show mpls l2transport vc vcid detail command displays detailed information about AToM VCs.

Example 7-102 shows the output from this command for VC ID 123.

Example 7-102. show mpls l2transport vc vcid detail Command Output
London_PE#show mpls l2transport vc 123 detail
Local interface: Se4/0 up, line protocol up, FR DLCI 50 up
  Destination address: 172.16.1.4, VC ID: 123, VC status: up
    Tunnel label: 22, next hop 172.16.2.2
    Output interface: Fa2/0, imposed label stack {22 26}
  Create time: 00:50:50, last status change time: 00:00:47
  Signaling protocol: LDP, peer 172.16.1.4:0 up
    MPLS VC labels: local 29, remote 26
    Group ID: local 5, remote 6
    MTU: local 1500, remote 1500
    Remote interface description:
  Sequencing: receive disabled, send disabled
  VC statistics:
    packet totals: receive 6, send 56
    byte totals:   receive 596, send 3168
    packet drops:  receive 0, send 0
London_PE#

Highlighted line 1 shows that the local interface state is up and the line protocol is up. The local circuit (Frame Relay DLCI 50) is also in an up state.

The destination address (172.16.1.4, the peer PE router), together with the VC ID (123) and VC status (up), are shown in highlighted line 2.

In highlighted line 3, you can see the tunnel label (22), as well as the address of the next-hop LSR (172.16.1.2) in the path to the PE router.

Highlighted line 4 shows the outbound (core) interface for the tunnel LSP (fast Ethernet 2/0), together with the label stack imposed on tunneled Layer 2 PDUs. In this case, the label stack is 22, 26. Label 22 is the tunnel label, and 26 is the VC label.

The time when the circuit was created (00:50:50) and the time since the circuit state last changed (00:00:47) are shown in highlighted line 5.

In highlighted line 6, you can see the signaling protocol (LDP), together with the peer PE router LDP ID (172.16.1.4:0), and status (up). Highlighted line 7 shows local (29) and remote (26) VC labels for the circuit. Local (5) and remote (6) group IDs are shown in highlighted line 8.

Highlighted line 9 shows local and remote MTUs (both 1500). In highlighted line 10, you can see that send and receive sequencing for pseudowire packets is disabled. Finally, highlighted lines 11 to 13 show the number of receive and send packets, bytes, and packet drops.

show mpls l2transport hw-capability interface interface_name

This command displays the supported transport types and associated functionality on PE router interfaces.

Example 7-103 shows the output from the show mpls l2transport hw-capability interface interface_name command. Note that only a portion of the output is shown.

Example 7-103. show mpls l2transport hw-capability interface interface_name Command Output
London_PE#show mpls l2transport hw-capability interface atm 3/0
Interface ATM3/0
Transport type FR DLCI
  Core functionality:
    MPLS label disposition supported
    Control word processing supported
    Sequence number processing not supported
  Edge functionality:
    Not supported
Transport type ATM AAL5
  Core functionality:
    MPLS label disposition supported
    Control word processing supported
    Sequence number processing not supported
  Edge functionality:
    MPLS label imposition supported
    Control word processing supported
    Sequence number processing not supported
    ATM AAL5 forwarding supported
    F5 OAM cell forwarding supported
    CLP bit setting supported
    CLP bit detecting supported
    EFCI bit setting supported
    EFCI bit detecting supported

In Example 7-103, you can see the core and edge functionality supported for Frame Relay DLCI and ATM AAL5 transport types. Core functionality includes MPLS label disposition, control word processing, and sequencing. Edge functionality includes MPLS label imposition, control word processing, and sequence number processing.

In this example, you can also see that ATM AAL5 forwarding, F5 Operations, Administration, and Maintenance (OAM) cell forwarding, cell loss priority (CLP) bit setting and detecting, as well as Explicit Forward Congestion Indication (EFCI) bit setting and detecting are supported for ATM AAL5.

show mpls l2transport summary

The show mpls l2transport summary command can be used to display summary information about AToM virtual circuits.

Example 7-104 shows the output from this command.

Example 7-104. show mpls l2transport summary Command Output
show mpls l2transport summary
Destination address: 172.16.1.4, total number of vc: 4
  0 unknown, 3 up, 1 down, 0 admin down
  3 active vc on MPLS interface Fa2/0
London_PE#

Highlighted line 1 shows the destination address (172.16.1.4, the peer PE router) and the total number of VCs (4).

In highlighted line 2, you can see the number of VCs in an unknown state (0), the number in an up state (3), the number in a down state (1), and the number in an administratively down state (0).

Then in highlighted line 3, you can see that the number of VCs that are active (3) on core interfaces (here, interface fast Ethernet 2/0).

show mpls l2transport binding

The show mpls l2transport binding command displays VC label bindings, as shown in Example 7-105.

Example 7-105. Verifying VC Label Bindings
London_PE#show mpls l2transport binding
  Destination Address: 172.16.1.4,  VC ID: 121
    Local Label:  16
        Cbit: 1,    VC Type: Eth VLAN,    GroupID: 2
        MTU: 1500,   Interface Desc: n/a
    Remote Label: 17
        Cbit: 1,    VC Type: Eth VLAN,    GroupID: 1
        MTU: 1500,   Interface Desc: n/a
  Destination Address: 172.16.1.4,  VC ID: 123
    Local Label:  27
        Cbit: 1,    VC Type: FR DLCI,    GroupID: 5
        MTU: 1500,   Interface Desc: n/a
    Remote Label: 26
        Cbit: 1,    VC Type: FR DLCI,    GroupID: 6
        MTU: 1500,   Interface Desc: n/a
  Destination Address: 172.16.1.4,  VC ID: 124
    Local Label:  30
        Cbit: 1,    VC Type: HDLC,    GroupID: 6
        MTU: 1500,   Interface Desc: n/a
    Remote Label: 25
        Cbit: 1,    VC Type: HDLC,    GroupID: 8
        MTU: 1500,   Interface Desc: n/a
London_PE#

Highlighted line 1 shows the VC ID (123), as well as the associated destination PE router address (172.16.1.4).

The local VC label (27), together with the C (control word) bit setting (1), VC type (Frame Relay DLCI-to-DLCI connection), group ID (5), and MTU (1500) are shown in highlighted lines 1 to 4.

The corresponding remote VC label (26), as well as C bit setting (1), VC type (DLCI-to-DLCI connection), group ID (6), and MTU (1500) are shown in highlighted lines 5 to 7.

debug mpls l2transport signaling [event | fsm | message]

The debug mpls l2transport signaling command displays signaling protocol (LDP) information for AToM, as demonstrated in Example 7-106.

Example 7-106. debug mpls l2transport signaling message Command Output
London_PE#debug mpls l2transport signaling message
AToM LDP message debugging is on
London_PE#
*Apr 19 19:01:54.183 UTC: AToM LDP [172.16.1.4]: Received label mapping msg, id 29
  vc type 1, cbit 1, vc id 123, group id 6, vc label 24, status 0, mtu 1500
*Apr 19 19:01:55.183 UTC: AToM LDP [172.16.1.4]: Received label withdraw msg, id 30
  vc type 1, cbit 1, vc id 123, group id 6, vc label 24, status 0, mtu 0
*Apr 19 19:02:05.187 UTC: AToM LDP [172.16.1.4]: Received label mapping msg, id 32
  vc type 1, cbit 1, vc id 123, group id 6, vc label 25, status 0, mtu 1500
*Apr 19 19:02:06.415 UTC: AToM LDP [172.16.1.4]: Sending label mapping msg
  vc type 1, cbit 1, vc id 123, group id 5, vc label 25, status 0, mtu 1500
*Apr 19 19:02:07.415 UTC: AToM LDP [172.16.1.4]: Sending label withdraw msg
  vc type 1, cbit 1, vc id 123, group id 5, vc label 25, status 0, mtu 1500
*Apr 19 19:02:17.423 UTC: AToM LDP [172.16.1.4]: Sending label mapping msg
  vc type 1, cbit 1, vc id 123, group id 5, vc label 26, status 0, mtu 1500
London_PE#

In highlighted line 1, you can see London_PE has received a label mapping message from peer PE router 172.16.1.4. Information contained in the message includes VC type (1), the C (control word) bit setting, the VC ID (123), the group ID (6), the VC label (24), the status (0), and the MTU (1500).

Highlighted line 2 shows that a label withdraw message has been received. London_PE sends a label mapping message to peer PE router 172.16.1.4 in highlighted line 3. London_PE sends a label withdraw message in highlighted line 4.

debug mpls l2transport packet {data | error}

The debug mpls l2transport packet {data | error} command displays information about packets switched over AToM pseudowires, as demonstrated in Example 7-107.

Example 7-107. debug mpls l2transport packet data Command Output
London_PE#debug mpls l2transport packet data
AToM packet data debugging is on
London_PE#
*Apr 19 19:05:48.147 UTC: ATOM-FR DLCI imposition: in Se4/0, out Fa2/0, circuit id 50,
  size 32, EXP 0x0, seq 0, control word 0x220000
*Apr 19 19:05:48.147 UTC: 00 00 08 00 45 C0 00 1C 10 1D 00 00 01 02 BC DA
*Apr 19 19:05:48.147 UTC: 0A 01 01 01 E0 00 01 27 16 00 08 D8 E0 00 01 27
*Apr 19 19:05:49.147 UTC: ATOM-FR DLCI imposition: in Se4/0, out Fa2/0, circuit id 50,
  size 32, EXP 0x0, seq 0, control word 0x220000
*Apr 19 19:05:49.147 UTC: 00 00 08 00 45 C0 00 1C 10 1E 00 00 01 02 BC D8
*Apr 19 19:05:49.147 UTC: 0A 01 01 01 E0 00 01 28 16 00 08 D7 E0 00 01 28
London_PE#

Highlighted line 1 shows a Frame Relay PDU (without the header or FCS) being switched from interface serial 4/0 out over the AToM pseudowire out of core interface fast Ethernet 2/0. Other information shown includes the circuit ID (50), the Experimental (EXP) bits setting (0x0), the sequence number (0), and the control word (0x22000).

CAUTION

Exercise extra caution when using this command because it can produce copious output.

debug frame-relay events

The debug frame-relay events command displays information about the Frame Relay Address Resolution Protocol (ARP), as well as circuit status events.

Example 7-108 demonstrates sample output from this command.

Example 7-108. debug frame-relay events Command Output
London_PE#debug frame-relay events
Frame Relay events debugging is on
London_PE#
*Apr 19 18:42:04.679 UTC: FRoMPLS [172.16.1.4, 123]: Local up, sending
  acmgr_circuit_up
*Apr 19 18:42:04.679 UTC: FRoMPLS [172.16.1.4, 123]: PW pvc_status set ACTIVE
*Apr 19 18:42:04.679 UTC: FRoMPLS [172.16.1.4, 123]: Setting pw segment UP
*Apr 19 18:42:04.679 UTC: FRoMPLS [172.16.1.4, 123]: PW nni_pvc_status set ACTIVE
*Apr 19 18:42:05.679 UTC: FRoMPLS [172.16.1.4, 123]: acmgr_circuit_down
*Apr 19 18:42:05.679 UTC: FRoMPLS [172.16.1.4, 123]: PW pvc_status set INACTIVE
*Apr 19 18:42:15.683 UTC: FRoMPLS [172.16.1.4, 123]: Local up, sending
  acmgr_circuit_up
*Apr 19 18:42:15.683 UTC: FRoMPLS [172.16.1.4, 123]: PW nni_pvc_status set ACTIVE
*Apr 19 18:42:15.683 UTC: FRoMPLS [172.16.1.4, 123]: PW pvc_status set ACTIVE
*Apr 19 18:42:15.683 UTC: FRoMPLS [172.16.1.4, 123]: Setting pw segment UP
*Apr 19 18:42:15.683 UTC: FRoMPLS [172.16.1.4, 123]: Setting connection UP
London_PE#

In highlighted line 1, the pseudowire PVC status changes to active. Then in highlighted line 2, the pseudowire NNI PVC status changes to active.

debug acircuit [error | event]

The debug acircuit [error | event] command displays attachment circuit error and event information such as provisioning events, circuit up/down events, and setup/configuration failures.

Example 7-109 demonstrates sample output from the debug acircuit event command.

Example 7-109. debug acircuit event Command Output
London_PE#debug acircuit event
Attachment Circuit events debugging is on
London_PE#
*Apr 19 19:14:03.031 UTC: ACMGR: Receive <Circuit Up> msg
*Apr 19 19:14:03.031 UTC: Se4/0 ACMGR: circuit up event, SIP state chg down to
  connecting, action is service request
*Apr 19 19:14:03.031 UTC: Se4/0 ACMGR: Sent a sip service request
*Apr 19 19:14:03.035 UTC: Se4/0 ACMGR: Rcv SIP msg: resp connect forwarded, hdl
  14000008, l2ss_hdl E5000009
*Apr 19 19:14:03.035 UTC: Se4/0 ACMGR: service connected event, SIP state chg
  connecting to connected, action is respond forwarded
*Apr 19 19:14:03.035 UTC: Se4/0 ACMGR: Rcv SIP msg: resp remote up notification, hdl
  14000008, l2ss_hdl E5000009
*Apr 19 19:14:03.035 UTC: Se4/0 ACMGR: remote up event, SIP connected state no chg,
  action is ignore
*Apr 19 19:14:04.031 UTC: Se4/0 ACMGR: Receive <Circuit Down> msg
*Apr 19 19:14:04.031 UTC: Se4/0 ACMGR: circuit down event, SIP state chg connected to
  end, action is service disconnect
*Apr 19 19:14:04.031 UTC: Se4/0 ACMGR: Sent a sip service disconnect
*Apr 19 19:14:14.039 UTC: ACMGR: Receive <Circuit Up> msg
*Apr 19 19:14:14.039 UTC: Se4/0 ACMGR: circuit up event, SIP state chg down to
  connecting, action is service request
*Apr 19 19:14:14.039 UTC: Se4/0 ACMGR: Sent a sip service request
*Apr 19 19:14:14.039 UTC: Se4/0 ACMGR: Rcv SIP msg: resp connect forwarded, hdl
  9100000A, l2ss_hdl A800000B
*Apr 19 19:14:14.039 UTC: Se4/0 ACMGR: service connected event, SIP state chg
  connecting to connected, action is respond forwarded
*Apr 19 19:14:14.039 UTC: Se4/0 ACMGR: Rcv SIP msg: resp remote up notification, hdl
  9100000A, l2ss_hdl A800000B
*Apr 19 19:14:14.039 UTC: Se4/0 ACMGR: remote up event, SIP connected state no chg,
  action is ignore
London_PE#


Troubleshooting AToM: Command Summary

Table 7-3 summarizes the commands used for troubleshooting AToM in this chapter.

Table 7-3. AToM Troubleshooting Commands

Command

Parameter

Description

show cef

interface interface_name

Displays interface CEF information

show ip cef

Displays the CEF FIB

summary

Displays a summary of the CEF FIB

show mpls

interfaces

Displays information about interfaces configured for MPLS

forwarding-table

Displays the LFIB

show mpls ldp

Shows information about LDP neighbor discovery

neighbor

Shows information about LDP sessions

bindings

Displays the LIB

show mpls l2transport

binding

Displays bindings for AToM VCs

hw-capability interface interface_name

Displays information about transport types supported on router interfaces

summary

Shows summary information about AToM VCs

vc [vcid] [detail]

Shows information about AToM VCs

debug mpls

atm-ldp api

Shows information about label virtual circuits (LVCs)

debug mpls l2transport

vc {error | event}

Displays information about AToM VCs

signaling {event | message}

Displays information about AToM signaling

packet {data | error}

Displays information about AToM packet switching and errors

debug frame-relay

events

Displays Frame Relay ARP and circuit status information

debug acircuit

{error | event}

Displays error and event information for attachment circuits


Review Questions

1: | What is the innermost label in the label stack of a packet sent over an AToM pseudowire?
2: | How do the peer PE routers discover each other?
3: | How do the peer PE routers advertise VC labels to each other?
4: | If an attachment circuit changes state to down, how does the PE router indicate this state change to its peer PE router?
5: | How do LDP LSRs with directly connected interfaces discover each other?
6: | How do LSRs with directly connected interfaces establish an LDP session?
7: | Assuming that the PE routers are not in a back-to-back configuration (or directly connected via a GRE or L2TP tunnel), what is the minimum number of labels required to transport Layer 2 PDUs across an MPLS network between ingress and egress PE routers?
8: | How many LSPs are required to establish a single AToM pseudowire between peer PE routers?
9: | What is a likely cause if labels are not locally assigned to prefixes?
10: | Assuming an LDP signaled tunnel LSP, to what prefix does the tunnel (IGP) label correspond?


Chapter 8. Troubleshooting IPSec VPNs

IP Security (IPSec) provides security services for IP traffic. IPSec can be used to build secure site-to-site and remote access virtual private networks (VPNs) over a public infrastructure such as the Internet.

Site-to-site VPNs consist of IPSec tunnels built between the sites of an organization or organizations. These tunnels terminate on security gateways, such as routers and firewalls, and once established, allow transparent and secure transport of IP traffic between sites.

Figure 8-1 illustrates a simple site-to-site VPN.

Figure 8-1. Simple Site-to-Site VPN

[View full size image]

Remote access IPSec VPNs (see Figure 8-2) can also be deployed to allow remote access clients, such as a sales force, to connect back to a corporate network. In this case, an IPSec tunnel is built between the user's desktop or laptop computer and a security gateway at the corporate site.

Figure 8-2. Remote Access VPN

Previous Page
Next Page


Technical Overview of IPSec

When troubleshooting IPSec VPNs, it is very important to have a good understanding of the underlying mechanisms used to establish the IPSec tunnel and transport the traffic over it. To that end, a brief discussion of the IPSec architecture is included here.

The IPSec architecture (defined in RFC 2401) provides security services to IP traffic. These security services include integrity, data origin authentication, replay protection, data confidentiality, and limited traffic flow confidentiality.

IPSec components that provide these services include the following:

  • Security protocols

  • Security associations

  • Key management mechanisms

  • Associated authentication and encryption algorithms

The remainder of this section describes the first three components in greater detail. Authentication and encryption algorithms are discussed further in the sections "Security Protocols" on page 656 and "Configuring IPSec VPNs" on page 668.

Security Protocols

IPSec provides two security protocols that provide traffic security services to IP traffic transiting between IPSec peers:

  • Authentication Header (AH)

  • Encapsulating Security Payload (ESP)

Authentication Header

Authentication Header (AH) is a packet header that can provide message integrity, origin authentication, and, optionally, replay protection.

Message integrity and origin authentication (collectively called authentication) employ algorithms such as one-way hash functions to ensure that messages are not modified in transit and are sent by the supposed originator and not any other source. Hash functions that can be employed include Message Digest 5 (MD5) and the Secure Hash Algorithm (SHA-1).

Authentication protects the IP header (with exception of fields, such as Time-To-Live [TTL], that might change in transit), as well as the packet payload.

Replay protection ensures that messages are not re-sent by other malicious sources. Replay protection is implemented using a sequence number.

AH is identified in the preceding packet header by IP protocol number 51 and can operate in one of two modes:

  • Transport mode

  • Tunnel mode

AH Transport Mode

In transport mode, the AH is inserted into an IP packet between original IP header and the packet payload (including the UDP/TCP/other header).

Transport mode encapsulation is illustrated in Figure 8-3.

Figure 8-3. AH Transport Mode Encapsulation

Transport mode is used to protect traffic between end systems.

AH Tunnel Mode

In tunnel mode, a new IP header and AH are prepended to the original IP packet. The new header is used to transport the original packet between security gateways such as routers or firewalls.

Figure 8-4 illustrates tunnel mode encapsulation.

Figure 8-4. AH Tunnel Mode Encapsulation

Tunnel mode can be used between end systems, but is typically used to protect traffic transiting security gateways between end systems. AH can be used either on its own or in conjunction with ESP.

For more information about AH, see RFC 2402.

Encapsulating Security Payload

Encapsulating Security Payload (ESP) is a packet header with trailers that can provide message integrity, data origin authentication, confidentiality, antireplay protection, and traffic flow confidentiality.

Message integrity and authentication (collectively called authentication) perform the same functions and use the same algorithms as described in the previous section on AH. One key difference, however, is that ESP does not offer authentication of the initial IP header.

Confidentiality consists of packet encryption using algorithms such as the Data Encryption Standard (DES), Triple DES (3DES), and the Advanced Encryption Standard (AES).

Replay protection again ensures that messages are not replayed by another malicious source. Replay protection is implemented using sequence numbers.

Traffic flow confidentiality prevents traffic analysis, ensuring that eavesdroppers cannot discover information such as the volume, frequency, or packet sizes of traffic sent between any given source and destination. Traffic flow confidentiality is available only in tunnel mode.

ESP is identified in the preceding packet header by IP protocol number 50 and can operate in one of two modes:

  • Transport mode

  • Tunnel mode

ESP Transport Mode

In transport mode, an ESP header is inserted into an IP packet between the original packet header and the payload (including the UDP/TCP/other header). A trailer consisting of padding can also be added if required by the encryption algorithm. Finally, authentication data can be appended to the packet. This authentication data consists of an Integrity Check Value (ICV), which is calculated over the ESP packet.

Figure 8-5 illustrates transport mode encapsulation.

Figure 8-5. ESP Transport Mode Encapsulation

[View full size image]

Transport mode is used to protect traffic between end systems.

ESP Tunnel Mode

In tunnel mode, a new IP header and ESP header are prepended to the original IP packet. Additionally, a trailer and authentication data may be added to the packet. The new IP header is used to transport the original packet between security gateways.

Figure 8-6 illustrates tunnel mode encapsulation.

Figure 8-6. ESP Tunnel Mode Encapsulation

[View full size image]

Tunnel mode can be used to protect traffic sent between end systems, but it is typically used to protect traffic transiting security gateways between end systems.

See RFC 2406 for more details on ESP.

Security Associations

An IPSec security association (SA) is a protected connection between two end systems or security gateways, and it is unidirectional in nature. This means that for secure communication to be established between two entities, there must be at least one SA in each direction.

An SA is uniquely identified by a combination (triple) of a unique 32-bit number called a Security Parameter Index (SPI), together with a destination address and security protocol (either AH or ESP).

RFC 2401 defines two database structures, known as the Security Policy Database (SPD) and the Security Association Database (SAD or SADB).

The SPD contains IPSec policy definitions, and it is used during the processing of all inbound and outbound traffic. The SPD defines traffic that should be dropped, traffic that should be protected by IPSec, and traffic that should not protected by IPSec.

If, during traffic processing, the SPD determines that there is inbound traffic that should be protected by IPSec, but there is no SA in the SABD, that traffic will be dropped. Also, if the SPD determines that there is outbound traffic that should be protected by IPSec, but there is no SA in the SADB, this will trigger the Internet Key Exchange (IKE) protocol to negotiate the required SA with the appropriate IPSec peer.

The SADB, on the other hand, is used to store parameters associated with SAs, including information such as the SPI, algorithms, and the key. The SADB is populated either manually or dynamically via IKE negotiation.

SA and Key Management with the IKE Protocol

The IKE protocol version 1, defined in RFC 2409, provides an automated mechanism for the exchange of keying material and secure negotiation of IPSec SAs. It is also possible to manually configure keying material and SAs on IPSec peers. Manual configuration of keying material and SAs is practical only in very small-scale environments, however, so it is not discussed further in this section.

IKE is a hybrid protocol made up of elements of the following protocols:

  • Internet Security Association and Key Management Protocol (ISAKMP, RFC 2408)

  • Oakley Key Determination Protocol (RFC 2412)

  • Secure Key Exchange Mechanism for the Internet (SKEME)

NOTE

Additional elements are defined in RFC 2407 ("The Internet IP Security Domain of Interpretation for ISAKMP").

IKE operates in two phases and three modes:

  • Phase 1 Main or aggressive mode negotiation is used in this phase to establish a single bidirectional IKE SA between IPSec peers. This IKE SA, in turn, provides a secure means by which IPSec SAs can be established via quick mode negotiation.

  • Phase 2 Quick mode negotiation occurs during this phase.

Overall ISAKMP Message Format

As previously mentioned, one element of IKE is ISAKMP, which provides (among other things) a message format for IKE negotiation.

To understand IKE negotiation, it is important to have a basic understanding of the overall structure of the ISAKMP message, which is made up of a fixed header and a number of payloads. Figure 8-7 illustrates the relationship of the header to the payloads.

Figure 8-7. Overall ISAKMP Message Format

In Figure 8-7, the sample message consists of a header and four payloads. Each payload is indicated in the previous payload. For example, in the header, the Next Payload field indicates that the first payload in the chain is type X1. The Next Payload field in the X1 payload indicates that the second payload is of type X2, and so on. The final payload is indicated by the fact that the Next Payload field contains a value of 0.

Table 8-1 lists the payload types, together with their associated functions.

Table 8-1. Payload Types, Values, and Functions

Value

Payload Type

Description

0

NONE

This is the final payload

1

Security Association (SA)

Contains security attributes ([sub] payload types 2 and 3)

2

Proposal (P)

Contains information used during SA negotiation

3

Transform (T)

Contains information used for SA negotiation (for example, IKE policy information)

4

Key Exchange (KE)

Used for key exchange between peers

5

Identification (ID)

Used to exchange identification information between peers

6

Certificate (CERT)

Used to send certificates or certificate-related information

7

Certificate Request (CR)

Used to request certificates

8

Hash (HASH)

Used to exchange data generated by hash function

9

Signature (SIG)

Used to exchange data generated by digital signature function (for nonrepudiation)

10

Nonce (NONCE)

Contains random data used to indicate liveliness and to protect against replay attacks

11

Notification/Notify (N)

Used to send informational data such as error conditions

12

Delete

Used to communicate SPIs of deleted SAs to peer

13

Vendor ID (VID)

Constant value to identify a vendor; can be used to implement vendor-specific features

14127

RESERVED

Must be set to 0

128255

Private Use

Private use

For more information on ISAKMP message structures, see RFC 2408.

IKE Phase 1

As previously mentioned, the objective of IKE phase 1 is to establish a secure IKE SA and generate keys for IPSec. To this end, IPSec peers must agree on IKE parameters, exchange keying material, and authenticate each other.

These objectives are achieved using one of the following negotiation modes:

  • Main mode negotiation

  • Aggressive mode negotiation

NOTE

Before Cisco IOS Software Release 12.2(8)T, Cisco routers could not initiate aggressive mode negotiation.

Main Mode Negotiation

Main mode negotiation involves the exchange of six messages between IPSec peers. The precise form of these messages is dictated by the method of peer authentication used.

The three methods of authentication that can be used with IKE (in both main and aggressive modes) are:

  • Preshared keys

  • Rivest, Shamir, Adleman (RSA) signatures

  • RSA encrypted nonces

NOTE

Because authentication using encrypted nonces is not widely used, this section concentrates on authentication using preshared keys and RSA signatures.

Main Mode with Preshared Key Authentication

As mentioned, main mode consists of the exchange of three pairs or six messages between IPSec peers. Each of these pairs of messages serves a particular purpose.

When a router or other system (called the initiator) wants to begin IKE negotiation, it sends a message to its peer. This message contains one or more IKE policy proposals (protection suites) containing parameters such as encryption algorithm, hash algorithm, authentication method, Diffie-Hellman group, and SA lifetime. These policy proposals are contained within an SA payload and its associated Proposal and Transform payloads. IKE policy is configured on Cisco routers using the crypto isakmp policy command.

The peer router (called the responder) examines the IKE policy information and attempts to find a match with its own locally configured IKE policies. Assuming the responder finds a matching IKE policy, it responds with a message indicating acceptance of one of the initiator's policies. Again, this proposal is contained with an SA payload. The peers have now negotiated an IKE policy.

The next two messages sent between the initiator and responder serve to exchange Diffie-Hellman public values, as well as nonces (random numbers). These values are exchanged in KE and NONCE payloads, respectively (see Table 8-1).

Diffie-Hellman is a public key algorithm that allows peers to exchange public key values over an insecure network, to combine the value received with their own private value, and through the wonders of modular exponentiation, to arrive independently at the same shared secret key.

The two nonce values (initiator's and responder's), together with the preshared key, are then used to generate the first of four session key values (SKEYID).

SKEYID is used, together with the shared secret key (from the Diffie-Hellman exchange) and other keying material, to derive three other session key values called SKEYID_d, SKEYID_a, and SKEYID_e. These session key values are used to derive keys for IPSec, authenticate further ISAKMP messages, and encrypt ISAKMP messages respectively.

At this stage, an IKE policy has been agreed upon (first two messages), keying material has been exchanged (second two messages), and session key values have been calculated.

All that now remains in phase 1 is for the two peers to exchange hash and identification values, contained in HASH and ID payloads. This is done during a third exchange of messages.

The peers then authenticate each other based on the hash values received. If the received hash value is the same as a hash value calculated locally, authentication succeeds. Note that the function of the ID payload is to identify the sender using, in this case, an IP address. The third exchange in phase 1 is encrypted (using SKEYID_e).

Figure 8-8 illustrates IKE phase 1 using preshared keys.

Figure 8-8. IKE Phase 1 Using Preshared Keys

Main Mode with RSA Signature Authentication Using Digital Certificates

Main mode negotiation with RSA signature (digital certificate) authentication is very similar to main mode with preshared key authentication. The first two messages are again used to negotiate an IKE policy. The second two messages are again used to exchange keying material (Diffie-Hellman public values and nonces).

The difference is the third exchange of messages. IKE peers using RSA signature authentication exchange identification, certificates, and signature. These elements are carried in the ID, CERT, and SIG payloads respectively.

Note that the SIG (signature) payload contains a digital signature. This provides nonrepudiation, which means that the system that sent the message cannot deny that it sent the message. The ID payload can contain the system's IP address, a fully qualified domain name (FQDN), or an X.500 distinguished name, for example.

Figure 8-9 illustrates main mode with RSA signature authentication using digital certificates.

Figure 8-9. Main Mode with RSA Signature Authentication

Aggressive Mode Negotiation

Aggressive mode is faster but slightly less secure than main mode negotiation. It is faster because negotiation consists of only three messages, and it is slightly less secure because the ID payload is exchanged unencrypted.

Aggressive Mode with Preshared Key Authentication

The first message sent by the initiator in aggressive mode consists of proposed IKE policies, its Diffie-Hellman public value, a nonce value, and identification. These are contained in the SA, KE, NONCE, and ID payloads, respectively. Note that all payloads exchanged during aggressive mode perform the same function as in main mode.

The responder now replies with a message containing the accepted IKE policy, its Diffie-Hellman public value, a nonce, a hash used by the initiator to authenticate the responder, and identification. These are contained in SA, KE, HASH, and ID payloads.

Finally, the initiator sends the third and final message in the exchange. This consists simply of a hash (used by the responder to authenticate the initiator). The hash is contained in a HASH payload.

Figure 8-10 illustrates aggressive mode using preshared key authentication.

Figure 8-10. Aggressive Mode Using Preshared Key Authentication

Aggressive Mode with RSA Signature Authentication Using Digital Certificates

Aggressive mode with RSA signature (digital certificate) authentication follows a similar pattern to that for preshared keys, with three messages being exchanged.

The first message sent by the initiator contains policy proposals, its Diffie-Hellman public value, a nonce value, and identification. These are contained in SA, KE, NONCE, and ID payloads, respectively.

The responder replies with a message containing the accepted policy, its Diffie-Hellman public value, a nonce, identification, its certificate, and signature. These are contained in SA, KE, NONCE, ID, CERT, and SIG payloads.

Finally, the initiator sends a certificate and signature. These are contained in CERT and SIG payloads.

Figure 8-11 illustrates aggressive mode with RSA signature authentication using digital certificates.

Figure 8-11. Aggressive Mode with RSA Signature Authentication

IKE Phase 2

Once phase 1 is complete, and the IKE SA has been established, phase 2 can begin. The objective of phase 2 is to negotiate IPSec SAs.

There is only one mode of negotiation within phase 2, called quick mode. Note that quick mode negotiation is protected by the IKE SA established in phase 1 (using SKEYID_a and SKEYID_e). Quick mode negotiation consists of the exchange of three messages between the initiator and the responder.

The first message in the exchange contains a hash, IPSec proposals, a nonce, and optionally, another Diffie-Hellman public value, and identities. These elements are contained in HASH, SA, NONCE, KE, and ID payloads, respectively.

The hash is used to authenticate the message to the responder. The IPSec proposals are used to specify security parameters, such as the security protocol (AH or ESP), encryption algorithm, hash algorithm, and IPSec tunnel mode (transport or tunnel) to be used for the IPSec SA. These parameters are configured on Cisco routers using the crypto ipsec transform-set command.

The nonce is used to protect against replay attacks. It is also used as additional keying material. The Diffie-Hellman public value is included in the message only if the initiator is configured for Perfect Forward Secrecy (PFS). Normally, keys used with IPSec SA are derived from keying material generated during IKE phase 1. This means that IPSec keys generated using PFS are more secure. PFS is configured using the set pfs {group 1 | group 2} command (within the crypto map).

Phase 2 identities are used to exchange selector information. These identities describe the addresses, protocols, and ports for which this IPSec SA is being established. On Cisco routers, phase 2 identities are configured using a crypto access list.

The responder then replies with a message containing a hash (used by the initiator to authenticate the responder), an IPSec proposal acceptance, a nonce value, and optionally, a Diffie-Hellman public value (if the responder supports PFS), and identities. These elements are again contained in HASH, SA, NONCE, KE, and ID payloads. The payloads in the message sent by the responder serve the same purpose as those sent by the initiator.

The initiator now sends a third and final message. This contains a hash (HASH payload), and it serves to acknowledge the responder's message and to prove that the initiator is alive (that is, that the first message sent by the initiator was not just a message replayed by another source).

Figure 8-12 illustrates quick mode negotiation.

Figure 8-12. Quick Mode Negotiation

Previous Page
Next Page


Configuring IPSec VPNs

Because simple misconfiguration is the cause of many issues that arise with IPSec VPNs, this section discusses basic configuration of both site-to-site and remote access VPNs. This section also assumes that IKE is being used for SA negotiation.

Note that it is also possible to manually configure IPSec session keys on IPSec peers. This method of configuration, however, is comparatively rare, and is, therefore, not discussed further in this chapter.

NOTE

For more information concerning manual configuration of IPSec session keys, see the following URL:

http://www.cisco.com/warp/customer/707/manual.shtml

Similarly, although there are three methods of peer authentication during IKE negotiation, only preshared keys and digital signatures are widely used. The third method, encrypted nonces, is also not discussed further in this section.

NOTE

For more information about the configuration of IKE authentication with encrypted nonces, see the following URL:

http://www.cisco.com/warp/customer/707/18.html

Configuring a Site-to-Site IPSec VPN

Configuration of the site-to-site VPN varies according to whether preshared or digital certificates are used for peer authentication. This section is therefore divided into two parts:

  • Configuring site-to-site IPSec VPNs with preshared keys

  • Configuring site-to-site IPSec VPNs with digital certificates

Configuring Site-to-Site IPSec VPNs with Preshared Keys

Configuration of site-to-site IPSec VPNs using preshared keys involves six basic steps on each peer:

Step 1. | Configure the preshared key.
Step 2. | Configure the IKE policy.
Step 3. | Configure the IPSec transform set.
Step 4. | Configure the crypto access list.
Step 5. | Configure the crypto map.
Step 6. | Apply the crypto map to the external interfaces.

The sections that follow cover these steps in more detail.

Step 1: Configure the Preshared Key

When using preshared key authentication, the first step is to configure the preshared key. The preshared key should consist of an alphanumeric string and must be identical on the peer routers. The preshared key for a particular peer is configured using the crypto isakmp key key address peer_address command.

Example 8-1 shows the configuration of a preshared key.

Example 8-1. Configuration of the ISAKMP Preshared Key
crypto isakmp key cisco address 172.16.6.2

In Example 8-1, the preshared key cisco is configured for peer 172.16.6.2. This particular choice of preshared key is not secure and is used only for illustrative purposes.

The address keyword is used in conjunction with the (phase 1) identity set using the crypto isakmp identity {address | hostname} command. The default identity is address, so in this case, there is no need to configure this command.

Note that the crypto isakmp identity command should be configured with the default (IP) address option when using preshared keys.

Step 2: Configure IKE Policies

Once preshared key has been defined, the next step is to configure IKE (ISAKMP) policies. An IKE policy defines the cryptographic parameters to be used during IKE negotiation. Included in the IKE policy are the encryption algorithm, the hash algorithm, the Diffie-Hellman group, and the method of authentication. IKE policies are specified using the crypto isakmp policy priority command.

The parameters used with the IKE policy are then configured using the authentication, encryption, group, hash, and lifetime commands. These commands are used to specify the authentication method, encryption algorithm, Diffie-Hellman group, hash algorithm, and IKE SA lifetime, respectively.

Example 8-2 shows a sample IKE policy configuration.

Example 8-2. Sample IKE Policy
crypto isakmp policy 10
 hash md5
 authentication pre-share

Example 8-2 configures an IKE policy with a priority of 10. The encryption algorithm is DES, the Diffie-Hellman group is 1, the hash algorithm is MD5, the authentication method is preshared keys, and the IKE SA lifetime is 86,400 seconds. The encryption algorithm, Diffie-Hellman group, and lifetime are not shown in Example 8-2 because they are the defaults.

Table 8-2 shows the encryption algorithms, hash algorithms, Diffie-Hellman groups, methods of authentication, and lifetimes that can be configured for IKE policies on Cisco routers.

Table 8-2. Encryption Algorithms, Hash Algorithms, Diffie-Hellman Groups, Methods of Authentication, and Lifetimes That Can Be Configured for IKE Policies

Command

Parameter

Description

authentication

rsa-sig

RSA signatures (default)

rsa-encr

RSA encrypted nonces

pre-share

Preshared keys

encryption

des

56-bit DES (default)

3des

168-bit DES

aes

128-bit AES

aes 192

192-bit AES

aes 256

256-bit AES

group

group 1

768-bit Diffie-Hellman group (default)

group 2

1024-bit Diffie-Hellman group

group 5

1536-bit Diffie-Hellman group

hash

sha

SHA-1, HMAC variant (default)

md5

MD5, HMAC variant

lifetime

seconds

IKE SA lifetime, ranging from 60 to 86,400 seconds (default 86,400 seconds)

Note that multiple IKE policies can be configured with differing priorities ranging from 1 to 10,000. The policy with the highest priority has the lowest number. IKE policy negotiation between peers begins with the highest priority policy.

Also, when IKE is enabled, a default policy with a priority of 65535 is created. This policy contains the default values indicated in Table 8-2.

Step 3: Configure the IPSec Transform Set

The IPSec transform set defines the cryptographic parameters to be used by the IPSec SAs negotiated during IKE phase 2 (quick mode).

The parameters defined in the IPSec transform set are the security and compression protocols, hash algorithm, and encryption algorithm.

The transform set is configured using the crypto transform-set transform_set_name transform1 [transform2] [transform3] [transform4] command.

Example 8-3 shows a sample configuration of a IPSec transform set.

Example 8-3. Sample IPSec Transform Set
crypto ipsec transform-set mjlnettrans esp-des esp-md5-hmac

In Example 8-3, an IPSec transform set called mjlnettrans is created that specifies two transforms:

  • ESP with encryption using the DES algorithm

  • Authentication using the MD5-HMAC algorithm

NOTE

Note that it is possible to specify up to four transforms in a transform setone AH, two ESPs, and one compression.

Table 8-3 lists the security and compression protocols, as well as hash and encryption algorithms (transforms), that can be specified in an IPSec transform set.

Table 8-3. Security and Compression Protocols, Hash and Encryption Algorithms for an IPSec Transform Set

Protocol

Hash Algorithm Transform

Encryption Algorithm Transform

Compression Algorithm Transform

Description

Authentication Header (AH)

ah-md5-hmac

AH with MD5, HMAC variant; provides authentication

ah-sha-hmac

AH with SHA-1, HMAC variant; provides authentication

Encapsulating Security Payload (ESP)

esp-md5-hmac

ESP with MD5, HMAC variant; provides authentication

esp-sha-hmac

ESP with SHA-1, HMAC variant; provides authentication

esp-null

ESP with null encryption; provides authentication, but no encryption

esp-des

ESP with 56-bit DES encryption

esp-3des

ESP with 168-bit 3DES encryption

esp-aes

ESP with 128-bit AES encryption

esp-aes 192

ESP with 192-bit AES encryption

esp-aes 256

ESP with 256-bit AES encryption

IP Compression

comp-lzs

Lempel-Ziv-Stac compression

The IPSec mode can also be specified when configuring the transform set. The two available modes are as follows:

  • Tunnel mode The default mode, which is used to provide protection for user traffic transiting the router.

  • Transport mode This mode is used to provide protection for traffic in an end system to end system configuration.

You might think that tunnel mode is the only mode required when configuring IPSec on a router. This is usually the case, but when configuring protection for a Generic Routing Encapsulation (GRE), Layer Two Forwarding (L2F), or Layer Two Tunneling Protocol (L2TP) tunnel sourced by the router itself, transport mode protection can be used.

The IPSec mode is configured using the mode {tunnel | transport} command.

Transport mode could be configured for transform set mjlnettrans (from Example 8-3) as shown in Example 8-4.

Example 8-4. Configuring Transport Mode Protection
crypto ipsec transform-set mjlnettrans esp-des esp-md5-hmac
 mode transport

Step 4: Configure the Crypto Access List

Configuration of the crypto access list comes next. The crypto access list defines traffic that is protected by the IPSec transforms specified in the transform set.

The crypto access list must be an extended IP access list, as shown Example 8-5.

Example 8-5. Configuring the Crypto Access List
access-list 101 permit ip 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255

In Example 8-5, access list 101 specifies that IP traffic between networks 10.1.1.0/24 at the local site and 10.2.2.0/24 at the remote site is protected.

The crypto access list not only defines what outbound traffic is protected, but also what inbound traffic should be protected. If traffic arrives that matches the crypto access list, but is not protected in the manner defined by the transform set, the traffic is dropped.

IPSec natively protects unicast IP traffic, but if you want to protect multiprotocol or multicast traffic, you have to configure a GRE over IPSec tunnel.

If you configure a GRE tunnel, the crypto access list should be in the following form: access-list number permit gre host gre_tunnel_source_address host gre_tunnel_destination_address.

Step 5: Configure the Crypto Map

The crypto map brings together the specification of peer address, transform set, and crypto access list. In doing so, it defines what traffic will be protected and how it will be protected when sent and received from an IPSec peer.

Additionally, you can specify within the crypto map that the local router should negotiate perfect forward secrecy (PFS) with the peer when establishing new IPSec SAs.

The crypto map is configured using the crypto map map_name sequence_number ipsec-isakmp command.

The peer address, transform set, and crypto access list associated with the crypto map are configured using the set peer peer_address, set transform-set transform_set_name, and match address access_list_number commands, respectively.

PFS can optionally be configured using the set pfs {group 1 | group 2} command.

Example 8-6 shows a sample crypto map.

Example 8-6. Sample Crypto Map
crypto map mjlnetmap 10 ipsec-isakmp
 set peer 172.16.6.2
 set transform-set mjlnettrans
 match address 101

Example 8-6 defines a crypto map called mjlnetmap. An entry with sequence number 10 is configured that specifies the transform set (mjlnettrans) and crypto access list (101) that will be used with IPSec peer 172.16.6.2.

If the local router is going to establish IPSec SAs with multiple peers on a given interface, you can configure multiple entries (sequence numbers) in the crypto map, one for each peer.

If you are unsure of the addresses or parameters to be used with peers that might connect, you can configure a dynamic crypto map.

NOTE

Dynamic crypto maps are discussed further in the section entitled "Configuring Remote Access VPNs with Cisco VPN Client 3.x / 4.0," on page 682.

Step 6: Apply the Crypto Map to the External Interfaces

Once you have configured the crypto map, the next step is to apply it to an interface or interfaces. The interfaces to which the crypto map should be applied are the external interfacesthat is, the interfaces on which you expect to send and receive IPSec protected traffic to and from the remote peer.

The crypto map is applied to the interfaces using the crypto map crypto_map_name command.

In Example 8-7, crypto map mjlnetmap is applied to interface serial 4/0 using the crypto map crypto_map_name command.

Example 8-7. Applying the Crypto Map to the Interface
interface Serial4/0
 crypto map mjlnetmap

Note that only one crypto map can be applied to an interface.

NOTE

If you have configured a GRE tunnel to carry multiprotocol and multicast traffic, be sure to apply the crypto map to both the physical interface and the GRE tunnel interface if you are using a release of Cisco IOS Software before 12.2(13)T. For Cisco IOS Software Release 12.2(13)T and later, you need to apply the crypto map only to the physical interface.

IPSec protection can also be applied to a GRE tunnel using the tunnel protection command. If the crypto map is not correctly applied (or the tunnel protection command is not used), GRE tunnel traffic will not be protected by IPSec.

Configuring Site-to-Site IPSec VPNs with Preshared Keys: Sample Configuration

Example 8-8 shows a complete sample configuration of an IPSec VPN router using preshared keys.

Example 8-8. IPSec VPN Router Configuration Using Preshared Keys
Tokyo#show running-config
Building configuration...
Current configuration : 2046 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 Tokyo
!
logging buffered 16384 debugging
enable secret 5 $1$t0rF$AbPOBhIDFsyUUjfBr002y/
!
clock timezone GMT 0
ip subnet-zero
no ip source-route
ip cef
!
no ip domain-lookup
!
no ip bootp server
ip ssh time-out 120
ip ssh authentication-retries 3
!
! Configure the IKE Policy
crypto isakmp policy 10
 hash md5
 authentication pre-share
!
! Configure the pre-shared key
crypto isakmp key cisco address 172.16.6.2
!
!! Configure the IPSec transform set
crypto ipsec transform-set mjlnettrans esp-des esp-md5-hmac
!
! Configure the crypto map
crypto map mjlnetmap 10 ipsec-isakmp
 set peer 172.16.6.2
 set transform-set mjlnettrans
 match address 101
!
interface FastEthernet0/0
 ip address 10.1.1.1 255.255.255.0
 no ip redirects
 no ip proxy-arp
 no keepalive
 duplex half
 no cdp enable
!
! Apply the crypto map to the external interface
interface Serial4/0
 ip address 172.16.5.1 255.255.255.0
 no ip redirects
 no ip proxy-arp
 no fair-queue
 no cdp enable
 crypto map mjlnetmap
!
!
ip classless
ip route 0.0.0.0 0.0.0.0 172.16.5.5
no ip http server
ip pim bidir-enable
!
logging trap debugging
!
! Configure the crypto access list
access-list 101 permit ip 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255
!
line con 0
 password 7 05080F1C2243
 login
line aux 0
line vty 0 4
 password 7 121A0C041104
 login
!
!
end
Tokyo#

Configuring Site-to-Site IPSec VPNs with Digital Certificates

Configuration of site-to-site IPSec VPNs using digital certificates is very similar to that for preshared keys and involves 12 basic steps on each peer:

Step 1. | Configure the router's clock and time zone.
Step 2. | Configure the router's hostname and domain name.
Step 3. | Ensure that the certificate server is reachable.
Step 4. | Generate the router's RSA key pairs.
Step 5. | Declare the certificate authority (CA) trustpoint.
Step 6. | Authenticate the CA.
Step 7. | Enroll the router with the CA.
Step 8. | Configure the IKE policy.
Step 9. | Configure the IPSec transform set.
Step 10. | Configure the crypto access list.
Step 11. | Configure the crypto map.
Step 12. | Apply the crypto map to the external interfaces.

The sections that follow discuss Steps 1 to 8 in more detail. Steps 9 to 12 are identical to Steps 3 to 6 in the previous section ("Configuring Site-to-Site IPSec VPNs with Preshared Keys"), and so are not discussed further here. See the previous section for a discussion of these steps.

Step 1: Configure the Router's Clock and Time Zone

The first step when configuring IPSec VPNs using digital certificates is to set the clock and time zone. Use the clock set and clock timezone commands to set the router's clock and time zone, respectively.

An alternative to setting the clock manually on each router is to configure the Network Time Protocol (NTP). Using NTP is a good idea if your routers do not have hardware clocks because their clock settings will be lost in the event of a reboot. See Cisco.com for more details about configuring NTP.

Step 2: Configure the Router's Hostname and Domain Name

The next step is to configure the router's hostname and domain name using the hostname and ip domain-name commands.

Ensure that you follow the guidelines in RFC 952. These guidelines are summarized as follows:

  • The hostname should be no more than 24 characters long.

  • The name may include the AZ, 09, minus sign (-), and period (.) characters.

  • Periods should be used only to delimit parts of the domain name.

  • No blank spaces should be included in the name.

  • The first character should be an alpha character (az, AZ).

  • The last character should not be a period (.) or a minus sign(-).

The hostname is concatenated with the domain name configured on the router to produce an FQDN.

Step 3: Ensure That the Certificate Server Is Reachable

Ensure that the CA server's name is either mapped locally using the ip host name IP_address command or is resolvable via DNS.

Also ensure that the CA server is reachable using the ping command.

NOTE

Note that some public CA servers may not respond to a ping. In this case, you can test connectivity by Telnetting to them on port 80 (the Simple Certificate Enrollment Protocol (SCEP) is transported over HTTP).

Step 4: Generate the Router's RSA Key Pairs

Next you must generate the router's RSA key pairs. RSA keys are generated using the crypto key generate rsa [usage-keys | general-keys] command. By default, this command will generate a single pair of general usage keys. These keys can then be used for both encryption and signing.

If you want to use separate key pairs for encryption and signatures, specify the usage-keys keyword.

In Example 8-9, general-purpose keys with a modulus of 1024 bits are generated on the router. Note that Cisco recommends a minimum modulus of 1024 bits.

Example 8-9. General-Purpose Keys Are Generated
Tokyo#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Tokyo(config)#crypto key generate rsa
The name for the keys will be: Tokyo.mjlnet.com
Choose the size of the key modulus in the range of 360 to 2048 for your
  General Purpose Keys. Choosing a key modulus greater than 512 may take
  a few minutes.
How many bits in the modulus [512]: 1024
% Generating 1024 bit RSA keys ...[OK]
Tokyo(config)#

Step 5: Declare the CA

After generating the RSA keys, the next step is to declare the CA that will be used by the router.

Use the crypto ca trustpoint name command to declare the CA. Note that this command replaces the crypto ca identity command. Cisco routers support CAs from a number of vendors including Baltimore, Entrust, iPlanet, Microsoft, and Verisign.

In Example 8-10, the router is configured to communicate with a Microsoft CA called mjlnetca.

Example 8-10. Configuration for a Microsoft CA Server
crypto ca trustpoint mjlnetca
 enrollment mode ra
 enrollment url http://mjlnetca:80/certsrv/mscep/mscep.dll
 crl optional

In Example 8-10, the enrollment mode ra command is used to specify that the router is communicating with a Registration Authority (RA).

The URL for the CA is then specified using the enrollment url url command. This command is mandatory. Check with your CA administrator for the correct URL.

Finally, the crl optional command is used to specify that the router should accept a peer's certificate even if the certificate revocation list (CRL) is unavailable.

CAUTION

Because the crl optional command may allow peers with revoked certificates to establish an IPSec tunnel with the router, it is a good idea to consult your security policy before using this command.

Step 6: Authenticate the CA

The router now needs to authenticate the CA by obtaining its certificate.

Use the crypto ca authenticate name command to authenticate the CA server, as shown in Example 8-11.

Example 8-11. Authentication of the CA
Tokyo#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Tokyo(config)#crypto ca authenticate mjlnetca
Certificate has the following attributes:
Fingerprint: 9C514FE0 A4A56F42 8612D771 6AC073FC
% Do you accept this certificate? [yes/no]: yes
Trustpoint CA certificate accepted.
Tokyo(config)#

In Example 8-11, a CA server called mjlnetca is authenticated.

Note that a fingerprint is displayed. The CA administrator should also be able to see the fingerprint of the certificate. If the two fingerprints are the same, then you know that the certificate is valid and can be accepted.

Step 7: Enroll the Router with the CA

By enrolling the router with the CA, you obtain a certificate for each RSA key pair on the router.

Use the crypto ca enroll name command to enroll the router with the CA, as demonstrated in Example 8-12.

Example 8-12. Router Enrollment with the CA
Tokyo(config)#crypto ca enroll mjlnetca
%
% Start certificate enrollment ..
% Create a challenge password. You will need to verbally provide this
   password to the CA Administrator in order to revoke your certificate.
   For security reasons your password will not be saved in the configuration.
   Please make a note of it.
Password:
Re-enter password:
% The fully-qualified domain name in the certificate will be: Tokyo.mjlnet.com
% The subject name in the certificate will be: Tokyo.mjlnet.com
% Include the router serial number in the subject name? [yes/no]: no
% Include an IP address in the subject name? [no]: no
Request certificate from CA? [yes/no]: yes
% Certificate request sent to Certificate Authority
% The certificate request fingerprint will be displayed.
% The 'show crypto ca certificate' command will also show the fingerprint.
Tokyo(config)#    Fingerprint:  259CD7C2 C194427A 304F0670 975570F3
Tokyo(config)#

In Example 8-12, router Tokyo enrolls with CA server mjlnetca. Note that the router's FQDN (Tokyo.mjlnet.com) is included in the certificate (highlighted line 1). You can also choose to include the router's serial number and IP address in the certificate's subject name as indicated in highlighted lines 2 and 3.

NOTE

It is also worth remembering that the certificate request must be approved by the CA administrator before the certificate is issued.

Step 8: Configure the IKE Policy

When configuring the IKE policy using digital certificates, you must specify rsa-sig as the authentication method.

Example 8-13 shows a sample configuration of IKE policy when using digital certificates.

Example 8-13. IKE Policy with RSA Signature Authentication
crypto isakmp policy 10
 hash md5

In the IKE policy shown in Example 8-13, the method of authentication is RSA signatures, the encryption algorithm is DES, the Diffie-Hellman group is 1, the hash algorithm is MD5, and the lifetime is 86,400 seconds. With the exception of the hash algorithm, all of these parameters are the defaults and are therefore not shown.

That completes the configuration of site-to-site IPSec VPNs.

Configuring Remote Access VPNs with Cisco VPN Client 3.x / 4.0

Cisco routers running Cisco IOS Software Release 12.2(8)T or later can be configured to support connections from Cisco VPN Client 3.x/4.0.

There are ten steps involved in configuring support for Cisco VPN Client 3.x/4.0 (with local authentication):

Step 1. | Configure the local username database.
Step 2. | Configure authentication, authorization, and accounting (AAA).
Step 3. | Configure the local IP address pool.
Step 4. | Configure IKE policies.
Step 5. | Configure the split tunneling access list (optional).
Step 6. | Configure the VPN Client group policy profile.
Step 7. | Configure the IPSec transform set.
Step 8. | Configure the dynamic crypto map.
Step 9. | Configure IKE extended authentication, client mode address configuration, and a crypto profile for remote clients.
Step 10. | Apply the crypto map to the external interface.

The sections that follow describe these steps in greater detail.

Step 1: Configure the Local Username Database

If you are using local authentication, the first step in configuring support for Cisco VPN Client 3.x/4.0 is to configure the local username database, as demonstrated in Example 8-14.

Example 8-14. Configuration of the Local Username Database
username nakano password cisco

In Example 8-14, username nakano is specified with password cisco.

The usernames and passwords specified here correspond to those that remote users have to enter during extended authentication (XAuth).

Extended authentication takes place after IKE phase 1, and it allows the user of the remote device, in addition to the device itself, to be authenticated. The device is authenticated during IKE phase 1.

Step 2: Configure AAA

The next step is the configuration of AAA, as demonstrated in Example 8-15.

Example 8-15. Configuration of AAA
aaa new-model
aaa authentication login mjlnetUsers local
aaa authorization network mjlnet local

In Example 8-15, the aaa new-model command is used to enable AAA.

Next comes the aaa authentication login mjlnetUsers local command, which defines the authentication method list mjlnetUsers. This method list specifies that the method used for login authentication should be the local username database.

Finally, the aaa authorization network mjlnet local command defines the mjlnet method list for network authorization. This method list specifies that the method used for network authorization should be local.

Step 3: Configure the Local IP Address Pool

An IP address pool from which addresses are assigned to remote access clients is configured in Step 3.

The IP address pool is configured using the ip local pool name start_address end_address command.

Example 8-16 shows a sample IP address pool.

Example 8-16. Configuration of the IP Address Pool
ip local pool mjlnetPool 10.2.2.1 10.2.2.253

In Example 8-16, IP address pool mjlnetPool is configured on the router. This pool contains IP addresses in the range 10.2.2.110.2.2.253.

Step 4: Configure IKE Policies

After AAA is configured, the next step is to configure the IKE policy, as demonstrated in Example 8-17.

Example 8-17. IKE Policy for Cisco VPN Client 3.x/4.0
crypto isakmp policy 10
 hash md5
 authentication pre-share
 group 2

The IKE policy in Example 8-17 specifies an ISAKMP (IKE) policy with a priority of 10. This policy specifies that the authentication method is pre-share, the encryption algorithm is DES (the default), the Diffie-Hellman group is 2, the hash algorithm is MD5, and the lifetime is 86,400 seconds (the default).

For more details about parameters that can be configured in IKE policies see the section "Configuring a Site-to-Site IPSec VPN" on page 669.

Step 5: Configure the Split Tunneling Access List (Optional)

An access list that is used to enable split tunneling can now be configured. Split tunneling is used so that the remote access clients will send only traffic destined for the corporate network via the IPSec tunnel.

Example 8-18 demonstrates the configuration of the split tunneling access list.

Example 8-18. Split Tunneling Access List
access-list 101 permit ip 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255

The access list in Example 8-18 will ensure that traffic from network 10.2.2.0/24 (allocated to the clients from the local address pool) to network 10.1.1.0/24 (the corporate network) will travel over the IPSec tunnel.

CAUTION

When configuring split tunneling for remote access clients, you should ensure that the client operating systems are sufficiently secured using a personal firewall so that they do not become a security risk to the main corporate network.

Step 6: Configure the VPN Client Group Policy Profile

The group policy profile is used to specify parameters such as the preshared key used for IKE authentication and client configuration parameters. Example 8-19 shows a sample group policy profile.

Example 8-19. Sample Group Policy Profile
crypto isakmp client configuration group mjlnetVPN
 key cisco
 dns 10.1.1.100
 wins 10.1.1.101
 pool mjlnetPool
 acl 101

Example 8-20 shows a group policy profile called mjlnetVPN. This profile defines the preshared key (key pre-shared-key), DNS and WINS server addresses (dns server_address, wins server_address), the IP address pool from which addresses will be assigned to remote access clients (pool pool_name, specified in Step 3), and the access list that will be used to enforce split tunneling on the clients (acl access-list_number, specified in Step 5). The DNS and WINS server addresses, as well as the assigned address from the IP address pool, are all pushed to the remote access client during mode configuration (Mode Config). These parameters are pushed to the remote access client after extended authentication (XAuth).

The group policy profile name (in this example, mjlnetVPN) and preshared key must match the name and the password specified under Group Access Information in the New Connection Entry Wizard of Cisco VPN Client 3.x, or the name and password specified under Group Authentication in the Create New VPN Connection Entry Wizard of Cisco VPN Client 4.0.

Step 7: Configure the IPSec Transform Set

The next step is the configuration of the IPSec transform set, as demonstrated in Example 8-20.

Example 8-20. IPSec Transform Set
crypto ipsec transform-set mjlnetTrans esp-des esp-md5-hmac

In this example, the transform set (mjlnetTrans) specifies two transforms. These are ESP with encryption using the DES algorithm, and authentication using the MD5-HMAC algorithm.

Step 8: Configure the Dynamic Crypto Map

Step 8 is to configure the dynamic crypto map, which allows the router to negotiate SAs with remote access clients when not all parameters are known. This is essential because it is difficult or impossible to know the IP address of remote access clients when they connect to the router over the Internet.

The dynamic crypto map is created using the crypto dynamic-map name sequence_number command.

Example 8-21 shows a sample dynamic crypto map.

Example 8-21. Dynamic Crypto Map
crypto dynamic-map mjlnetDyn 10
 set transform-set mjlnetTrans

In Example 8-21, the dynamic crypto map mjlnetDyn is created. The transform set mjlnetTrans (configured in Step 7) is then specified.

One other very useful command that you might want to configure with the dynamic crypto map is the reverse-route command. When used with dynamic crypto maps, this command causes static routes corresponding to IPSec SAs negotiated with remote clients to be placed into the routing table. These routes can then be redistributed into a routing protocol as required.

Step 9: Configure IKE Extended Authentication, Authorization, Client Mode Address Configuration, and a Crypto Profile for Remote Clients

The next step is to configure IKE extended authentication, authorization, client mode configuration, and a crypto profile.

Extended authentication is configured on a crypto map using the crypto map name client authentication list method_list_name command.

Authorization on the crypto map is configured using the crypto map name isakmp authorization list method_list_name command.

Client mode address configuration is specified using the crypto map name client configuration address {initiate | respond} command. The initiate keyword specifies that the router should attempt to configure an IP address for the clients. The respond keyword specifies that the router can accept requests for IP address configuration from the clients.

Finally, the crypto map name sequence_number ipsec-isakmp dynamic dynamic_map_name command is used to configure a crypto profile that provides a template used to create dynamic crypto maps.

Example 8-22 shows sample configurations of these commands.

Example 8-22. Configuration of Extended Authentication, Authorization, Client Address, and Crypto Profile
crypto map mjlnetMap client authentication list mjlnetUsers
crypto map mjlnetMap isakmp authorization list mjlnet
crypto map mjlnetMap client configuration address respond
crypto map mjlnetMap 10 ipsec-isakmp dynamic mjlnetDyn

In Example 8-22, extended authentication is configured using the mjlnetUsers method list (specified in Step 2), authorization is configured using method list mjlnet (specified in Step 2), client mode address configuration is specified so that the router will respond to client IP address requests, and a crypto profile is created using the dynamic crypto map created in Step 8.

Step 10: Apply the Crypto Map to the External Interface

The last step is to apply the crypto map to the external interface, as demonstrated in Example 8-23.

Example 8-23. Apply the Crypto Map to the External Interface
interface Serial4/0
 crypto map mjlnetMap

In Example 8-23, the crypto map (with the name specified in Step 9) is applied to the external interface.

That completes the configuration of the router for a remote access VPN.

IPSec Remote Access VPN Gateway: Sample Configuration

Example 8-24 shows a complete sample configuration of an IPSec remote access VPN gateway.

Example 8-24. Sample IPSec Remote Access VPN Gateway Configuration
[View full width]
Tokyo#show running-config
Building configuration...
Current configuration : 2543 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 Tokyo
!
logging buffered 16384 debugging
enable secret 5 $1$ABA3$Wmyspeir29lZ9Enrp.rr50
!
! Configure the local username database
username koenji password 7 121A0C041104
username nakano password 7 05080F1C2243
username shinjuku password 7 110A1016141D
username roppongi password 7 05080F1C2243
clock timezone GMT 0
!
! Configure AAA
aaa new-model
aaa authentication login mjlnetUsers local
aaa authorization network mjlnet local
aaa session-id common
ip subnet-zero
no ip source-route
ip cef
!
!
!
no ip bootp server
!
! Configure IKE policies
crypto isakmp policy 10
 hash md5
 authentication pre-share
 group 2
!
! Configure the VPN Client group policy profile
crypto isakmp client configuration group mjlnetVPN
 key cisco
 dns 10.1.1.100
 wins 10.1.1.101
 pool mjlnetPool
 acl 101
!
!
! Configure the IPSec transform set
crypto ipsec transform-set mjlnetTrans esp-des esp-md5-hmac
!
! Configure the dynamic crypto map
crypto dynamic-map mjlnetDyn 10
 set transform-set mjlnetTrans
!
! Configure IKE extended authentication, client mode address configuration, and a crypto
   profile for remote clients
crypto map mjlnetMap client authentication list mjlnetUsers
crypto map mjlnetMap isakmp authorization list mjlnet
crypto map mjlnetMap client configuration address respond
crypto map mjlnetMap 10 ipsec-isakmp dynamic mjlnetDyn
!
interface FastEthernet0/0
 ip address 10.1.1.254 255.255.255.0
 no ip redirects
 no ip proxy-arp
 duplex half
 no cdp enable
!
! Apply the crypto map to the external interface
interface Serial4/0
 ip address 172.16.5.1 255.255.255.0
 no ip redirects
 no ip proxy-arp
 serial restart_delay 0
 no fair-queue
 no cdp enable
 crypto map mjlnetMap
!
!
! Configure the local IP address pool
ip local pool mjlnetPool 10.2.2.1 10.2.2.253
ip classless
ip route 0.0.0.0 0.0.0.0 172.16.5.5
no ip http server
ip pim bidir-enable
!
logging trap debugging
!
! Configure the split tunneling access list
access-list 101 permit ip 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255
no cdp run
!
line con 0
line aux 0
line vty 0 4
end
Tokyo#

Maximum Transmission Unit (MTU) Issues with IPSec

When using IPSec tunnels to transport traffic between sites, or from a remote access client to a security gateway, you should be aware of Maximum Transmission Unit (MTU) issues that may result.

IPSec adds significant overhead to the regular IP packet. The size of the overhead depends on the security protocol, the choice of tunnel or transport mode, encryption padding, and the size of the authentication data field, with padding and authentication data being of variable size.

A good rough starting point when calculating IPSec tunnel mode overhead is 60 bytes (with ESP encryption and authentication). If you are using transport mode, you save 20 bytes because a new IP header is not prepended to the packet (compare the figures from 8-3 to 8-6). If you are using GRE over IPSec to transport multiprotocol and multicast packets, this will add a further 24 bytes (GRE header [4 bytes] + additional IP header [20 bytes]).

There are two issues with large IPSec packets:

  • Large IPSec packets may become fragmented if the packet size is greater than the outgoing interface MTU of any of the routers in the path between IPSec peers, and the Don't Fragment (DF) bit is not set in the IP header of IPSec packets (the DF bit setting is copied from the original IP packet). Fragments cause high overhead on the receiving IPSec router, because it reassembles them.

  • If Path MTU Discovery (PMTUD), a mechanism used to detect the smallest link MTU over a network, is broken, then large packets may be dropped if the Don't Fragment (DF) bit is set in the packet header. When a router in the path between the IPSec peers needs to fragment a large IPSec packet because it is larger than the router's outgoing interface MTU, and the DF bit in the IP header of the tunnel packet is set, the router should send an Internet Control Message Protocol unreachable message (ICMP message type 3, code 4) back to the IPSec router that sent the IPSec packet. This message should specify that fragmentation is required but that the DF bit is set; at this point, the IPSec router should decrease the size of packets that it sends. PMTUD breaks if a router in the path between IPSec peers does not send ICMP unreachable messages when it should, or a firewall blocks these messages.

There are a number of ways around these issues:

  • If possible, you should reconfigure firewalls to permit ICMP unreachable (type 3, code 4) messages.

  • You can configure IPSec routers to perform fragmentation of large IP packets before encrypting them. If packets are fragmented before encryption, then reassembly is performed on the end host (destination of the protected IP packet), and not on the remote IPSec router.

  • If you are using a GRE tunnel with IPSec, you can configure the tunnel path-mtu-discovery command on the GRE tunnel interface. This enables PMTUD support on the GRE tunnel interface.

  • If you are using a GRE tunnel with IPSec, you can also configure the router to dynamically reduce the Maximum Segment Size (MSS) value in TCP SYN packets sent over the tunnel using the ip tcp adjust-mss commands. This will cause end hosts to send smaller TCP segments (and IP packets).

  • As a last resort, you can clear the DF bit on packets before they are sent over the IPSec tunnel. Clearing the DF bit allows IPSec packets to be fragmented and can therefore cause high CPU overhead on the remote IPSec peer as packets are reassembled.

NOTE

A fuller discussion of these issues is beyond the scope of this chapter, but further details can be found in the following articles:

http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a0080115533.html

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122t/122t2/ftdfipsc.htm

TIP

You can modify the Cisco VPN Client MTU size by using the Set MTU application (available from the Start menu on Microsoft clients).


Troubleshooting IPSec VPNs

When troubleshooting IPSec VPNs, it is important to adopt a step-by-step approach.

The first step in troubleshooting IPSec VPNs is to verify IKE phase 1 negotiation between the peer routers. Once this has been verified, the next step is to verify IKE phase 2. In the final step, you should verify that user traffic is being transported successfully over the IPSec tunnel.

The flowchart in Figure 8-13 describes the troubleshooting process used with IPSec VPNs. You can use this flowchart to quickly access the section of the chapter relevant to problems you are experiencing on your network.

Figure 8-13. IPSec VPN Troubleshooting Flowchart

Refer to the sample topology in Figure 8-14 for the various concepts discussed in the troubleshooting sections that follow. You may also find it useful to refer back to Table 8-1 as you read command output.

Figure 8-14. Sample IPSec VPN Topology

[View full size image]

In this example, the initiator of IKE negotiation is called Tokyo, and the responder is called Osaka. When troubleshooting IPSec, it is a good idea to start on the initiator, which in this scenario is Tokyo.

IKE Phase 1 (Main Mode) Negotiation Fails

Two peers attempting to establish an IPSec tunnel must complete IKE negotiation.

IKE negotiation is in two parts:

  • Phase 1, which is used to establish an IKE SA

  • Phase 2, which is used to establish IPSec SAs

If IKE phase 1 negotiation fails, phase 2 cannot begin, and no IPSec SAs will be established. Figure 8-15 illustrates Phase 1 negotiation.

Figure 8-15. IKE Phase 1 Negotiation

[View full size image]

Before troubleshooting IKE phase 1, it is worth examining a successful IKE negotiation sequence using the debug crypto isakmp command.

Examples 8-25 to 8-28 show successful IKE main mode negotiation. Note that only the relevant portion of the output is shown.

Example 8-25. Successful IKE Main Mode Negotiation
Tokyo#debug crypto isakmp
Crypto ISAKMP debugging is on
Tokyo#
Mar  7 16:14:29.027 GMT: ISAKMP: received ke message (1/1)
Mar  7 16:14:29.027 GMT: ISAKMP: local port 500, remote port 500
Mar  7 16:14:29.027 GMT: ISAKMP (0:1): Input = IKE_MESG_FROM_IPSEC, IKE_SA_REQ_MM
Old State = IKE_READY  New State = IKE_I_MM1
Mar  7 16:14:29.027 GMT: ISAKMP (0:1): beginning Main Mode exchange
Mar  7 16:14:29.027 GMT: ISAKMP (0:1): sending packet to 172.16.6.2 (I) MM_NO_STATE

In highlighted line 1, you can see the message Old State = IKE_READY New State = IKE_I_MM1. This indicates that IKE negotiation has been initiated, and the first ISAKMP message in the main mode exchange is about to be sent. Note the I in the message here. This character indicates that Tokyo is the initiator of IKE negotiation. If Tokyo were the responder, then an R would be shown.

Highlighted line 2 shows that IKE main mode is about to begin. In highlighted line 3, main mode begins with Tokyo (the initiator) sending IKE SA proposals to Osaka (172.16.6.2, the responder). These proposals correspond to the policies configured on Tokyo (crypto isakmp policy policy_number).

In Example 8-26, a proposal acceptance is received from Osaka.

Example 8-26. Received Proposal Acceptance from Osaka (the Responder)
Mar  7 16:14:29.067 GMT: ISAKMP (0:1): received packet from 172.16.6.2 (I) MM_NO_STATE
Mar  7 16:14:29.067 GMT: ISAKMP (0:1): Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
Old State = IKE_I_MM1  New State = IKE_I_MM2
Mar  7 16:14:29.067 GMT: ISAKMP (0:1): processing SA payload. message ID = 0
Mar  7 16:14:29.067 GMT: ISAKMP (0:1): found peer pre-shared key matching 172.16.6.2
Mar  7 16:14:29.067 GMT: ISAKMP (0:1): Checking ISAKMP transform 1 against priority 10
  policy
Mar  7 16:14:29.067 GMT: ISAKMP:      encryption DES-CBC
Mar  7 16:14:29.067 GMT: ISAKMP:      hash MD5
Mar  7 16:14:29.067 GMT: ISAKMP:      default group 1
Mar  7 16:14:29.067 GMT: ISAKMP:      auth pre-share
Mar  7 16:14:29.067 GMT: ISAKMP:      life type in seconds
Mar  7 16:14:29.067 GMT: ISAKMP:      life duration (VPI) of  0x0 0x1 0x51 0x80
Mar  7 16:14:29.067 GMT: ISAKMP (0:1): atts are acceptable. Next payload is 0
Mar  7 16:14:29.103 GMT: ISAKMP (0:1): SA is doing pre-shared key authentication using
  id type ID_IPV4_ADDR
Mar  7 16:14:29.103 GMT: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
Old State = IKE_I_MM2  New State = IKE_I_MM2

A message is now received from Osaka (highlighted line 1). This message contains the accepted proposal (one out of those sent in Tokyo's initial message in Example 8-25, highlighted line 2).

Highlighted line 2 shows that the state has moved from IKE_I_MM1 to IKE_I_MM2, indicating that this is the second message in the IKE exchange.

Tokyo now begins to process the SA payload, which contains the accepted proposal, in highlighted line 3. Note the message ID here. The function of the message ID is to distinguish messages for different phase 2 exchanges (SAs) from each other, and so it remains as zero throughout main mode negotiation.

In highlighted lines 4 to 9, you can see the accepted proposal. The proposal, in this case, consists of DES encryption, the MD5 hash algorithm, preshared key authentication, and an SA lifetime of 86,400 seconds (seen in hexadecimal notation in highlighted line 9).

Then in highlighted line 10, Tokyo reports that these proposal attributes are acceptable. Tokyo and Osaka have now negotiated the parameters (attributes) of the IKE SA, and are now ready to exchange Diffie-Hellman public values and nonces (random numbers), as demonstrated in Example 8-27.

Example 8-27. Exchange of Diffie-Hellman Public Values and Nonces (Messages Three and Four)
Mar  7 16:14:29.103 GMT: ISAKMP (0:1): sending packet to 172.16.6.2 (I) MM_SA_SETUP
Mar  7 16:14:29.107 GMT: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
  Old State = IKE_I_MM2  New State = IKE_I_MM3
Mar  7 16:14:29.147 GMT: ISAKMP (0:1): received packet from 172.16.6.2 (I) MM_SA_SETUP
Mar  7 16:14:29.147 GMT: ISAKMP (0:1): Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
  Old State = IKE_I_MM3  New State = IKE_I_MM4
Mar  7 16:14:29.147 GMT: ISAKMP (0:1): processing KE payload. message ID = 0
Mar  7 16:14:29.183 GMT: ISAKMP (0:1): processing NONCE payload. message ID = 0
Mar  7 16:14:29.183 GMT: ISAKMP (0:1): found peer pre-shared key matching 172.16.6.2
Mar  7 16:14:29.183 GMT: ISAKMP (0:1): SKEYID state generated
Mar  7 16:14:29.183 GMT: ISAKMP (0:1): processing vendor id payload
Mar  7 16:14:29.183 GMT: ISAKMP (0:1): speaking to another IOS box!
Mar  7 16:14:29.187 GMT: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
Old State = IKE_I_MM4  New State = IKE_I_MM4

Highlighted line 1 shows Tokyo sending its Diffie-Hellman public value and nonce value to Osaka. In highlighted line 2, the state changes to IKE_I_MM3, indicating that the third message in the IKE exchange has been sent.

A response is now received from Osaka (highlighted line 3). Highlighted line 4 shows that the state has now changed to IKE_I_MM4, indicating that this response was the fourth message in the main mode exchange.

Tokyo now begins to process the packet received from Osaka, beginning with the KE (Key Exchange) and NONCE payloads in highlighted lines 5 and 6. These payloads contain Osaka's Diffie-Hellman public value and nonce value.

Note also the vendor ID payload shown in highlighted lines 8 and 9. As you can see, the vendor ID indicates that this message is from another Cisco IOS router.

In highlighted line 7, the message SKEYID state generated is displayed. This indicates that Tokyo has generated keying material (session keys SKEYID_d, SKEYID_e, and SKEY_a) used for deriving IPSec keys, and encrypting and authenticating remaining main mode and quick mode ISAKMP messages.

IKE peer authentication now begins with Tokyo and Osaka exchanging main mode messages five and six, as shown in Example 8-28.

Example 8-28. Exchange of ISAKMP Messages Five and Six
Mar  7 16:14:29.187 GMT: ISAKMP (1): ID payload
    next-payload : 8
    type         : 1
    protocol     : 17
    port         : 500
    length       : 8
Mar  7 16:14:29.187 GMT: ISAKMP (1): Total payload length: 12
Mar  7 16:14:29.187 GMT: ISAKMP (0:1): sending packet to 172.16.6.2 (I) MM_KEY_EXCH
Mar  7 16:14:29.187 GMT: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
Old State = IKE_I_MM4  New State = IKE_I_MM5
Mar  7 16:14:29.191 GMT: ISAKMP (0:1): received packet from 172.16.6.2 (I) MM_KEY_EXCH
Mar  7 16:14:29.191 GMT: ISAKMP (0:1): Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
Old State = IKE_I_MM5  New State = UNKNOWN
Mar  7 16:14:29.191 GMT: ISAKMP (0:1): processing ID payload. message ID = 0
Mar  7 16:14:29.191 GMT: ISAKMP (0:1): processing HASH payload. message ID = 0
Mar  7 16:14:29.191 GMT: ISAKMP (0:1): SA has been authenticated with 172.16.6.2
Mar  7 16:14:29.191 GMT: ISAKMP (0:1): Input = IKE_MESG_INTERNAL,
  IKE_PROCESS_MAIN_MODE
Old State = UNKNOWN  New State = UNKNOWN
Mar  7 16:14:29.191 GMT: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
Old State = UNKNOWN  New State = IKE_P1_COMPLETE

In highlighted line 1, Tokyo sends an ISAKMP message to Osaka. This message contains ID and HASH payloads. The ID payload is used for identification, and the HASH payload is used for authentication.

Then in highlighted line 2, the state changes to IKE_I_MM5, indicating that the fifth message in the IKE exchange has been sent.

The response is received from Osaka in highlighted line 3. This is the sixth and final message in the IKE main mode exchange. Contained within the message from Osaka are again ID and HASH payloads. These payloads are processed in highlighted lines 4 and 5.

Osaka is then authenticated by Tokyo in highlighted line 6. In highlighted line 7, the state changes to IKE_P1_COMPLETE, indicating that main mode (phase 1) has been completed.

To verify that phase 1 has been successfully negotiated, use the show crypto isakmp sa command, as demonstrated in Example 8-29.

Example 8-29. Main Mode Successfully Negotiated
Tokyo#show crypto isakmp sa
dst             src             state           conn-id    slot
172.16.6.2      172.16.5.1      QM_IDLE               1       0
Tokyo#

In highlighted line 1, you can see that the IKE SA has been successfully negotiated between Tokyo (172.16.5.1) and Osaka (172.16.6.2). Note that the state QM_IDLE indicates that the IKE SA has been successfully negotiated and that quick mode is in a latent state. Table 8-4 shows the different states that you might see when using this command.

Table 8-4. IKE States Shown in the Output of the show crypto isakmp sa Command

IKE Mode

State

Description

Main Mode (Phase 1)

MM_NO_STATE

IKE (ISAKMP) negotiation has been initiated for main mode.

MM_SA_SETUP

IKE (ISAKMP) parameters has been agreed.

MM_KEY_EXCH

A shared secret has been generated (based on Diffie-Hellman public key exchange).

MM_KEY_AUTH

The IKE (ISAKMP) SA has been authenticated (quick mode is about to begin).

Aggressive Mode (Phase 1)

AG_NO_STATE

IKE (ISAKMP) negotiation has been initiated for aggressive mode.

AG_INIT_EXCH

The first exchange has taken place.

AG_AUTH

The IKE (ISAKMP) SA has been authenticated (quick mode is about to begin).

Quick Mode (Phase 2)

QM_IDLE

The IKE (ISAKMP) SA has been negotiated, and quick mode is in a latent state.

NOTE

When troubleshooting IKE, it may be necessary to clear the IKE and IPSec SAs. To do this, use the clear crypto isakmp and clear crypto ipsec sa commands.

IKE main mode can fail for a number of reasons. These reasons fall into one of the following five summarized categories:

  • The IKE negotiation is not initiated.

  • The responder does not receive ISAKMP messages from the initiator.

  • The responder does not have a preshared key, certificate, or route to the initiator.

  • An IKE policy mismatch exists.

  • IKE authentication fails.

These IKE phase 1 negotiation failures are discussed in the following few sections.

Note that if there is a NAT device in the path between the initiator and the responder, it is also possible for this to cause IKE negotiation failure. See the section entitled "NAT Device Blocks IPSec Traffic" for more details.

IKE Negotiation Is Not Initiated

If IKE negotiation is not initiated (as indicated by a lack of appropriate output from the debug crypto isakmp commandsee Example 8-25), this can indicate a number of problems, including the following:

  • A routing issue exists on the initiator.

  • The crypto map is applied to the wrong interface (or not applied at all).

  • The crypto access list is misconfigured.

  • The peer's IP address is misconfigured, or the router has not generated RSA keys, authenticated the CA, and obtained a certificate.

  • ISAKMP is disabled.

These issues are discussed in the sections that follow.

Routing Issue Exists on the Initiator

If packets are not being routed out of the interface to which the crypto map is applied, IKE main mode negotiation will not be triggered.

Check that the router initiating the tunnel has a route to the peer router and to the destination address specified in the crypto access list. Also make sure that the route's next-hop is out of the interface with the crypto map applied to it.

Use the show ip route command to verify the initiator's routing table, as shown in Example 8-30.

Example 8-30. Routing Table on Tokyo
Tokyo#show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
       * - candidate default, U - per-user static route, o - ODR
       P - periodic downloaded static route
Gateway of last resort is not set
     172.16.0.0/24 is subnetted, 1 subnets
C       172.16.5.0 is directly connected, Serial4/0
     10.0.0.0/24 is subnetted, 1 subnets
C       10.1.1.0 is directly connected, FastEthernet0/0
Tokyo#

As you can see, there is not a route to the peer (172.16.6.2) nor to the address specified in the crypto map (in this example, 10.2.2.0/24).

In this example, a default route is added to provide IP reachability to both, as shown in Example 8-31.

Example 8-31. Default Route Is Added for Peer Reachability
Tokyo#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Tokyo(config)#ip route 0.0.0.0 0.0.0.0 172.16.5.5
Tokyo(config)#exit
Tokyo#

Once the default route has been added, IKE main mode negotiation succeeds. This is verified using the show crypto isakmp sa command (see Example 8-32).

Example 8-32. IKE Main Mode Negotiation Succeeds
Tokyo#show crypto isakmp sa
dst             src             state           conn-id    slot
172.16.6.2      172.16.5.1      QM_IDLE               1       0
Tokyo#

As you can see, IKE main mode negotiation has succeeded, and quick mode is in an idle state (QM_IDLE).

Crypto Map Is Applied to the Wrong Interface or Is Not Applied at All

If the crypto map is not applied to the correct interfaces or is not applied at all, IKE main mode negotiation will not be initiated.

Crypto maps should be applied to the external (outbound) interface on the router. In Figure 8-14, the crypto map should be applied to interface serial 4/0 on Tokyo.

Use the show crypto map tag crypto_map_name command to verify proper crypto map placement, as demonstrated in Example 8-33.

Example 8-33. Verifying Proper Crypto Map Placement
Tokyo#show crypto map tag mjlnetmap
Crypto Map "mjlnetmap" 10 ipsec-isakmp
        Peer = 172.16.6.2
        Extended IP access list 101
            access-list 101 permit ip 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255
        Current peer: 172.16.6.2
        Security association lifetime: 4608000 kilobytes/3600 seconds
        PFS (Y/N): N
        Transform sets={
                mjlnet,
        }
        Interfaces using crypto map mjlnetmap:
                FastEthernet0/0
Tokyo#

Highlighted line 1 shows that crypto map mjlnetmap is applied to interface FastEthernet 0/0. It is not going to work there.

In Example 8-34, the crypto map is removed from interface FastEthernet 0/0 and applied to interface serial 4/0.

In highlighted lines 1 and 2, crypto map mjlnetmap is removed from interface FastEthernet 0/0 and, in highlighted lines 3 and 4, it is applied to interface serial 4/0.

Example 8-34. Removal of the Crypto Map from One Interface and Applying to Another Interface
Tokyo#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Tokyo(config)#interface fastethernet 0/0
Tokyo(config-if)#no crypto map mjlnetmap
Tokyo(config-if)#exit
Tokyo(config)#
Tokyo(config)#interface serial 4/0
Tokyo(config-if)#crypto map mjlnetmap
Tokyo(config-if)#end
Tokyo#

Once the crypto map has been applied to the correct interface, IKE main mode negotiation succeeds. This is verified using the show crypto isakmp sa command, as shown in Example 8-35.

Example 8-35. IKE Main Mode Negotiation Succeeds
Tokyo#show crypto isakmp sa
dst             src             state           conn-id    slot
172.16.6.2      172.16.5.1      QM_IDLE               1       0
Tokyo#

Example 8-36 shows that main mode negotiation has succeeded, and quick mode is in an idle state (QM_IDLE).

Crypto Access List Is Misconfigured

If the crypto access list is misconfigured, IKE negotiation may not be initiated.

To verify the crypto access list associated with a crypto map, use the show crypto map tag crypto_map_name, as shown in Example 8-36.

Example 8-36. Verify the Access List Associated with the Crypto Map
Tokyo#show crypto map tag mjlnetmap
Crypto Map "mjlnetmap" 10 ipsec-isakmp
        Peer = 172.16.6.2
        Extended IP access list 101
            access-list 101 permit ip 10.2.2.0 0.0.0.255 10.1.1.0 0.0.0.255
        Current peer: 172.16.6.2
        Security association lifetime: 4608000 kilobytes/3600 seconds
        PFS (Y/N): N
        Transform sets={mjlnet, }
        Interfaces using crypto map mjlnetmap:
                Serial4/0
Tokyo#

Highlighted line 1 shows that extended IP access list 101 is associated with crypto map mjlnetmap. The access list itself is shown in highlighted line 2.

At first glance, the access list looks fine, but on closer examination (and with reference to Figure 8-14), you will notice that the source and destination addresses are the wrong way round. The source address and mask should be 10.1.1.0 and 0.0.0.255, and the destination address and mask should be 10.2.2.0 and 0.0.0.255.

The crypto access list is then reconfigured in Example 8-37.

Example 8-37. Reconfiguration of the Crypto Access List
Tokyo#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Tokyo(config)#no access-list 101
Tokyo(config)#access-list 101 permit ip 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255
Tokyo(config)#exit
Tokyo#

User traffic is now matched by the crypto access list, and the IKE main mode is successfully negotiated between Tokyo and Osaka.

This is verified using the show crypto isakmp sa command, as shown in Example 8-38.

Example 8-38. ISAKMP SA Has Been Successfully Negotiated
Tokyo#show crypto isakmp sa
dst             src             state           conn-id    slot
172.16.6.2      172.16.5.1      QM_IDLE               1       0
Tokyo#

The highlighted line indicates that an IKE main mode has been successfully negotiated between Tokyo (172.16.5.1) and Osaka (172.16.6.2), and quick mode is idle (QM_IDLE).

Peer's IP Address Is Misconfigured or the Router Has Not Generated RSA Keys, Authenticated the CA, and Obtained a Certificate

If either the crypto isakmp key key address peer_address or the set peer peer_address commands are misconfigured then IKE phase 1 negotiation may not be initiated. Also, if certificates are being used and the router has not generated RSA keys, authenticated the CA, and obtained a certificate, IKE phase 1 negotiation may not be initiated.

Use the debug crypto isakmp command to troubleshoot this issue, as shown in Example 8-39.

Example 8-39. IPSec Peer's Address Is Misconfigured
Tokyo#debug crypto isakmp
Crypto ISAKMP debugging is on
Tokyo#
Mar 10 13:10:29.522 GMT: ISAKMP: received ke message (1/1)
Mar 10 13:10:29.522 GMT: ISAKMP: local port 500, remote port 500
Mar 10 13:10:29.526 GMT: ISAKMP (0:1): No Cert or pre-shared address key.
Mar 10 13:10:29.526 GMT: ISAKMP (0:1): Can not start Main mode
Mar 10 13:10:29.526 GMT: ISAKMP (0:1): Can not start aggressive mode.
Mar 10 13:10:29.526 GMT: ISAKMP (0:1): purging SA., sa=6327990C, delme=6327990C
Mar 10 13:10:29.526 GMT: ISAKMP (0:1): purging node 1168904210
Tokyo#

Highlighted line 1 shows that Tokyo is unable to find a preshared key corresponding to the crypto map-specified peer address.

In highlighted lines 2 and 3, you can see that Tokyo is unable to initiate either main or aggressive mode without a corresponding preshared key.

The peer address specified in the crypto map is then verified using the show crypto map tag crypto_map_name command, as demonstrated in Example 8-40.

Example 8-40. Crypto Map Specified Peer Address
Tokyo#show crypto map tag mjlnetmap
Crypto Map "mjlnetmap" 10 ipsec-isakmp
    Peer = 172.16.6.2
    Extended IP access list 101
        access-list 101 permit ip 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255
    Current peer: 172.16.6.2
    Security association lifetime: 4608000 kilobytes/3600 seconds
    PFS (Y/N): N
    Transform sets={mjlnet, }
    Interfaces using crypto map mjlnetmap:
        Serial4/0
Tokyo#

The highlighted line indicates that the peer address specified in crypto map mjlnetmap is 172.16.6.2. This address is correctly configured.

The preshared key is then checked using the show crypto isakmp key command, as demonstrated in Example 8-41.

Example 8-41. No Corresponding Preshared Key
Tokyo#show crypto isakmp key
Hostname/Address        Preshared Key
172.16.5.2              cisco
Tokyo#

The highlighted line shows that there is no preshared key corresponding to peer 172.16.6.2 (the peer address specified in crypto map mjlnetmap). In fact, the address specified in Example 8-41 (172.16.5.2) is misconfiguredit should be 172.16.6.2.

In Example 8-42, the misconfigured preshared key is removed, and a preshared key corresponding to peer 172.16.6.2 (Osaka) is added.

Example 8-42. Adding a Preshared Key for Osaka
Tokyo#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Tokyo(config)#no crypto isakmp key cisco address 172.16.5.2
Tokyo(config)#crypto isakmp key cisco address 172.16.6.2
Tokyo(config)#exit
Tokyo#

Once the preshared key has been added for Osaka, IKE phase 1 is successfully negotiated with between Tokyo and Osaka, as shown in Example 8-43.

Example 8-43. IKE Phase 1 Negotiation Succeeds
Tokyo#show crypto isakmp sa
dst             src             state           conn-id    slot
172.16.6.2      172.16.5.1      QM_IDLE               1       0
Tokyo#

Example 8-43 shows the IKE phase 1 negotiation has completed successfully, and quick mode is in an idle state.

As previously mentioned, if you are using certificates, check that the router has generated an RSA key pair, authenticated the CA, and obtained its certificate. Use the show crypto key mypubkey rsa and show crypto ca certificates commands to verify this.

For more details see the section "Configuring Site-to-Site IPSec VPNs with Digital Certificates" earlier in this chapter.

ISAKMP Is Disabled

If ISAKMP has been disabled on the router, then IKE negotiation will not be initiated. Note that ISAKMP is enabled by default on Cisco routers.

You can use either the debug crypto isakmp or show crypto isakmp sa commands to verify whether ISAKMP is disabled.

Example 8-44 shows the output of the debug crypto isakmp command when ISAKMP is disabled.

Example 8-44. ISAKMP Is Disabled
Tokyo#debug crypto isakmp
Crypto ISAKMP debugging is on
Tokyo#
Mar 10 11:21:28.203 GMT: ISAKMP: received ke message (1/1)
Mar 10 11:21:28.203 GMT: ISAKMP: can't initiate when turned off!
Mar 10 11:21:28.203 GMT: ISAKMP: local port 500, remote port 500
Mar 10 11:21:28.207 GMT: ISAKMP (0:1): Input = IKE_MESG_FROM_IPSEC, IKE_SA_REQ_MM
Old State = IKE_READY  New State = IKE_I_MM1
Tokyo#

The highlighted line clearly indicates that ISAKMP is disabled. To further verify this, use the show crypto isakmp sa command as demonstrated in Example 8-45.

Example 8-45. ISAKMP Is Disabled on the Router
Tokyo#show crypto isakmp sa
ISAKMP is turned off
Tokyo#

As you can see, ISAKMP is disabled on the router.

ISAKMP is then re-enabled in Example 8-46.

Example 8-46. ISAKMP Is Re-enabled on the Router
Tokyo#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Tokyo(config)#crypto isakmp enable
Tokyo(config)#exit
Tokyo#

The highlighted line indicates that ISAKMP is re-enabled.

IKE negotiation now negotiates successfully. This is verified in Example 8-47 using the show crypto isakmp sa command.

Example 8-47. IKE Negotiates Successfully
Tokyo#show crypto isakmp sa
dst             src             state           conn-id    slot
172.16.6.2      172.16.5.1      QM_IDLE               1       0
Tokyo#

As you can see, IKE phase 1 has successfully negotiated, and quick mode is in an idle state (QM_IDLE).

Initiator Sends ISAKMP Messages, but They Are Not Received by the Responder

If ISAKMP messages are being sent by the initiator, but are not received by the responder (as verified using the debug crypto isakmp command), this can indicate a number of problems, including the following:

  • IP connectivity has failed between the IPSec peers.

  • The responder's IP address is incorrectly configured.

  • UDP port 500 (ISAKMP) is blocked by an access list or firewall.

These issues are detailed in the sections that follow.

IP Connectivity Has Failed Between the IPSec Peers

Use the ping command to verify IP connectivity between the initiator and the responder.

If ping fails, you should begin to troubleshoot IP routing between the two peers. Remember, however, that ping only verifies reachability for ICMP Echo Request and Response messages.

Responder's IP Address Is Incorrectly Configured on the Initiator

If the responder's IP address is incorrectly configured on the initiator, IKE negotiation will fail.

Use the show crypto isakmp key and show crypto map tag crypto_map_name to verify that the peer address is correctly configured, as demonstrated in Example 8-48.

Example 8-48. Verifying the Peer's IP Address
Tokyo#show crypto isakmp key
Hostname/Address       Preshared Key
172.16.4.2             cisco
Tokyo#
Tokyo#show crypto map tag mjlnetmap
Crypto Map "mjlnetmap" 10 ipsec-isakmp
        Peer = 172.16.4.2
        Extended IP access list 101
            access-list 101 permit ip 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255
        Current peer: 172.16.4.2
        Security association lifetime: 4608000 kilobytes/3600 seconds
        PFS (Y/N): N
        Transform sets={mjlnet, }
        Interfaces using crypto map mjlnetmap:
                Serial4/0
Tokyo#

Highlighted lines 1 and 2 show that the peer's IP address is configured as 172.16.4.2. Unfortunately, it should be configured as 172.16.6.2.

The peer IP address is then reconfigured as shown in Example 8-49.

Example 8-49. Reconfiguration of the Peer IP Address (in the Crypto Map)
Tokyo#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Tokyo(config)#no crypto isakmp key cisco address 172.16.4.2
Tokyo(config)#crypto isakmp key cisco address 172.16.6.2
Tokyo(config)#
Tokyo(config)#crypto map mjlnetmap 10
Tokyo(config-crypto-map)#no set peer 172.16.4.2
Tokyo(config-crypto-map)#set peer 172.16.6.2
Tokyo(config-crypto-map)#end
Tokyo#

In highlighted lines 1 to 4, the peer's address is reconfigured as 172.16.6.2. Once the peer IP address has been reconfigured, IKE main mode negotiation succeeds. This is verified using the show crypto isakmp sa command, as shown in Example 8-50.

Example 8-50. IKE Main Mode Negotiation Succeeds
Tokyo#show crypto isakmp sa
dst             src             state           conn-id    slot
172.16.6.2      172.16.5.1      QM_IDLE               1       0
Tokyo#

The highlighted line indicates that IKE main mode negotiation has succeeded, and quick mode is in an idle state (QM_IDLE).

ISAKMP Is Blocked by an Access List or Firewall

If an access list or firewalls do not permit UDP port 500 (ISAKMP), IKE negotiation will fail.

In this scenario, Tokyo is initiating IKE negotiation to Osaka. Example 8-51 shows the output of the debug crypto isakmp command when Tokyo initiates IKE negotiation with Osaka.

Example 8-51. IKE Negotiation Fails
Tokyo#debug crypto isakmp
Crypto ISAKMP debugging is on
Tokyo#
Mar 10 10:21:55.963 GMT: ISAKMP (0:1): purging SA., sa=62C26CC0, delme=62C26CC0
Mar 10 10:21:56.367 GMT: ISAKMP: received ke message (1/1)
Mar 10 10:21:56.367 GMT: ISAKMP: local port 500, remote port 500
Mar 10 10:21:56.367 GMT: ISAKMP (0:1): Input = IKE_MESG_FROM_IPSEC, IKE_SA_REQ_MM
Old State = IKE_READY  New State = IKE_I_MM1
Mar 10 10:21:56.367 GMT: ISAKMP (0:1): beginning Main Mode exchange
Mar 10 10:21:56.367 GMT: ISAKMP (0:1): sending packet to 172.16.6.2 (I) MM_NO_STATE
Mar 10 10:22:06.367 GMT: ISAKMP (0:1): retransmitting phase 1 MM_NO_STATE
Mar 10 10:22:06.367 GMT: ISAKMP (0:1): incrementing error counter on sa: retransmit phase 1
Mar 10 10:22:06.367 GMT: ISAKMP (0:1): retransmitting phase 1 MM_NO_STATE
Mar 10 10:22:06.367 GMT: ISAKMP (0:1): sending packet to 172.16.6.2 (I) MM_NO_STATE
Tokyo#

Highlighted line 1 shows that IKE main mode negotiation is about to begin, and then in highlighted line 2, Tokyo sends the first packet in the exchange. In highlighted lines 3 and 4, Tokyo retransmits the packet.

Tokyo is sending ISAKMP messages to Osaka, but no response is received. This might indicate the presence of an access list in the path from Tokyo to Osaka.

When Osaka is checked using the show ip interface [interface_name] command, an access list is found on its external interface (serial 2/0), as shown in Example 8-52. Note that only the relevant portion of the output is shown.

Example 8-52. Access List Is Found on the External Interface of Osaka
Osaka#show ip interface serial 2/0
Serial2/0 is up, line protocol is up
  Internet address is 172.16.6.2/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
  Multicast reserved groups joined: 224.0.0.10
  Outgoing access list is not set
  Inbound  access list is 102
  Proxy ARP is enabled
  Security level is default
  Split horizon is enabled

The contents of the access list are then verified using the show ip access-lists [access-list_number] command.

Example 8-53 shows the output of the show ip access-lists command on Osaka.

Example 8-53. Access List 102 Blocks ISAKMP
Osaka#show ip access-lists 102
Extended IP access list 102
    permit icmp any any
    permit eigrp any any
    permit pim any any
    permit esp any any
    permit ahp any any
    permit tcp any any
    permit udp any any eq domain
    permit udp any any eq ntp
    permit udp any any eq snmp
    permit udp any any eq snmptrap
    permit udp any any eq tftp
    permit udp any any eq tacacs
Osaka#

As you can see, access list 102 is not configured to specifically permit ISAKMP traffic, so it is blocked by the implicit deny any at the end of the access list.

You could either add a line to the access list to permit ISAKMP traffic (access-list access-list-number permit udp source source-wildcard destination destination-wildcard eq isakmp) or remove the access list entirely, if it is not necessary. In this case, the access list is deemed unnecessary, so in Example 8-54, it is removed from the interface serial 2/0.

Example 8-54. Access List Is Removed
Osaka#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Osaka(config)#interface serial 2/0
Osaka(config-if)#no ip access-group 102 in
Osaka(config-if)#end
Osaka#

IKE negotiation now succeeds. This is verified using the show crypto isakmp sa command, as shown in Example 8-55.

Example 8-55. IKE Negotiation Succeeds
Tokyo#show crypto isakmp sa
dst             src             state           conn-id    slot
172.16.6.2      172.16.5.1      QM_IDLE               1       0
Tokyo#

As you can see, IKE phase 1 has been successfully negotiated, and quick mode is in an idle state.

Responder Does Not Have a Preshared Key, Certificate, or Route to the Initiator

If the responder does not have a preshared key for the initiator, does not have a certificate, or does not have a route back to the initiator, IKE phase 1 negotiations will fail.

Use the debug crypto isakmp command to troubleshoot this issue, as shown in Example 8-56.

Example 8-56. Responder Has No Preshared Key for the Initiator
[View full width]
Osaka#debug crypto isakmp
Crypto ISAKMP debugging is on
*May 13 16:57:07.283 GMT: ISAKMP (0:2): Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
Old State = IKE_READY  New State = IKE_R_MM1
*May 13 16:57:07.283 GMT: ISAKMP (0:2): processing SA payload. message ID = 0
*May 13 16:57:07.283 GMT: ISAKMP (0:2): No pre-shared key with 172.16.5.1!
*May 13 16:57:07.283 GMT: ISAKMP (0:2): Checking ISAKMP transform 1 against
  priority 10 policy
*May 13 16:57:07.283 GMT: ISAKMP:      encryption DES-CBC
*May 13 16:57:07.283 GMT: ISAKMP:      hash MD5
*May 13 16:57:07.283 GMT: ISAKMP:      default group 1
*May 13 16:57:07.283 GMT: ISAKMP:      auth pre-share
*May 13 16:57:07.283 GMT: ISAKMP:      life type in seconds
*May 13 16:57:07.283 GMT: ISAKMP:      life duration (VPI) of  0x0 0x1 0x51 0x80
*May 13 16:57:07.283 GMT: ISAKMP (0:2): Preshared authentication offered but does not
  match policy!
*May 13 16:57:07.283 GMT: ISAKMP (0:2): atts are not acceptable. Next payload is 0
*May 13 16:57:07.283 GMT: ISAKMP (0:2): Checking ISAKMP transform 1 against
  priority 65535 policy
*May 13 16:57:07.283 GMT: ISAKMP:      encryption DES-CBC
*May 13 16:57:07.283 GMT: ISAKMP:      hash MD5
*May 13 16:57:07.283 GMT: ISAKMP:      default group 1
*May 13 16:57:07.283 GMT: ISAKMP:      auth pre-share
*May 13 16:57:07.283 GMT: ISAKMP:      life type in seconds
*May 13 16:57:07.283 GMT: ISAKMP:      life duration (VPI) of  0x0 0x1 0x51 0x80
*May 13 16:57:07.283 GMT: ISAKMP (0:2): Hash algorithm offered does not match policy!
*May 13 16:57:07.287 GMT: ISAKMP (0:2): atts are not acceptable. Next payload is 0
*May 13 16:57:07.287 GMT: ISAKMP (0:2): no offers accepted!
*May 13 16:57:07.287 GMT: ISAKMP (0:2): phase 1 SA not acceptable!
*May 13 16:57:07.287 GMT: ISAKMP (0:2): incrementing error counter on sa:
   construct_fail_ag_init
*May 13 16:57:07.287 GMT: ISAKMP (0:2): Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
Old State = IKE_R_MM1  New State = IKE_R_MM1
*May 13 16:57:07.287 GMT: ISAKMP (0:2): Input = IKE_MESG_INTERNAL, IKE_PROCESS_ERROR
Old State = IKE_R_MM1  New State = IKE_READY
Osaka#

In highlighted line 1, the IKE state changes from IKE_READY to IKE_R_MM1. Osaka has received the first message in the main mode exchange from router Tokyo. Note the R in the output hereit indicates that Osaka is the responder.

Osaka then begins to process the SA payload (highlighted line 2), but in highlighted line 3, it reports that it does not have a preshared key for the initiator.

Osaka continues to process the SA payload in the following lines, but in highlighted line 4, the IKE state changes back to IKE_READY, indicating that phase 1 negotiation has failed.

The reason for the failure was, of course, indicated in highlighted line 3. Osaka does not have a preshared key for Tokyo.

Osaka's configuration is then examined using the show running-config command as demonstrated in Example 8-57. Note that only the relevant portion of the output is shown.

Example 8-57. Osaka's Configuration
Osaka#show running-config
Building configuration...
!
crypto isakmp policy 10
 hash md5
 authentication pre-share
crypto isakmp key cisco address 172.16.4.1
!

As you can see, there is only one preshared key configured, and it is configured for peer 172.16.4.1. In fact, there is no such peerit should be 172.16.5.1 (Tokyo).

The preshared key is then reconfigured, as shown in Example 8-58.

Example 8-58. Reconfiguration of the Preshared Key
Osaka#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Osaka(config)#no crypto isakmp key cisco address 172.16.4.1
Osaka(config)#crypto isakmp key cisco address 172.16.5.1
Osaka(config)#exit
Osaka#

The highlighted lines show where the preshared key is reconfigured.

Once the preshared key has been reconfigured, IKE phase 1 negotiation is successful, as shown in Example 8-59.

Example 8-59. IKE Phase 1 Negotiation Succeeds
Osaka#show crypto isakmp sa
dst              src             state           conn-id    slot
172.16.6.2       172.16.5.1      QM_IDLE               9       0
Osaka#

As you can see, IKE phase 1 negotiation has succeeded, and quick mode is in an idle state.

If you are using certificates, check that the router has generated an RSA key pair, authenticated the CA, and obtained its certificate. Use the show crypto key mypubkey rsa and show crypto ca certificates commands to verify this. See the section "Configuring Site-to-Site IPSec VPNs with Digital Certificates" on page 677.

Finally, ensure that the responder has a route back to the initiator using the show ip route command. If it cannot send ISAKMP messages to the initiator, IKE phase 1 negotiation will fail.

IKE Policy Mismatch Exists

If IKE policy parameters are mismatched between IPSec peer routers, IKE phase 1 negotiation will fail. Use the debug crypto isakmp command to troubleshoot this issue.

Example 8-60 shows the output of the debug crypto isakmp command when IKE phase 1 negotiation fails.

Example 8-60. IKE Main Mode Negotiation Fails
Tokyo#debug crypto isakmp
Crypto ISAKMP debugging is on
Tokyo#
Mar 10 21:23:18.775 GMT: ISAKMP: received ke message (1/1)
Mar 10 21:23:18.775 GMT: ISAKMP: local port 500, remote port 500
Mar 10 21:23:18.775 GMT: ISAKMP (0:1): Input = IKE_MESG_FROM_IPSEC, IKE_SA_REQ_MM
Old State = IKE_READY  New State = IKE_I_MM1
Mar 10 21:23:18.775 GMT: ISAKMP (0:1): beginning Main Mode exchange
Mar 10 21:23:18.775 GMT: ISAKMP (0:1): sending packet to 172.16.6.2 (I) MM_NO_STATE
Mar 10 21:23:28.775 GMT: ISAKMP (0:1): retransmitting phase 1 MM_NO_STATE
Mar 10 21:23:28.775 GMT: ISAKMP (0:1): incrementing error counter on sa: retransmit phase 1
Mar 10 21:23:28.775 GMT: ISAKMP (0:1): retransmitting phase 1 MM_NO_STATE
Mar 10 21:23:28.775 GMT: ISAKMP (0:1): sending packet to 172.16.6.2 (I) MM_NO_STATE
Tokyo#

Highlighted line 1 shows that main mode negotiation is about to begin between the Tokyo and Osaka. The first packet in the IKE main mode negotiation sequence is sent by Tokyo in highlighted line 2. Then in highlighted lines 3 and 4, Tokyo retransmits the packet. There is no response from Osaka.

The debug crypto isakmp command is then used on Osaka to examine IKE negotiation from its perspective, as demonstrated in Example 8-61.

Example 8-61. IKE Main Mode Negotiation Failure Seen on Osaka
Osaka#debug crypto isakmp
Crypto ISAKMP debugging is on
Osaka#
00:08:57: ISAKMP (0:0): received packet from 172.16.5.1 (N) NEW SA
00:08:57: ISAKMP: local port 500, remote port 500
00:09:37: ISAKMP (0:3): Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
Old State = IKE_READY  New State = IKE_R_MM1
00:09:37: ISAKMP (0:3): processing SA payload. message ID = 0
00:09:37: ISAKMP (0:3): found peer pre-shared key matching 172.16.5.1
00:09:37: ISAKMP (0:3): Checking ISAKMP transform 1 against priority 10 policy
00:09:37: ISAKMP:      encryption DES-CBC
00:09:37: ISAKMP:      hash SHA
00:09:37: ISAKMP:      default group 1
00:09:37: ISAKMP:      auth pre-share
00:09:37: ISAKMP:      life type in seconds
00:09:37: ISAKMP:      life duration (VPI) of  0x0 0x1 0x51 0x80
00:09:37: ISAKMP (0:3): Hash algorithm offered does not match policy!
00:09:37: ISAKMP (0:3): atts are not acceptable. Next payload is 0

Highlighted line 1 shows that an ISAKMP packet has been received from Tokyo (172.16.5.1). Then in highlighted line 2, Osaka reports that it is processing the ISAKMP message SA payload. Contained within the SA payload is the IKE policy proposal from router Tokyo.

Osaka begins to try to find a match for the IKE proposals in highlighted line 3, when it attempts to match the first proposal from Tokyo against its own highest priority (lowest numbered) IKE policy. In this case, the highest priority IKE policy configured on Osaka is priority 10.

From highlighted lines 4 to 9, the attributes of Tokyo's first proposal are listed, and then in highlighted line 10, Osaka reports that the hash algorithm offered in Tokyo's proposal (SHA) does not match its own hash algorithm.

Because the hash algorithms do not match, Osaka reports that the IKE policy proposal attributes sent by Tokyo are not acceptable (highlighted line 11).

Note that Osaka also reports in highlighted line 11 that Next payload is 0. This is significant because it indicates that there is no next payload, meaning that Tokyo has sent only one IKE policy proposal.

Refer to Table 8-1 for more information about ISAKMP message payload types.

Osaka now tries to match the proposal from Tokyo against its default policy in Example 8-62.

Example 8-62. Osaka Tries to Match the Proposal from Tokyo Against Its Default Policy
00:09:37: ISAKMP (0:3): Checking ISAKMP transform 1 against priority 65535 policy
00:09:37: ISAKMP:      encryption DES-CBC
00:09:37: ISAKMP:      hash SHA
00:09:37: ISAKMP:      default group 1
00:09:37: ISAKMP:      auth pre-share
00:09:37: ISAKMP:      life type in seconds
00:09:37: ISAKMP:      life duration (VPI) of  0x0 0x1 0x51 0x80
00:09:37: ISAKMP (0:3): Authentication method offered does not match policy!
00:09:37: ISAKMP (0:3): atts are not acceptable. Next payload is 0
00:09:37: ISAKMP (0:3): no offers accepted!
00:09:37: ISAKMP (0:3): phase 1 SA not acceptable!
00:09:37: ISAKMP (0:3): incrementing error counter on sa: construct_fail_ag_init
00:09:37: ISAKMP (0:3): Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
Old State = IKE_R_MM1  New State = IKE_R_MM1
00:09:37: ISAKMP (0:3): Input = IKE_MESG_INTERNAL, IKE_PROCESS_ERROR
Old State = IKE_R_MM1  New State = IKE_READY
00:09:47: ISAKMP (0:0): received packet from 172.16.5.1 (N) NEW SA
00:09:47: ISAKMP: local port 500, remote port 500
Osaka#

In highlighted line 1, Osaka reports that it is trying to match this proposal against its own default policy (number 65535).

Then in highlighted line 2, Osaka reports that the authentication method does not match, and in highlighted line 3, it reports that the attributes do not match its own policy and are, therefore, not acceptable. Finally, in highlighted lines 4 and 5, Osaka reports that no offers (policy proposals) have been accepted and that the phase 1 IKE SA is not acceptable.

Tokyo's proposal has been rejected because its hash algorithm does not match that of the policy configured on Osaka (Example 8-62, highlighted line 11). Additionally, the authentication method does not match that of the default policy (highlighted line 2). You know that the hash algorithm proposed by Tokyo was SHA (Example 8-62, highlighted line 5), so you can probably guess the hash algorithm configured on Osaka.

The ISAKMP (IKE) policies on Osaka are then examined using the show crypto isakmp policy command, as shown in Example 8-63.

Example 8-63. IKE Policies on Osaka
Osaka#show crypto isakmp policy
Protection suite of priority 10
    encryption algorithm:    DES - Data Encryption Standard (56 bit keys).
    hash algorithm:        Message Digest 5
    authentication method:    Pre-Shared Key
    Diffie-Hellman group:    #1 (768 bit)
    lifetime:        86400 seconds, no volume limit
Default protection suite
    encryption algorithm:    DES - Data Encryption Standard (56 bit keys).
    hash algorithm:        Secure Hash Standard
    authentication method:    Rivest-Shamir-Adleman Signature
    Diffie-Hellman group:    #1 (768 bit)
    lifetime:        86400 seconds, no volume limit
Osaka#

Highlighted line 1 shows the protection suite of IKE policy 10. As you can see, the hash algorithm configured on Osaka is MD5. This is the cause of the failureTokyo is configured to use SHA, and Osaka is configured to use MD5.

Note also the default policy in highlighted line 2. The authentication method of the default policy is RSA signatures. The authentication method proposed by Tokyo was preshared keys (highlighted line 7, Example 8-62), so no match there either.

The hash algorithm must be changed on either Tokyo or Osaka. In this case, it is changed on Tokyo. This is shown in Example 8-64.

Example 8-64. Hash Algorithm Changed to MD5 on Tokyo
Tokyo#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Tokyo(config)#crypto isakmp policy 10
Tokyo(config-isakmp)#hash md5
Tokyo(config-isakmp)#end
Tokyo#

As the highlighted line indicates, the hash algorithm on Tokyo is changed to MD5.

Once the hash algorithm has been changed, the IKE SA is successfully negotiated between Tokyo and Osaka. This is verified using the show crypto isakmp sa command, as shown in Example 8-65.

Example 8-65. IKE SA Is Successfully Negotiated
Tokyo#show crypto isakmp sa
dst             src             state           conn-id    slot
172.16.6.2      172.16.5.1      QM_IDLE               1       0
Tokyo#

It is also a good idea to ensure that the ISAKMP lifetime (configured in crypto isakmp policy number) is equal on the initiator and the responder. If the lifetime is not equal then the policy may be rejected (depending on the version of IOS and whether the initiator's lifetime is greater or less than that of the responder).

IKE Authentication Fails

If IKE authentication does not succeed, phase 1 negotiation will fail.

Reasons for authentication failure depend on whether you are using preshared keys or digital certificates. These reasons are discussed in the two sections that follow.

Authentication Fails with Preshared Keys

If preshared keys are mismatched between IPSec peers, authentication will not succeed, and IKE negotiation will fail.

In IKE main mode, authentication occurs when the IPSec peers exchange the fifth and sixth messages in the IKE negotiation sequence. Use the debug crypto isakmp command to troubleshoot this issue.

Example 8-66 shows the output of the debug crypto isakmp command when an authentication failure occurs. Note that only the relevant portion of the output is shown.

Example 8-66. IKE Preshared Key Authentication Failure
Tokyo#debug crypto isakmp
Crypto ISAKMP debugging is on
Tokyo#
Mar 11 11:17:55.555 GMT: ISAKMP (0:1): sending packet to 172.16.6.2 (I) MM_KEY_EXCH
Mar 11 11:17:55.555 GMT: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
Old State = IKE_I_MM4  New State = IKE_I_MM5
Mar 11 11:17:55.627 GMT: ISAKMP (0:1): received packet from 172.16.6.2 (I) MM_KEY_EXCH
Mar 11 11:17:55.627 GMT: ISAKMP: reserved not zero on NOTIFY payload!
Mar 11 11:17:55.627 GMT: %CRYPTO-4-IKMP_BAD_MESSAGE: IKE message from 172.16.6.2
  failed its sanity check or is malformed
Mar 11 11:17:55.627 GMT: ISAKMP (0:1): incrementing error counter on sa: reset_retransmission
Mar 11 11:17:56.627 GMT: ISAKMP (0:1): retransmitting phase 1 MM_KEY_EXCH
Mar 11 11:17:56.627 GMT: ISAKMP (0:1): incrementing error counter on sa: retransmit phase 1
Tokyo#

In highlighted line 1, Tokyo (the initiator) sends a packet to Osaka (the responder).

Highlighted line 2 shows that the state has changed from IKE_I_MM4 to IKE_I_MM5, indicating that the packet sent in highlighted line 1 was the fifth in the sequence. Then in highlighted line 3, a packet is received from Osaka (172.16.6.2).

Highlighted lines 4 and 5 indicate that this packet contains an unauthenticated Notify message. Notify messages are used to send error conditions (or status data). This might mean that the shared key has been misconfigured on either Tokyo or Osaka. Osaka confirms that the shared key is properly configured as cisco.

Tokyo's configuration is then examined using the show running-config command in Example 8-67. Note that only the relevant portion of the output is shown.

Example 8-67. Tokyo Configuration
Tokyo#show running-config
Building configuration...
!
crypto isakmp policy 10
 hash md5
 authentication pre-share
crypto isakmp key disco address 172.16.6.2
!

Highlighted line 1 shows that the preshared key is configured as disco on Tokyo. In this example, it should be cisco, of course.

The preshared key is, therefore, corrected on Tokyo, as shown in Example 8-68.

Example 8-68. Correction of Misconfigured Preshared Key on Tokyo
Tokyo#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Tokyo(config)#no crypto isakmp key disco address 172.16.6.2
Tokyo(config)#crypto isakmp key cisco address 172.16.6.2
Tokyo(config)#exit
Tokyo#

When IKE negotiation is reinitiated by user traffic, it succeeds. This is verified using the show crypto isakmp sa command. The output of the show crypto isakmp sa command shows that IKE (phase 1) negotiation has been successful, as seen in Example 8-69.

Example 8-69. IKE Phase 1 Negotiation Is Successful
Tokyo#show crypto isakmp sa
dst              src             state           conn-id    slot
172.16.6.2       172.16.5.1      QM_IDLE               1       0
Tokyo#

As you can see, IKE phase 1 negotiation has succeeded, and quick mode negotiation is in an idle state.

Authentication Fails When Using Certificates

If you are using digital signatures (certificates) for authentication and a certificate has expired, or the time on a router is outside of the validity dates for a certificate, then IKE authentication will fail.

Use debug crypto isakmp command to troubleshoot this issue, as shown in Example 8-70. Note that only the relevant portion of the output is shown.

Example 8-70. IKE Negotiation Fails
Tokyo#debug crypto isakmp
Crypto ISAKMP debugging is on
Tokyo#
03:05:18: ISAKMP (0:1): sending packet to 172.16.6.2 (I) MM_KEY_EXCH
03:05:18: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE
Old State = IKE_I_MM4  New State = IKE_I_MM5
03:05:19: ISAKMP (0:1): received packet from 172.16.6.2 (I) MM_KEY_EXCH
03:05:19: ISAKMP (0:1): Notify has no hash. Rejected.
03:05:19: ISAKMP (0:1): Input = IKE_MESG_FROM_PEER, IKE_INFO_NOTIFY
Old State = IKE_I_MM5  New State = IKE_I_MM5
Tokyo#

In highlighted line 1, Tokyo sends a packet to Osaka (172.16.6.2).

Highlighted line 2 shows that the state has changed to IKE_I_MM5, indicating that the message sent in highlighted line 1 was the fifth in the IKE phase 1 exchange. Remember that the fifth and sixth messages in phase 1 are used for peer authentication.

Then in highlighted line 3, a packet is received from Osaka. This is a Notify message, as shown in highlighted line 4. This indicates an error condition, and IKE negotiation now terminates. An error has occurred, but there is not much information as to the cause.

The next step is to examine the exchange from the point of view of Osaka. Again, use the debug crypto isakmp command to examine the IKE negotiation exchange (when it restarts) as shown in Example 8-71.

Example 8-71. IKE Negotiation Failure on Osaka
Osaka#debug crypto isakmp
Crypto ISAKMP debugging is on
Osaka#
05:13:10: ISAKMP (0:3): received packet from 172.16.5.1 (R) MM_KEY_EXCH
05:13:10: ISAKMP (0:3): Input = IKE_MESG_FROM_PEER, IKE_MM_EXCH
Old State = IKE_R_MM4  New State = IKE_R_MM5
05:13:10: ISAKMP (0:3): processing ID payload. message ID = 0
05:13:10: ISAKMP (0:3): processing CERT payload. message ID = 0
05:13:10: ISAKMP (0:3): processing a CT_X509_SIGNATURE cert
05:13:10: %CRYPTO-5-IKMP_INVAL_CERT: Certificate received from 172.16.5.1
  is bad: certificate invalid
05:13:10: ISKAMP: growing send buffer from 1024 to 3072
05:13:10: ISAKMP (0:3): Input = IKE_MESG_INTERNAL, IKE_PROCESS_MAIN_MODE
Old State = IKE_R_MM5  New State = IKE_R_MM5
05:13:10: ISAKMP (0:3): sending packet to 172.16.5.1 (R) MM_KEY_EXCH
05:13:10: ISAKMP (0:3): Input = IKE_MESG_INTERNAL, IKE_PROCESS_ERROR
Old State = IKE_R_MM5  New State = IKE_R_MM4
Osaka#

A packet is received from Tokyo (172.16.5.1) in highlighted line 1, and in highlighted line 2, the router reports that the new state is IKE_R_MM5. Again, this indicates that the message received in highlighted line 1 is the fifth message in the phase 1 negotiation exchange. Osaka now begins to process the payloads contained within the packet.

In highlighted lines 3 and 4, Osaka processes the ID and CERT (certificate) payloads. Then in highlighted lines 5, 6, and 7, Osaka processes the X.509 certificate itself and reports that the certificate is invalid.

Finally, Osaka sends a packet to Tokyo is highlighted line 7. This is the Notify message used to inform Tokyo of the error.

The certificate is invalid. There are a number of possibilities, three of which are as follows:

  • The certificate has expired.

  • The validity period of the certificate itself is incorrect because of an incorrectly set clock on the certificate server.

  • The clock is incorrectly set on the router, and it is outside the validity period of the certificate received.

Note that other reasons why a certificate might be invalid are listed at the end of this section.

The next step is to check the clock on Osaka and the validity period of the certificate. To check the clock, use the show clock command, as shown in Example 8-72.

Example 8-72. Osaka's Clock
Osaka#show clock
.14:18:58.579 UTC Sun Mar 14 2005
Osaka#

As you can see, the clock on Osaka is set to 14 March 2005. In fact, it should be set to 14 March 2003.

In Example 8-73 Tokyo's certificate is examined using the show crypto ca certificates command. Note that only the relevant portion of the output is shown.

Example 8-73. Tokyo's Certificate
Tokyo#show crypto ca certificates
Certificate
  Status: Available
  Certificate Serial Number: 614A2572000000000006
  Key Usage: General Purpose
  Issuer:
    CN = markacs
     OU = markacs
     O = markacs
     L = london
     ST = london
     C = UK
     EA =<16> mark@markacs.com
  Subject Name Contains:
    Name: Tokyo.mjlnet.com
    IP Address: 172.16.5.1
    Serial Number: 0168FEB5
  CRL Distribution Point:
    http://markacs/CertEnroll/markacs.crl
  Validity Date:
    start date: 09:04:23 UTC Mar 13 2003
    end   date: 09:14:23 UTC Mar 13 2004
  Associated Identity: mjlnetca

As you can see, Tokyo's certificate is valid from 13 March 2003 to 13 March 2004. Osaka's clock doesn't fall within these dates, and therefore IKE authentication fails. Osaka's clock is then modified to the correct time using the clock set command (Example 8-74).

If your routers do not have hardware clocks, every time they are rebooted, their clocks will be resetthis is a good reason to use NTP instead.

Example 8-74. Modifying Osaka's Clock
Tokyo#clock set 21:01:00 14 march 2003

Once Osaka's clock has been modified, IKE negotiation succeeds between Tokyo and Osaka. This is verified using the show crypto isakmp sa command in Example 8-75.

Example 8-75. IKE Negotiation Succeeds
Tokyo#show crypto isakmp sa
dst              src             state           conn-id    slot
172.16.6.2       172.16.5.1      QM_IDLE               1       0
Tokyo#

Example 8-76 shows that the phase 1 has been successfully negotiated, and quick mode is in an idle state.

Other common issues with certificate authentication include the following:

  • One or both of the IPSecs peers does not have a certificate and has not requested one.

    Ensure that both IPSec peers have a certificate. Verify this using the show crypto ca certificates command.

    See the section "Configuring Site-to-Site IPSec VPNs with Digital Certificates" for more details.

  • The certificate has not been issued.

    Make sure that the router's certificate has been issued by the CA and is not pending.

    If the certificate is pending, the following message is logged on the router:

    00:55:17: CRYPTO_PKI: status = 102: certificate request pending

    Once the certificate has been issued, the following message is logged on the router:

    00:56:19: %CRYPTO-6-CERTRET: Certificate received from Certificate Authority

    Note that you can also use the show crypto ca certificates command to verify certificate status.

  • The router is unable to retrieve the CRL.

    Check that the CA is up and reachable via TCP port 80 (HTTP) or TCP port 389 (LDAP), depending on the protocol the router is using to retrieve the CRL.

    If you want to use the (crl) query command to retrieve the CRL via LDAP, ensure that your CA server supports this.

    Check that you have an ip host mapping on the router for the CA server name as seen in the CRL distribution point (CDP) URL, or it is resolvable via DNS. Use the show crypto ca certificates command to verify this.

    Note that if you configure the crl optional command, the router will accept the peer's certificate even if it is not able to retrieve the CRL.

    If connectivity to the CA server is intermittent, one way around this is to manually download the CRL using the crypto ca crl request ca_server. Verify that the CRL has been successfully downloaded using the show crypto ca crls command.

  • Peer router certificates are issued by different certificate servers or certificate hierarchies.

    Check that certificates obtained by peer routers are issued by the same CA or the same CA hierarchy.

    Use the show crypto ca certificates command to verify this.

  • The certificate has been revoked.

    Check that the router certificate has not been revoked on the CA.

  • The router hostname or IP address has changed.

    Ensure that the router's hostname (including the domain name) has not been changed since its certificate was issued.

    Also, if there is an IP address associated with the router's certificate, ensure that it has not changed.

    Use the show crypto ca certificates command to verify the hostname and IP address associated with the router's certificate.

  • Fields in the peer IPSec router's certificate do not match attributes specified using certificate security attribute-based access control.

    If certificate security attribute-based access control is configured on one IPSec router (using the crypto ca certificate map label sequence-number command), ensure that fields in the peer IPSec router's certificate match the attributes specified. If there is a mismatch then the following message is logged:

    [View full width]

*Apr 16 10:08:04.067: %CRYPTO-5-IKMP_INVAL_CERT: Certificate received from 172.16.6.2
   is bad: unknown error returned in certificate validation

    Verify the peer's certificate using the show crypto ca certificates command.

IKE Phase 2 (Quick Mode) Negotiation Fails

Once IKE phase 1 is complete, the two peers then negotiate IPSec SAs in phase 2 (quick mode). If IKE phase 2 negotiation fails, no IPSec SAs will be established. Figure 8-16 illustrates phase 2 negotiation.

Figure 8-16. IKE Phase 2 Negotiation

[View full size image]

Before beginning to troubleshoot IKE phase 2, it is worth examining a successful IKE phase 2 negotiation sequence.

Examples 8-76 to 8-78 show successful IKE phase 2 (quick mode) negotiation. Note that only the relevant portion of the output is shown.

Example 8-76. Quick Mode Negotiation Begins
Tokyo#debug crypto isakmp
Crypto ISAKMP debugging is on
Tokyo#
Mar  7 16:14:29.191 GMT: ISAKMP (0:1): beginning Quick Mode exchange, M-ID of
  216243713
Mar  7 16:14:29.195 GMT: ISAKMP (0:1): sending packet to 172.16.6.2 (I) QM_IDLE
Mar  7 16:14:29.195 GMT: ISAKMP (0:1): Node -216243713, Input = IKE_MESG_INTERNAL,
  IKE_INIT_QM
Old State = IKE_QM_READY  New State = IKE_QM_I_QM1

Highlighted line 1 shows that quick mode is about to begin. Also note the message ID (M-ID) of the first quick mode message that Tokyo is about to send. Notice that it is nonzero (in fact, random), unlike those of messages in main mode.

The first message in the quick mode exchange is sent by Tokyo in highlighted line 2. This message contains, among other things, IPSec proposals.

In highlighted line 3, you can see the state is now IKE_QM_I_QM1, indicating that the first message in the quick mode exchange has been sent. Osaka responds.

Example 8-77. Received Second Quick Mode Message (from Responder)
Mar  7 16:14:29.195 GMT: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE
Old State = IKE_P1_COMPLETE  New State = IKE_P1_COMPLETE
Mar  7 16:14:29.447 GMT: ISAKMP (0:1): received packet from 172.16.6.2 (I) QM_IDLE
Mar  7 16:14:29.451 GMT: ISAKMP (0:1): processing HASH payload. message ID =
  -216243713
Mar  7 16:14:29.451 GMT: ISAKMP (0:1): processing SA payload. message ID = -216243713
Mar  7 16:14:29.451 GMT: ISAKMP (0:1): Checking IPSec proposal 1
Mar  7 16:14:29.451 GMT: ISAKMP: transform 1, ESP_DES
Mar  7 16:14:29.451 GMT: ISAKMP:   attributes in transform:
Mar  7 16:14:29.451 GMT: ISAKMP:      encaps is 1
Mar  7 16:14:29.451 GMT: ISAKMP:      SA life type in seconds
Mar  7 16:14:29.451 GMT: ISAKMP:      SA life duration (basic) of 3600
Mar  7 16:14:29.451 GMT: ISAKMP:      SA life type in kilobytes
Mar  7 16:14:29.451 GMT: ISAKMP:      SA life duration (VPI) of  0x0 0x46 0x50 0x0
Mar  7 16:14:29.451 GMT: ISAKMP:      authenticator is HMAC-MD5
Mar  7 16:14:29.451 GMT: ISAKMP (0:1): atts are acceptable.
Mar  7 16:14:29.451 GMT: ISAKMP (0:1): processing NONCE payload. message ID =
  -216243713
Mar  7 16:14:29.451 GMT: ISAKMP (0:1): processing ID payload. message ID = -216243713
Mar  7 16:14:29.451 GMT: ISAKMP (0:1): processing ID payload. message ID = -216243713
Mar  7 16:14:29.451 GMT: ISAKMP (0:1): Creating IPSec SAs
Mar  7 16:14:29.451 GMT:         inbound SA from 172.16.6.2 to 172.16.5.1
        (proxy 10.2.2.0 to 10.1.1.0)
Mar  7 16:14:29.451 GMT:         has spi 0x7E5A7D6C and conn_id 2000 and flags 4
Mar  7 16:14:29.451 GMT:         lifetime of 3600 seconds
Mar  7 16:14:29.451 GMT:         lifetime of 4608000 kilobytes
Mar  7 16:14:29.451 GMT:         outbound SA from 172.16.5.1      to 172.16.6.2
  (proxy 10.1.1.0        to 10.2.2.0       )
Mar  7 16:14:29.455 GMT:         has spi -565122577 and conn_id 2001 and flags 4
Mar  7 16:14:29.455 GMT:         lifetime of 3600 seconds
Mar  7 16:14:29.455 GMT:         lifetime of 4608000 kilobytes

A reply is then received from Osaka in highlighted line 1. This message contains a number of payloads, including a HASH payload, an SA payload, a NONCE payload, and ID payload.

The HASH payload (highlighted line 2) serves to authenticate the message, as well as being a liveliness indicator.

The SA payload (highlighted line 3) contains IPSec proposals. In lines 4 to 12, the SA is processed, and in line 13, it is accepted.

The NONCE payload contains a random number and serves to prevent replay attacks, as well as being used to generate fresh keying material. This payload is processed by Tokyo in highlighted line 14.

The ID payloads are used to carry (proxy) identities. These are also called traffic selectors and correspond to the crypto access list configured on Tokyo. The ID payloads are processed in highlighted lines 15 and 16.

Once the message from Osaka has been completely processed, Tokyo begins to create the IPSec SAs (highlighted line 17).

In highlighted line 18, the inbound IPSec SA is created. Note that the SA is created between IP addresses 172.16.6.2 (Osaka) and 172.16.5.1 (Tokyo) for proxy identities 10.2.2.0 (the source address in the crypto access list on Osaka) and 10.1.1.0 (the destination address in the crypto access list on Osaka).

The Security Parameters Index (SPI) and lifetimes (seconds and kilobytes) of the SA are shown in highlighted lines 19 to 21. The SPI acts as a unique identifier for the SA.

Then in highlighted line 22, the outbound IPSec SA is created. This SA is created between 172.16.5.1 (Tokyo) and 172.16.6.2 (Osaka), with proxy identities 10.1.1.0 (the source address in the crypto map on Tokyo) and 10.2.2.0 (the destination address in the crypto map on Tokyo). Again, the SPI and lifetimes associated with this SA are shown in highlighted lines 23 to 25. Tokyo responds in Example 8-78.

Example 8-78. Sending Third and Last Message in Quick Mode Exchange
Mar  7 16:14:29.455 GMT: ISAKMP (0:1): sending packet to 172.16.6.2 (I) QM_IDLE
Mar  7 16:14:29.455 GMT: ISAKMP (0:1): deleting node -216243713 error FALSE reason ""
Mar  7 16:14:29.455 GMT: ISAKMP (0:1): Node -216243713, Input = IKE_MESG_FROM_PEER,
  IKE_QM_EXCH
Old State = IKE_QM_I_QM1  New State = IKE_QM_PHASE2_COMPLETE
Tokyo#

The last message in the quick mode exchange is sent by Tokyo to Osaka in highlighted line 1. This message again serves as an acknowledgement and as an indicator of liveliness.

Finally, in highlighted line 2, the message IKE_QM_PHASE2_COMPLETE is displayed. This shows that phase 2 (quick mode) is complete.

Once IKE quick mode is complete, you can verify that IPSec SAs have been successfully negotiated using the show crypto ipsec sa command.

Example 8-79 shows the output of the show crypto ipsec sa command.

Example 8-79. IPSec SAs
Tokyo#show crypto ipsec sa
interface: Serial4/0
    Crypto map tag: mjlnetmap, local addr. 172.16.5.1
   local  ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (10.2.2.0/255.255.255.0/0/0)
   current_peer: 172.16.6.2
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 4, #pkts encrypt: 4, #pkts digest 4
    #pkts decaps: 4, #pkts decrypt: 4, #pkts verify 4
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0
    #send errors 1, #recv errors 0
     local crypto endpt.: 172.16.5.1, remote crypto endpt.: 172.16.6.2
     path mtu 1500, media mtu 1500
     current outbound spi: 6DEA8F23
     inbound esp sas:
      spi: 0x249582ED(613778157)
        transform: esp-des esp-md5-hmac ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 2000, flow_id: 1, crypto map: mjlnetmap
        sa timing: remaining key lifetime (k/sec): (4607999/3314)
        IV size: 8 bytes
        replay detection support: Y
     inbound ah sas:
     inbound pcp sas:
     outbound esp sas:
      spi: 0x6DEA8F23(1844088611)
        transform: esp-des esp-md5-hmac ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 2001, flow_id: 2, crypto map: mjlnetmap
        sa timing: remaining key lifetime (k/sec): (4607999/3314)
        IV size: 8 bytes
        replay detection support: Y
     outbound ah sas:
     outbound pcp sas:

Tokyo#

Highlighted lines 1 and 2 show that crypto map mjlnetmap is applied to interface serial 4/0 and that the local IP address is 172.16.5.1.

The local and remote (proxy) identities are shown in highlighted lines 3 and 4. These correspond to the addresses, masks, protocols, and ports specified in the crypto access list.

Highlighted line 5 shows the IPSec peer address (172.16.6.2, Osaka). The local and remote endpoints (Tokyo and Osaka) are shown in highlighted line 6. The path and local media MTUs are shown in highlighted line 7. In highlighted line 8, you can see the Security Parameter Index (SPI) associated with the outbound IPSec SA. Note that an SA is uniquely identified by an SPI, an IP destination address, and a security protocol (ESP or AH) identifier.

Inbound ESP SAs associated with interface serial 4/0 are shown starting from highlighted line 9 (there is only one). The transform set, tunnel mode, connection ID, flow ID, crypto map, SA lifetime, initialization vector (IV) size, and replay detection support settings associated with the SA are also shown.

Note that one connection ID is associated with each SA. An initialization vector is used to initialize the first round of cipher block chaining (CBC). CBC is used in conjunction with DES or AES encryption in cipher-block chaining mode.

Highlighted lines 10 and 11 show that there are currently no AH and IP Payload Compression Protocol (PCP) SAs. PCP provides network-layer compression and can be used in conjunction with IPSec. PCP requires that a SA be set up between IPSec peers. Note that the two compression algorithms that are defined for use with PCP are Lempel-Ziv-Stac (LZS) and Deflate. On Cisco routers, only LZS can be used. In highlighted line 12, you can see the outbound ESP SA associated with interface serial 4/0.

IKE phase 2 (quick mode) negotiations can fail for a number of reasons, including the following:

  • An IPSec transform set mismatch exists between peers.

  • The peers' crypto access lists are asymmetric.

  • A DN-based crypto map prevents quick mode negotiation with a peer.

These possible causes of IKE phase 2 negotiation failure are discussed in the following sections.

It is worth noting that if there is a NAT device in the path between the initiator and the responder, it is also possible for this to cause IKE negotiation failure. See the section entitled "NAT Device Blocks IPSec Traffic" later in this chapter for more details.

NOTE

It might be necessary to clear the existing ISAKMP and IPSec SAs when troubleshooting issues contained in this section.

Use the clear crypto isakmp command to clear existing ISAKMP SAs.

Use the clear crypto sa command to clear existing IPSec SAs.

IPSec Transform Set Mismatch Exists Between Peers

If IPSec transform sets are mismatched between IPSec peers, IKE phase 2 (quick mode) will fail.

Use the debug crypto isakmp command to troubleshoot this issue, as demonstrated in Example 8-80. Note that only the relevant portion of the output is shown.

Example 8-80. IKE Quick Mode Fails with Transform Set Mismatch
Tokyo#debug crypto isakmp
Crypto ISAKMP debugging is on
Tokyo#
Old State = UNKNOWN  New State = IKE_P1_COMPLETE
Mar 11 20:31:24.094 GMT: ISAKMP (0:1): beginning Quick Mode exchange, M-ID of
  1110884980
Mar 11 20:31:24.094 GMT: ISAKMP (0:1): sending packet to 172.16.6.2 (I) QM_IDLE
Mar 11 20:31:24.094 GMT: ISAKMP (0:1): Node -1110884980, Input = IKE_MESG_INTERNAL,
  IKE_INIT_QM
Old State = IKE_QM_READY  New State = IKE_QM_I_QM1
Mar 11 20:31:24.094 GMT: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE
Old State = IKE_P1_COMPLETE  New State = IKE_P1_COMPLETE
Mar 11 20:31:24.194 GMT: ISAKMP (0:1): received packet from 172.16.6.2 (I) QM_IDLE
Mar 11 20:31:24.194 GMT: ISAKMP (0:1): processing HASH payload. message ID =
  1998102984
Mar 11 20:31:24.194 GMT: ISAKMP (0:1): processing NOTIFY PROPOSAL_NOT_CHOSEN
  protocol 3
    spi 4050089439, message ID = 1998102984, sa = 62C239EC
Mar 11 20:31:24.194 GMT: ISAKMP (0:1): deleting spi 4050089439 message ID = -
  1110884980
Mar 11 20:31:24.194 GMT: ISAKMP (0:1): deleting node -1110884980 error TRUE reason
  "delete_larval"
Mar 11 20:31:24.194 GMT: ISAKMP (0:1): deleting node 1998102984 error FALSE reason
  "informational (in) state 1"
Mar 11 20:31:24.194 GMT: ISAKMP (0:1): Input = IKE_MESG_FROM_PEER, IKE_INFO_NOTIFY
Old State = IKE_P1_COMPLETE  New State = IKE_P1_COMPLETE
Tokyo#

In highlighted line 1, you can see that the state has changed to IKE_P1_COMPLETE1. This indicates that IKE phase 1 negotiation has been completed successfully.

Highlighted line 2 indicates that IKE quick mode is about to begin, and in highlighted line 3, Tokyo sends the first quick mode packet to Osaka (172.16.6.2).

Then in highlighted line 4, the second quick mode packet is received from Osaka. Highlighted line 5 shows that this packet contains a Notify message indicating that the proposal (transform set) has been rejected. This means that the transform set on Osaka doesn't match that on Tokyo.

To examine the IPSec transform set, use the show crypto ipsec transform-set command.

Example 8-81 shows the output of the show crypto ipsec transform-set command on Tokyo and Osaka.

Example 8-81. IPSec Transform Set on Tokyo and Osaka
Tokyo#show crypto ipsec transform-set
Transform set mjlnet: {esp-des esp-sha-hmac  }
   will negotiate = {Tunnel,  },
Tokyo#
________________________________________________________________
Osaka#show crypto ipsec transform-set
Transform set mjlnet: {esp-des esp-md5-hmac  }
   will negotiate = {Tunnel,  },

Osaka#

If you compare the two transform sets, you can see that the ESP hash algorithm on Tokyo is SHA-HMAC, and on Osaka it is MD5-HMAC: clearly a mismatch. The solution is to reconfigure either Tokyo or Osaka so that they are both the same.

Example 8-82 shows the reconfiguration of the hash algorithm on Tokyo.

Example 8-82. Reconfiguration of the Key Hashing Algorithm on Tokyo
Tokyo#conf t
Enter configuration commands, one per line.  End with CNTL/Z.

Tokyo(config)#crypto ipsec transform-set mjlnet esp-des esp-md5-hmac
Tokyo(config)#exit
Tokyo#

In Example 8-82, the transform set is modified as appropriate. Once the hash algorithm has been modified, the IPSec SAs are successfully negotiated. Successful negotiation of the IPSec SAs is verified using the show crypto ipsec sa command in Example 8-83.

Example 8-83. IPSec SAs Are Successfully Negotiated
Tokyo#show crypto ipsec sa
interface: Serial4/0
    Crypto map tag: mjlnetmap, local addr. 172.16.5.1
   local  ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (10.2.2.0/255.255.255.0/0/0)
   current_peer: 172.16.6.2
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 4, #pkts encrypt: 4, #pkts digest 4
    #pkts decaps: 4, #pkts decrypt: 4, #pkts verify 4
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0
    #send errors 6, #recv errors 0
     local crypto endpt.: 172.16.5.1, remote crypto endpt.: 172.16.6.2
     path mtu 1500, media mtu 1500
     current outbound spi: 7FED973B
     inbound esp sas:
      spi: 0xF5707082(4117786754)
        transform: esp-des esp-md5-hmac ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 2000, flow_id: 1, crypto map: mjlnetmap
        sa timing: remaining key lifetime (k/sec): (4607998/3540)
        IV size: 8 bytes
        replay detection support: Y
     inbound ah sas:
     inbound pcp sas:
     outbound esp sas:
      spi: 0x7FED973B(2146277179)
        transform: esp-des esp-md5-hmac ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 2001, flow_id: 2, crypto map: mjlnetmap
        sa timing: remaining key lifetime (k/sec): (4607999/3540)
        IV size: 8 bytes
        replay detection support: Y
     outbound ah sas:
     outbound pcp sas:

Tokyo#

Highlighted line 1 shows the local and remote tunnel endpoints (Tokyo and Osaka, respectively). In highlighted lines 2 and 3, you can see that inbound and outbound IPSec SAs have been successfully negotiated.

Note that you should also ensure that the set peer {hostname | ip_address} command is correctly configured within the crypto map on the responder. If this is incorrectly specified, then phase 2 (quick mode) negotiation will fail.

Peers' Crypto Access Lists Are Asymmetric

If crypto access lists on the IPSec peers are asymmetric (not mirror images of each other), problems may ensue. One result of asymmetrical access lists is that quick mode (and IPSec SAs) will not be successfully negotiated. Another is that one peer will be able to initiate successful quick mode, but the other will not. Use the debug crypto isakmp command to troubleshoot this issue.

In this scenario, Tokyo initiates IKE negotiation. In Example 8-84, Tokyo initiates quick mode negotiation. Note that only the relevant portion of the output is shown.

Example 8-84. Tokyo Initiates Quick Mode Negotiation
Tokyo#debug crypto isakmp
Crypto ISAKMP debugging is on
Tokyo#
Mar 11 22:45:57.855 GMT: ISAKMP (0:1): beginning Quick Mode exchange, M-ID of
  -324913471
Mar 11 22:45:57.855 GMT: ISAKMP. (0:1): sending packet to 172.16.6.2 (I) QM_IDLE
Mar 11 22:45:57.855 GMT: ISAKMP (0:1): Node -324913471, Input = IKE_MESG_INTERNAL,
  IKE_INIT_QM
Old State = IKE_QM_READY  New State = IKE_QM_I_QM1
Mar 11 22:45:57.855 GMT: ISAKMP (0:1): Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE
Old State = IKE_P1_COMPLETE  New State = IKE_P1_COMPLETE
Mar 11 22:45:57.959 GMT: ISAKMP (0:1): received packet from 172.16.6.2 (I) QM_IDLE
Mar 11 22:45:57.959 GMT: ISAKMP (0:1): processing HASH payload. message ID =
  1298728624
Mar 11 22:45:57.959 GMT: ISAKMP (0:1): processing NOTIFY PROPOSAL_NOT_CHOSEN
  protocol 3
    spi 3852444734, message ID = 1298728624, sa = 632F8428
Mar 11 22:45:57.959 GMT: ISAKMP (0:1): deleting spi 3852444734 message ID = -324913471
Mar 11 22:45:57.959 GMT: ISAKMP (0:1): deleting node -324913471 error TRUE reason
  "delete_larval"
Mar 11 22:45:57.959 GMT: ISAKMP (0:1): deleting node 1298728624 error FALSE reason
  "informational (in) state 1"
Mar 11 22:45:57.959 GMT: ISAKMP (0:1): Input = IKE_MESG_FROM_PEER, IKE_INFO_NOTIFY
Old State = IKE_P1_COMPLETE  New State = IKE_P1_COMPLETE
Tokyo#

Highlighted line 1 shows that quick mode negotiation is about to begin. The first packet in the quick mode exchange is sent by Tokyo to Osaka (172.16.6.2) in highlighted line 2. This packet contains the IPSec proposal (transform set).

A packet is then received from Osaka in highlighted line 3. Highlighted line 4 shows that the packet from Osaka contained a Notify message indicating that the IPSec proposal was rejected. Failure of quick mode initiated by Tokyo to negotiate IPSec SAs is verified using the show crypto ipsec sa command in Example 8-85.

Highlighted line 1 in Example 8-85 shows that the local and remote endpoints are Tokyo (172.16.5.1) and Osaka (172.16.6.2), respectively. Below that you can see that no SAs have been negotiated.

Example 8-85. No IPSec SAs Negotiated When Quick Mode Is Initiated by Tokyo
Tokyo#show crypto ipsec sa
interface: Serial4/0
    Crypto map tag: mjlnetmap, local addr. 172.16.5.1
   local  ident (addr/mask/prot/port): (10.1.0.0/255.255.0.0/0/0)
   remote ident (addr/mask/prot/port): (10.2.0.0/255.255.0.0/0/0)
   current_peer: 172.16.6.2
     PERMIT, flags={origin_is_acl,}
    #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 10, #recv errors 0
     local crypto endpt.: 172.16.5.1, remote crypto endpt.: 172.16.6.2
     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:

Tokyo#

When quick mode is initiated from Osaka, however, quick mode successfully negotiates IPSec SAs. This is verified using the show crypto ipsec sa command in Example 8-86.

Example 8-86. IPSec SAs Are Negotiated When Quick Mode Is Initiated by Osaka
Osaka#show crypto ipsec sa
interface: Serial2/0
    Crypto map tag: mjlnetmap, local addr. 172.16.6.2
   local  ident (addr/mask/prot/port): (10.2.2.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0)
   current_peer: 172.16.5.1
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 4, #pkts encrypt: 4, #pkts digest 4
    #pkts decaps: 4, #pkts decrypt: 4, #pkts verify 4
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0
    #send errors 1, #recv errors 0
     local crypto endpt.: 172.16.6.2, remote crypto endpt.: 172.16.5.1
     path mtu 1500, media mtu 1500
     current outbound spi: B75DB07A
     inbound esp sas:
      spi: 0xB0FC85E9(2969339369)
        transform: esp-des esp-md5-hmac ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 2000, flow_id: 1, crypto map: mjlnetmap
        sa timing: remaining key lifetime (k/sec): (4607999/3530)
        IV size: 8 bytes
        replay detection support: Y
     inbound ah sas:
     inbound pcp sas:
     outbound esp sas:
      spi: 0xB75DB07A(3076370554)
        transform: esp-des esp-md5-hmac ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 2001, flow_id: 2, crypto map: mjlnetmap
        sa timing: remaining key lifetime (k/sec): (4607999/3530)
        IV size: 8 bytes
        replay detection support: Y
     outbound ah sas:
     outbound pcp sas:
Osaka#

Highlighted line 1 shows that the local and remote endpoints are Osaka and Tokyo, respectively. In highlighted lines 2 and 3, you can see that inbound and outbound ESP SAs have been negotiated.

A look at the crypto access lists on Tokyo and Osaka reveals that they are asymmetric, as indicated in Example 8-87.

Example 8-87. Crypto Access Lists on Tokyo and Osaka
Tokyo#show crypto map tag mjlnetmap
Crypto Map "mjlnetmap" 10 ipsec-isakmp
    Peer = 172.16.6.2
    Extended IP access list 101
        access-list 101 permit ip 10.1.0.0 0.0.255.255 10.2.0.0 0.0.255.255
    Current peer: 172.16.6.2
    Security association lifetime: 4608000 kilobytes/3600 seconds
    PFS (Y/N): N
    Transform sets={mjlnet, }
    Interfaces using crypto map mjlnetmap:
        Serial4/0
Tokyo#
________________________________________________________________
Osaka#show crypto map tag mjlnetmap
Crypto Map "mjlnetmap" 10 ipsec-isakmp
        Peer = 172.16.5.1
        Extended IP access list 101
            access-list 101 permit ip 10.2.2.0 0.0.0.255 10.1.1.0 0.0.0.255
        Current peer: 172.16.5.1
        Security association lifetime: 4608000 kilobytes/3600 seconds
        PFS (Y/N): N
        Transform sets={mjlnet, }
        Interfaces using crypto map mjlnetmap:
                Serial2/0
Osaka#

You can see in highlighted lines 1 and 2 that the two crypto access lists are asymmetric. On Tokyo, the source address and mask are 10.1.0.0 and 0.0.255.255, and the destination address and mask are 10.2.0.0 0.0.255.255. On Osaka, the source address and mask are 10.2.2.0 and 0.0.0.255, and the destination address and mask are 10.1.1.0 and 0.0.0.255.

The reason that Tokyo could not initiate successful quick mode negotiation with Osaka is that its crypto access list encompasses addresses outside the range defined by the crypto access list on Osaka. Osaka, therefore, rejected Tokyo's IPSec SA proposal.

Osaka, on the other hand, was able to initiate successful quick mode negotiation because its crypto access list encompasses addresses that fall within the range specified by Tokyo's crypto access list.

In Example 8-88, Tokyo's crypto access list is modified to be symmetrical (a mirror image of) Osaka's crypto access list.

Example 8-88. Tokyo's Crypto Access List Is Modified
Tokyo#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Tokyo(config)#no access-list 101
Tokyo(config)#access-list 101 permit ip 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255
Tokyo(config)#exit
Tokyo#

Once Tokyo's crypto access list has been modified, Tokyo is able to initiate successful quick mode negotiation with Osaka. This is verified using the show crypto ipsec sa command in Example 8-89.

Example 8-89. Tokyo Can Now Initiate Successful Quick Mode Negotiation
Tokyo#show crypto ipsec sa
interface: Serial4/0
    Crypto map tag: mjlnetmap, local addr. 172.16.5.1
   local  ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (10.2.2.0/255.255.255.0/0/0)
   current_peer: 172.16.6.2
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 4, #pkts encrypt: 4, #pkts digest 4
    #pkts decaps: 4, #pkts decrypt: 4, #pkts verify 4
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0
    #send errors 1, #recv errors 0
     local crypto endpt.: 172.16.5.1, remote crypto endpt.: 172.16.6.2
     path mtu 1500, media mtu 1500
     current outbound spi: 72D2164E
     inbound esp sas:
      spi: 0x91A4BE0F(2443492879)
        transform: esp-des esp-md5-hmac ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 2000, flow_id: 1, crypto map: mjlnetmap
        sa timing: remaining key lifetime (k/sec): (4607998/3577)
        IV size: 8 bytes
        replay detection support: Y
     inbound ah sas:
     inbound pcp sas:
     outbound esp sas:
      spi: 0x72D2164E(1926370894)
        transform: esp-des esp-md5-hmac ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 2001, flow_id: 2, crypto map: mjlnetmap
        sa timing: remaining key lifetime (k/sec): (4607999/3577)
        IV size: 8 bytes
        replay detection support: Y
     outbound ah sas:
     outbound pcp sas:

Tokyo#

Highlighted line 1 shows the local and remote endpoints are Tokyo and Osaka, respectively. In highlighted lines 2 and 3, you can see that inbound and outbound ESP SAs have been negotiated with Osaka. The issue is now resolved.

CAUTION

It is inadvisable to use the any keyword in crypto access lists because it can cause the router to drop control protocol traffic, such as routing protocol traffic, because it is not encrypted.

If you do decide to use the any keyword, make sure that you use appropriate deny keywords to specify that control protocol traffic should not be encrypted.

DN-Based Crypto Map Prevents Quick Mode Negotiation with a Peer

If you are using Distinguished Name (DN) based crypto maps, you must be careful to ensure that they are correctly configured to permit the intended peers. If a peer is not permitted by the DN-based crypto map, quick mode negotiation will fail.

In this example, network administrators in Osaka are complaining that they are unable to initiate an IPSec tunnel to Tokyo.

Use the debug crypto isakmp command to troubleshoot this issue, as shown in Example 8-90. Note that only the relevant portion of the output is shown.

Example 8-90. IPSec Tunnel Between Tokyo and Osaka Fails
[View full width]
Tokyo#debug crypto isakmp
Crypto ISAKMP debugging is on
Tokyo#
Old State = IKE_P1_COMPLETE  New State = IKE_P1_COMPLETE
00:43:29: ISAKMP (0:1): received packet from 172.16.6.2 (I) QM_IDLE
00:43:29: ISAKMP (0:1): processing HASH payload. message ID = 531797542
00:43:29: ISAKMP (0:1): processing SA payload. message ID = 531797542
00:43:29: ISAKMP (0:1): Checking IPSec proposal 1
00:43:29: ISAKMP: transform 1, ESP_DES
00:43:29: ISAKMP:   attributes in transform:
00:43:29: ISAKMP:      encaps is 1
00:43:29: ISAKMP:      SA life type in seconds
00:43:29: ISAKMP:      SA life duration (basic) of 3600
00:43:29: ISAKMP:      SA life type in kilobytes
00:43:29: ISAKMP:      SA life duration (VPI) of  0x0 0x46 0x50 0x0
00:43:29: ISAKMP:      authenticator is HMAC-MD5
00:43:29: %CRYPTO-4-IKE_QUICKMODE_BAD_CERT: encrypted connection attempted with a peer
  without the configured certificate attributes
00:43:29: ISAKMP (0:1): atts not acceptable. Next payload is 0
00:43:29: ISAKMP (0:1): phase 2 SA not acceptable!
00:43:29: ISAKMP (0:1): sending packet to 172.16.6.2 (I) QM_IDLE
00:43:29: ISAKMP (0:1): purging node 1379210405
00:43:29: ISAKMP (0:1): Unknown Input for node 531797542: state = IKE_QM_I_QM1, major =
   0x00000001, minor = 0x0000000C
00:43:29: %CRYPTO-6-IKMP_MODE_FAILURE: Processing of Quick mode failed with peer at
  172.16.6.2
Tokyo#

In highlighted line 1, phase 1 has been completed, and quick mode is about to begin. The first quick mode packet is received from Osaka (172.16.6.2) in highlighted line 2.

The payload of the packet is then processed, but in highlighted line 3, Tokyo reports encrypted connection attempted with a peer without the configured certificate attributes. Finally, in highlighted lines 4 and 5, Tokyo reports that the attributes in the packet sent by Osaka are not acceptable and that quick mode negotiation has failed.

The error message in highlighted line 3 is the key to solving this issue. It indicates that the peer is not permitted by the DN-based crypto map.

Use the show crypto map tag crypto_map_name command to examine the crypto map, as shown in Example 8-91.

Example 8-91. Crypto Map Shows an Identity List
Tokyo#show crypto map tag mjlnetmap
Crypto Map "mjlnetmap" 10 ipsec-isakmp
        Peer = 172.16.6.2
        Extended IP access list 101
            access-list 101 permit ip 10.1.1.0 0.0.0.255 10.2.2.0 0.0.0.255
        Current peer: 172.16.6.2
        Allowed identity list = from-mjlnet
        Security association lifetime: 4608000 kilobytes/3600 seconds
        PFS (Y/N): N
        Transform sets={mjlnet, }
        Interfaces using crypto map mjlnetmap:
                Serial4/0
Tokyo#

As you can see, the identity list from-mjlnet is configured in crypto map mjlnetmap.

To examine the identity list, use the show crypto identity identity_list_name command as shown in Example 8-92.

Example 8-92. Identity List Permits Only Niigata.mjlnet.com
Tokyo#show crypto identity from-mjlnet
crypto identity from-mjlnet:
   fqdn Niigata.mjlnet.com
Tokyo#

The highlighted line indicates that the identity list permits only the FQDN Niigata.mjlnet.com. So only this peer will be able to establish a tunnel with Tokyo.

To allow Osaka to establish an IPSec tunnel with Tokyo, the FQDN for Osaka is added to the identity list, as shown in Example 8-93.

Example 8-93. Osaka Is Added to the Identity List
Tokyo#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Tokyo(config)#crypto identity from-mjlnet
Tokyo(config-crypto-identity)#fqdn Osaka.mjlnet.com
Tokyo(config-crypto-identity)#end
Tokyo#

Once the identity list has been modified, an IPSec tunnel from Osaka is established. This is verified using the show crypto ipsec sa command, as demonstrated in Example 8-94.

Example 8-94. IPSec Tunnel Is Established to Osaka
Tokyo#show crypto ipsec sa
interface: Serial4/0
    Crypto map tag: mjlnetmap, local addr. 172.16.5.1
   local  ident (addr/mask/prot/port): (10.1.1.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (10.2.2.0/255.255.255.0/0/0)
   current_peer: 172.16.6.2:500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 26, #pkts encrypt: 26, #pkts digest 26
    #pkts decaps: 26, #pkts decrypt: 26, #pkts verify 26
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0
     local crypto endpt.: 172.16.5.1, remote crypto endpt.: 172.16.6.2
     path mtu 1500, media mtu 1500
     current outbound spi: 61E5F098
     inbound esp sas:
      spi: 0x1FE27FD5(534937557)
        transform: esp-des esp-md5-hmac ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 2000, flow_id: 1, crypto map: mjlnetmap
        sa timing: remaining key lifetime (k/sec): (4607992/2334)
        IV size: 8 bytes
        replay detection support: Y
     inbound ah sas:
     inbound pcp sas:
     outbound esp sas:
      spi: 0x61E5F098(1642459288)
        transform: esp-des esp-md5-hmac ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 2001, flow_id: 2, crypto map: mjlnetmap
        sa timing: remaining key lifetime (k/sec): (4607996/2334)
        IV size: 8 bytes
        replay detection support: Y
     outbound ah sas:
     outbound pcp sas:
Tokyo#

Highlighted line 1 shows the local and remote (172.16.6.2, Osaka) tunnel endpoints. In highlighted lines 2 and 3, you can see that both inbound and outbound ESP SAs have been established.

User Traffic Does Not Successfully Cross the IPSec Tunnel

Once the IKE phase 1 and phase 2 have been successfully negotiated and the IPSec tunnel has been established, user traffic should be able to cross the tunnel between the IPSec peers, as illustrated in Figure 8-17.

Figure 8-17. User Traffic Crosses the Tunnel Between the IPSec Peers

[View full size image]

If traffic is sent over the IPSec tunnel but does not arrive at the remote site, there are a number of possible causes, including the following:

  • An access list or firewall is blocking AH or ESP in the path to the destination.

  • A Network Address Translation (NAT) device is in the path to the remote peer.

These issues are discussed in the following two sections.

Note that you should also verify that the responder has a route to the destination address specified in its crypto access list using the show ip access-lists and show ip route commands.

Access List or Firewall Is Blocking AH or ESP

If an access list or firewall is blocking AH (IP protocol 51) or ESP (IP protocol 50) then IPSec tunnel traffic will be dropped.

In this example, IPSec tunnel traffic sent from Tokyo is not reaching end hosts at the Osaka site. An examination of the Osaka router using the show ip interface command in Example 8-95 reveals the presence of an access list on the external (Internet) interface.

Example 8-95. Access List on Interface Serial 2/0
Osaka#show ip interface serial 2/0
Serial2/0 is up, line protocol is up
  Internet address is 172.16.6.2/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
  Multicast reserved groups joined: 224.0.0.10
  Outgoing access list is not set
  Inbound  access list is 105
  Proxy ARP is enabled
  Security level is default
  Split horizon is enabled

In highlighted line 1, you can see that access list 105 is configured on interface serial 2/0. Access list 105 is then examined using the show ip access-lists command, as shown in Example 8-96.

Example 8-96. Access List 105
Osaka#show ip access-lists 105
Extended IP access list 105
    deny esp any any (20 matches)
    permit ip any any (134 matches)
Osaka#

As you can see, the (slightly contrived) access list blocks ESP traffic. Because IPSec tunnel traffic in this example is using an ESP, it is being dropped by Osaka.

Access list 105 is then removed from the interface in Example 8-97.

Example 8-97. Removal of Access List 105 from the Interface
Osaka#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Osaka(config)#interface serial 2/0
Osaka(config-if)#no ip access-group 105 in
Osaka(config-if)#end
Osaka#

Once the access list has been removed, user traffic crosses the IPSec tunnel from Tokyo to end hosts at the Osaka site.

It is also worth noting that if an access list is configured on a tunnel endpoint, such as Osaka in this example, you must be sure to allow both AH/ESP and the source and destination addresses and ports in the original IP packet.

This means that if a Telnet packet is sent from host 10.1.1.1 at the Tokyo site to host 10.2.2.1 at the Osaka site, an access list on the external interface of Osaka should permit both AH/ESP (depending on the security protocol), and source/destination address 10.1.1.1/10.2.2.1, plus TCP port 23 (Telnet). This is necessary because all IPSec tunnel packets are tested against an external interface access list twicewhen they first arrive in the encapsulated form, and then after the AH/ESP headers have been removed.

NAT Device Blocks IPSec Traffic

If there is NAT device in the path between the IPSec peers, it might cause IKE negotiation to fail or IPSec traffic to be dropped if the IPSec peers are not configured to support NAT.

NOTE

To allow IPSec traffic to successfully traverse a NAT device, you can use ESP authentication rather than AH (NAT devices modify the outer IP header, which causes the AH integrity check to fail), use tunnel mode instead of transport mode, use the IPSec NAT transparency feature, or use an IPSec-aware NAT device. A fuller discussion is beyond the scope of this chapter, but more details can be found at the following URLs:

http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a0080110bca.html

http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a0080110c03.html

http://www.cisco.com/en/US/products/sw/iosswrel/ps1839/products_feature_guide09186a00801541de.html


Case Studies

This section contains some troubleshooting issues that are slightly more uncommon than those contained in the main section on troubleshooting IPSec VPNs.

Topics covered in this section include CA server authentication and enrollment issues, together with VPN client IKE negotiation issues.

CA Authentication or Enrollment Fails

If you are using a certificate server for certificate distribution, you will need to authenticate the CA server and then enroll your router with the CA to obtain a certificate. A number of issues can, however, cause authentication or enrollment to fail.

In this case study, the network administrator at the Tokyo site is attempting to obtain a certificate for the local router.

In Example 8-98, the administrator attempts to authenticate the CA by obtaining the CA server certificate from the server.

Example 8-98. CA Authentication Fails
Tokyo#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Tokyo(config)#crypto ca authenticate mjlnetca
% CA Cert not yet valid or is expired -
    start date: 15:11:14 GMT Mar 14 2003
    end   date: 15:19:53 GMT Mar 14 2005
% Error processing Certificate Authority certificate.
Tokyo(config)#exit
Tokyo#

In highlighted line 1, the administrator issues the command to obtain the CA certificate and authenticate the CA server. Then in highlighted line 2, the router reports that the CA's certificate is not yet valid or is expired.

If you examine highlighted lines 3 and 4, you can see that the CA certificate's start date is March 14 2003, and the end date is March 14 2005. The message in highlighted line 2, therefore, indicates that the time on the router is outside this range.

The problem is soon revealed when the router's clock is examined using the show clock command, as shown in Example 8-99.

Example 8-99. Tokyo's Clock Is Incorrect
Tokyo#show clock
21:02:48.563 GMT Sun Jun 27 2025
Tokyo#

As you can see, someone has incorrectly set Tokyo's clock. In this case, because NTP is not being used, the clock can be reset locally on Tokyo using the clock set command. This is demonstrated in Example 8-100.

TIP

If your routers do not have hardware clocks, every time they are rebooted the clock will be resetthis is a good reason to use NTP instead.

Example 8-100. Tokyo's Clock Is Reset
Tokyo#clock set 21:01:00 14 march 2003

Once Tokyo's clock has been reset, CA authentication, together with enrollment for Tokyo, succeeds. This is shown in Example 8-101.

Example 8-101. CA Authentication and Enrollment Succeed
Tokyo#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Tokyo(config)#crypto ca authenticate mjlnetca
Certificate has the following attributes:
Fingerprint: 9C514FE0 A4A56F42 8612D771 6AC073FC
% Do you accept this certificate? [yes/no]: yes
Tokyo(config)#
Tokyo(config)#crypto ca enroll mjlnetca
%
% Start certificate enrollment ..
% Create a challenge password. You will need to verbally provide this
   password to the CA Administrator in order to revoke your certificate.
   For security reasons your password will not be saved in the configuration.
   Please make a note of it.
Password:
Re-enter password:
% The subject name in the certificate will be: Tokyo.mjlnet.com
% Include the router serial number in the subject name? [yes/no]: yes
% The serial number in the certificate will be: 0168FEB5
% Include an IP address in the subject name? [yes/no]: yes
Interface: serial4/0
Request certificate from CA? [yes/no]: yes
% Certificate request sent to Certificate Authority
% The certificate request fingerprint will be displayed.
% The 'show crypto ca certificate' command will also show the fingerprint.
Tokyo(config)#    Fingerprint:  C51338A8 62CA6739 6E88718E CC574ACF
Tokyo(config)#
00:13:27: CRYPTO_PKI: status = 102: certificate request pending
00:13:36: CRYPTO_PKI: status = 102: certificate request pending
00:14:39: %CRYPTO-6-CERTRET: Certificate received from Certificate Authority
Tokyo(config)#exit
Tokyo#

In highlighted line 1, CA authentication is attempted using the crypto ca authenticate command. Then in highlighted line 2, the administrator is asked to accept the CA's certificate (which he does), indicating that the CA's certificate has been successfully downloaded and accepted. Finally, in highlighted lines 3 and 4, the administrator enrolls Tokyo with the CA and receives a certificate.

Successful enrollment is confirmed using the show crypto ca certificates command, as shown in Example 8-102.

Example 8-102. Tokyo Has Successfully Enrolled
Tokyo#show crypto ca certificates
Certificate
  Status: Available
  Certificate Serial Number: 1135294300000000000A
  Key Usage: General Purpose
  Issuer:
    CN = mjlnetca
     OU = mjlnet
     O = MJL Network Services
     L = London
     ST = London
     C = UK
     EA =<16> mark@mjlnet.com
  Subject Name Contains:
    Name: Tokyo.mjlnet.com
    IP Address: 172.16.5.1
    Serial Number: 0168FEB5
  CRL Distribution Point:
    http://markacs/CertEnroll/mjlnetca.crl
  Validity Date:
    start date: 20:52:50 GMT Mar 14 2003
    end   date: 21:02:50 GMT Mar 14 2004
  Associated Identity: mjlnetca

As you can see, a certificate for Tokyo has been obtained from the CA. This is indicated by the certificate's available status (highlighted line 1). The issue is resolved.

Numerous of other issues can cause CA authentication or enrollment to fail. Some of these are as follows:

  • The crypto ca trustpoint or ca identity parameters are misconfigured.

    If any of the trustpoint or ca identity parameters are misconfigured, there may be problems with certificate enrollment.

    See the section "Configuring Site-to-Site IPSec VPNs with Digital Certificates" on page 677 for more details.

  • The CA server is unreachable on TCP port 80 (HTTP) or UDP port 69 (TFTP).

    Ensure that the CA server is reachable via TCP port 80 from the router if you are using HTTP for certificate enrollment.

    If you are using TFTP, then ensure that the server is reachable via UDP port 69. If the server is unreachable from the router CA server authentication and enrollment will fail.

    Note that the following error message is logged if the server is unreachable during CA server authentication:

    Tokyo(config)#crypto ca authenticate mjlnetca
% Error in receiving Certificate Authority certificate: status = FAIL, cert
  length = 0
Tokyo(config)#

    If reachability to the CA server fails during enrollment, the following message is displayed by the debug crypto pki transactions command:

    Tokyo#debug crypto pki transactions
Crypto PKI Trans debugging is on
Tokyo#
Tokyo#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Tokyo(config)#crypto ca enroll mjlnetca

03:42:36: CRYPTO_PKI: status = 0: failed to open http connection

    Note that only the relevant portion of the output is shown.

  • Certificate enrollment is rejected.

    If the CA server rejects certificate enrollment, the following message is logged:

    00:17:25: %CRYPTO-6-CERTREJECT: Certificate enrollment request was rejected by
  Certificate Authority

    This message may indicate that the CA administrator has rejected the enrollment request, that the CA server has already issued a certificate to the router, or that you supplied an incorrect challenge password during enrollment.

  • The router cannot enroll with a Microsoft CA server.

    If you cannot enroll the router with a Microsoft CA server, this may indicate that the server is not configured to support Simple Certificate Enrollment Protocol (SCEP).

    Cisco routers use SCEP for certificate enrollment. Microsoft CA servers require you to install an additional component to support SCEP. This component can be installed by running the cepsetup.exe executable, which is available on the Microsoft Web site (www.microsoft.com).

  • The password you supplied during enrollment is incorrect.

    If you are using a Microsoft CA server, and it is configured to require a password during enrollment, you can view the password at the following URL:

    http://certificate-server-name-or-IP-address/certsrv/mscep

IKE Negotiation Fails with a Remote VPN Client

When connecting to a Cisco IOS router in a remote access VPN environment, you must be careful to ensure that the Cisco IOS router is configured to support IKE policy and IPSec transform set parameters that are compatible with the client.

In this example, a remote access user running Cisco VPN Client 3.x is attempting to connect to the corporate network via an IPSec tunnel to the Tokyo IOS router, as illustrated in Figure 8-18.

Figure 8-18. Remote Access Client Connects to the Corporate Network

When the client attempts to make a connection, however, it fails.

A Cisco VPN client should negotiate aggressive mode in phase 1, then extended authentication of the initiator (the VPN client) to the responder (Tokyo, in this case) should take place, parameters such as an IP address should be pushed to the client, and quick mode (phase 2) negotiation should be completed.

The network administrator examines the IKE negotiation sequence between the remote access client and Tokyo, using the debug crypto isakmp command. The output is shown in Examples 8-103 to 8-107.

Example 8-103. Aggressive Mode Negotiation with Remote Access Client Fails
Tokyo#debug crypto isakmp
Crypto ISAKMP debugging is on
Tokyo#
*Mar 15 16:13:42.807 GMT: ISAKMP (0:0): received packet from 172.16.7.56 dport 500
  sport 500 (N) NEW SA
*Mar 15 16:13:42.807 GMT: ISAKMP: Found a peer struct for 172.16.7.56, peer port 500
  by CONFIG
*Mar 15 16:13:42.811 GMT: ISAKMP: Locking peer struct 0x63BD36FC, IKE refcount 1 for
  crypto_ikmp_config_initialize_sa
*Mar 15 16:13:42.811 GMT: ISAKMP (0:0): (Re)Setting client xauth list  and state
*Mar 15 16:13:42.811 GMT: ISAKMP: local port 500, remote port 500
*Mar 15 16:13:42.811 GMT: ISAKMP (0:1): processing SA payload. message ID = 0
*Mar 15 16:13:42.811 GMT: ISAKMP (0:1): processing ID payload. message ID = 0
*Mar 15 16:13:42.811 GMT: ISAKMP (0:1): processing vendor id payload
*Mar 15 16:13:42.811 GMT: ISAKMP (0:1): vendor ID seems Unity/DPD but bad major
*Mar 15 16:13:42.811 GMT: ISAKMP (0:1): vendor ID is XAUTH
*Mar 15 16:13:42.811 GMT: ISAKMP (0:1): processing vendor id payload
*Mar 15 16:13:42.811 GMT: ISAKMP (0:1): vendor ID is DPD
*Mar 15 16:13:42.811 GMT: ISAKMP (0:1): vendor ID is NAT-T
*Mar 15 16:13:42.811 GMT: ISAKMP (0:1): processing vendor id payload
*Mar 15 16:13:42.811 GMT: ISAKMP (0:1): vendor ID seems Unity/DPD but bad major
*Mar 15 16:13:42.811 GMT: ISAKMP (0:1): vendor ID is NAT-T
*Mar 15 16:13:42.811 GMT: ISAKMP (0:1): processing vendor id payload
*Mar 15 16:13:42.811 GMT: ISAKMP (0:1): vendor ID seems Unity/DPD but bad major
*Mar 15 16:13:42.811 GMT: ISAKMP (0:1): processing vendor id payload
*Mar 15 16:13:42.811 GMT: ISAKMP (0:1): vendor ID is Unity
*Mar 15 16:13:42.811 GMT: ISAKMP (0:1): vendor ID is NAT-T
*Mar 15 16:13:42.811 GMT: ISAKMP (0:1) Authentication by xauth preshared

In highlighted line 1, phase 1 aggressive mode negotiation begins when a packet is received from the remote access client (172.16.7.56).

Tokyo then begins to process the contents of the packet, starting with the IKE SA, ID, and vendor ID payloads.

The vendor ID payload is used to announce capabilities such as extended authentication (XAUTH), dead peer discovery (DPD), NAT transparency (NAT-T), and support for the Unity protocol.

The IKE SA payload transforms (which correspond to IKE policies) sent by the remote access client are now compared to the policies configured on Tokyo, as shown in Example 8-104.

Example 8-104. SA Payload Transform to Tokyo's ISAKMP Policy Comparison Begins
*Mar 15 16:13:42.811 GMT: ISAKMP (0:1): Checking ISAKMP transform 1 against
  priority 10 policy
*Mar 15 16:13:42.811 GMT: ISAKMP:      encryption AES-CBC
*Mar 15 16:13:42.811 GMT: ISAKMP:      hash SHA
*Mar 15 16:13:42.811 GMT: ISAKMP:      default group 2
*Mar 15 16:13:42.811 GMT: ISAKMP:      auth XAUTHInitPreShared
*Mar 15 16:13:42.811 GMT: ISAKMP:      life type in seconds
*Mar 15 16:13:42.811 GMT: ISAKMP:      life duration (VPI) of  0x0 0x20 0xC4 0x9B
*Mar 15 16:13:42.811 GMT: ISAKMP:      keylength of 256
*Mar 15 16:13:42.811 GMT: ISAKMP (0:1): Encryption algorithm offered does not match
  policy!
*Mar 15 16:13:42.811 GMT: ISAKMP (0:1): atts are not acceptable. Next payload is 3
*Mar 15 16:13:42.811 GMT: ISAKMP (0:1): Checking ISAKMP transform 2 against
  priority 10 policy
*Mar 15 16:13:42.811 GMT: ISAKMP:      encryption AES-CBC
*Mar 15 16:13:42.811 GMT: ISAKMP:      hash MD5
*Mar 15 16:13:42.811 GMT: ISAKMP:      default group 2
*Mar 15 16:13:42.811 GMT: ISAKMP:      auth XAUTHInitPreShared
*Mar 15 16:13:42.815 GMT: ISAKMP:      life type in seconds
*Mar 15 16:13:42.815 GMT: ISAKMP:      life duration (VPI) of  0x0 0x20 0xC4 0x9B
*Mar 15 16:13:42.815 GMT: ISAKMP:      keylength of 256
*Mar 15 16:13:42.815 GMT: ISAKMP (0:1): Encryption algorithm offered does not match
  policy!
*Mar 15 16:13:42.815 GMT: ISAKMP (0:1): atts are not acceptable. Next payload is 3

In highlighted line 1 of Example 8-104, the first transform sent by the client is compared to IKE policy 10.

The attributes of the of the transform are then listed, and in highlighted line 2, Tokyo reports that the encryption algorithm (AES) contained within the transform does not match that in policy 10. For this reason, Tokyo rejects the transform in highlighted line 3.

Note also the message Next payload 3 message in highlighted line 3. This indicates that there is another transform contained in the packet sent by the client (see Table 8-1).

Tokyo now begins to compare this next transform to policy 10 (highlighted line 4), and in highlighted line 5 reports once again that the encryption algorithm does not match that in policy 10.

Note the attributes contained within the second transform (shown between highlighted lines 4 and 5) and those of the first transform (shown between highlighted lines 1 and 2). Notice that the hash algorithms are different (MD5 against SHA).

Tokyo continues to process and reject another 11 transforms (not shown for the sake of brevity/your sanity) until it reaches the 13th and 14th transforms, as shown in Example 8-105.

Example 8-105. SA Payload Comparison Ends
*Mar 15 16:13:42.819 GMT: ISAKMP (0:1): Checking ISAKMP transform 13 against
  priority 10 policy
*Mar 15 16:13:42.819 GMT: ISAKMP:      encryption DES-CBC
*Mar 15 16:13:42.819 GMT: ISAKMP:      hash MD5
*Mar 15 16:13:42.819 GMT: ISAKMP:      default group 2
*Mar 15 16:13:42.819 GMT: ISAKMP:      auth XAUTHInitPreShared
*Mar 15 16:13:42.819 GMT: ISAKMP:      life type in seconds
*Mar 15 16:13:42.819 GMT: ISAKMP:      life duration (VPI) of  0x0 0x20 0xC4 0x9B
*Mar 15 16:13:42.819 GMT: ISAKMP (0:1): Diffie-Hellman group offered does not match
  policy!
*Mar 15 16:13:42.819 GMT: ISAKMP (0:1): atts are not acceptable. Next payload is 3
*Mar 15 16:13:42.819 GMT: ISAKMP (0:1): atts are not acceptable. Next payload is 3
*Mar 15 16:13:42.823 GMT: ISAKMP (0:1): Checking ISAKMP transform 14 against
  priority 10 policy
*Mar 15 16:13:42.823 GMT: ISAKMP:      encryption DES-CBC
*Mar 15 16:13:42.823 GMT: ISAKMP:      hash MD5
*Mar 15 16:13:42.823 GMT: ISAKMP:      default group 2
*Mar 15 16:13:42.823 GMT: ISAKMP:      auth pre-share
*Mar 15 16:13:42.823 GMT: ISAKMP:      life type in seconds
*Mar 15 16:13:42.823 GMT: ISAKMP:      life duration (VPI) of  0x0 0x20 0xC4 0x9B
*Mar 15 16:13:42.823 GMT: ISAKMP (0:1): Diffie-Hellman group offered does not match
  policy!
*Mar 15 16:13:42.823 GMT: ISAKMP (0:1): atts are not acceptable. Next payload is 0

Having rejected 12 previous transforms because their encryption algorithms (AES and 3DES, not shown) do not match the policy, Tokyo now rejects these transforms because the Diffie-Hellman group does not match (highlighted lines 1 to 7). This is significant because it indicates that the encryption and hash algorithms (DES and MD5) specified in these transforms are OK.

Notice also the Diffie-Hellman group contained within the transforms shown in Examples 8-104 and 8-105. It is group 2. This is also the group specified in the transforms that are not shown. Also note the Next payload 0 message in highlighted line 7. This indicates that there are no more payloads (and transforms) contained in the packet (see Table 8-1).

Having failed to match any of the transforms sent by the client to policy 10, Tokyo begins to compare them to the default policy (65535).

Example 8-107 shows the comparison of the transforms to the default policy. Only the first and last (14th) comparisons are shown.

Example 8-106. Tokyo Compares the Client Transforms to the Default Policy
*Mar 15 16:13:42.823 GMT: ISAKMP (0:1): Checking ISAKMP transform 1 against
  priority 65535 policy
*Mar 15 16:13:42.823 GMT: ISAKMP:      encryption AES-CBC
*Mar 15 16:13:42.823 GMT: ISAKMP:      hash SHA
*Mar 15 16:13:42.823 GMT: ISAKMP:      default group 2
*Mar 15 16:13:42.823 GMT: ISAKMP:      auth XAUTHInitPreShared
*Mar 15 16:13:42.823 GMT: ISAKMP:      life type in seconds
*Mar 15 16:13:42.823 GMT: ISAKMP:      life duration (VPI) of  0x0 0x20 0xC4 0x9B
*Mar 15 16:13:42.823 GMT: ISAKMP:      keylength of 256
*Mar 15 16:13:42.823 GMT: ISAKMP (0:1): Encryption algorithm offered does not match
  policy!
*Mar 15 16:13:42.823 GMT: ISAKMP (0:1): atts are not acceptable. Next payload is 3
! Output omitted for brevity
*Mar 15 16:13:42.831 GMT: ISAKMP (0:1): Checking ISAKMP transform 14 against
  priority 65535 policy
*Mar 15 16:13:42.831 GMT: ISAKMP:      encryption DES-CBC
*Mar 15 16:13:42.831 GMT: ISAKMP:      hash MD5
*Mar 15 16:13:42.831 GMT: ISAKMP:      default group 2
*Mar 15 16:13:42.831 GMT: ISAKMP:      auth pre-share
*Mar 15 16:13:42.831 GMT: ISAKMP:      life type in seconds
*Mar 15 16:13:42.831 GMT: ISAKMP:      life duration (VPI) of  0x0 0x20 0xC4 0x9B
*Mar 15 16:13:42.831 GMT: ISAKMP (0:1): Hash algorithm offered does not match policy!
*Mar 15 16:13:42.831 GMT: ISAKMP (0:1): atts are not acceptable. Next payload is 0
*Mar 15 16:13:42.831 GMT: ISAKMP (0:1): no offers accepted!
*Mar 15 16:13:42.831 GMT: ISAKMP (0:1): phase 1 SA not acceptable!

In highlighted lines 1 to 3, Tokyo compares transform one to the default policy and then rejects it because the encryption algorithm (AES) does not match.

Then in highlighted lines 4 to 6, Tokyo compares the 14th and final transform to the default policy and again rejects itthis time because the hash algorithm (MD5) does not match.

Finally, Tokyo reports that no offers (transforms) were accepted and that phase 1 as a whole was not acceptable (highlighted lines 7 and 8).

So phase 1 was not acceptable, and Tokyo now begins to terminate aggressive mode negotiation accordingly as shown in Example 8-107.

Example 8-107. Tokyo Terminates Aggressive Mode Negotiation
*Mar 15 16:13:42.831 GMT: ISAKMP (0:1): incrementing error counter on sa:
  construct_fail_ag_init
*Mar 15 16:13:42.831 GMT: ISAKMP (0:1): Unknown Input: state = IKE_READY, major,
  minor = IKE_MESG_FROM_PEER, IKE_AM_EXCH
*Mar 15 16:13:42.831 GMT: %CRYPTO-6-IKMP_MODE_FAILURE: Processing of Aggressive mode
  failed with peer at 172.16.7.56
*Mar 15 16:13:47.811 GMT: ISAKMP (0:1): received packet from 172.16.7.56 dport 500
  sport 500 (R) AG_NO_STATE
*Mar 15 16:13:47.815 GMT: ISAKMP (0:1): phase 1 packet is a duplicate of a previous
  packet.
*Mar 15 16:13:47.815 GMT: ISAKMP (0:1): retransmitting due to retransmit phase 1
*Mar 15 16:13:47.815 GMT: ISAKMP (0:1): retransmitting phase 1 AG_NO_STATE...
*Mar 15 16:13:48.315 GMT: ISAKMP (0:1): retransmitting phase 1 AG_NO_STATE...
*Mar 15 16:13:48.315 GMT: ISAKMP (0:1): incrementing error counter on sa: retransmit
  phase 1
*Mar 15 16:13:48.315 GMT: ISAKMP (0:1): retransmitting phase 1 AG_NO_STATE
*Mar 15 16:13:48.315 GMT: ISAKMP (0:1): sending packet to 172.16.7.56 my_port 500
  peer_port 500 (R) AG_NO_STATE
Tokyo#

Tokyo reports that aggressive mode negotiation has failed with the remote access client (highlighted line 1). Then, in highlighted line 2, Tokyo sends a final (Notify) message to the remote client to inform it of phase 1 failure.

The key to finding out the reason for the failure is shown back in Example 8-105. As pointed out, the comparison of transforms 14 and 15 to policy 10 failed because the Diffie-Hellman group did not match. A likely culprit for IKE policy negotiation failure is the Diffie-Hellman group setting in policy 10 on Tokyo.

The IKE (ISAKMP) policy is then examined using the show crypto isakmp policy command, as shown in Example 8-108.

Example 8-108. Examination of the ISAKMP Policies on Tokyo
Tokyo#show crypto isakmp policy
Protection suite of priority 10
        encryption algorithm:   DES - Data Encryption Standard (56 bit keys).
        hash algorithm:         Message Digest 5
        authentication method:  Pre-Shared Key
        Diffie-Hellman group:   #1 (768 bit)
        lifetime:               86400 seconds, no volume limit
Default protection suite
        encryption algorithm:   DES - Data Encryption Standard (56 bit keys).
        hash algorithm:         Secure Hash Standard
        authentication method:  Rivest-Shamir-Adleman Signature
        Diffie-Hellman group:   #1 (768 bit)
        lifetime:               86400 seconds, no volume limit
Tokyo#

Highlighted lines 1 and 2 in Example 8-108 show that the Diffie-Hellman group in both policies is 1. Note also the authentication method in policy 10 is preshared keys.

Unfortunately, Diffie-Hellman group 1 with preshared keys is not supported at all by Cisco VPN Client 3.x. In fact, the only group supported with preshared key authentication is group 2.

The next step is to reconfigure the Diffie-Hellman group for policy 10, as shown in Example 8-109.

Example 8-109. Reconfiguration of the Diffie-Hellman Group
Tokyo#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Tokyo(config)#crypto isakmp policy 10
Tokyo(config-isakmp)#group 2
Tokyo(config-isakmp)#end
Tokyo#

Once the Diffie-Hellman group is reconfigured, the remote access client reconnects, and IKE negotiation completes successfully.

This is verified using the show crypto isakmp sa command, as demonstrated in Example 8-110.

Example 8-110. IKE Negotiation Has Completed Successfully
Tokyo#show crypto isakmp sa
dst              src             state           conn-id    slot
172.16.5.1       172.16.7.56     QM_IDLE               2       0
Tokyo#

Example 8-110 shows that IKE phase 1 has successfully negotiated, and the quick mode (phase 2) is in an idle state.

In Example 8-111, successful negotiation of IPSec SAs for the remote access client is verified using the show crypto ipsec sa command.

Example 8-111. Successful IPSec SA Negotiation
Tokyo#show crypto ipsec sa
interface: Serial4/0
    Crypto map tag: mjlnetMap, local addr. 172.16.5.1
   local  ident (addr/mask/prot/port): (172.16.5.1/255.255.255.255/0/0)
   remote ident (addr/mask/prot/port): (10.2.2.57/255.255.255.255/0/0)
   current_peer: 172.16.7.56:500
     PERMIT, flags={}
    #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 not decompressed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0
     local crypto endpt.: 172.16.5.1, remote crypto endpt.: 172.16.7.56
     path mtu 1500, media mtu 1500
     current outbound spi: 93F3666F
     inbound esp sas:
      spi: 0x4C20CF91(1277218705)
        transform: esp-des esp-md5-hmac ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 2000, flow_id: 1, crypto map: mjlnetMap
        sa timing: remaining key lifetime (k/sec): (4608000/3573)
        IV size: 8 bytes
        replay detection support: Y
     inbound ah sas:
     inbound pcp sas:
     outbound esp sas:
      spi: 0x93F3666F(2482202223)
        transform: esp-des esp-md5-hmac ,
        in use settings ={Tunnel, }
        slot: 0, conn id: 2001, flow_id: 2, crypto map: mjlnetMap
        sa timing: remaining key lifetime (k/sec): (4608000/3573)
        IV size: 8 bytes
        replay detection support: Y
     outbound ah sas:
     outbound pcp sas:
Tokyo#

Highlighted line 1 shows the remote identity. This is the IP address assigned to the remote access client from the IP address pool configured on Tokyo.

In highlighted line 2, you can see the local and remote tunnel endpoints. These are Tokyo (172.16.5.1) and the remote access client (172.16.7.56). Note that the IP address specified here for the client is the address that the client uses on the Internet.

Finally, in highlighted lines 3 and 4, the inbound and outbound ESP SAs negotiated with the client are shown.

NOTE

Note that when configuring the IKE policy and IPSec transform set on a router, you should always verify the parameters that the client supports.

IKE and IPSec parameters supported by Cisco VPN Client 3.x are shown in Tables 6-2 and 6-3 at the following URL:

http://www.cisco.com/en/US/products/sw/secursw/ps2308/products_administration_guide09186a00800bd991.html


Additional Troubleshooting Commands

This section contains some additional commands that may be useful when troubleshooting IPSec VPNs.

show crypto engine connections active

The show crypto engine connections active command (see Example 8-112) shows active IKE and IPSec SAs.

Example 8-112. Active IKE and IPSec SAs
Tokyo#show crypto engine connections active
  ID Interface        IP-Address      State  Algorithm           Encrypt  Decrypt
   3 <none>           <none>          set    HMAC_MD5+DES_56_CB        0        0
2000 Serial4/0        172.16.5.1      set    HMAC_MD5+DES_56_CB        0        5
2001 Serial4/0        172.16.5.1      set    HMAC_MD5+DES_56_CB       11        0
Tokyo#

Highlighted line 1 shows an IKE SA with connection ID 3. Note that the encrypt and decrypt counters both remain at zero.

Highlighted lines 2 and 3 show an inbound and an outbound IPSec SA associated with interface serial 4/0. Also shown is the IP address configured on the interface, as well as the hash and encryptions algorithms in use.

Note the encrypt and decrypt counters. You will notice that the decrypt counter in highlighted line 2 is a nonzero value. This is because highlighted line 2 shows an inbound IPSec SA. In highlighted line 3, the encrypt counter is a nonzero value. This is because highlighted line 3 shows an outbound IPSec SA.

As you can see, this command can be very useful for verifying that traffic is being sent and received over the IPSec tunnel.

show crypto key mypubkey rsa

The show crypto key mypubkey rsa command can be used to display the router's RSA public keys.

Example 8-113 shows the output of this command.

Example 8-113. show crypto key mypubkey rsa Command Output
Tokyo#show crypto key mypubkey rsa
% Key pair was generated at: 16:40:43 GMT Mar 17 2003
Key name: Tokyo.mjlnet.com
 Usage: General Purpose Key
 Key Data:
  30819F30 0D06092A 864886F7 0D010101 05000381 8D003081 89028181 00E3D7D5
  83D2063A 1725567C 7A9F9173 3001B06A C87208D7 9B990301 AC9A03D6 1FD87656
  903ED06F EBE17FD1 CF672EC7 391CDF3C A40247E4 8FC09102 02E09D98 2D097C5F
  DEA636BA 9B1DA643 6B765C71 57CE58DD 5DCACF8B E20ACF8C D10E478E F32C501D
  00412C0B 787CD246 3E886C06 351D4829 19076F7F 12669970 188ADDA5 21020301 0001
% Key pair was generated at: 18:40:50 GMT Mar 17 2003
Key name: Tokyo.mjlnet.com.server
 Usage: Encryption Key
 Key Data:
  307C300D 06092A86 4886F70D 01010105 00036B00 30680261 00D199FE 2DFE34C5
  E53DB392 96AF3FFD 50DE1DE7 0E913F9E 660C3031 95A31A44 24AD606B FFABFCD5
  240913CC B84183CF 9E8AF126 214C8E0A 1D1DA5C9 B6D317C2 50B8FDAB F7F258CD
  3FD9BCD5 2F5CF4C0 47C14E47 78CB0233 C302DFF1 64E532D6 9B020301 0001
Tokyo#

Highlighted line 1 shows the time when the keys were generated. Then in highlighted lines 2 and 3, the key name and usage are shown.

show crypto key pubkey-chain rsa

The show crypto key pubkey-chain rsa command shows peer RSA keys.

Example 8-114 shows the output of the show crypto key pubkey-chain rsa command.

Example 8-114. show crypto key pubkey-chain rsa Command Output
Tokyo#show crypto key pubkey-chain rsa
Codes: M - Manually configured, C - Extracted from certificate
Code Usage   IP-Address       Name
C    Signing                  X.500 DN name:
                              CN = mjlnetca
                               OU = mjlnet
                               O = MJL Network Services
                               L = London
                               ST = London
                               C = UK
                               EA = mark@mjlnet.com

Tokyo#

As you can see, this command shows the key, its usage, and the associated name.

show crypto ipsec dynamic-map

Use the show crypto ipsec dynamic-map command to display dynamic crypto map sets.

Example 8-115 shows the output of the show crypto ipsec dynamic-map command.

Example 8-115. show crypto ipsec dynamic-map Command Outpu
Tokyo#show crypto dynamic-map
Crypto Map Template"mjlnetDyn" 10
        No matching address list set.
        Security association lifetime: 4608000 kilobytes/3600 seconds
        PFS (Y/N): N
        Transform sets={
                mjlnetTrans,
        }
Tokyo#

show crypto ipsec security-association lifetime

The show crypto ipsec security-association lifetime command can be used to display the SA associated with crypto maps.

Example 8-116 shows the output of the show crypto ipsec security-association lifetime command.

Example 8-116. show crypto ipsec security-association lifetime Command Output
Tokyo#show crypto ipsec security-association-lifetime
Security association lifetime: 4608000 kilobytes/3600 seconds
Tokyo#

debug crypto ipsec

The debug crypto ipsec command is used to examine IPSec events.

Examples 8-117 and 8-118 show the output of the debug crypto ipsec command.

Example 8-117. debug crypto ipsec Command Output
Tokyo#debug crypto ipsec
Crypto IPSEC debugging is on
Tokyo#
Mar  8 22:50:00.147 GMT: IPSEC(sa_request): ,
  (key eng. msg.) src= 172.16.5.1, dest= 172.16.6.2,
    src_proxy= 10.1.1.0/255.255.255.0/0/0 (type=4),
    dest_proxy= 10.2.2.0/255.255.255.0/0/0 (type=4),
    protocol= ESP, transform= esp-des esp-md5-hmac ,
    lifedur= 3600s and 4608000kb,
    spi= 0xDE162122(3725992226), conn_id= 0, keysize= 0, flags= 0x4004
Mar  8 22:50:00.567 GMT: IPSEC(validate_proposal_request): proposal part #1,
  (key eng. msg.) dest= 172.16.6.2, src= 172.16.5.1,
    dest_proxy= 10.2.2.0/255.255.255.0/0/0 (type=4),
    src_proxy= 10.1.1.0/255.255.255.0/0/0 (type=4),
    protocol= ESP, transform= esp-des esp-md5-hmac ,
    lifedur= 0s and 0kb,
    spi= 0x0(0), conn_id= 0, keysize= 0, flags= 0x4
Mar  8 22:50:00.571 GMT: IPSEC(key_engine): got a queue event

In highlighted line 1, user traffic matching the crypto access list has caused router Tokyo to initiate IPSec SA setup to the peer router.

IPSec SAs are then negotiated via IKE quick mode, and in highlighted line 2, Tokyo validates an IPSec SA proposal. Example 8-118 shows a continuation of the debug.

Example 8-118. debug crypto ipsec Command Output (Continued from Example 8-117)
Mar  8 22:50:00.571 GMT: IPSEC(initialize_sas): ,
  (key eng. msg.) dest= 172.16.5.1, src= 172.16.6.2,
    dest_proxy= 10.1.1.0/255.255.255.0/0/0 (type=4),
    src_proxy= 10.2.2.0/255.255.255.0/0/0 (type=4),
    protocol= ESP, transform= esp-des esp-md5-hmac ,
    lifedur= 3600s and 4608000kb,
    spi= 0xDE162122(3725992226), conn_id= 2000, keysize= 0, flags= 0x4
Mar  8 22:50:00.571 GMT: IPSEC(initialize_sas): ,
  (key eng. msg.) src= 172.16.5.1, dest= 172.16.6.2,
    src_proxy= 10.1.1.0/255.255.255.0/0/0 (type=4),
    dest_proxy= 10.2.2.0/255.255.255.0/0/0 (type=4),
    protocol= ESP, transform= esp-des esp-md5-hmac ,
    lifedur= 3600s and 4608000kb,
    spi= 0xD28E6C84(3532549252), conn_id= 2001, keysize= 0, flags= 0x4
Mar  8 22:50:00.571 GMT: IPSEC(create_sa): sa created,
  (sa) sa_dest= 172.16.5.1, sa_prot= 50,
    sa_spi= 0xDE162122(3725992226),
    sa_trans= esp-des esp-md5-hmac , sa_conn_id= 2000
Mar  8 22:50:00.571 GMT: IPSEC(create_sa): sa created,
  (sa) sa_dest= 172.16.6.2, sa_prot= 50,
    sa_spi= 0xD28E6C84(3532549252),
    sa_trans= esp-des esp-md5-hmac , sa_conn_id= 2001
Tokyo#

In highlighted lines 1 and 2, inbound and outbound IPSec SAs are initialized in the security association database (SADB). Finally, in highlighted lines 3 and 4, the inbound and outbound SAs are created, and the IPSec tunnel is up.


show and debug Command Summary

Table 8-5 summarizes show and debug commands used to troubleshoot IPSec.

Table 8-5. IPSec Troubleshooting Commands: show and debug

Command

Parameter

Description

show crypto isakmp

key

Displays the preshared key associated with particular peers

policy

Displays the ISAKMP (IKE) policies configured on the router

sa

Displays established ISAKMP (IKE) SAs

show crypto map

[interface interface | tag map-name]

Displays specified crypto map

show crypto ipsec

sa

Displays IPSec SAs

transform-set

Displays IPSec transform sets

security-association lifetime

Displays the SA lifetime value configured for a particular crypto map entry

show crypto dynamic-map

Displays crypto map templates

show crypto identity

Displays configured crypto identities

show crypto engine

connections active

Displays IPSec connections, together with encrypted and decrypted packets

show crypto ca

certificates

Displays digital certificates

crls

Displays the CRL

show crypto key

mypubkey rsa

Displays router's public keys

pubkey-chain rsa

Displays peers' public keys

debug crypto isakmp

Displays IKE negotiation messages

debug crypto ipsec

Displays IPSec events

debug crypto pki

transactions

Displays PKI message exchange between the router and the CA


Review Questions

1: | What are the two modes that can be used during IKE phase 1 negotiation?
2: | What mode is used during IKE phase 2 negotiation?
3: | How many messages are exchanged during main mode negotiation?
4: | How many messages are exchanged during quick mode negotiation?
5: | Which messages are used for peer authentication during main mode negotiation?
6: | If an error occurs during IKE negotiation, what type of payload can be sent to inform the peer of the error?
7: | If main mode negotiation fails during the exchange of the first two messages, what is likely to be the issue?
8: | What are the three ways that one IPSec peer can authenticate another during IKE negotiation?
9: | How many messages are exchanged during IKE aggressive mode?
10: | How is aggressive mode negotiation supported on Cisco IOS routers?


Practice Labs

Three practice labs are provided here to help you consolidate and practice the skills learned in this chapter.

Figure 8-19 illustrates the topology used for the labs.

Figure 8-19. IPSec Lab Topology

[View full size image]

In each of the three labs, you must restore IP connectivity over the IPSec tunnel between the LANs at the Tokyo and Fukuoka sites.

To verify that you have restored IP connectivity over the IPSec tunnel, use extended ping (to ping from the LAN interface on Tokyo to the LAN interface on Fukuoka, and vice versa), and the show crypto engine connections active command to verify that the traffic is encrypted when it is transmitted between Tokyo and Fukuoka.

Base configurations for the labs can be found on the Cisco Press Web site (www.ciscopress.com/1587051044).

Detailed instructions for loading these base configurations onto your lab routers can be found in Appendix B.

Troubleshooting Lab 1

Q1:

In this scenario, network administrators at the Tokyo site report that when user traffic for the Fukuoka site arrives at the router from the local LAN, IKE negotiation is not initiated.

Troubleshoot this issue end-to-end, and record the symptoms, actions, and resolution in the space provided below:

Symptoms:

________________________________________________________________

________________________________________________________________

________________________________________________________________

________________________________________________________________

Actions:

________________________________________________________________

________________________________________________________________

________________________________________________________________

________________________________________________________________

Resolution:

________________________________________________________________

________________________________________________________________

________________________________________________________________

________________________________________________________________

Troubleshooting Lab 2

Q1:

In this scenario, network administrators report that IKE negotiation begins between Tokyo and Fukuoka, but that it soon fails.

Troubleshoot this issue end-to-end, and record the symptoms, actions, and resolution in the space provided below:

Symptoms:

________________________________________________________________

________________________________________________________________

________________________________________________________________

________________________________________________________________

Actions:

________________________________________________________________

________________________________________________________________

________________________________________________________________

________________________________________________________________

Resolution:

________________________________________________________________

________________________________________________________________

________________________________________________________________

________________________________________________________________

Troubleshooting Lab 3

Q1:

Network administrators are now complaining that, although IPSec tunnel setup is successful, user traffic is not successfully transmitted over the tunnel between Tokyo and Fukuoka.

Troubleshoot this issue end-to-end, and record the symptoms, actions, and resolution in the space provided below:

Symptoms:

________________________________________________________________

________________________________________________________________

________________________________________________________________

________________________________________________________________

Actions:

________________________________________________________________

________________________________________________________________

________________________________________________________________

________________________________________________________________

Resolution:

________________________________________________________________

________________________________________________________________

________________________________________________________________

________________________________________________________________


Appendix A. 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


Chapter 2 Review Questions & Answers

1: | Which L2F message type is the first sent when a NAS is establishing a L2F tunnel to the Home Gateway?
A1: | Answer: The L2F_CONF.
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 configured to authenticate the NAS.
A2: | Answer: The NAS sends a CHAP Challenge message, and the client replies with a CHAP Response message.
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.
A3: | Answer: The Home Gateway sends the client a CHAP Success or Failure message.
4: | By default, how is LCP negotiated between the remote access client and the Home Gateway?
A4: | Answer: By default, LCP is not negotiated between the client and the Home Gateway. Instead, LCP is negotiated between the client and the NAS, and the NAS passes these parameters to the Home Gateway during session setup.
5: | Which parts of the PPP frame are NOT carried when the frame is forwarded by the NAS to the Home Gateway?
A5: | Answer: Flags, transparency data (ACCM or bit-stuffing), and the CRC.
6: | How is a tunnel termination reason indicated within the L2F_CLOSE message?
A6: | Answer: Using the L2F_CLOSE_WHY and L2F_CLOSE_STR suboptions.
7: | What does the error message %VPDN-6-SOFTSHUT: mean? How can this issue be resolved?
A7: | Answer: This indicates that the vpdn softshut command is configured on the NAS/Home Gateway. To resolve this issue, remove this command.
8: | What are the MID and the CLID?
A8: | Answer: The MID is the Multiplex ID, and it uniquely identifies a session within the L2F tunnel. The CLID is the Client ID, and it uniquely identifies the L2F tunnel.
9: | What is the significance of MID 0?
A9: | Answer: MID 0 identifies tunnel management packets (L2F_PROTO).
10: | How is the L2F tunnel maintained in the absence of client traffic?
A10: | Answer: The L2F_ECHO and L2F_ECHO_RESP message types provide a keepalive mechanism that can be used to maintain the tunnel.


Chapter 3 Review Questions & Answers

1: | What is the initial message used in PPTP tunnel negotiation?
A1: | Answer: The initial message is the Start-Control-Connection-Request (SCCRQ).
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?
A2: | Answer: Lack of basic IP connectivity, an access-list blocking TCP port 1723.
3: | How is the tunnel session established between the remote access client/PNS and the PAC?
A3: | Answer: The remote access client/PNS sends a OCRQ, and the PAC replies with an OCRP.
4: | How are data tunnel packets transmitted between the remote access client/PNS and the PAC?
A4: | Answer: Data tunnel packets are transmitted using Enhanced GRE.
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?
A5: | Answer: MPPE requires MS-CHAP authentication.
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?
A6: | Answer: This message indicates that the PAC has rejected configuration of the CCP, including MS-PPC and MPPE.
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.
A7: | Answer: This indicates that the IP address pool has been incorrectly configured or that there are no addresses left to allocate.
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?
A8: | Answer: The PAC first sends a CDN to the remote access client/PNS. This is immediately followed by a Stop-Control-Connection-Request (StopCCRQ). The remote access client/PNS replies with a Stop-Control-Connection-Reply, and the tunnel is down.
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?
A9: | Answer: The remote access client/PNS most likely has a split tunnel issue. This means that the default route on the remote access client/PNS is causing Internet-bound packets to be sent via the PPTP tunnel to the PAC, rather than directly to the ISP.
10: | A remote access client/PNS user wishes to configure Multilink PPP on the PPTP tunnel to the PAC. How can this be supported on the PAC?
A10: | Answer: Multilink PPP is not supported on PPTP tunnels with Cisco routers.


Chapter 4 Review Questions & Answers

1:

What is the purpose of the Start-Control-Connection-Request (SCCRQ) message?

A1:

Answer: It is used to initiate the L2TP control connection between the LAC and the LNS.

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?

A2:

Answer: The sequence of messages used to set up a data session is Incoming-Call-Request (ICRQ), Incoming-Call-Reply (ICRP), and Incoming-Call-Connected (ICCN).

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.

A3:

Answer: The sequence of messages used to set up an outgoing call is Outgoing-Call-Request (OCRQ), Outgoing-Call-Reply (OCRP), and Outgoing-Call-Connected (OCCN).

4:

During session setup, the LNS wishes to signal the LAC that there are insufficient resources and that the session should be disconnected. Which message is used to signal this?

A4:

Answer: The LNS signals the LAC that there are insufficient resources to complete session setup using the CDN message.

5:

How can the number of L2TP sessions be limited?

A5:

Answer: The number of sessions can be limited using the vpdn session-limit command.

6:

How are remote access client PPP connections associated with a particular L2TP tunnel by the LAC?

A6:

Answer: The LAC associates PPP connections with a particular L2TP tunnel using either the remote access client's domain name, DNIS string, or complete user name (per-user VPDN).

7:

Should the network administrator not wish to store tunnel configuration on the LAC, what is an alternative?

A7:

Answer: Tunnel configuration (definitions) can be stored on a AAA server.

8:

What is the significance of the tunnel ID in the tunnel definitions on an AAA server?

A8:

Answer: The tunnel ID corresponds to the hostname of the LAC.

9:

You suspect that the remote access client's password is incorrectly configured, and this is causing L2TP session establishment failure. Where and with what command which you troubleshoot this issue? Assume local authentication is being used.

A9:

Answer: The remote access client is only partially authenticated on the LAC, so this issue would have to be dealt with on the LNS. The command to use would be debug ppp negotiation or, alternatively, debug ppp authentication.

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.

A10:

Answer: This most likely indicates that no IP address is configured on the virtual template.


Chapter 5 Review Questions & Answers

1: | What is the function of the control connection?
A1: | Answer: The control connection provides a mechanism to authenticate a peer, and dynamically establish, maintain, and tear down data sessions.
2: | Is a control connection required? Why or why not?
A2: | Answer: A control connection is not required if L2TPv3 sessions are statically configured.
3: | What is the function of the session ID and the cookie?
A3: | Answer: The session ID is used to associate data (session) messages with attachment circuits. The cookie provides additional assurance that data messages are associated with the correct attachment circuit, as well as protecting against blind insertion attacks.
4: | For what are the Message Digest and Control Message Authentication Nonce AVPs used?
A4: | Answer: These AVPs are carried in control connection messages and are used to support peer authentication. The Message Digest AVP is also used to ensure message integrity.
5: | What three messages are exchanged in order to establish a control connection?
A5: | Answer: Start-Control-Connection-Request (SCCRQ), Start-Control-Connection-Reply (SCCRP), and Start-Control-Connection-Connected (SCCCN).
6: | What three messages are exchanged in order to establish a session?
A6: | Answer: Incoming-Call-Request (ICRQ), Incoming-Call-Reply (ICRP), Incoming-Call-Connected (ICCN).
7: | If an LCCE wants to tear down a control connection, what message does it send?
A7: | Answer: It sends a Stop-Control-Connection-Notification (StopCCN) message.
8: | If an LCCE wants to tear down a session, what message does it send?
A8: | Answer: It sends a Call-Disconnect-Notify (CDN) message.
9: | What message does an LCCE send to its peer to signal that attachment circuit status has changed from active to inactive (or vice-versa)?
A9: | Answer: It sends a Set-Link-Info (SLI) message.
10: | What is the major difference between L2TPv2 and L2TPv3 with regard to supported Layer 2 payloads?
A10: | Answer: L2TPv2 only supports the tunneling of PPP frames, whereas L2TPv3 provides a generic framework for tunneling Layer 2 frames.


Chapter 6 Review Questions & Answers

1:

What transport mechanism is used for neighbor discovery between directly connected LDP peers?

A1:

Answer: The all routers multicast address (UDP 224.0.0.2) is used.

2:

What is the LIB?

A2:

Answer: The Label Information Base (LIB) contains all bindings. This includes all local label bindings and all label bindings received from peer LSRs (assuming liberal label retention).

3:

What is the LFIB?

A3:

Answer: The LFIB is the Label Forwarding Information Base. The LFIB stores only those label bindings used for forwarding.

4:

What is a VRF?

A4:

Answer: A VPN Routing and Forwarding instance.

5:

How are overlapping customer address spaces disambiguated in the MPLS VPN backbone?

A5:

Answer: A Route Distinguisher (RD) is used to disambiguate IP address space.

6:

Which BGP extended community is used to control which VPN routes are imported into VRFs?

A6:

Answer: The Route Target (RT) extended community.

7:

Which routing protocols can be used between Cisco CE and PE routers?

A7:

Answer: Currently RIPv2, EIGRP, OSPF, and EBGP. Note that static routes can also be used.

8:

What label distribution protocol is used to advertise VPN labels?

A8:

Answer: VPN labels are advertised by MP-BGP.

9:

What label distribution protocol is used with MPLS traffic engineering on Cisco routers?

A9:

Answer: RSVP.

10:

What are the default and data MDTs?

A10:

Answer: The default Multicast Distribution Tree (MDT) is used to distribute customer multicast traffic and control packets to all PE routers in the MVPN.

The data MDT can be used to distribute high-rate multicast traffic to only those PE routers connected to sites with receivers.


Chapter 7 Review Questions & Answers

1: | What is the innermost label in the label stack of a packet sent over an AToM pseudowire?
A1: | Answer: The innermost label in the label stack is the VC label. This label is used by the egress PE router to associate the Layer 2 PDU carried in the packet with the correct attachment circuit.
2: | How do the peer PE routers discover each other?
A2: | Answer: They use extended (unicast UDP port 646) LDP discovery.
3: | How do the peer PE routers advertise VC labels to each other?
A3: | Answer: They form an LDP neighbor relationship and exchange label mapping messages.
4: | If an attachment circuit changes state to down, how does the PE router indicate this state change to its peer PE router?
A4: | Answer: It sends an LDP label withdraw message.
5: | How do LDP LSRs with directly connected interfaces discover each other?
A5: | Answer: They use UDP port 646 and the all routers multicast address (224.0.0.2).
6: | How do LSRs with directly connected interfaces establish an LDP session?
A6: | Answer: They use TCP unicast communication (port 646) between LDP ID (transport) addresses.
7: | Assuming that the PE routers are not in a back-to-back configuration (or directly connected via a GRE or L2TP tunnel), what is the minimum number of labels required to transport Layer 2 PDUs across an MPLS network between ingress and egress PE routers?
A7: | Answer: The minimum number of labels is two (tunnel and VC labels).
8: | How many LSPs are required to establish a single AToM pseudowire between peer PE routers?
A8: | Answer: Two LSPs are required (LSPs are unidirectional).
9: | What is a likely cause if labels are not locally assigned to prefixes?
A9: | Answer: A likely cause is that CEF is disabled.
10: | Assuming an LDP signaled tunnel LSP, to what prefix does the tunnel (IGP) label correspond?
A10: | Answer: It corresponds to the egress PE router's LDP ID address.


Chapter 8 Review Questions & Answers

1: | What are the two modes that can be used during IKE phase 1 negotiation?
A1: | Answer: Main mode and aggressive mode.
2: | What mode is used during IKE phase 2 negotiation?
A2: | Answer: Quick mode.
3: | How many messages are exchanged during main mode negotiation?
A3: | Answer: Six messages are exchanged.
4: | How many messages are exchanged during quick mode negotiation?
A4: | Answer: Three messages are exchanged.
5: | Which messages are used for peer authentication during main mode negotiation?
A5: | Answer: Messages five and six.
6: | If an error occurs during IKE negotiation, what type of payload can be sent to inform the peer of the error?
A6: | Answer: A Notify payload.
7: | If main mode negotiation fails during the exchange of the first two messages, what is likely to be the issue?
A7: | Answer: An IKE policy proposal has been rejected.
8: | What are the three ways that one IPSec peer can authenticate another during IKE negotiation?
A8: | Answer: Preshared keys, RSA signatures, and RSA encrypted nonces.
9: | How many messages are exchanged during IKE aggressive mode?
A9: | Answer: Three messages.
10: | How is aggressive mode negotiation supported on Cisco IOS routers?
A10: | Answer: Before Cisco IOS Software Release 12.2(8)T, Cisco IOS routers supported aggressive mode negotiation in the role of a responder only. In Cisco IOS 12.2(8)T, the capability to initiate aggressive mode negotiation was added. Note, however, that the default mode when initiating IKE phase negotiation remains main mode.


Appendix B. Lab Instructions and Solutions

This appendix contains instructions for loading the configuration files found on the Cisco Press Web site (www.ciscopress.com/1587051044) onto lab routers and provides lab solutions.


Setting Up Your Routers and Loading the Configuration Files

There are two steps that you must complete before you can begin each lab:

Step 1. | Cable your routers.
Step 2. | Load the configuration files found on the Cisco Press Web site (www.ciscopress.com/1587051044) onto your routers.

Router Platforms and Cabling

All the labs were tested on Cisco 2611 routers loaded with Cisco IOS Software Release 12.2(16a) Enterprise Plus IPSec 56.

To do these labs, you will need five routers with a mix of ISDN Basic Rate Interface (BRI), Fast Ethernet and serial interfaces (see lab diagrams), as well as an IOS image that supports VPDNs for L2F and L2TPv2, MPLS (and, optionally, MPLS traceroute), and IPSec.

The quickest way to find an IOS image that supports these features is to use the Cisco Feature Navigator at the following URL (CCO account required):

http://tools.cisco.com/ITDIT/CFN/jsp/index.jsp

Note that a 2600 minimum platform is required for MPLS.

For the L2F and L2TPv2 troubleshooting labs, you will also need a two-port ISDN simulator.

Follow the lab diagrams when cabling the your routers. Use back-to-back serial or cross-over Ethernet connections between routers, as appropriate.

Loading Configuration Files onto Your Lab Routers

If your lab routers have interface configurations different from those specified in the configuration files on the book's Web site, you will need to modify the interface numbering (and one or two other commands) before loading them on your routers. Again, check the lab diagrams, and compare the interface numbering carefully with your own routers.

Once you have cabled your routers, the next step is to navigate to the directory that contains configuration files for the lab that you are doing. This should be pretty easyfor example, the configuration files for L2TPv2 Troubleshooting Lab 1 are contained in the L2TPv2/Lab1 directory, and the configuration files for IPSec Troubleshooting Lab 2 are contained in the IPSec/Lab2 directory.

Now that you have found the correct directory, you can begin loading the configuration files onto your lab routers.

To load the configuration files on your routers, follow these instructions:

1. | Erase any existing configuration on your lab routers.
2. | Open each configuration file in a text editor, and if necessary (see lab diagrams) modify the interface numbering so that it conforms to the routers on which you will be loading the configuration files.

For example, in L2F Troubleshooting Lab 1, router DELAND_RTR has two serial interfaces numbered serial 0/0 and serial 1/0 (see lab diagram). If you are using a 2501 router for DELAND_RTR, however, you will need to modify the interface numbering in the DELAND_RTR.txt configuration file, as shown in Figure B-1.

Figure B-1. Modifying Interface Numbering

As you can see, the numbering for the serial interfaces has been modified so that it conforms to 2501 router interface numbering (serial 0 and serial 1, as opposed to serial 0/0 and serial 0/1).

Before doing L2F and L2TPv2 Troubleshooting Labs 1, 2, and 3, you may also need to modify the isdn switch-type and dialer string commands on routers TATEBAYASHI@mjlnet.com and joebloggs@mjlnet.com. You might also need to add ISDN SPIDs using the isdn spid1 spid-number ldn [ldn] [ldn] and isdn spid2 spid-number ldn [ldn] [ldn] commands if required by your ISDN simulator. Note that you may also need to modify the isdn switch-type command on LODI_NAS1 and CalCity_LAC.

The ISDN switch type specified on TATEBAYASHI@mjlnet.com and joebloggs@mjlnetcom using the isdn switch-type command is basic-net 3 (on the BRI). Modify this if appropriate. Again, you may also have to add ISDN SPIDs, if required by your ISDN simulator.

The dialer string command on interface Dialer1 on TATEBAYASHI@mjlnet.com and joebloggs@mjlnet.com in the configuration files specifies 2222 as the number to dial for LODI_NAS1 and CalCity_LAC (in the L2F and L2TPv2 labs, respectively). Make sure you modify this number as appropriate.

Figure B-2 illustrates these modifications.

Figure B-2. Modify the isdn switch-type and dialer string Commands if Appropriate

In Figure B-2, the ISDN switch type on interface BRI0/0 has been modified to be basic-ni (National), and the dialer string command on interface Dialer1 now specifies 1234 as the number to dial for LODI_NAS1.

The ISDN switch type specified on LODI_NAS1 and CalCity_LAC in the configuration files is also basic-net3 (on interface BRI0/0). Be sure to modify this if appropriate.

If you are in a hurry to get started, however, just modify the interface numbering as appropriate. You can make modification of ISDN switch types, dialer strings, and so on part of the lab exercises themselves.

Once you have made any necessary modifications to the configuration files, select all and copy and paste them to the Router(config)# prompt on your lab routers. This is shown in Figures B-3 and B-4.

Figure B-3. Select All

[View full size image]

When you have loaded all the configuration files on your lab routers, you are ready to start.

As a final thought: the purpose of the troubleshooting labs is to improve your VPN troubleshooting skills, and help you develop your understanding of relevant show and debug commands. So, try to use the VPN show and debug commands as you do the labs, and try to avoid using the show running-config command as much as possible.

Note that the console, Telnet, and enable password on all routers in all labs is mjlnet.

Figure B-4. Copy and Paste the Configuration Files to Your Lab Routers

[View full size image]


Chapter 2: L2F Troubleshooting Lab Solutions

This section provides solutions for L2F Troubleshooting Labs 1, 2, and 3. Note that the directory L2F/LabSolution directory contains working configuration files for all routers for your reference.

Troubleshooting Lab 1 Solution

A1:

In Troubleshooting Lab 1, the domain is incorrectly specified under the VPDN group (vpdn-group 1). It should be mjlnet.com and not mjl.com. Make sure that you remove the mjl.com domain (no domain mjl.com), before adding the mjlnet.com domain (domain mjlnet.com). For more details on troubleshooting this issue, see the section entitled "Partial PPP Authentication Fails on the NAS" on page 64.

Troubleshooting Lab 2 Solution

A1:

The IP address of the PERRIS_HGW1 is incorrectly specified on LODI_NAS1 (initiate-to ip 172.16.2.3) under the VPDN-group (vpdn-group 1). It should be 172.16.2.2.

Ensure that you remove the incorrect IP address (no initiate-to ip 172.16.2.3) before adding the correct IP address (initiate-to ip 172.16.2.2). More details on troubleshooting this issue can be found in the section entitled "Troubleshooting L2F Tunnel Establishment" on page 69.

Additionally, one of the tunnel passwords is mismatched between LODI_NAS1 and PERRIS_HGW1 (username username password password). See the section entitled "Tunnel Authentication Failure" on page 74 for more information on troubleshooting this issue.

Troubleshooting Lab 3 Solution

A1:

The vpdn softshut command is configured on PERRIS_HGW1. This should be removed to allow new L2F sessions to be established (no vpdn softshut). See the section entitled "Troubleshooting L2F Session Establishment" on page 80 for more details on troubleshooting this issue.

Also, there is no IP address configured on interface Virtual-Template1 on PERRIS_HGW1. Configure an IP address on this interface (ip unnumbered interface_name) to resolve this issue. The section entitled "NCP Negotiation Failure" on page 91 has more information on this issue.


Chapter 4: L2TPv2 Troubleshooting Lab Solutions

This section contains solutions for L2TPv2 Troubleshooting Labs 1, 2, and 3. Note that the directory L2TPv2/LabSolution directory contains working configuration files for all routers for your reference.

Troubleshooting Lab 1 Solution

A1:

There is a PPP authentication protocol mismatch between the remote client (TATEBAYASHI@mjlnet.com) and CalCity_LAC. TATEBAYASHI@mjlnet.com is configured to use CHAP, and LODI_NAS1 is configured to use PAP.

Reconfigure the PPP authentication protocol to be CHAP on LODI_NAS1 by using the ppp authentication chap command (on interface BRI number). See the section entitled "LCP Negotiation Between the Remote Access Client and the LAC" on page 266 for more information on troubleshooting this issue.

Troubleshooting Lab 2 Solution

A1:

There is a tunnel protocol mismatch between CalCity_LAC and Skydance_LNS. Skydance_LNS is configured to use L2F under vpdn-group 1. Reconfigure the tunnel protocol to be L2TP on Skydance_LNS using the protocol l2tp command under vpdn-group 1. See the "VPDN Protocol Mismatch" section on page 281 for details about troubleshooting this issue.

Also configure the terminate-from hostname CalCity_LAC command, as well as an L2TP tunnel password, on Skydance_LNS using the l2tp tunnel password password (in this case, the password is cisco).

Troubleshooting Lab 3 Solution

A1:

In Troubleshooting Lab 3, there is an access list configured on Intermediate1 that is blocking L2TP (UDP port 1701). Remove the access list to resolve this issue.

There is also an authentication failure for joebloggs@mjlnet.com on Skydance_LNS (the username jobloggs@mjlnet.com password password command should specify the password cisco). See the section entitled "LCP Negotiation or PPP Authentication Failure on the LNS" on page 299 for more details on troubleshooting this issue.


Chapter 6: MPLS Layer 3 VPN Troubleshooting Lab Solutions

This section contains solutions for MPLS Layer 3 VPN Troubleshooting Labs 1, 2, and 3. Note that the directory MPLSL3VPN/LabSolution directory contains working configuration files for all routers for your reference.

Troubleshooting Lab 1 Solution

A1:

RIP is used as the PE-CE routing protocol between mjlnet_CE1 and Chengdu_PE, but RIP parameters are configured globally, and not under an address family (address-family ipv4 vrf mjlnet_VPN). Reconfigure RIP parameters under the address family on Chengdu_PE. More information about troubleshooting this issue can be found in the section entitled "Routing Protocol Is Configured Globally" on page 516.

Troubleshooting Lab 2 Solution

A1:

CEF is disabled on Guangzhou_P. Enable CEF on Guangzhou_P using the ip cef global configuration command. See the section entitled "Verifying CEF" on page 481 for more details on troubleshooting this issue.

Additionally, redistribution of RIP (the PE-CE routing protocol) into MP-BGP is not configured on HongKong_PE. Enter the redistribute rip command under the address family (address-family ipv4 vrf mjlnet_VPN) in router bgp 64512. More information about troubleshooting this issue can be found in the section entitled "Redistribution of Customer Routes into MP-BGP Is Not Successful on the Egress PE Router" on page 518.

Troubleshooting Lab 3 Solution

A1:

MPLS is disabled on the interface serial 0/0 on Guangzhou_P (connected to Chengdu_P). MPLS should be enabled on this interface using the mpls ip command. More information on troubleshooting this issue can be found in the section entitled "MPLS Is Disabled on an Interface" on page 485.

Conditional label advertisement is also configured on Chengdu_PE. This is blocking the advertisement of a label binding for prefix 10.1.1.1. In this example, conditional label advertisement can be removed using the no tag-switching advertise-tags for 1 command. See the section entitled "Conditional Label Advertisement Blocks Label Bindings" on page 506. for more details on troubleshooting this issue.


Chapter 8: IPSec Troubleshooting Lab Solutions

This section contains solutions for IPSec Troubleshooting Labs 1, 2, and 3. Note that the directory IPSec/LabSolution directory working configurations for all routers for your reference.

Troubleshooting Lab 1 Solution

A1:

In Troubleshooting Lab 1, the crypto map mjlnetmap is not applied to the serial 0/0 interface on Tokyo. Apply the crypto map to the interface using the crypto map mjlnetmap command. For more details on troubleshooting this issue, see the section entitled "IKE Negotiation Is Not Initiated" on page 696.

Additionally, there is an access list configured on Osaka that is blocking ISAKMP. This access list should be removed. The section entitled "ISAKMP Is Blocked by an Access List or Firewall" on page 705 contains more information on troubleshooting this issue.

Troubleshooting Lab 2 Solution

A1:

The IKE (ISAKMP) policy is mismatched between Tokyo and Fukuoka. Modify the IKE (ISAKMP) policy on either Fukuoka or Tokyo so that the policies are no longer mismatched. More details about troubleshooting this issue can be found in the section entitled "IKE Policy Mismatch Exists" on page 709.

There is also a mismatch between the IPSec transform sets configured on Tokyo and Fukuoka. Reconfigure the transform set on either Fukuoka or Tokyo so that there is no longer a mismatch. See the section entitled "IPSec Transform Set Mismatch Exists Between Peers" on page 723 for more information about troubleshooting this issue.

Troubleshooting Lab 3 Solution

A1:

There is an access list configured on Tokyo that is blocking ESP. Remove this access list.

Additionally, there is an access list configured on Fukuoka that is blocking traffic from the Tokyo LAN (10.1.1.0/24). Remove this access list.

More information on troubleshooting both of these issues can also be found in the section entitled "Access List or Firewall Is Blocking AH or ESP" on page 733.


Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [Z]


SYMBOL

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [Z]

% VPDN-3-NORESOURCE error message
% VPDN-4-MIDERROR error Message
% VPDN-4-REFUSED error message
% VPDN-5-NOIDB error message
% VPDN-5-UNREACH error message
% VPDN-6-CLOSED error message
% VPDN-6-DOWN error message
% VPDN-6-MAX_SESS_EXCD Error Message
% VPDN-6-RESIZE error message
% VPDN-6-SOFTSHUT error message
% VPDN-6-TIMEOUT error message
%VPDN-6-AUTHENERR error message
%VPDN-6-AUTHENFAIL error message
%VPDN-6-AUTHORERR error message
%VPDN-6-AUTHORFAIL error message
(crl) query command
commands
(crl) query
(ISAKMP (Internet Security Association and Key Management Protocol)
_VV1026M 2nd
_VV326M
_VV622M


A

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [Z]

AAA
configuring
configuration:AAA
remote
configuring;remote AAA:conifguring;configuration:remote AAA
aaa new-model command
commands
aaa new-model
aaa new-model;enabling:AAA
AAL5 over MPLS configuration
enncapsulation
AAL5 over MPLS;MPLS:AAL5 over configuration;encapsulation:AAL5
access lists
AH
troubleshooting;AH:access lists:troubleshooting;ESP:access lists:troubleshooting;access list:ESP:troubleshooting;firewalls:AH/ESP:troublehsooting
deleting
deleting:access lists
L2TPv3
blocking of;blocking L2TPv3, troubleshooting access lists
LDP
blocking;LDP:access lists:blocking;blocking access lists:LDP;sessions:LDP:blocking access lists
acecss lists
modifying
modification:access lists
active lines
verifying
verification:active lines;LCP:negotiation;negotiation:LCP;remote access linets:LCP negotiation;clients:remote access:LCP negotiation;negotiation:LCP
adding
preshared keys
preshared keys:adding
additive keyword
keywords
additive
Address & Control Field Compression (ACFC)
ACFC (Address & Control Field Compression)
Address and Control Field Compression (ACFC)
ACFC (Address and Control Field Compression)
compression:ACFC
Administrator subfields
Advanced Encryption Standard (AES)
AES (Advanced Encryption Standard)
advertisements
label bindings
labels:bindings:advertisements;binding:labels:advertisements
aggressive mode negotation
negotiation
aggressive mode;modes:aggressive negotiation;preshared key authentication:aggressive mode negotiation;authentication:afggressive mode negotiation
aggressive mode negotiation
RSA signature authentication
RSA signature authentication:aggressive mode negotiation;digital certificates;certificates:digital;authentication:aggressive mode:RSA signature authentication
any keyword
keywords
any
Any Transport over MPLS
Layer 2
AToM [See AToM, AToM;PDUs (protocol data units):AToM. See also AToM;networks:MPLS:AToM. See also AToM]
architecture
IPSec
tunneling:IPSec [See also IPSec, IPSec;traffic:IPSec. See also IPSec]
Layer 3 MPLS VPNs
Assigned Number subfields
Assigned Tunnel ID AVP
asymmetric payload types, L2TPv3
payloads
asymmetric L2TPv3 types;L2TPv3:asymmetric payload types
Asynchronous Control Character Map (ACCM)
ACCM (Asynchronous Control Character Map)
maps:ACCM
asynchronous interfaces
L2TP
configuration:asynchronous interfaces:L2TP;interfaces:asynchronous:L2TP
asynchronous lines
L2TP
configuring;configuration:asynchronous lines:L2TP;parameters:asynchronous lines:configuring
ATM
cell relay
cell relay:ATM
cell relay control words
Ethernets:control words;HDLC:control words;PPP:control words
VP cell relay
cells:ATM:VP relay;VP:ATM cell relay
AToM
CEF
configuration:AToM:CEF;PE:AToM:CEF;routers:AToM:CEF;CEF:AToM:enabling;enabling:CEF:AToM
commands
commands:AToM;troubleshooting:ATom:troubleshooting 2nd 3rd
configuring
configuration:AToM;PE:AToM:configuring;routers:AToM:configuring 2nd
Layer 2 PDU transport
transports:AToM Layer 2 PDU;attachment circuits:AToM Layer 2 PDU transports 2nd
LDP
Router ID;configuration:AToM:LDP Router ID;PE:AToM:LDP Router ID;routers:AToM:LDP ROUTER ID;LDP:AToM:Router ID
specifying;configuration:AToM:specifying LDP;PE:AToM:specifying LDP;routers:AToM:specifying LDP;LDP:AToM:specifying;specifying:LDP:AToM
loopback interfaces
conifguring;configuration:AToM:loopbakc interfaces;PE:AToM:loopback interfaces;routers:AToM:loopback interfaces;loopback interfaces:AToM;LDP:AToM:loopback interfaces
MPLS backbone IGPs
configuration:AToM:MPLS backbone IGPs;PE:AToM:MPLS backbone IGPs;routers:AToM:MPLS backbone IGPs;MPLS:backbone IGPs;IGPs:MPLS backbones;backbones:MPLS:IGPs 2nd
MPLS core interfaces
configuration:AToM:MPLS core interfaces;PE:AToM:MPLS core interfaces;routers:AToM:MPLS core interfaces;MPLS:core interfaces;core interfaces:MPLS;interfaces:core:MPLS 2nd
MTU issues
MTU:AToM
pseudowires
configuration:AToM:pseudowires;PE:AToM:pseudowires;routers:AToM:pseudowires;pseudowires:AToM;attachment circuits:AToM:pseudowires;encapsulation:AToM:pseudowires 2nd
sample configurations
configuration:AToM:sample conifgurations;PE:AToM:sample configurations;routers:AToM:sample configurations;sample configurations:AToM 2nd
techical overview of
troubleshooting
configuration:AToM:troubleshooting;PE:AToM:troubleshooting;routers:AToM:troubleshooting;troubleshooting:AToM 2nd
VC label exchanges
configuration:AToM:VC label exchanges;PE:AToM:VC label exchanges;routers:AToM:VC label exchanges;troubleshooting:AToM:VC label exchanges;VC:label exchanges;labels:VC exchanges;exchanges:VC labels 2nd
VC:labels:exchanges;labels:VC:exchanges;exchanges:VC labels;PE:VC label exchanges;routers:VC label exchanges;LDP:VC label exchanges;sessions:LDP:VC label exchanges;discovery:LDP:VC label exchanges 2nd
AToM (Any Transport over MPLS)
attachment circuits
configuring
configuration:attachment circuits;circuits:attachment:configuring
attribute-value-pairs
AVPs (attribute-value-pairs) [See AVPs]
attributes
RT
authentication
AVPs
AVPs:authentication;proxy LCP AVPs;LCP:proxy AVPs
IKE
troubleshooting;IKE;authentication:troubleshooting;troubleshooting:IKE;authentication;preshared keys:authentication:troublehsooting
L2TPv3
troubleshooting
authentication AVPs
Authentication Header (AH)
AH (Authentication Header)
packets:AH;headers:AH 2nd
authentication protocol (AuthProto)
authentication, authorization, and accounting (AAA)
L2F tunnel establishment
AAA (authentication, authorization, and accounting):L2F tunnel establishment
autonomous system (AS) numbers
AS (autonomous system) numbers
AVPs
call management
call status
control connection management
hiding
hiding:AVPs
L2TP
encoding formats;L2TP:AVPs [See also AVPs;encoding:AVPs]
L2TPv3 2nd
Result Code


B

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [Z]

backbones
IGP
conifguring;IGP:backbones:configuring;configuration:backbones:IGP
troubleshooting;IGP:backbones:troubleshooting;troubleshooting:IGP backbones 2nd
MPLS [See also AToM, MPLS]
VPNs
traffic:VPNs [See also VPNs, ]
basic discovery, LDP
extended discovery, LDP
bindings
VC label exchanges
bits per second (bps)
bps (bits per second)


C

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [Z]

C (Command / Response) bit
cal setup
verifying
verification:call setup;debug isdn q931 command;commands:debug isdn q931
call management AVPs
call reception
verifying
verification:call reception;modems:call reception:verifying
call sessions [See also sessions]
call status AVPs
Call-Disconnect-Notify (CDN) message
CDN (Call-Disconnect-Notify) message
messages:CDN
messages
CDN
carrier's carrier topologies
topologies
carrier's carrier
CAs
authentication
authentication:CAs
declaring
declarations:CAs
enrollment
troubleshooting;enrollment:CAs:troubleshooting;authentication:CAs:troubleshooting;troubleshooting:CAs
case studies
L2F
tunnel failures from offload servers;L2F:tunnling:failures from offload servers;offload servers:L2F tunnel failures;servers:offload:L2F tunnel failures;Home Gateways:L2F:tunnel failures from offload servers 2nd
remote AAA
remote AAA:case study;AAA:remote:case study;configuration:remote AAA:case study 2nd
CCP
negotiation
negotiation:CCP
CDN messages
CE routers
configuring
routers:CE:conifguring;configuration:CE routes
MVPNs
routers:CE:MVPNs;PIM:CE routers:MVPNs;MVPNs:CE routers;configuring
CEF
AToM
troubleshooting;verification:CEF:AToM
disabling
disabling:CEF
enabling
enabling:CEF
cell-mode
MPLS
MPLS:modes:cell-mode;modes:MPLS:cell-mode
certificate revocation list (CRL)
CRL (ceritifcate revocation list)
certificates
authentication
troubleshooting;authentication:certificates:troubleshooting;troubleshooting:certificates:authentication
Challenge Handshake Authentication Protocol
CHAP (Challenge Handshake Authentication Protocol)
L2F tunnel establishment;protocols:CHAP:L2F tunnel establishment;authentication:CHAP [See Challenge Handshake Authentication Protocol;CHAP, Challenge Handshake Authentication Protocol; CHAP]
Challenge Handshake Authentication Protocol (CHAP)
configuring
CHAP (Challenge Handshake Authentication Protocol):configuring;configuration:CHAP;protocols:CHAP:configuring
channels
control [See also control channels]
cipher block chaining (CBC)
CBC (cipher block chaining)
circuit status AVPs
AVPs
L2TPv3:circuit status
Cisco Express Forwarding (CEF)
tables
CEF (Cisco Express Forwarding):tables;tables:CEF
classes
L2TPv3
configuring;L2TPv3:classes:configuring;configuration:classes:L2TPv3
clear crypto isakmp command
commands
clear crypto isakmp
clear crypto sa command
commands
clear crypto sa
clear vpdn tunnel command
commands
clear vpdn tunnel 2nd 3rd
clear vpdn tunnel pptp remote access client/PNS_name PAC_name command
commands
clear vpdn tunnel pptp remote access client/ONS_namePac_name
Client ID (CLID)
L2F
CLID (Client ID):L2F;Home Gateway:CLID
clients
VPNs
group policy profiles;groups:VPN client policy profiles;policies:VPM client group profiles;profiles:VPN client group policies
clock set command
commands
clock set;clock timezone command;commands:clock timezone
clock set;clocks:troubleshooting;troubleshooting:clocks
cloning
virtual access interfaces
vitual access interfaces:cloning;interfaces:virtual access:cloning
Common Part Convergence Sublayer-Service Data Units (CPCS-SDUs)
CPCS-SDUs (Common Part Convergence Sublayer-Service Data Units)
Compression Control Protocol (CCP)
CCP (Compression Control Protocol)
protocols:CCP
compulsory tunnel modes
conditional label advertisements
advertisements
conditional label;labels:conditional advertisements
conditional label;labels:conditional advertisements;blocking:label bindings;binding:labels:blocking
deleting
deleting:conditional label advertisements
CONFACK
remote access clients
remote access clients:CONFACK;clients:remote access:CONFACK
configuration
EIGRP
EIGRP:configuring
IKE
policies;IKE:policies:configuring;policies:IKE:configuring
PFS
pseudowire classes
classes:pseudowire:configuring;pseudowire class:configuring
Configure-Ack (CONFACK)
Configure-Reject (CONFREJ)
CONFREJ (Configure-Reject)
Configure-Request (CONFREQ)
conifguration
attachment circuits
attachment circuits:configuring;circuits:attachment:configuring
MDTs
MDTs:configuring;default MDTs:configuring;data MDTs:configuring
VFRs
VFRs:configuring;instances:VFRs:configuring
conservative label retention
constrained shortest path (CSPF) algorithms
CSPF (constrained shortest path) algorithms
algorithms:CSPF
Constraint-based Routed Label Distribution Protocol (CR-LDP)
CR-LDP (Constraint-based Routed Label Distribution Protocol)
protocols:CR-LDP
control channels
messages
ZLB Ack;messages:control channels:ZLB Ack
Control Connection IDs
L2TPv3
control connection management AVPs
L2TPv3
AVPs:L2TPv3:control connection management
control connections
L2Tpv3
troubleshooting;connections:L2TPv3:troubleshooting
control messages
L2TP
data messages:L2TP
L2TPv3 2nd
AVPs;AVPs:L2TPv3 control messages
control planes
MPLS
MPLS:control planes;data planes:MPLS;MPLS:data planes
control VCs
mismatches
VC:control mismatches;LDP:control VC mismatches
control words 2nd
ATM AAL5 CPCS-SDU
ATM AAL5 CPCS-SDU control words
Frame Relay
Frame Relay:control words;pseudowires:AToM:control words;transports:control words
cookies
values
L2TPv3;values:cookies:L2TPv3
copying
conifguration files
pasting:configuration files;moving:configuration files
core interfaces
MPLS
configuring;interfaces:core:configuring MPLS:MPLS:core interfaces:configuring
PIM
configuring;interfaces:core:PIM;configuration:core interfaces:PIM on
Create New VPN Connection Entry Wizard
wizards
Create New VPN Connection Entry
CRL distribution point (CDP)
CDP (CRL distribution point)
distribution:CDP
crl optional command
commands
crl optional 2nd
crypto access list, configuring
configuration
crypto access list;access lists:crypto:configuring;traffic:crypto access lists;IP:crypto access lists
crypto access lists
asymmetric
asymmetric crypto access lists;access lists:crypto:asymmetric
misconfiguration
access lists:crypto:misconfiguration;misconfigurations:crypto access lists
reconfiguration of
access lists:crypto:reconfiguration of;reconfiguration:crypto access lists
crypto ca authenticate name command
commands
crypto ca authenticate name
crypto ca enroll name command
commands
crypto ca enroll name
crypto ca identity command
commands
crypto ca identity
crypto ipsec transform-set command
commands
crypto ipsec transform-set
crypto isakmp key key address peer_address command
commands
crypto isakmp key key address peer_address
crypto isakmp policy command
commands
crypto isakmp policy
crypto isakmp sa command
commands
crypto isakmp sa
crypto map command
commands
crypto map 2nd
crypto maps
identity lists
identity lists:crypto maps
interfaces
applying to;maps:crypto:applying to inerfaces;interfaces:crypto maps:applying to;external interfaces:crypto maps:applying to;applying:crypto maps:to external interfaces
applying to;maps:crypto:applying to interfaces;interfaces:crypto maps:applying to;external interfaces:crypto maps:applying to;applying:crypto maps:to external interfaces
troubleshooting
troubleshooting:crypto maps;maps:crypto:troubleshooting;interfaces:crypto maps:troubleshooting;external interfaces:crypto maps:troubleshooting
crypto maps, configuring
maps
crypto:configuring;configuration:crypto maps
crypto transform-set command
commands
crypto transform-set
customer edge (CE) devices
CE (customer edge) devices
devices:CE


D

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [Z]

D channels
L2TP
channels:D:L2TP;configuration:D channels:L2TP
Data Encryption Standard (DES)
DES (Data Encryption Standard)
data MDTs [See also MDT]
data messages
L2TPv3
data tunnels
dCEF
AToM
enabling
debug aaa authentication command
commands
debug aaa authentication
debug aaa authorization command
commands
debug aaa authorization
debug crypto ipsec command
commands
debug crypto ipsec
debug crypto isakmp command
commands
debug crypto isakmp 2nd 3rd
debug frame-relay events command
commands
debug frame-relay events
debug isdn q931 command
commands
debug isdn q931
debug modem command
commands
debug modem
debug mpls atm-ldp api command
commands
debug mpls atm-ldp api
debug mpls l2transport signaling command
commands
debug mpls 12transport signaling
debug mpls l2transport vc event command
commands
debug mpls 12transport vc event
debug mpls ldp advertisements command
commands
debug mpls ldp advertisements
debug mpls ldp bindings command
commands
debug mpls ldp bindings
debug mpls ldp messages command
commands
debug mpls ldp messages
debug mpls ldp transport events command
commands
debug mpls ldp transport events
debug mppe packet command
commands
debug mppe packet
debug ppp authentication command
commands
debug ppp authentication 2nd 3rd
debug ppp mppe detailed command
commands
debug ppp mppe detailed
debug ppp mppe event command
commands
debug ppp mppe event
debug ppp negotiation command
commands
debug ppp negotiation 2nd 3rd 4th 5th 6th 7th 8th
debug radius command
commands
debug radius 2nd
debug vpdn error command
commands
debug vpdn error 2nd 3rd
debug vpdn event command
comamnds
debug vpdn event
commands
debug vpdn event 2nd
debug vpdn l2tp-sequencing command
commands
debug vpdn 12ttp-sequencing
debug vpdn l2x-data command
comamnds
debug vpdn 12x-data
commands
debug vpdn 12-data
debug vpdn l2x-errors command
commands
debug vpdn 12-errors
debug vpdn 12x-errors
debug vpdn l2x-events command
commands
debug vpdn 12x-events 2nd 3rd
debug vpdn l2x-packets command
commands
debug vpdn 12-packets
debug vpdn 12x-packets 2nd
debug vpdn packet command
commands
debug vpdn packet 2nd 3rd
debug vtemplate command
commands
debug vtemplate 2nd
debug vtemplate;virtual templates:cloning;templates:virtual:cloning;cloning:virtual templates
debug xconnect event command
commands
debug xconnect event
default Multicast Distribution Tree (default MDT)
trees
default MDT;distribution:default MDT;MDT:default
default routes
adding
adding:default routes;routes:default:adding;peer reachability, adding default routes
deleting
access lists
access lists:deleting;interfaces:access lists:deleting;external access lists:deleting
crypto maps
crypto maps:deleting;maps:crypto:deleting;interfaces:crypto maps:deleting;external interfaces:crypto maps:deleting
import maps
import maps:deleting;maps:import:deleting
VPDN session limitations
demultiplexer fields, VC labels
VC
labels;labels:VC
deny any statement
statements
deny any
Department of Defense
DoD (Department of Defense) models
models:DoD;reference models:DoD [See Department of Defense;DoD]
Dialed Number Identification Service (DNIS)
DNIS (Dialed Number Identification Service)
Dialed Number Information Service (DNIS)
DNIS (Dialed Number Information Service)
Diffie-Hellman public values
exchanges
values:Diffie-Helman public:exchanges;exchanges:Diffie-Helman public values
values
Diffie-Helman public
digital certificates
site-to-site IPSec VPNs
digital subscriber line access multiplexer (DSLAM)
DSLAM (digital subscriber line access multiplexer)
disabling
CEF
CEF:disabling
ISAKMP
ISAKMP:disabling;re-enabling:ISAMP;ISAKMP:re-enabling
labels
assignments;labels:assignments:disabling;assignments:labels:diabling
disconnections
remote access clients
remote access clients:disconnections;access:remote clients:disconnections;clients:remote access:disconnections
Distinguished Name (DN)
crypto maps
DN (Distinguished Name):crypto maps;crypto maps:DN;maps:crypto:DN;peers:DN-based crypto maps;tunneling:IPSec:troubleshooting
distributed CEF [See dCEF]
distributed CEF (dCEF)
enabling
dCEF (distributed CEF):enabling;enabling:dCEF
DLCI-to-DLCI connections
Frame Relay
connections:DLCI-to-DLCI:Frame Relay;Frame Relay:DLCI-to-DLCI connections
Don't Fragment (DF)
DF (Don't Fragment)
Don't Fragment (DF) bit
DF (Don't Fragment) bit
bits:DF
downstream LSRs
LSRs
downstream;distribution:downstream LSRs
downstream-on-demand label distribution
dynamic crypto maps [See also crypto maps]
configuring
configuration:dynamic crypto maps;maps:dynamic crypto
dynamic sessions
L2TPv3
configuring;sessions:dynamic:L2TPv3;configuration:dynamic sessions:L2TPv3;LCCE:routers:dynamic sessions (L2TPv3);routers:L2TPv3:dynamic sessions 2nd
troubleshooting;sessions:dynamic:troubleshooting


E

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [Z]

E (Explicit Forward Congestion Indication, EFCI) bit
E1
L2TP
configuring;T1:L2TP:configuring;controllers:E1/T1:L2TP;configuration:E1/T1 controllers:L2TP
E1 controllers
configuring
controllers:E1/T1:configuring;configuring:E1/T1 controllers
EBGP
configuring
configuration:EBGP
Echo-Reply message
PPTP
messages:Echo-Reply:PPTP;formats:Echo-Reply messages;packets:Echo-Reply messages;formats:Echo-Request messages
Echo-Request messages
PPTP
messages:Echo-Request:PPTP;packets:Echo-Request messages
egress LSRs
penultimate hop popping
egress PE routers
installing
troubleshooting;PE routers:installing:troubleshooting;installation:PE routers:troubleshooting;BGP:tables:egress MP-BGP routes;tables:BGP:MP-BGP routes
enabling
CEF
CEF:enabling
Encapsulating Security Payload (ESP)
ESP (Encapsulating Security Payload)
packets:ESP;headers:ESP 2nd
encapsulation
AH
Layer 3 MPLS VPNs
encoding
RD
RD
encryption
algorithms
algorithms:encryption;hash algorithms;algorithms:hash
ESP
end-to-end troubleshooting
bottom-up troubleshooting
top-down troubleshooting;troubleshooting:types of;types:of troubleshooting
Enhanced GRE
headers
headers:Enhanced GRE
enrollment
CAs
CAs:enrollment;routers:CAs:enrollment
enrollment mode ra command
commands
enrollment mode ra
error codes
L2TPv3 2nd
PPTP
values
values:error codes
ESP DES encryption
encryption
ESP DES
Ethernet
VLAN (802.1q) mode
Ethernets
encapsulation
AToM;encapsulation:Ethernets:AToM
encapsulation:Ethernets;interfaces:Ethernets:encpasulation
port mode attachment circuits
ports:Ethernets:attachment circuits
exchanges
quick mode [See also responders; quick mode]
Experimental (EXP) field
extended authentication (XAuth)
XAuth (extended authentication)
external interfaces
access lists
access lists:external interfaces;interfaces:access lists


F

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [Z]

failure codes
session/tunnel setup
tunneling:failure codes;sessions:failure codes
fields
values
L2F;values:fields:L2F
firewalls
ISAKMP
blocking;ISAKMP:firewalls:blocking;blocking:ISAKMP:firewalls
Flags field
bits
fields:Flags:bits;bits:Flags field
flowcharts
IPSec VPN troubleshooting
topologies:IPSec VPNs
PPTP
FORCED CONFACK
FORCED CONFREQ, incoming
incoming FORCED CONFREQ
FORCED LCP CONFREQ
formats
RD
encoding:RD
forwarding
MPLS
MPLS:forwarding
traffic
VPNs;traffic:VPNs:forwarding;VPNs:traffic:forwarding;backbones:VPNs:forwarding traffic
Forwarding Equivalence Class (FEC)
FEC (Forwarding Equivalence Class)
Forwarding Equivalence Class (FEC) elements
FEC (Forwarding Equivalence Class) elements
elements:FEC
Frame Check Sequence (FCS)
FCS (Frame Check Sequence)
Frame Relay
encapsulation
AToM;encapsulation:Frame Relay:Atom
encapsulation:Frame Relay
port-to-port connections
port-to-port connections:Frame Relay;connections:port-to-port:Frame Relay
transports
transports:Frame Relay
trunks
trunks:Frame Relay;connections:Frame Relay:trunks;conifguration:Frame Relay:trunks
frame-mode
MPLS
modes:MPLS:frame-mode;MPLS:modes:frame-mode


G

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [Z]

gateways
IPSec remote access
configuration:gateways:IPSec remote access
global BGP parameters
configuring
configuration:global BGP parameters;BGP
global ISDN parameters
configuring
ISDN:global parameters:configuring;parameters:global ISDN:configuring;configuration:global ISDN parameters
L2TP
group asynchronous interfaces
configuring
interfaces:asynchronous group:conifguring;configuration:asynchronous group interfaces


H

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [Z]

hash algorithm
MD5
modification of;MD5:hash algorithm:modifiication of;algorithms:hash:modification of MD5
hash algorithms
reconfigurations
reconfiguration:hash algorithms;algorithms:hash:reconfiguration of
HDLC
encapsulation
encapsulation:HDLC;PPP:encapsulation;encapsulation:PPP
head-end (PE) routers, configuring
hello messages
L2TP
messages:hello:L2TP;L2TP:hello messages
Hidden (H) bits
Home Gateway
MIDs
Home gateways
L2F_OPEN messages
session setup
PPP frames
forwarding;PPP:frames:forwarding;frames:PPP:forwarding;forwarding:PPP frames;NAS:PPP frames:forwarding;tunneling:PPP frames;protocols:PPP:forwarding frames


I

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [Z]

idnetification
tunnel packets
CLIDs;tunneling:packets:identifying with CLIDs;packets:tunneling:identifying with CLIDs
IDs
LDP neighbors
neighbors:LDP ID
IKE
AAA
AAA:IKE;policies:IKE:AAA
policies
configuring;configuration:IKE:policies;policies:IKE:configuring
configuring;policies:IKE:configuring;configuration:IKE:policies
mismatches;mismatches:IKE policies;policies:IKE:mismatches
policies:IKE
IKE phase 1
main mode negotiation failure
main mode negotiation:failure of;modes:main:negotiation failure;negotiation:main mode:failure of 2nd
IKE phase 2
quick mode negotiation failure
quick mode negotiation:failure of;modes:quick:negotiation failure;negotiation:quick mode:failure of 2nd
import maps
ingress PE routers
maps:import:ingress PE routers;ingress PE routers:import maps;PE:import maps;routers:PE:import maps
inbound traffic
Incoming-Call-Connected (ICCN)
ICCN (Incoming-Call-Connected) 2nd
Incoming-Call-Reply (ICRP)
ICRP (Incoming-Call-Reply)
Incoming-Call-Reply (ICRP) message
ICRP (Incoming-Call-Reply) message
messages:ICRP
Incoming-Call-Request (ICRQ)
ICRQ (Incoming-Call-Request)
Incoming-Call-Request (ICRQ) message
ICRQ (Incoming-Call-Request) message
messages:ICRQ
independent LSP control
LSPs
independent control
initialization
L2F tunnels
initialization vector (IV)
IV (initialization vector)
initiation
IKE negotiation
quick mode negotiation
initiators
routing
troubleshooting;routing:initiators:troublehsooting;troubleshooting:routing:initiators
Interface Parameters field
fields
Interface Parameters' values:Parameter ID
interfaces
MPLS
disabling;disabling:MPLS:interfaces;MPLS:interfaces:disabling;core interfaces:MPLS:disabling;interfaces:core:disabling MPLS
MPLS TE
parameters:interfaces:MPLS TE
VPNs
Internet access with separate;VPNs:interfaces:Internet access with separate;Internet:access:interfaces;access:Internet:interfaces
Intermediate System-to-Intermediate System
IS-IS (Internediate System-to-Intermediate System)
MPLS backbone IGPs;configuration:IS-IS:MPLS backbone IGPs [See IS-IS]
Internet
access
VPNs;access:Internet:VPNs;VPns:Internet access
Internet Control Message Protocol (ICMP)
ICMP (Internet Control Message Protocol)
protocols:ICMP;messages:ICMP
Internet Engineering Task Force (IETF)
IETF (Internet Engineering Task Force)
Internet Key Exchange (IKE)
IKE (Internet Key Exchange)
keys:IKE [See also IKE]
interprovider VPNs [See also VPNs]
IP
addresses
misconfigurations;addresses:IP:misconifgurations;misconfigurations:IP addresses;initiators:IP addresses:troubleshooting;verification:peer IP addresses
mismatches;addresses:IP:mismatches;mismatches:IP addresses;PE:routers:IP address mismatches;routers:PE:IP address mismatches;peer PE routers:IP address mismatches;misconfigurations:peer IP addresses
PPTP;addresses:IP:PPTP;pools:IP:PPTP;DNS:PPTP;WINS:PPTP;servers:addresses:PPTP
L2TPv3 control message header over
headers:IP:over L2TPv3
pools
creating;pools:IP:creating;configuration:IP:pools;DNS:addresses:configuring;addresses:conifguring;configuration:DNS:addresses;WINS:addresses:configuring;addresses:WINs:configuring;conifguration:WINS:addresses
L2TP;pools:IP:L2TP;DNS:addresses:L2TP;addresses:DNS:L2TP;WINS:addresses:L2TP;addresses:WINS:L2TP;servers:addresses:L2TP
ip dfbit set command
commands
ip difbit set
ip domain-name command
commands
ip domain-name
ip local pool command
commands
ip local pool
ip ospf network point-to-point command
commands
ip ospf network point-to-point
ip pim sparse-dense-mode command
commands
ip pim sparse-dense-mode
ip pmtu command
commands
ip pmtu
ip unnumbered command
commands
ip unnumbered
IPCP
negotiation
troubleshooting;negotiation:IPCP:troubleshooting;troubleshooting:IPCP:negotiation
IPCP CONFREQ
IPSec
case studies
case studies:IPSec 2nd
commands
commands:IPSec;troubleshooting:commands:IPSec 2nd 3rd
lab solutions 2nd
SAs
SAs:IPSec
transform sets
mismatches;mismatches:IPSec:transform sets;transform sets:IPSec:mismatches
tunnels
establishing;tunneling:IPSec:establishing;establishment:of IPSec tunnels;tunneling:IPSec [See also IPSec]
IPSec (IP Security)
configuring
VPNs:IPSec:configuring;security:IPSec:configuring;configuration:IPSec VPNs
IKE
VPNs:IPSec:IKE;security:IPSec:IKE;SAs (security associtations):IKE;security associations (SAs):IKE;connections:SAs:IKE;gateways:SAs:IKE;IKE;management:IKE 2nd
L2TP
IP Security (IPSec):L2TP
MTU issues
VPNs:IPSec:MTU issues;security:IPSec:MTU issues;configuration:IPSec VPNs:MTU issues;MTU:IPSec VPNs:troubleshooting;troubleshooting:IPSec VPNs:MTU issues 2nd
remote access
VPNs:IPSec:remote access;security:IPSec:remote access;configuration:IPSec VPNs:remote access;remote access IPSec VPNs:configuring 2nd
SAs
VPNs:IPSec:SAs;security:IPSec:SAs;SAs (security associtations);security associations (SAs);connections:SAs;gateways:SAs 2nd
security protocols
VPNs:IPSec:security protocols;security:IPSec:security protocols;protocols:security 2nd
site-to-site
VPNs:IPSec:site-to-site;security:IPSec:site-to-site;configuration:IPSec VPNs:site-to-site;site-to-site IPSec VPNs:configuring 2nd
technical overview of
VPNs:IPSec:technical overview of;security:IPSec:technical overview of 2nd
troubleshooting
VPNs:IPSec:troubleshooting;security:IPSec:troubleshooting;configuration:IPSec VPNs:troubleshooting;troubleshooting:IPSec VPNs:troubleshooting 2nd
VPNs
IPSec;security:IPSec
IS-IS
advertisements
advertisements:IS-IS
loopback interfaces
enabling;loopback interfaces:IS-IS:enabling;enabling:loopback interfaces:IS-IS;interfaces:loopback:IS-IS
ISAKMP
disabling
disabling:ISAKMP
exchanges
exchanges:ISAKMP
messages
ISAKMP
troubleshooting;messages:ISAKMP:troubleshooting;troubleshooting:ISAKMP:messages
preshared keys
configuring
ISDN
D channels
configuring;D channels:configuring;configuration:ISDN:D channels


K

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [Z]

keepalives
L2F
L2TP
L2TP:keepalives
PPTP
PPTP:keepalives
keys
L2F
calculating;calculations:keys:L2F


L

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [Z]

L (Cell Loss Priority, CLP) bit
L2F
commands
commands:L2F;troubleshooting:L2F;commands 2nd
show;L2F:commands:debug;debug commands:L2F;show commands:L2F;commands:debug:L2F;commands:show:L2F 2nd 3rd
Home Gateways
configuring;troubleshooting:L2F:Home Gateway configuration;configuration:L2F:Home gateways;Home Gateways:L2F:conifguring 2nd
maintenance
troubleshooting:L2F:maintenance;configuration:L2F:maintenance;maintenance:tunneling:L2F;tunneling:L2F:maintenance;maintenance:L2F:tunneling 2nd
management messages
troubleshooting:L2F:management messages;configuration:L2F:management messages;management:L2F:messages;messages:L2F 2nd
NAS
configuring;troubleshooting:L2F:NAS conifiguration;configuration:L2F:NAS;NAS:L2F:conifguring 2nd
PPP
NAS;troubelshooting:L2F:PPP on NAS;configuration:L2F:PPP on NAS;NAS:L2F:PPP;PPP:NAS:troubleshooting L2F;protocols:PPP:NAS 2nd
PPP negotiation
troubleshooting;troubleshooting:L2F:PPP negotiation;configuration:L2F:PPP negotiation;Home Gateways:L2F:PPP negotiation;PPP:L2F:negotiation;remote access clients:PPP negotiation failures;clients:PPP negotiation faliures 2nd
sessions
troubleshooting:L2F:sessions;configuration:L2F:sessions;sessions:L2F 2nd
troubleshooting;troubleshooting:L2F:sessions;configuration:L2F:sessions;NAS:L2F:sessions;sessions:L2F:troubleshooting 2nd
teardown
troubleshooting:L2F:teardown;configuration:L2F:teardown;teardown:tunneling:L2F;tunneling:L2F:teardown;teardown:L2F:tunneling 2nd
technical overview of
troubleshooting:L2F:technical overview of;configuration:L2F:technical overview of 2nd
troubleshooting
troubelshooting:L2F;configuration:L2F:troubleshooting;flowcharts:L2F:troubleshooting 2nd 3rd
tunneling
troubleshooting:L2F:tunneling;configuration:L2F:tunneling;tunneling:L2F 2nd
troubleshooting;troubleshooting:L2F:tunneling;configuration:L2F:tunneling;NAS:L2F:tunneling;tunneling:L2F:troubleshooting 2nd
L2F_CLOSE messages
messages
L2F_CLOSE
L2F_CONF messages
messages
L2F_CONF
L2F_CONF;Home Gateways:L2F_CONF messages
L2F_ECHO messages
messages
L2F_ECHO
L2F_OPEN messages
messages
L2F_OPEN;NAS:L2F_OPEN
L2TP
IPSec
disabling;IPSec:L2TP:disabling;disabling:IPSec:L2TP
L2TP (Layer Two Tunneling Protocol)
case study
AAA server unreachable;case studies:L2TP:AAA server unreachable;AAA:servers:unreachable from LNS;servers:AAA:unreachable from LNS;LNS:AAA severs unreachable from 2nd
misconfiguration (AAA RADIUS servers);case studies:L2TP:misconfiguration (AAA RADIUS server);misconfiguration:L2TP:AAA RADIUS servers;AAA:L2TP misconfiguration;RADIUS:L2TP misconfiguration 2nd
protocols:L2TP:case study;negotiation:L2TP:case study;troubleshooting:L2TP:case study;configuration:L2TP:case study;case studies:L2TP 2nd
remote AAA authentication failure;case studies:L2TP:remote AAA authentication;AAA:remote:authentication failure;authentication:remote AAA:failure;RADIUS:authentication failure 2nd
remote AAA authorization failure;case studies:L2TP:remote AAA authorization;AAA:remote:authorization failure;authorization:remote AAA:failure;RADIUS:authorization failure 2nd
commands
commands:L2TP;troubleshooting:L2TP:commands 2nd
compulsory tunnel mode
protocols:L2TP:compulsory tunnel mode;tunneling:L2TP:compulsory tunnel mode;compulsory tunnel mode:L2TP;configuration:L2TP:compulsory tunnel mode 2nd
control messagesf
protocols:L2TP:control messages;tunneling:L2TP:control messages;control messages:L2TP;messages:L2TP 2nd
debug commands
debug commands:L2TP;commands:debug:L2TP 2nd
error messages
error messages:L2TP 2nd
establishment
protocols:L2TP:establishment;tunneling:L2TP:establishment 2nd
IPSec
protocols:L2TP:IPSec;tunneling:L2TP:IPSec;IPSec:L2TP;configuration:L2TP:IPSec;compulsory tunnel mode:IPSec:configuring;preshared keys:compulsory tunnel mode:IPSec 2nd
protocols:L2TP:IPSec;tunneling:L2TP:IPSec;IPSec:L2TP;configuration:L2TP:IPSec;voluntary tunnel mode:IPSec:configuring;preshared keys:voluntary tunnel mode:IPSec 2nd
LAC
call reception;protocols:L2TP:call reception;tunneling:L2TP:call reception;troubleshooting:L2TP:call reception;configuration:L2TP:call reception;LAC:call reception;call reception:L:AC 2nd
PPP;protocols:L2TP:PPP on LAC;tunneling:L2TP:PPP on LAC;troubleshooting:L2TP:PPP on LAC;configuration:L2TP:PPP on LAC;LAC:PPP on;PPP:LAC 2nd
LNS
protocols:L2TP:LNS;tunneling:L2TP:LNS;LNS:L2TP;configuration:L2TP:LNS;LNS:configuring 2nd
maintenance
protocols:L2TP:maintenance;tunneling:L2TP:maintenance;maintenance:L2TP
messages
protocols:L2TP:messages;tunneling:L2TP:messages;messages:L2TP 2nd
negotiation
troubleshooting;protocols:L2TP:sessions;negotiation:L2TP:troubleshooting;troubleshooting:L2TP:negotiation;configuration:L2TP:negotiation 2nd
outgoing calls
protocols:L2TP:outgoing calls;tunneling:L2TP:outgoing calls;outgoing calls:L2TP 2nd
security
protocols:L2TP:security;tunneling:L2TP:security;security:L2TP
sessions
protocols:L2TP:sessions;tunneling:L2TP:sessions;sessions:L2TP 2nd
troubleshooting;protocols:L2TP:sessions;sessions:L2TP:troubleshooting;troubleshooting:L2TP:sessions;configuration:L2TP:sessions 2nd
show commands
show commands:L2TP;commands:show:L2TP 2nd
teardown
protocols:L2TP:teardown;tunneling:L2TP:teardown;teardown:L2TP
technical overview of
protocols:L2TP:technical overview of;tunneling:L2TP:technical overview of 2nd
troubleshooting
protocols:L2TP:troubleshooting;tunneling:L2TP:troubleshooting;troubleshooting:L2TP;configuration:L2TP:troubleshooting 2nd
tunnels
troubleshooting;protocols:L2TP:tunnels;tunneling:L2TP:troubleshooting;troubleshooting:L2TP:tunnels;configuration:L2TP:tunnels 2nd
voluntary tunnel mode
protocols:L2TP:voluntary tunnel mode;tunneling:L2TP:voluntary tunnel mode;voluntary tunnel mode:L2TP;configuration:L2TP:voluntary tunnel mode 2nd
L2TP Access Concentrator (LAC)
LAC (L2TP Access Concentrator)
l2tp hidden command
commands
12tp hidden
L2TP Network Server
LNS (L2TP Network Server)
servers:LNS [See LNS]
L2TP Network Server (LNS)
LNS (L2TP Network Server)
servers:L2TP
L2TPv2
lab solutions
L2TPv3
commands
commands:L2TPv3;troubleshooting:L2TPv3:commands 2nd 3rd
configuring
configuration:L2TPv3;LAC:L2TPv3:configuring;routers:L2TPv3:conifguring 2nd
control connections
LAC:L2TPv3:control connections;LNS:L2TPv3:control connections;control connections:L2TPv3;connections:control:L2TPv3 2nd
maintenance;LAC:L2TPv3:control connections;LNS:L2TPv3:control connections;control connections:L2TPv3:maintenance;connections:control:L2TPv3;maintenance:L2TPv3
messages
LAC:L2TPv3:messages;LNS:L2TPv3:messages;messages:L2TPv3 2nd
MTU issues
configuration:L2TPv3:MTU issues;MTU:L2TPv3:troubleshooting;Maximum Transmission Unit (MTU):L2TPv3:troubleshooting;troubleshooting:MTU:L2TPv3 2nd
sample configurations
configuration:L2TPv3:sample configurations;LCCE:L2TPv3:sample configurations;dynamic sessions:L2TPv3:sample configurations;sessions:L2Tpv3:sample configurations;routers:LCCE:sample L2TPv3 configurations 2nd
sessions
LAC:L2TPv3:sessions;LNS:L2TPv3:sessions;sessions:L2TPv3
SLI
LAC:L2TPv3:SLI;LNS:L2TPv3:SLI;SLI (Set-Link-Info) message:L2TPv3;Set-Info-Link (SLI) message:L2TPv3;messages:SLI:L2TPv3
teardown
LAC:L2TPv3:teardown;LNS:L2TPv3:teardown;control connections:L2TPv3:teardown;teardown:L2TPv3;sessions:L2TPv3:teardowns
technical overview of
LAC:L2TPv3:technical overview of;LNS:L2TPv3:technical overview of
troubleshooting
configuration:L2TPv3:troubleshooting;LAC:L2TPv3:troubleshooting;routers:L2TPv3:troubleshooting;troubleshooting:L2TPv3 2nd 3rd
L2TPv3 control connection endpoints (LCCEs)
LCCEs (L2TPv3 control connection endpoints)
L@TPv2
lab solutions
lab routers
configuration files
loading
loading;lab routers [See also routers]
lab solutions, troubleshooting
troubleshooting
lab solutions;lab routers:troubleshooting;solutions, troubleshooting labs 2nd
Label Controlled ATM (LC-ATM) interfaces
LC-ATM (Label Controlled ATM) interfaces
interfaces:LC-ATM
Label Distribution Protocol (LDP)
LDP (Label Distribution Protocol)
protocols:LDP 2nd 3rd
Label Forwarding Information Base (LFIB)
LFIB (Label Forwarding Information Base) 2nd
Label Information Base (LIB)
LIB (Label Information Base)
label stacks
stacks
labels
label switched path (LSP)
LSP (label switched path)
labels
bindings
verifying;bindings:labels:verifying;verification:labels:bindings;tunneling:labels:verifying bindings;advertisements:labels:verifying tunnels;LSP:tunnels:verifying label bindings
distribution protocols
distribution:label protocols;protocols:label distribution
messages
mapping;messages:labels:mapping;mapping:labels:messages
withdraw;messages:labels:withdraw;withdraw messages, labels
LAC
configuring
configuration:LAC 2nd
Layer 3
VPNs
models:VPNs [See also VPNs, VPNs;IP:VPNs. See also VPNs;connections:IP:VPNs. See also VPNs]
Layer Two Forwarding Protocol
L2F (Layer 2 Forwarding) Protocol
protocols:L2F;forwarding:L2F [See L2F, L2F;PPP:L2F. See also L2F;SLIP:L2F. See also L2F;IP backbones:L2F. See also L2F;backbones:L2F. See also L2F]
Layer Two Tunneling Protocol
L2TP (Layer Two Tunneling Protocol)
protocols:L2TP;tunneling:L2TP [See L2TP]
Layer Two Tunneling Protocol Version 3
tunneling
L2TPv3. See L2TPv3;frames:L2TPv3. See L2TPv3;models:L2TPv3. See L2TPv3;L2TPv3 (Layer Two Tunneling Protocol Version 3);protocols:L2TPv3 [See L2TPv3, ]
LC-ATM interfaces
troubleshooting
interfaces:LC-ATM:troubleshooting;troubleshooting:LC-ATM interfaces
LCP
negotiation
negotiation:LCP;partial authentication;authentication:partial
troublehsooting;negotiation:LCP:troubleshooting;troubleshooting:LCP:negotiation;remote clients:LCP negotiation failures;NAS:LCP negotation failures
troubleshooting;negotiation:LCP:troubleshooting;troubleshooting:LCP:negotiation;PPP:authentication:troubleshooting;authentication:PPP:troubleshooting:troubleshooting:PPP:authentication
lcp renegotiation command
commands
lcp renegotiation
LDP
authentication
troubleshooting;authentication:LDP:troubleshooting;mismatches:authentication password;passwords:authentication:troubleshooting
authentication mismatches
authentication:LDP mismatches;mismatches:LDP authentication
configuring
configuration:LDP;protocols:LDP:configuring
mismatches
mismatches:LDP
neighbor discovery
peer PE routers;neighbors:LDP discovery:PE peer routers;discovery:LDP neighbors:PE peer routers
troublehsooting;neighbors:LDP:discovery failures;discovery:LDP neighbor failures;connections:LDP neighbor discovery failures;LSRs:LDP neighbor discovery failures
sessions
PE routers;sessions:LDP:PE routers;PE:routers:LDP session failures;routers:PE:LDP session failures
troublehsooting;sessions:LDP:troubleshooting;LSRs:LDP session failures
troubleshooting;sessions:LDP:troublehshooting;troubleshooting:LDP:sessions
tunnel LSP establishment
troubleshooting;LSP:tunnel establishement::troubleshooting;tunneling:LSP:troubleshooting
LFIB
verifying
verification:LFIB
liberal label retention
Link Control Protocol
LCP (Link Control Protocol)
negotiation;negotiation:LCP;protocols:LCP:negotiation [See LCP]
LNS
CDN
sending;CDN:LNS:sending
conifguring
configuration:LNS
RADIUS authentication failure
RADIUS authorization failure
VPDNs
enabling;VPDNs:LNS:enabling;enabling:VPDNs:LNS;groups:VPDNs:LNS;configuration:VPDNs:LNS
local authentication
LNS
authentication:local:LNS;remote AAA:LNS;AAA:remote:LNS;conifguration:remote AAA:LNS;configuration:local authentication:LNS;authentication:LNS
local IP address pools
configuring
IP:addresses:local pools;pools:IP addresses:local
local username databases
configuring
configuration:local username databases;databases:local username;usernames:local databases
loopback interfaces
PE routers
interfaces:loopback:PE routers;BGP:updating;updating:BGP;protocols:BGP:updating;LDP:updating;updating:LDP;protocols:LDP:updating
loopbakc interfaces
conifguring
interfaces:loopback:configuring;packets:l2TPv3 [See also L2TPv3]
loss of alarm signals
signals
loss of alarm
LSP
AToM
troubleshooting
MPLS VPNs
troubleshooting;troubleshooting:LSP:MPLS VPNs 2nd
LSRs
labels
retention;labels:retention;retention:lables


M

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [Z]

Magic Cookie field
fields
Magic Cookie
Magic Numbers
main mode negotiation
negotiation
main mode;modes:main mode negotiation
main mode;negotiation:main mode;preshred key authentication;authentication:preshared key;keys:preshared key authentication
RSA signature authentication
RSA signature authentication;authentication:RSA signature;signatures:RSA authentication;digital certificates;certificates:digital
mandatory (M) bits
maps
certificate servers
certificates:server maps;servers:certificate maps
Maximum Segment Size (MSS)
MSS (Maximum Segment Size)
Maximum Transmission Unit (MTU)
MTU (Maximum Transmission Unit)
MDT
optimizing
optimization:MDT;forwarding:MDT:optimizing;backbones:MDT:optimizing
Message Digest 5
MD5 (Message Digest 5)
calculating;calculations:MD5 [See hash algorithm;MD5]
Message Type AVP
messages
error [See VPDNs;error messages]
PPTP Control
Microsoft CA servers, configuring
configuration
Microsoft CA servers;servers:Microsoft CA:configuring
Microsoft Point-to-Point Compression (MS-PPC)
MS-PPC (Microsoft Point-to-Point Compression)
compression:MS-PPC
midpoint routers
configuring
tail-end routers:configuring
misconfigurations
export maps
export maps:misconfigurations;maps:export:misconfiguration
interfaces
interfaces:misconfigurations
peer LCCE IP addresses
LCCE:IP addresses:misconfiguration of;IP:addresses:peer LCCE misconfiguration;xconnect command;commands:xconnect
static routes
mismatches
proposals
proposals:mismatches
targets
targets:mismatches;export route targer mismatches;import route target mismatches
modes
AH transport
modes:AH tunnel;encapsulation:AH
ESP 2nd
MPLS
MPLS:modes
MP-BGP
activating
activation:MP-BGP;BGP:MP-BGP:activating;routes:MP-BGP:activating;exchanges:routes:activating MP-BGP
routes
redistributing;routes:MP-BGP:redistributing;redistribution:MP-BGP routes;BGP:MP-BGP:redistributing routes
MPLS
AToM
troubleshooting;verification:MPLS:AToM
disabling
disabling:MPLS
HDLC over encapsulation
HDLC:encapsulation;encapsulation:HDLC;conifguration:HDL:MPLS
lab solutions
labels
labels:MPLS
verifying
verification:MPLS
VPNs
case studies;VPNs:MPLS:case studies;troubleshooting:MPLS VPNs:case studies;case studies:MPLS VPNs 2nd
commands;VPNs:MPLS:commands;troubleshooting:MPLS VPNs:commands;commands:MPLS VPNs 2nd 3rd
troubleshooting;VPNs:MPLS:troubleshooting;troubleshooting:MPLS VPNs 2nd
mpls ip command
commands
mpls id
mpls ip 2nd
mpls label protocol ldp command
commands
mpls label protocol ldp
MPLS Layer 3 VPN
lab solutions
mpls ldp advertise-labels command
commands
mpls ldp advertise-labels
MPLS TE, enabling
enabling
MPLS TE
MPPE
negotiation
troubleshooting;negotiation:MPPE:troubleshooting;troubleshooting:MPPE:negotiation
MS-CHAP
virtual templates
PPTP;verification:PPTP tunnels
MS-PPC supported bits
MTU
mismatches
mismatches:MTU
mtu command
commands
mtu
Multicast Distribution Tree (MDT)
MDT (Multicast Distribution)
trees:MDT;distribution:MDT;addresses:MDT
Multicast Domains (MD)
MD (Multicast Domains)
domains:MD
Multicast Tunnel Interface (MTI)
MTI Multicast Tunnel Interface)
tunneling:MTI;interfaces:MTI
Multicast VPNs (MVPNs)
MVPNs (Multicast VPNs) [See also VPNs, ]
Multicast VRF (MVRF)
MVRF (Multicast VRF)
VRF:MVRF
Multichassis Multilink PPP (MMP)
MMP (Multichassis Multilink PPP)
PPP:MMP
Multilink PPP (MP)
MP (Multilink PPP)
PPP:MP [See also MP]
Multilink-Endpoint-Discriminator (ED)
ED (Multilink-Endpoint-Discrimnator)
Multilink-Maximum-Reconstructed-Receive-Unit (MRRU)
MRRU (Multilink-Maximum-Reconstructed-Recieve-Unit)
multiplex ID (MID)
MID (multiplex ID)
Multiprotocol Extensions for BGP-4 (MP-BGP)
MP-BGP (Multiprotocol Extensions for BGP-4)
multiprotocol label switching (MPLS) networks
AToM
MPLS (multiprotocol label switching) networks:AToM [See also AToM, AToM;switching:MPLS:AToM. See also AToM;labels:AToM. See also AToM]
MVPNs
configuring
configuration:MVPns;PE routers:MVPNs:configuring;routers:PE:MVPNs 2nd
MVRFs
enabling
enabling:MVRFs;multicasting:enabling;enabling:multicasting


N

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [Z]

NAS
call reception
call reception:NAS
L2F_OPEN message
session setup;L2F_OPEN message:session setup;messgaes:L2F_OPEN:session setup
NAT
IPSec
troubleshooting;devices:NAT:troubleshooting IPSec;IPSec:NAT devices:troubleshooting;blocking:IPSec traffic:troubleshooting NAT devices
NCP
negoitation
failure on LNS
negotiation
troubleshooting;negotiation:NCP:troubleshooting;troubleshooting:NCP:negotiation;protocols:NCP:negotiation failures
negotiation
termination
termination:negotiation
neighbors
MP-BGP
activating
Network Access Server
NAS (Network Access Server)
servers:NAS [See NAS]
Network Address Translation (NAT)
NAT (Network Address Translation)
devices:NAT;firewalls;security:firewalls
Network Control Protocol (NCP)
negotiation
NCP (Network Control Protocol):negotiation;negotiation:NCP;protocols:NCP:negotiation
Network Control Protocols (NCPs)
negotiation
NCPs (Network Control Protocols):negotiation;protocols:NCPs:negotiation;negotiation:NCPs
Network Time Protocol (NTP)
NTP (Network Time Protocol)
protocols:NTP
networks
baselining
baselining:networks;topologies:baselining;diagrams:networks:baselining
no auto-summary command
commands
no auto-summary
no mpls ldp advertise-labels command
commands
no mpls ldp advertise-labels
no vpdn softshut command
commands
no vpdn softshut
NONCE payloads
payloads
NONCE 2nd


O

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [Z]

O (Offset) bits
Oakley Key Determination Protocol (RFC 2412)
Offset pad field
Offset size field
Open Shortest Path First
OSPF (Open Shortest Path First)
MPLS backbone IGPs [See OSPF]
Open Systems Interconnection
OSI (Open System Interconnection)
models:OSI;reference models:OSI [See Open Systems Interconnection;OSI]
options
L2F management messages
tunneling:management:packet payload options;packets:payloads:options;payloads:packets:options
ordered LSP control
LSPs
ordered control
OSPF
configuring
configuration:OSPF
MPLS
configuring;configuration:MPLS:OSPF;MPLS:OSPF:configuring
outbound traffic
Outgoing-Call-Connected (OCCN) message
messages
OCCN;OCCN (Outgoing-Call-Connected) message
Outgoing-Call-Reply (OCRP) message
messages
OCRP;OCRP (Outgoing-Call-Reply) message
OCRP (Outgoing-Call-Reply) message
messages:OCRP
Outgoing-Call-Request (OCRQ) message
messages
OCRQ;OCRQ (Outgoing-Call-Request) message
overlapping IP address space
addresses
IP:overlapping;IP:addresses:overlapping
overlay VPN model


P

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [Z]

P (Priority) bits
P routers
MVPNs
configuring;routers:P:MVPNs;backbones:MVPNs:configuring;configuration:P routers:MVPNs 2nd
TE tunnels
routers:P:TE tunnels;TE tunnels:P routers;interfaces:MPLS TE tunnel;configuration:TE tunnels:between P routers
PAC
CONFREQ
CONFRQ:PAC
local authentication
local authentication:PAC;authenitcation:local:PAC;configuration:PAC:local authentication
PPTP
termination
packets
L2F
formats;formats:packets:L2F;headers:packets:L2F
leaking
leaking:packets;static routes:packet leaking;routes:static:packet leaking
MTU
AToM
TCP SYN
parameters
asynchronous lines
configuring;asynchronous lines:parameters:conifguring;configuration:asynchronous lines:parameters
partial PPP authentication failures
PPP
partial authentication failures;protocols:PPP:partial authentication failures;authentication:partial PPP failures;troubleshooting:PPP:partial authentication failures
troubleshooting
partial PPP authentication;authentication:partial PPP failures;LAC:partial PPP authentication failures
passwords
LDP
mismatches;LDP:password mismatches;mismatches:LDP:passwords
Path MTU Discovery (PMTUD)
PMTUD (Path MTU Discovery)
payloads
types
of payloads;values:payloads;functions:payloads
PE
routers
LDP;routers:PE:LDP;LDP:PE routersLtroubleshooting
PE routers
advertisements
CE routers:advertisements
CE route advertisement
CE routers:advertisements;advertisements:PE to CE route;routes:PE to CE advertisement
configuring
routers:PE:configuring;configuration:PE routers
IS-IS
configuring;routers:PE:IS-IS;configuration:PE routers:IS-IS;IS-IS:PE routers:configuring
MVPNs
routers:PE:MVPNs;PIM:PE routers:MVPNs;MVPNs:PE routers;configuring 2nd 3rd
TE tunnels
routers:PE:TE tunnels 2nd 3rd 4th 5th
PE-CE routing protocol
troubleshooting
protocols:PE-CE routing:troubleshooting;troubleshooting:PE-CE routing protocols;static routes:troubleshooting;routes:static:troubleshooting;troubleshooting:static routes
PE-CE routing protocols
troubleshooting
troubleshooting:PE-CE routing protocols;protocols:PE-CE routing:troubleshooting
PE-CE routing protocols, conifguring
configuration
PE-CE routing protocols;protocols:PE-CE routing;routing:PE-CE protocols;static routes:configuring;configuration:static routes;routes:static:configuring
peer addresses
misconfigurations
addresses:peer:misconfigurations;misconfiguration:peer addresses;IP:addresses:misconfigurations
peer IP addresses
reconfigurations
reconfiguration:peer IP addresses
peer LACs [See also LACs]
peer LCCEs
sample L2TPv3 configurations
VCID mismatches
LCCE:VCID mismatches;VCID:peer LCCE mismatches;mismatches:Peer LCCE VCIDs
peer LSR
label bindings
labels:bindings:peer LSR;bindings:label:peer LSR;advertisments:label bindings:peer LSR
peer-to-peer VPN model
peers
LDP
authentication;authentication:LDP:peers
tunnels
maintenance
penultimate hop popping
hops
penultimate hop popping;LSR:penultimate hop popping
Perfect Forward Secrecy (PFS)
PFS (Perfect Forward Secrecy)
permanent virtual path (PVP)
PVP (permanent virtual path)
connections:PVP
PERRIS_POOL (IP pool)
PIM
adjacencies
adjacencies:PIM
BGP
updating;BGP:PIM:updating;updating:PIM:BGP;interfaces:BGP:configuring PIM
PIM Bi-directional (PIM-BIDIR)
PIM-BIDIR (PIM Bi-directional)
PIM Dense Mode (PIM-DM)
PIM-DM (PIM Dense Mode)
modes:PIM-DM
PIM Source Specific Multicast (PIM-SSM)
PIM-SSM (PIM Source Specific Multicast)
PIM Sparse-Mode (PIM-SM)
PIM-SM (PIM Sparse-Mode)
modes:PIM-SM
ping command
commands
ping
ping;connections:IPSec peers:troubleshooting;peers:IPSEc:troubleshooting
MPLS VPNs
commands:ping:MPLS VPNs;traceroute command:MPLS VPNs;commands:traceroute:MPLS VPNs 2nd
tunnel LSP location
commands:ping:tunnel LSP location
point-of-presence (POP)
POP (point-of-presence)
Point-of-Presence (POP)
POP (Point-of-Presence)
Point-to-Point Tunneling Protocol
protocols
PPTP [See PPTP, PPTP;tunneling:PPTP. See also PPPTP]
port mode, ATM cell relat
ATM
cell relay;cell relay:ATM
PPP
authentication
authentication:PPP
autodetection
autodetection:PPP
encapsulation
encapsulation:PPP
PPP (Point-to-Point Protocol)
SLIP (Serial Line Internet Protocol)
protocols:PPP;protocols:SLIP
PPTP
authentication
troubleshooting;troubleshooting:PPTP:authentication;PPP:authentication:troubleshooting;authentication:PPP:troubleshooting 2nd
case studies
MPPE attributes not returned;case studies:PPTP:MPPE attributes not returned;MPPE:attributes not returned:RADIUS:MPPE:attributes not returned from 2nd
split tunnels;case studies:PPTP:split tunnels;split tunnelsPPTP;troubleshooting:split tunnels 2nd
commands
commands:PPTP;troubleshooting:PPTP:commands 2nd
configuring
configuration:PPTP 2nd
control channels
configuring;control channels:configuring;configuration:control channels;packets:control channels;formats:control channels 2nd
troubleshooting;troubleshooting:PPTP:control channels;control channels:troubleshooting;sessions:PPTP:troubleshooting;PPTP:sessions:troubleshooting;troubleshooting:PPTP:sessions 2nd
debug commands
commands:debug:PPTP;troubleshooting:PPTP:debug commands
LCP negotiation
troubleshooting;troubleshooting:PPTP:LCP negotiation;LCP:negotiation:troubleshooting;negotiation:LCP:troubleshooting 2nd
maintenance
maintenance:PPTP;packets:PPTP:maintenance;control channels:PPTP:maintenance;remote access clients:PPTP:maintenance 2nd
messages
messages:PPTP;packets:PPTP:messages;control channels:PPTP:messages;remote access clients:PPTP:messages;sessions:PPTP:messages 2nd
NCP negotiaton
troubleshooting;troubleshooting:PPTP:NCP negotiation;NCP:negotiation:troubleshooting;negotiation:NCP:troubleshooting 2nd
PPP negotiation
PPP:negotiation:PPTP;configuration:PPTP:PPP negotiation;negotiation:PPP:PPTP;frames:forwarding:PPTP;forwarding:frames:PPTP;PPTP:frame forwarding 2nd
sessions
configuring;sessions:PPTP:configuring;configuration:PPTP:sessions;OCRQ (Outgoing-Call-Request) messages;messages:OCRQ;Outgoing-Call-Request (OCRQ) messages;packets:OCRQ messages;formats:OCRQ messages 2nd
show commands
commands:show:PPTP;troubleshooting:PPTP:show commands
technical overview of
voluntary tunnel modes:technical overview of PPTP;remote access clients:PPTP;clients:remote access:PPTP 2nd
termination
termination:PPTP;packets:PPTP:termination;control channels:PPTP:termination;remote access clients:PPTP:termination;sessions:PPTP:termination;termination:PPTP 2nd
troubleshooting
troubleshooting:PPTP 2nd
virtual interfaces
troubleshooting;troubleshooting:PPTP:virtual interfaces;virtual interfaces:troubleshooting;cloning:virtual interfaces:preventing 2nd
PPTP (Point-to-Point Tunneling Protocol)
PPP
PPTP [See also PPTP]
PPTP Access Concentrator
PAC (PPTP Access Concentrator) [See PAC]
PPTP Network Server
servers
PNS [See PPTP Network Server;servers;PNS, PNS;PNS (PPTP Network Server)]
preshared keys
configuring
configuration:preshared keys;keys:preshared [See also preshared keys]
L2TP
over IPSec with;L2TP:IPSec:over with preshared keys;IPSec:L2TP:over with preshared keys
misconfigurations
misconfigurations:preshared keys
site-to-site IPSec VPNs
troubleshooting
troubleshooting:preshared keys
Primary Rate Interface (PRI)
verifying
PRI (Primary Rate Interface):verifying;verification:PRI;interfaces:PRI:verifying
Primary Rate Interfaces (PRIs)
PRIs (Primary Rate Interfaces)
interfaces:PRIs
proposal acceptances
Protocol Field Compression (PFC)
PFC (Protocol Field Compression)
compression:PFC
Protocol Independent Multicast (PIM)
PIM (Protocol Independent Multicast)
protocol none command
commands
protocol none
protocols
security [See also IPSec, L2TP (Layer Two Tunneling Protocol);security]
provider edge (PE) routers
PE (provider edge) routers
routers:PE
provisioning
MPLS VPNs
Proxy LCP
pseudowire classes
configuring
classes:pseudowire:configuring;configuration:pseudowire classes
pseudowires
AToM
troubleshooting;configuration:pseudowires:troubleshooting AtoM


Q

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [Z]

quick mode negotiation
negotiation
quick mode;modes:quick mode negotation


R

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [Z]

RADIUS
sever unreachabble from LNS
reconfiguration
authenticaton
PPTP;verification:PPTP:session setup
passwords
passwords:reconfiguring
VPDN groups
VPDN:groups:reconfiguring;groups:VPDN:reconfiguring
redistribute command
commands
redistribute
redistribute rip command
commands
redistribute ip
redistribution
MP-BGP
MP-BGP:redistribution;PE-CE routing protocol:MP-BGP redsitribution;ingress PE routers:redistribution;routers:PE:MP-BGP redistribution;PE routers:MP_BGP route redistribution
routes
MP-BGP;routes:MP-BGP:redistribution;redistribution:routes:MP-BGP;BGP:MP-BGP:route redistribution
Registration Authority (RA)
RA (Registration Authority)
remote AAA
authentication failures
authentication:remote AAA:troubleshooting;RADIUS:authentication failures 2nd
authorization failures
authorization:remote AAA:troubleshooting;RADIUS:authorization failures 2nd
configuring
AAA:remote:configuring;configuration:AAA:remote;local authentication:configuring;authentication:local:configuring;configuration:local authentication
L2TP
configuring;configuration:remote AAA:L2TP;AAA:remote:L2TP
Remote Authentication Dial-In User Service (RADIUS)
RADIUS (Remote Authentication Dial-in User Service)
remote VPN clients
IKE negotiation failure
clients:remote VPN:IKE negotiation failure;IKE:remote VPN clients:troubleshooting;negotiation:IKE:remote VPN client failure
Resource Reservation Protocol (RSVP)
RSVP (Resource Resevation Protocol)
protocols:RSVP
responders
preshared keys
preshared keys:responders;certerificates:responders;routers:responders;initiators:responders
quick mode
troubleshooting
Result Code AVP
Result Code AVPs
L2TPv3
result codes
CDN
verifying from;error codes:CDN:verifying from
CDN messages
PPTP
StopCCN messages
RIP
PE-CE routing
Route Distinguisher (RD)
RD (Route Distingusher)
Route Target (RT)
RT (Route Target)
router isis command
commands
router isis
router ospf 100 command
commands
router ospf 100
routers
clocks
configuring;clocks:configuring;time zones:configuring;configuration:clocks
configuring
configuration:routers;loading configuration files;configuration files:loading;files:configuration:loading 2nd
hostnames
hostnames:routers:domains:routers;routers:domains;names:domans:routers;names:hostnames:routers
platforms
platforms:routers;cabling;connections:cabling
routes
VPNs
advertisements;VPNs:advertisements:troubleshooting;advertisements:VPNs:troubleshooting;troubleshooting:VPNs:advertisements 2nd
routing
VPNs
forwarding:VPNs [See also VPNs, VPNs;instances:forwarding]
RSA key pairs, generating
generation
of RSA key pairs;keys;RSA key pairs:generating
RSVP


S

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [Z]

SAs
IKE
successful neogitation;IKW:SAs:successful negotiation;negotiation:IKE:SAs
Security Association Database (SAD)
SAD (Security Association Database)
databases:SAD
Security Parameter Index (SPI)
SPI (Security Parameter Index)
Security Parameters Index (SPI)
SPI (Security Parameters Index)
Security Policy Database (SPD)
SPD (Security Policy Database)
databases:SPD
sequences
PPTP tunnel setup
servers
AAA
servers:AAA:misconfiguration of L2F tunnel definitions;L2F:tunneling:misconfiguration on AAA servers 2nd [See also AAA]
addresses
configuring
service password-encryption command
commands
service password-encryption;reconfiguration:tunnel passwords;tunneling:passwords:reconfiguring;passwords:tunnels:reconfiguring
Session IDs
sessions
data message headers
headers:session data messages
management AVPs
L2TPv3;AVPs:L2TPv3:session management
Set-Link-Info (SLI) message
SLI (Set-Link-Info) message
messages:SLI
Set-Link-Info (SLI) packets
SLI (Set-Link-Info) packets
packets:SLI;formats:SLI packets
SHA-1 authentication
authentication
SHA-1
shim headers
headers
shim
show adjacency detail command
commands
show adjacency detail
show atm vc command
commands
show atm vc
show caller user command
commands
show caller user 2nd 3rd 4th
show caller user;verification:NCP negotiation
show clock command
commands
show clock;clocks:troubleshooting;troubleshooting:clocks
show commands
IPSec
commands:show:IPSec;debug commands:IPSec;commands:debug:IPSec 2nd 3rd
MPLS VPNs
commands:show:MPLS VPNs;debug commands:MPLS VPNs;commands:debug:MPLS VPNs 2nd
show controller e1 command
commands
show controller e1
show crypto ca certificates command
commands
show crypto ca certiicates
show crypto engine connections active command
commands
show crypto engine connections active
show crypto ipsec dynamic-map command
commands
show crypto ipsec dynamic-map
show crypto ipsec sa command
commands
show crypto ipsec sa
show crypto ipsec security-association lifetime command
commands
show crypto ipsec security-associaiton lifetime
show crypto ipsec transform-set command
commands
show crypto ipsec transform-set
show crypto isakmp key command
commands
show crypto isakmp key
show crypto isakmp sa command
commands
show crypto isakmp sa
show crypto key mypubkey rsa command
commands
show crypto key mypubkey rsa
show crypto key pubkey-chain rsa command
commands
show crypto key pubkey-chain rsa
show crypto map tag command
commands
show crypto map tag
show crypto map tag;verification:crypto map placement;placement:crypto maps:verifying
show ip access-lists command
commands
show ip access-lists 2nd 3rd 4th 5th
show ip bgp neighbors command
commands
show ip bgp neighbors
show ip bgp vpnv4 vrf vrf_name command
commands
show ip bgp vpn4 vrf vrf-name
show ip bgp vpnv4 vrf vrf_name
show ip bgp vpnv4 vrf vrf_name labels command
commands
show ip bgp vpnv4 vrf vrf_name labels
show ip cef command
commands
show ip cef 2nd
show ip cef summary command
commands
show ip cef summary;CEF:verifying;verification:CEF
show ip interface command
commands
show ip interface
show ip rip database vrf command
commands
show ip rip database vrf
show ip route command
commands
show ip route 2nd
show ip route vrf vrf_name static command
commands
show ip route vrf vrf_name static
show ip vrf detail vrf_name command
commands
show ip vrf detail vrf-name
show ip vrf interfaces command
commands
show ip vrf interfaces
show isdn status command
commands
show isdn status 2nd
show isdn status;alarms:remote:E1 controllers;remote alarms:E1 controllers;E1 controllers:remote alrams;signals:loss;loss of signals;reports:alarms
show l2tun session all command
commands
show 12tun session all
show l2tun tunnel all command
commands
show12tun tunnel all
show mpls atm-ldp capability command
commands
show mpls atm-ldp capability
show mpls forwarding-table command
commands
show mpls forwarding-table 2nd
show mpls interfaces command
commands
show mpls interfaces
show mpls l2transport binding command
commands
show mpls 12transport binding
show mpls l2transport hw-capability interface interface_name command
commands
show mpls 12transport hw-capability interface_name
show mpls l2transport summary command
commands
show mpls 12transport summary
show mpls l2transport vc command
commands
show mpls 12transport vc 2nd
show mpls l2transport vc vcid detail command
commands
show mpls 12transport vc vcid detail 2nd
show mpls ldp bindings command
commands
show mpls idp bindings
show mpls ldp bindings 2nd 3rd
show mpls ldp discovery command
commands
show mpls idp discovery
show mpls ldp discovery
show mpls ldp neighbor command
commands
show mpls ldp neighbor 2nd 3rd
show mpls ldp parameters command
commands
show mpls ldp parameters
show ppp mppe virtual-access number command
commands
show ppp mpe virtual-access number
show ppp multilink command
commands
show ppp multilink 2nd
show route-map command
commands
show route-map
show running-config command
commands
show running-config 2nd
show user command
commands
show user
show vpdn command
commands
show vpdn
show vpdn history failure command
commands
show vpdn history failure 2nd
show vpdn session all command
commands
show vpdn session all 2nd
show vpdn session command
commands
show vpdn session 2nd 3rd
show vpdn tunnel all command
commands
show vpdn tunnel all 2nd 3rd 4th 5th 6th
show vpdn tunnel command
commands
show vpdn tunnel 2nd
site-to-site VPNs
IPSec
remote access VPNs:IPSec
SKEME (Secure Key Exchange Mechanism for the Internet)
SKYDANCE_POOL
creating
configuration:SKYDANCE_POOL
SMI Network Management Private Enterprise Codes
SMI Network Management Private Enterprise Codes (RFC 1700)
split tunneling access lists
access list
split tunneling;tunneling:split tunneling access lists;configuration:split tunneling access lists
stack (S) bits
Start-Control-Connection-Connected (SCCCN)
SCCCN (Start-Control-Connection-Connected)
messages:SCCCN
Start-Control-Connection-Connected (SCCCN) message
Start-Control-Connection-Connected (SCCCN) message
messages:SCCCN
Start-Control-Connection-Reply (SCCRP)
SCCRP (Start-Control-Connection-Reply)
messages:SCCRP
Start-Control-Connection-Reply (SCCRP) message
SCCRP (Start-Control-Connection-Reply) message
messages:SCCRP
Start-Control-Connection-Request (SCCRQ)
SCCRQ (Start-Control-Connection-Request)
messages:SCCRQ
Start-Control-Connection-Request (SCCRQ) message
SCCRQ (Start-Control-Connection-Request) message
messages:SCCRQ 2nd
static routes
configuring
conifguration:static routes;routes:static:configuring
static sessions
L2TPv3
configuring;sessions:static:L2TPv3;configuration:static sessions:L2TPv3;LCCE:routers:static sessions (L2TPv3);routers:L2TPv3:static sessions 2nd
troubleshooting;sessions:L2TPv3:troubleshooting;L2TPv3:sessions:troubleshooting
Stop-Control-Connection-Notification (StopCCN) message
StopCCN (Stop-Control-Connection-Notification) message
messages:StopCCN
Stop-Control-Connection-Notification (StopCCN) messages
messages
StopCCN
StopCCRQ packet fields
fields
StopCCRQ packet;packets:StopCCRQ fields
sublayers
Layer 2
Layer 2:sublayers;AVPs:L2TP3:Layer 2 Specific Sublayer
switches
global ISDN parameters
configuring
switching
Frame Relay
trunks:Frame Relay:switching


T

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [Z]

T (transport type) bit
Tag Distribution Protocol (TDP)
TDP (Tag Distribution Protocol)
protocols:TDP 2nd 3rd
TDP/LDP router IDs, configuring
configuration
TDP/LDP router IDs;routers:IDs:configuring;IDs:routers:configuring
TE Tunnels
MPLS VPN
configuring;MPLS:TE tunnels:configuring;VPNs:MPLS:TE tunnels;tunnels:MPLS VPNs:conifguring;configuration:TE tunnels:MPLS VPNs;tunneling:TE tunnels:MPLS VPN traffic 2nd
teardown
PPP connections
PPP:teardown;connections:PPP [See also PPP;connections:PPP:teardown]
TERMACK messages
messages
TERMACK
Terminal Access Controller Access Control Server plus (TACACS+)
TACACS+ (Terminal Access Controller Access Control Server plus)
Terminate-Acks (TERMACKs)
Terminate-Request (TERMREQ)
TERMREQ (Terminate-Request)
Terminate-Requests (TERMREQs)
TERMREQ messages
messages
TERMREQ
testing
IP connectivuty
IP:connectivity:testing;connectivity:IP:testing
Time-to-Live (TTL)
TTL (Time-to-Live)
fields:TTL;Label field;fields:Label
tools
troubleshooting
tools;commands:tools;show command;ping command;traceroute command;debug command;commands:show;commands:ping;commands:traceroute;commands:debug 2nd
topologies
MPLS Layer VPNs [See also MPLS, VPNs]
traffic-engineering (TE) tunnels
TE (traffic-engineering) tunnels
tunneling:TE
tranform sets
IPSec
configuring;configuration:UPSec:transform sets
transform sets
configuring
configuration:transform sets
IPSec
IPSec:transform sets;configuration:transform sets
transparent forwarding
L2F [See also L2F]
transports
connections
connections:transports
Triple DES (3DES)
3DES (Triple DES)
troubleshooting
VPDNs
protocol mismatches
Tunnel IDs
tunnel path-mtu-discovery command
commands
tunnel path-mtu-discovery
tunnel protection command
commands
tunnel protection
tunneling
authentication
troubleshooting;authentication:tunneling:troubleshooting;troubleshooting:tunneling:authentication failures
troubleshooting;authentication:tunnels:troubleshooting;troubleshooting:authentication:tunnels
IPsec
traffic;traffic:IPSec:troubleshooting;troubleshooting:IPSec:tunneling;peers:IPSec:troubleshooting tunneling 2nd
L2F
multiple sessions;multiple sessions:tunneling:L2F
LSP
locating;locating LSP tunnels
secrets
configuring;secrets:tunneling:configuring;configuration:tunneling:secrets;enabling:VPDNs;VPDNs:enabling;VPDNs:groups:configuring;groups:VPDNs:configuring;configuration:VPDNs:grouops
configuring;secrets:tunnels:configuring;configuration:tunneling:secrets;VPDNs:enabling;enabling:VPDNs;configuration:VPDNs:groups;groups:VPDNs:configuring;VPDNs:groups:conifguring
shutdown
shutdown:tunnels


U

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [Z]

unsolicited downstream label distribution
user-to-tunnel associations
usernames
reconfiguring
reconfiguration:usernames;passwords:reconfiguring;reconfiguration:passwords;Home Gateways:passwords:reconfiguring


V

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [Z]

VC
ID mismatches
mismatches:VC ID
types
mismatches;types:VC:mismatches;mismatches:VC types
types:VC
VC mode, ATM cell relay
Vendor-ID field
verfication
tunnel LSP
verification
access lists
AToM;access list:AToM:verifying presence of
PPTP tunnels
virtual interfaces
PPTP
VPDN groups
PPTP
Virtual Circuit ID (VCID) values
VCID (Virtual Circuit) values
values:VCID
virtual template interfaces
L2TP
interfaces:virtual template:L2TP;configuration:virtual template interfaces:L2TP
virtual templates
creating
templates:virtual:creating;configuration:virtual templates;VPDNs:groups:creating virtual templates;groups:VPDNs:creating virtaul templates
IP addresses
configuring;templates:virtual:conifguring IP addresses;IP:addresses:virtual templates;addresses:IP:virtual templates
PPTP
templates:virtual:PPTP;PPTP:virtual templates
VLAN (802.1Q) interfaces
encapsulation
encapsulation:VLAN (802.1Q) interfaces:interfaces:VLAN (802.1Q) encapsulation
voluntary tunnel modes
voluntary tunnels modes
PPTP [See also PPTP]
VP mode, ATM cell relay
ATM
cell relay;cell relay:ATM
VPDN
groups
PPTP;groups:VPDNs:PPTP:PPTP:VPDN groups
mismatches
protocols:VPDN:mismatches;mismatches:VPDN
vpdn domain-delimiter command
commands
vpdn domain-delimiter
vpdn multihop command
commands
vpdn multihop
vpdn search order domain command
commands
vpdn search order domain
vpdn session-limit sessions command
commands
vpdn session-limit sessions
vpdn softshut command
commands
vpdn softshut
vpdn softshut;disabling:VPDN softshut
VPDNs
error messages
error messages:VPDNs;L2F:VPDNs:error messages;troubleshooting:L2F:error messages
groups
misconfiguration of domain names;groups:VPDNs:misconfiguration of domain names;domains:names:VPDNs;names:domains:VPDNs
L2TP
enabling;enabling:VPDNs:L2TP;groups:VPDNs:L2TP;configuration:VPDNs:L2TP
protocol mismatches
protocols:VPDN mismatches;mismataches:VPDN protocol
session limitations
limitations:VPDN sessionsHome Gateways:VPDNs:session limitations
VPI
ranges
troubleshooting;ranges:VPI:troubleshooting;LC-ATM interfaces:VPI ranges:troubleshooting;interfaces:LC-ATM:troubleshooting VPI ranges;peers:LC-ATM interfaces:troubleshooting VPI ranges;overlaps:VPI ranges
VPN Routing and Forwarding (VRF)
VRF (VPN Routing and Forwarding)
routing:VRF;forwarding:VRF;instances:VRF;tables:VRF;PE routers:VRF;routers:PE:VRF
VPN-IPv4 (VPNv4) address family, troubleshooting
VPNs
Layer 3 MPLS
configuring;MPLS:Layer 3 VPNs:configuring;configuration:MPLS Layer 3 VPNs 2nd
P router configuration;MPLS:Layer 3 VPNs:P router configuration;configuration:MPLS Layer 3 VPNs:P routers;P routers:configuring;routers:P:configuring 2nd
PE router smaple configuration;MPLS:Layer 3 VPNs:PE route smaple configuration;configuration:MPLS Layer 3 VPNs:PE routers;PE:routers:conifguring;routers:PE:configuring 2nd
technical overview of;MPLS:Layer 3 VPNs:technical overview of;troubleshooting:MPLS Layer 3 VPNs:technical overview of 2nd
route distribution
routes:VPN;distribution:VPN routes
VRF
interfaces
configuring;configuration:VFRs:interfaces;interfaces:VFRs:configuring
Interfaces
PIM;interfaces:VRF:PIM;PIM:VRF interfaces;configuration:PIM:VRF interfaces
packet leaking


W

Previous Page
Next Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [Z]

WAN-Error-Notify (WEN) message
WEN (WAN-Error-Notify) message
messages:WEN


Z

Previous Page

Index

[SYMBOL] [A] [B] [C] [D] [E] [F] [G] [H] [I] [K] [L] [M] [N] [O] [P] [Q] [R] [S] [T] [U] [V] [W] [Z]

Zero-Length-Body Acknowledgment (ZLB Ack)
ZLB (Zero-Length-Body Acknowledgement)
ZLB Ack (Zero-Length-Body Acknowledgement)